ITP: efilinux -- A UEFI bootloader

[Nobuhiro Iwamatsu]

Package: wnpp
Owner: Nobuhiro Iwamatsu 
Severity: wishlist

*** Please type your report below this line ***

* Package name: efilinux
  Version : 0.8.0
  Upstream Author : Matt Fleming 
* URL : http://www.kernel.org/pub/linux/boot/efilinux/
* License : BSD
  Programming Lang: C
  Description : A UEFI bootloader

efilinux is a UEFI OS loader. This has no bells or whistles,
it is simply a prototype with the minimum amount of smarts required
to load a linux kernel (though loaders for other formatscould be added).


-- 
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/CABMQnVJTwL=yhnq8ehqqbuuvzv1vpprv4w4ew1g6czyt8oc...@mail.gmail.com

Bug#639756: ITP: recorditnow -- Qt/KDE application to record the desktop

[Eshat Cakar]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: recorditnow
Version: 0.8.1
Upstream Author: Kai Dombrowe 
URL: http://recorditnow.sourceforge.net/
License: GPLv2
Description: Qt/KDE application to capture desktop

-- 
eshat cakar
web: www.eshat.de   gpg-id: 799B 95D5



-- 
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/201108300029.28483.i...@eshat.de

Re: getting permission denied with shmat() as non-root

[Timothy Stotts]

Thanks Peter. That was the tip I needed for debugging the program on the
Debian system. ipcs(1), when run as the same user as the program, did
not show any shared memory being created. However, running ipcs(1) as
root showed the memory being created by the non-root user with
permissions of . Obviously, it should be 0660 or something similar,
so I corrected the issue by or'ing the permissions with the create flags
as the last argument to the function shmget(). Cheers.

Timothy Stotts

On Sun, 2011-08-28 at 21:11 +1000, Peter Miller wrote:
> On Sat, 2011-08-27 at 20:44 -0400, Timothy Stotts wrote:
> > I am using ftok(), shmget(), shmat() to obtain a small quantity of
> > shared memory for the application. As root, the shmat() function
> > succeeds on the embedded system. However, on the Debian system the
> > shmat() function returns -1 with an error code of EACCES, indicating
> > permission denied.
> 
> This means that the shared memory exists, or you would get EINVAL.
> The ipcs command may be used to list information about shared memory,
> and other ipc facilities.  Try using ipcs(1) to see if there is a an
> owner and/or permissions mismatch for the shmid you are using.
> 
> 
> -- 
> Peter Miller 
> 
> 



-- 
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/1314656509.2359.5.camel@pedahzur

Re: Maintainers, porters, and burden of porting

[Philipp Kern]

On 2011-08-29, Russ Allbery  wrote:
> Samuel Thibault  writes:
>> Lucas Nussbaum, le Mon 29 Aug 2011 16:49:17 +0200, a écrit :
>>> Those packages should be set Not-For-Us anyway, no? So they still need
>>> an action from porters or buildd maintainers.
>> We want to avoid Not-For-Us. Maintainers should simply set the
>> architecture list.
> Does this work now?  Previously, setting the architecture list didn't do
> anything useful if the source package built at least one arch: all
> package.

Policy says this:

766a66d2 (Manoj Srivastava 2005-06-16 05:43:33 +  3015) 
8ec4f17a (Russ Allbery 2010-06-01 15:47:48 -0700  3016)   Specifying a list 
of architectures or architecture wildcards
8ec4f17a (Russ Allbery 2010-06-01 15:47:48 -0700  3017)   indicates that 
the source will build an architecture-dependent
8ec4f17a (Russ Allbery 2010-06-01 15:47:48 -0700  3018)   package, and will 
only work correctly on the listed or
8ec4f17a (Russ Allbery 2010-06-01 15:47:48 -0700  3019)   matching 
architectures.  If the source package also builds at
8ec4f17a (Russ Allbery 2010-06-01 15:47:48 -0700  3020)   least one 
architecture-independent package, all will
8ec4f17a (Russ Allbery 2010-06-01 15:47:48 -0700  3021)   also be included 
in the list.
e7a3eb89 (Manoj Srivastava 2005-06-16 05:40:10 +  3022) 

