Re: Bits from the FTPMaster meeting

[Jean-Christophe Dubacq]

Luk Claes a écrit :
> Charles Plessy wrote:
>> Le Tue, Nov 17, 2009 at 08:27:22AM +0100, Yves-Alexis Perez a écrit :
>>> Unless your proposal is just for unstable but doesn't want to change the
>>> policy for testing migration?
>> Hi,
>>
>> Testing migration works the way it should: if a package is never built on an
>> architecture, testing migration is not prevented. The problem is that for the
>> sake of universality, some programs are built where nobody wants them. Then
>> when there is a build failure, nobody wants the ‘hot potato’. Upstream does 
>> not
>> support non-mainstream arches, the porters are busy porting more central
>> packages, the package maintainer has user requests to answer and knows that
>> nobody will send him kudos for building the package where it is not used.
> 
> The reason we want everything to be built everywhere if possible is not
> universality, but quality.
> 
> If your package FTBFS on some architecture, then that is a bug. A bug
> that was already there, it just was not noticed yet. In most cases the
> bug is rather easy to fix, even for non porters as most of the
> architecture specific FTBFS issues are due to wrong assumptions like
> 32bit/64bit, little endian/big endian...

Is there somewhere a list of "how to fix"? Something simple so that
maintainers may do the right things as soon as a package is FTBFS?


-- 
Jean-Christophe Dubacq


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

Re: Bits from the FTPMaster meeting

[Clint Adams]

On Wed, Nov 18, 2009 at 07:41:51AM +0100, Luk Claes wrote:
> I don't think it's good to waste buildd time on failing to build packages.
> I also don't think anyone is stopped from setting up a service that
> allows source-only uploads as a go-between.

Do you mean set up an unofficial upload queue that builds a source package,
autosigns the .changes, and uploads it to Debian?


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

Re: Bits from the FTPMaster meeting

[Stefano Zacchiroli]

On Wed, Nov 18, 2009 at 08:47:33AM +0100, Jean-Christophe Dubacq wrote:
> > If your package FTBFS on some architecture, then that is a bug. A bug
> > that was already there, it just was not noticed yet. In most cases the
> > bug is rather easy to fix, even for non porters as most of the
> > architecture specific FTBFS issues are due to wrong assumptions like
> > 32bit/64bit, little endian/big endian...
> Is there somewhere a list of "how to fix"? Something simple so that
> maintainers may do the right things as soon as a package is FTBFS?

http://wiki.debian.org/qa.debian.org/FTBFS

(linked from all bug reports reported by massive rebuild by Lucas)

The page is maintained in a collaborative manner: if you find a common
patter, please add it there. The page might also need some
re-organization. Any contribution is welcome.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Bits from the FTPMaster meeting

[Andreas Tille]

On Wed, Nov 18, 2009 at 07:41:51AM +0100, Luk Claes wrote:
> 
> I think one would be surprised how many packages get used on 'exotic'
> architectures. Most users don't specifically search for a piece of
> software, they want to have some specific task done by using a specific
> package. Not providing the package will only mean that the user either
> uses another package or does not get the task done.

Well, I do not think that you can do gene sequencing or number crunching
on current mobile phones.  So there are really programs which are not
needed on all architectures and even if you find a binary package which
claims to do the job it is just useless.  Even if I agree with your
arguing that each program at least theoretically should build on any
architecture (if not it is a bug) in some cases it looks foolish to
provide binary packages just for the sake of it.  This is was Charles
meant when he wrote: We should trust the maintainer if a specific
program is not needed for a certain architecture.

> Slow architectures are dying otherwise there would get new chipsets
> built that are faster IMHO.

There are architectures for different issues.  There are issues which
allways need the fastest available architecture and there are other
needs which are targeting at low power consumption etc.  We should
probably not put a large effort on a theoretical option which is never
used in real live (and I mean a reall *never* not only low chances).

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

Re: Bits from the FTPMaster meeting

[Philipp Kern]

On 2009-11-18, Andreas Tille  wrote:
> Well, I do not think that you can do gene sequencing or number crunching
> on current mobile phones.  So there are really programs which are not
> needed on all architectures and even if you find a binary package which
> claims to do the job it is just useless.  Even if I agree with your
> arguing that each program at least theoretically should build on any
> architecture (if not it is a bug) in some cases it looks foolish to
> provide binary packages just for the sake of it.  This is was Charles
> meant when he wrote: We should trust the maintainer if a specific
> program is not needed for a certain architecture.

Or the porters (c.f. xorg video or drivers on s390).  But that's what
P-a-s is for, at the moment.  Still it ought to be buildable everywhere,
there might not be clusters of arm yet but I saw offers for clusters of mips.

Kind regards,
Philipp Kern


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

Re: Bits from the FTPMaster meeting

[Gerfried Fuchs]

Hi!

 First of all, thanks for this great roundup. There are just some few
questions that popped up in my mind that I hope haven't asked yet
(wasn't able to check all the responses completely ...). Sorry if there
are duplications, a reference to the answer for easier tracking would be
appreciated, though. :)

* Joerg Jaspert  [2009-11-15 16:15:35 CET]:
> source-only uploads
> ---
> The current "winning" opinion is to go with the source+throw away
> binaries route.  We are close to being able to achieve this, it is
> simply that it has not yet been enabled.  Before any version of this
> can be enabled, buildd autosigning needs to be implemented in order
> that dak can differentiate buildd uploads vs maintainer uploads.

 I am a bit confused with respect to how buildd autosigning is required
for this. It makes it sound somehow like it would affect porter binary
uploads. Is this the case or am I reading too much into this? What's the
rationale for the requirement of autosiging needs, and would porters
still be able to upload binary-only without having them thrown away
because they aren't signed with a key in the buildd-keyring? It's
unfortunately not too uncommon that some buildds have issues over a
longer period of time, and being able to help while that's the case is
what I consider an important feature for a porter.

> Tracking arch all packages
> --
> #246992 asked us to not delete arch all packages before the
> corresponding (if any) arch any packages are available for all
> architectures.  Example: whenever a new source package for emacs23
> gets uploaded the installation of the metapackage emacs_*_all.deb
> breaks on most architectures until the needed Architecture: any
> packages like emacs23 get built by the buildds. That happens because
> dak removes all arch: all packages but the newest one.

 What exactly is meant with deleting here? From the pool? Or does it
