Re: Bug#661329: recommends doom-wad which is only provided by non-free doom-wad-shareware

[Sven Joachim]

On 2012-04-30 09:23 +0200, Thomas Goirand wrote:

> On 04/30/2012 03:48 AM, Sven Joachim wrote:
>> The difference is that there are millions of videos you can watch with
>> VLC, while there are only a dozen or so iwads for doomsday, none of
>> which are free.
>
> And then what? Is it about numbers?

No, it's about the fact that while it is theoretically possible to play
doomsday with free iwads, no such iwads actually exist TTBMOMK.

> Now, let me find another example. We have in the main archive a lot of
> emulators:
> - visualboyadvance
> - xmame
> - atari800

That package is actually in contrib.

> - aranym
> - gnuboy
> - uae
> - stella

Moved to main only after somebody found free ROMs for it.

> - openmsx
> - etc.
>
> For all of these, there's no ROM available in the Debian archive, and
> it'd be hard, if not impossible in some cases, to find some free ROMs.
> This doesn't prevent the packages to be in main. If you want to
> challenge this fact, then please do it in debian-devel@l.d.o, but not
> for this RC bug, as this is a general situation really not specific to
> doomsday.

Moving the discussion to debian-devel hereby.

Cheers,
   Sven


-- 
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/87397l4q1d@turtle.gmx.de

Re: Re: RFC: OpenRC as Init System for Debian

[Dmitry Nezhevenko]

On Mon, Apr 30, 2012 at 01:49:57AM +0300, Uoti Urpala wrote:
> Marco d'Itri wrote:
> > I am on friendly terms with many Red Hat people, but it is a fact that 
> > they take design decisions which are aligned with the needs of RHEL 
> > and these needs are often far from what is good for other distributions.
> 
> > - configuration files in /etc/ overriding configuration files in /lib/, 
> >   to work around the inferior configuration files handling of RPM
> 
> I'm not convinced that the traditional Debian way of directly editing
> package-created files under /etc would be preferable. I think the
> etc-overrides-lib alternative is technically superior in many ways: the
> original version is kept in a known location, it's trivial to
> (temporarily) revert to defaults when you suspect a problem is caused by
> local configuration, it's easier to see what has been locally modified
> and what hasn't, and especially if the program supports file inclusion
> (to include then override the default version) you can resolve more
> updates without needing to do 3-way merges by hand.
> 
> The main argument against etc-overrides-lib has been that dpkg can
> automatically give warnings about some of the cases where you may need
> to update your local configuration. But this ability isn't really
> inherent to the directly-editing case, nor only implementable with it. I

Currently dpkg allows not only warnings about "some of the cases". It
always warns user when config file was changed in package and user edited
installed copy. And provides a a nice way to quickly take a look to
changes, choose which version to use or even start shell for resolving it
manually. So you just can't miss time when config should be edited at all.

With "etc-overrides-lib" it's not possible at all... 

-- 
WBR, Dmitry


signature.asc
Description: Digital signature

Re: Enabling hardened build flags for Wheezy

[Bernhard R. Link]

* Charles Plessy  [120430 04:31]:
> Sorry to rant again, but am I the only one thinking that we are in most of the
> case wasting everybody's time by not simply passing all the hardening flags by
> default in CFLAGS ?  In my experience (and I maintain more than 100 packages),
> it is extremely rare to need to ensure that the compiler, preprocessor and
> linker flags are in three separate variables.
>
> When we need to modify a large number of packages in order to propagate a
> change, isn't this meaning that we are not picking the most efficient 
> defaults ?

As I wrote again, keeping them seperate means you can support both
cases: systems following GNU coding standards to keep them seperate and
systems wanting them in one place. If you mix them first you cannot
seperate them later.

There is also no way this can work without any maintainer intervention.
You need to look what the flags are called. It is quite common for
hand-written flags to use CFLAGS where CXXFLAGS is meant for example.
So you as maintainer have to decide what mapping to use anyway.
If you need CFLAGS='$(CFLAGS)' CPPFLAGS='$(CPPFLAGS)' or
CFLAGS='$(CXXFLAGS)' CPPFLAGS='$(CPPFLAGS)' or
CFLAGS='$(CPPFLAGS) $(CFLAGS)' or
CFLAGS='$(CPPFLAGS) $(CXXFLAGS)' or even something like
CFLAGS='$(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS)'.

So what we have is already the most efficient default and also the only
one always working.

Bernhard R. Link


-- 
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/20120430084657.ga2...@client.brlink.eu

non-satisfyable Recommends: in main (was Re: Bug#661329: recommends doom-wad which is only provided by non-free doom-wad-shareware)

[Jon Dowland]

On Mon, Apr 30, 2012 at 09:50:06AM +0200, Sven Joachim wrote:
> Moving the discussion to debian-devel hereby.

Oh joy-of-joys, a context free drive-by-CC to -devel, and a bug which indicates
an NMU without warning, DELAYED queue use or nmudiff, for a package to which
the maintainer is actively discussing the bug (not MIA), for a maintainer who
is just beginning their time with Debian and relies on support and sponsorship.
How inviting to the project!

FWIW, I (or someone else) could quite easily contrive and upload a freedoom
derivative which worked with Doomsday and upload it. It would then satisfy this
technical requirement and thus the argument would go away.  It would also be
a poor imitation of Freedoom (lack features), confusing to users and generally
be a complete waste of time.


-- 
Jon Dowland


-- 
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/20120430093354.GD32217@debian

Re: switching from exim to postfix

[Bernd Zeimetz]

On 04/29/2012 03:13 AM, Marco d'Itri wrote:
> Is this the right time to do it?

First lets fix all RC bugs and get other more important things done than
discussing - yet again - the replacement of a well working MTA by a
different well working MTA. Both are equally easy to setup and configure
with debconf for the "normal" user - and that is what counts. Those who
know what they want/need also know how to install exactly that.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
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/4f9e614e.8070...@bzed.de

Re: switching from exim to postfix

[Carsten Hey]

As I'm not involved in developing dma at all, neither upstream nor in
Debian, I'm not the right one to discuss implementation details in depth
with.


* Russ Allbery [2012-04-29 17:32 -0700]:
> Adam Borowski  writes:
> > On Sun, Apr 29, 2012 at 10:50:45PM +0200, Carsten Hey wrote:
>
> >> Looks like the DragonFly Mail Agent (dma), which already has been
> >> mentioned in this thread, could become a decent default for Wheezy+1
> >> after some small changes.
> >>
> >> In a nutshell: it's able to deliver locally and remotely, has a queue,
> >> supports TLS/SSL, does not listen on port 25 and instead of running as
> >> daemon, it if run every 5 minutes via cron to flush the queue.
>
> > I hope you mean: to run retries (in which case every 5 minutes is an
> > overkill).
>
> > Delaying every outgoing mail by 5 minutes doesn't sound like a good idea
> > to me.
>
> ... incron ... You'd still need timed handling of queued mail for retries.

There are two modes dma can run in, one is the deferred mode, which
seems to be basically how you think dma always works.  The other is the
immediate mode that is default in Debian and upstream and as the name
suggests it delivers immediately if possible and it forks for mails that
can not be delivered immediately.  The resulting processes then handle
besides obvious other things the timed handling of queued mail for
retries.


The rest of this mail is likely not interesting for most of you since it
only tries to answer the natural follow up question "Why does it need
a cronjob then?" and explains why I don't think anymore that a switch to
incron should be considered.


Two reasons for running dma -q via cronjob in my own words but stolen
from README.Debian are:
 * If the queue is not empty after reboot, dma -q needs to be run at
   least once to start delivering these mails.  A @reboot cronjob or an
   init script would also to this job.
 * Delivery processes might die for various reasons, but the mails still
   need to be delivered in a timely manner.

If dma would be the default MTA, then it should IMHO be as reliable as
possible and even try to prevent user errors.  If a user would
unintentionally enables deferred mode (which is useful if you are behind
a dial-up line) but would not set up dma -q to run periodically, then
the mails would not be delivered without such a default cronjob.
A comment that reminds users to adapt the cronjob if needed should be
added to the config file.  If dma -q is run every 5 minutes be default
anyway, the option -bq does not make that much sense anymore; this can
possibly be solved by implementing different ways of processing queued
mails.  All in all, enabling the cronjob by default, as it is already
done in Debian, seems to be sane.


> I think that was Carsten's point about switching to incron, which
> would then do the right thing for new outgoing mail.

This is a reasonable and logical assumption, but it is wrong ;)

Actually the reason to mention incron was that I thought that running
dma -q if triggered by inotify could be a bit cheaper than running it
every five minutes.  For a default MTA, the amount of systems that run
it could make considering even minimal differences in efficiency
worthwhile.

The idea was to use incron to restart failed delivery processes, if this
would be possible at all depends on details of dma and incron/inotify
I'm not aware off.  An additional reason to the explanation above not to
use incron is that in rare cases dma might fail for example with ENOMEM
whilst reading its configuration file before it is able to open any file
in the spool dir, which would render running it by incron to be not 100%
bullet proof anyway.


Regards
Carsten


-- 
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/20120430095818.ga6...@furrball.stateful.de

Re: switching from exim to postfix

