Daniel Bolton | 2 Mar 13:22 2010
Picon

wmii 3.9b1 deb contains no binary

I downloaded the wmii 3.9b1 tarball here:

   http://dl.suckless.org/wmii/wmii+ixp-3.9b1.tbz

and proceeded to build a debian package, per the instructions in the README
file. I made three changes: 1) I changed PREFIX to "/usr", 2) I changed ETC
to "/etc", and I did not build the package via the "deb" make target, as the
build would fail due to gpg errors. Instead I built it via

   dpkg-buildpackage -rfakeroot -us -uc

The build finished and no errors were visible. However, the resulting
deb contained only the following files:

   /usr/share/doc/wmii-hg/changelog.gz
   /usr/share/doc/wmii-hg/copyright
   /usr/share/doc/wmii-hg/README

So, why wasn't a binary produced? Thinking that I messed up somewhere, I
started over in a clean directory and did NOT edit any files before building
the package, but once again the deb contained only the aforementioned three
files.

The means by which I am viewing these files is copying the deb to a new
directory and running "dpkg -x wmii-hg_hg2550_amd64.deb .". This is the
only deb produced.

Could someone explain why the deb doesn't have a wmii binary in it?

Thanks,
(Continue reading)

Suraj Kurapati | 3 Mar 00:43 2010
Picon

Re: [wmii] Reproducible crashes with "dead" windows

On Wed, Feb 24, 2010 at 1:29 PM, Tom Kazimiers <tom <at> voodoo-arts.net> wrote:
>> I will add error checking, to detect a missing "label" section, right
>> at the beginning when the status bar applet is initialized.
>
> That would be great. Improvements in robustness are most of tho time a
> good thing.

Done:

http://github.com/sunaku/wmiirc/commit/84c268c427d146b8e8b7297e90ba6e4db152b759