mean that the Packages files will keep all versions of the arch all
packages in them and thus reducing the amount of uninstallable packages?
The later would be greatly help with regular reports of uninstallable
packages that weren't yet built and the old binary package depending on
the old arch package which otherwise wouldn't be available anymore. From
what I understand (and tried) apt does the right thing and chooses the
most recent versions in cases where it doesn't matter anyway.

 Thanks in advance for clearing up these questions, and again, thanks
for your work!

 So long,
Rhonda


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

Bug#556928: ITP: pyflag -- An advanced forensic tool for large volumes of log files

[Tiago Bortoletto Vaz]

Package: wnpp
Severity: wishlist
Owner: Tiago Bortoletto Vaz 


* Package name: pyflag
  Version : 0.87-pre1
  Upstream Author : Michael Cohen and David Collett 

* URL : http://www.pyflag.net
* License : GPL-2
  Programming Lang: C, Python
  Description : An advanced forensic tool for large volumes of log files

FLAG (Forensic and Log Analysis GUI) is an advanced forensic tool for the
analysis of large volumes of log files and forensic investigations.

PyFlag features a rich FeatureList which include the ability to load many
different log file formats, Perform forensic analysis of disks and images.
PyFlag can also analyse network traffic as obtained via tcpdump quickly and
efficiently.

Since PyFLAG is web based, it is able to be deployed on a central server and
shared with a number of users at the same time. Data is loaded into cases which
keeps information separated.



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

Re: Bits from the FTPMaster meeting

[Charles Plessy]

Le Wed, Nov 18, 2009 at 12:42:47AM -0600, Manoj Srivastava a écrit :
> 
> I beg to differ. This sounds like a maintainer that is not
>  providing the support for their package, and needs to  orphan that
>  package; not building on some architecture is often a symptom of
>  problems elsewhere as well. I am not sure we ought to support
>  maintainers that are neglectful of their packages.

You are member of the technical comittee, which means that I should trust your
experience. I want you and this list to understand that I take your advice to
orphan my packages very seriously. For the programs I am interested in, I do
not share Debian's goal to make them run on all existing platforms we support.

Trust me, it is not only to save my time, but also because I do not want my
packages to be a burden to the communauty. It is my experience that for
bioinformatics packages, when a bug is found by the buildd network on an
unsupported architecture, neither upstream nor the porters show much interest
for it. I do not mean this as a criticism, since I share this point of view
that there is better to do than fixing those bugs.

Luk suggested to use an unofficial upload system and indeed I have been
browsing the documentation of Ubuntu's personnal package archive and signed
their code of conduct recently. The only problem is that their PPAs do not
build the packages against Lenny or Sid, but actually it would not be a problem
for many of the users of my packages, because apparently they are Ubuntu users…

I am of course pleased to see my work re-used, but I would be even more pleased
if people would use Debian Med. To attract more users, we need a good release
and good medical packages. I do think that not speding time on porting some
of our bioinformatics packages would help the two sides of the coin.

Have a nice day,

-- 
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

Bug#556949: ITP: libalgorithm-diff-xs-perl -- module to find differences between files (XS accelerated)

[Jonathan Yu]

Package: wnpp
Owner: Jonathan Yu 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libalgorithm-diff-xs-perl
  Version : 0.04
  Upstream Author : Audrey Tang 
* URL : http://search.cpan.org/dist/Algorithm-Diff-XS/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to find differences between files (XS accelerated)

 Algorithm::Diff::XS is a Perl diff utility module based on Joe Schaefer's
 excellent but not very well-known Algorithm::LCS module, with a drop-in
 interface identical to Algorithm::Diff.
 .
 Note that only the LCSidx function is optimized in XS at the moment, which
 means only compact_diff will get significantly faster for large data sets,
 while diff and sdiff will run in identical speed as Algorithm::Diff.



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

Re: Bits from the FTPMaster meeting

[Charles Plessy]

Le Wed, Nov 18, 2009 at 10:54:18AM +, Philipp Kern a écrit :

> there might not be clusters of arm yet but I saw offers for clusters of mips.

Hi Philipp

I also saw this cluster and got quite curious until I realised that most
programs I package are not parallelised…

The day we are contacted to do some genomics on mips clusters it will be very
exciting, but this should come with real support from the groups interested in,
let's not forget we are just volunteers. Preparing for this event with no
indication whether it could happen or not is risky and in my opinion,
prematurate.

If we mean to attract such users, I do not think that the best strategy would
necessarly be having a pre-existing MIPS support of bioinformatics, which I
think is completely beyond our reach and expertise. I think that what would
matter would be to have a healthy MIPS port on one side, and be the best distro
for bioinformatics on mainstream platforms on the other side. This would be a
solid basis to start a collaboration to become a good bioinformatics distro on
MIPS. Just because we can build packages is not the best indicator: most of them
have no regression tests yet, and a significant number of the build failures
I experienced on my packages happen during such tests…

So in conclusion (like a broken disk), with a simple modification of
dpkg-gencontrol, we can stop building on some architectures some packages which
bring them no added value. For new packages, that seems to be enough. For
existing packages, maintainers who want to opt-out of some architectures would
need to submit a patch against the packages-arch-specific file and sumbit a
bunch of dak commands to the release file. This could be consolidated in
batches and I can help for this, so that the work load is minimum, compared to
the gain for everybody. 

Have a nice day,

-- 
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

Re: Bits from the FTPMaster meeting

[Manoj Srivastava]

On Wed, Nov 18 2009, Charles Plessy wrote:

> Le Wed, Nov 18, 2009 at 12:42:47AM -0600, Manoj Srivastava a écrit :
>> 
>> I beg to differ. This sounds like a maintainer that is not
>>  providing the support for their package, and needs to  orphan that
>>  package; not building on some architecture is often a symptom of
>>  problems elsewhere as well. I am not sure we ought to support
>>  maintainers that are neglectful of their packages.
>
> You are member of the technical comittee, which means that I should
> trust your experience. I want you and this list to understand that I
> take your advice to orphan my packages very seriously.

While I am flattered, I don't think you should pay special
 attention to my words based on who I am. That is the flip side of
 arguing to the man; arguing by authority. You should pay attention to
 my argument only if it makes sense.