And actually I requested that change in dpkg before policy was adjusted.  (My
bad, didn't know it better at that time.)  So yeah, that's checked by
wanna-build since some time already.

Also I just saw that buxy committed the "any all" change to policy, which is
nice and will finally tell us which packages need arch:all building at all.

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
Archive: http://lists.debian.org/slrnj5o22r.fje.tr...@kelgar.0x539.de

Re: Maintainers, porters, and burden of porting

[Andreas Barth]

* Russ Allbery (r...@debian.org) [110829 20:42]:
> Samuel Thibault  writes:
> > Lucas Nussbaum, le Mon 29 Aug 2011 16:49:17 +0200, a écrit :
> 
> >> Those packages should be set Not-For-Us anyway, no? So they still need
> >> an action from porters or buildd maintainers.
> 
> > We want to avoid Not-For-Us. Maintainers should simply set the
> > architecture list.
> 
> Does this work now?  Previously, setting the architecture list didn't do
> anything useful if the source package built at least one arch: all
> package.

That should be changed some months ago. If not, please give me an
example package and I'll fix it.


Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110829203803.gi15...@mails.so.argh.org

Re: Maintainers, porters, and burden of porting

[Cyril Brulebois]

Russ Allbery  (29/08/2011):
> Does this work now?  Previously, setting the architecture list didn't
> do anything useful if the source package built at least one arch: all
> package.

Since arch: all as per-arch (…) now, I guess that limitation is gone.

And yes, arch restrictions have been working for a while (several months
at the very least).

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Maintainers, porters, and burden of porting

[Russ Allbery]

Samuel Thibault  writes:
> Lucas Nussbaum, le Mon 29 Aug 2011 16:49:17 +0200, a écrit :

>> Those packages should be set Not-For-Us anyway, no? So they still need
>> an action from porters or buildd maintainers.

> We want to avoid Not-For-Us. Maintainers should simply set the
> architecture list.

Does this work now?  Previously, setting the architecture list didn't do
anything useful if the source package built at least one arch: all
package.

-- 
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/874o10cb56@windlord.stanford.edu

Re: Maintainers, porters, and burden of porting

[Jonathan Nieder]

Lucas Nussbaum wrote:

> We might chose to make ruby1.9.1 the default ruby implementation for
> wheezy (instead of ruby1.8).  I still hope that all porting issues
> affecting ruby1.9.1 will be resolved.
> But if it's down to those four choices, what should I do in a couple of
> weeks, when the new upstream release will be available?
> (1) not upload the next ruby release to unstable until porting issues
> are fixed
> (2) disable the test suite on architectures where it fails, so that the
> package can build and migrate to testing (but it will be completely
> broken, which might annoy DSA, e.g because of puppet)
> (3) request removal of ruby binaries on architectures where it fails to
> build
> (4) orphan ruby1.9.1 ;)

What gcc seems to do (though I may be understanding incorrectly) is
to allow the default version to vary by architecture.  People
interested in a given architecture are expected to do some work to
allow a modern version to be used, and if that doesn't happen, it's a
bad sign and accounted for in the usual ways.  Which I guess is
closest to (2) or (3), depending on the nature of the test failures.

I can understand if there are details involved that make that not
work here, though.


-- 
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/20110829180607.ga9...@elie.gateway.2wire.net

Re: Maintainers, porters, and burden of porting

[Jonathan Nieder]

Hi Lucas,

Lucas Nussbaum wrote:

> But if porting software to
> KFreeBSD's linuxthreads-based threading library with slightly broken
> semantics becomes my own task, I won't try to solve issues on KFreeBSD
> and instead stop supporting it, because I just don't have the time to do
> that.

That sounds reasonable.  I think a good policy in a case like this is,
"if a co-maintainer interested in this feature (support for platforms
that don't use NPTL) doesn't step up, I am dropping it".  In other
words, the burden for keeping such a feature is even higher than you
said --- what is needed is not a porter but someone interested in and
familiar with both the package and linuxthreads.

The problem with saying "that's the porters' job" is that then nobody
will want to be a porter. :)

Thanks for your hard work!
Jonathan