[Riku Voipio]

On Sat, Apr 28, 2012 at 07:12:42PM -0700, Russ Allbery wrote:
> I'm not sure that I see the point, and I say that as someone who
> replaces Exim with Postfix on all of my boxes.

Nobody's suggesting you need to change to anything. The worst you
have to do if debian changed default MTA, would be to
"apt-get install exim4" (gasp, what horrible pain) when doing new
installations.

> There's nothing particularly wrong with Exim; it works just fine. 

Exim in 2012 not supporting 8BITMIME and thus being the last Major MTA
forcing quoted-printable conversions to make emails "7bit clean" is quite
horribly wrong.

Debian is the main source of Exim installs in internet, it is also our fault.
According to one old stat[1], 34% of mx records were exim, most probably almost
all simply because it came by default in debian and it was "good enough"
so people didnt' switch away from it.

So yes, switching to postfix by default  would reduce the workload of email
servers around the globe (no need to burn cpu cycles and thus co2 to convert
emails to quoted-printable). 

Yes that was a bit of a hyperbole, but this is my pet issue. I complained
last about it in 2009 [2] with no change from upstream since...

Riku

[1] http://www.securityspace.com/s_survey/data/man.201007/mxsurvey.html
[2] http://suihkulokki.blogspot.com/2009/07/cult-of-workarounds.html


-- 
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/20120430101419.ga30...@afflict.kos.to

Re: RFC: OpenRC as Init System for Debian

[Uoti Urpala]

Dmitry Nezhevenko wrote:
> On Mon, Apr 30, 2012 at 01:49:57AM +0300, Uoti Urpala wrote:
> > Marco d'Itri wrote:
> > > - configuration files in /etc/ overriding configuration files in /lib/, 
> > >   to work around the inferior configuration files handling of RPM
> > 
> > I'm not convinced that the traditional Debian way of directly editing
> > package-created files under /etc would be preferable. I think the
> > etc-overrides-lib alternative is technically superior in many ways: the
> > original version is kept in a known location, it's trivial to
> > (temporarily) revert to defaults when you suspect a problem is caused by
> > local configuration, it's easier to see what has been locally modified
> > and what hasn't, and especially if the program supports file inclusion
> > (to include then override the default version) you can resolve more
> > updates without needing to do 3-way merges by hand.
> > 
> > The main argument against etc-overrides-lib has been that dpkg can
> > automatically give warnings about some of the cases where you may need
> > to update your local configuration. But this ability isn't really
> > inherent to the directly-editing case, nor only implementable with it. I
> 
> Currently dpkg allows not only warnings about "some of the cases". It
> always warns user when config file was changed in package and user edited
> installed copy. And provides a a nice way to quickly take a look to
> changes, choose which version to use or even start shell for resolving it
> manually. So you just can't miss time when config should be edited at all.

Wrong. Any program behavior change may require changing custom
configuration, but such changes need not be accompanied by changes in
the default configuration file. Currently dpkg lacks any mechanism to
show warnings in these cases, even if the maintainers are aware of it.
The only workaround would be to make dummy changes to the configuration
files just to trigger the dpkg warnings, but this would cause other
problems. Thus "can't miss at all" is false.

> With "etc-overrides-lib" it's not possible at all... 

This is not true either. You could develop tools that work in this case.
I think there is no fundamental reason why such tools couldn't work
better than current dpkg behavior with equal effort. An easy starting
point (requiring no per-package work at all) would be to show a warning
if an updated package owns a directory under /etc, and that directory
contains non-package-owned files. With some extra work, still no worse
than what's required for current dpkg handling, you should be able to
include information about changes to the corresponding default files (if
any).



-- 
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/1335786282.1766.57.camel@glyph.nonexistent.invalid

Re: RFC: OpenRC as Init System for Debian

[Dmitry Nezhevenko]

On Mon, Apr 30, 2012 at 02:44:42PM +0300, Uoti Urpala wrote:
> > Currently dpkg allows not only warnings about "some of the cases". It
> > always warns user when config file was changed in package and user edited
> > installed copy. And provides a a nice way to quickly take a look to
> > changes, choose which version to use or even start shell for resolving it
> > manually. So you just can't miss time when config should be edited at all.
> 
> Wrong. Any program behavior change may require changing custom
> configuration, but such changes need not be accompanied by changes in
> the default configuration file. Currently dpkg lacks any mechanism to
> show warnings in these cases, even if the maintainers are aware of it.
> The only workaround would be to make dummy changes to the configuration
> files just to trigger the dpkg warnings, but this would cause other
> problems. Thus "can't miss at all" is false.

You are talking about changing "default" values, right? Other cases
("option do_foo starts doing something called bar instead" seems just like
bugs). But even for changing default, a lot of software with editable by
hands config files usually are shipped with well commented options and
commented out default value. Something like this (from dovecot.conf):

   # If you want to specify non-default ports or anything more complex,
   # edit conf.d/master.conf.
   #listen = *, ::
   
   # Base directory where to store runtime data.
   #base_dir = /var/run/dovecot/
   
   # Name of this instance. Used to prefix all Dovecot processes in ps
   # output.
   #instance_name = dovecot

So if upstream will decide to change default value, they will also update
configuration file and this will trigger dpkg handling of changed
conffiles.

> > With "etc-overrides-lib" it's not possible at all... 
> 
> This is not true either. You could develop tools that work in this case.
> I think there is no fundamental reason why such tools couldn't work
> better than current dpkg behavior with equal effort. An easy starting
> point (requiring no per-package work at all) would be to show a warning
> if an updated package owns a directory under /etc, and that directory
> contains non-package-owned files. With some extra work, still no worse
> than what's required for current dpkg handling, you should be able to
> include information about changes to the corresponding default files (if
> any).

Yeah. I agree. It's _currently_ not possible at all. But again, it's
possible but introduce new issues complications for users.

By default Debian users are aware that files in /etc are supposed to be
edited by user (directly using editor or via special tool, like passwd can
be edited using useradd/userdel). So if you're using software for a first
time, you can just do "dpkg-query -L cooldaemon | grep /etc" to find out it's
configuration file, quickly edit it and that's all you need. In simple
cases where configuration files are full of comments, you even don't need
to open documentation.

Now compare this with "etc-overrides-lib" case. You're doing same
dpkg-query -L and it show nothing in /etc (or just empty directory if you
are lucky) and a lot of stuff pieces of which looks like a config in /lib,
/usr/lib, /usr/share or any other place. So you should carefully read
documentation to find out, is it possible at all to override such file,
and if yes, how an where to copy these them before editing.
 
-- WBR, Dmitry


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Steve McIntyre]

Marco wrote:
>On Apr 29, Jonathan Nieder  wrote:
>
>> Claiming that we are at their mercy is ignoring the ability to reason
>> with them.
>The problem is not "reasoning", in my experience Red Hat people will 
>promply agree that different distributions can make different choices.
>But nowadays they just refuse to support these choices.
>Obviously this is their prerogative, but it is also a fact which we need 
>to be aware of.

If that's really the case, then we should be looking at other options
that *will* support what we want/need rather than simply meekly
following.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane


-- 
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/e1sopa8-0005cg...@mail.einval.com

Re: switching from exim to postfix

[Adam Borowski]

On Mon, Apr 30, 2012 at 11:58:18AM +0200, Carsten Hey wrote:
> * Russ Allbery [2012-04-29 17:32 -0700]:
> > Adam Borowski  writes:
> > > On Sun, Apr 29, 2012 at 10:50:45PM +0200, Carsten Hey wrote:
> >
> > >> Looks like the DragonFly Mail Agent (dma), which already has been
> > >> mentioned in this thread, could become a decent default for Wheezy+1
> > >> after some small changes.
> > >>
> > >> In a nutshell: it's able to deliver locally and remotely, has a queue,
> > >> supports TLS/SSL, does not listen on port 25 and instead of running as
> > >> daemon, it if run every 5 minutes via cron to flush the queue.
> 
> If dma would be the default MTA, then it should IMHO be as reliable as
> possible and even try to prevent user errors.  If a user would
> unintentionally enables deferred mode (which is useful if you are behind
> a dial-up line) but would not set up dma -q to run periodically, then
> the mails would not be delivered without such a default cronjob.
> A comment that reminds users to adapt the cronjob if needed should be
> added to the config file.  If dma -q is run every 5 minutes be default
> anyway, the option -bq does not make that much sense anymore; this can
> possibly be solved by implementing different ways of processing queued
> mails.  All in all, enabling the cronjob by default, as it is already
> done in Debian, seems to be sane.

Not on a laptop or any machine that has to conserve power and avoid
unnecessary wakeups / disk spin-ups.

A cronjob every 5 minutes means you need to start up the process, which adds
quite a bit of churn.  Worse, it will spam the logs, and since at least
auth.log is fsync()ed after every write, it needs to spin up the disk.

That's too big a price for a MTA on a system that typically goes months or
years without a single mail.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


signature.asc
Description: Digital signature

Re: switching from exim to postfix

[Michael Tokarev]