> For the programs I am interested in, I do not share Debian's goal to
> make them run on all existing platforms we support.

I don't think that that is the rationale for making packages
 build everywhere; if it were, we would not have P-a-s. The rationale is
 that making packages portable unmasks bugs that are present everywhere,
 but not yet triggered,

Now, there are of course packages that do not make sense to
 build on all architectures, or to not build on specific arches. My
 SELinux related packages are an example -- they do not make sense to
 have on the kfreebsd or the HURD. Which is why we have mechanisms to
 exclude packages from architectures -- and by default, if a package has
 never built on an architecture, it is not a testing migration blocker. 

The answer is to utilize these exception mechanisms.

> Trust me, it is not only to save my time, but also because I do not
> want my packages to be a burden to the communauty. It is my experience
> that for bioinformatics packages, when a bug is found by the buildd
> network on an unsupported architecture, neither upstream nor the
> porters show much interest for it. I do not mean this as a criticism,
> since I share this point of view that there is better to do than
> fixing those bugs.

Right. But it is not for upstream or the porters alone: this is
 what we, as Debian developers, do.  We are not just glorified
 packagers; we are supposed to be "Developers", we  take an active role
 in improving and fixing our packages. Anything less does not do justice
 to the project's goal of creating the "BEst" OS ever.

> I am of course pleased to see my work re-used, but I would be even
> more pleased if people would use Debian Med. To attract more users, we
> need a good release and good medical packages. I do think that not
> speding time on porting some of our bioinformatics packages would help
> the two sides of the coin.

Firstly, if it requires that much porting, it might point to a
 defect in design, which should be fixed. Secondly, if there is a
 legitimate reason (and of course there are legitimate reasons to not
 build stuff on some arches) -- then talk to your fellow Debian
 developers, and get an entry added to the P-a-s. It is not hard.

manoj
-- 
"...and scantily clad females, of course.  Who cares if it's below zero
outside" (By Linus Torvalds)
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bits from the FTPMaster meeting

[Manoj Srivastava]

On Wed, Nov 18 2009, Clint Adams wrote:

> On Wed, Nov 18, 2009 at 07:41:51AM +0100, Luk Claes wrote:
>> I don't think it's good to waste buildd time on failing to build packages.
>> I also don't think anyone is stopped from setting up a service that
>> allows source-only uploads as a go-between.
>
> Do you mean set up an unofficial upload queue that builds a source
> package, autosigns the .changes, and uploads it to Debian?

If such a system is set into play, I promise to help test it by
 funneling my uploads through it.

manoj
-- 
It would be nice to be sure of anything the way some people are of
everything.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bits from the FTPMaster meeting

[Mark Brown]

On Wed, Nov 18, 2009 at 11:40:52PM +0900, Charles Plessy wrote:

> If we mean to attract such users, I do not think that the best strategy would
> necessarly be having a pre-existing MIPS support of bioinformatics, which I
> think is completely beyond our reach and expertise. I think that what would
> matter would be to have a healthy MIPS port on one side, and be the best 
> distro
> for bioinformatics on mainstream platforms on the other side. This would be a
> solid basis to start a collaboration to become a good bioinformatics distro on
> MIPS. Just because we can build packages is not the best indicator: most of 
> them
> have no regression tests yet, and a significant number of the build failures
> I experienced on my packages happen during such tests???

It's a bit worrying that the software requires noticable porting effort
in the first place - often that's a sign of general fragility which will
also manifiest itself on supported arches sooner or later.

> So in conclusion (like a broken disk), with a simple modification of
> dpkg-gencontrol, we can stop building on some architectures some packages 
> which
> bring them no added value. For new packages, that seems to be enough. For
> existing packages, maintainers who want to opt-out of some architectures would
> need to submit a patch against the packages-arch-specific file and sumbit a
> bunch of dak commands to the release file. This could be consolidated in
> batches and I can help for this, so that the work load is minimum, compared to
> the gain for everybody. 

The flip side of this is that it's just inviting maintainers to decide
they can't be bothered with porting effort and leaving ports as second
class citizens.


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

Bug#556958: ITP: abiword-docs -- documentation for the abiword word processor

[Patrik Fimml]

Package: wnpp
Severity: wishlist
Owner: Patrik Fimml 

* Package name: abiword-docs
* Version : 2.8.1
* Upstream Author : Dom Lachowicz 
* URL : http://www.abisource.com
* License : to be clarified, most likely GPL
* Description : documentation for the abiword word processor

Hey,

in my function as maintainer of the abiword package, I decided to build
the documentation from a separate source package starting with 2.8.1.
Following the upstream naming scheme, this will be abiword-docs and will
replace the old abiword-help binary package.

Patrik


signature.asc
Description: Digital signature

Bug#556966: ITP: libpod-coverage-trustpod-perl -- module to support hints for Pod::Coverage

[Jonathan Yu]

Package: wnpp
Owner: Jonathan Yu 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libpod-coverage-trustpod-perl
  Version : 0.092830
  Upstream Author : Ricardo SIGNES 
* URL : http://search.cpan.org/dist/Pod-Coverage-TrustPod/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to support hints for Pod::Coverage

 Pod::Coverage::TrustPod is a Perl module that extends Pod::Coverage by
 allowing your Plain Old Documentation (POD) to declare certain symbol names
 as trusted. It is similar to using the 'trustme' feature in your test file,
 but does not require changes to the test file; instead, you make such trust
 annotations in your POD in a specially formatted field.

NOTE: this is already a module used for testing several modules (useful for
Build-Depends/Build-Depends-Indep).



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

Re: Bits from the FTPMaster meeting

[Luk Claes]

Andreas Tille wrote:
> On Wed, Nov 18, 2009 at 07:41:51AM +0100, Luk Claes wrote:
>> I think one would be surprised how many packages get used on 'exotic'
>> architectures. Most users don't specifically search for a piece of
>> software, they want to have some specific task done by using a specific
>> package. Not providing the package will only mean that the user either
>> uses another package or does not get the task done.
> 
> Well, I do not think that you can do gene sequencing or number crunching
> on current mobile phones.  So there are really programs which are not
> needed on all architectures and even if you find a binary package which
> claims to do the job it is just useless.  Even if I agree with your
> arguing that each program at least theoretically should build on any
> architecture (if not it is a bug) in some cases it looks foolish to
> provide binary packages just for the sake of it.  This is was Charles
> meant when he wrote: We should trust the maintainer if a specific
> program is not needed for a certain architecture.
> 
>> Slow architectures are dying otherwise there would get new chipsets
>> built that are faster IMHO.
> 
> There are architectures for different issues.  There are issues which
> allways need the fastest available architecture and there are other
> needs which are targeting at low power consumption etc.  We should
> probably not put a large effort on a theoretical option which is never
> used in real live (and I mean a reall *never* not only low chances).

