Re: Bug#617999: Please include link to general info in each lists page

[Alexander Wirt]

Michelle Konzack schrieb am Thursday, den 17. March 2011:

> Hello Andrei Popescu and Listmasters,
> 
> it would be nice, if  could implement an autoresponder
> for peoles sending messages to lists without being subscribed.
Eh no. Autoresponder are a plague. 

Alex


-- 
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/20110318061041.ga28...@lisa.snow-crash.org

Re: Speeding up dpkg, a proposal

[Henrique de Moraes Holschuh]

On Fri, 18 Mar 2011, Russell Coker wrote:
> On Fri, 18 Mar 2011, Goswin von Brederlow  wrote:
> > > On a machine with lots of RAM (== disk cache...) and high I/O load, you 
> > > don't want to do a (global!) sync().  This can totally kill the machine
> > > for  20min or more and is a big no go.
> > > 
> > > -- vbi
> > 
> > Then don't use the option. It should definetly be an option:
> 
> It's a pity that there is no kernel support for synching one filesystem (or 
> maybe a few filesystems).

It is being implemented right now, actually...  Maybe it will be in 2.6.39.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20110318013625.ga6...@khazad-dum.debian.net

Bug#618737: ITP: libcrypt-nettle-perl -- Perl bindings for the Nettle cryptographic library

[Daniel Kahn Gillmor]

Package: wnpp
Severity: wishlist
Owner: Daniel Kahn Gillmor 

* Package name: libcrypt-nettle-perl
  Version : 0.1
  Upstream Author : Daniel Kahn Gillmor 
* URL : http://search.cpan.org/dist/Crypt-Nettle/
* License : GPL
  Programming Lang: C, Perl
  Description : Perl bindings for the Nettle cryptographic library

 Crypt::Nettle provides object-style bindings to libnettle and
 libhogweed for Perl.
 .
 It supports a wide range of message digests (Crypt::Nettle::Hash),
 symmetric encryption and decryption (Crypt::Nettle::Cipher), random
 number generation (Crypt::Nettle::Yarrow), and public-key crypto
 (Crypt::Nettle::RSA).



-- 
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/20110318010326.2885.240.reportbug@localhost.localdomain

Re: Bug#617999: Please include link to general info in each lists page

[Michelle Konzack]

Hello Lisandro Damián Nicanor Pérez Meyer,

Am 2011-03-17 20:27:57, hacktest Du folgendes herunter:
> On Thursday 17 March 2011 20:02:31 Michelle Konzack wrote:
> > But I do not mean Auto-Subscribe.
> Neither me, sorry for not being clear. I meant that people tend to subscribe 
> on recibing such mails.

OK  ;-)

> Kinds regards, Lisandro.

Thanks, Greetings and nice Day/Evening
Michelle Konzack

-- 
# Debian GNU/Linux Consultant ##
   Development of Intranet and Embedded Systems with Debian GNU/Linux

itsystems@tdnet France EURL   itsystems@tdnet UG (limited liability)
Owner Michelle KonzackOwner Michelle Konzack

Apt. 917 (homeoffice)
50, rue de Soultz Kinzigstraße 17
67100 Strasbourg/France   77694 Kehl/Germany
Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil
Tel: +33-9-52705884 fix

  
 

Jabber linux4miche...@jabber.ccc.de
ICQ#328449886

Linux-User #280138 with the Linux Counter, http://counter.li.org/


signature.pgp
Description: Digital signature

Re: Speeding up dpkg, a proposal

[Olaf van der Spek]

On Fri, Mar 18, 2011 at 12:11 AM, Russell Coker  wrote:
>> Then don't use the option. It should definetly be an option:
>
> It's a pity that there is no kernel support for synching one filesystem (or
> maybe a few filesystems).

That'd be only a partial work around. Even with a single fs one big
sync can be bad.

> I recently had a situation where I was doing a backup to a USB flash device
> and I decided to install some Debian packages.  The sync() didn't complete
> until the backup completed because the write-back buffers were never empty!

Didn't dpkg stop using sync?

Olaf


--
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/AANLkTi=sjgv2n_otcrgymw8zvqo0pgd9zz_1+dquu...@mail.gmail.com

Re: Bug#617999: Please include link to general info in each lists page

[Lisandro Damián Nicanor Pérez Meyer]

On Thursday 17 March 2011 20:02:31 Michelle Konzack wrote:
> Am 2011-03-17 19:15:45, schrieb Lisandro Damián Nicanor Pérez Meyer:
> > Just as a bit of extra information, we have done this (although manually)
> > in a couple of very used lists with nice success (people getting
> > subscribed and sometimes becoming real active).
> > 
> > Of course, not everyone will do it, but I think it has helped a lot.
> 
> But I do not mean Auto-Subscribe.

Neither me, sorry for not being clear. I meant that people tend to subscribe 
on recibing such mails.

Kinds regards, Lisandro.

-- 
I am two fools, I know, for loving, and for saying so.
  John Donne

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Speeding up dpkg, a proposal

[Russell Coker]

On Fri, 18 Mar 2011, Goswin von Brederlow  wrote:
> > On a machine with lots of RAM (== disk cache...) and high I/O load, you 
> > don't want to do a (global!) sync().  This can totally kill the machine
> > for  20min or more and is a big no go.
> > 
> > -- vbi
> 
> Then don't use the option. It should definetly be an option:

It's a pity that there is no kernel support for synching one filesystem (or 
maybe a few filesystems).

I recently had a situation where I was doing a backup to a USB flash device 
and I decided to install some Debian packages.  The sync() didn't complete 
until the backup completed because the write-back buffers were never empty!

If dpkg had only sync'd the filesystems used for Debian files (IE ones on the 
hard drive) then the package install would have taken a fraction of the time 
and I could have used the programs in question while the backup was running.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
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/201103181011.08741.russ...@coker.com.au

Re: Bug#617999: Please include link to general info in each lists page

[Michelle Konzack]

Am 2011-03-17 19:15:45, schrieb Lisandro Damián Nicanor Pérez Meyer:
> Just as a bit of extra information, we have done this (although manually) in 
> a 
> couple of very used lists with nice success (people getting subscribed and 
> sometimes becoming real active).
> 
> Of course, not everyone will do it, but I think it has helped a lot.

But I do not mean Auto-Subscribe.

I do not like to become auto-subscribed with  my  Business-E-Mail  which
send all messages (only Debian would send 1000 messages to my smartphone
per day) to my Smart-Phone.

> Kinds regards, Lisandro.

Thanks, Greetings and nice Day/Evening
Michelle Konzack

-- 
# Debian GNU/Linux Consultant ##
   Development of Intranet and Embedded Systems with Debian GNU/Linux

itsystems@tdnet France EURL   itsystems@tdnet UG (limited liability)
Owner Michelle KonzackOwner Michelle Konzack

Apt. 917 (homeoffice)
50, rue de Soultz Kinzigstraße 17
67100 Strasbourg/France   77694 Kehl/Germany
Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil
Tel: +33-9-52705884 fix

  
 

Jabber linux4miche...@jabber.ccc.de

Linux-User #280138 with the Linux Counter, http://counter.li.org/


signature.pgp
Description: Digital signature

Re: Bug#617999: Please include link to general info in each lists page

[Lisandro Damián Nicanor Pérez Meyer]

On Thursday 17 March 2011 18:32:43 Michelle Konzack wrote:
> Hello Andrei Popescu and Listmasters,
> 
> it would be nice, if  could implement an autoresponder
> for peoles sending messages to lists without being subscribed.
> 
> This message should only send one time  per  year  and  contain  usefull
> links based on the mailinglist, the FAQ and the CoC.
> 
> Thanks, Greetings and nice Day/Evening
> Michelle Konzack

Just as a bit of extra information, we have done this (although manually) in a 
couple of very used lists with nice success (people getting subscribed and 
sometimes becoming real active).

Of course, not everyone will do it, but I think it has helped a lot.

Kinds regards, Lisandro.

-- 
9: Que es el "Explorador" de Windows
* El tipo que le roba las ideas a MacOs
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Best practice for cleaning autotools-generated files?

[Marcin Owsiany]