-- 
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/20110829174922.ga9...@elie.gateway.2wire.net

Re: Maintainers, porters, and burden of porting

[Bastian Blank]

On Mon, Aug 29, 2011 at 04:49:17PM +0200, Lucas Nussbaum wrote:
> On 29/08/11 at 16:16 +0200, Bernd Zeimetz wrote:
> > or test suites failing for various random reasons.
> Like what? In my experience rebuilding the archive on amd64, there are
> only a handful of packages where the test suite fails randomly. If it
> fails randomly only on $PORTER_ARCH, it's likely to be an indication of
> a bug in toolchain/libc/kernel/whatever that only triggers through a
> race condition. And that's clearly porter's business.

My experience shows that many errors are hidden undefined behaviours in
the source somewhere. Especially in C and C++ this error-class is easily
missed.

Bastian

-- 
Four thousand throats may be cut in one night by a running man.
-- Klingon Soldier, "Day of the Dove", stardate unknown


-- 
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/20110829173939.ga1...@wavehammer.waldi.eu.org

Re: Maintainers, porters, and burden of porting

[Lucas Nussbaum]

On 29/08/11 at 18:21 +0200, Bernd Zeimetz wrote:
> On 08/29/2011 04:49 PM, Lucas Nussbaum wrote:
> [...]
> >> In my experience you would get a lot of issues which are nothing porters
> >> need to solve, like libraries not being available as the hardware just
> >> doesn't exist for that architecture
> > 
> > Those packages should be set Not-For-Us anyway, no? So they still need
> > an action from porters or buildd maintainers.
> 
> No, for example zbar ships an example application which uses a webcam to
> read barcodes and the necessary webcam libraries are (or were!?) not
> available on freebsd and hurd - so only the build of that single example
> had to be disabled while recognizing barcodes from images works well of
> course and the library builds fine.

I think that bugs caused by important differences compared to other
Debian architectures are the porter's job to handle, not the
maintainer's.
That includes stuff like:
- missing/different packages on $ARCH
- missing/different libraries on $ARCH
- different libc semantics on $ARCH (hi kfreebsd+hurd!)
etc.

KFreeBSD is a very nice experiment, and the KFreeBSD porters are
amongst the most helpful I've been talking to. But if porting software to
KFreeBSD's linuxthreads-based threading library with slightly broken
semantics becomes my own task, I won't try to solve issues on KFreeBSD
and instead stop supporting it, because I just don't have the time to do
that.

> >> If you want a help from a porter,
> > 
> > As a maintainer, I don't want to be in a situation where I need help
> > from porters. I would like porters to feel responsible for packages on
> > their architectures. Of course, if porters want help from me, I will do
> > my best to help them. But it shouldn't work the other way around.
> 
> Imho it can only work the other way round or we need a LOT more porters,
> and that won't happen.
> 
> > I'm also completely tired of investigating issues which are already
> > known to porters, which is unavoidable if each maintainer is asked
> > to first do the investigation and then ask porters for help.
> 
> I'm sure there are issues where even porters can't tell you its a
> known one without a lot of debugging.  Also there is google which is
> very helpful in finding problems on weird architectures.

Only once you have pinpointed a specific problem. In my case, it often
means going from a broken Ruby script to a minimal test case in Ruby, to
Ruby's C code, to a minimal test case in C.

> >> imho you should present a problem in a way which is easy reproducible
> >> - I don't think that we should expect from porters that they debug
> >> your program's test suite for you.
> > 
> > Note that failed builds are usually easily reproducible. Just try to
> > build the package. It fails. Reducing the failure to a minimal test case
> > usually takes hours of hard work, which are often useless, because when
> > you finally share the test case with the porters' list, a porter usually
> > says "oh, that must be $COMMON_PROBLEM_WITH_PORT".
> 
> If a failed build is easy reproducible, where is the problem for a
> maintainer to come up with something easy to reprouce for a porter?
> Anf when it is not easy reproducible or some easy way to create a test
> case is not obviously - why should a porter do the work if you as
> maintainer probably know the source times better than the porter and you
> should be able to come up with something useful to debug much faster? We
> don't have enough porters to throw all the longish tasks on them, imho
> the maintainer should go to porters with an arch specific problem to
> solve, not with 'fix my package'.