That is what I meant. There are users of openoffice.org on armel and
mipsel, so it's not at all theoretical even if one would think
differently from a first look.

Cheers

Luk


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

Re: Bits from the FTPMaster meeting

[Luk Claes]

Clint Adams wrote:
> On Wed, Nov 18, 2009 at 07:41:51AM +0100, Luk Claes wrote:
>> I don't think it's good to waste buildd time on failing to build packages.
>> I also don't think anyone is stopped from setting up a service that
>> allows source-only uploads as a go-between.
> 
> Do you mean set up an unofficial upload queue that builds a source package,
> autosigns the .changes, and uploads it to Debian?

I was more thinking of an unofficial upload queue that builds a source
package and let the maintainer sign to do the upload to Debian instead
of autosigning. So it would still be the maintainer's responsability to
check the resulting package before uploading.

Cheers

Luk


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

Re: Bits from the FTPMaster meeting

[Luk Claes]

Gerfried Fuchs wrote:
>   Hi!
> 
>  First of all, thanks for this great roundup. There are just some few
> questions that popped up in my mind that I hope haven't asked yet
> (wasn't able to check all the responses completely ...). Sorry if there
> are duplications, a reference to the answer for easier tracking would be
> appreciated, though. :)
> 
> * Joerg Jaspert  [2009-11-15 16:15:35 CET]:
>> source-only uploads
>> ---
>> The current "winning" opinion is to go with the source+throw away
>> binaries route.  We are close to being able to achieve this, it is
>> simply that it has not yet been enabled.  Before any version of this
>> can be enabled, buildd autosigning needs to be implemented in order
>> that dak can differentiate buildd uploads vs maintainer uploads.
> 
>  I am a bit confused with respect to how buildd autosigning is required
> for this. It makes it sound somehow like it would affect porter binary
> uploads. Is this the case or am I reading too much into this? What's the
> rationale for the requirement of autosiging needs, and would porters
> still be able to upload binary-only without having them thrown away
> because they aren't signed with a key in the buildd-keyring? It's
> unfortunately not too uncommon that some buildds have issues over a
> longer period of time, and being able to help while that's the case is
> what I consider an important feature for a porter.

The rationale is that the turnaround time would get smaller. Currently
the built package waits for the buildd admin to manually sign. A smaller
turnaround time would at least affect transitions, binNMUs and testing
migration in general.

AFAIK binary packages would only be thrown away for sourceful uploads.

There still needs to be implemented a solution regarding the
Architecture: all packages and actual testing and preparation by the
wb-team to get actual autosigning on any buildd btw.

>> Tracking arch all packages
>> --
>> #246992 asked us to not delete arch all packages before the
>> corresponding (if any) arch any packages are available for all
>> architectures.  Example: whenever a new source package for emacs23
>> gets uploaded the installation of the metapackage emacs_*_all.deb
>> breaks on most architectures until the needed Architecture: any
>> packages like emacs23 get built by the buildds. That happens because
>> dak removes all arch: all packages but the newest one.
> 
>  What exactly is meant with deleting here? From the pool? Or does it
> mean that the Packages files will keep all versions of the arch all
> packages in them and thus reducing the amount of uninstallable packages?
> The later would be greatly help with regular reports of uninstallable
> packages that weren't yet built and the old binary package depending on
> the old arch package which otherwise wouldn't be available anymore. From
> what I understand (and tried) apt does the right thing and chooses the
> most recent versions in cases where it doesn't matter anyway.

The solution consists of keeping the Architecture: all packages in the
Packages files as long as the corresponding Architecture: any packages
are not installed in the archive if any (actual implementation is a bit
more involved due to some corner cases).

Cheers

Luk


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

Re: Bits from the FTPMaster meeting

[Luk Claes]

Charles Plessy wrote:
> Le Wed, Nov 18, 2009 at 10:54:18AM +, Philipp Kern a écrit :
> 
>> there might not be clusters of arm yet but I saw offers for clusters of mips.
> 
> Hi Philipp
> 
> I also saw this cluster and got quite curious until I realised that most
> programs I package are not parallelised…

A cluster is not only about parallel programs, but also about running
single threaded applications in parallel...

> If we mean to attract such users, I do not think that the best strategy would
> necessarly be having a pre-existing MIPS support of bioinformatics, which I
> think is completely beyond our reach and expertise. I think that what would
> matter would be to have a healthy MIPS port on one side, and be the best 
> distro
> for bioinformatics on mainstream platforms on the other side. This would be a
> solid basis to start a collaboration to become a good bioinformatics distro on
> MIPS. Just because we can build packages is not the best indicator: most of 
> them
> have no regression tests yet, and a significant number of the build failures
> I experienced on my packages happen during such tests…

You apparently fail to see that building the packages on mips uncovers
bugs that would otherwise be there, but take a longer time to uncover on
the 'mainstream' platforms.

> So in conclusion (like a broken disk), with a simple modification of
> dpkg-gencontrol, we can stop building on some architectures some packages 
> which
> bring them no added value. For new packages, that seems to be enough. For
> existing packages, maintainers who want to opt-out of some architectures would
> need to submit a patch against the packages-arch-specific file and sumbit a
> bunch of dak commands to the release file. This could be consolidated in
> batches and I can help for this, so that the work load is minimum, compared to
> the gain for everybody. 

As IMHO there is added value in building a package on all release
architectures, there is no reason to change dpkg-gencontrol at all.

Cheers

Luk


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

Bug#556996: ITP: gnuspool -- A network-based print spooler

[Philip Hands]

Package: wnpp
Severity: wishlist
Owner: John M Collins 


* Package name: gnuspool
  Version : 1.6
  Upstream Author : John M Collins 