>> 7. Run the gdb commands on the core dump file.
>
> if I understand the output correct, wmii is not the problem:
>
> Core was generated by `/usr/lib/nspluginwrapper/i386/linux/npviewer.bin
> --plugin /usr/lib/flashplugin-'.
> Program terminated with signal 11, Segmentation fault.
>
> I hate the Adobe flash player

:-)

> I don't know what the gdb means for my problem (I even had
> flash not running). Like I said before: It is reproducable by having a
> window in moving (grab/pan?) mode (so they are floating) while closing
> it.

I am able to reproduce this by opening an xterm in the floating area,
running "sleep 3; exit" command in the xterm, then grabbing it and
(Continue reading)

Anselm R Garbe | 3 Mar 09:07 2010
Picon

GSoC 2010

Hi there,

GSoC 2010 has kicked of and is looking for mentoring organisations
next week, hence it's time now to get organised.

Who is willing to mentor this time?

What project ideas do you have apart from http://suckless.org/project_ideas?

Note, to be successful this time, we need to focus on a bunch of
similar projects according to Google's feedback of last year. They
basically argued that our proposals were too diverse.

I'd say let's have a deadline until Saturday for these discussions and
in order to have enough time to create a successful application on
Monday. I also got the impression that early applications are checked
more carefully by the Google guys as late applications (afaik our
application was neither early or late last time) -- but this time I
want to press the submit button as early as possible.

Cheers,
Anselm

Martin Kopta | 3 Mar 09:22 2010
Picon

Re: GSoC 2010

On Wed, Mar 03, 2010 at 08:07:19AM +0000, Anselm R Garbe wrote:
> Hi there,
> 
> GSoC 2010 has kicked of and is looking for mentoring organisations
> next week, hence it's time now to get organised.
> 
> Who is willing to mentor this time?
> 
> What project ideas do you have apart from http://suckless.org/project_ideas?

"Create stali stable release"

~dum8d0g

Anselm R Garbe | 3 Mar 09:41 2010
Picon

Re: GSoC 2010

On 3 March 2010 08:22, Martin Kopta <martin <at> kopta.eu> wrote:
> On Wed, Mar 03, 2010 at 08:07:19AM +0000, Anselm R Garbe wrote:
>> Hi there,
>>
>> GSoC 2010 has kicked of and is looking for mentoring organisations
>> next week, hence it's time now to get organised.
>>
>> Who is willing to mentor this time?
>>
>> What project ideas do you have apart from http://suckless.org/project_ideas?
>
> "Create stali stable release"

Stali is definately a topic, forgot to mention this. The project idea
a colleague of mine at work came up with is creating wether a
completely new ld or ld wrapper at the least to collect all info when
a shared lib/executable is linked and using this info to create a
static library/executable instead, basically kind of a tee ld if you
like, where one result invisible to the caller is a static lib instead
of a dynamic one ;) This would enable building nearly everything
statically without the need of extra makefiles. I don't consider this
approach for the base system, since the value in it is all about
decent make files, but this might be a cool project for all other
stuff and would fit the GSoC scope quite well.

Cheers,
Anselm

Johannes Wegener | 3 Mar 09:53 2010
Picon
Picon

Re: GSoC 2010

I would love to see a suckless windowing system. I know 
that it is a point on the project page. But that is something
I see as a important thing for me. But I'm also not sure
if that is something which can be done during the GSoC.

I think the approch of Stali is intresting but since
I'm a BSD guy it doesn't intrest me so much.

On Wed, Mar 03, 2010 at 08:07:19AM +0000, Anselm R Garbe wrote:
> Hi there,
> 
> GSoC 2010 has kicked of and is looking for mentoring organisations
> next week, hence it's time now to get organised.
> 
> Who is willing to mentor this time?
> 
> What project ideas do you have apart from http://suckless.org/project_ideas?
> 
> Note, to be successful this time, we need to focus on a bunch of
> similar projects according to Google's feedback of last year. They
> basically argued that our proposals were too diverse.
> 
> I'd say let's have a deadline until Saturday for these discussions and
> in order to have enough time to create a successful application on
> Monday. I also got the impression that early applications are checked
> more carefully by the Google guys as late applications (afaik our
> application was neither early or late last time) -- but this time I
> want to press the submit button as early as possible.
> 
> Cheers,
(Continue reading)

Anselm R Garbe | 3 Mar 09:53 2010
Picon

Re: GSoC 2010

Another idea that I'd like to push this year is the creation of a
suckless issue tracking/bug tracking system. All existing systems suck
and it is still a burden for projects and small businesses to track
bugs or customer issues in less sucking ways. The existing
alternatives are all a big desgrace, can't speak of those commercial
ones, but I guess they ain't any better than the floss ones.

Approaches like trac do too many things, and hence fail at doing issue
tracking right. A friend pointed me to the debian bug tracking system
(http://www.debian.org/Bugs/server-refcard) and I must admit I kind of
like parts of it.

I think it is a strong requirement for a decent issue tracker to have
a decent mail integration, people don't want to use hairy web
interfaces and developers or customer relation staff doesn't wants to
use them either -- RT for instance is good in the mail integration,
but it does too many things and has a bad web interface that really
sucks.

Kind regards,
Anselm

pancake | 3 Mar 11:09 2010

Re: GSoC 2010

+1

Current bugtrackers sucks.

The linker proposal, looks interesting, but i dont get the idea at all,
i would do it if i get bored somewhile..but i can't trick google to say
that i'm a student. Is your idea to create a static bin from a shared one?
There's a program called 'staticify' or something like this that does it.

Do somebody checked 'bug'? a simple todo/bugtracker for commandline?

  http://vicerveza.homeunix.net/~viric/soft/bug/

Another topic I would like to open is about 'suckless games'. Recently
I have discovered 'jvgs' and 'ledboy' which bring me some fun and think
about minimalistic games with fun inside, originality and clean code.

The problem here for example..is that jvgs is c++ with stupid dependencies
like lua or cmake, ledboy is just hardware, most of games are bloated, 
filled
with silly graphics and big media stuff, but lacking any kind of 
simplicity and
clean code on it.

  http://jvgs.sourceforge.net/
  http://hackaday.com/2009/12/08/ledboy-super-pixel-brothers/

Sure, there are bsdgames, and few years ago I wrote 'pag' a platform
arcade game in text mode..but the code I wrote 10 years ago sucks..

(Continue reading)

pancake | 3 Mar 11:17 2010

Re: GSoC 2010

About the mail part of the bug tracker.. why not push 'dmc'? and
fix the imap protocol, implement the SMTP part and write a frontend.

This can sound like not so much work..but it does from the side that
it is actually not usable application, and it needs some love.

I think that a decent minimal mail solution is mandatory for most of us..
So.. is anyone going to work on it? :)

--pancake

Anselm R Garbe wrote:
> Another idea that I'd like to push this year is the creation of a
> suckless issue tracking/bug tracking system. All existing systems suck
> and it is still a burden for projects and small businesses to track
> bugs or customer issues in less sucking ways. The existing
> alternatives are all a big desgrace, can't speak of those commercial
> ones, but I guess they ain't any better than the floss ones.
>
> Approaches like trac do too many things, and hence fail at doing issue
> tracking right. A friend pointed me to the debian bug tracking system
> (http://www.debian.org/Bugs/server-refcard) and I must admit I kind of
> like parts of it.
>
> I think it is a strong requirement for a decent issue tracker to have
> a decent mail integration, people don't want to use hairy web
> interfaces and developers or customer relation staff doesn't wants to
> use them either -- RT for instance is good in the mail integration,
> but it does too many things and has a bad web interface that really
> sucks.
(Continue reading)

Anselm R Garbe | 3 Mar 11:26 2010
Picon

Re: GSoC 2010

On 3 March 2010 10:09, pancake <pancake <at> youterm.com> wrote:
> About the distro I think it requires so many stuff on it, so at this moment
> I think is more important to push partial projects before working on stali.

These are the current main drivers of stali (or my take on it):

a) having a decent toolchain and build system for embedded development
(which is lacking big time in most of such projects like maemo and
friends), the real value are the mkfile's here that ignore the
configure hell completely.

b) to prove that static linking produces slimmer systems that run
faster, use less memory and are more secure -- contrary to all those
pseudo-arguments the dynamic linking fan boys came up with.

Cheers,
Anselm


Gmane