The porter should do the work become he cares about that architecture.
I'm perfectly fine with helping porters get my packages ported to the
architectures they care about. I'm not fine with having to spend a lot
of time porting my packages to 'experimental' ports.

Anyway, I'm just trying to see if we can find ways to work better
together, since all those ports are a very important feature of Debian.
But it doesn't sound easy...

- Lucas


-- 
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/20110829171517.ga18...@xanadu.blop.info

Bug#639715: ITP: libjsoup-java -- Java HTML parser that makes sense of real-world HTML soup

[Torsten Werner]

Package: wnpp
Severity: wishlist
Owner: Torsten Werner 

* Package name: libjsoup-java
  Version : 1.6.1
  Upstream Author : Jonathan Hedley
* URL : http://jsoup.org/
* License : MIT
  Programming Lang: Java
  Description : Java HTML parser that makes sense of real-world HTML soup

 Jsoup is a Java library for working with real-world HTML. It provides a very
 convenient API for extracting and manipulating data, using the best of DOM,
 CSS, and jquery-like methods.
 .
 jsoup implements the WHATWG HTML specification (http://whatwg.org/html), and
 parses HTML to the same DOM as modern browsers do.
 .
   * parse HTML from a URL, file, or string
   * find and extract data, using DOM traversal or CSS selectors
   * manipulate the HTML elements, attributes, and text
   * clean user-submitted content against a safe white-list, to prevent XSS
   * output tidy HTML
 .
 jsoup is designed to deal with all varieties of HTML found in the wild; from
 pristine and validating, to invalid tag-soup; jsoup will create a sensible
 parse tree.

Jsoup is a build dependency for release 1.0 of wagon.

Torsten



-- 
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/20110829170103.ga2...@lumpi.twerner42.de

Re: Maintainers, porters, and burden of porting

[Andreas Barth]

* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110829 13:10]:
> If you take a list of packages that failed on $PORTER_ARCH, but built
> fine on at least two or three other architectures, do you really expect
> to get many false positives (i.e, non-arch-specific problems)?

If we have methods which produce reliable lists packages for porters
to check, I'm all for it. But if it takes more time for the porters to
get rid of false positives, then we need to do something different.

Until however an issue has been handed over to the porters explicitly,
it's still the maintainers task to take care of it. Even if it only
means handing it over to the porters in an appropriate way. (And
of course, the maintainer still needs to help, and can't just yell "my
package doesn't build, fix it" to the porters. Especially as the
maintainer has valid package-specific knowledge in many cases.)



Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110829165703.gh15...@mails.so.argh.org

Re: Maintainers, porters, and burden of porting

[Bernd Zeimetz]

On 08/29/2011 04:49 PM, Lucas Nussbaum wrote:
[...]
>> In my experience you would get a lot of issues which are nothing porters
>> need to solve, like libraries not being available as the hardware just
>> doesn't exist for that architecture
> 
> Those packages should be set Not-For-Us anyway, no? So they still need
> an action from porters or buildd maintainers.

No, for example zbar ships an example application which uses a webcam to
read barcodes and the necessary webcam libraries are (or were!?) not
available on freebsd and hurd - so only the build of that single example
had to be disabled while recognizing barcodes from images works well of
course and the library builds fine.

>> or test suites failing for various random reasons.
> 
> Like what? In my experience rebuilding the archive on amd64, there are
> only a handful of packages where the test suite fails randomly. If it
> fails randomly only on $PORTER_ARCH, it's likely to be an indication of
> a bug in toolchain/libc/kernel/whatever that only triggers through a
> race condition. And that's clearly porter's business.

Doesn't make me wonder. I guess most software is well tested on amd64
and i386.


>> If you want a help from a porter,
> 
> As a maintainer, I don't want to be in a situation where I need help
> from porters. I would like porters to feel responsible for packages on
> their architectures. Of course, if porters want help from me, I will do
> my best to help them. But it shouldn't work the other way around.

Imho it can only work the other way round or we need a LOT more porters,
and that won't happen.