* URL : http://www.gnu.org/software/gnuspool
* License : GPL (>=3)
  Programming Lang: C, (and some python in a sub-package)
  Description : A network-based print spooler

GNUspool is a fully functioned, high performance Print Spooler and
Management System for a wide range of Unix and GNU/Linux platforms.

It acts as a complete replacement for the standard Unix printing system
and provides a wide variety of print post processing options, form type
handling, alignment pages and numerous other facilities.

In addition, GNUspool runs completely transparently over networks of
hosts, sharing jobs on any host with printers on any other host.

=-=-=-=-
While I'm submitting this ITP, I'm doing it on behalf of the upstream
author, John M Collins , who is keen to package it himself.

I've been working with him to get the package into shape, and will be
doing the uploads, as John is not currently a DM or DD.

Cheers, Phil.



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

Re: Bits from the FTPMaster meeting

[Andreas Tille]

On Wed, Nov 18, 2009 at 08:18:57PM +0100, Luk Claes wrote:
> > There are architectures for different issues.  There are issues which
> > allways need the fastest available architecture and there are other
> > needs which are targeting at low power consumption etc.  We should
> > probably not put a large effort on a theoretical option which is never
> > used in real live (and I mean a reall *never* not only low chances).
> 
> That is what I meant. There are users of openoffice.org on armel and
> mipsel, so it's not at all theoretical even if one would think
> differently from a first look.

That's actually *not* what I mean.  I agree that there might be a use
for openoffice.org on any architecture.  This general use applications
are exactly what I was *not* speaking about.  But please let this settle
because the "find a bug" reason might be strong enough to make our
arguing void.

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

Re: Bits from the FTPMaster meeting

[Felipe Sateler]

Luk Claes wrote:


You apparently fail to see that building the packages on mips uncovers
bugs that would otherwise be there, but take a longer time to uncover on
the 'mainstream' platforms.


This is not generally true. There are are classes of bugs that appear on
different platforms _due to being different platforms_, not just because
they were latent bugs waiting to be discovered. I presume that packages
that require as much efficiency as possible (like Charles is implying in
his packages) are very likely to implement platform-specific
hacks/optimizations to run faster. It can be considered bad design, ugly
and whatnot, but it is irrelevant if nobody ever uses other platforms.

Saludos,
Felipe Sateler


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

ITP: mercurial-buildpackage (for those who care about Mercurial)

[Jens Peter Secher]

Executive summary: If you use Mercurial and pbuilder for package
maintenance you should try out mercurial-buildpackage in
http://people.debian.org/~jps/squeeze/ .

I have spent some time on making an improved version of
hg-buildpackage, which turned out to become a complete rewrite now
called mercurial-buildpackage.  The highlights are

 * Support dpkg source format 3.0.

 * Several .dsc can be imported to retain the full history when
   converting an existing package.

 * Building via pbuilder is a breeze.

 * Easily parsable output; same format as Lintian or Piuparts.

 * Complains if the repository has uncommited changes (unless --force).

 * Only one repository.  Branches are used to keep upstream separate.

I will now work on getting backporting, downstreaming (Ubuntu etc.) to
be a breeze (breezy?) too. 


Cheers,
-- 
Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1.

A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?


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

Re: Bits from the FTPMaster meeting

[Philipp Kern]

On 2009-11-18, Felipe Sateler  wrote:
> This is not generally true. There are are classes of bugs that appear on
> different platforms _due to being different platforms_, not just because
> they were latent bugs waiting to be discovered. I presume that packages
> that require as much efficiency as possible (like Charles is implying in
> his packages) are very likely to implement platform-specific
> hacks/optimizations to run faster. It can be considered bad design, ugly
> and whatnot, but it is irrelevant if nobody ever uses other platforms.

However that's one *exact* use-case for P-a-s.  If you do such optimizations.
(C.f. zsnes with its x86 assembly as a hard example.)

Mostly, though, I'd guess that it's written in a higher-level language without
resorting to architecture-dependent assembly.  And this code should, barring
alignment issues, also run on other platforms.

(Ok, there are weird cases of stack growing upwards, that's a special case
I agree upon.  However in most programs you do not need to deal with this
fact.)

Kind regards,
Philipp Kern


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

Re: Bits from the FTPMaster meeting

[Sune Vuorela]

On 2009-11-18, Gerfried Fuchs  wrote:
>  I am a bit confused with respect to how buildd autosigning is required
> for this. It makes it sound somehow like it would affect porter binary

Basicalyl, the turnaround time is too long if we have to wait for manual
buildd signings.

For example, when we upload a new KDE, we usually upload a big chunk of
source packages (3-5) where package 1 breaks last package.

Currently, we can upload all source packages built for amd64 and i386
and that way keep kde installable in unstable for more than 95 % of the
users. 

With 1 package signing per day (which is quite normal), we have 5 days
where kde by itself is uninstallable on all archs, if the buildds have
to build all packages by current means.

With buildd autosigning, we probably only have a day or so on the fast
archs with kde being uninstallable.

and I have the impression that we will get quite many bug reports about
kde being uninstallable. We arleady do that when kde is a part of
another transition, and if kde is blocking itself on main archs, we will
only get more.

So yes, I really hope that 'source only' (or throw away binaries)
uploads only get implemented when buildd autosigning is in place.

(KDE doesn't have that many users on e.g. hppa, so the current
turnaround time isn't that much of a problem outside the main archs)

/Sune


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

Re: Bits from the FTPMaster meeting

[Charles Plessy]

Le Wed, Nov 18, 2009 at 02:49:46PM +, Mark Brown a écrit :
> 
> The flip side of this is that it's just inviting maintainers to decide
> they can't be bothered with porting effort and leaving ports as second
> class citizens.

It seems that the trend this year is to not trust the maintainers for anything…

How about the porters responsability towards the project ? For instance, hppa
is blocking the testing migration of a couple of my packages, and probably the
packages of many other maintainers as well. Why would it be my duty to help
people running Debian on machines that are not used in my profession, and for
which I have no qualification at all? I do not want to prevent people having
fun with Debian on this arch, so wouldn't the best solution to never build my
package on their arch in the first place? It would reduce the number of issues
to solve in both groups, Debian Med and the hppa porters, which like every
other group in Debian severely lack manpower.

Have a nice day,

-- 
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

Re: Bug#556928: ITP: pyflag -- An advanced forensic tool for large volumes of log files

[Cristian Greco]

On Wed, 18 Nov 2009 10:05:41 -0200
Tiago Bortoletto Vaz  wrote:

> * Package name: pyflag
>   Version : 0.87-pre1
>   Upstream Author : Michael Cohen and David Collett
> 
> * URL : http://www.pyflag.net
> * License : GPL-2
>   Programming Lang: C, Python
>   Description : An advanced forensic tool for large volumes of log files
> 
> FLAG (Forensic and Log Analysis GUI) is an advanced forensic tool for the
> analysis of large volumes of log files and forensic investigations.

Hi Tiago,

you may consider joining the Debian Forensics team and maintaining this
package under its umbrella. :-)