On 30.04.2012 16:55, Adam Borowski wrote:
> On Mon, Apr 30, 2012 at 11:58:18AM +0200, Carsten Hey wrote:
>> * Russ Allbery [2012-04-29 17:32 -0700]:
[]
>> If dma would be the default MTA, then it should IMHO be as reliable as
>> possible and even try to prevent user errors.  If a user would
>> unintentionally enables deferred mode (which is useful if you are behind
>> a dial-up line) but would not set up dma -q to run periodically, then
>> the mails would not be delivered without such a default cronjob.
>> A comment that reminds users to adapt the cronjob if needed should be
>> added to the config file.  If dma -q is run every 5 minutes be default
>> anyway, the option -bq does not make that much sense anymore; this can
>> possibly be solved by implementing different ways of processing queued
>> mails.  All in all, enabling the cronjob by default, as it is already
>> done in Debian, seems to be sane.
> 
> Not on a laptop or any machine that has to conserve power and avoid
> unnecessary wakeups / disk spin-ups.
> 
> A cronjob every 5 minutes means you need to start up the process, which adds
> quite a bit of churn.  Worse, it will spam the logs, and since at least
> auth.log is fsync()ed after every write, it needs to spin up the disk.
> 
> That's too big a price for a MTA on a system that typically goes months or
> years without a single mail.

Hmm..  Now when you mentioned it...

On all our postfix servers (yes we use postfix), I mount a tmpfs over
/var/spool/postfix/run, create subdirs "pid", "private" and "public"
in there and change corresponding dirs in /var/spool/postfix/ into
symlinks to run/$subdir.

Exactly in order to avoid extra disk wakeups every so often, by default
every 5min -- when qmgr gets woken up to re-scan its queue.  This is
done by master process according to master.cf, master writes a byte
into corresponding /var/spool/postfix/public/qmgr FIFO, which results
in mtime of that inode being updated every 5 minutes.  Oh well.