On Tue, Mar 15, 2011 at 10:29:57PM +, Marcin Owsiany wrote:
> How are others doing it?

Thanks for all the responses (I never expected to start such a big
discussion - it must have been a while since I last read debian-devel),
and especially for the pointer to dh-autoreconf. This looks like exactly
what I was looking for! I wish it was mentioned in the autotools-dev
README.

regards,
-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216


-- 
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/20110317213849.GJ9900@beczulka

Re: Bug#617999: Please include link to general info in each lists page

[Michelle Konzack]

Hello Andrei Popescu and Listmasters,

it would be nice, if  could implement an autoresponder
for peoles sending messages to lists without being subscribed.

This message should only send one time  per  year  and  contain  usefull
links based on the mailinglist, the FAQ and the CoC.

Thanks, Greetings and nice Day/Evening
Michelle Konzack

-- 
# Debian GNU/Linux Consultant ##
   Development of Intranet and Embedded Systems with Debian GNU/Linux

itsystems@tdnet France EURL   itsystems@tdnet UG (limited liability)
Owner Michelle KonzackOwner Michelle Konzack

Apt. 917 (homeoffice)
50, rue de Soultz Kinzigstraße 17
67100 Strasbourg/France   77694 Kehl/Germany
Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil
Tel: +33-9-52705884 fix

  
 

Jabber linux4miche...@jabber.ccc.de
ICQ#328449886

Linux-User #280138 with the Linux Counter, http://counter.li.org/


signature.pgp
Description: Digital signature

Re: Best practice for cleaning autotools-generated files?

[Russ Allbery]

Ian Jackson  writes:

> The design of autoconf is predicated on the idea that people who are
> building the package are given a portable configure as part of the
> source package, so there is no need to have good compatibility between
> configure.in and various versions of autoconf.

> I don't understand why the current autoconf maintainers have lost sight
> of this.  Perhaps it's because they're actually the automake maintainers
> who maybe never understood it.

They've drastically improved the compatibility between Autoconf releases
starting at around 2.59, so at this point unless you're using new features
you very rarely run into any trouble with being unable to rebuild
configure.  Automake and Libtool are similarly much more solid than they
used to be.

I used to have a lot of qualms about regenerating the files because so
many people used hacked versions or weird constructs that would be buggy
in some versions of the autotools, but this problem really has largely
gone away due to tons of hard work on the part of the Autoconf, Automake,
and Libtool maintainers.  I'm much more comfortable just regenerating the
files with the latest versions now.

-- 
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/878vwd4epu@windlord.stanford.edu

Re: Transitional packages with conffiles

[Goswin von Brederlow]

Ian Jackson  writes:

> Goswin von Brederlow writes ("Transitional packages with conffiles"):
>> Looking into the cause we discovered that the problem is that
>> dhcp3-client is now a transitional package that pulls in
>> isc-dhcp-client. The new package expects its config files in /etc/dhcp
>> while the old had /etc/dhcp3/. The changes made to the old config no
>> longer affect the new client.
>
> Well surely the question is: why are the files moved to a different
> directory ?  Why is the package renamed, even ?  Do we need to be able
> to co-install the old and new ISC DHCP clients ?!
>
> Ian.

That is a question with a specific answere for every single transition
and irelevant to the question about what to do in general.

But if you must know I think in this case it is to correct the mistake
made with dhcp v3 where the major version was added to the dir
name. Using /etc/dhcp3 for a v4 dhcp seems wrong.

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

Re: oops I sent a courtesy copy in violation of the code of conduct

[Michelle Konzack]

Hello Carsten Hey,

Am 2011-03-12 10:50:03, hacktest Du folgendes herunter:
> If a message I reply to contains a Mail-Followup-To: set, I use it.  If
> not, I guess if the person I reply to wants to receive a reply.  To
> prevent me to Cc: you, you need to explicitly set Mail-Followup-To: to
> the list.

Which is not supported by many MUAs expecialy on  Smartphones,  PDAs  or
MUAs Android which I use in my business.

Thanks, Greetings and nice Day/Evening
Michelle Konzack

-- 
# Debian GNU/Linux Consultant ##
   Development of Intranet and Embedded Systems with Debian GNU/Linux

itsystems@tdnet France EURL   itsystems@tdnet UG (limited liability)
Owner Michelle KonzackOwner Michelle Konzack

Apt. 917 (homeoffice)
50, rue de Soultz Kinzigstraße 17
67100 Strasbourg/France   77694 Kehl/Germany
Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil
Tel: +33-9-52705884 fix

  
 

Jabber linux4miche...@jabber.ccc.de
ICQ#328449886

Linux-User #280138 with the Linux Counter, http://counter.li.org/


signature.pgp
Description: Digital signature

Re: oops I sent a courtesy copy in violation of the code of conduct

[Michelle Konzack]

Hello Shachar Shemesh,

Am 2011-03-13 19:54:01, hacktest Du folgendes herunter:
> If I set "reply-to" to myself, the mail won't go to the list. If I
> set it to the list, it won't go to me. Either way, the desired
> effect isn't achieved.
> 
> Also, reply-to is the wrong tool for this job (this is NOT what it's
> for), as it prohibits distinction between replies to the list and
> reply to me.

If I remember right another discussion in the past about Reply-To: and
Mail-Followup-To: you can specify more then one E-Mail like

Reply-To: shac...@shemesh.biz, debian-devel@lists.debian.org
or
Mail-Followup-To: shac...@shemesh.biz, debian-devel@lists.debian.org

Note:   I am not subscribed to any Debian Lists except 
and on mailinglists which support "nomail",  it  is  REALY
annoying, if someone send me useless messages  of  several
100 kByte to my cell-phone.

If I have the need for list-help/infos I read it  from  an
archive, but my business E-Mail must  be  clean.  And  no,
filtering of messages is no option, because I get to  many
false-positives du to my customers which are On-List too.

Thanks, Greetings and nice Day/Evening
Michelle Konzack

-- 
# Debian GNU/Linux Consultant ##
   Development of Intranet and Embedded Systems with Debian GNU/Linux

itsystems@tdnet France EURL   itsystems@tdnet UG (limited liability)
Owner Michelle KonzackOwner Michelle Konzack

Apt. 917 (homeoffice)
50, rue de Soultz Kinzigstraße 17
67100 Strasbourg/France   77694 Kehl/Germany
Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil
Tel: +33-9-52705884 fix

  
 

Jabber linux4miche...@jabber.ccc.de
ICQ#328449886

Linux-User #280138 with the Linux Counter, http://counter.li.org/


signature.pgp
Description: Digital signature

Re: potential MBF: first alternate depends not available in main

[Goswin von Brederlow]

"Bernhard R. Link"  writes:

> * Goswin von Brederlow  [110316 01:24]:
>> I disagree. If non-free has a superior implementation of a package and
>> the user has non-free configured then it should prefer the non-free
>> package.
>
> Superiority is always a question of what metrics you start with.
> Not being able to fix bugs because of missing source code or missing
> licenses gives a very strong push into inferiority, at least it should
> for Debian users.
>
>   Bernhard R. Link

My metric here is clearly the functionality for the user.

If not having free (as in speech) source is a problem then do not add
non-free to your sources.list. That metric should not decide the order
of depends.

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

Re: quantification of cost of outdated dependencies

[Goswin von Brederlow]

Joey Hess  writes:

> I've been hearing a bit lately about removing dependencies that are no
> longer needed for stable upgrade paths. The most common reason seems
> that this will make apt need less memory[1].
>
> So then, someone must have measured the memory use. Unless this is a
> kind of premature optimation. But, I've not seen a citation of any such
> measurement. I can make a rough estimate: apt-cache stats suggests that
> the average dependency takes 29 bytes.
>
> If that estimate were right, then to save 100kb, which seems an easy
> minimum amount to care about, 3500 dependencies would have to be
> removed. On average, one package in ten would need to be modified.
>
> That's a lot of skull sweat. It's larger than all but the biggest
> transitions. It does not seem, to me, to be worthwhile to save 100 kb of
> ram. Perhaps others would disagree?
>
> But my estimate is *not* right. apt-get may show a RSS of 20 mb
> but 16 of that is mmaped cache files. So, removing a dependency probably
> saves closer to 0 bytes of memory than 20 bytes.