> I'm also completely tired of investigating issues which are already
> known to porters, which is unavoidable if each maintainer is asked to
> first do the investigation and then ask porters for help.

I'm sure there are issues where even porters can't tell you its a known
one without a lot of debugging. Also there is google which is very
helpful in finding problems on weird architectures.


>> imho you should present a problem in a way which is easy reproducible
>> - I don't think that we should expect from porters that they debug
>> your program's test suite for you.
> 
> Note that failed builds are usually easily reproducible. Just try to
> build the package. It fails. Reducing the failure to a minimal test case
> usually takes hours of hard work, which are often useless, because when
> you finally share the test case with the porters' list, a porter usually
> says "oh, that must be $COMMON_PROBLEM_WITH_PORT".

If a failed build is easy reproducible, where is the problem for a
maintainer to come up with something easy to reprouce for a porter?
Anf when it is not easy reproducible or some easy way to create a test
case is not obviously - why should a porter do the work if you as
maintainer probably know the source times better than the porter and you
should be able to come up with something useful to debug much faster? We
don't have enough porters to throw all the longish tasks on them, imho
the maintainer should go to porters with an arch specific problem to
solve, not with 'fix my package'.


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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e5bbc9a.8010...@bzed.de

Re: Dependencies of metapackages

[Andrey Rahmatullin]