(And when I create these symlinks, `postfix check' starts reporting
wrong permissions on /var/spool/postfix/p* - since they becomes
"world writable").

FWIW, but Postfix also has this issue, unless it is set up very
carefully and in a non-standard way :)

(This is something I use since about 2002)

Thanks,

/mjt


-- 
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/4f9e9014.8020...@msgid.tls.msk.ru

Re: RFC: OpenRC as Init System for Debian

[George Danchev]

On Mon, 30 Apr 2012 14:44:42 +0300, Uoti Urpala 
 wrote:


Hi,


Dmitry Nezhevenko wrote:

On Mon, Apr 30, 2012 at 01:49:57AM +0300, Uoti Urpala wrote:
> Marco d'Itri wrote:
> > - configuration files in /etc/ overriding configuration files in 
/lib/,
> >   to work around the inferior configuration files handling of 
RPM

>
> I'm not convinced that the traditional Debian way of directly 
editing

> package-created files under /etc would be preferable. I think the
> etc-overrides-lib alternative is technically superior in many 
ways: the

> original version is kept in a known location, it's trivial to
> (temporarily) revert to defaults when you suspect a problem is 
caused by
> local configuration, it's easier to see what has been locally 
modified
> and what hasn't, and especially if the program supports file 
inclusion
> (to include then override the default version) you can resolve 
more

> updates without needing to do 3-way merges by hand.
>
> The main argument against etc-overrides-lib has been that dpkg can
> automatically give warnings about some of the cases where you may 
need

> to update your local configuration. But this ability isn't really
> inherent to the directly-editing case, nor only implementable with 
it. I


Currently dpkg allows not only warnings about "some of the cases". 
It
always warns user when config file was changed in package and user 
edited

installed copy. And provides a a nice way to quickly take a look to
changes, choose which version to use or even start shell for 
resolving it
manually. So you just can't miss time when config should be edited 
at all.


Wrong. Any program behavior change may require changing custom
configuration, but such changes need not be accompanied by changes in
the default configuration file. Currently dpkg lacks any mechanism to
show warnings in these cases, even if the maintainers are aware of 
it.
The only workaround would be to make dummy changes to the 
configuration

files just to trigger the dpkg warnings, but this would cause other
problems. Thus "can't miss at all" is false.


I don't think it would be a very good idea for a low-level package 
manager to screen
for any subtle application changes be in the non-default configuration, 
its handling, or otherwise a more general
changes in the application functionality itself. To communicate such 
subtle application changes to the users,
there are Changelogs, NEWS files, and upper-level tools like 
apt-listchanges. Bonus: BTS + apt-listbugs.

I seriously doubt there is more room left for extra engineering.


--
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/115988c609b2c90f790cffeba8567...@spnet.net

Re: RFC: OpenRC as Init System for Debian

[Jon Dowland]

On Fri, Apr 27, 2012 at 08:56:21AM +0200, Bernd Zeimetz wrote:
> How do you define "really available"? When the link is up (and your
> favourite cisco is still blocking traffic to figure out its STP fun?) or
> you default gateway is pingable (and waits for you to start your
> VPN/authentication/whatever stuff)... and so on. There is always a
> reason why you need to configure something manually for the special
> cases - I can't see why an event driven system would be reduce the pain
> enough to make it worth the hassle to migrate to it.

I can't see another way to solve this problem, other than definine more than
one network state, and making sure the dependencies are to the correct ones
(e.g. "post-vpn", or "gateway-available", or whatever)


-- 
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/20120430133821.GH7795@debian

Re: switching from exim to postfix

[Stefano Zacchiroli]

On Sun, Apr 29, 2012 at 07:18:54PM +0200, Marco d'Itri wrote:
> On Apr 29, Russ Allbery  wrote:
> > The giant endless flamewars on debian-devel required to make a decision to
> > change anything.  :)
>
> Unrelated: you have just shown what poisons Debian and has been keeping 
> us behind innovation for the last years.
> Not the flamewars themselves, most of us are grown ups and can handle 
> them, but the fear that proposing a change will cause endless 
> discussions and no results.

Still unrelated, but let me AOL the above. Russ was just joking, but I
completely agree with Marco's point here. We're often scared of
"starting a thread on -devel" to propose changes that are far reaching
enough not to be directly implementable. Every now and then I got asked
advice on whether proposing some change on -devel is a good idea or not.
I'm always happy to give advice, but the fact we sometime worry to
propose changes is worrisome in itself. And it can induce project-wide
inertia as much as worrying too much about performing NMUs to fix bugs.

But we also need to convince ourselves that -devel discussions are
useful and lead to progress. For that to happen, we need more people
that look back at past discussions, summarize their conclusions (if
there have been) or relaunch them (if not), and take concrete actions as
the natural next step of discussing. There are people doing that, but
not nearly enough.

Cheers.
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Bug#661329: recommends doom-wad which is only provided by non-free doom-wad-shareware

[Charles Plessy]

Le Mon, Apr 30, 2012 at 09:50:06AM +0200, Sven Joachim a écrit :
> >
> > For all of these, there's no ROM available in the Debian archive, and
> > it'd be hard, if not impossible in some cases, to find some free ROMs.
> > This doesn't prevent the packages to be in main. If you want to
> > challenge this fact, then please do it in debian-devel@l.d.o, but not
> > for this RC bug, as this is a general situation really not specific to
> > doomsday.
> 
> Moving the discussion to debian-devel hereby.

Hi all,

perhaps one way to solve for good these frequently re-occuring disagreements
would be to suppress the contrib area, and distribute its contents into main
and non-free according to their license and their dependancy chain:  packages
that cause the installation of non-Free works through our packaging system
itself are definitely and mechanically non-Free, and packages that do not cause
non-Free works to be automatically installed are Free.  They may be useless
without additional data, but this is the same as drivers that are useless
without additional hardware.

Cheers,   

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/20120430141345.ga2...@falafel.plessy.net

Re: Towards multi-arch: "Multi-Arch: same" file conflicts

[Goswin von Brederlow]

Aron Xu  writes:

> But what if I endianness does matters for those gettext .mo files?
> Installing them as libfoo-translations-be and libfoo-translations-le
> will need some change in gettext support of those
> applications/libraries, that is finding mo files in alternative paths,
> and choosing the right one when being built (cross or not) and run
> (host or qemu).

Yes it does. Or maybe not. Lets talk about the general case instead of
gettext (gettext uses /usr/share/... so they must be arch independent).

With libfoo being in /usr/lib// any endian dependent data
should be in /usr/lib/// or /usr/lib/// (sorry, did we pick one of them as standard yet?),
which is usualy a configure option.

When the files are moved into libfoo-data-be then you can put links in
/usr/lib/// or /usr/lib/// to
link to /usr/lib//.

> Apart form (possibly) patching the software, marking the library as

Not the library, only the data files.

> M-A:foreign is questionable. How do we specify dependencies in
> d/control? If libfoo requires either libfoo-data-be or libfoo-data-le
> on different architectures, do we really want to hard code which
> architecture to depend on which package manually?

For the moment I don't see any other choice. If this is a frequent
problem then some dpkg support could be added or some debhelper
tool. Detecting the endianness at compile time and setting a substvar
would be relatively easy even now.

> Generating data files for both be and le then making it an arch:all
> and M-A:foreign package is not a solution for all maintainers, as this
> requires to patch the software which upstream are tend to reject of
> inclusion in many cases. Generating such data files in maintainer
> scripts is another thing I hate because I believe these data meant to
> have checksum stored in the package file list so that users can verify
> its integrity when needed.

There is no one solution for all maintainers.

At the moment and given the closeness of the freeze I would just do
whatever works for now. If that means big and little endian flavours of
the library have to conflict (libfoo-data-be conflicts libfoo-data-le)
because the path can't be untangeled then I would still think that would
be better than no multiarch support at all. The most common case is
amd64+i386 and adding armel is probably the next common. So most
multiarch users would be ok.

MfG
Goswin


-- 
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/87zk9ts3k9.fsf@frosties.localnet

Re: non-satisfyable Recommends: in main (was Re: Bug#661329: recommends doom-wad which is only provided by non-free doom-wad-shareware)

[Thomas Goirand]

On 04/30/2012 05:33 PM, Jon Dowland wrote:
> Oh joy-of-joys, a context free drive-by-CC to -devel, and a bug which 
> indicates
> an NMU without warning, DELAYED queue use or nmudiff, for a package to which
> the maintainer is actively discussing the bug (not MIA), for a maintainer who
> is just beginning their time with Debian and relies on support and 
> sponsorship.
> How inviting to the project!
>
> FWIW, I (or someone else) could quite easily contrive and upload a freedoom
> derivative which worked with Doomsday and upload it. It would then satisfy 
> this
> technical requirement and thus the argument would go away.  It would also be
> a poor imitation of Freedoom (lack features), confusing to users and generally
> be a complete waste of time

Well, here's the maintainer's view on this:

> The game should be able to run with free content as well, so I disagree 
> on that. Shall I just remove te requirement?

I happen to agree with him, also because there's at least one GPL editor for
doom, like doom builder:
http://www.doombuilder.com/index.php?p=development

"Doom Builder is an open source development released under GNU GPL. 
Everyone can learn from the source code and use it in a GPL compatible 
project."

Yes, doom builder is a windows app, but there are many ways to run
a windows APP (wine, ReactOS, etc.). [Before you ask: no, I didn't try
to actually run doombuilder myself.]

Or is it that doomsday still needs iwad files on top of the wad
files for levels, sprites, and characters?

In any case, if you still think that this was a mistake that I did,
I am sorry for it, but if that's the case, it's easy to fix:
- reopen #661329
- retitle it "doomsday should be in contrib, not in main" so that it's
not miss-leading anymore.

Cheers,

Thomas



-- 
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/4f9ea091.90...@debian.org

Re: Bug#661329: recommends doom-wad which is only provided by non-free doom-wad-shareware

[Michael Banck]

On Mon, Apr 30, 2012 at 11:13:45PM +0900, Charles Plessy wrote:
> They may be useless without additional data, but this is the same as
> drivers that are useless without additional hardware.

I don't buy this analogy - usually, drivers are programmed for existing
(or soon-to-be-existing) hardware, so the additional hardware is
obtainable, just possibly not-existent for the user.

On the other hand, the free data files you are talking about *are*
non-existant and unobtainable.


Michael


-- 
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/20120430142436.gh18...@nighthawk.chemicalconnection.dyndns.org

Re: Enabling hardened build flags for Wheezy

[Charles Plessy]

Le Mon, Apr 30, 2012 at 10:46:57AM +0200, Bernhard R. Link a écrit :
> * Charles Plessy  [120430 04:31]:
> >
> > When we need to modify a large number of packages in order to propagate a
> > change, isn't this meaning that we are not picking the most efficient 
> > defaults ?
> 
> As I wrote again, keeping them seperate means you can support both
> cases.

The problem is: who wants to support what and what for ?  I thought that the
release goal was to harden Debian, not to fine-grain makefiles in general.

What I see here is a system that is generous of other people's time.

If people who are interested by improving our dozens of thousands upstream
makefiles could spend time forwarding patches upstream by themselves, that
would be appreciated.  I have a hard time finding convincing words when I think
the patch is borderline useless.

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
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/20120430142553.gb2...@falafel.plessy.net

Re: RFC: OpenRC as Init System for Debian

[Uoti Urpala]

Dmitry Nezhevenko wrote:
> On Mon, Apr 30, 2012 at 02:44:42PM +0300, Uoti Urpala wrote:
> > Wrong. Any program behavior change may require changing custom
> > configuration, but such changes need not be accompanied by changes in
> > the default configuration file. Currently dpkg lacks any mechanism to

> You are talking about changing "default" values, right? Other cases

More generally about things not necessarily directly related to any
particular option. For example changing heuristics in the program, which
may require using different options to override (even if the options
themselves didn't change).


> > > With "etc-overrides-lib" it's not possible at all... 
> > 
> > This is not true either. You could develop tools that work in this case.

> Yeah. I agree. It's _currently_ not possible at all.

It is possible the with etc-overrides-libs behavior. Your "_currently_
not possible" is about the current state of the Debian tools, not about
etc-overrides-libs. My original point was exactly that the issues are
due to limitations of the existing Debian tools, not fundamental
problems with the etc-overrides-libs model itself.

>  But again, it's
> possible but introduce new issues complications for users.

I don't think it would be any more complicated to use once you're
familiar with the model.



-- 
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/1335795081.1766.69.camel@glyph.nonexistent.invalid

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

[Igor Pashev]

+1 to let Node.js be just "node"


-- 
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/4f9ea18a.8030...@gmail.com

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 04/30/2012 05:25 AM, Marco d'Itri wrote:
> This has been happening more and more after SuSE has become irrelevant.
>   
What (or what time) are you talking about?
Has SuSE ever been relevant? :)

Thomas


-- 
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/4f9ea64c.1060...@debian.org

Re: non-satisfyable Recommends: in main (was Re: Bug#661329: recommends doom-wad which is only provided by non-free doom-wad-shareware)

[Jon Dowland]

On Mon, Apr 30, 2012 at 10:24:17PM +0800, Thomas Goirand wrote:
> On 04/30/2012 05:33 PM, Jon Dowland wrote:
> > Oh joy-of-joys, a context free drive-by-CC to -devel, and a bug which 
> > indicates
> > an NMU without warning, DELAYED queue use or nmudiff, for a package to which
> > the maintainer is actively discussing the bug (not MIA), for a maintainer 
> > who
> > is just beginning their time with Debian and relies on support and 
> > sponsorship.
> > How inviting to the project!
> >
> > FWIW, I (or someone else) could quite easily contrive and upload a freedoom
> > derivative which worked with Doomsday and upload it. It would then satisfy 
> > this
> > technical requirement and thus the argument would go away.  It would also be
> > a poor imitation of Freedoom (lack features), confusing to users and 
> > generally
> > be a complete waste of time
> 
> Well, here's the maintainer's view on this:
> 
> > The game should be able to run with free content as well, so I disagree 
> > on that. Shall I just remove te requirement?
> 
> I happen to agree with him, also because there's at least one GPL editor for
> doom, like doom builder:
> http://www.doombuilder.com/index.php?p=development
> 
> "Doom Builder is an open source development released under GNU GPL. 
> Everyone can learn from the source code and use it in a GPL compatible 
> project."
> 
> Yes, doom builder is a windows app, but there are many ways to run
> a windows APP (wine, ReactOS, etc.). [Before you ask: no, I didn't try
> to actually run doombuilder myself.]

There's also Yadex, which was (at one time) packaged in Debian, and WadC
(), however…

> Or is it that doomsday still needs iwad files on top of the wad
> files for levels, sprites, and characters?

doomsday will need an internally-complete iwad: that is, one which provides
levels, sprites and sounds for the monsters in those levels, music to play
during the levels, textures for the walls and floors in those levels, and 
sound effects for the environment and weapons exposed in those levels, and
possibly ones not exposed (the engine may perform availability checks to
determine the precise game it is supposed to be offering.)

The problem with Freedoom (which provides all of the above) is that the levels
in Freedoom make use of features introduced in a doom derivative called 'boom',
from which the vast majority of doom engines derive, but not all, including
doomsday.  Doomsday will therefore crash trying to run those levels. (There
exists another port 'risen3d' which merged boom support into Doomsday -
, it is also, in theory, open source:
)

Note that chocolate-doom is another engine in the same situation (which is
in contrib).  There have been noises that people might re-work Freedoom to
remove the Boom features, or make a Boom-free variant, but I haven't seen
anything beyond discussion.

Another interesting consideration: You could use doomsday and freedoom together
as long as you never played the freedoom levels. So, you could play a
third-party level.  We could also package third-party levels.  What would be
the situation then? All the required pieces to use the engine would be in main.
(I have thought that a bundle of some of the best F/OSS compatible Doom levels
would be worthwhile. Sadly most of the classic or historically noteable Doom
levels are not F/OSS compatible.)

> In any case, if you still think that this was a mistake that I did,
> I am sorry for it, but if that's the case, it's easy to fix:
> - reopen #661329
> - retitle it "doomsday should be in contrib, not in main" so that it's
> not miss-leading anymore.

Well the issue is not so much the decision but the actions.  It would be nice
for you to submit the nmudiff, so Kees can merge it into his git repository.
AFAIK  the next in-progress doomsday release was being prepared in a git
repository (which would add the VCS- headers, too)


-- 
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/20120430145550.GJ7795@debian

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 04/30/2012 04:56 AM, Fernando Lemos wrote:
> I agree that OpenRC would be an improvement over the status
> quo, but migrating *away* from OpenRC later on would be a major pain
> as we would have to support both LSB/sysvinit scripts and OpenRC
> service descriptions for the foreseeable future.
>   
Ah? Is this any different with other alternatives like
upstart or systemd?

Thomas


-- 
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/4f9ea852.5090...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Fernando Lemos]

On Mon, Apr 30, 2012 at 11:57 AM, Thomas Goirand  wrote:
> On 04/30/2012 04:56 AM, Fernando Lemos wrote:
>> I agree that OpenRC would be an improvement over the status
>> quo, but migrating *away* from OpenRC later on would be a major pain
>> as we would have to support both LSB/sysvinit scripts and OpenRC
>> service descriptions for the foreseeable future.
>>
> Ah? Is this any different with other alternatives like
> upstart or systemd?

Yes. The kernel isn't getting any less event-based, so OpenRC would be
an interim solution.


-- 
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/canvyna-pad0n6bw-k2h4cbsmcwyqfjom3zq-jvmw33qq8dw...@mail.gmail.com

Re: switching from exim to postfix

[Russ Allbery]

Riku Voipio  writes:
> On Sat, Apr 28, 2012 at 07:12:42PM -0700, Russ Allbery wrote:

>> I'm not sure that I see the point, and I say that as someone who
>> replaces Exim with Postfix on all of my boxes.

> Nobody's suggesting you need to change to anything. The worst you have
> to do if debian changed default MTA, would be to "apt-get install exim4"
> (gasp, what horrible pain) when doing new installations.

Did you miss the bit where I said that I replace Exim with Postfix on all
of my boxes, despite quoting it?  Logically, you can draw the inference
that I know exactly how hard it is to replace the default MTA with a
different one.

>> There's nothing particularly wrong with Exim; it works just fine. 

> Exim in 2012 not supporting 8BITMIME and thus being the last Major MTA
> forcing quoted-printable conversions to make emails "7bit clean" is
> quite horribly wrong.

I didn't realize that.  I agree, that's an annoying missing feature.  Has
someone talked with upstream about whether they have plans to implement
it?

> Yes that was a bit of a hyperbole, but this is my pet issue. I
> complained last about it in 2009 [2] with no change from upstream
> since...

> [2] http://suihkulokki.blogspot.com/2009/07/cult-of-workarounds.html

Okay, let me rephrase that: has anyone talked with upstream about this
without making sweeping, confrontational statements about a "cult of
workarounds" and otherwise insulting them?

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87397lcl42@windlord.stanford.edu

Re: RFC: OpenRC as Init System for Debian

[Marco d'Itri]

On Apr 30, Thomas Goirand  wrote:

> On 04/30/2012 05:25 AM, Marco d'Itri wrote:
> > This has been happening more and more after SuSE has become irrelevant.
> What (or what time) are you talking about?
> Has SuSE ever been relevant? :)
In this context it was, because it was the other distribution supported 
by major hardware vendors and (some) ISVs and which employed the 
upstream maintainers of many kernel and core user space components.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Enabling hardened build flags for Wheezy

[Russ Allbery]

Charles Plessy  writes:

> The problem is: who wants to support what and what for ?  I thought that
> the release goal was to harden Debian, not to fine-grain makefiles in
> general.

> What I see here is a system that is generous of other people's time.

I would have assumed you would just add CPPFLAGS, CFLAGS, and LDFLAGS from
dpkg-buildflags to CFLAGS in your package if that's how your build system
works and be done.  In other words, debian/rules code like:

include /usr/share/dpkg/buildflags.mk

override_dh_autobuild:
make CFLAGS="$(CPPFLAGS) $(CFLAGS) $(LDFLAGS)"

This seems only marginally more difficult than a typical package only
because you'll have to invoke dpkg-buildflags yourself and can't just use
dh, but I can't imagine this taking more than five to ten minutes in
debian/rules unless something very strange is going on.

And yet, this clearly must not be correct, since you're talking about
sending Makefile patches upstream and are upset about having your time
wasted.  What am I missing?

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87y5pdb694@windlord.stanford.edu

Re: switching from exim to postfix

[Andreas Barth]

* Russ Allbery (r...@debian.org) [120430 17:09]:
> Riku Voipio  writes:

> > Exim in 2012 not supporting 8BITMIME and thus being the last Major MTA
> > forcing quoted-printable conversions to make emails "7bit clean" is
> > quite horribly wrong.
> 
> I didn't realize that.  I agree, that's an annoying missing feature.  Has
> someone talked with upstream about whether they have plans to implement
> it?

Quoting the manual
| accept_8bitmime Use: main   Type: boolean   Default: false
| 
| This option causes Exim to send 8BITMIME in its response to an SMTP EHLO
| command, and to accept the BODY= parameter on MAIL commands. However, though
| Exim is 8-bit clean, it is not a protocol converter, and it takes no steps to
| do anything special with messages received by this route. Consequently, this
| option is turned off by default. 

So the *default* configuration doesn't advertise 8BITMIME for the
reason that exim won't do conversions later on when relaying to other
hosts (which might be a possible RFC violation, depending where the
mail is relayed to). One could certainly argue that isn't the best /
recommended state, but it's not that bad either.

(And this is one of the first hits while searching for 8BITMIME and
exim.)


Andi


-- 
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/20120430152149.gp2...@mails.so.argh.org

Re: Bug#661329: recommends doom-wad which is only provided by non-free doom-wad-shareware

[Andrey Rahmatullin]

On Mon, Apr 30, 2012 at 04:24:36PM +0200, Michael Banck wrote:
> > They may be useless without additional data, but this is the same as
> > drivers that are useless without additional hardware.
> I don't buy this analogy - usually, drivers are programmed for existing
> (or soon-to-be-existing) hardware, so the additional hardware is
> obtainable, just possibly not-existent for the user.
How is non-free hardware different from non-free data in this case?

> On the other hand, the free data files you are talking about *are*
> non-existant and unobtainable.
Charles was not talking about *free* data.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Roger Leigh]

On Mon, Apr 30, 2012 at 12:04:32PM -0300, Fernando Lemos wrote:
> On Mon, Apr 30, 2012 at 11:57 AM, Thomas Goirand  wrote:
> > On 04/30/2012 04:56 AM, Fernando Lemos wrote:
> >> I agree that OpenRC would be an improvement over the status
> >> quo, but migrating *away* from OpenRC later on would be a major pain
> >> as we would have to support both LSB/sysvinit scripts and OpenRC
> >> service descriptions for the foreseeable future.
> >>
> > Ah? Is this any different with other alternatives like
> > upstart or systemd?
> 
> Yes. The kernel isn't getting any less event-based, so OpenRC would be
> an interim solution.

Unless OpenRC itself could become more event-based.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20120430155009.gl28...@codelibre.net

Re: Towards multi-arch: "Multi-Arch: same" file conflicts

[Simon McVittie]

On 30/04/12 15:21, Goswin von Brederlow wrote:
> With libfoo being in /usr/lib// any endian dependent data
> should be in /usr/lib/// or /usr/lib/ tuple>// (sorry, did we pick one of them as standard yet?),
> which is usualy a configure option.

I think you mean /usr/lib// for the second option?

If so, then the second option is what you'd naturally get from
./configure --libdir="\${prefix}/lib/$DEB_HOST_MULTIARCH" in an
Autotools package, and that's more or less what debhelper compat 9 does
- so it seems more natural to prefer that one. It's what we'll get in a
large percentage of packages anyway.

> For the moment I don't see any other choice. If this is a frequent
> problem then some dpkg support could be added or some debhelper
> tool. Detecting the endianness at compile time and setting a substvar
> would be relatively easy even now.

DEB_HOST_ARCH_ENDIAN is a dpkg-architecture query variable, just like
DEB_HOST_MULTIARCH, if you need it. (It takes values "big" or "little".)

S


-- 
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/4f9eb72b.5000...@debian.org

Re: RFC: OpenRC as Init System for Debian

[George Danchev]

On Mon, 30 Apr 2012 17:11:21 +0300, Uoti Urpala 
 wrote:

Dmitry Nezhevenko wrote:

On Mon, Apr 30, 2012 at 02:44:42PM +0300, Uoti Urpala wrote:
> Wrong. Any program behavior change may require changing custom
> configuration, but such changes need not be accompanied by changes 
in
> the default configuration file. Currently dpkg lacks any mechanism 
to



You are talking about changing "default" values, right? Other cases


More generally about things not necessarily directly related to any
particular option. For example changing heuristics in the program, 
which

may require using different options to override (even if the options
themselves didn't change).



> > With "etc-overrides-lib" it's not possible at all...
>
> This is not true either. You could develop tools that work in this 
case.



Yeah. I agree. It's _currently_ not possible at all.


It is possible the with etc-overrides-libs behavior. Your 
"_currently_
not possible" is about the current state of the Debian tools, not 
about

etc-overrides-libs. My original point was exactly that the issues are
due to limitations of the existing Debian tools, not fundamental
problems with the etc-overrides-libs model itself.


It is entirely possible to manage configuration files from dpkg's 
maintainer
scripts (postinst on 'configure' stage, and resp. postrm) as you find 
fit,

or by means of ucf, and possibly in combination with debconf.

One can ship a bunch of configuration files in /usr/share/$pkg, or
rather /usr/share/doc/$pkg/examples/ to avoid redundancy,
and have them copied to /etc/$whatever or whatever is needed.

(this has been so for more than a decade)


--
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/495ab64b83513d1b28f64662febb5...@spnet.net

Re: RFC: OpenRC as Init System for Debian

[Uoti Urpala]

George Danchev wrote:
> It is entirely possible to manage configuration files from dpkg's
> maintainerscripts (postinst on 'configure' stage, and resp. postrm) as
> you find fit,
> or by means of ucf, and possibly in combination with debconf.
> 
> One can ship a bunch of configuration files in /usr/share/$pkg, or
> rather /usr/share/doc/$pkg/examples/ to avoid redundancy,
> and have them copied to /etc/$whatever or whatever is needed.

You seem to be talking about something else, not about using
etc-overrides-lib semantics the same way as was meant in the messages
you replied to.



-- 
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/1335804141.1766.76.camel@glyph.nonexistent.invalid

Re: RFC: OpenRC as Init System for Debian

[Fernando Lemos]

On Mon, Apr 30, 2012 at 12:50 PM, Roger Leigh  wrote:
> On Mon, Apr 30, 2012 at 12:04:32PM -0300, Fernando Lemos wrote:
>> On Mon, Apr 30, 2012 at 11:57 AM, Thomas Goirand  wrote:
>> > On 04/30/2012 04:56 AM, Fernando Lemos wrote:
>> >> I agree that OpenRC would be an improvement over the status
>> >> quo, but migrating *away* from OpenRC later on would be a major pain
>> >> as we would have to support both LSB/sysvinit scripts and OpenRC
>> >> service descriptions for the foreseeable future.
>> >>
>> > Ah? Is this any different with other alternatives like
>> > upstart or systemd?
>>
>> Yes. The kernel isn't getting any less event-based, so OpenRC would be
>> an interim solution.
>
> Unless OpenRC itself could become more event-based.

How realistic is that?


-- 
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/canvyna-jrxkfeicsvhz2mzbe-4nldkfqmfmyex5bdb+uf8g...@mail.gmail.com

Re: question about "Conflicts:"

[Ralf Treinen]

On Mon, Apr 23, 2012 at 04:59:00PM +0200, Tollef Fog Heen wrote:
> ]] Harald Dunkel 
> 
> > How can I tell a Debian package to conflict with a real
> > package "foo", but not with other packages providing "foo"?
> 
> Conflicts: foo (>= 0)
> 
> since versioned provides don't exist.

Conflicts: foo (>= 0), foo (<< 0)

to be exact, since versions smaller than 0 are possible.

-Ralf.


-- 
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/20120430165756.ga13...@free.fr

Making -devel discussions more viable (was: switching from exim to postfix)

[Russ Allbery]

Stefano Zacchiroli  writes:
> On Sun, Apr 29, 2012 at 07:18:54PM +0200, Marco d'Itri wrote:

>> Unrelated: you have just shown what poisons Debian and has been keeping
>> us behind innovation for the last years.  Not the flamewars themselves,
>> most of us are grown ups and can handle them, but the fear that
>> proposing a change will cause endless discussions and no results.

> Still unrelated, but let me AOL the above. Russ was just joking, but I
> completely agree with Marco's point here. We're often scared of
> "starting a thread on -devel" to propose changes that are far reaching
> enough not to be directly implementable. Every now and then I got asked
> advice on whether proposing some change on -devel is a good idea or not.
> I'm always happy to give advice, but the fact we sometime worry to
> propose changes is worrisome in itself. And it can induce project-wide
> inertia as much as worrying too much about performing NMUs to fix bugs.

Yes, I was just joking and I'm inclined to agree.  (Although with respect
to Marco's specific proposal, there *is* a cost to debate and a request
for everyone's attention, and unless the gains are particularly clear, I'm
not sure it's worth incurring that cost.)

> But we also need to convince ourselves that -devel discussions are
> useful and lead to progress. For that to happen, we need more people
> that look back at past discussions, summarize their conclusions (if
> there have been) or relaunch them (if not), and take concrete actions as
> the natural next step of discussing. There are people doing that, but
> not nearly enough.

Given recent experiences, I'm also coming around to Ian's position that
aggressive and confrontational contributions from people who don't
otherwise seem to be contributing to Debian are part of the problem and
are not useful, and possibly should be banned.  I think that's been a
significant factor in the deterioration of the init system threads.

I want our technical discussions to be welcoming to anyone who has
information to share and who can bring additional clarity and insight to
the discussion.  But once things start getting heated or people start
throwing around accusations or verge towards personal attacks, there's a
real psychological difference between people who are contributing to
Debian and people who aren't.

If I'm being attacked by a colleague, it's a lot easier for me to go
"well, that made me mad, but they've done a great job of maintaining this
package I use and I've seen them do lots of other work for Debian, so they
must just be having a bad day" and let it go.  There's some built-up good
will because they're part of the community.

When that sort of attack comes from someone who I've never heard of
before, and when I then go to the PTS and db.debian.org and find no track
record of that person ever contributing to Debian other than via mailing
list discussions, it's a lot harder to give them that benefit of the
doubt.  And it gets really frustrating to have to keep discussing and
defending decisions with people who don't appear to be doing anything for
Debian other than feeding discussions that are a net drain of energy.

I'm leery of this whole line of argument, since it's inherently a double
standard.  That's why I've not raised it before.  But, well, humans are
social animals and social dynamics involve some degree of double standard,
and it would be nice if people who were effectively guests in our
technical discussions would behave like house guests rather than diving in
with the degree of robust engagement that (while never exactly ideal) our
long-time contributors have to some degree made up for in advance.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87fwbl9mbo.fsf...@windlord.stanford.edu

Re: switching from exim to postfix

[Raf Czlonka]

On Mon, Apr 30, 2012 at 01:55:24PM BST, Adam Borowski wrote:
> Not on a laptop or any machine that has to conserve power and avoid
> unnecessary wakeups / disk spin-ups.

Or any device with an SSD or SD card (more and more popular net-tops
nowadays).

> A cronjob every 5 minutes means you need to start up the process, which adds
> quite a bit of churn.  Worse, it will spam the logs, and since at least
> auth.log is fsync()ed after every write, it needs to spin up the disk.

This is the reason why I got rid of DMA on my systems, the defaults -
cron job and unnecessary entries in the logs.
Other than that I don't really have anything else against it.
If those two get fixed it could be a sane default MTA (IMHO).

Cheers,
-- 
Raf


-- 
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/20120430171517.ga3...@linuxstuff.pl

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: non-satisfyable Recommends: in main (was Re: Bug#661329: recommends doom-wad which is only provided by non-free doom-wad-shareware)

[Adam Borowski]

On Mon, Apr 30, 2012 at 03:55:50PM +0100, Jon Dowland wrote:
> > Or is it that doomsday still needs iwad files on top of the wad
> > files for levels, sprites, and characters?
> 
> The problem with Freedoom (which provides all of the above) is that the levels
> in Freedoom make use of features introduced in a doom derivative called 
> 'boom',
> from which the vast majority of doom engines derive, but not all, including
> doomsday.  Doomsday will therefore crash trying to run those levels.
> 
> Another interesting consideration: You could use doomsday and freedoom 
> together
> as long as you never played the freedoom levels.

So it's, of all Doom resources, the lack of _levels_ working with original
(-llish) Doom code that's the problem?  This would sound a lot more dire if
less than, say, 1/3 of us who remember the times of original Doom made our
own levels.

There's a bad case of Sturgeon's law, of course, but the only difficulty
here lies in sifting through a giant pile of levels and picking the best
ones.

My own "masterpieces" probably don't belong in the "best" category, but at
least a few could be ok contenders, especially after a few minor edits.
(Temporary URL: http://angband.pl/tmp/mywads/, ignore old copyright
statements, yadda yadda).

If you pool mine, yours and a few other random folks' wads, you'll have
enough content to get a good set.  And if you want one of famous ones,
there's a good chance authors will agree to relicense.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


signature.asc
Description: Digital signature

Re: Definition of _boot_

[Carsten Hey]

* Vincent Bernat [2012-04-30 20:30 +0200]:
> 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.

What you claim is not true.  If the system is up that far as his boot
definition would have implied, it would be easy for him to write
a simple shell script to do the rest or to install file-rc.  For the
rest of us, it would be easier to work around upgrade problems like the
ones udev's maintainer fixed for us for the last two releases.

Looks like sending a thread's summary before the thread started does not
end it ;)  Unless someone plans to write yet another init replacement or
to adapt an existent one, I think this discussion will not lead us to
anything helpful.


Regards
Carsten


-- 
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/20120430191414.ga17...@furrball.stateful.de

Re: non-satisfyable Recommends: in main (was Re: Bug#661329: recommends doom-wad which is only provided by non-free doom-wad-shareware)

[Jon Dowland]

On Mon, Apr 30, 2012 at 09:27:19PM +0200, Adam Borowski wrote:
> So it's, of all Doom resources, the lack of _levels_ working with original
> (-llish) Doom code that's the problem?  This would sound a lot more dire if
> less than, say, 1/3 of us who remember the times of original Doom made our
> own levels.

Yes.

> There's a bad case of Sturgeon's law, of course, but the only difficulty
> here lies in sifting through a giant pile of levels and picking the best
> ones.
> 
> My own "masterpieces" probably don't belong in the "best" category, but at
> least a few could be ok contenders, especially after a few minor edits.
> (Temporary URL: http://angband.pl/tmp/mywads/, ignore old copyright
> statements, yadda yadda).

Thanks.

> If you pool mine, yours and a few other random folks' wads, you'll have
> enough content to get a good set.  And if you want one of famous ones,
> there's a good chance authors will agree to relicense.

I had a plan to package a collection of PWADs ('patch' WADs - levels) as a
package which I never did.  I'm going to see about picking that up tomorrow.
I've identified two that are "public domain" and featured in a "100 best PWADs
of all time" list in the last few years.  After that, I'm hoping to arrange
access to the DB backing 'http://www.doomworld.com/idgames";, which has user-
submitted ratings and a list of txt files supplied with each PWAD. Luckily,
there was a widely-used txt-template that offered one of three "licenses"
and the majority of people who created levels used the template and picked
a license, so it should be possible to identify some highly-rated PWADs
which have DFSG-compatible terms. ("you can do whatever you want with this
file." was one of the license-texts; one of others was "you may use this
as a base for another PWAD, but you must give the original author credit"
which I think should pass, depending on how strict you want to be about
interpreting the proscriptiveness of "base for another PWAD")


-- 
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/20120430201320.GA16843@debian

Re: Towards multi-arch: "Multi-Arch: same" file conflicts

[Aron Xu]

On Mon, Apr 30, 2012 at 22:21, Goswin von Brederlow  wrote:
> Aron Xu  writes:
>
>> But what if I endianness does matters for those gettext .mo files?
>> Installing them as libfoo-translations-be and libfoo-translations-le
>> will need some change in gettext support of those
>> applications/libraries, that is finding mo files in alternative paths,
>> and choosing the right one when being built (cross or not) and run
>> (host or qemu).
>
> Yes it does. Or maybe not. Lets talk about the general case instead of
> gettext (gettext uses /usr/share/... so they must be arch independent).
>
> With libfoo being in /usr/lib// any endian dependent data
> should be in /usr/lib/// or /usr/lib/ tuple>// (sorry, did we pick one of them as standard yet?),
> which is usualy a configure option.
>

/usr/lib//package/ is more natural with Autotools and CMake,
which I prefer to use.

> When the files are moved into libfoo-data-be then you can put links in
> /usr/lib/// or /usr/lib/// to
> link to /usr/lib//.
>
>> Apart form (possibly) patching the software, marking the library as
>
> Not the library, only the data files.
>
>> M-A:foreign is questionable. How do we specify dependencies in
>> d/control? If libfoo requires either libfoo-data-be or libfoo-data-le
>> on different architectures, do we really want to hard code which
>> architecture to depend on which package manually?
>
> For the moment I don't see any other choice. If this is a frequent
> problem then some dpkg support could be added or some debhelper
> tool. Detecting the endianness at compile time and setting a substvar
> would be relatively easy even now.
>

Yes, detecting endianness at compile time and setting substvar is
easy, but again if those packages are arch:any, then they'll actually
consume a lot of space on our mirrors (discussed at -devel before).

>> Generating data files for both be and le then making it an arch:all
>> and M-A:foreign package is not a solution for all maintainers, as this
>> requires to patch the software which upstream are tend to reject of
>> inclusion in many cases. Generating such data files in maintainer
>> scripts is another thing I hate because I believe these data meant to
>> have checksum stored in the package file list so that users can verify
>> its integrity when needed.
>
> There is no one solution for all maintainers.
>

If we want to reduce the mirror space consumed by such a package,
building arch:all package is a straightforward solution without
modifying archive management software and dpkg/apt, but it's again not
a good choice because we have to keep using binary upload mechanism
(or the maintainer will be required to patch the software so it can
generate both be/le data during a single buildd run).

> At the moment and given the closeness of the freeze I would just do
> whatever works for now. If that means big and little endian flavours of
> the library have to conflict (libfoo-data-be conflicts libfoo-data-le)
> because the path can't be untangeled then I would still think that would
> be better than no multiarch support at all. The most common case is
> amd64+i386 and adding armel is probably the next common. So most
> multiarch users would be ok.
>
> MfG
>        Goswin

I agree on your opinion. It's much better than nothing. But we do need
to discover possible solution for Wheezy+1 or even Wheezy+2, don't we?
:-)

-- 
Regards,
Aron Xu


--
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/CAMr=8w5uu+ojvtfhp-7op6g4ijjdj7pdsi+n5jnqt_r3kt0...@mail.gmail.com

Re: non-satisfyable Recommends: in main (was Re: Bug#661329: recommends doom-wad which is only provided by non-free doom-wad-shareware)

[Adam Borowski]

On Mon, Apr 30, 2012 at 09:13:25PM +0100, Jon Dowland wrote:
> I had a plan to package a collection of PWADs ('patch' WADs - levels) as a
> package which I never did.  I'm going to see about picking that up tomorrow.
> I've identified two that are "public domain" and featured in a "100 best PWADs
> of all time" list in the last few years.  After that, I'm hoping to arrange
> access to the DB backing 'http://www.doomworld.com/idgames";, which has user-
> submitted ratings and a list of txt files supplied with each PWAD. Luckily,
> there was a widely-used txt-template that offered one of three "licenses"
> and the majority of people who created levels used the template and picked
> a license, so it should be possible to identify some highly-rated PWADs
> which have DFSG-compatible terms. ("you can do whatever you want with this
> file." was one of the license-texts; one of others was "you may use this
> as a base for another PWAD, but you must give the original author credit"
> which I think should pass, depending on how strict you want to be about
> interpreting the proscriptiveness of "base for another PWAD")

Most of WAD authors didn't put any thought into the license terms, me
included, and just picked any option at random.  I bet a majority of them
would be willing to relicense if asked.

Contacting those folks can be problematic, though -- 16-18 years later, few
email addresses are still valid.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


signature.asc
Description: Digital signature

Re: Enabling hardened build flags for Wheezy

[Charles Plessy]

Le Mon, Apr 30, 2012 at 08:15:35AM -0700, Russ Allbery a écrit :
> Charles Plessy  writes:
> 
> > The problem is: who wants to support what and what for ?  I thought that
> > the release goal was to harden Debian, not to fine-grain makefiles in
> > general.
> 
> > What I see here is a system that is generous of other people's time.
> 
> I would have assumed you would just add CPPFLAGS, CFLAGS, and LDFLAGS from
> dpkg-buildflags to CFLAGS in your package if that's how your build system
> works and be done.  In other words, debian/rules code like:
> 
> include /usr/share/dpkg/buildflags.mk
> 
> override_dh_autobuild:
> make CFLAGS="$(CPPFLAGS) $(CFLAGS) $(LDFLAGS)"
> 
> This seems only marginally more difficult than a typical package only
> because you'll have to invoke dpkg-buildflags yourself and can't just use
> dh, but I can't imagine this taking more than five to ten minutes in
> debian/rules unless something very strange is going on.
> 
> And yet, this clearly must not be correct, since you're talking about
> sending Makefile patches upstream and are upset about having your time
> wasted.  What am I missing?

Hi Russ,

all our packages include a way to pass build flags to the upstream build
system, in order to implement features such as DEB_BUILD_OPTIONS=noopt.  It
would have been trivial to pass the hardening flags automatically through the
same communication channel.

Unfortunately, the hardening build flags have been split in three variables.
To make sure they are passed correctly, either the upstream makefiles have to
be modified, or debian/rules has to be modified.  Why couldn't we design a
solution that does not require these modifications except for corner cases ?
It does not matter that they are trivial, the point is that if most C programs
need to have the same override in debian/rules, it feels that there is
something wrong.

(For the patches, I am getting them through the BTS, and I would feel too
unwelcoming to just throw them away).


Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
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/20120430223954.gd17...@falafel.plessy.net

Re: Enabling hardened build flags for Wheezy

[Russ Allbery]

Charles Plessy  writes:

> all our packages include a way to pass build flags to the upstream build
> system, in order to implement features such as DEB_BUILD_OPTIONS=noopt.
> It would have been trivial to pass the hardening flags automatically
> through the same communication channel.

I don't understand what you mean.  Explicit logic is required in
debian/rules to handle DEB_BUILD_OPTIONS=noopt unless you use a helper
system that embeds that logic.  There's nothing magic about that.  dh
deals with it for you, of course, but it's no different so far as I can
tell from the way hardening flags were implemented, except that it's much
simpler to change the optimization level than it is to harden all the
parts of the build.

> Unfortunately, the hardening build flags have been split in three
> variables.  To make sure they are passed correctly, either the upstream
> makefiles have to be modified, or debian/rules has to be modified.

Well... it's usual to have to modify debian/rules to adjust to new
features of the Debian build system, no?  It's a pretty simple one-time
change, isn't it?

> Why couldn't we design a solution that does not require these
> modifications except for corner cases ?

We did... that's dh.  dh 9 just picks up hardening flags and just works
without any changes required for any Autoconf-enabled package, or for any
package with another build system that it understands.

> It does not matter that they are trivial, the point is that if most C
> programs need to have the same override in debian/rules, it feels that
> there is something wrong.

Most C programs use Autoconf in my experience.  I know that scientific
software often doesn't, but I think scientific software is the significant
outlier in that respect.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87pqao6dno@windlord.stanford.edu

Re: Bug#661329: recommends doom-wad which is only provided by non-free doom-wad-shareware

[Charles Plessy]

Le Mon, Apr 30, 2012 at 04:24:36PM +0200, Michael Banck a écrit :
> On Mon, Apr 30, 2012 at 11:13:45PM +0900, Charles Plessy wrote:
> > They may be useless without additional data, but this is the same as
> > drivers that are useless without additional hardware.
> 
> I don't buy this analogy - usually, drivers are programmed for existing
> (or soon-to-be-existing) hardware, so the additional hardware is
> obtainable, just possibly not-existent for the user.
> 
> On the other hand, the free data files you are talking about *are*
> non-existant and unobtainable.

Hi Michael,

any analogy is discutable, and fortunately it is not the main point of my
argument.

By the way I would like to add another point, that the split between contrib
and non-free is not informative.  A program in contrib can be tightly coupled
to a non-free library in a way that would require a considerable amount of work
to free it.  On the other hand, a program in non-free can be so because of
re-using non-free code that can be easily removed.

For instance, the seaview package went from main to non-free when it gained the
possibility to do some kind of phylogenetic analysis, and if one would remove
this function, the resulting program would still be completely functional and
would be an improvement compared to the last free version.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
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/20120430224650.ge17...@falafel.plessy.net

Re: Bug#661329: recommends doom-wad which is only provided by non-free doom-wad-shareware

[Russ Allbery]

Charles Plessy  writes:

> By the way I would like to add another point, that the split between
> contrib and non-free is not informative.  A program in contrib can be
> tightly coupled to a non-free library in a way that would require a
> considerable amount of work to free it.  On the other hand, a program in
> non-free can be so because of re-using non-free code that can be easily
> removed.

The distinction between contrib and non-free is not informative because
it's not based on what would be a sensible division from a user
perspective.  The distinction between contrib and non-free is purely
legal.  contrib contains software that's redistributable in its entirety
under the DFSG; non-free contains software that is not, in part or in
whole.  That's basically it; that's the whole of the distinction, and
attempting to read more into it than that is going to lead people astray.

> For instance, the seaview package went from main to non-free when it
> gained the possibility to do some kind of phylogenetic analysis, and if
> one would remove this function, the resulting program would still be
> completely functional and would be an improvement compared to the last
> free version.

This is just because the granularity of our ability to divide things
between archives is the package level.  We can't divide things at any
lower level than that, so each package has to be declared DFSG-free or not
in its entirety.

If you separated out the phylogenetic analysis into a separate package,
then we would be able to divide the software properly.  (I realize that
this is probably difficult or you would have already done so.)

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87haw06cyh@windlord.stanford.edu

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

[Carsten Hey]

* Carl Fürstenberg [2012-04-28 03:31 +0200]:
> There has been an log struggle between the nodejs package and the node
> package, which is still unresolved (bug #611698 for example) And I
> wonder now what the future should look like.

In short I think that there is only one sane solution to this and that
the way to reach this solution is to ask the tech-ctte for a decision.


This is the second thread about this topic on -devel, the first one was
in November 2011.  In both threads and in some smaller ones, people
basically claimed things like (incomplete list):
  * node is older and nodejs should have checked the binary name
  * first come first server
  * nodejs is used as node in the shebang line
  * my node is more widely used than yours (which node is meant depends
on the year)
  * node is a daemon and there it does not matter what name it uses
  * one of them should use the binary name node
  * none should use the binary name node if there is no consensus
  * let the user decide via debconf
  * users from either group would complain if they need to use a name
other than node
  * policy is wrong, packages should conflict
  * conflicts would be wrong

Nowadays, the popcon stats for both packages strongly suggest that most
of node's user are users that wanted to install node.js and did not
remove the node package after noticing that it is not what they
expected.

Given that node is a rarely used daemon and that nodejs is a widely used
language, I think that nodejs should get the binary name node; but due
to the non-responsiveness of node's maintainers I think this might be
a case where involving the tech-ctte would help.

node's maintainers don't participate in such discussions in a reasonable
and timely manner, for example the RC bug had no action for months
despite the patch and nobody ever explained what exactly the problem of
a changed binary name for a daemon would be (node can be used
interactively, but it is not supposed to be used that way and those
users that do would be able to set up an alias anyway).  The first
answer from one of the uploaders was sent nearly a year after nodesjs'
maintainer asked about this issue on the maintainer's list (back then he
didn't seem to notice that those who answered were unrelated to the node
package).  The subject of the -devel thread last year "Is anyone
maintaining (the ham radio tool) node?" speaks for itself.

I assume all of node's uploaders did great work on many ham related
packages, but all that the two uploaders that replied to this issue
during the last two years did related to the node package is that they
also replied to the "Call for debian hamradio developers pool" from
node's actual but now retired maintainer who then added them as
uploaders.  Only Hamish, who did not respond to this issue, uploaded
node once in 2005, the others did never do any upload.  The responses
from the other two uploaders were essentially "please report a bug"
(although this was already done) by one; and "... then no package should
get the name" and in one mail "this patch needs to be tested by someone
who runs node and nodejs" by the other.


Regards
Carsten


-- 
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/20120430230711.gb17...@furrball.stateful.de

Bug#670984: ITP: libphidget -- Phidgets runtime library

[Jonathan McCrohan]

Package: wnpp
Severity: wishlist
Owner: Jonathan McCrohan 

* Package name: libphidget
  Version : 2.1.8.20120216
  Upstream Author : Phidgets Inc. 
* URL : http://www.phidgets.com/
* License : LGPL-3
  Programming Lang: C
  Description : Phidgets runtime library

Phidgets are a set of "plug and play" building blocks for low cost USB sensing
and control from your PC. All the USB complexity is taken care of by the robust
libphidget API.

Note: This package is *not* related to martin f. krafft's libphidgets library
which was previously in the archive.



-- 
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/20120501010014.3095.87595.report...@lambda.dereenigne.org

Re: switching from exim to postfix

[Chris Knadle]

On Monday, April 30, 2012 06:14:19, Riku Voipio wrote:
> On Sat, Apr 28, 2012 at 07:12:42PM -0700, Russ Allbery wrote:
...
> > There's nothing particularly wrong with Exim; it works just fine.
> 
> Exim in 2012 not supporting 8BITMIME and thus being the last Major MTA
> forcing quoted-printable conversions to make emails "7bit clean" is quite
> horribly wrong.

I think it would be useful to describe what issue(s) there are concerning 
8BITMIME and why this is important.  I've found some information [1] about 
this, but it isn't clear what problems are actially *caused* by the lack of 
8BITMIME support by default in Exim.  Is it just slow sending of outbound 
attachments?

> Debian is the main source of Exim installs in internet, it is also our
> fault. According to one old stat, 34% of mx records were exim, most
> probably almost all simply because it came by default in debian and it was
> "good enough" so people didnt' switch away from it.

The quoted 2010 survey [2] showed Exim was the most popular MTA (which I found 
surprising), deployment of Exim growing just slightly faster than Postfix, and 
everything else falling in popularity.  I don't know how one would verify (or 
dispute) the claim that Debian was the main source of Exim installs, and I'm 
not sure that's a "problem" that needs fixing.  (Also if you look more closely 
at the survey, ~55% of responding MTAs didn't identify themselves and are thus 
not counted in the statistics, which is a potential wide margin of error.)

> So yes, switching to postfix by default  would reduce the workload of email
> servers around the globe (no need to burn cpu cycles and thus co2 to
> convert emails to quoted-printable).

The statistics quoted showed that Exim was most popular, so wouldn't switching 
to Postfix by default actually be more CPU costly than the reverse?  :-/  [I'm 
not saying you're wrong, just that I don't see the logic in the argument.]




I administer both Postfix and Exim and greatly prefer Exim (specifically 
exim4-daemon-heavy and using a single config file), but I wouldn't mind if the 
default were Postifx.  Whatever the default MTA is should IMHO be whatever DDs 
supporting Debian think is the most supportable and "the best default".

I've likewise often wondered if a low-resource MTA like DMA or ssmtp could be 
the default MTA for Desktop installs (and I've occasionally tried them), but 
as has been discussed there seem to be some issues with the idea.  In my case 
for Desktops I want the local MTA to be able to handle sending local outbound 
mail to a server via port 587 over TLS with authentication, to retry sending 
at increasing time intervals, using a "queue runner" but without a daemon 
listening, and to notify the sender on a permanent failure.  Thusfar I've only 
been able to find all of that in a full-fledged MTA.



[1] http://cr.yp.to/smtp/8bitmime.html

[2] http://www.securityspace.com/s_survey/data/man.201007/mxsurvey.html

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


signature.asc
Description: This is a digitally signed message part.