The mmaped chache file IS where the memory is spend. apt doesn't keep
the dependencies in memory and cache. It just mmapes the cache. But even
though that are files you still need the memory to swap in the data.

Also the dependency resolver needs to process the extra depends. I'm
certain I could construct you a case that has exponentially many nearly
solution that the resolve can only exclude at the end of a long chain.

> Where then is the savings? It's not in Packages file download time;
> pdiff optimizes that away. It's not Package file bloat on the mirrors
> or on disk; the compressed text of *all* Dependency lines takes only
> some 500 kb on-disk. The main bloat seems to be 6 mb used in
> pkgcache.bin, and some amount of CPU time spent by apt-get update to
> parse the dependencies and populate the file.

So 6 out of 16MB are depends. That is nearly 40%. How much of those are
obsolete?  1%, 10%, 50%?

> So, I've convinved myself this is probably a false optimisation.

I wouldn't jump to conclusions either way that fast.

Why not write little script that checks the Packages file for obsolete
depends. Simply remove all entries that are not available in squeeze
main. That shouldn't be to hard to script and should be a fair
approximation. Then feed that to apt and compare memory and runtime for
a few things.

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

Processed: Re: Bug#618473: general: Problems to handle NIS group names

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 618473 nfs-common
Bug #618473 [general] general: Problems to handle NIS group names
Bug reassigned from package 'general' to 'nfs-common'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
618473: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618473
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.130039451515991.transcr...@bugs.debian.org

Re: Speeding up dpkg, a proposal

[Goswin von Brederlow]

Adrian von Bidder  writes:

> On Wednesday 02 March 2011 17.02:11 Marius Vollmer wrote:
>> - Instead, we move all packages that are to be unpacked into
>>   half-installed / reinstreq before touching the first one, and put a
>>   big sync() right before carefully writing /var/lib/dpkg/status.
>
> You don't want to do this. While production systems usually are upgraded in 
> downtime windows (with less load), it is sometimes necessary to install some 
> package (tcpdump or whatever to diagnose problems...) while the system is 
> under high load. Especially when you're trying to find out why the machine 
> has a load of 20 and you can't afford to kill it...
>
> On a machine with lots of RAM (== disk cache...) and high I/O load, you 
> don't want to do a (global!) sync().  This can totally kill the machine for 
> 20min or more and is a big no go.
>
> -- vbi

Then don't use the option. It should definetly be an option:

sync / fs sync / fsync / sync only metadata / single sync at end / no sync at 
all

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/871v25a36z.fsf@frosties.localnet

Re: Speeding up dpkg, a proposal

[Goswin von Brederlow]

Marius Vollmer  writes:

> ext Chow Loong Jin  writes:
>
>> Could we somehow avoid using sync()? sync() syncs all mounted filesystems, 
>> which
>> isn't exactly very friendly when you have a few slow-syncing filesystems like
>> btrfs (or even NFS) mounted.
>
> Hmm, right.  We could keep a list of all files that need fsyncing, and
> then fsync them all just before writing the checkpoint.
>
> Half of that is already done (for the content of the packages), we would
> need to add it for the files in /var/lib/dpkg/, or we could just fsync
> the whole directory.
>
> But then again, I would argue that the sync() is actually necessary
> always, for correct semantics: You also want to sync everything that the
> postinst script has done before recording that a package is fully
> installed.

Except for chroots, the throw away after use kind, this realy doesn't
matter. If the system crashes at any point before the chroot is thrown
away then it just gets thrown away after boot and the whole operation is
restarted from scratch.

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/8762rha3ax.fsf@frosties.localnet

Bug#618473: general: Problems to handle NIS group names

[Arthur de Jong]

reassign nfs-common
thanks

On Tue, 2011-03-15 at 15:10 +0100, Christian Andretzky wrote:
> I've really no idea, which package(s) are responsible for this problem.

Reassigning to nfs-common because that seems to be the most likely
candidate (assuming autofs is used to mount nfs filesystems).

> In my log files I can find messages like:
> 
> Mar 15 14:56:09 oedibus automount[1983]: set_tsd_user_vars: failed to get 
> group info from getgrgid_r
> 
> As the result the output from ls command looks like
> 
> ...
> drwx--  21 saadi   12000  4096 19. Nov 12:22 saadi
> ...
> 
> The output of 'ypcat group' shows the correct group names.
> 
> If I dont use autofs and mount the filesystem manual using 'mount',
> the same problem happens.

It would really be hulpful if you could post more
information. /etc/nsswitch.conf, /etc/auto.master, nfs mount settings
(nfs version), etc come to mind.

