On Thu, Jul 21, 2011 at 02:50:48AM +0100, Connor Lane Smith wrote:
> On 21 July 2011 02:19, Phillip Warner wrote:
> > The only issue I have with the latest release is the file name 'lsx'. It's
> > already taken.
>
> Hmm, that's unfortunate, but lsx has been named that since 2006 [1],
> and some
On 21 July 2011 02:19, Phillip Warner wrote:
> The only issue I have with the latest release is the file name 'lsx'. It's
> already taken.
Hmm, that's unfortunate, but lsx has been named that since 2006 [1],
and some greedy alias is just annoying. That one package claims lrb,
lrx, lsb, lsx, rb,
On Tue, Jul 19, 2011 at 4:48 PM, Connor Lane Smith wrote:
>
> I've just released dmenu-4.4. It fixes some bugs and it should be
> slightly nippier, especially if your path is, ahem, broken.
>
> (Hopefully there won't be 4.4.1! :p)
The only issue I have with the latest release is the file name '
> I can reproduce that fullscreen flash requires this. Flash creates a
> new window with "" title and class and sets the
> _NET_WM_FULLSCREEN property. Maybe as a solution it makes sense to
> check for _NET_WM_FULLSCREEN property in manage() and set
> c->isfullscreen (and modify some layout functio
On Wed, Jul 20, 2011 at 8:39 PM, garbeam wrote:
>
>> Current discussion on the mailing list is leaning to just eliminating that
>> chunk of code. Apparently, flash fullscreen requires it (which I haven't
>> been able to reproduce!) But why on earth is that code there, and can't
>> flash fullscre
On 20 July 2011 21:11, ilf wrote:
> On 07-20 20:52, garbeam wrote:
>>>
>>> Could the releasers please start providing checksums (or PGP signatures)
>>> for releases?
>>
>> We coped very well without it for many years, why is the lack of md5 files
>> a concern now?
>
> I always wondered if this had
On 20 July 2011 09:43, ilf wrote:
> Could the releasers please start providing checksums (or PGP signatures) for
> releases?
We do use Mercurial, which creates a hash for each revision. So if
this matters to you, clone the repository and checksum the contents?
cls
On 07-20 20:52, garbeam wrote:
Could the releasers please start providing checksums (or PGP signatures) for
releases?
We coped very well without it for many years, why is the lack of md5
files a concern now?
I always wondered if this had been discussed and rejected or just never
thought about
On 20 July 2011 10:43, ilf wrote:
> On 07-19 21:48, Connor Lane Smith wrote:
>>
>> tarball: http://dl.suckless.org/tools/dmenu-4.4.tar.gz
>
> Thanks for all.
>
> Could the releasers please start providing checksums (or PGP signatures) for
> releases?
We coped very well without it for many years,
I think we should send the suckless van to the sender and raid their
homes to authenticate the release.
I feel like I can't be sure who I'm talking to on this mailing list
any more. Everyone show their ids now or I will call the police!
On 12 July 2011 15:34, Connor Lane Smith wrote:
> I noticed a slight aesthetic 'bug' in dwm's tile layout, which can
> cause the stack to 'shake' when your master changes, if your config.h
> respects resizehints, because it uses c->w instead of mw. Patch
> attached. (If I'm honest I don't know wha
On 19 July 2011 17:49, Connor Lane Smith wrote:
> And here's a usability bug. (I don't have a patch for this one.)
>
> If you have the following clients:
>
> A (tag 1)
> B (tag 2)
> C (tags 1,2)
>
> Whenever you switch from tag 1 to 2, client C will *always* be
> focused, even if it your last two
Hi Peter,
On 11 July 2011 01:02, Peter John Hartman wrote:
> Actually, this bug goes way back, but I thought I'd be the first to report
> it, just to ruin dwm's birthday. The culprit is this chunk of code in
> manage():
>
> if(c->w == c->mon->mw && c->h == c->mon->mh) {
> /
Hi lolilolicon,
On 20 July 2011 17:53, lolilolicon wrote:
> I have a rule in config.h for MPlayer to always float. The bug was
> observed when I played a 720p video whose window was 1280 pixels so it
> filled the width of my laptop screen. The MPlayer window was supposed to
> be centered, but a b
On Wed, Jul 20, 2011 at 11:32:25AM -0400, Peter John Hartman wrote:
> Why not just have a quick once-over of the code? There's a reason suckless
> apps aim to be under a certain SLOC limit, and I take it that one of these
> is so that one can have a quick once-over of the code. And if the distro
I have a rule in config.h for MPlayer to always float. The bug was
observed when I played a 720p video whose window was 1280 pixels so it
filled the width of my laptop screen. The MPlayer window was supposed to
be centered, but a border line on the left was clearly visible. For
further confirmation
Why not just have a quick once-over of the code? There's a reason suckless
apps aim to be under a certain SLOC limit, and I take it that one of these
is so that one can have a quick once-over of the code. And if the distro
maintainer can't do this, so much the worse for the distrubition.
Peter
On Wed, 20 Jul 2011 11:06:37 +0100
Nick wrote:
> as mentioned trusting CAs (HTTPS) is
> pretty problematic.
This is more problematic, because there is no clear way of knowing
which CAs your browser trust e.g. removing CNNIC (China Internet
Network Information Center) doesn't help at all.
CA can
On Wed, Jul 20, 2011 at 7:02 AM, Kai Hendry wrote:
> Lets pretend I'm the package maintainer for Debian and I need to
> ensure that the dmenu I download indeed came from suckless and was not
> tampered with.
Why? If you're a package maintainer for Debian you're just going to
tamper with it anywa
On Wed, Jul 20, 2011 at 12:32:32PM +0200, markus schnalke wrote:
> On 20 July 2011 11:06, Nick wrote:
> > But just downloading the key from a keyserver, even if it isn't
> > trusted by your web of trust, is better than e.g. just
> > distributing a hash, [...]
>
> The concept of PGP trust lies in
On 20 July 2011 11:32, ilf wrote:
> Also I fail to see where "package meintainers" are involved.
Lets pretend I'm the package maintainer for Debian and I need to
ensure that the dmenu I download indeed came from suckless and was not
tampered with.
>> So would you be happy just with HTTPS and not
On 20 July 2011 11:06, Lukas Fleischer wrote:
> pacman 4.0.0 will support package signatures and we'll sign all packages
> in the official repos ([core], [extra], [community]) soon.
Debian IIRC just signs the package lists (including checksums) in
practice, which is fine.
I hope there isn't goin
On 07-20 11:16, Kai Hendry wrote:
In the mail with the release announcement.
checksums in the announcement is something as a package maintainer you
can't automate and has to be manual and hence sucks.
I believe the mail that started this thread is not automated.
Also I fail to see where "pack
On 20 July 2011 11:06, Nick wrote:
> But just downloading the key from a keyserver, even if it isn't
> trusted by your web of trust, is better than e.g. just
> distributing a hash, [...]
The concept of PGP trust lies in the Web-of-Trust, nowhere else. If
you don't find a trust-path from you to th
On Wed, Jul 20, 2011 at 10:58:32AM +0100, Kai Hendry wrote:
> On 20 July 2011 10:54, Nick wrote:
> > wget http://dl.suckless.org/tools/dmenu-4.4.tar.gz.sig
> > gpg --verify dmenu-0.4.tar.gz.sig
> > is not that tricky.
>
> You've skipped over the part of how you exchange the public key, no?
Jus
On 20 July 2011 11:11, ilf wrote:
> In the mail with the release announcement.
checksums in the announcement is something as a package maintainer you
can't automate and has to be manual and hence sucks.
> Of course X.509 is broken and everything sucks, but it's what we have to
> live with. And b
On 07-20 10:47, Kai Hendry wrote:
"publishing the SHA" sounds crappy to me. How do you do it? In a wiki?
In a text file? All suck.
In the mail with the release announcement.
HTTPS I can _just_ about live with, but that's crappy too really.
Of course X.509 is broken and everything sucks, but
On 20 July 2011 11:06, Nick wrote:
> But just downloading the key from a keyserver, even if it isn't
> trusted by your web of trust, is better than e.g. just
> distributing a hash, and as mentioned trusting CAs (HTTPS) is
> pretty problematic.
Why is a random keyserver more trustworthy than a run
On Wed, Jul 20, 2011 at 10:58:32AM +0100, Kai Hendry wrote:
> On 20 July 2011 10:54, Nick wrote:
> > wget http://dl.suckless.org/tools/dmenu-4.4.tar.gz.sig
> > gpg --verify dmenu-0.4.tar.gz.sig
> > is not that tricky.
>
> You've skipped over the part of how you exchange the public key, no?
Tha
On 20 July 2011 10:54, Nick wrote:
> wget http://dl.suckless.org/tools/dmenu-4.4.tar.gz.sig
> gpg --verify dmenu-0.4.tar.gz.sig
> is not that tricky.
You've skipped over the part of how you exchange the public key, no?
If it's not that tricky why doesn't Arch for example build it in to their t
On Wed, Jul 20, 2011 at 10:47:28AM +0100, Kai Hendry wrote:
> HTTPS I can _just_ about live with, but that's crappy too really.
> Anyone can get a HTTPS cert, so how can you test sanely that it indeed
> came from suckless when sucking it down with curl? Surly it's more of
> a DNS thang we need to r
On 20 July 2011 10:41, ilf wrote:
> On 07-20 10:20, Kai Hendry wrote:
> Both HTTPS and SHA(1|256) shouldn't really be a problem.
You mean HTTPS download and publishing the SHA somewhere?
"publishing the SHA" sounds crappy to me. How do you do it? In a wiki?
In a text file? All suck.
HTTPS I can
On 07-20 10:20, Kai Hendry wrote:
Might it be satisfactory to just supply some sort of DNS level
security and/or use HTTPS? I dunno.
Both HTTPS and SHA(1|256) shouldn't really be a problem.
--
ilf
Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
-- Ein
On 20 July 2011 09:43, ilf wrote:
> Could the releasers please start providing checksums (or PGP signatures) for
> releases?
Might it be satisfactory to just supply some sort of DNS level
security and/or use HTTPS? I dunno.
I just know PGP checksums are a bit painful to say the least.
On 07-19 21:48, Connor Lane Smith wrote:
tarball: http://dl.suckless.org/tools/dmenu-4.4.tar.gz
Thanks for all.
Could the releasers please start providing checksums (or PGP signatures)
for releases?
Now that'd be great..
--
ilf
Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich
35 matches
Mail list logo