Thanks,
--
Cristian Greco
GPG key ID: 0xCF4D32E4 (old: 0x0C095825)


signature.asc
Description: PGP signature

Bug#557026: ITP: gtkhotkey -- Gtk hotkey shared library

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: gtkhotkey
  Version : 0.2.1
  Upstream Author : Mikkel Kamstrup Erlandsen 
* URL : https://launchpad.net/gtkhotkey
* License : LGPL-3
  Programming Lang: C
  Description : Gtk hotkey shared library

Cross platform library for using desktop wide hotkeys.
Platform independent hotkey handling for Gtk+ applications.



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

Re: Bits from the FTPMaster meeting

[Manoj Srivastava]

On Wed, Nov 18 2009, Charles Plessy wrote:

> Le Wed, Nov 18, 2009 at 02:49:46PM +, Mark Brown a écrit :
>> 
>> The flip side of this is that it's just inviting maintainers to
>> decide they can't be bothered with porting effort and leaving ports
>> as second class citizens.
>
> It seems that the trend this year is to not trust the maintainers for
> anything…

It would seem that your remark below somewhat validate 

> How about the porters responsability towards the project ? For

They are also jointly responsible for trying to port stuff to
 their machines. We are, like, you know, in it together? Which is why
 the "project" is a plurality?

> instance, hppa is blocking the testing migration of a couple of my
> packages, and probably the packages of many other maintainers as
> well. Why would it be my duty to help people running Debian on
> machines that are not used in my profession, and for which I have no
> qualification at all? I do not want to prevent people having fun with

To try and make Debian better, rather than just be narrowly
 focused on your little fiefdom? 

The package maintianer is the resident expert Debian has for the
 package. If there are problems building it, the first line of
 defense is the package maintainer. I mean, dude, they are _your_
 packages that are not building on a supported architecture. If the
 problem is in the tool chain, the porters should take lead, but that is
 the lower probability scenario. Chances are the fix lies in your domain
 of expertise, namely, the package source.

> Debian on this arch, so wouldn't the best solution to never build my
> package on their arch in the first place?

No. The best solution is to fix the buggy package. Or deem it
 too buggy to be in Debian, of course.


> It would reduce the number of issues to solve in both groups, Debian
> Med and the hppa porters, which like every other group in Debian
> severely lack manpower.

If some package is so straining the resources of the teams, by
 being so fragile as to require a huge amount of effort on  a couple of
 architectures with no legitimate reason for being included in P-a-s,
 then the consideration should be to fix the package, or drop it, before
 relegating users of hppa to second class citizens -- as long as the
 project still supports hppa.

manoj
-- 
"Mind if I smoke?" "I don't care if you burst into flames and die!"
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bits from the FTPMaster meeting

[Kumar Appaiah]

(Note: I am not a porter, so please correct anything wrong I say
below)

On Thu, Nov 19, 2009 at 08:29:53AM +0900, Charles Plessy wrote:
> How about the porters responsability towards the project ? For instance, hppa
> is blocking the testing migration of a couple of my packages, and probably the
> packages of many other maintainers as well. Why would it be my duty to help
> people running Debian on machines that are not used in my profession, and for
> which I have no qualification at all?

Because of DFSG point 4: "Our priorities are our users and free
software".

Believe it or not, I've never _imagined_ that some software which are
in Debian are actually used on non-x86ish hardware. However, people
want to do weird things on weird non-x86ish machines, and they like
Debian because they Debian enables them to natively use the very same
tools used by ordinary PC users on, say, their embedded machines for
low power solutions for various automated tasks. They love it.

> I do not want to prevent people having fun with Debian on this arch,
> so wouldn't the best solution to never build my package on their
> arch in the first place? It would reduce the number of issues to
> solve in both groups, Debian Med and the hppa porters, which like
> every other group in Debian severely lack manpower.

Your complaint makes sense. But such policies are in place because
Debian wants to allow for all its users to have all goodness,
irrespective of computer type. While it may seem that your packages
are (unfairly) being blocked from migration due to one particular
architecture's lag, removing a package from that architecture would be
looked upon as a regression uniformly, irrespective of whether such
packages are used on that architecture or not. You never now on which
day someone would decide to try something fancy with your package on a
fancy architecture; we don't want to disappoint him/her by saying
"Hey, sorry, it was too painful for us to keep providing the package
on your architecture, so we just removed it"; (thereby, in my opinion,
not fulfilling DFSG 4).

Of course, if the architecture fails the release qualification, then
it's a different matter.
Kumar
-- 
Why are there always boycotts?  Shouldn't there be girlcotts too?
-- argon on #Linux


signature.asc
Description: Digital signature

Re: possible MBF about Policy 8.2 (Shared library support files)

[Goswin von Brederlow]

Russ Allbery  writes:

> Goswin von Brederlow  writes:
>
>> I mentioned before that there are a lot of packages that violate
>> Policy 8.2 Shared library support files:
>
>>   | If your package contains files whose names do not change with each
>>   | change in the library shared object version, you must not put them
>>   | in the shared library package. Otherwise, several versions of the
>>   | shared library cannot be installed at the same time without
>>   | filename clashes, making upgrades and transitions unnecessarily
>>   | difficult.
>
>> I detected 1063 possible violations with some percentage of false
>> positives. Since those are too many to go through by hand I filtered a
>> bit for the location of the violating files:
>
>> /etc/   : 137 packages
>> /bin/ or /usr/bin   : 285 packages
>> /sbin/ or /usr/sbin/: 47 packages
>
>> Still too many for one go and a huge overlap between the 3 cases so I
>> picked just packages that contained a shared library (as witnessed by
>> a shlibs file in the control.tar.gz) and files in /etc/. I considered
>> any file in /etc/ that does not contain a version in its path or name
>> that would make it distinct from a future SOVERSION in violation of
>> 8.2. I (hopefully) removed all false positives (leaving 126 packages).
>
> One of the potentially tricky parts of this, just to warn, is that Policy
> says just that the files need to change with each change to the SONAME,
> not that this has to be done in any specific way.  So while it's a lot
> cleaner to separate the package (I think), there are cases where we know,
> for some reason, that the upstream is either never going to change SONAME
> ever or that the file will be guaranteed to be obsolete and not included
> in the next revision.
>
> So there may be some cases here where people will say "this really doesn't
> apply to me."
>
> (For example, it probably doesn't really apply to glibc, since the chances
> of it changing SONAMEs are pretty low, although I do appreciate the libc
> maintainers breaking it apart anyway.)

This is true. On its own none of them are a policy violation if you
want to nit-pick. Only when a new SONAME is uploaded with the same
files is the policy really violated.

For that I have 2 things to consider:

1) How sure are you the SONAME never changes? How sure are you the
file will be obsolete in the next SONAME? How sure are you that you
will remember to rename all files on a SONAME change? If there is even
the slightest doubt the name should be changed now to a safe name so
the package is prepared for all eventualities.

With a verry few exceptions (like libc6) the risk of a future
collision is just to big. If that means you have to add a version to
the conffile or split the package now instead of in a year or two that
is regrettable but something I hope can be lived with.


2) Multiarch (are you hating that word yet?) is a release goal for squeeze

With multiarch the library should be installable for multiple
architectures so that (different) binaries from multiple architectures
that depend on it can be installed. E.g. /usr/bin/bar and /usr/bin/baz
both depending on libfoo.

If libfoo contains conffiles then they will give a file collision in
dpkg preventing the installation of more than one architecture. Having
the conffile in libfoo-common (Arch: all) avoids that. Using the arch
tripplet in the path or name avoids it too but should be only used
when conffiles are architecture specific.


Multiarch is actualy the reason libc-bin was created recently as
thereis no libc7 anywhere in sight that would require it. So jump on
the wagon and get your package prepared to meat the challenge of
multiarch.

MfG
Goswin


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

Re: Bits from the FTPMaster meeting

[Goswin von Brederlow]

Andreas Tille  writes:

> On Wed, Nov 18, 2009 at 07:41:51AM +0100, Luk Claes wrote:
>> 
>> I think one would be surprised how many packages get used on 'exotic'
>> architectures. Most users don't specifically search for a piece of
>> software, they want to have some specific task done by using a specific
>> package. Not providing the package will only mean that the user either
>> uses another package or does not get the task done.
>
> Well, I do not think that you can do gene sequencing or number crunching
> on current mobile phones.  So there are really programs which are not
> needed on all architectures and even if you find a binary package which
> claims to do the job it is just useless.  Even if I agree with your
> arguing that each program at least theoretically should build on any
> architecture (if not it is a bug) in some cases it looks foolish to
> provide binary packages just for the sake of it.  This is was Charles
> meant when he wrote: We should trust the maintainer if a specific
> program is not needed for a certain architecture.

And then someone comes along and builds a Supercomputer cluster out of
game consoles.

With the way energy consumption becomes important I would not be
surprised to see an arm supercomputer cluster next.

MfG
Goswin


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

Re: Bits from the FTPMaster meeting

[Goswin von Brederlow]

Felipe Sateler  writes:

> Luk Claes wrote:
>
>> You apparently fail to see that building the packages on mips uncovers
>> bugs that would otherwise be there, but take a longer time to uncover on
>> the 'mainstream' platforms.
>
> This is not generally true. There are are classes of bugs that appear on
> different platforms _due to being different platforms_, not just because

Unless you talk about hand optimized code the first 3 or 4 debian
archs will already have the bug. They might not all show it directly
but it will be there. The remaining archs then just make it more
likely a bug shows early.

> they were latent bugs waiting to be discovered. I presume that packages
> that require as much efficiency as possible (like Charles is implying in
> his packages) are very likely to implement platform-specific
> hacks/optimizations to run faster. It can be considered bad design, ugly
> and whatnot, but it is irrelevant if nobody ever uses other platforms.
>
> Saludos,
> Felipe Sateler

My take on this is that the code should first be written in a high
level form, e.g. generic C code that runs everywhere, and then only
parts that profiling show being worth it should be optimized.

The generic C code has 3 functions:

1) It is usualy much easier to understand and verify.

2) It can be used to compare results against the optimized code.

3) It can be used on archs where optimized code is too much work or
out of your expertise.


So all supporting all the different archs really costs is keeping the
generic C code current. And you should be using it to verify changes
in the optimized code on a continuing basis. Something that helps keep
the quality of the optimized code strong too.

MfG
Goswin


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

Re: Bits from the FTPMaster meeting

[Goswin von Brederlow]

Sune Vuorela  writes:

