Re: Bug#679078: ITP: acpi-support-minimal -- minimal acpi scripts

[Vincent Bernat]

 ❦  7 juillet 2012 20:38 CEST, Michael Meskes  :

>> The bug is already closed but I'd like to share another solution: I am
>> using "acpi_fakekey $KEY_COFFEE" which sends XF86ScreenSaver key to the
>> currently displayed X server. This is not foolproof (only one X server,
>> only if it is currently displayed) but it is far simpler than other
>> solutions.
>
> Sorry, but what is "acpi_fakekey $KEY_COFFEE" supposed to accomplish? Sending
> XF86ScreenSaver key? I don't really how this relates to this big report. Could
> you please explain?

Yes, this would send the XF86ScreenSaver which would kick the
screensaver of the currently displayed X session. This is another
(imperfect) way to solve the problem of locking the user's screen
without needing either an entry in /var/run/utmp or consolekit.
-- 
Use self-identifying input.  Allow defaults.  Echo both on output.
- The Elements of Programming Style (Kernighan & Plauger)


pgpRBMGfoS9fD.pgp
Description: PGP signature

Re: Bug#679078: ITP: acpi-support-minimal -- minimal acpi scripts

[Vincent Bernat]

 ❦ 26 juin 2012 14:48 CEST, Michael Meskes  :

>> I'll be reopening 665987, but if that gets closed again I'd be very
>> happy to switch to acpi-support-minimal from my now locally built
>> acpi-support packages w/ the consolekit dependency removed.
>
> I'm not sure I like the attitude here. "If that gets closed again" sounds like
> I was closing the bug without a reason, which I didn't. I'm absolutely willing
> to listen to ideas of solving this, which imo would be a much better solution
> than creating an additional package that will only partly work. But please 
> don't
> forget that upstream started using consolekit for a reason. 

The bug is already closed but I'd like to share another solution: I am
using "acpi_fakekey $KEY_COFFEE" which sends XF86ScreenSaver key to the
currently displayed X server. This is not foolproof (only one X server,
only if it is currently displayed) but it is far simpler than other
solutions.
-- 
Don't stop with your first draft.
- The Elements of Programming Style (Kernighan & Plauger)


pgpHazP7UuTUH.pgp
Description: PGP signature

Re: apt-get source gets a more recent version of linux than I can install

[Vincent Bernat]

 ❦ 26 juin 2012 21:02 CEST, Philip Ashmore  :

> I noticed a few hours ago that apt-get source linux gets me 3.2.21-1,
> but the I have the "latest" kernel installed which is 3.2.20-1. What
> gives?

The latest one may not be available for your architecture on your
current mirror yet.
-- 
die_if_kernel("Whee... Hello Mr. Penguin", current->tss.kregs);
2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c


pgpo41FYrozny.pgp
Description: PGP signature

Re: "could not perform immediate configuration"

[Vincent Bernat]

 ❦ 25 juin 2012 14:28 CEST, Tanguy Ortolo  :

>> The change between Wheezy and Squeeze is that roundcube-sqlite package
>> has been dropped.
>
> Any specific reason for that? Looking at the upstream website, they do
> not seem to have dropped SQLite compatibility…

PHP doesn't have support for SQLite 2.x in Debian anymore.
-- 
#if 0
2.2.16 /usr/src/linux/fs/buffer.c


pgpou72wnucUL.pgp
Description: PGP signature

Re: Bug#678815: ITP: wmfs -- Window Manager From Scratch

[Vincent Bernat]

 ❦ 24 juin 2012 19:15 CEST, Neil Williams  :

>> > I shortened the list to only include one line for each window manager 
>> > already 
>> > in Debian:
[...]

I think the list is incomplete. For example, awesome is not in it but is
properly tagged.

>> You're right, there are already a lot of X11 window managers in Debian ...
>> 
>> But WMFS is not already in the list and it works fine, that's why I want to 
>> package it :-)
>
> That is no reason for it to be in Debian.
>
> Debian is not a dumping ground for every piece of free software just
> because it "works fine".

A window manager is something highly personal (like an editor). You put
a lot of effort to configure it and to get used to it. If Debian didn't
had my favorite window manager, I would be quite unhappy to have to
learn one which was here before. Plus, I would need to rewamp my whole
configuration.
-- 
printk("??? No FDIV bug? Lucky you...\n");
2.2.16 /usr/src/linux/include/asm-i386/bugs.h


pgpEPo0Z6a2FK.pgp
Description: PGP signature

Re: "could not perform immediate configuration"

[Vincent Bernat]

 ❦ 24 juin 2012 15:50 CEST, David Kalnischkies  :