I know nfs4 uses and idmap that has caused issues in the past if the
naming service is not available during boot (see e.g. #500778).

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


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

Re: Best practice for cleaning autotools-generated files?

[Ian Jackson]

Tollef Fog Heen writes ("Re: Best practice for cleaning autotools-generated 
files?"):
> | Adam Borowski writes ("Re: Best practice for cleaning autotools-generated 
> files?"):
> | No, it doesn't work if the auto* on the system is not compatible with
> | the auto* in the package, which happens very often.  It doesn't happen
> | often to people who are building packages for Debian courgette /on/
> | Debian courgette.  But it happens to Debian's users and downstreams a
> | lot.
> 
> (I disagree with it happening very often, but that's a minor point.)
> 
> If you can't regenerate the autofoo files with the autofoo that we ship
> we're not actually shipping source any more than shipping preprocessed C
> source files would be considered shipping source.  Any such
> incompatibility is a fairly serious bug.

I agree with that.  But Debian source packages are not only built on
the identical same environment that we build them.

We should be providing source packages which are maximally useful to
users of related distros, whether that's derivatives with different
versions of autoconf, or different versions of Debian.


> | The design of autoconf is predicated on the idea that people who are
> | building the package are given a portable configure as part of the
> | source package, so there is no need to have good compatibility between
> | configure.in and various versions of autoconf.
> 
> This might have been true once upon a time.  It's becoming less and less
> common with many people building VCS-es instead of using a tarball.

The _design_ is still predicated on this assumption.  The autotools
maintainers' behaviour with respect to backward compatibility is still
predicated on this assumption.

What has happened is simply that the assumption is becoming false.  
I agree that many people nowadays do not provide autotools output as
part of their vcs trees or sometimes even tarballs.  They do this
because the autotools maintainers recommend it, and because of threads
like this one.

But those people are doing it wrong.

Either (a) autotools needs to be redesigned so that it no longer
assumes that the autotools output form part of the source code which
is distributed to people who want to modify and build the package, or
(b) we need to make that assumption true.

(a) is obviously too hard.  (b) is very simple.


> Personally, I wish I could treat configure and its siblings with the
> same amount of attention I treat gcc's intermediate files with: none,
> unless I need to debug something weird.

The analogy is completely flawed.

One can compile source code for gcc with pretty much any version of
gcc; whereas, autotools source code can only reliably be compiled with
the specific version of autotools for which it is intended.

gcc's intermediate files do not work except on the exact system where
they are built; whereas, autotools output files are highly portable
aned can be used unaltered anywhere regardless of processor, autotools
version, or even the entire build and target operating systems.


> | I think this is a highly unlikely scenario.  No-one is suggesting
> | removing configure.in et al and there is no plausible mechanism that
> | might result in it vanishing.  Since often the Debian packaging is
> | going to involve editing auto* input, the buildability from scratch
> | will be tested on every new upstream version.
> 
> We have to ship _source_ and the necessary tools to get from source to
> whatever ends up in binaries. It's not ok to ship configure scripts we
> can't rebuild any more than shipping .jar files we can't rebuild or
> PDF-es we can't rebuild. People go to great lengths to rebuild
> documentation and similar that upstream ship, and I see no reason we
> should not go to the same lengths to rebuild the build system.

Did you read what I wrote ?  Let me say it again a few times:

No-one is suggesting removing configure.in et al.

I agree that we must continue to ship autotools input.

Yes, the source code input to autotools must continue to be in all vcs
repositories and source packages.

Indeed, the autotools input must not be deleted.


BUT we should ALSO provide the autotools-generated files.

The reason why people go to these great lengths to rebuild
documentation is to make sure that it can be done.  This does not
apply to autoconf output.

As I say, it will in practice be essential to rerun the autotools
when we package every upstream release anyway.  So there is very low
risk that we will ship package where autotools can't be rerun using
the tools we're shipping.


Ian.


-- 
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/19842.23318.483133.267...@chiark.greenend.org.uk

Re: Best practice for cleaning autotools-generated files?

[Bernhard R. Link]

* Peter Samuelson  [110317 19:12]:
> If there _is_ some risk or perception of risk, that re-auto-tooling a
> package might break it, then we're not really providing the FSF's
> freedom 1.  We're then saying "This is free software; downstream users
> can modify the .c files, you can modify the .h files, you can modify
> the manpages, but you'll want to try and avoid modifying any
> Makefile.am or configure.ac files, or who knows what might happen."

It's not higher than the risk that a program might no longer work with
a newer version of some library used. And still we have no
build-dependencies that forbid all future versions and we do not rebuild
everything every time there is a new build system.

Changing something in the source can always have some ill effects.
Editing a .c or .h file can also make a program non-functional, you have
to know what you do.

> (Side note: even if automake lets you change things without editing
> Makefile.am, there are limits.  What if you refactor to add or
> remove a source file?  I think Freedom 1 applies to those types of
> edits as much as to trivial typo fixes.)

Removing it easy, that is simply some _OBJECTS variable. Adding can be
more complex, but in easy setting it is just the same.

> Better to take on this risk, such as it is, by building from source
> every time.  It's the only way to know we _can_.

While I'am all in favour of failing early instead of hiding things, the
question is: does this make sense?

> There's also the added convenience that if you always build from
> source, downstream users who patch the autotools files won't have to
> wonder how to rebuild them.

I'd rather say rebuilding them puts additional pressure on downstream
users to make sure it still works, as they will not usually synchronize
all those packages in the same way.

> That's sort of a side benefit, but
> can be important (say, if the downstream patch-er happens to be the
> Debian Security Team).

I think security uploads are a big argument against recreating the
build system at every build.

Security patches should be minimal, changes to the build system are
usually a big no-go there and having minimal and thus easier to review
changes is much important than then suddenly having to also patch some
minor build-system incompatiblity.

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/20110317191157.ga24...@pcpool00.mathematik.uni-freiburg.de

Re: Best practice for cleaning autotools-generated files?

[Ian Jackson]

Peter Samuelson writes ("Re: Best practice for cleaning autotools-generated 
files?"):
> Better to take on this risk, such as it is, by building from source
> every time.  It's the only way to know we _can_.  And fix whatever
> issues come up.  Even though it's not actually spelled out in the DFSG,
> I see it as a maintainer responsibility to ensure that our software
> builds from source on a Debian platform, even if you patch it, assuming
> your patch itself isn't buggy.

This is true and it would be fine to insist that our own builds of our
own packages on the intended distro always rebuilt the autotools
output.

But that doesn't mean that we should hobble the users who _aren't_
doing that, by deleting the files they need to achieve their
objectives without undue hassle.

> I see it as a question of, as the FSF puts it, "the freedom to study
> how the program works, and change it to make it do what you wish
> (freedom 1)."  A lot of us believe that's one of the main points of
> Free Software in the first place.  Access to source code isn't _just_
> to let you build on armel if the vendor only cares about i386.
> 
> If there _is_ some risk or perception of risk, that re-auto-tooling a
> package might break it, then we're not really providing the FSF's
> freedom 1.  [...]

That rerunning the autotools is sometimes difficult and sometimes
breaks things (because the attempt deletes the working output files)
is not a "perception", it is a fact.

Deleting the working autotools output files does nothing to help this
situation.  It just puts the user who only wanted to edit a .c file in
the same bad position as one who wants to add a new .c file or a new
autoconf test.

Ian.


-- 
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/19842.22419.134372.778...@chiark.greenend.org.uk

Re: Best practice for cleaning autotools-generated files?

[Peter Samuelson]

[Bernhard R. Link]
> It usually also make sense to think twice before patching build
> systems.  Especially automake is very good in allowing many things
> changed without having to patch something. (There are some cases
> where patches are necessary, but there are also enough cases where
> patching can be easily avoided).

I see it as a question of, as the FSF puts it, "the freedom to study
how the program works, and change it to make it do what you wish
(freedom 1)."  A lot of us believe that's one of the main points of
Free Software in the first place.  Access to source code isn't _just_
to let you build on armel if the vendor only cares about i386.

If there _is_ some risk or perception of risk, that re-auto-tooling a
package might break it, then we're not really providing the FSF's
freedom 1.  We're then saying "This is free software; downstream users
can modify the .c files, you can modify the .h files, you can modify
the manpages, but you'll want to try and avoid modifying any
Makefile.am or configure.ac files, or who knows what might happen."

(Side note: even if automake lets you change things without editing
Makefile.am, there are limits.  What if you refactor to add or
remove a source file?  I think Freedom 1 applies to those types of
edits as much as to trivial typo fixes.)

Better to take on this risk, such as it is, by building from source
every time.  It's the only way to know we _can_.  And fix whatever
issues come up.  Even though it's not actually spelled out in the DFSG,
I see it as a maintainer responsibility to ensure that our software
builds from source on a Debian platform, even if you patch it, assuming
your patch itself isn't buggy.

There's also the added convenience that if you always build from
source, downstream users who patch the autotools files won't have to
wonder how to rebuild them.  'sudo apt-get build-dep packagename' and
'dpkg-buildpackage' will Just Work.  That's sort of a side benefit, but
can be important (say, if the downstream patch-er happens to be the
Debian Security Team).
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.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/20110317175627.gf10...@p12n.org

Re: Best practice for cleaning autotools-generated files?

[Tollef Fog Heen]

]] Ian Jackson 

Hi,

| Adam Borowski writes ("Re: Best practice for cleaning autotools-generated 
files?"):
| > Ie, consistently with all regular commands in a makefile: if a source file
| > has been modified, everything that is generated from that source needs to be
| > rebuilt.
| > 
| > Which works just fine if timestamps haven't been trampled over.
| 
| No, it doesn't work if the auto* on the system is not compatible with
| the auto* in the package, which happens very often.  It doesn't happen
| often to people who are building packages for Debian courgette /on/
| Debian courgette.  But it happens to Debian's users and downstreams a
| lot.

(I disagree with it happening very often, but that's a minor point.)

If you can't regenerate the autofoo files with the autofoo that we ship
we're not actually shipping source any more than shipping preprocessed C
source files would be considered shipping source.  Any such
incompatibility is a fairly serious bug.

| The design of autoconf is predicated on the idea that people who are
| building the package are given a portable configure as part of the
| source package, so there is no need to have good compatibility between
| configure.in and various versions of autoconf.

This might have been true once upon a time.  It's becoming less and less
common with many people building VCS-es instead of using a tarball.

Personally, I wish I could treat configure and its siblings with the
same amount of attention I treat gcc's intermediate files with: none,
unless I need to debug something weird.

| > You're likely to end up shipping things without source, obviously failing
| > DFSG and being in a breach of the GPL.  There's no way you can argue for
| > ./configure to be a preferred form for modification...
| 
| I think this is a highly unlikely scenario.  No-one is suggesting
| removing configure.in et al and there is no plausible mechanism that
| might result in it vanishing.  Since often the Debian packaging is
| going to involve editing auto* input, the buildability from scratch
| will be tested on every new upstream version.

We have to ship _source_ and the necessary tools to get from source to
whatever ends up in binaries. It's not ok to ship configure scripts we
can't rebuild any more than shipping .jar files we can't rebuild or
PDF-es we can't rebuild. People go to great lengths to rebuild
documentation and similar that upstream ship, and I see no reason we
should not go to the same lengths to rebuild the build system.

| Also, I could argue that the configure.in without configure is
| likewise not the preferred form for modification.  The question surely
| is "preferred by who".  I think that the preferred form for
| modification of "ls" includes coreutils's Makefile, Makefile.in and
| configure as well as its Makefile.am and configure.in etc.

I think the preferred form is whatever is in its git (or whatever VCS
they are using) repository.

Regards,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87aagtlm6l@qurzaw.varnish-software.com

Re: Best practice for cleaning autotools-generated files?

[Ian Jackson]

Adam Borowski writes ("Re: Best practice for cleaning autotools-generated 
files?"):
> Ie, consistently with all regular commands in a makefile: if a source file
> has been modified, everything that is generated from that source needs to be
> rebuilt.
> 
> Which works just fine if timestamps haven't been trampled over.

No, it doesn't work if the auto* on the system is not compatible with
the auto* in the package, which happens very often.  It doesn't happen
often to people who are building packages for Debian courgette /on/
Debian courgette.  But it happens to Debian's users and downstreams a
lot.

Furthermore when the auto* incompatibility strikes, it can be a very
hard hole to dig out of.  If there is some problem with rejected
patches or timestamps, but a working and compatible auto* setup, it is
trivial to rerun auto* to fix the problem.

The design of autoconf is predicated on the idea that people who are
building the package are given a portable configure as part of the
source package, so there is no need to have good compatibility between
configure.in and various versions of autoconf.

I don't understand why the current autoconf maintainers have lost
sight of this.  Perhaps it's because they're actually the automake
maintainers who maybe never understood it.

> AM_MAINTAINER_MODE is also strongly depreciated and discouraged.

It is discouraged and deprecated (not depreciated!) by the autotools
maintainers.  But the autotools maintainers are wrong.

>  Using it, you are effectively patching compiler output rather than
> source.

I'm not sure what you mean by "you are patching".  Automatic systems
for managing source code will indeed edit compiled output as well as
input, but with AM_MAINTAINER_MODE no human ever needs to edit
compiled output.

There is nothing wrong with automated systems such as version control
systems and patch systems including representations of changes to
generated files, provided the generated files are portable.

> You're likely to end up shipping things without source, obviously failing
> DFSG and being in a breach of the GPL.  There's no way you can argue for
> ./configure to be a preferred form for modification...

I think this is a highly unlikely scenario.  No-one is suggesting
removing configure.in et al and there is no plausible mechanism that
might result in it vanishing.  Since often the Debian packaging is
going to involve editing auto* input, the buildability from scratch
will be tested on every new upstream version.

Also, I could argue that the configure.in without configure is
likewise not the preferred form for modification.  The question surely
is "preferred by who".  I think that the preferred form for
modification of "ls" includes coreutils's Makefile, Makefile.in and
configure as well as its Makefile.am and configure.in etc.

Ian.


-- 
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/19842.11967.790255.179...@chiark.greenend.org.uk

Re: Best practice for cleaning autotools-generated files?

[Andreas Tille]

On Thu, Mar 17, 2011 at 11:01:44AM -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 17 Mar 2011, Andreas Tille wrote:
> > Assume please the following:
> > 
> >   1. Unpack upstream source, copy debian/ dir into it
> >   2. make -f debian/rules clean
> 
> You should have looked for a get-orig-sources target, first.  You just
> skipped any orig source conditioning the maintainer had to do.

I assumed I'm the maintainer (and have either written such a target or
know about it)
 
> Let's assume none was required.

Yes.  If it is assumed anyway in most cases it is to just change the
upstream source for whatever reason.  In this case I would also fix the
issues I have mentioned.  So assuming none is required is the only case
we really need to discuss here.
 
> >   3. store the resulting build dir into a temporary dir say dir1
> >   4. debuild
> >   5. store a backup of your *.dsc + *diff*
> >   6. make -f debian/rules clean
> >   7. Now compare the build dir with dir1
> >   --> you get a diff (for whatever reason there are several
> >   examples - most of them because of broken clean targets
> >   which do not clean up autogenerated files)
> 
> The packaging is broken, maybe in a minor way.

I agree that it is minor.  However, I try to care also for minor issues.

> It depends on whether it
> retools properly and will present the same differences no matter how many
> times you rebuild, or do a different thing at every rebuild.

It does different things between the first and all other builds (while
the later will probably not lead to remarkable changes any more - except
if some autogenerated files might contain time stamps inside the code).
 
> > I would consider this a situation which should be avoided if possible.
> 
> Sure, but it has nothing to do with using non-reversible transformations
> during the build (such as removing files or retooling in-place).
> 
> It has everything to do with not doing a througout job in "debian/rules
> clean", and not fixing/working around bugs in the upstream build system.

Yes.  You can make backup copies of all affected files and put them
right into place inside your clean target.  That's perfectly doable but
is this really worth the effort?  I would prefer to fix the upstream
tarball in a way that these stupid cases will not happen (if such a
change is easily doable and in cases were upstream just has forgotten
to call make distclean it is).

So the question boils down to:  Fixing up upstream cruft in
get-orig-source or in clean target?

Kind regards

Andreas.

-- 
http://fam-tille.de


-- 
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/20110317143357.gb10...@an3as.eu

Bug#618674: ITP: sagan-rules -- Real-time System & Event Log Monitoring System [rules]

[Pierre Chifflier]

Package: wnpp
Severity: wishlist
Owner: Pierre Chifflier 

* Package name: sagan-rules
  Version : 10212010-r1
  Upstream Author : Champ Clark III 
* URL : http://sagan.softwink.com/
* License : BSD
  Programming Lang: other (text files)
  Description : Real-time System & Event Log Monitoring System [rules]

 Sagan is a multi-threaded, real time system- and event-log monitoring
 system, but with a twist. Sagan uses a “Snort” like rule set for
 detecting malicious events happening on your network and/or computer
 systems.
 If Sagan detects a potentially bad event, that event can be stored to a
 Snort database (MySQL/PostgreSQL), send it to a SIEM tool like Prelude,
 or send an email.
 .
 This package provides the rules for Sagan.



--
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/20110317140905.26473.35592.report...@piche2.inl.fr

Re: Best practice for cleaning autotools-generated files?

[Henrique de Moraes Holschuh]

On Thu, 17 Mar 2011, Sean Finney wrote:
> autofoo stuff examines timestamps on various files, so it's possible
> that if configure gets patched before configure.ac, and
> AM_MAINTAINER_MODE is set to a specific value, that ./configure ends up
> wanting to regenerate ./configure at build time.  double fail.
> 
> > > So Makefile rules can then re-run auto* tools at build time and you
> > > lost the benefit you want to have.
> > 
> > Makefile rules should not rerun auto* stuff at build time.
> 
> they will if AM_MAINTAINER_MODE is being used, in some cases.

It is the other way around.  UNLESS you are using AM_MAINTAINER_MODE, it
*will* attempt to regenerate itself due to timestamp skews or file
modifications.  It will use the "missing" script if it cannot find the tools
it wants (and "missing" will touch things to solve the timestamp skew).

AM_MAINTAINER_MODE is used to DISABLE the timestamp checking in the first
place, so that no retooling is done even if the user has some random version
of the autotools installed.

It is also worth noticing that this is an automake macro.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20110317140750.gd1...@khazad-dum.debian.net

Re: Best practice for cleaning autotools-generated files?

[Henrique de Moraes Holschuh]

On Thu, 17 Mar 2011, Andreas Tille wrote:
> Assume please the following:
> 
>   1. Unpack upstream source, copy debian/ dir into it
>   2. make -f debian/rules clean

You should have looked for a get-orig-sources target, first.  You just
skipped any orig source conditioning the maintainer had to do.

Let's assume none was required.

>   3. store the resulting build dir into a temporary dir say dir1
>   4. debuild
>   5. store a backup of your *.dsc + *diff*
>   6. make -f debian/rules clean
>   7. Now compare the build dir with dir1
>   --> you get a diff (for whatever reason there are several
>   examples - most of them because of broken clean targets
>   which do not clean up autogenerated files)

The packaging is broken, maybe in a minor way.  It depends on whether it
retools properly and will present the same differences no matter how many
times you rebuild, or do a different thing at every rebuild.

> I would consider this a situation which should be avoided if possible.

Sure, but it has nothing to do with using non-reversible transformations
during the build (such as removing files or retooling in-place).

It has everything to do with not doing a througout job in "debian/rules
clean", and not fixing/working around bugs in the upstream build system.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20110317140144.gc1...@khazad-dum.debian.net

Re: Best practice for cleaning autotools-generated files?

[Henrique de Moraes Holschuh]

On Thu, 17 Mar 2011, Andreas Tille wrote:
> On Thu, Mar 17, 2011 at 04:09:25PM +0800, Paul Wise wrote:
> > Agreed. That would usually not be something that would cause enough
> > problems for a new tar.gz to be warranted though.
> 
> I just accept your opinion that repackaging is not warranted and I did
> not in the past - but I was never really sure whether this is really
> reasonable.  I'm somehow missing *clear* rules when to rebuild the orig
> tarball and when not.

If it breaks something, it violates the DFSG, or it increases the chances of
massively confusing someone or breaking a security build/NMU/binNMU, rebuild
it (and *document* it properly).

Otherwise, don't.

It is a bit simpleminded, but it has worked for me for 15 years, so far.

For a while I had "debian/rules clean" cleaning up some of the mess more
likely to show up, and it was simple enough for anyone to understand how it
interacted with the build at first glance... but it was certainly NOT simple
for people to grasp how to regenerate the list of supposed-to-be-executable
files and supposed-to-be-deleted-on-sight files.  But all my upstreams got
better at rolling release tarballs, and after a couple years without any
need to use any such fixups, I dropped that machinery in the name of
simplicity.

Now that we have get-orig-source targets, such heavy-handed cleanups even
have a place to live that is standard and fully documented.

> > > If you try to build the source twice in a row you get a diff to the
> > > original tarball.  This should be avoided.
> > 
> > I would just have `debian/rules clean` remove the (re-)generated files
> > as per usual.
> 
> I understand the requirement to build a package "twice in a row" as it
> was discussed here[1] (including link to policy) that the removal of
> those files is not OK.

You can have packages that build properly n times in a row, for n > 0,
without messing with the debian diff, even if you remove files in
debian/rules clean and do full retooling on every build.  Debian QA was
complaining of broken packaging that did not do that, and NOT of the removal
of the files themselves.

Note that any non-reversible transformation of the package source during
build IS against policy.  I cheerfully ignore that requirement as long as
the packaging is properly done (i.e. it not only rebuilds as many times in a
row as you want, it ALSO always rebuilds in the same way, INCLUDING in the
first time, and INCLUDING source package builds, not just binary packages).

I consider that policy requirement an artifact of dark times we've long left
behind.  As I said, I have never been presented with an usecase that
requires that policy of only allowing reversible transformations in the
first place, and I didn't have enough imagination to come up with one that
fit reality.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20110317134838.gb1...@khazad-dum.debian.net

Re: Best practice for cleaning autotools-generated files?

[Henrique de Moraes Holschuh]

On Thu, 17 Mar 2011, Paul Wise wrote:
> Does your autogen.sh script ever become anything more than calling
> autoreconf with some specific options?

Yes.  I think it was Cyrus IMAP that required -I in places where
autoreconf doesn't reach, so I called each tool separately.  Which is
obviously a problem in autoreconf.

> > 3. I always hook the debian package to retool on package build.  I have
> ...
> > 4. Just deal with the annoyance in the debian clean target, but do use
> ...
> > 5. Cheerfully ignore any purists complaining that debian/rules clean does
> >   not restore whatever crap was there upstream.
> 
> I generally don't bother with these unless I'm patching the autotools
> source files (configure.ac/Makefile.am). I'm increasingly being
> convinced that doing it in all autotools-based packages is a good
> idea.

If you get it right, and life for anyone doing an NMU suddenly is much
easier.  That's why I do it on all my packages, even if I don't have to
patch configure.ac or Makefile.am at the moment.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20110317130818.ga1...@khazad-dum.debian.net

Re: Best practice for cleaning autotools-generated files?

[Ian Jackson]

Sean Finney writes ("Re: Best practice for cleaning autotools-generated 
files?"):
> On Wed, 2011-03-16 at 16:36 +, Ian Jackson wrote:
> > That's fine, you patch the input, rerun the autofoobar stuff, and then
> > build the source package with diff.  If you're using a patch queue
> > system, or a vcs, you arrange for the autogenerated autofoobar output
> > changes to be committed along with the corresponding input change.
> 
> and then you end up with either (a) masses of changes to upstream files
> in your local branch which will cause merge conflicts (and
> aesthetically, ew, yuck.) or (b) a patch in your patch queue which will
> very likely not apply in the next upstream release.

Yes, you get some trivial-to-fix conflicts: you simply rerun
autofoobar and the affected files are fixed.

> autofoo stuff examines timestamps on various files, so it's possible
> that if configure gets patched before configure.ac, and
> AM_MAINTAINER_MODE is set to a specific value, that ./configure ends up
> wanting to regenerate ./configure at build time.  double fail.

The package should be configured so that this does not happen.

Ian.


-- 
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/19841.62614.539116.696...@chiark.greenend.org.uk

Re: Best practice for cleaning autotools-generated files?

[Andreas Tille]

On Thu, Mar 17, 2011 at 10:30:48AM +0100, Julien Cristau wrote:
> > The problem is that the regenerated files are not identical to the
> > original files and you simply get a diff which finally makes different
> > Debian source packages depending how often you start the build process.
> > 
> Err, no.  If debian/rules clean removes some files, they'll never show
> up in a diff anywhere.

Assume please the following:

  1. Unpack upstream source, copy debian/ dir into it
  2. make -f debian/rules clean
  3. store the resulting build dir into a temporary dir say dir1
  4. debuild
  5. store a backup of your *.dsc + *diff*
  6. make -f debian/rules clean
  7. Now compare the build dir with dir1
  --> you get a diff (for whatever reason there are several
  examples - most of them because of broken clean targets
  which do not clean up autogenerated files)
  8. debuild
  9. Now compare the backup of the *.dsc + *diff* with the
 current one - for sure they will feature a difference because
 you noticed the diff in 7.

Do you agree that there are cases where you get such a diff?

I would consider this a situation which should be avoided if possible.

Kind regards

  Andreas.

-- 
http://fam-tille.de


-- 
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/20110317105055.gg31...@an3as.eu

Re: Best practice for cleaning autotools-generated files?

[Adam Borowski]

On Thu, Mar 17, 2011 at 09:17:05AM +0100, Michael Biebl wrote:
> Am 17.03.2011 08:51, schrieb Sean Finney:
> >>> So Makefile rules can then re-run auto* tools at build time and you
> >>> lost the benefit you want to have.
> >>
> >> Makefile rules should not rerun auto* stuff at build time.
> > 
> > they will if AM_MAINTAINER_MODE is being used, in some cases.
> 
> It's really the other way around.
> By default automake generates rules which will regenerate the build system if
> affected files are changed.

Ie, consistently with all regular commands in a makefile: if a source file
has been modified, everything that is generated from that source needs to be
rebuilt.

Which works just fine if timestamps haven't been trampled over.

The problem in the past stemmed from "patch" not preserving them, but dpkg
since version 1.13.15 (five years ago) works around that by setting the
timestamps of patched files to current time.

> AM_MAINTAINER_MODE (which is optional and not used by most packages) allows to
> explicitl disable this dependency checking via AM_MAINTAINER_MODE(disable) or 
> as
> configure switch --disable-maintainer-mode.

AM_MAINTAINER_MODE is also strongly depreciated and discouraged.  Using it,
you are effectively patching compiler output rather than source.

You're likely to end up shipping things without source, obviously failing
DFSG and being in a breach of the GPL.  There's no way you can argue for
./configure to be a preferred form for modification...

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
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/20110317104253.ga17...@angband.pl

Re: Best practice for cleaning autotools-generated files?

[Julien Cristau]

On Thu, Mar 17, 2011 at 10:12:35 +0100, Andreas Tille wrote:

> On Thu, Mar 17, 2011 at 04:40:29PM +0800, Paul Wise wrote:
> > Eh? Rebuilding twice in a row would remove the files, regenerate them,
> > remove them, regenerate them. I can't see how the second regeneration
> > would fail if the first one did not.
> 
> The problem is that the regenerated files are not identical to the
> original files and you simply get a diff which finally makes different
> Debian source packages depending how often you start the build process.
> 
Err, no.  If debian/rules clean removes some files, they'll never show
up in a diff anywhere.

Cheers,
Julien


-- 
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/20110317093048.ga12...@radis.liafa.jussieu.fr

Re: Best practice for cleaning autotools-generated files?

[Paul Wise]

On Thu, Mar 17, 2011 at 5:12 PM, Andreas Tille  wrote:

> The problem is that the regenerated files are not identical to the
> original files and you simply get a diff which finally makes different
> Debian source packages depending how often you start the build process.

You won't get a diff if you remove them in `debian/rules clean` like
dh-autoreconf does. I agree that the regenerated files can be
different for each build but I don't consider that an issue.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/AANLkTimeTo+=5dGQ9MH8=zcw87bfn+2+zsjprxbmc...@mail.gmail.com

Re: Best practice for cleaning autotools-generated files?

[Andrey Rahmatullin]

On Thu, Mar 17, 2011 at 09:17:27AM +, Lars Wirzenius wrote:
> > > My rule is: when there is something non-free or when the amount of
> > > useless stuff is huge. For example I would repack a tarball with a
> > > small program and 20Mb of embedded code copies of all its dependencies
> > > to remove the deps.
> > What about .svn dirs?
> I would not re-package a tarball because of .svn dirs, unless they
> actuall cause breakage or are large. 
.svn dirs are usually exactly the same size as all other files, unless
there are huge non-committed files in the tarball.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Best practice for cleaning autotools-generated files?

[Lars Wirzenius]

On to, 2011-03-17 at 10:12 +0100, Andreas Tille wrote:
> On Thu, Mar 17, 2011 at 04:40:29PM +0800, Paul Wise wrote:
> > My rule is: when there is something non-free or when the amount of
> > useless stuff is huge. For example I would repack a tarball with a
> > small program and 20Mb of embedded code copies of all its dependencies
> > to remove the deps.
> 
> What about .svn dirs?

I would not re-package a tarball because of .svn dirs, unless they
actuall cause breakage or are large. I would, however, talk to upstream
about generating tarballs without them.

(Ditto for CVS, .git, .bzr, etc, of course.)

-- 
Blog/wiki/website hosting with ikiwiki (free for free software):
http://www.branchable.com/


-- 
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/1300353447.2771.92.ca...@havelock.lan

Re: Best practice for cleaning autotools-generated files?

[Andreas Tille]

On Thu, Mar 17, 2011 at 04:40:29PM +0800, Paul Wise wrote:
> My rule is: when there is something non-free or when the amount of
> useless stuff is huge. For example I would repack a tarball with a
> small program and 20Mb of embedded code copies of all its dependencies
> to remove the deps.

What about .svn dirs?
 
> Eh? Rebuilding twice in a row would remove the files, regenerate them,
> remove them, regenerate them. I can't see how the second regeneration
> would fail if the first one did not.

The problem is that the regenerated files are not identical to the
original files and you simply get a diff which finally makes different
Debian source packages depending how often you start the build process.

Kind regards

  Andreas. 

-- 
http://fam-tille.de


-- 
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/20110317091235.gg25...@an3as.eu

Re: new Contents generator on ftp-master

[Adam D. Barratt]

On Tue, March 15, 2011 21:40, Joerg Jaspert wrote:
>
>>> The new implementation is currently only used for suites that are not
>>> marked as untouchable. Oldstable and stable will switch during the next
>>> point release.
>> Have you (or anyone else) verified that any tools in {old,}stable
>> parsing contents files are compatible with the new structure (and
>> filenames in the case of udebs)?
>
> As far as I remember, there is currently no user for the udeb contents
> files.
> Or that was the case last we had a discussion about it. :)

That wouldn't surprise me.  The filenames were a bit of an add-on thought
to be honest, my main concern was the tool compatibility.

Regards,

Adam


-- 
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/c84c74dad8297a327440c4cd27cd48f8.squir...@adsl.funky-badger.org

Re: Best practice for cleaning autotools-generated files?

[Paul Wise]

On Thu, Mar 17, 2011 at 4:34 PM, Andreas Tille  wrote:

> I just accept your opinion that repackaging is not warranted and I did
> not in the past - but I was never really sure whether this is really
> reasonable.  I'm somehow missing *clear* rules when to rebuild the orig
> tarball and when not.

My rule is: when there is something non-free or when the amount of
useless stuff is huge. For example I would repack a tarball with a
small program and 20Mb of embedded code copies of all its dependencies
to remove the deps.

> I understand the requirement to build a package "twice in a row" as it
> was discussed here[1] (including link to policy) that the removal of
> those files is not OK.

Eh? Rebuilding twice in a row would remove the files, regenerate them,
remove them, regenerate them. I can't see how the second regeneration
would fail if the first one did not.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
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/AANLkTinJ7+4Z6yX=mvfbp+gxthxcvbbxjrlqkbjs5...@mail.gmail.com

Re: [buildd-tools-devel] re buildd's resolver and package's build deps

[Lars Wirzenius]

On to, 2011-03-17 at 08:32 +, Roger Leigh wrote:
> You can get the same effect with "file" chroots (tarball unpack).  It's
> not that slow providing your tarball is really minimal, and it works
> on all architectures.  I used this for the whole archive rebuild after
> LVM snapshots oopsed and then froze the kernel.

As a data point for comparison: Some years ago, when I ran piuparts
tests on the archive myself, it took a few seconds to unpack the
piuparts chroot tarball. 

An LVM snapshot or other such magic might be faster than that, but the
actual build or install test is so much slower that it is hardly worth
worrying about a few seconds.

-- 
Blog/wiki/website hosting with ikiwiki (free for free software):
http://www.branchable.com/


-- 
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/1300351213.2771.83.ca...@havelock.lan

Re: Best practice for cleaning autotools-generated files?

[Andreas Tille]

On Thu, Mar 17, 2011 at 04:09:25PM +0800, Paul Wise wrote:
> 
> Agreed. That would usually not be something that would cause enough
> problems for a new tar.gz to be warranted though.

I just accept your opinion that repackaging is not warranted and I did
not in the past - but I was never really sure whether this is really
reasonable.  I'm somehow missing *clear* rules when to rebuild the orig
tarball and when not.
 
> > If you try to build the source twice in a row you get a diff to the
> > original tarball.  This should be avoided.
> 
> I would just have `debian/rules clean` remove the (re-)generated files
> as per usual.

I understand the requirement to build a package "twice in a row" as it
was discussed here[1] (including link to policy) that the removal of
those files is not OK.

Kind regards

  Andreas.

[1] http://lists.debian.org/debian-devel/2007/05/msg00490.html 

-- 
http://fam-tille.de


-- 
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/20110317083422.ge25...@an3as.eu

Re: [buildd-tools-devel] re buildd's resolver and package's build deps

[Roger Leigh]

On Thu, Mar 17, 2011 at 08:31:13AM +0100, Cyril Brulebois wrote:
> Hi,
> 
> just as a reminder:
> 
> Roger Leigh  (16/03/2011):
> > OK.  I think this is the only known discrepancy between the two
> > resolvers.  Given that we now routinely build using minimal clean
> > (cloned) chroots, they will behave identically in practice because
>   
> AFAICT: only possible on Linux for now.

You can get the same effect with "file" chroots (tarball unpack).  It's
not that slow providing your tarball is really minimal, and it works
on all architectures.  I used this for the whole archive rebuild after
LVM snapshots oopsed and then froze the kernel.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Best practice for cleaning autotools-generated files?

[Michael Biebl]

Am 17.03.2011 08:51, schrieb Sean Finney:

> 
>>> So Makefile rules can then re-run auto* tools at build time and you
>>> lost the benefit you want to have.
>>
>> Makefile rules should not rerun auto* stuff at build time.
> 
> they will if AM_MAINTAINER_MODE is being used, in some cases.

It's really the other way around.
By default automake generates rules which will regenerate the build system if
affected files are changed.

AM_MAINTAINER_MODE (which is optional and not used by most packages) allows to
explicitl disable this dependency checking via AM_MAINTAINER_MODE(disable) or as
configure switch --disable-maintainer-mode.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Best practice for cleaning autotools-generated files?

[Paul Wise]

On Thu, Mar 17, 2011 at 4:02 PM, Andreas Tille  wrote:

> Sorry, I was not precise.  I also regard Makefile.in and configure (and
> files which are used by configure to run properly) as useful in an
> upstream tarball.  However, files like config.log etc. should be cleaned
> up.

Agreed. That would usually not be something that would cause enough
problems for a new tar.gz to be warranted though.

> I mean cases were the process:
>
>   tar -xzf *.orig.tar.gz
>   cd 
>   make clean    (or make distclean whatever is used)
>
> leads to a different directory layout than it is provided in the
> tarball.  For sure I would try to contact upstream but this does not
> always work (dead upstream, unresponsive upstream).
>
> Simply rebuilding the cleaned source as orig.tar.gz would be a quite
> simple way to handle issues like this.
...
> If you try to build the source twice in a row you get a diff to the
> original tarball.  This should be avoided.

I would just have `debian/rules clean` remove the (re-)generated files
as per usual.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
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/aanlktikk7zpgawu70ihpx5naa_ghptmpvuvpcfszi...@mail.gmail.com

Re: Best practice for cleaning autotools-generated files?

[Andreas Tille]

On Thu, Mar 17, 2011 at 03:32:05PM +0800, Paul Wise wrote:
> On Thu, Mar 17, 2011 at 3:15 PM, Andreas Tille  wrote:
> 
> > Would you consider the existence of autotools autogenerated files inside
> > an upstream source a valid reason to rebuild upstream source in a
> > get-orig-source target?
> 
> I would consider autotools generated files (Makefile.in, configure,
> etc) in an orig.tar.gz to be normal for an upstream project with a
> build system based on autotools. Indeed, if such projects had a
> tarball without those things I would consider it abnormal. I usually
> wouldn't consider rebuilding a tarball to remove such files.

Sorry, I was not precise.  I also regard Makefile.in and configure (and
files which are used by configure to run properly) as useful in an
upstream tarball.  However, files like config.log etc. should be cleaned
up.
 
> > More generally: Would you consider it a valid reason for rebuilding
> > upstream source if upstream forgot to `make (dist)clean`?
> 
> Not sure what you are asking here. If upstream didn't use `make dist`
> or `make distcheck` and that caused a problem I would contact upstream
> and educate them about how to generate tarballs from autotools-based
> projects.

I mean cases were the process:

   tar -xzf *.orig.tar.gz
   cd 
   make clean(or make distclean whatever is used)

leads to a different directory layout than it is provided in the
tarball.  For sure I would try to contact upstream but this does not
always work (dead upstream, unresponsive upstream).

Simply rebuilding the cleaned source as orig.tar.gz would be a quite
simple way to handle issues like this.
 
> > In several cases the answer "yes" to both questions would have saved me
> > a certain amount of time because I cared about "purists complaining that
> > debian/rules clean does not restore whatever crap was there upstream".
> 
> I don't think `debian/rules clean` was ever supposed to restore stuff
> in orig.tar.gz, as long as debian/rules build regenerates it. So I
> wouldn't bother caring about such folks.

If you try to build the source twice in a row you get a diff to the
original tarball.  This should be avoided.

Kind regards

   Andreas. 

-- 
http://fam-tille.de


-- 
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/20110317080210.gc25...@an3as.eu

Re: Best practice for cleaning autotools-generated files?

[Raphael Hertzog]

On Thu, 17 Mar 2011, Sean Finney wrote:
> > > If you do it with the patch system (quilt or even plain dpkg),
> > > before building the package source, you cannot ensure that files are
> > > patched in the right order.
> > 
> > What do you mean "in the right order" ?
> 
> autofoo stuff examines timestamps on various files, so it's possible
> that if configure gets patched before configure.ac, and
> AM_MAINTAINER_MODE is set to a specific value, that ./configure ends up
> wanting to regenerate ./configure at build time.  double fail.

dpkg-source resets the timestamp of patched files so that they all have
the same timestamp. This is precisely to avoid this.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110317075628.gb7...@rivendell.home.ouaza.com

Re: Best practice for cleaning autotools-generated files?

[Sean Finney]

On Wed, 2011-03-16 at 16:36 +, Ian Jackson wrote:
> > Then, you need a way to patch them. There is lots of software where
> > you need to patch configure.ac and/or Makefile.am
> 
> That's fine, you patch the input, rerun the autofoobar stuff, and then
> build the source package with diff.  If you're using a patch queue
> system, or a vcs, you arrange for the autogenerated autofoobar output
> changes to be committed along with the corresponding input change.

and then you end up with either (a) masses of changes to upstream files
in your local branch which will cause merge conflicts (and
aesthetically, ew, yuck.) or (b) a patch in your patch queue which will
very likely not apply in the next upstream release.

> > If you do it with the patch system (quilt or even plain dpkg),
> > before building the package source, you cannot ensure that files are
> > patched in the right order.
> 
> What do you mean "in the right order" ?

autofoo stuff examines timestamps on various files, so it's possible
that if configure gets patched before configure.ac, and
AM_MAINTAINER_MODE is set to a specific value, that ./configure ends up
wanting to regenerate ./configure at build time.  double fail.

> > So Makefile rules can then re-run auto* tools at build time and you
> > lost the benefit you want to have.
> 
> Makefile rules should not rerun auto* stuff at build time.

they will if AM_MAINTAINER_MODE is being used, in some cases.


sean


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

Re: Best practice for cleaning autotools-generated files?

[Paul Wise]

On Thu, Mar 17, 2011 at 3:15 PM, Andreas Tille  wrote:

> Would you consider the existence of autotools autogenerated files inside
> an upstream source a valid reason to rebuild upstream source in a
> get-orig-source target?

I would consider autotools generated files (Makefile.in, configure,
etc) in an orig.tar.gz to be normal for an upstream project with a
build system based on autotools. Indeed, if such projects had a
tarball without those things I would consider it abnormal. I usually
wouldn't consider rebuilding a tarball to remove such files.

> More generally: Would you consider it a valid reason for rebuilding
> upstream source if upstream forgot to `make (dist)clean`?

Not sure what you are asking here. If upstream didn't use `make dist`
or `make distcheck` and that caused a problem I would contact upstream
and educate them about how to generate tarballs from autotools-based
projects.

> In several cases the answer "yes" to both questions would have saved me
> a certain amount of time because I cared about "purists complaining that
> debian/rules clean does not restore whatever crap was there upstream".

I don't think `debian/rules clean` was ever supposed to restore stuff
in orig.tar.gz, as long as debian/rules build regenerates it. So I
wouldn't bother caring about such folks.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/AANLkTi=4986onj6f8yk3nifkt-omk68407bivv+kl...@mail.gmail.com

Re: [buildd-tools-devel] re buildd's resolver and package's build deps

[Cyril Brulebois]

Hi,

just as a reminder:

Roger Leigh  (16/03/2011):
> OK.  I think this is the only known discrepancy between the two
> resolvers.  Given that we now routinely build using minimal clean
> (cloned) chroots, they will behave identically in practice because
  
AFAICT: only possible on Linux for now.

> non-first alternatives will not be present in the clean chroot, so
> this behaviour in the internal resolver will not be exercised in
> practice.  I certainly saw no evidence of it during my whole-archive
> rebuild.

KiBi.


signature.asc
Description: Digital signature

Re: Best practice for cleaning autotools-generated files?

[Andreas Tille]

On Thu, Mar 17, 2011 at 11:21:52AM +0800, Paul Wise wrote:
> > 5. Cheerfully ignore any purists complaining that debian/rules clean does
> >   not restore whatever crap was there upstream.
> 
> I generally don't bother with these unless I'm patching the autotools
> source files (configure.ac/Makefile.am). I'm increasingly being
> convinced that doing it in all autotools-based packages is a good
> idea.

Would you consider the existence of autotools autogenerated files inside
an upstream source a valid reason to rebuild upstream source in a
get-orig-source target?

More generally: Would you consider it a valid reason for rebuilding
upstream source if upstream forgot to `make (dist)clean`?

In several cases the answer "yes" to both questions would have saved me
a certain amount of time because I cared about "purists complaining that
debian/rules clean does not restore whatever crap was there upstream".

Kind regards

Andreas.

-- 
http://fam-tille.de


-- 
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/20110317071542.ga25...@an3as.eu