On Mon, Aug 29, 2011 at 04:40:30PM +0100, Wolodja Wentland wrote:
> they decided to remove one of (typically) gnome's dependencies, which
> caused the metapackage to be removed as well. 
That also causes an effect of "GNOME gets removed!" even without any
additional autoremoved packages :(

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Dependencies of metapackages

[Wolodja Wentland]

Hi all,

is there a specific reason why metapackages depend rather then recommend
packages they are meant to pull in?

The rationale behind this question is [0] that we see a plethora of users in
#debian who ask questions like:

"Why did apt remove all my system??⸘one!one!eleven!"

and we have to explain to them that it is because they decided to remove one
of (typically) gnome's dependencies, which caused the metapackage to be
removed as well. The solution is then to either mark all other dependencies as
manually installed, install a smaller metapackage or a combination of those.

As this is a common problem of our users I was thinking why we don't make it
easier for them to slim down their system after they've done a default
installation. Are there any drawbacks to this change in metapackage semantics
that I am not aware of?

[0] The rationale is also more or less the same as the one formulated for
DEP-6
http://dep.debian.net/deps/dep6/
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: Maintainers, porters, and burden of porting

[Lucas Nussbaum]

On 29/08/11 at 13:06 +0200, Lucas Nussbaum wrote:
> If you take a list of packages that failed on $PORTER_ARCH, but built
> fine on at least two or three other architectures, do you really expect
> to get many false positives (i.e, non-arch-specific problems)?

Such a list would be easy to generate using UDD, and I might even do it,
if porters find it useful (and fix all the Ruby porting issues. j/k).

What would be needed for making it "optimally useful"?
- list of packages that FTBFS on $ARCH
- state on other architectures
- list of bugs with architecture usertags for that package
- list of other bugs matching FTBFS, build, or an architecture for that
  package
- links to BTS, PTS, buildd.d.o 

What else?

Would you use it?

L.


-- 
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/20110829151900.ga13...@xanadu.blop.info

Re: Maintainers, porters, and burden of porting

[Samuel Thibault]

Lucas Nussbaum, le Mon 29 Aug 2011 16:49:17 +0200, a écrit :
> On 29/08/11 at 16:16 +0200, Bernd Zeimetz wrote:
> > On 08/29/2011 01:06 PM, Lucas Nussbaum wrote:
> > > On 29/08/11 at 09:47 +0200, Andreas Barth wrote:
> > >> * Lucas Nussbaum (lu...@lucas-nussbaum.net) [110829 08:59]:
> > >>> I'd like to reinforce the fact that it's the porters' responsibility 
> > >>> to investigate porters issues, and propose the following
> > >>> responsibilities:
> > >>> (1) It is the responsibility of porters to:
> > >>> - track architecture-specific bugs (build failures, toolchain
> > >>>   issues, etc)
> > >>> - investigate and solve such bugs
> > >>
> > >> Sorry, but I disagree here. I don't think it is reasonable to expect
> > >> porters to check for build failures in general, especially as many of
> > >> them just happen because of generic maintainer errors and
> > >> cross-architectures.
> > > 
> > > I'm not saying that porters should check for build failures in general.
> > > 
> > > If you take a list of packages that failed on $PORTER_ARCH, but built
> > > fine on at least two or three other architectures, do you really expect
> > > to get many false positives (i.e, non-arch-specific problems)?
> > 
> > In my experience you would get a lot of issues which are nothing porters
> > need to solve, like libraries not being available as the hardware just
> > doesn't exist for that architecture
> 
> Those packages should be set Not-For-Us anyway, no? So they still need
> an action from porters or buildd maintainers.

We want to avoid Not-For-Us. Maintainers should simply set the
architecture list.

> Note that failed builds are usually easily reproducible. Just try to
> build the package. It fails. Reducing the failure to a minimal test case
> usually takes hours of hard work, which are often useless, because when
> you finally share the test case with the porters' list, a porter usually
> says "oh, that must be $COMMON_PROBLEM_WITH_PORT".

Such common problems should ideally be documented.

Samuel


-- 
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/20110829145553.gg3...@type.u-bordeaux.fr

Re: Maintainers, porters, and burden of porting

[Lucas Nussbaum]

On 29/08/11 at 16:16 +0200, Bernd Zeimetz wrote:
> On 08/29/2011 01:06 PM, Lucas Nussbaum wrote:
> > On 29/08/11 at 09:47 +0200, Andreas Barth wrote:
> >> * Lucas Nussbaum (lu...@lucas-nussbaum.net) [110829 08:59]:
> >>> I'd like to reinforce the fact that it's the porters' responsibility 
> >>> to investigate porters issues, and propose the following
> >>> responsibilities:
> >>> (1) It is the responsibility of porters to:
> >>> - track architecture-specific bugs (build failures, toolchain
> >>>   issues, etc)
> >>> - investigate and solve such bugs
> >>
> >> Sorry, but I disagree here. I don't think it is reasonable to expect
> >> porters to check for build failures in general, especially as many of
> >> them just happen because of generic maintainer errors and
> >> cross-architectures.
> > 
> > I'm not saying that porters should check for build failures in general.
> > 
> > If you take a list of packages that failed on $PORTER_ARCH, but built
> > fine on at least two or three other architectures, do you really expect
> > to get many false positives (i.e, non-arch-specific problems)?
> 
> In my experience you would get a lot of issues which are nothing porters
> need to solve, like libraries not being available as the hardware just
> doesn't exist for that architecture

Those packages should be set Not-For-Us anyway, no? So they still need
an action from porters or buildd maintainers.

> or test suites failing for various random reasons.

Like what? In my experience rebuilding the archive on amd64, there are
only a handful of packages where the test suite fails randomly. If it
fails randomly only on $PORTER_ARCH, it's likely to be an indication of
a bug in toolchain/libc/kernel/whatever that only triggers through a
race condition. And that's clearly porter's business.

> If you want a help from a porter,

As a maintainer, I don't want to be in a situation where I need help
from porters. I would like porters to feel responsible for packages on
their architectures. Of course, if porters want help from me, I will do
my best to help them. But it shouldn't work the other way around.

I'm also completely tired of investigating issues which are already
known to porters, which is unavoidable if each maintainer is asked to
first do the investigation and then ask porters for help.

> imho you should present a problem in a way which is easy reproducible
> - I don't think that we should expect from porters that they debug
> your program's test suite for you.

Note that failed builds are usually easily reproducible. Just try to
build the package. It fails. Reducing the failure to a minimal test case
usually takes hours of hard work, which are often useless, because when
you finally share the test case with the porters' list, a porter usually
says "oh, that must be $COMMON_PROBLEM_WITH_PORT".

- Lucas


-- 
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/20110829144917.ga12...@xanadu.blop.info

Bug#639701: ITP: festvox-ca-ona-hts -- Catalan text to speech voice for festival. 16kHz, HTS, female.

[Sergio Oller]

Package: wnpp
Severity: wishlist
Owner: Sergio Oller 

* Package name: festvox-ca-ona-hts
  Version : 1.0
  Upstream Author : Sergio Oller 
* URL : http://www.talp.cat/festcat/
* License : LGPL
  Programming Lang: Lisp
  Description : Catalan text to speech voice for festival. 16kHz, HTS,
female.



-- 
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/20110829143537.2880.94113.reportbug@localhost6.localdomain6

Re: Maintainers, porters, and burden of porting

[Bernd Zeimetz]

On 08/29/2011 01:06 PM, Lucas Nussbaum wrote:
> On 29/08/11 at 09:47 +0200, Andreas Barth wrote:
>> * Lucas Nussbaum (lu...@lucas-nussbaum.net) [110829 08:59]:
>>> I'd like to reinforce the fact that it's the porters' responsibility 
>>> to investigate porters issues, and propose the following
>>> responsibilities:
>>> (1) It is the responsibility of porters to:
>>> - track architecture-specific bugs (build failures, toolchain
>>>   issues, etc)
>>> - investigate and solve such bugs
>>
>> Sorry, but I disagree here. I don't think it is reasonable to expect
>> porters to check for build failures in general, especially as many of
>> them just happen because of generic maintainer errors and
>> cross-architectures.
> 
> I'm not saying that porters should check for build failures in general.
> 
> If you take a list of packages that failed on $PORTER_ARCH, but built
> fine on at least two or three other architectures, do you really expect
> to get many false positives (i.e, non-arch-specific problems)?

In my experience you would get a lot of issues which are nothing porters
need to solve, like libraries not being available as the hardware just
doesn't exist for that architecture or test suites failing for various
random reasons.
If you want a help from a porter, imho you should present a problem in a
way which is easy reproducible - I don't think that we should expect
from porters that they debug your program's test suite for you.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e5b9f27.6000...@bzed.de

Re: Maintainers, porters, and burden of porting

[Lucas Nussbaum]

On 29/08/11 at 09:47 +0200, Andreas Barth wrote:
> * Lucas Nussbaum (lu...@lucas-nussbaum.net) [110829 08:59]:
> > I'd like to reinforce the fact that it's the porters' responsibility 
> > to investigate porters issues, and propose the following
> > responsibilities:
> > (1) It is the responsibility of porters to:
> > - track architecture-specific bugs (build failures, toolchain
> >   issues, etc)
> > - investigate and solve such bugs
> 
> Sorry, but I disagree here. I don't think it is reasonable to expect
> porters to check for build failures in general, especially as many of
> them just happen because of generic maintainer errors and
> cross-architectures.

I'm not saying that porters should check for build failures in general.

If you take a list of packages that failed on $PORTER_ARCH, but built
fine on at least two or three other architectures, do you really expect
to get many false positives (i.e, non-arch-specific problems)?

- Lucas


-- 
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/20110829110615.ga4...@xanadu.blop.info

Re: Maintainers, porters, and burden of porting

[Andreas Barth]

* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110829 08:59]:
> I'd like to reinforce the fact that it's the porters' responsibility 
> to investigate porters issues, and propose the following
> responsibilities:
> (1) It is the responsibility of porters to:
> - track architecture-specific bugs (build failures, toolchain
>   issues, etc)
> - investigate and solve such bugs

Sorry, but I disagree here. I don't think it is reasonable to expect
porters to check for build failures in general, especially as many of
them just happen because of generic maintainer errors and
cross-architectures.

It is the responsiblity of the maintainer to track whether his
packages build, and, in case build failures are not easily resolveable by
the maintainer and are architecture-specific, to contact the porters.
(This doesn't read as "the maintainer needs to fix all the bugs"
though.)

>From here on, I agree if it are portability issues, the porters have
to start caring and to provide fixes.

> (3) When porters are failing to do (1), we should investigate ways to
> continue to support these ports without releasing them as stable
> architectures.

This mechanismn is already in place, and was used more than once in
the past. Though it hurts, we have done it, and we will definitly EOL
further architectures in due time.




Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110829074725.gg15...@mails.so.argh.org