>> This should be working in apt in wheezy (I didn't verify it), but that
>> is not available at dist-upgrade time.
>
> I can't reproduce this in either version with our usual testcase creator
> (apt/test/integration/create-test-data), but these testcases aren't exactly
> what helps here, so it's kind of expected. If you want a definite answer
> attaching a real /var/lib/dpkg/status to the bugreport should help.
[...]

> Back at the problem at hand:
> I think it is more a problem of the tree below roundcube-*:
> php-mdb2-driver-sqlite is dropped from wheezy, too
> (which btw has still horde3 and ansel1 as rev-depends in or-groups).
> php5-sqlite breaks roundcube-sqlite, so different roundcube-*sql*
> packages can't co-exist.
>
> Not sure why exactly that should be a problem, but a transitional
> package probably doesn't hurt.
> [Haven't looked too deeply into it as neither time nor data plan allows
>  it though, so I reserve the right to change my mind any minute]

I have uploaded a new version with roundcube-sqlite as a transitional
package. This seems to solve the problem. I don't have time to dig more
and since you don't have time either, this seems a good match. ;-)

Hopefully, the Breaks in php5-sqlite is versioned.
-- 
Don't over-comment.
- The Elements of Programming Style (Kernighan & Plauger)


pgprcVbgouOdQ.pgp
Description: PGP signature

Re: Bug#677803: "could not perform immediate configuration"

[Vincent Bernat]

 ❦ 23 juin 2012 18:32 CEST, Vincent Bernat  :

> I have asked help in debian-devel@ (but forgot the Cc).
[...]

Oh, I didn't realized that you crossposted. ;-)
-- 
printk("HPFS: G... Kernel memory corrupted ... going on, but 
it'll crash very soon :-(\n");
2.4.3 linux/fs/hpfs/super.c


pgpaHFvDEOnkC.pgp
Description: PGP signature

Re: Bug#677803: "could not perform immediate configuration"

[Vincent Bernat]

 ❦ 23 juin 2012 18:23 CEST, Andreas Beckmann  :

> This should be working in apt in wheezy (I didn't verify it), but that
> is not available at dist-upgrade time.
>
>> A conflict with `roundcube-sqlite`
>> may work but is it sane to add "Conflicts" for this?
>
> I just tested Breaks and Conflicts with roundcube-sqlite (in the end
> added them to all binary packages built from roundcube source), this
> does not help at all (it could influence apt to prefer the decision to
> remove roundcube-sqlite, but that was its intention from the very
> beginning). (And I also suggested to add Breaks in another bug report
> (#677403) for a different Package (gdal) to make a conflict explicit
> which could be derived previously by following a chain of several
> packages ...)
>
> On the other hand, adding the following transitional package:
>
> Package: roundcube-sqlite
> Architecture: all
> Depends: roundcube-mysql | roundcube-pgsql
> Description: transitional dummy package to aid upgrades
>  "Transitional packages are your friend, conflicts are not" D.K.
>  Closes: #677803
>
> solves the problem.

I have asked help in debian-devel@ (but forgot the Cc). But your
solution seems good in fact. I didn't think it in this way. This seems
equivalent to the current situation where someone installs roundcube
From scratch and get roundcube-mysql unless it explicitely installs
roundcube-pgsql. If I don't get any answer tomorrow in debian-devel@, I
will implement your solution.
-- 
10.0 times 0.1 is hardly ever 1.0.
- The Elements of Programming Style (Kernighan & Plauger)


pgpfUhxY7CHX8.pgp
Description: PGP signature

"could not perform immediate configuration"

[Vincent Bernat]

Hi!

I have a problem with one of my packages and I am unable to see the
beginning of a solution for it. The bug report is here:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677803

In Squeeze, `roundcube` depends on `roundcube-core` which depends on
`roundcube-sqlite | roundcube-mysql | roundcube-pgsql`. Each of those
packages depends on the appropriate PHP package and client for the given
database.

When upgrading to Wheezy, I have:

#v+
E: Could not perform immediate configuration on
'roundcube-mysql'. Please see man 5 apt.conf under
APT::Immediate-Configure for details. (2)
#v-

The manual page does not help me. There is no circular dependency and
the priority of packages is "extra".

The change between Wheezy and Squeeze is that roundcube-sqlite package
has been dropped. `roundcube-core` now depends on `roundcube-mysql |
roundcube-pgsql`. I suppose this is why I get the error but I don't know
how to solve it.

I was suggested to turn `roundcube-sqlite` into some kind of
transitional package. But it seems difficult for me to choose between
`roundcube-mysql` and `roundcube-sqlite`. And it does not explain why
APT does not know how to handle this. A conflict with `roundcube-sqlite`
may work but is it sane to add "Conflicts" for this?
-- 
printk(KERN_WARNING "%s: Short circuit detected on the lobe\n",
dev->name);
2.4.0-test2 /usr/src/linux/drivers/net/tokenring/lanstreamer.c


pgp0zbOZrjyOe.pgp
Description: PGP signature

Re: Why is irqbalance package so out of date?

[Vincent Bernat]

 ❦ 16 juin 2012 00:08 CEST, Yaroslav Halchenko  :

> $> links -dump https://irqbalance.org/download.html | grep -A2 Latest
> Latest release
>
>Source Code: irqbalance-0.56.tar.bz2 (28Kb)
>
> ?

The new home is:
 http://code.google.com/p/irqbalance/

There was recently a major update which leaded to version 1.0. The
current version is 1.0.3.
-- 
Make your program read from top to bottom.
- The Elements of Programming Style (Kernighan & Plauger)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m3395wyz7i@neo.luffy.cx

Re: Is it me or virtualbox memory management crap?

[Vincent Bernat]

Thomas Goirand  writes:

> Let's put it this way: I can't run Virtualbox AND
> Firefox at the same time, or my laptop becomes unusably
> slow and non responsive.
>
> Am I the only one who experienced that? Is there something
> I didn't understand, or is it Virtualbox that has a problem?

I have the exact same problem. 1GB for VirtualBox, 1GB for Firefox, 4GB
RAM and the machine becomes slow as a dog. Never cared enough to
investigate.
-- 
panic("Fod fight!");
2.2.16 /usr/src/linux/drivers/scsi/aha1542.c


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m3k3zec0tn@neo.luffy.cx

Re: Claiming the "debian" account on GitHub ?

[Vincent Bernat]

OoO En  cette nuit striée  d'éclairs du jeudi  31 mai 2012,  vers 02:09,
Charles Plessy  disait :

> I do not know why developers prefer GitHub over Gitorious or other providers.
> But I note that even gitlabhq, advertised on this list for its free license,
> has its main download link pointing to GitHub...

GitHub has an  issue tracker while Gitorious does  not.  Moreover, it is
easier  to have contribution  on a  platform where  many people  have an
account.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

panic("Oh boy, that early out of memory?");
2.2.16 /usr/src/linux/arch/mips/mm/init.c


pgpnyXe9PH3EY.pgp
Description: PGP signature

Re: RFC: OpenRC as Init System for Debian

[Vincent Bernat]

OoO  Pendant le  journal télévisé  du samedi  12 mai  2012,  vers 20:58,
Thomas Goirand  disait :

>> The advantage of having the defaults in a file is that it makes it much
>> easier to inspect them. A .h file would typically not be installed, so
>> it wouldn't be readily available. In addition to that, it is much less
>> expressive. The nice thing about storing the default values in the same
>> format used by the configuration file is that if you find a default that
>> you'd like to change, you immediately know what to put in the
>> configuration file in order to change it.
>> 
> Then why not simply write this in /usr/share/doc//examples ?

Because they  are the  defaults of the  application, not  examples. This
conversation is going nowhere.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

 /* Thanks to Rob `CmdrTaco' Malda for not influencing this code in any
  * way.
  */
2.4.3 linux/net/core/netfilter.c


pgppM9vVpexlQ.pgp
Description: PGP signature

Re: RFC: OpenRC as Init System for Debian

[Vincent Bernat]

OoO Peu  avant le début  de l'après-midi du  vendredi 11 mai  2012, vers
13:20, Gergely Nagy  disait :

>>> In other words, it does *exactly* the same thing systemd is
>>> criticised for.
>>> 
>> 
>> Which doesn't mean that it's a good practice.

> Tell me what you would gain, if there were no files under /lib/systemd,
> and all of these were compiled into the binary, please. Because that's
> the other option, as you *do not* let users change the defaults. You let
> them override them, you let them configure the system. (And that *is*
> being done in /etc.)

> There are *very* few programs that come without any kind of default, and
> even less, that let you change the default too.

> apt does not let you change the defaults, nor does dpkg. Both allow you
> to change their settings, but without recompiling, you can't change the
> defaults. Same happens with systemd, the difference is that it's easier
> to see the defaults, as they're broken out into files that are easy to
> copy and change as needed.

Yes, that's very  true. We are just used that the  kind of "defaults" in
init to  be in /etc. But  nothing is set  in stone. I was  first against
this etc-override-lib  behaviour but your  arguments are sound and  I am
now convinced that we should keep the way systemd is doing things.

Moreover, in the case of systemd, there are other mechanisms that can be
used to customize a configuration file for the more common modifications
(handling  dependencies and  ordering) using  symbolic links.  This way,
there  is  no need  to  copy  the  file from  /lib  in  /etc to  do  the
modifications.

Still in the  case of systemd, a README put in  /etc/systemd may be used
to explain  the whole etc-override-lib  to users that are  not expecting
such behaviour. A README is not a configuration file but there is one in
/etc/init.d as well.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

#if 0
2.2.16 /usr/src/linux/fs/buffer.c


pgpOoyGiMli3V.pgp
Description: PGP signature

Re: RFC: OpenRC as Init System for Debian

[Vincent Bernat]

OoO  Pendant le  journal  télévisé du  jeudi  10 mai  2012, vers  20:29,
Jean-Christophe Dubacq  disait :

> I do not know about trivially merging changes in the etc-overrides-lib
> model, but in the current model, I am presented with the dpkg prompt
> about conffiles for some programs where I added (or changed) only one
> line (off the top of my head: only the servers list in roundcube, for
> example), and dpkg does not propose to merge the two files: I am either
> stuck with keeping my old file, taking the new, or using a shell. All
> these things are interactive and prevent unattended upgrades without
> disruption of services.

roundcube uses  ucf for its  main configuration file and  therefore, you
should have a prompt with possibility to merge.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

printk(KERN_WARNING "%s: Short circuit detected on the lobe\n",
dev->name);
2.4.0-test2 /usr/src/linux/drivers/net/tokenring/lanstreamer.c


pgputTalXJ2N9.pgp
Description: PGP signature

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Vincent Bernat]

OoO Pendant le journal télévisé du lundi 07 mai 2012, vers 20:41, Philip
Hands  disait :

>> Package: node
>> Depends: ax25-node
>> Conflicts: nodejs
>> -- /usr/sbin/node -> /usr/sbin/ax25-node
>> 
>> Package: ax25-node
>> -- /usr/sbin/ax25-node
>> 
>> Package: nodejs
>> Conflicts: node
>> -- /usr/bin/nodejs
>> -- /usr/bin/node -> /usr/bin/nodejs
>> 
>> > So this would need package replacement, which is a pain, and an
>> > exception for a policy violation -- is that enough to kill the idea?
>> 
>> I think it's an acceptable compromise under the circumstances.

> This seems a little one-sided, as it inflicts the bulk of the work on
> those that are less to blame.

I  don't  see  the  point   to  perfect  symmetry:  nodejs  contains  an
interpreter while ax25-node  contains a daemon and will  work out of the
box for most people (those that don't need custom scripts).

My point is that nodejs without /usr/bin/node is useless.

> It also prevents a HAM from deciding to dabble in Node.js while
> preserving the 'node' name for their ax25 use.

For this point only:

Package: nodejs
Depends: nodejs-interpreter
Conflicts: node
-- /usr/bin/node -> /usr/bin/nodejs

Package: nodejs-interpreter
-- /usr/bin/nodejs

But one additional package for people we are not even sure they exist...

> I don't really see the point of adding the symlink to nodejs if you're
> not putting it in a separate package -- one of the reasons I had for
> doing that split was that it might allow us to later provide popcon
> stats of the proportion's of node.js users that install the symlink
> package as part of evidence to persuade upstream that it might be worth
> entertaining a better binary name -- having them both in the same
> package discards that information.

I doubt that upstream will  rename anything after years of use. Upstream
also has a community to please.  And popcon may just be an indication on
the number  of our users that  are pissed enough to  install from source
because installing "nodejs" package did not deliver the right command.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

printk(KERN_ERR "msp3400: chip reset failed, penguin on i2c bus?\n");
2.2.16 /usr/src/linux/drivers/char/msp3400.c


pgph3qWiNffw1.pgp
Description: PGP signature

Re: RFC: OpenRC as Init System for Debian

[Vincent Bernat]

OoO  Lors de  la soirée  naissante  du lundi  07 mai  2012, vers  18:29,
Patrick Lauer  disait :

>>> No, enough politeness.  We get that you like the way Gentoo does things
>>> (lots of options, you get to keep the pieces when they break), but some
>>> of us are trying to make Debian better than that.  We don't need more
>>> half-assed options, we need a solution.
>> AOL.
>> 
> Y'all really want to play that game?
[...]

Very constructive. Thanks.

> Now, we can just continue mudslinging, and in the end it's great fun but
> nothing productive, or you guys could just stop looking down on
> everything else and accept that sometimes other people do produce decent
> things.

> If you want to make Debian better you could start by looking at where
> others have eclipsed you already and figure out how to catch up. Unless
> you are willing to accept that possibility and learn you'll be stuck in
> NIH hell and rediscover every little corner case and trivial  bug that
> others already fixed years ago.

The  initial discussion  was about  to change  our current  default init
system to  something better.   OpenRC is better.  But as is  systemd and
upstart. Nobody is in the process of rewriting a new init.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Make it right before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


pgpJm4Vz52eCJ.pgp
Description: PGP signature

Re: Node.js and it's future in debian

[Vincent Bernat]

OoO En  cette fin de nuit blanche  du vendredi 04 mai  2012, vers 06:11,
Hamish Moffatt  disait :

> Secondly if node.js is usually just used via #!, I'm not sure why it's in 
> $PATH at all - why not in /usr/lib?

Neither "#!/usr/bin/node" nor "#!/usr/bin/env  node" will work then.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

panic("Aarggh: attempting to free lock with active wait queue - shoot Andy");
2.0.38 /usr/src/linux/fs/locks.c


pgpNlE7KxrNIK.pgp
Description: PGP signature

Re: Node.js and it's future in debian

[Vincent Bernat]

OoO En  ce début  de soirée du  jeudi 03  mai 2012, vers  21:11, Patrick
Ouellette  disait :

>> Yes, they are. But we need to  find a solution that will work for almost
>> every one and this solution seems to exist.
>> 

> Can you please elaborate on the solution that seems to exist?  All I have
> seen is a demand from Node.js to give up the name ASAP.  

Yes, this one (with the patch to rename the binary in your package).

> "From my experience, many MANY Linux hams have customized scripts that
> startup some very elaborate HAM systems.  For many, these scripts
> weren't written by them and the changing of the node command could be
> very difficult for some.  The other aspect is if this change came into
> a package update that could impact production systems in VERY remote
> sites.  This could cause all kinds ugliness that can be easily
> avoided."

Being not a ham radio user, I  find a bit dubious the above quote ("many
MANY" and  "customized scripts").  Out of 100  users, how much  is "many
MANY"? If it is 1 out of 100, well, that's not that much. They can still
put a symlink  (out of /usr/local/bin for example).  The difference with
node.js is that all users would have to put this link.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Make input easy to prepare and output self-explanatory.
- The Elements of Programming Style (Kernighan & Plauger)


pgpquho8dDrdv.pgp
Description: PGP signature

Re: Node.js and it's future in debian

[Vincent Bernat]

OoO Pendant le repas du jeudi 03 mai 2012, vers 19:35, Patrick Ouellette
 disait :

>> As said many times, node is an interpreter used in shebang. Using a
>> different name would just upset its user base. Debian will be seen,
>> again, as the one harming a community, like this may happen in the
>> Ruby community because of lack of understanding on how we work.
>> Outside of Debian, nobody will understand why a package related to
>> HAM radio hinders the use of one of the trendiest package (in the
>> top 5 of most watched and forked repository in GitHub).

> So every time something is the hot new trend it has the right to usurp
> an established package's binary namespace?  I'm not asking this to be
> argumentative, I really want to know if this is your intention.

Not  the right  but  this is  a  strong criteria  to  "hijack" a  binary
name. The second  strong criteria is the absolute  necessity for node.js
executable to be named "node" since it is used as a shebang.

> I'm not saying there is a perpetual right to a name either, but when
> a package has active users, has been in the distribution a long time,
> and still does what it is designed to do there should be some significant
> consideration given to protecting that package's name space.

I agree. But, this should not eclipse other aspects.

>> We are building a distribution for users. There are far more users
>> of node.js than there is for node. Plus the fact that the proposed
>> change will be absolutely invisible to most users of the "node"
>> package.

> The ham radio community is also our users.  In fact, one of Debian's early
> focus areas was amateur radio software (see Bruce Perens' history in Debian -
> he wanted to have a distribution that included the ham radio software and
> tools).

Yes, they are. But we need to  find a solution that will work for almost
every one and this solution seems to exist.

> Are you a ham radio user of node?   You can not make assertions that the
> change will be "absolutely invisible to most users" if you have zero
> experience with the community that uses the package.  The fact is it will
> break machines  that have been in  service for possibly as  long as 13
> years.

I am not  a ham radio user at  all. I base my writings on  what has been
said by others (who may not  be ham radio users either): "node" is meant
to be called through inetd which is configured by a conffile that can be
updated. This is a pity to do the change but it seems to be invisible to
most  users and  easy for  the almost  the rest  of them  (they  will be
prompted  for  the  configuration  change  if  they  have  modified  the
configuration file of inetd in the past).
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Take care to branch the right way on equality.
- The Elements of Programming Style (Kernighan & Plauger)


pgpHmcN5szqw9.pgp
Description: PGP signature

Re: Node.js and it's future in debian

[Vincent Bernat]

Le 03.05.2012 09:19, Bernd Zeimetz a écrit :

On 05/01/2012 11:32 PM, Jonathan Nieder wrote:


Sorry, I don't understand the above sentence.  Do you mean that it 
is

impossible to come to a consensus when one maintainer of a relevant
package disagrees?  I can understand that claim, but it doesn't seem
to be the same as the sentence above.


If one of the maintainers disagrees with a solution you did not come 
to

a consensus. Yes. And the policy has an easy solution for that:

10.1 Binaries
The maintainers should report this to the debian-devel mailing list 
and
try to find a consensus about which program will have to be renamed. 
If

a consensus cannot be reached, both programs must be renamed.


And this is - looking at this way too long thread - the best solution
for this issue imho.


As said many times, node is an interpreter used in shebang. Using a 
different name would just upset its user base. Debian will be seen, 
again, as the one harming a community, like this may happen in the Ruby 
community because of lack of understanding on how we work. Outside of 
Debian, nobody will understand why a package related to HAM radio 
hinders the use of one of the trendiest package (in the top 5 of most 
watched and forked repository in GitHub).


We are building a distribution for users. There are far more users of 
node.js than there is for node. Plus the fact that the proposed change 
will be absolutely invisible to most users of the "node" package.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ed79043f195f666fcda78be9f432f...@luffy.cx

Re: Definition of _boot_

[Vincent Bernat]

OoO En  ce doux  début de matinée  du lundi  30 avril 2012,  vers 08:15,
Svante Signell  disait :

>> I'm rather sure that he wants to define booting as part of what
>> currently is done in /etc/rcS.d.  Configuring the network or mounting
>> non-essential remote file systems wouldn't be part of this definition.
>> 
>> Then he would state that these early tasks do not need events at all,
>> and conclude that later tasks can be handled in event based userspace
>> tools, but that the initial process that invokes these event based tools
>> doesn't require events and thus can stay simple.

> Nice summary, thanks. This is the whole idea behind defining boot...
> Some people get it, others don't.

Since your  boot definition  is mostly the  current initrd, you  seem to
agree that the current init system could be replaced with something more
current like upstart and systemd.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Avoid temporary variables.
- The Elements of Programming Style (Kernighan & Plauger)


pgpVodDmgtN9J.pgp
Description: PGP signature

Re: RFC: OpenRC as Init System for Debian

[Vincent Bernat]

OoO Pendant le repas du samedi 28 avril 2012, vers 19:54, Thomas Goirand
 disait :

>> We are in 2012 and if a non-essential daemon blocks the boot (no working
>> network), we have no way to get a getty to be run.
>> 
> I agree with the rest of your post, but here, you are are
> picturing a very badly written init script that doesn't have
> a working failure mode! No daemon should block the boot,
> even with our current system. If it does, please feel free to
> file a bug.

There  is no  bug. When  using  start-stop-daemon on  a forking  daemon,
start-stop-daemon waits for the  process to detach which usually happens
when the  process is ready to  accept incoming requests. If  it needs to
establish some network connections, it will not fork before.

I am  not building some  random theoritical situation here.   It happens
with exim  and cfengine  for example. And  it also happens  when mouting
network drives. Even if you have  your root ready, you won't get a getty
after long long long timeouts.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Make sure special cases are truly special.
- The Elements of Programming Style (Kernighan & Plauger)


pgpDnk6aK2pJC.pgp
Description: PGP signature

Re: RFC: OpenRC as Init System for Debian

[Vincent Bernat]

OoO En  cette fin de  matinée radieuse du  dimanche 29 avril  2012, vers
11:25, Svante Signell  disait :

>> But that's the whole point : new hardware pops up while booting. See for
>> example a server that will need  a 3G connection. The 3G connection will
>> be done  by some  classic USB key.  When the  USB key is  detected, udev
>> triggers a script  asking the USB key (which defaults  to a mass storage
>> device) to  switch to  "modem mode".   Once it becomes  a modem,  the 3G
>> connection  can be initialized.   Turning the  USB key  into a  modem is
>> taking   some  time.   The   USB  key   will  be   "disconnected",  then
>> "reconnected". SO, "found new  hardware".  ifupdown scripts were already
>> run and filed with "interface not found".

> Nice description, thanks. However, this is not necessarily part of the
> _boot_ process!! This could/should happen _after_ the computer is up and
> running, e.g. when starting X. You are not able to use your USB modem
> until then anyway, and boot times should be as short as possible, not
> having to wait for a dongle to connect to the wireless network.

There is no  X. It is a _server_. Its  only available network connection
is through this 3G  usb dongle. If it does not happen  on boot, it never
happens.

>> udev can run simple actions when a device appears but cannot run a chain
>> of dependencies  (start the  3G connection, run  some daemon  that needs
>> Internet  which in  turn  will trigger  some  client to  this daemon  to
>> run). The solution is an event-based init. We want a reliable boot.

> Then the functionality of udev should be extended, not dragging the
> init scripts into this udev<->Linux kernel interaction. I think it
> would be much better to isolate these two instead of having a third
> (potentially buggy) software included. 

The  functionality of  udev should  be extended  to  manage dependencies
between system daemons? Isn't the job of init?
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Format a program to help the reader understand it.
- The Elements of Programming Style (Kernighan & Plauger)


pgpXpWSv0JZZH.pgp
Description: PGP signature

Re: RFC: OpenRC as Init System for Debian

[Vincent Bernat]

OoO Vers la  fin de l'après-midi du vendredi 27  avril 2012, vers 16:29,
Svante Signell  disait :

> Apparently it can today ... with init scripts, which _new_ features will
> be brought in for the _boot_ process. udev takes care of the events,
> already today, right? More secure boot, faster boot (coreboot), better
> debugging, simple ways of logging the boot massages, etc? Don't talk
> about plug-and-p{r}ay, that is not interesting for _boot_: Found new
> hardware, eh?

But that's the whole point : new hardware pops up while booting. See for
example a server that will need  a 3G connection. The 3G connection will
be done  by some  classic USB key.  When the  USB key is  detected, udev
triggers a script  asking the USB key (which defaults  to a mass storage
device) to  switch to  "modem mode".   Once it becomes  a modem,  the 3G
connection  can be initialized.   Turning the  USB key  into a  modem is
taking   some  time.   The   USB  key   will  be   "disconnected",  then
"reconnected". SO, "found new  hardware".  ifupdown scripts were already
run and filed with "interface not found".

udev can run simple actions when a device appears but cannot run a chain
of dependencies  (start the  3G connection, run  some daemon  that needs
Internet  which in  turn  will trigger  some  client to  this daemon  to
run). The solution is an event-based init. We want a reliable boot.

We are in 2012 and if a non-essential daemon blocks the boot (no working
network), we have no way to get a getty to be run.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Don't stop at one bug.
- The Elements of Programming Style (Kernighan & Plauger)


pgpzoo4HbRtjy.pgp
Description: PGP signature

Re: On init in Debian

[Vincent Bernat]

OoO En ce  milieu de nuit étoilée du vendredi 30  mars 2012, vers 03:54,
Carlos Alberto Lopez Perez  disait :

>> FWIW, I have a proposal for a GSoC task this year to write a
>> systemd-to-initscript converter,
>> http://wiki.debian.org/SummerOfCode2012/Projects#SysV-init_file_creator_from_systemd_service_files
>> 
>> The systemd service files are covered by the «interface guarantee»,
>> meaning they won't change incompatibly in a future release of systemd,
>> so I think having that as the base format would be fairly reasonable,
>> though probably just a subset so it's portable to other kernels and init
>> systems.

> And instead of this... why not simply improving metainit to support also
> systemd files?

> http://wiki.debian.org/MetaInit

> We already have this metainit thing that auto-generates both sysvinit
> and upstart files based on an easy common format.

> http://darcs.nomeata.de/metainit/examples/

Documentation is  rather absent. Currently (from Parse.pm),  it seems to
only  support   and  use  "Short-Description",   "Description",  "Exec",
"Prestart-Hook",  "Poststop-hook"  and  "No-Auto"  directive.   It  also
supports "Required-Start".  It seems  that simple things, like "reload",
cannot be achieved.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

panic("bad_user_access_length executed (not cool, dude)");
2.0.38 /usr/src/linux/kernel/panic.c


pgpTkil0976f7.pgp
Description: PGP signature

Re: On init in Debian

[Vincent Bernat]

OoO En ce  début d'après-midi ensoleillé du mercredi  21 mars 2012, vers
15:56, Svante Signell  disait :

> How on earth would anybody be able to make a decision if there are no
> comparisons between the alternatives available? Throw a dice, rely on
> gut feelings, or what? Since everybody is so damned biased in opinions,
> I don't see any alternative to making a thorough investigation. This
> could be a useful GSoC task. If case the "experts" approve that somebody
> not senior or expert enough enough do the work. This would be much more
> intersting than writing a systemd-to-initscript converter.

I have some difficulties to  understand how a comparison which will then
be debated ad  vitam eternam could be more useful  than actual code that
will  handle  the  only  viable  argument against  switching  to  a  new
init. This systemd-to-initscript converter is a great idea.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

 /* Binary compatibility is good American knowhow fuckin' up. */
2.2.16 /usr/src/linux/arch/sparc/kernel/sunos_ioctl.c


pgpqOghYN6IaK.pgp
Description: PGP signature

Re: On init in Debian

[Vincent Bernat]

Le 21.03.2012 10:01, Bernhard R. Link a écrit :

* Marco d'Itri  [120321 09:34]:

On Mar 21, Svante Signell  wrote:
> And how do you expect non-experts be able to solve problems when 
they

> pop up. Buying consultant services from the experts?
Non-experts are not able to solve any problem, so this is not an 
issue.


I'm really fed up with this elitism. There are not only experts and
people knowing nothing. The is a wide range between.


For me, Marco was just sarcastic.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/74153834109d47419998ace48bd97...@luffy.cx

Re: On init in Debian

[Vincent Bernat]

OoO  Lors de  la soirée  naissante du  lundi 19  mars 2012,  vers 18:48,
Thomas Goirand  disait :

>>> I just had a look, and no, that's not what metainit does.

>>> What it does is *generating* an init.d script, using the
>>> metainit syntax as input. IMO, just a normal shell script
>>> tiny library to simplify our init.d scripts would be enough.
>>> 
>> So it does more than enough - sounds to me like it meets your
>> requirements (in fact exceeds them) and has the added advantage
>> that it *already exists* whereas the hypothetical shell script
>> library does not.
>> 

> Not really. It invents a new syntax which I don't want to use.
> I want things to be more simple, not more complicated.

Writing configuration files  with the shell is not  going to be anywhere
simple. In  two years, it will be  the same mess as  now: everybody will
have extended  the "configuration" with  its own functions  and somebody
will come up and say those functions should be put into some library. We
already have  /lib/lsb/init-functions and start-stop-daemon.   Almost no
daemon stick to /etc/init.d/skeleton.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Write clearly - don't be too clever.
- The Elements of Programming Style (Kernighan & Plauger)


pgphR5xd6mXww.pgp
Description: PGP signature

Re: upstart: please update to latest upstream version

[Vincent Bernat]

OoO Pendant  le repas du dimanche  11 mars 2012, vers  19:24, Goswin von
Brederlow  disait :

>> Yes,  but systemd  relies on  cgroups which  are not  portable.   If all
>> daemons were able to not fork,  it would be easier to convert a .service
>> file to a classic init.d  script and therefore use systemd (for example)
>> as default with Linux and sysvinit with autogenerated files on kFreeBSD.

> That would actually make things more difficult since then you have to
> add some delay into the sysvinit files to wait for the daemon to become
> ready before the init.d script returns.

Is start-stop-daemon actually  relying on the PID file  being created to
know if the daemon  is ready? Or maybe you mean a  daemon fork only when
it is ready?

> The only thing that would benefit would be to run systemd on kFreeBSD
> without the cgroup mechanism. No forking so no need to trace fork()s.

It seems that systemd relies on many more Linux specifics.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

/* Fuck me gently with a chainsaw... */
2.0.38 /usr/src/linux/arch/sparc/kernel/ptrace.c


pgpugEaapTN2r.pgp
Description: PGP signature

Re: upstart: please update to latest upstream version

[Vincent Bernat]

OoO Vers  la fin de l'après-midi  du dimanche 11 mars  2012, vers 16:14,
Fernando Lemos  disait :

>> Maybe we could  have an intermediate goal to patch any  daemon to add an
>> option  to not  fork on  start.  If  any daemon  can be  started without
>> forking, it seems  easy to start/stop them without  cgroups.  This would
>> allow to generate a sysvinit  script from systemd service description. I
>> don't  know  any daemon  that  does  not have  a  flag  to  not fork  on
>> start. The number of daemons to patch may be low.
>> 
>> This will not be  as clean as using cgroups, but it  won't be worst than
>> the actual situation.

> I don't quite understand the problem you're trying to solve. Both
> upstart and systemd already handle cases where the daemon doesn't have
> the option of not forking.

Yes,  but systemd  relies on  cgroups which  are not  portable.   If all
daemons were able to not fork,  it would be easier to convert a .service
file to a classic init.d  script and therefore use systemd (for example)
as default with Linux and sysvinit with autogenerated files on kFreeBSD.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

panic ("Splunge!");
2.2.16 /usr/src/linux/drivers/scsi/psi240i.c


pgpIErz9fbgFD.pgp
Description: PGP signature

Re: debian-multimedia.org considered harmful, Was: Unofficial repositories on 'debian' domains

[Vincent Bernat]

OoO Pendant  le temps de midi du  samedi 10 mars 2012,  vers 12:30, Eric
Valette  disait :

> Yes acknowledged that vlc and mplayer are now up-to-date.

vlc 0.5.3 was released on April, 8 2003. Debian package on April, 14 2003.

vlc 0.8.6a was released on January, 4 2007.  Debian package on January, 11 2007.

vlc 1.0.0 was released on July, 7 2009. Debian package on July, 9 2009.

vlc 1.1.0 was released on June, 22 2010. Debian package on June, 24 2010.

vlc 1.1.11 was released on July, 16 2011. Debian package on July, 18 2011.

vlc 2.0.0 was released on February, 18 2012. Debian package on the same day.

When exactly was vlc not up-to-date on Debian?
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Don't use conditional branches as a substitute for a logical expression.
- The Elements of Programming Style (Kernighan & Plauger)


pgpUA2IztkxOH.pgp
Description: PGP signature

Re: upstart: please update to latest upstream version

[Vincent Bernat]

OoO  En  cette nuit  nuageuse  du mercredi  07  mars  2012, vers  00:21,
Fernando Lemos  disait :

>> To give one particular example: systemd uses Linux-specific features to
>> accurately track all the processes started by a service, which allows
>> accurate monitoring and shutdown of processes which could otherwise
>> disassociate themselves from their parent processes via the usual
>> daemonizing trick.  POSIX doesn't provide features that allow this in
>> general, but Linux does.  (Quite possibly other OSes provide those
>> features too, but not in a standardized way.)

> By the way, upstart uses ptrace for this:

> http://netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/

> It's an interesting trick, and probably more portable too.

Maybe we could  have an intermediate goal to patch any  daemon to add an
option  to not  fork on  start.  If  any daemon  can be  started without
forking, it seems  easy to start/stop them without  cgroups.  This would
allow to generate a sysvinit  script from systemd service description. I
don't  know  any daemon  that  does  not have  a  flag  to  not fork  on
start. The number of daemons to patch may be low.

This will not be  as clean as using cgroups, but it  won't be worst than
the actual situation.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

printk("Entering UltraSMPenguin Mode...\n");
2.2.16 /usr/src/linux/arch/sparc64/kernel/smp.c


pgptI9nUwDcVC.pgp
Description: PGP signature

Re: Rebuild of the Debian archive with clang

[Vincent Bernat]

OoO Lors de la soirée naissante du mercredi 29 février 2012, vers 17:19,
Sylvestre Ledru  disait :

> If you are looking for the raw list, I published the files:
> 2.9:
> http://clang.debian.net/scanlog-2.9-2011-09-11
> 3.0:
> http://clang.debian.net/scanlog-3.0-2012-01-12

Is  it possible to  find why  a package  has not  been considered  to be
built?
-- 
Vincent Bernat ☯ http://vincent.bernat.im

printk("What? oldfid != cii->c_fid. Call 911.\n");
2.4.3 linux/fs/coda/cnode.c


pgpTKjM2LqUhN.pgp
Description: PGP signature

Re: Default display manager should not be gdm3

[Vincent Bernat]

OoO En cette  fin de nuit blanche du jeudi 23  février 2012, vers 06:47,
Miles Bader  disait :

>> We should not still be using this software.

> Er, given that gdm3 works fine for many people, that seems excessive.

> Moreover, the choice of default display manager seems unrelated to its
> ability to support obscure tweaks -- indeed, it's very common for
> default packages to be those that are nicer for "average" users, not
> those that are the most customizable.  You have the choice of easily
> installing other display managers that meet your criteria, so what's
> the big deal?

Moreover, other display  manager may not work correctly  because gdm3 is
the only  display manager supporting  all modern stuff. For  example, we
could switch to  something like "slim" but slim does  not play nice with
ConsoleKit which means that a  user logged with slim won't be considered
as a  local user and therefore  won't have rights  for power management,
network configuration and things like that. See:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601003

The main  problem is things are now  more complex than 10  years ago and
alternatives are  unable to  cope with all  the new things  necessary to
make a  desktop work correctly.  We have  to rely on parts  of the GNOME
desktop. Unfortunately, those parts are dependant on other parts and are
not as hackable and documented as we are used to.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Make input easy to proofread.
- The Elements of Programming Style (Kernighan & Plauger)


pgpx3YUqDEo0k.pgp
Description: PGP signature

Re: MIA check for Robert Jordens and Mark A. Hershberger (anyone in contact with them?)

[Vincent Bernat]

OoO En  cette fin  de matinée  radieuse du jeudi  09 février  2012, vers
11:43, Cyril Brulebois  disait :

>> I have done the latest uploads for php-mdb2 packages. I suppose you
>> want me to drop php-mdb2-driver-sqlite package?

> From #debian-release's backlog, it seems likely.

OK, I have requested removal for both unstable and testing.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

printk("autofs: Out of inode numbers -- what the heck did you do??\n"); 
2.0.38 /usr/src/linux/fs/autofs/root.c


pgpPQ9FwbzaCd.pgp
Description: PGP signature

Re: MIA check for Robert Jordens and Mark A. Hershberger (anyone in contact with them?)

[Vincent Bernat]

Le 09.02.2012 10:15, Ondřej Surý a écrit :

Mark A. Hershberger (all his packages are co-maintained; Vincent, are
you in contact with him?):


I have done the latest uploads for php-mdb2 packages. I suppose you 
want me to drop php-mdb2-driver-sqlite package?



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/f29a710105652e84ea7b5d3f34f9f...@luffy.cx

Re: Linux 3.2 in wheezy

[Vincent Bernat]

OoO  En ce début  d'après-midi nuageux  du mardi  07 février  2012, vers
14:00, Thomas Goirand  disait :

>> With vservers and  OpenVZ you can run each service  in its own container
>> with a small  memory footprint. With Xen/KVM, you  will need to allocate
>> at least 128 MB for each container.
>> 
> NO ! The limit isn't that great.

> With Etch, 48 MB was enough. With Lenny, 64 MB was enough.
> With Squeeze, 96 MB is enough (the minimum is between 64 and
> 96 MB, I didn't care investigating). And with 96 MB, you can already
> run a DNS server, OpenVPN, or a (very basic) mail server. The issue
> though, might be with things like locales generation or other RAM
> intensive stuff in Debian, which may need a bit more RAM to run
> smoothly. But in such case, you'll have the issue with both KVM/XEN
> and containers, so it doesn't really apply as a point in the discussion
> here.

It  applies.  The major  point is  that with  containers, RAM  is shared
accross containers (the same kernel is used for all containers).  If one
container  needs for a  few seconds  200 MB,  it can  just use  them. No
memory needs to be allocated for the exclusive of one container.

> That doesn't discard your argument of the RAM usage all together,
> it's really truth that a container will use less RAM. But please, be
> reasonable when trying to make your point, and keep it with
> facts that you have checked by yourself.

Please, don't patronize people.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

panic("sun_82072_fd_inb: How did I get here?");
2.2.16 /usr/src/linux/include/asm-sparc/floppy.h


pgp1NXhyolFT7.pgp
Description: PGP signature

Re: mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts

[Vincent Bernat]

OoO Peu  avant le début de  l'après-midi du jeudi 02  février 2012, vers
13:11, Andreas Beckmann  disait :

> I'm planning to file bugs against all packages that currently fail the
> piuparts test with a 'deluser/delgroup: command not found' error in
> wheezy and sid.
> Currently 17 binary packages from 15 source packages are affected.

deluser  allows  the  use  of  "--system"  to avoid  to  remove  a  real
user. userdel does  not have this kind of  switch. Using userdel instead
of deluser is dangerous. I would prefer to leave the user untouched than
removing the wrong user instead. Of course, the postrm script should not
stop because of this (|| true).
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Use debugging compilers.
- The Elements of Programming Style (Kernighan & Plauger)


pgplI1TdM1oHI.pgp
Description: PGP signature

Re: Linux 3.2 in wheezy

[Vincent Bernat]

OoO En cette nuit striée d'éclairs du jeudi 02 février 2012, vers 02:21,
Russell Coker  disait :

>> However, a low profile container/virtualization solution is needed, and I
>> know there is quite some demand for it: both some larger scale
>> organisations and several smaller/non-profit organisations I am acquainted
>> with use either OpenVZ or linux-vserver and some of them will be in
>> trouble if there is no equivalent and not at least a rough migration path.

> Are there many users who need root containment but who won't have the 
> resources to run Xen or KVM when the support for Squeeze ends?

With vservers and  OpenVZ you can run each service  in its own container
with a small  memory footprint. With Xen/KVM, you  will need to allocate
at least 128 MB for each container.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Avoid temporary variables.
- The Elements of Programming Style (Kernighan & Plauger)


pgpX38v2OXLlH.pgp
Description: PGP signature

Re: Increasing minimum 'i386' processor

[Vincent Bernat]

OoO Lors de  la soirée naissante du mardi 22  novembre 2011, vers 18:28,
Bastian Blank  disait :

>> > The 486-class processors that would no longer be supported are:
>> > 1. All x86 processors with names including '486'
>> I'm still running the machine below, and it would be irritating to
>> have to replace it.

>> vendor_id: CentaurHauls
>> model name   : VIA Samuel 2

> I don't see any 486 in this name.

This processor  does not run with a  686 kernel and needs  a 486 kernel.
If   I  remember   correctly,   it   is  because   the   lack  of   CMOV
instruction. Therefore, no problem with 586.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Indent to show the logical structure of a program.
- The Elements of Programming Style (Kernighan & Plauger)


pgpVbq7hxHmAb.pgp
Description: PGP signature

Re: Is anyone maintaining (the ham radio tool) node?

[Vincent Bernat]

OoO En  ce début  d'après-midi nuageux du  lundi 07 novembre  2011, vers
14:42, Ian Jackson  disait :

>   2a. Likewise the maintainer of "nodejs" should prepare a version
>   of the package where the "node" binary is called "nodejs".

As Patrick  said earlier in the  thread that not enough  members seem to
care about this, I add my voice here: node from node.js is often used in
shebang  while node from  AX25 is  not.  Having  a "nodejs"  binary will
cause many difficulties to our users.

What  if  the  problem  was  raised  ten  years  ago  about  Python  for
example. What  an horrible mess it  would be today if  the python binary
was called "python-py" or "python-script".

See how communities may react to  this. Ruby community does not like our
packaging just  because we enforce stability over  freshness. What would
think  node.js community  if  we are  using  /usr/bin/nodejs instead  of
/usr/bin/node. Debian would  be listed as a black sheep  in every FAQ or
tutorial and  users will  be invited to  just install some  non official
package or use the source.

Patrick  seems OK  for both  binaries  to be  renamed. I  don't see  the
rationale of not accepting that node.js keeps the "node" name.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Modularise.  Use subroutines.
- The Elements of Programming Style (Kernighan & Plauger)


pgpC3OuFrB1Xe.pgp
Description: PGP signature

Re: Minified files and source code requirement

[Vincent Bernat]

OoO  En cette nuit  nuageuse du  vendredi 28  octobre 2011,  vers 00:34,
Philipp Kern  disait :

>> In other words, given the haziness in this area and the wildly divergent
>> practices of people when creating non-code works, I think we should look
>> at whether the provided "source" provides reasonable opportunity to meet
>> the core definition of free software, namely the ability to study and
>> adopt the work for one's own purposes and republish one's modifications,
>> and not get too hung up on whether the exact tools and steps the original
>> author took are included.

> What about a game that provides a set of resource source files but no scripts
> to create the actual pngs and jpegs?

We  should  not  push the  analogy  too  far.   Game resources  are  not
code. Here,  minified Javascript  code is code.  Your question  is still
valid but the answer would not help the debate here, I think.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Document your data layouts.
- The Elements of Programming Style (Kernighan & Plauger)


pgplpu70eZXbL.pgp
Description: PGP signature

Re: Move all to /usr

[Vincent Bernat]

On Thu, 13 Oct 2011 16:22:16 +0200, m...@linux.it wrote:

Some systems have quite a small /boot partition, I've had some 
problems with a
/boot partitions nowadays are mostly useless, unless e.g. you are 
doing

something stupid like a RAID 5 root.
If you have a 30 MB /boot partition then just stop mounting it and 
keep

your kernels in / .


Separate /boot are needed when encrypting root.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d2e6f94c674783d15948527b13b...@luffy.cx

Re: A few observations about systemd

[Vincent Bernat]

OoO  Pendant  le temps  de  midi  du lundi  01  août  2011, vers  12:47,
m...@linux.it (Marco d'Itri) disait :

>> If a package with the default config listens on external ifaces or does
>> other potentially insecure things (or maybe changes the system state in
>> some other undesirable way), the administrator may want to change its
>> config before the first start.
> A package should not do insecure or undesirable things by default.
> If administrators are concerned by the the race in the few seconds
> between "apt-get install" and "/etc/init.d/$package stop" then they can
> pre-install a suitable configuration file.

Or have a firewall configured.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

printk("Entering UltraSMPenguin Mode...\n");
2.2.16 /usr/src/linux/arch/sparc64/kernel/smp.c


pgp7o3ys15Pwr.pgp
Description: PGP signature

Re: Bug#636072: ITP: stud -- scalable TLS unwrapping daemon

[Vincent Bernat]

OoO En cette soirée bien amorcée  du samedi 30 juillet 2011, vers 22:42,
Peter Samuelson  disait :

>> stud is a network proxy that terminates TLS/SSL connections and
>> forwards the unencrypted traffic to some backend. It is designed to
>> handle tens of thousands of connections efficiently on multicore
>> machines.

> You should include some text to differentiate this from stunnel4.  From
> the ITP, I cannot figure out why I would want this instead, or indeed,
> why Debian should ship both.

The  main  difference  is  that  stud  "handles  tens  of  thousands  of
connections efficiently on multicore  machines".  stunnel is not able to
get similar  performance due  to its threaded  model. Moreover,  stud is
really small  (ten times  smaller than stunnel)  which may  be important
From a security point of view.

I hope to backup those claims with some figures soon.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Don't compare floating point numbers just for equality.
- The Elements of Programming Style (Kernighan & Plauger)


pgpcGSgqh3Ljk.pgp
Description: PGP signature

Bug#636072: ITP: stud -- scalable TLS unwrapping daemon

[Vincent Bernat]

Package: wnpp
Severity: wishlist
Owner: Vincent Bernat 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: stud
  Version : 0.1
  Upstream Author : Bump server team <http://bu.mp>
* URL : https://github.com/bumptech/stud
* License : Simplified BSD License
  Programming Lang: C
  Description : scalable TLS unwrapping daemon

stud is a network proxy that terminates TLS/SSL connections and
forwards the unencrypted traffic to some backend. It is designed to
handle tens of thousands of connections efficiently on multicore
machines.

stud has very few features. It is designed to be paired with an
intelligent backend like haproxy or nginx. It maintains a strict 1:1
connection pattern with this backend handler so that the backend can
dictate throttling behavior, maxmium connection behavior, availability
of service, etc.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk40VncACgkQKFvXofIqeU5+TwCgtGlqt9T6wYHpUGdZw7LqMMMJ
HiMAn1UNg0eVWfaZJgJrtuE7mp+rqGSH
=ZyNI
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110730190742.4302.53884.report...@neo.luffy.cx

Re: Providing official virtualisation images of Debian

[Vincent Bernat]

OoO En cette  matinée ensoleillée du mardi 26  juillet 2011, vers 09:28,
Lucas Nussbaum  disait :

>> What virtualisation solutions should be supported?
>> - Virtual Box seems like a natural candidate since it's free and
>> included since Squeeze.
>> - Vmware has a significant installed base and is relevant, although
>> proprietary
>> - Microsoft Virtual PC is likely also needed
>> - Qemu
>> - Citrix XenServer?

> - images for cloud infrastructures (AMI -- Amazon Machine Image)

I  was  about to  ask  the  same. Those  images  seem  very popular  for
Ubuntu. Maybe we are missing something by not providing them. I remember
that those  images can be used with  Eucalyptus as well (no  need to use
Amazon).
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plauger)


pgpnnWOUvUaKf.pgp
Description: PGP signature

Re: Fading away an old ABI transition

[Vincent Bernat]

OoO En cette  soirée bien amorcée du dimanche 19  juin 2011, vers 22:38,
Peter Samuelson  disait :

>> Or is it better to keep this prefix until a new major version
>> (unlikely to happen)?

> Maybe ask the maintainers of the 'zlib1g' package for advice.  That 'g'
> suffix is from an ABI transition in September 1997.

> (:

> In all seriousness, Julien is right - this is not worth a package
> transition.  Just wait for the next ABI bump.  And if there never is
> one, oh well.

Good to know. Since there is almost no "ldbl" package left, I was afraid
I  have missed  something about  those  ABI transitions.   I will  watch
zlib1g and  I understand that  as soon as  the "g" suffix is  dropped, I
have ten years to drop mine. ;-)
-- 
Vincent Bernat ☯ http://www.luffy.cx

# Okay, what on Earth is this one supposed to be used for?
2.4.0 linux/drivers/char/cp437.uni


pgpQjd32Ra8rD.pgp
Description: PGP signature

Fading away an old ABI transition

[Vincent Bernat]

Hi!

I maintain libsmi2  which ships libsmi2ldbl binary package  which is the
result of a transition started more  than four years ago. I am wondering
if I should do something to get  rid of the "ldbl" prefix? Should I make
a  transition package  (which means  keeping  it until  wheezy is  out)?
Should I organize  a mini transition of my own (there  is only a handful
reverse dependencies and  all of them could just  get a binary rebuild)?
Or is it better to keep  this prefix until a new major version (unlikely
to happen)?

Thanks.
-- 
Vincent Bernat ☯ http://www.luffy.cx

prom_printf("Detected PenguinPages, getting out of here.\n");
2.0.38 /usr/src/linux/arch/sparc/mm/srmmu.c


pgpNS4b9M0zNY.pgp
Description: PGP signature

Re: [ANNOUNCE] dh_splitpackage 0.2.2

[Vincent Bernat]

On Sat, 04 Jun 2011 22:56:24 +0200, Zygmunt Krynicki wrote:


[libfoo-dev]
include=**/*.h
include=**/*.la
include=**/*.a
# Just for demonstration, never pick any shared objects
exclude=**/*.so


I know this is just an exemple to show exclude but .so files have to be 
put in -dev packages. Exclude should be **/*.so.*. Moreover, there is an 
ongoing effort to drop .la files. Here is an updated example (with a 
real use of exclude)


[libfoo-dev]
include=**/*.h
include=**/*.a
include=**/*.so
exclude=**/libnotfoo.*



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/965a6126bed8bf55197a3bbb79387...@luffy.cx

Re: Ok to use upstream doumentation as-is (i.e. not regenerate)?

[Vincent Bernat]

On Sat, 4 Jun 2011 21:54:11 +0200, Jonas Smedegaard wrote:


What I do is use upstream provided tarballs, then put aside
autotools-generated files, then autogenerate myself, and in the clean
rule put back the upstream-provided files (because I want not only
minimal required build routines idempotent but also building with
git-buildpackage).


In the clean rules, you can just delete those autogenerated files.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/7f15d9df0f108f5f472471dcba532...@luffy.cx

Re: Linux 3.0

[Vincent Bernat]

OoO Lors  de la soirée naissante du  lundi 30 mai 2011,  vers 18:52, Ben
Hutchings  disait :

> As you may have seen, the next version of the Linux kernel will be 3.0
> (or 3.0.0).  There is no significant API change; this just shortens the
> version string and marks the start of the third decade of Linux.

Are we  sure that the  change won't be  reverted later in the  RC cycle?
This change  will break  a lot  of software that  rely on  detecting the
kernel version to make some decisions. Maybe the 3.0.0 could be released
as 2.6.40 to avoid unnecessary breakages?

I do not mean not working  on supporting 3.x numbering correctly as soon
as possible.
-- 
Vincent Bernat ☯ http://www.luffy.cx

Keep it right when you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


pgpHP8Ia5HyLz.pgp
Description: PGP signature

Re: bug reporting workflow is outdated

[Vincent Bernat]

OoO En ce milieu de nuit étoilée  du lundi 23 mai 2011, vers 03:42, Paul
Wise  disait :

>> The only advantage of this would be for systems that firewall outgoing
>> mail conections but allow http or have a http proxy but no smarthost.

> There are a *lot* of ISPs that do this. My ISP does this so I have to
> send mail via SSH tunnel or webmail.

Does it allow  port 587 (submission)? This becomes  common those days to
accept SMTP listening on this port.
-- 
Vincent Bernat ☯ http://www.luffy.cx

 /*
  * Hash table gook..
  */
2.4.0-test2 /usr/src/linux/fs/buffer.c


pgpF6cRgkC47k.pgp
Description: PGP signature

Re: httpd-cgi is it really CGI or maybe *CGI instead

[Vincent Bernat]

OoO Pendant  le repas du  mercredi 18 mai  2011, vers 19:55,  Jérémy Lal
 disait :

> I have the feeling it is a good idea to enforce web servers to declare their
> abilities like that. Today many webapps can run through fcgi, whether they are
> in php, ruby, c... but they can't state that fact in their control fields.
> Instead, i've seen some of them depend on apache2, whereas they can run with
> any other httpd-fcgi (example: roundcube-core)

roudncube-core depends on apache2 | lighttpd | httpd, php5.

Therefore,  you  can  install  it   with  nginx  and  php5-cgi  (or  now
php5-fpm).  The presence  of "apache2"  is  merely a  default here.  The
presence of "lighttpd"  may be removed since this  is neither a default,
neither a dependency that is not stated in httpd.
-- 
Vincent Bernat
http://www.luffy.cx


pgpcdhOEhvluF.pgp
Description: PGP signature

Re: More Vcs-Fields in debian/control?

[Vincent Bernat]

OoO En  cette aube naissante  du jeudi 07  avril 2011, vers  07:46, Joey
Hess  disait :

>> We (lindi, liw and me) had just a short discussion in #-devel, that it
>> would be nice to have some sort of Vcs-Upstream-* in debian/control, to
>> be able to get to upstreams vcs history if it is not imported in
>> debian's vcs (which is often the case when using svn-bp or git-bf with
>> import-orig). [background: lindi is doing some git-copyright checks and
>> it fails heavily if there is no upstream history as the debian
>> maintainer is asumed to be the copyright holder for everything]

> I would instead suggest we deprecate packages not including upstream
> source in their VCS. The weight of progress is against that practice;
> tools have improved so there is little excuse to do it, it increasingly
> violates expections and makes things harder.

> Some examples:

> * git cherry-pick cannot be used
> * pristine-tar cannot be used
> * apt-get source now suggests running debcheckout when VCS fields are
>   present. But for such a package, debcheckout won't result in the same
>   source tree as does apt-get source.

> Adding baroque complications to the VCS fields doesn't deal with these
> problems consistently, and while it might help this style of VCS use
> linger a while longer, it will be an unnecessary complication going
> forward.

Large SVN  repositories containing only debian/  directories are already
quite slow (at  least on alioth). Adding upstream  sources (and history)
would not improve this part.

Moreover, do we have space to cope with this?
-- 
I AM NOT MY LONG-LOST TWIN
I AM NOT MY LONG-LOST TWIN
I AM NOT MY LONG-LOST TWIN
-+- Bart Simpson on chalkboard in episode 4F03


pgp3JGLhwZXHe.pgp
Description: PGP signature

Re: Ruby changes for Wheezy

[Vincent Bernat]

OoO En  cette fin  de matinée  radieuse du dimanche  06 mars  2011, vers
11:40, Lucas Nussbaum  disait :

> Note that, for applications written in Ruby and packaged in Debian, we
> will make sure that they work no matter what /usr/bin/ruby points to (if
> necessary, by forcing the shebang to ruby1.8, and installing the correct
> dependencies). What might break is software manually installed by users.
> I don't see how that situation is different from the Java one.

This is  also what is done  with Python.  We get  very little complaints
with this. However, maybe the Python roadmap is easier to understand and
less applications get broken when upgrading to a new major version.

Breaking applications that are  installed outside of the package manager
is bad  but it  is far less  worse than breaking  applications installed
with the package manager.

>> > Anyway. We are early in the wheezy release cycle. If switching ruby
>> > implementations using alternatives turns out to be a bad idea, we can
>> > switch back to the former approach at some point. And we will arguments
>> > to reply to users who currently want it. 
>> 
>> Do you really need to break hundreds of user systems just to make a
>> handful of whiners happy?

> I am under the impression that it's not "a handful of whiners", but that
> the consensus in the Ruby community is that we should switch to
> alternatives.

Do they really understand that alternatives may break a lot of things on
user systems? By reading your blog, I understand that the Ruby community
(or a  part of it) does not  really understand that Debian  does want to
provide  a robust  way  to  manage applications.   If  the user  install
software X written in Ruby  with apt, then uses "update-alternatives" to
switch Ruby  version and then software X  is broken, it seems  we are to
blame  because  using  update-alternatives  should not  break  installed
softwares.
-- 
Program defensively.
- The Elements of Programming Style (Kernighan & Plauger)


pgp0oKAcTMtOH.pgp
Description: PGP signature

Re: What bug reports are for

[Vincent Bernat]

OoO En  ce début  d'après-midi ensoleillé du  dimanche 27  février 2011,
vers 15:33, Josselin Mouette  disait :

> You seem to forget the very reason bug reports are here. Their point is
> not to offer a service to our users - if you want that, you’ll need paid
> support. Bug reports are here to help improving the distribution.

> Now, maintainers receive a lot of bug reports, and have limited time to
> spare on Debian. Given the choice between: 
>  1. packaging a new upstream release that fixes a lot of bugs; 
>  2. fixing a nicely reported bug with a reproducible and
> well-identified cause; 
>  3. investigating a dubious bug report that seems to be triggered by
> a broken user configuration;
> only masochistic maintainers will spend time on #3 when they can help a
> lot more users on #1 and #2. It’s not that it’s easier (I remember
> spending entire days on single bugs), but it’s more useful.

> Now, if you spend enough time investigating to be able to tell, at the
> very least, “this is a bug in library foo which is reproducible by doing
> bar”, your report might go from #3 to #2 and get fixed.

The  last  message  of Dmitry  points  to  the  culprit (use  of  Tahoma
font). This seems a valid bug. I have added this instruction to my gtkrc
but did not succeed to reproduce the  bug (I get the black screen but it
is  not  expanding).  Maybe  there  is  something  else  to  add  (using
KDE?). We don't know if Sandro succeeded to reproduce this bug after the
Dmitry provided additional info because he just closed the bug.

In  my  opinion,  Sandro  should   have  left  the  bug  open  with  its
"unreproducible" tag.  The bug  is not solved  and should not  have been
closed. It would  have been nice to reevaluate  the "unreproducible" tag
with  the help of  the additional  input from  the reporter.  Some users
don't bother  to help the  maintainer and we  have here a user  which is
willing to  debug the problem. This seems  a bad idea to  just close its
bug without interacting with him.
-- 
BOFH excuse #306:
CPU-angle has to be adjusted because of vibrations coming from the nearby road


pgp0n4mzESAaA.pgp
Description: PGP signature

Re: Bug#611880: ITP: webkit2pdf -- export web pages to PDF files

[Vincent Bernat]

OoO En  cette fin  de matinée  radieuse du jeudi  03 février  2011, vers
11:15, Cyril Brulebois  disait :

>   $ apt-cache show wkhtmltopdf | sed -n '/^Description/,$p'

OoO En  cette fin  de matinée  radieuse du jeudi  03 février  2011, vers
11:19, Luca Bruno  disait :

> Have you seen cutycapt[0] already? I see no advantages in having
> webkit2pdf in Debian too, so far. Care to compare and expand your
> rationale?

> [0] http://packages.debian.org/squeeze/cutycapt

It seems neither cutycapt nor wkhtmltopdf (as compiled in Debian) allows
to convert hyperlinks. Does webkit2pdf allows this?
-- 
BOFH excuse #113:
Root nameservers are out of sync


pgpgPuZ6njyoQ.pgp
Description: PGP signature

Bug#605117: ITP: flowd -- fast, secure and flexible NetFlow collector

[Vincent Bernat]

Package: wnpp
Severity: wishlist
Owner: Vincent Bernat 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: flowd
  Version : 0.9.1
  Upstream Author : Damien Miller 
* URL : http://code.google.com/p/flowd/
* License : BSD
  Programming Lang: C
  Description : fast, secure and flexible NetFlow collector

flowd is a small, fast and secure NetFlow collector. It offers the
following features:
  * NetFlow protocol 1, 5, 7 and 9 (including IPv6 flows)
  * IPv4 and IPv6 transport of flows
  * filtering and tagging of flows
  * compact binary format for flow storage
  * Perl and Python interface for parsing on-disk record format

flowd works with any standard NetFlow exporter, including hardware
devices (e.g. routers) or software flow tracking agents.

The flowd sensor follows the Unix philosophy of "doing one thing well"
- - it doesn't try to do anything beyond accepting NetFlow packets and
storing them in a standard format on disk. In particular, it does not
include support for storing flows in multiple formats or performing
data analysis. That sort of thing is left to external tools. The
source distribution includes several example tools including a basic
reporting script and one to store flows in a SQL database.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkzxHscACgkQKFvXofIqeU4QyACfdmpmSqV9VvqRIAYdp7hJdXQi
NHcAnRg6xqzGemASaxb9dlq8UALbhyCn
=F19N
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101127150755.23692.68578.report...@neo.luffy.cx

Re: debian can be better

[Vincent Bernat]

OoO La nuit ayant déjà recouvert  d'encre ce jour du mercredi 27 octobre
2010, vers 23:48, Patrick Matthäi  disait :

> Most desktop users also want to have some 2D/3D performance, or special
> features like tv out, xvideo acceleration etc etc.
> nouveau is a good replacement for nv, but still far away of being useful
> for powerful desktop users.

nouveau  supports  2D  acceleration  including  compositing  and  Xvideo
acceleration.   I don't  see what  may be  missing for  everyday desktop
use. It  is even better  than the nvidia  driver because of  its perfect
support of xrandr.
-- 
printk("autofs: Out of inode numbers -- what the heck did you do??\n"); 
2.0.38 /usr/src/linux/fs/autofs/root.c


pgpMqdhr4JWVR.pgp
Description: PGP signature

Re: RFC: Rules for distro-friendly packages

[Vincent Bernat]

OoO Pendant le temps de midi  du vendredi 17 septembre 2010, vers 12:16,
Ian Jackson  disait :

>> We just don't live in the  same world. Keep living in your narrow-minded
>> world where  users are  not allowed to  compile themselves  software and
>> where all  systems are up-to-date. In  my real world, I  have users that
>> are running  very old  distro and that  cannot upgrade it  nightly while
>> everything  works perfectly  ans just  need to  test the  software  on a
>> preprod system before trying to package it.

> I agree with your underlying point.  But there is absolutely no call
> for phrases like "keep living in your narrow-minded world".  I think
> you owe Enrico an apology.

> Please try to keep this list polite.  It is OK to disagree with
> people.  It is not OK to call them rude names.

I am not a native English speaker so I fail to see how saying "living in
a  narrow-minded   world"  is  rude.   Wiktionary  does   not  say  that
narrow-minded is rude. It says  "having restricted or rigid views" which
is exactly what I am expressing  here. I should rephrase with "Keep your
restricted view  on what  a user  is allowed to...".  I apology  for any
misunderstanding.
-- 
Follow each decision as closely as possible with its associated action.
- The Elements of Programming Style (Kernighan & Plauger)


pgpjDLaGtonex.pgp
Description: PGP signature

Re: RFC: Rules for distro-friendly packages

[Vincent Bernat]

OoO En  cette matinée  ensoleillée du vendredi  17 septembre  2010, vers
09:08, Enrico Weigelt  disait :

>> No, no, no. Users are not  limited to Debian developers using Sid. Users
>> may try to compile  on an old RHEL 2. 

> In this case they should really *know* what they're doing.
> RHEL is meant as an binary-only distribution - you should NOT install
> arbitrary packages without going through the whole distro's build
> engine and qm process, otherwise they'll risk merly all the stability
> ensured by the distro - that's a design aspect of those distros.
[...]

> Wait a minute! Arbitrary _users_ should never try to rebuild anything
> on a stable/production system. As soon as you're attempting that,
> you're stepping into the package maintainer or developer role, and
> then you should *know* what you're doing (or at least learn it).
[...]

Hello, /usr/local...

>> As upstream, I  care about Debian and cross-compiling  but I also should
>> care about  people wanting to  compile my software  on old RHEL 2  or on
>> Debian Etch (an  old enough platform to require some  runtime test in my
>> case). None of those platforms have a recent enough autotools to rebuild
>> configure, BTW.

> Then they should be updated.

We just don't live in the  same world. Keep living in your narrow-minded
world where  users are  not allowed to  compile themselves  software and
where all  systems are up-to-date. In  my real world, I  have users that
are running  very old  distro and that  cannot upgrade it  nightly while
everything  works perfectly  ans just  need to  test the  software  on a
preprod system before trying to package it.
-- 
BOFH excuse #148:
Insert coin for new game


pgp5cnptLYLXQ.pgp
Description: PGP signature

Re: RFC: Rules for distro-friendly packages

[Vincent Bernat]

OoO Pendant  le temps de  midi du jeudi  16 septembre 2010,  vers 12:28,
Enrico Weigelt  disait :

>> About autoconf stuff:
>> - Why require autogen.sh? On a release, configure script should be
>> present. No need to rebuild it. 

> No, there often *is* a need to rebuild it (actually, much of my
> QM work on dozens packages requires changing configure.in+friends).
> And you don't seriously want to patch autogenerated files, do you ? ;-o

>> Some users just don't have recent enough autotools to rebuild the
>> configure. 

> They should simply install it. Similar as they need recent toolchain,
> make, pkg-config, etc, etc.

No, no, no. Users are not  limited to Debian developers using Sid. Users
may try to compile  on an old RHEL 2. They should  absolutely not try to
rebuild configure since it is likely  to not work and leave them with an
unconfigurable package. On most projects, there is not autogen/bootstrap
in the realeases  for this very reason: do not confuse  the user and let
him install  autotools which is not mandatory  at all. autogen/bootstrap
is shipped in the VCS repository because this is targeted at developer.

autotools are  aimed at the end  user, not the distro  packager. This is
stated in the  introduction to autotools.  This is nice  to be nice with
the distro packager but the primary  target is the lambda user (which is
usually less skilled than the distro packager).

Compiling software from source is  enough a pain to avoid any unecessary
dependency. No need for a recent toolchain and no need for autotools for
a software aimed at running on a lot of systems (which is what autotools
are for too).

>> - Not using AC_TRY_RUN is too strong. 

> No, it's mandatory. It simply cannot crosscompile, no chance.

>> This macro has a parameter to be used when cross-compiling.

> It's inherently unreliable, by design. The developer has to specify
> some default behaviour in case of crosscompiling. And that's most
> likely wrong. If you do use that macro, you've normally relying
> on basicly assumptions. Such as the building system is equal 
> (yes *equal*, not just similar) to the actual target system.

>> It is more useful to detect a problem when not cross-compiling
>> with AC_TRY_RUN than to not detect it at all.

> If you really wanna have some runtime tests, then it should be
> done separately (eg. separate script or in make test stage).

Oh sure, if there  is a problem that can only be  detected at runtime, I
will let  the user  deal with it  in some  "make test" that  nobody runs
instead  of  handling  the  problem   for  him  in  most  situations  in
configure. Again, configure is targetted  at the end user (which usually
does not cross-compile). It  should automatically configure the software
to  be in  a workable  state  after compilation.  No need  to read  some
README or run some additional scripts.

As upstream, I  care about Debian and cross-compiling  but I also should
care about  people wanting to  compile my software  on old RHEL 2  or on
Debian Etch (an  old enough platform to require some  runtime test in my
case). None of those platforms have a recent enough autotools to rebuild
configure, BTW.
-- 
Use the "telephone test" for readability.
- The Elements of Programming Style (Kernighan & Plauger)


pgpM0Fy62RtPn.pgp
Description: PGP signature

Re: RFC: Rules for distro-friendly packages

[Vincent Bernat]

On Thu, 16 Sep 2010 10:40:30 +0200, Enrico Weigelt 
wrote:

> I've collected several rules that upstreams should follow to make
> distro maintainer's life much easier:
> 
> http://www.metux.de/index.php/de/component/content/article/57.html
> 
> Free feel to comment on it :)

About autoconf stuff:
 - Why require autogen.sh? On a release, configure script should be
present. No need to rebuild it. Some users just don't have recent enough
autotools to rebuild the configure. Moreover, with modern autotools, I tend
to think that autoreconf -i is just as simple as autogen.sh.
 - Why require building in a separate tree? Why it helps, most of the
packages we have just build in the same source tree.
 - Not using AC_TRY_RUN is too strong. This macro has a parameter to be
used when cross-compiling. It is more useful to detect a problem when not
cross-compiling with AC_TRY_RUN than to not detect it at all.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/0668dd331505dad9896cff083909a...@chopper.luffy.cx

Re: doc-base is hugely unloved; bug mass-filing needed?

[Vincent Bernat]

OoO Vers  la fin de l'après-midi  du dimanche 08 août  2010, vers 16:32,
Osamu Aoki  disait :

>> > So, out of 273 doc-containing packages on this system, just 70 bothered.
>> > I feel a strong urge to put the commands in a script that will auto-file
>> > a bug against any package in the output of the last command.  How do
>> > maintainers feel about that?

> For these things in general, supplying lintian check is good idea.

There exists already one.
-- 
 Attention . ne pas lire! Ceci n'est qu'un r.glement de compte. 
 D.sol., hier, j'.tais absent.
 -+- DT in GGE - Aujourd'hui aussi, merci les kill-files -+-


pgpwOvdXUWgVQ.pgp
Description: PGP signature

Re: RFH: How to compile swf files from source

[Vincent Bernat]

OoO En ce début d'après-midi nuageux  du jeudi 05 août 2010, vers 14:15,
Paul Wise  disait :

>> I had  a package which also  ships a SWF along  with a FLA and  an AS. I
>> assumed that SWF could be built from  FLA and AS. I did not find how and
>> therefore, I just removed the SWF from the binary package.

> I think that usually the AS would not be distributed like that,
> normally it would be inside the FLA file. Perhaps the SWF only
> consists of code and the AS is split out as a convenience. You might
> try using mtasc on the AS file to see what you get as a result.

canvas.as:12: characters 0-3 : parse error Unexpected var

It seems that mtasc only  understands ActionScript 2. This is not really
important  in my  case  since upstream  also  wants to  get  rid of  the
SWF. Since it seems there is a lot of bug reports about those SWF files,
it would be nice  that people who knows how those tools  work put a page
in the wiki to explain how a SWF could be built with tools in Debian.
-- 
I WILL NOT BARF UNLESS I'M SICK
I WILL NOT BARF UNLESS I'M SICK
I WILL NOT BARF UNLESS I'M SICK
-+- Bart Simpson on chalkboard in episode 8F15


pgplnbVTZ1r6h.pgp
Description: PGP signature

Re: RFH: How to compile swf files from source

[Vincent Bernat]

OoO En cette fin de nuit blanche du jeudi 05 août 2010, vers 05:52, Paul
Wise  disait :

>> In my package ampache it ships xspf_jukebox.fla and xspf_jukebox.swf and
>> I recently received bug #591202 which states:
> ...
>> Are there debian tools available to do this?  If so what are they?

> The FLA format is binary and completely undocumented by Adobe so
> nothing except the Flash authoring tools read it.

But people working with Flash programs uses FLA format as source format?
In this case, FLA could be  the preferred form of modification and hence
the source file. The fact that it is difficult to modify is annoying but
we cannot  require that each  program must be  able to be  modified with
ease only with tools in main.

I had  a package which also  ships a SWF along  with a FLA and  an AS. I
assumed that SWF could be built from  FLA and AS. I did not find how and
therefore, I just removed the SWF from the binary package.
-- 
 /*
  *   Should be panic but... (Why are BSD people panic obsessed ??)
  */
2.0.38 /usr/src/linux/net/ipv4/ip_fw.c


pgpBMp2N0xOpP.pgp
Description: PGP signature

Re: Would appreciate advice on Debian Policy and draft webapp sub policy

[Vincent Bernat]

OoO En  cette fin  de matinée  radieuse du mardi  27 juillet  2010, vers
11:39, Nicholas Bamber  disait :

> Now we come to the nub of the problem. The bug report suggests that
> the post install script should run "a2enmod include" (and then bounce
> the webserver). I looked for guidence in the policy manuals but could
> not find any indication of how to handle dependencies of this
> sort. Bouncing the webserver seems a bit drastic in some ways. Maybe
> the person in charge might want to install the modules during the day
> but bounce the web server late at night. It seems a big step to me for
> a package to take this choice away from  a the person in
> charge. Assuming one does make the post install script work that way,
> what would the post remove script do? It cannot blindly run "a2dismod
> include". The more I think about this the worse it gets.

Look at  other web apps.  They usually have  a question to let  the user
choose  to restart or  not the  web server.  For example,  mediawiki and
roundcube have such  questions. Keep the wording to  ease the l10n teams
work.

Please note that I did not look at the webapp policy recently.
-- 
SUBSTITUTE TEACHERS ARE NOT SCABS
SUBSTITUTE TEACHERS ARE NOT SCABS
SUBSTITUTE TEACHERS ARE NOT SCABS
-+- Bart Simpson on chalkboard in episode BABF09


pgpbizkZGCpAp.pgp
Description: PGP signature

Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling

[Vincent Bernat]

OoO Lors  de la soirée naissante  du mardi 27 juillet  2010, vers 17:55,
Roland Mas  disait :

> Probably easier: add a CGI-like interface to reportbug, and open a
> browser on it?  Since it *is* reportbug, it can continue grabbing
> whatever information is relevant using its scripts.  And then it's a
> matter of a menu entry (or a big fat icon) running "reportbug --http &
> sensible-browser http://localhost:$some-port/";.  AJAX to taste, then
> submit via local or remote SMTP.

This seems a sensible idea. However, any web interface would lead to the
same  problems that  were  raised with  reportbug-ng.  To my  knowledge,
useful  bug reports  need to  run interactive  console scripts  for some
packages. This could be solved with some AJAX terminal.
-- 
panic("Unable to find empty mailbox for aha1542.\n");
2.2.16 /usr/src/linux/drivers/scsi/aha1542.c


pgp9MTWJEILpw.pgp
Description: PGP signature

Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling

[Vincent Bernat]

OoO  En ce début  d'après-midi nuageux  du jeudi  22 juillet  2010, vers
14:26, Russ Allbery  disait :

> In Launchpad, for anything in universe, the typical experience is that
> your bug goes into a black hole until a month or two later someone sends
> you some form letter about it.

By form letter, you mean automatic closing of the bug on the base that a
new  Ubuntu has  been released?  This  is why  I think  that Ubuntu  bug
reports are usually not helpful at  all when you try to solve a problem:
nobody takes care of the bug and it is automatically closed.

However, the automatic backtrace with the help of debug repository would
be useful to have in Debian. We need the debug repository first.
-- 
Avoid temporary variables.
- The Elements of Programming Style (Kernighan & Plauger)


pgpjdVpNytueF.pgp
Description: PGP signature

Re: packages being essential but having stuff in /usr/?!

[Vincent Bernat]

OoO Pendant le repas du  vendredi 16 juillet 2010, vers 19:30, Christoph
Anton Mitterer  disait :

> Also, right after the init system starts, neither /proc, nor /dev,
> nor /sys are there, right?

/dev is always  here. It may not be complete but  it contains the strict
minimum needed  by any program  (like /dev/null). /proc is  mounted very
very  early. Except  for the  script which  should mount  it,  all other
scripts should safely assume that /proc is here. The same now applies to
/sys.
-- 
I WILL NOT DRIVE THE PRINCIPAL'S CAR
I WILL NOT DRIVE THE PRINCIPAL'S CAR
I WILL NOT DRIVE THE PRINCIPAL'S CAR
-+- Bart Simpson on chalkboard in episode 7F06


pgpZJgLIc0Itv.pgp
Description: PGP signature

Re: Bindv6only once again

[Vincent Bernat]

OoO La nuit ayant déjà recouvert  d'encre ce jour du mardi 15 juin 2010,
vers 23:18, George Danchev  disait :

> they would be still inferior to those opening two separate sockets (which 
> means more fine-grained control like listening on v4 or v6 or both, or 
> establish means to threat them specifically if necessary), but this is at 
> least 
> easily doable for brain-damaged apps badly in need for 0.

How an  application which is working at  level 7 and that  don't want to
care about level 3 is a brain-damaged app? No doubt that IPv6 support is
so slow.
-- 
I DID NOT WIN THE NOBEL FART PRIZE
I DID NOT WIN THE NOBEL FART PRIZE
I DID NOT WIN THE NOBEL FART PRIZE
-+- Bart Simpson on chalkboard in episode AABF19


pgpPoVl9UzXO3.pgp
Description: PGP signature

Re: Bindv6only once again

[Vincent Bernat]

OoO En  cette matinée  pluvieuse du dimanche  13 juin 2010,  vers 10:59,
Sune Vuorela  disait :

>> It is difficult  to understand why we should wait  freeze time to change
>> anything.  Some people (including me) may be afraid that the problem may
>> not be corrected because of  the freeze. Moreover, in the meantime, some
>> applications don't  work with  IPv6 for people  that are unaware  of the
>> possibility to modify the sysctl.

> You are taking the wrong approach to things. We should see if it is
> still a major problem at freeze time, or if we have managed to fix all
> the buggy software before freeze.

The problem is not the software that are in Debian and have bugs already
reported, the  problem is the software  that are not in  Debian and that
won't work with Debian but with any other distribution.

— XXX does not work with my Debian, it just fails with some network error
— I just tested, it works fine on my Arch
— Oh, Debian just sucks, let's try something else

*That* is a real situation case.  Nobody will set bindv6only to 1 on her
own.
-- 
SPITWADS ARE NOT FREE SPEECH
SPITWADS ARE NOT FREE SPEECH
SPITWADS ARE NOT FREE SPEECH
-+- Bart Simpson on chalkboard in episode 8F01


pgpVbHfMUlS9t.pgp
Description: PGP signature

Re: Bindv6only once again

[Vincent Bernat]

OoO En  cette matinée  pluvieuse du dimanche  13 juin 2010,  vers 10:09,
Stefano Zacchiroli  disait :

> Now, the above is used routinely cum grano salis by individual
> maintainers, that before pushing big changes that affect others discuss
> them first and listen to feedback of the others. As reported by Julien
> in this thread already, that has happened in this specific case and the
> maintainer position is still (AFAIU) that the decision will be
> re-evaluated at freeze time.

It is difficult  to understand why we should wait  freeze time to change
anything.  Some people (including me) may be afraid that the problem may
not be corrected because of  the freeze. Moreover, in the meantime, some
applications don't  work with  IPv6 for people  that are unaware  of the
possibility to modify the sysctl.
-- 
Test input for validity and plausibility.
- The Elements of Programming Style (Kernighan & Plauger)


pgpoPxe2mxiGi.pgp
Description: PGP signature

Re: UPG and the default umask

[Vincent Bernat]

OoO La nuit ayant déjà recouvert  d'encre ce jour du samedi 15 mai 2010,
vers 23:34, Russ Allbery  disait :

>> Is it possible to detect whether an account is configured properly based
>> on the UPG idea? If yes, wouldn't it then make sense to only set umask
>> 002 if a proper UPG account is detected, otherwise 022? This would avoid
>> putting non-UPG systems on danger.

> That's a good idea.  I'm not sure if all UNIX group systems allow one to
> ask how many users are a member of a particular group, but if there's a
> way to ask that question at least in those group systems that support it,
> the implementation should be fairly straightforward.

If you  are thinking about checking if  the user is alone  in her group,
this seems a bad idea. I may  be alone in "users" group. But I may later
add  someone else. My  umask will  then change  but all  already created
files will be readable and writable by the new user.

Comparing names seems a better solution.
-- 
panic("aha1740.c"); /* Goodbye */
2.2.16 /usr/src/linux/drivers/scsi/aha1740.c


pgpXrIlwZh4EL.pgp
Description: PGP signature

Re: About new source formats for packages without patches

[Vincent Bernat]

OoO  En ce  début de  soirée du  jeudi 25  mars 2010,  vers  21:06, Neil
Williams  disait :

> Removing the tag without fixing dpkg to not require
> debian/source/format for source format 1.0 packages. That bug does need
> to be fixed. I've only altered a few of my packages in SVN - none of
> those need an upload particularly soon - so if there's a realistic
> chance that dpkg will never assert format 3.0 in the absence of
> debian/source/format, I'll override the lintian warning until dpkg is
> fixed. (Already done that for a few packages.)

No offense,  but adding a file  to override a  lintian information about
adding a simple file seems a bit odd.
-- 
Don't stop at one bug.
- The Elements of Programming Style (Kernighan & Plauger)


pgpzkSjWP595c.pgp
Description: PGP signature

Re: Has Debian abandoned Python?

[Vincent Bernat]

OoO  En cette  nuit nuageuse  du mardi  09 mars  2010, vers  01:14, Russ
Allbery  disait :

>>> Maybe the group of people doing that work should also be the people who
>>> decide when Python 2.6 will be uploaded, if the current maintainer
>>> isn't able or willing to coordinate the work for whatever reason?

>> Yes, that would be awesome in theory, still quite difficult (or seen as
>> rude) in reality.

> Well, I'm personally not directly involved with Python development, but it
> seems like a lot of people are upset with the way that the python package
> is being maintained.  We do have a procedure for this: it falls under the
> jurisdiction of the Debian Technical Committee.  If there is a group of
> people who believe they would be better able to maintain the python
> package than the current maintainer and are willing to assemble a team and
> propose themselves as the maintainers, that's certainly something that can
> be appealed to the Debian Technical Committee for discussion.

Some respectable people keep telling  us that the problem is handled and
the solution  will come  soon. Going to  the technical committee  may be
seen at confrontational against them, I think.
-- 
MUD IS NOT ONE OF THE 4 FOOD GROUPS
MUD IS NOT ONE OF THE 4 FOOD GROUPS
MUD IS NOT ONE OF THE 4 FOOD GROUPS
-+- Bart Simpson on chalkboard in episode 9F15


pgpAaj3yXuBQ1.pgp
Description: PGP signature

Re: git and quilt

[Vincent Bernat]

OoO En ce début d'après-midi  ensoleillé du samedi 06 février 2010, vers
15:15, Goswin von Brederlow  disait :

> He wants to KISS. So lets make it even simpler.

> - master:   patched source
> - upstream: upstream source

Suppose the following workflow:
 - upstream version X.Y
 - master branch based on X.Y
 - patch Z applied on master branch
 - upstream branch is updated to (X+1).0
 - upstream  is merged  into master  branch and  manual  intervention is
   needed because  there are conflicts between changes  on upstream side
   and patch Z

Now, if upstream want to get patch Z, he can :
 - get patch Z for version X.Y
 - get  patch between  upstream  (X+1).0 and  master (X+1).0  containing
   patch Z and other stuff

While git  allows to  keep track of  modifications, it is  difficult for
upstream (or some other people) to review a precise patch.  Or maybe you
rebase master  branch on the upstream  one (which would be  great to see
watch patches  are applying  to upstream but  will lead  to difficulties
when tracking master branch)?
-- 
Don't comment bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)


pgpk4diN0Vp0H.pgp
Description: PGP signature

Re: Roundcube does not create database

[Vincent Bernat]

OoO  Pendant  le repas  du  mardi 26  janvier  2010,  vers 19:17,  Frank
Niedermann  disait :

> Already tried "dpkg-reconfigure -plow roundcube-core". It asks
> about the mailserver, encryption and stuff but not about the
> database. When I installed phpmyadmin dbconfig-common asked
> me to enter the database admin password and created the new
> phpmyadmin database in MySQL.

> I expected roundcube to do the same but it did not. It also did
> not ask the mailserver settings, this only comes up with the -plow
> parameter for dpkg-reconfigure.

Well, I  don't know exactly  how to solve  your problem. You can  ask on
debian-us...@ldo (since  debian-de...@ldo is not the right  place to ask
for help on this) or file a  bug report. I doubt that the bug is related
to roundcube since all database handling is done by dbconfig-common.

You can also look at :
 debconf-get-selections | grep -E ^(roundcube-core|dbconfig-common)

"dbconfig-install" key should be "true".
-- 
BOFH excuse #269:
Melting hard drives


pgp7dAIwsJbkP.pgp
Description: PGP signature

Re: Roundcube does not create database

[Vincent Bernat]

OoO  Pendant le repas  du dimanche  24 janvier  2010, vers  19:39, Frank
Niedermann  disait :

> I have installed the package roundcube on Debian Squeeze. It does not create
> the required database (roundcube-core and roundcube-mysql also installed). I
> already tried with dpkg-reconfigure but this does not work either.

> Other packages like phpmyadmin do work fine and are able to create the
> database.

> Is this a known issue or should I create a bugreport? Can I fix it on my
> own?

Well,   dunnowhat   happens.   Database   creationis   done   by
dbconfig-common. You should  try "dpkg-reconfigure -plow roundcube-core"
to check if it asks something.
-- 
panic("esp: what could it be... I wonder...");
2.2.16 /usr/src/linux/drivers/scsi/esp.c


pgpHZScL4tDGm.pgp
Description: PGP signature

Re: where is /etc/hosts supposed to come from?

[Vincent Bernat]

OoO En  cette nuit nuageuse du  jeudi 31 décembre 2009,  vers 01:16, Sam
Morris  disait :

>>> Adding meaningless configuration to work around programs that are
>>> broken by design does not seem like a good solution.
>> 
>> There are  a lot of  programs requiring some  kind of FQDN  (for example
>> because they implement a protocol requiring it). How should they get it?
>> I have never  seen a more universal that to get  node name with uname(),
>> then use gethostbyname(). Please, provide better way.

> The admin should supply it in the program's configuration, since only the 
> admin is able to know the correct value.

Sure, the admin would have to  configure a whole set of programs instead
of just configuring the canonical name in one unique place of the system
and let each program that needs it to autodiscover it?

This  does  not preclude  the  possibility  to  override what  has  been
discovered on a case by case basis.
-- 
panic ("No CPUs found.  System halted.\n");
2.4.3 linux/arch/parisc/kernel/setup.c


pgpsJCTUzoBfc.pgp
Description: PGP signature

Re: where is /etc/hosts supposed to come from?

[Vincent Bernat]

OoO Pendant le  temps de midi du mercredi 30  décembre 2009, vers 12:03,
Gabor Gombas  disait :

>> If this is a real question, put:
>> 127.0.1.1 fqdn nodename
>> 
>> This seems a  very acceptable way to give a FQDN  to your laptop without
>> relying  on network.  hostname -f  and  programs using  a similar  inner
>> working will be able to get the right result.

> Adding meaningless configuration to work around programs that are broken
> by design does not seem like a good solution.

There are  a lot of  programs requiring some  kind of FQDN  (for example
because they implement a protocol requiring it). How should they get it?
I have never  seen a more universal that to get  node name with uname(),
then use gethostbyname(). Please, provide better way.
-- 
MUD IS NOT ONE OF THE 4 FOOD GROUPS
MUD IS NOT ONE OF THE 4 FOOD GROUPS
MUD IS NOT ONE OF THE 4 FOOD GROUPS
-+- Bart Simpson on chalkboard in episode 9F15


pgpNbq2P1eUD7.pgp
Description: PGP signature

Re: where is /etc/hosts supposed to come from?

[Vincent Bernat]

OoO En  cette fin  de nuit  blanche du mercredi  30 décembre  2009, vers
05:23, Russ Allbery  disait :

>> I haven't said that. And this is often not the case under Debian,
>> i.e. the FQDN is often obtained from /etc/hosts, which has the
>> precedence over DNS (see /etc/nsswitch.conf).

> I have no entry in /etc/hosts other than 127.0.0.1 and the corresponding
> IPv6 entries.  What could I possibly put in there?

If this is a real question, put:
127.0.1.1 fqdn nodename

This seems a  very acceptable way to give a FQDN  to your laptop without
relying  on network.  hostname -f  and  programs using  a similar  inner
working will be able to get the right result.
-- 
I WILL NOT BURP IN CLASS
I WILL NOT BURP IN CLASS
I WILL NOT BURP IN CLASS
-+- Bart Simpson on chalkboard in episode 7G04


pgpikse8ltT4a.pgp
Description: PGP signature

Re: where is /etc/hosts supposed to come from?

[Vincent Bernat]

OoO En ce  doux début de matinée du mardi 29  décembre 2009, vers 08:34,
je disais:

>> Details in . I 
>> do wonder, however, why the system hostname has to appear in /etc/hosts 
>> at all? Programs that want to find it out can read /etc/hostname 
>> directly, after all. And wtf is 'localdomain' for, anyway?

> A common way to get hostname is to request node name through uname, then
> asks  for a resolution  of this  name. If  the name  does not  appear in
> /etc/hosts, this will lead to a DNS resolution and without network, this
> can take a long time.

And BTW, this is exactly what hostname -f does. It does not read /etc/hostname.
-- 
BOFH excuse #96:
Vendor no longer supports the product


pgp9CwnzoThWh.pgp
Description: PGP signature

Re: where is /etc/hosts supposed to come from?

[Vincent Bernat]

OoO En  cette nuit nuageuse du  mardi 29 décembre 2009,  vers 00:41, Sam
Morris  disait :

> Details in . I 
> do wonder, however, why the system hostname has to appear in /etc/hosts 
> at all? Programs that want to find it out can read /etc/hostname 
> directly, after all. And wtf is 'localdomain' for, anyway?

A common way to get hostname is to request node name through uname, then
asks  for a resolution  of this  name. If  the name  does not  appear in
/etc/hosts, this will lead to a DNS resolution and without network, this
can take a long time.
-- 
panic("kmem_cache_init(): Offsets are wrong - I've been messed with!");
2.2.16 /usr/src/linux/mm/slab.c


pgpoaQHfiLk8y.pgp
Description: PGP signature

Re: Bug#559039: ITP: snmp-mibs-downloader -- Downloads RFCs and IANA Docs containing MIBs and extracts them

[Vincent Bernat]

OoO Pendant le repas du mardi  01 décembre 2009, vers 19:45, sean finney
 disait :

>> This package contains a script which downloads RFCs containing SNMP MIB
>> files and extracts them into /usr/share/mibs/ietf. It also downloads the
>> most current MIBs from IANA and extracts them into /usr/share/mibs/iana.

> afaict this wouldn't be policy compliant wrt the FHS.  such a script
> would need to download them to somewhere under /var/{lib,cache} or
> maybe under /usr/local/share if it's intended to be primarily manually 
> invoked.

Putting MIBs  in /var/lib/mibs seems  a sensible choice. A  symlink from
/usr/share/mibs/{ietf,iana} would help too.
-- 
BOFH excuse #192:
runaway cat on system.


pgpvCgb7ywgCW.pgp
Description: PGP signature

Re: Bug#454993: RFH: fglrx-driver -- non-free AMD/ATI r5xx, r6xx display driver

[Vincent Bernat]

n Wed, 19 Aug 2009 02:03:18 +, Leinier Cruz Salfran
 wrote:

> I see this post and I would ask the team that keep the old version of
> theses packages in order to allow me to use my old integrated video card
> 'ati radeon  xpress 200'

This card works without any problem with radeon driver. Both 2D and 3D.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Resigning from Debian

[Vincent Bernat]

OoO En  cette matinée  pluvieuse du mardi  07 juillet 2009,  vers 10:30,
Alexis Sukrieh  disait :

>> What's the  status of tinymce? Is  there someone else  in Debain Webapps
>> team?

> Andrea De Iacovo[1], maintainer of Wordpress, did tell me he wanted to
> adopt tinymce, as wordpress depends on it.

> I agreed, maybe you can contact him and see if you can work together?

I was  just worried  that it would  stay unmaintained. Since  Andrea has
already stepped up to maintain it, I am fine with this.
-- 
 /* James M doesn't say fuck enough. */
2.4.3 linux/net/core/netfilter.c


pgpArXkU5OyRJ.pgp
Description: PGP signature

Re: Resigning from Debian

[Vincent Bernat]

OoO Lors  de la soirée naissante  du lundi 06 juillet  2009, vers 17:12,
Alexis Sukrieh  disait :

> Hi,
> It's been a very long time since I worked for Debian, and my packages
> have been actually unmaintained for a while.

> This is because of two major reasons:

> - My paid work is time and energy consuming, hence my freetime is precious

> - During the last months, I've lost the motivation and the energy to
>   honnor my Debian activities.

> It's been a pleasure to contribute to that beautiful project,
> and I wish the very best to the whole community.

> Feel free to orphan/adopt all of my packages.

What's the  status of tinymce? Is  there someone else  in Debain Webapps
team?

Thanks for your work!
-- 
HARDFAIL("Not enough magic.");
2.4.0-test2 /usr/src/linux/drivers/block/nbd.c


pgpC8fuDNKNaw.pgp
Description: PGP signature

Re: debian and lilypond 2.12

[Vincent Bernat]

OoO En ce  début d'après-midi ensoleillé du dimanche  07 juin 2009, vers
15:59, Gilles Filippini  disait :

> It appears that lilypond is actively maintained in ubuntu[1].
> I'd like to take over this package in Debian but I don't know about the
> practices when a package is already maintained in Ubuntu:
> * should I start from the Ubuntu source package?
> * the Ubuntu lilypond release is now 2.12.1-0ubuntu1; what should be the
> debian release then? 2.12.1-1?
> * or simply persuade the ubuntu maintainer to package it for Debian ;)
> (cc-ing him)?

You could also propose to package it as a team.

For the  version number,  yes, Debian version  should be  2.12.1-1.
-- 
BOFH excuse #335:
the AA battery in the wallclock sends magnetic interference


pgpDfesKa8HRO.pgp
Description: PGP signature

Re: ignoring the CoC in regards to cc:s (Re: Can we ship sources of a PDF file in the Debian diff?

[Vincent Bernat]

OoO En  cette fin de  nuit blanche du  mardi 28 avril 2009,  vers 05:27,
Brian May  disait :

>> I tried hard, for many years, to love the Mail-Followup-To field, but I
>> must agree that it doesn't serve the purpose well enough to recommend.
>> (Briefly: it breaks when a discussion crosses between different mailing
>> lists, and other common use cases.)

> I don't think that is a problem with the field, but the MUA programs.
> Mutt, for example, AFAIK will list all mailing lists in the
> autogenerated Mail-Folloup-To, without allowing the user to change this
> (unless the user overrides the entire field) or pick only one mailing
> list.

How Mutt is able to detect  all mailing lists? The fields in the headers
only allow to detect the current mailing list.
-- 
BOFH excuse #419:
Repeated reboots of the system failed to solve problem


pgpZ6i9Utic39.pgp
Description: PGP signature

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Vincent Bernat]

OoO En  ce début de soirée du  dimanche 05 avril 2009,  vers 21:56, Russ
Allbery  disait :

>> I don't  know for proftpd,  but a daemon  can use an empty  directory in
>> /var/run to chroot into it.

> Seems like a good use for /var/lib to me.  There's no reason that I can
> see  to put  such  a directory  on  a file  system  that's defined  as
> transient.

Both   /var/lib  and   /var/run  are   for  files,   not   really  empty
directories. It seems to be more usual to put an empty (or almost empty)
directory into  /var/run than into /var/lib.  Googling a bit,  I did not
find  any  rationale  behind  this.   It  seems  not  advisable  to  use
/var/empty (an hole in an  application could permit to share the exploit
with another for example).

This  is not  an  argument against  having  /var/run in  tmpfs, just  an
information about what  kind of daemon could be run  from inetd and need
something in /var/run.
-- 
I WILL NOT HANG DONUTS ON MY PERSON
I WILL NOT HANG DONUTS ON MY PERSON
I WILL NOT HANG DONUTS ON MY PERSON
-+- Bart Simpson on chalkboard in episode 2F13


pgpJs7ykkZEwH.pgp
Description: PGP signature

Re: New architectures

[Vincent Bernat]

OoO Lors de  la soirée naissante du dimanche 05  avril 2009, vers 17:53,
Paul Wise  disait :

>> How packages that run on Linux only should handle those new architectures?

> Same as for stuff that only runs on i386; port them to kFreeBSD or
> restrict them to linux architectures and add them to P-a-s.

Hum, what's "P-a-s"?


pgpavALVk5BJn.pgp
Description: PGP signature

Re: New architectures

[Vincent Bernat]

OoO Vers la  fin de l'après-midi du dimanche 05  avril 2009, vers 16:23,
Joerg Jaspert  disait :

> we just added two new architectures to the Debian archive. Everybody
> please welcome

>   kfreebsd-i386 AKA GNU/kFreeBSD i386
>   kfreebsd-amd64 AKA GNU/kFreeBSD amd64


> Note that this enables porter NMUs for those two. In case you have a
> bug with a patch waiting for your package that has to do with one of
> them, please either fix it soon or expect a porter NMU to be done soon.

> The two new architectures (well, better named OS i think, as they use a
> different kernel) are available in unstable and experimental. We do
> start out empty, importing only what is needed to get a buildd
> running. For this reason you will not be able to directly use it
> immediately. Please wait until they catched up, which I expect to happen
> soon.

Hi Joerg!

How packages that run on Linux only should handle those new architectures?
-- 
# Basic IBM dingbats, some of which will never have a purpose clear
# to mankind
2.4.0 linux/drivers/char/cp437.uni


pgpZdExSTLIgE.pgp
Description: PGP signature

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Vincent Bernat]

OoO En cette nuit striée d'éclairs  du samedi 04 avril 2009, vers 02:14,
Russ Allbery  disait :

>> There are still daemons though (like proftpd comes to mind), which ship a
>> subdirectory in /var/run and support inetd.

> What does it use the directory for?

I don't  know for proftpd,  but a daemon  can use an empty  directory in
/var/run to chroot into it.
-- 
FUNNY NOISES ARE NOT FUNNY
FUNNY NOISES ARE NOT FUNNY
FUNNY NOISES ARE NOT FUNNY
-+- Bart Simpson on chalkboard in episode 8F20


pgpaTIof8Ed1U.pgp
Description: PGP signature

Re: DebConf10 to take place in New York City, USA

[Vincent Bernat]

OoO Pendant  le temps de midi  du mercredi 25 février  2009, vers 12:45,
martin f krafft  disait :

> In eleven years of DebConf history, this will be the first time
> that the Debian developer conference takes place in the United
> States of America, which had been avoided in previous years due to
> visa and other immigration issues. The NYC team had addressed those
> issues from the very start and submitted a very convincing bid.

Out of curiosity, how those issues will be handled?
-- 
Localise input and output in subroutines.
- The Elements of Programming Style (Kernighan & Plauger)


pgp6Q5VnhTSHG.pgp
Description: PGP signature

Re: Python related changes for unstable/squeeze

[Vincent Bernat]

OoO Lors  de la soirée naissante  du mardi 17 février  2009, vers 17:09,
Holger Levsen  disait :

>> This is not a technical problem. The technical divergences can be solved
>> if consensus is reached about them or if a decision body (TC or GR)
>> forces them. This is purely a person problem: Matthias is clearly not
>> willing to maintain python-central correctly nor to make it evolve
>> according to the needs of developers. These are two very good reasons to
>> keep maintaining an alternative.

> Hint: it takes two to discuss. If I were Matthias and would read those 
> statements,  I probably  wouldnt see  added  value in  talking to  you
> neither.

IMO,  this is unfortunate  but it  is really  difficult to  discuss with
Matthias. Most comments are just ignored.

For example:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474630
Matthias made a  short statement about the problem  and ignored the rest
of  the discussion.  I had  to switch  to python-central  to  solve this
bug. Josselin added a functionality to python-support to circumvent this
limitation.

Here is another example:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475440
Some fixes  were proposed  to circumvent this  problem but bug  was just
marked as "won't fix". This  hits all users using easy_install (which is
fairly popular among Python developers). And this bug is in Lenny.
-- 
A TRAINED APE COULD NOT TEACH GYM
A TRAINED APE COULD NOT TEACH GYM
A TRAINED APE COULD NOT TEACH GYM
-+- Bart Simpson on chalkboard in episode AABF15


pgpMRDQ4D5Dxa.pgp
Description: PGP signature

Re: ode 0.11 transition

[Vincent Bernat]

OoO  En cette  soirée bien  amorcée du  dimanche 15  février  2009, vers
22:49, je disais:

>> I uploaded libode 0.11 in experimental. Can you please, test it with
>> your package and adjust your build dependency in order to able to build
>> it with libode-dev or libode0-dev.

After a second read, maybe  this should be "libode-dev | libode0-dev". I
thought that we should choose one.

> Which  package should we  use between  libode-dev and  libode0-dev? They
> both provide /usr/lib/libode.a without being in conflict.

This problem still remains.
-- 
I WILL NOT TEACH OTHERS TO FLY
I WILL NOT TEACH OTHERS TO FLY
I WILL NOT TEACH OTHERS TO FLY
-+- Bart Simpson on chalkboard in episode 9F05


pgplg7jMuL3Iu.pgp
Description: PGP signature

Re: ode 0.11 transition

[Vincent Bernat]

OoO  En cette  soirée bien  amorcée du  dimanche 15  février  2009, vers
22:16, Gonéri Le Bouder  disait :

> I uploaded libode 0.11 in experimental. Can you please, test it with
> your package and adjust your build dependency in order to able to build
> it with libode-dev or libode0-dev.
> Please, note that "enable double precision" has be enabled.

> I'll upload ode 0.11 in unstable in the coming days unless an anormal
> behaviour is detected.

Hi Goneri!

Which  package should we  use between  libode-dev and  libode0-dev? They
both provide /usr/lib/libode.a without being in conflict.
-- 
I WILL NOT HIDE THE TEACHER'S PROZAC
I WILL NOT HIDE THE TEACHER'S PROZAC
I WILL NOT HIDE THE TEACHER'S PROZAC
-+- Bart Simpson on chalkboard in episode 3G03


pgpMjD6L8Yj9e.pgp
Description: PGP signature