> On 2009-11-18, Gerfried Fuchs  wrote:
>>  I am a bit confused with respect to how buildd autosigning is required
>> for this. It makes it sound somehow like it would affect porter binary
>
> Basicalyl, the turnaround time is too long if we have to wait for manual
> buildd signings.
>
> For example, when we upload a new KDE, we usually upload a big chunk of
> source packages (3-5) where package 1 breaks last package.
>
> Currently, we can upload all source packages built for amd64 and i386
> and that way keep kde installable in unstable for more than 95 % of the
> users. 
>
> With 1 package signing per day (which is quite normal), we have 5 days
> where kde by itself is uninstallable on all archs, if the buildds have
> to build all packages by current means.
>
> With buildd autosigning, we probably only have a day or so on the fast
> archs with kde being uninstallable.
>
> and I have the impression that we will get quite many bug reports about
> kde being uninstallable. We arleady do that when kde is a part of
> another transition, and if kde is blocking itself on main archs, we will
> only get more.
>
> So yes, I really hope that 'source only' (or throw away binaries)
> uploads only get implemented when buildd autosigning is in place.
>
> (KDE doesn't have that many users on e.g. hppa, so the current
> turnaround time isn't that much of a problem outside the main archs)
>
> /Sune

An alternative way to solve this is to use build packages on the
buildd without waiting for them to be signed and uploaded. This would
require some coordination with wanna-build so later KDE packages are
only given to the buildd that has the earlier ones available.

The buildd would then build all of KDE and the buildd admin could sign
it all in one go. That way you have potentially 0 uninstallable time.

MfG
Goswin


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

Re: ITP: mercurial-buildpackage (for those who care about Mercurial)

[Goswin von Brederlow]

Jens Peter Secher  writes:

> Executive summary: If you use Mercurial and pbuilder for package
> maintenance you should try out mercurial-buildpackage in
> http://people.debian.org/~jps/squeeze/ .
>
> I have spent some time on making an improved version of
> hg-buildpackage, which turned out to become a complete rewrite now
> called mercurial-buildpackage.  The highlights are
>
>  * Support dpkg source format 3.0.

Integration of the hg stacked patches extenstion (don't remember the
name, the one giving you qpull/qpush) with 3.0 (quilt) format?

>  * Several .dsc can be imported to retain the full history when
>converting an existing package.
>
>  * Building via pbuilder is a breeze.
>
>  * Easily parsable output; same format as Lintian or Piuparts.
>
>  * Complains if the repository has uncommited changes (unless --force).
>
>  * Only one repository.  Branches are used to keep upstream separate.

Support for pristine-tar?

> I will now work on getting backporting, downstreaming (Ubuntu etc.) to
> be a breeze (breezy?) too. 
>
>
> Cheers,

Much appreciated.

MfG
Goswin


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

Re: Bits from the FTPMaster meeting

[Carlo Segre]

On Mon, 16 Nov 2009, Steffen Joeris wrote:


On Mon, 16 Nov 2009 02:04:28 pm Carlo Segre wrote:

On Sun, 15 Nov 2009, Joerg Jaspert wrote:

The current "winning" opinion is to go with the source+throw away
binaries route.  We are close to being able to achieve this, it is
simply that it has not yet been enabled.  Before any version of this
can be enabled, buildd autosigning needs to be implemented in order
that dak can differentiate buildd uploads vs maintainer uploads.


It may be necessary to also move the building of contrib packages to the
unofficial non-free buildd network.  As it stands any contrib package
which has a non-free Build-Depends is not guaranteed to build on all
architectures since not all the buildd systems include the non-free
archives.  Up to now it has been possible to do binary uploads to work
around this and get as many architectures in the archive as possible to
build manually.  When this new option is enabled, it will no longer be
possible.

As I understood it, it is still possible for DDs to do binary-only uploads (as
allowed per GR). This throwing away of the binary package is only for the
initial source+binary upload.
(In an ideal world, there should be no need for DDs to do binary-only uploads
by hand, but in reality it has to happen every now and then, at least for
security).


I suppose that is correct.  It still makes sense to me that the contrib 
packages be built on the non-free autobuilders for practical reasons I 
have mentioned above.


Cheers,

Carlo


--
Carlo U. Segre -- Professor of Physics
Associate Dean for Graduate Admissions, Graduate College
Illinois Institute of Technology
Voice: 312.567.3498Fax: 312.567.3494
se...@iit.edu   http://www.iit.edu/~segre   se...@debian.org


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

Re: Bits from the FTPMaster meeting

[Luk Claes]

Goswin von Brederlow wrote:
> Sune Vuorela  writes:
> 
>> On 2009-11-18, Gerfried Fuchs  wrote:
>>>  I am a bit confused with respect to how buildd autosigning is required
>>> for this. It makes it sound somehow like it would affect porter binary
>> Basicalyl, the turnaround time is too long if we have to wait for manual
>> buildd signings.
>>
>> For example, when we upload a new KDE, we usually upload a big chunk of
>> source packages (3-5) where package 1 breaks last package.
>>
>> Currently, we can upload all source packages built for amd64 and i386
>> and that way keep kde installable in unstable for more than 95 % of the
>> users. 
>>
>> With 1 package signing per day (which is quite normal), we have 5 days
>> where kde by itself is uninstallable on all archs, if the buildds have
>> to build all packages by current means.
>>
>> With buildd autosigning, we probably only have a day or so on the fast
>> archs with kde being uninstallable.
>>
>> and I have the impression that we will get quite many bug reports about
>> kde being uninstallable. We arleady do that when kde is a part of
>> another transition, and if kde is blocking itself on main archs, we will
>> only get more.
>>
>> So yes, I really hope that 'source only' (or throw away binaries)
>> uploads only get implemented when buildd autosigning is in place.
>>
>> (KDE doesn't have that many users on e.g. hppa, so the current
>> turnaround time isn't that much of a problem outside the main archs)
>>
>> /Sune
> 
> An alternative way to solve this is to use build packages on the
> buildd without waiting for them to be signed and uploaded. This would
> require some coordination with wanna-build so later KDE packages are
> only given to the buildd that has the earlier ones available.

This could only work if the built package is needed on the same buildd
it was built.

> The buildd would then build all of KDE and the buildd admin could sign
> it all in one go. That way you have potentially 0 uninstallable time.

It's very unlikely that the builds for all these packages ends up on the
same buildd, so in practice that would not work. It could be an
improvement though.

Cheers

Luk


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

Re: Bits from the FTPMaster meeting

[Mike Hommey]

On Wed, Nov 18, 2009 at 11:16:41PM +, Sune Vuorela wrote:
> On 2009-11-18, Gerfried Fuchs  wrote:
> >  I am a bit confused with respect to how buildd autosigning is required
> > for this. It makes it sound somehow like it would affect porter binary
> 
> Basicalyl, the turnaround time is too long if we have to wait for manual
> buildd signings.
> 
> For example, when we upload a new KDE, we usually upload a big chunk of
> source packages (3-5) where package 1 breaks last package.
> 
> Currently, we can upload all source packages built for amd64 and i386
> and that way keep kde installable in unstable for more than 95 % of the
> users. 
> 
> With 1 package signing per day (which is quite normal), we have 5 days
> where kde by itself is uninstallable on all archs, if the buildds have
> to build all packages by current means.

Stupid question: If all these packages are interdependent and need to be
built the same day, why not upload them as a single package ?

It's even easier now, with the new source formats.

Mike


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