Statistics for licenses?
Hello, I am preparing a document to advocate further use of open-source software in my organization. I am looking for some statistics of the [main] licenses used in Debian packages (or some statistics about the license used in open-source software at large). Are you aware of such analyze? Thanks, Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531581: Critical problems on hppa and ia64 buildds
Luk Claes wrote: >> That doesn't solve my problem: Should I > >> - make sure that the porters, buildd admins etc. are aware of the >> problem and simply close the bug? > > You might want to downgrade the bug and only close it when it is realy > solved? And what would be the criterion for "solved"? After an analysis of N build logs of random packages on that buildd show no segfaults any more? I am not going to do that. It's not a bug in my package; I am not going to take responsibility for it. >>> The one on ia64 breaks the buildd's chroot and looks to be easily solved >>> by making sure that the maintainer scripts don't fail when the missing >>> command is not available. >> >> ? >> >> It could be easily solved by making sure that nothing on the buildd >> installs packages without installing their dependencies. > > A patch is appreciated, thanks for your cooperation. Excuse me - that should already be guaranteed by dpkg, or am I missing something? If it isn't on that machine, what kind of patch should I write? Regards, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
On Jun 04, Giacomo Catenazzi wrote: > Do we really need to handle such hotplugs? We could require that > all boot hardwares must be available short after boot loader. The > later plugged hardware will be shown only later, when the system > in up. I see no disadvantage, and make thing easier, more > testable (and I think also more secure). The complexity required to decide and configure which events should be delayed and when, and implementing the infrastructure needed to do this. If you have further opinions about this please bring them to the upstream mailing list. -- ciao, Marco signature.asc Description: Digital signature
Re: no deprecation of /usr as a standalone filesystem
Ken Bloom writes: > Josselin Mouette wrote: >> Le lundi 01 juin 2009 à 16:26 +0200, Goswin von Brederlow a écrit : >> > > What has the initramfs got to do with this? >> > >> > For / to be on LVM you need an initramfs. / on raid (with custom >> > kernel) or plain partition works without one. >> >> I already know that, thanks, but it still doesnât make your point. Just >> because you have some religious taboo against initramfs doesnât make it >> an invalid solution. > > Go back and look at what Goswin wrote in the first place: > >> As long as debian does not provide support for kernel independent non >> breaking initramfs support (i.e. not regenerated on every whim and >> break) having / outside lvm and no initramfs is a real plus. > > It sounds like he feels that having an initramfs is very fragile the way > Debian handles it now. If / is outside of lvm, then when the initramfs > breaks, he can boot up without it and get to a place where he can > regenerate an initramfs. That's not "a religious taboo against > initramfs." That's sensible troubleshooting behavior. > > --Ken Not quite. I don't need an initramfs at all. I boot with root=/dev/md0 using the raid autodetect of the kernel. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531581: Critical problems on hppa and ia64 buildds
On 2009-06-04, Frank Küster wrote: > And what would be the criterion for "solved"? After an analysis of > N build logs of random packages on that buildd show no segfaults any > more? I am not going to do that. > > It's not a bug in my package; I am not going to take responsibility for > it. There are two issues: one that a buildd has random segfaults. That's sadly common on hppa and ought to be ignored. Secondly a package messes up the buildd's chroot on ia64. There is no such segfault excuse. Such issues could also happen on other machines and don't have anything to do with the buildd using unauthenticated packages. 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: realtime kernel for Debian
Uwe Kleine-König wrote: Hi, I was wondering about how far are we with implementing a RT kernel in Debian... Some progress here? Would be nice. The patch I created that "fits" on Debian's vanilla kernel creates conflicts on the sources with the Debian patches. I hope to be able to clean that up by minimizing the -rt series (e.g. the first broken out patch consists usually of various bits from the -tip tree that are (AFAIK) not all needed.) So just have some more patience. How are things going? Just interest... Hhhm, well, I spottet a problem. The thing is that linux-rt does many deep changes in the kernel and I won't be able to support the harder problems. And upstream probably won't help because the Debian rt-kernel isn't a vanilla rt-kernel. Moreover even the broken out rt-patch isn't nicely sorted (e.g. bisectable, some patches undo changes of other patches earier in the series etc. pp), so I fear the Debian kernel team isn't filled with enthusiasm when asked to add an rt variant. I already thought about packaging debian-kernel + rt for Debian and vanilla-kernel + rt for a non-Debian package repository such that it's easy for bug reporters to try out a vanilla kernel. But that still needs more work. I currently investigate how the Debian kernel packages are created. Any help is welcome. Probably the first step will be to create a vanilla-rt package, but that wont be accepted to go into Debian main. Just trying to keep thinks a bit alive here ;) How are things going Uwe? Kind regards, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531827: ITP: mono-uia -- Implementations of members and interfaces based on MS UIA API
Package: wnpp Severity: wishlist Owner: Ray Wang * Package name: mono-uia Version : 1.0 Upstream Author : Mono Accessibility * URL : http://www.mono-project.com/Accessibility * License : MIT/X Programming Lang: C# Description : Implementations of members and interfaces based on MS UIA API Implementations of the members and interfaces based on MS UIA API. The Mono Project is an open development initiative that is working to develop an open source, Unix version of the .NET development platform. Its objective is to enable Unix developers to build and deploy cross-platform .NET applications. The project will implement various technologies that have been submitted to the ECMA for standardization. -- System Information: Debian Release: 5.0 APT prefers lenny-security APT policy: (500, 'lenny-security'), (500, 'lenny') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531848: ITP: python-tg.devtools -- developer tools for the TurboGears web framework
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli * Package name: python-tg.devtools Version : 2.0 Upstream Author : Kevin Dangoor and contributors * URL : http://www.turbogears.org/ * License : MIT/X Programming Lang: Python Description : developer tools for the TurboGears web framework TurboGears2 is a framework to develop web applications in Python, following a model-view-controller architecture. . The main TurboGears2 package is python-turbogears2. This package contains developer tools that ease developing TurboGears applications. In particular, this package provide integration with the Python Paste tools implementing scaffolding command to start developing TurboGears2 applications. I'm packaging this as a dependency of TurboGears2, which is currently in unstable but is lacking the packaging of its dependencies to work (gap that I'm trying to fill). The code of this particular package is currently shipped by python-turbogears2, but---as discussed with other folks of #debian-python---it is better to package it separately. Until the turbogears2 package itself is fixed to account for this code move, this package will stay in experimental. Another important note is that this package depends on zope.sqlalchemy which is not currently packaging. I'm trying to contact the Zope maintainers to decide whether I'm to package it or they are. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531221: okular: Arbitrarily enforces DRM
Roberto C. Sánchez dijo [Sun, May 31, 2009 at 07:27:56AM -0400]: > Here is behavior that I consider to be equally sane: > > $ su - > Password: > # echo ciao >/tmp/foo > # chmod -w /tmp/foo > # exit > logout > $ vim /tmp/foo > :w -> E45: 'readonly' option is set (add ! to override) > :w! -> "/tmp/foo" E212: Can't open file for writing > (…) > In reality, what I am having trouble with is, how these two > scenarios are different: > > 1. Someone produces a PDF with certain DRM restrictions. The user > decides that he does not like the restrictions and so looks to > circumvent them. > > 2. A user or sysadmin produces a file and removes certain access (read > and/or write) for other users. The user decides that he does not like > the restrictions and so looks to circumvent them. Strong difference here, given we are talking about a Unixish system: In case 1, all of the bits in question belong to the same user. In case 2, some of the bits belong to a special user who is in charge of running the machine. -- Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531221: okular: Arbitrarily enforces DRM
John Goerzen dijo [Sun, May 31, 2009 at 08:24:17AM -0500]:
> > Actually an advisory dialog (which could be turned off) would make some
> > sense.
> > ("The author of this PDF document didn't mean to allow you $foo, do you want
> > to continue anyway? Abort Continue")
> >
> > Then a) you are aware that there are restrictions on the document, so if
> > you b) pass it on to people who cannot turn off DRM restrictions (like to
> > print it for you) you can take additional action to strip DRM.
>
> That would seem a quite reasonable compromise to me, as a default
> option. You can still have a checkbox in preferences for complete
> enforcement if there is somebody that really wants it, and leave it off
> by default.
>
> What do you think, Pino?
I have seen arguments on this (very long) thread by Pino and other
members of the KDE team regarding the undeniable disadvantage of
having to maintain a patch basically forever. I have not seen
indication of this mailing reaching the upstream developers for Okular
— Yes, Pino is addressed at a @kde.org, but I understand he is
addressed as he is listed as the Debian maintainer for Okular. Has
this suggestion been pushed upstream? Don't you think we would do a
greater service to the KDE users if we convinced the authors instead
of just the Debian maintainers? (or at least, if we listened at their
arguments as well)
Greetings,
--
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531221: okular: Arbitrarily enforces DRM
Gunnar Wolf writes: > Has this suggestion been pushed upstream? Don't you think we would do > a greater service to the KDE users if we convinced the authors instead > of just the Debian maintainers? (or at least, if we listened at their > arguments as well) My understanding of the job of package maintainer is that it firmly includes advocating the needs of the package's users upstream to the developers. -- \ “We demand rigidly defined areas of doubt and uncertainty!” | `\—Vroomfondel, _The Hitch-Hiker's Guide To The Galaxy_, Douglas | _o__)Adams | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531848: ITP: python-tg.devtools -- developer tools for the TurboGears web framework
On Thu, Jun 04, 2009 at 03:01:03PM +0200, Stefano Zacchiroli wrote:
> Another important note is that this package depends on
> zope.sqlalchemy which is not currently packaging. I'm trying to
> contact the Zope maintainers to decide whether I'm to package it or
> they are.
Just receive a comment about that from the Zope people (via Fabio
Tranchitella): they are packaging zope.sqlalchemy, hence tg.devtools
will just depend on their work. Thanks!
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
Bug#531871: ITP: python-peak.rules -- generic functions and business rules support systems for Python
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli * Package name: python-peak.rules Version : 0.5a1 Upstream Author : Phillip J. Eby * URL : http://pypi.python.org/pypi/PEAK-Rules * License : ZPL Programming Lang: Python Description : generic functions and business rules support systems for Python long description following soon ... I'm packaging this is because PEAK Rules is one of the missing dependencies for turbojson, no matter its being currently uploaded to unstable. Without PEAK Rules, turbojson is currently useless and makes in turn unusable both turbogears2 *and* turbogears 1 (which was working in Lenny). More details can be found in #507909, which I'm Cc-ing with this ITP bug report. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531581: Critical problems on hppa and ia64 buildds
Frank Küster wrote: > Luk Claes wrote: > >>> That doesn't solve my problem: Should I >>> - make sure that the porters, buildd admins etc. are aware of the >>> problem and simply close the bug? >> You might want to downgrade the bug and only close it when it is realy >> solved? > > And what would be the criterion for "solved"? After an analysis of > N build logs of random packages on that buildd show no segfaults any > more? I am not going to do that. > > It's not a bug in my package; I am not going to take responsibility for > it. Fine, though taking the trouble to talk to the porters might still be worthwile. The one on ia64 breaks the buildd's chroot and looks to be easily solved by making sure that the maintainer scripts don't fail when the missing command is not available. >>> ? >>> >>> It could be easily solved by making sure that nothing on the buildd >>> installs packages without installing their dependencies. >> A patch is appreciated, thanks for your cooperation. > > Excuse me - that should already be guaranteed by dpkg, or am I missing > something? If it isn't on that machine, what kind of patch should I > write? That it apparently is not already guaranteed by dpkg or it would not happen and that it only seems to happen with your package? Apparently you don't want to change your package to cope with it, so I guess the only other option is to make the build environment cope with your package (which might be actually implementing the behaviour you expect and seems to be written in policy). Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531581: Critical problems on hppa and ia64 buildds
Luk Claes wrote: > Fine, though taking the trouble to talk to the porters might still be > worthwile. Yes, but definitely not after I've spend hours of my little Debian arguing about non-bugs with people who don't read what I say and instead insist on blaming our packages without explaining why. Regards, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531581: Critical problems on hppa and ia64 buildds
Philipp Kern wrote: > On 2009-06-04, Frank Küster wrote: >> And what would be the criterion for "solved"? After an analysis of >> N build logs of random packages on that buildd show no segfaults any >> more? I am not going to do that. >> >> It's not a bug in my package; I am not going to take responsibility for >> it. > > There are two issues: one that a buildd has random segfaults. That's > sadly common on hppa and ought to be ignored. > > Secondly a package messes up the buildd's chroot on ia64. You are speaking of #530832, aren't you? So please tell me why some people think that it is tex-common who messes up the buildd's chroot. I have given detailed arguments, multiple times, why I don't think so. Please follow up on that. Please follow up on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530832#51 or http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530832#56 after you've read what I wrote there. I'm open to be convinced, but so far no one has been giving any technical arguments. Pissed, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531581: Critical problems on hppa and ia64 buildds
Frank Küster wrote: > Luk Claes wrote: > >> Fine, though taking the trouble to talk to the porters might still be >> worthwile. > > Yes, but definitely not after I've spend hours of my little Debian ^time > arguing about non-bugs with people who don't read what I say and instead > insist on blaming our packages without explaining why. > > Regards, Frank > -- > Dr. Frank Küster > Debian Developer (TeXLive) > VCD Aschaffenburg-Miltenberg, ADFC Miltenberg > B90/Grüne KV Miltenberg -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531581: Critical problems on hppa and ia64 buildds
Frank Küster wrote: > Luk Claes wrote: > >> Fine, though taking the trouble to talk to the porters might still be >> worthwile. > > Yes, but definitely not after I've spend hours of my little Debian > arguing about non-bugs with people who don't read what I say and instead > insist on blaming our packages without explaining why. You were the one reassigning in the first place AFAIR... Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531581: Critical problems on hppa and ia64 buildds
Frank Küster wrote: > Frank Küster wrote: > >> Luk Claes wrote: >> >>> Fine, though taking the trouble to talk to the porters might still be >>> worthwile. >> Yes, but definitely not after I've spend hours of my little Debian > ^time > >> arguing about non-bugs with people who don't read what I say and instead >> insist on blaming our packages without explaining why. Except for arguing, mixing (non?) bugs and resisting to upload an easy workaround might have made things worse btw... Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531581: Critical problems on hppa and ia64 buildds
On Do, 04 Jun 2009, Luk Claes wrote: > Except for arguing, mixing (non?) bugs and resisting to upload an easy > workaround might have made things worse btw... And that easy workaround would be??? Best wishes Norbert --- Dr. Norbert Preining Vienna University of Technology Debian Developer Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- `Er, hey Earthman...' `Arthur,' said Arthur. `Yeah, could you just sort of keep this robot with you and guard this end of the passageway. OK?' What from? You just said there's no one here.' `Yeah, well, just for safety, OK?' said Zaphod. `Whose? Yours or mine?' --- Arthur drawing the short straw on Magrathea. --- Douglas Adams, The Hitchhikers Guide to the Galaxy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531581: Critical problems on hppa and ia64 buildds
Luk Claes wrote: > Frank Küster wrote: >> Luk Claes wrote: >> >>> Fine, though taking the trouble to talk to the porters might still be >>> worthwile. >> >> Yes, but definitely not after I've spend hours of my little Debian >> arguing about non-bugs with people who don't read what I say and instead >> insist on blaming our packages without explaining why. > > You were the one reassigning in the first place AFAIR... Because I didn't see a reason why it should be a bug in our packages. And I still don't, since although you and others send loads of mails what we should do, no one ever discusses the technical aspects of the problem. Regards, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531581: Critical problems on hppa and ia64 buildds
Norbert Preining wrote: > On Do, 04 Jun 2009, Luk Claes wrote: >> Except for arguing, mixing (non?) bugs and resisting to upload an easy >> workaround might have made things worse btw... > > And that easy workaround would be??? To only conditionaly use a command that seems to not always be available. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531902: ITP: syrthes -- Transient thermal simulations in complex solid geometries
Package: wnpp Severity: wishlist Owner: Pini * Package name: syrthes Version : 3.4.2 Upstream Author : EDF R&D * URL : http://rd.edf.com/syrthes * License : GPL Programming Lang: Fortran, C Description : Transient thermal simulations in complex solid geometries SYRTHES is a general purpose thermal software developed at EDF R&D which models conduction and radiation heat transfers in complex geometries. .. SYRTHES can be used coupled with the computational fluid dynamics (CFD) Code_Saturne. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Statistics for licenses?
Hi, I think there are some resources in: https://fossbazaar.org Not exactly the one you mentioned, but something similar At Thu, 04 Jun 2009 09:10:30 +0200, Frank Lin PIAT wrote: > > Hello, > > I am preparing a document to advocate further use of open-source > software in my organization. > > I am looking for some statistics of the [main] licenses used in Debian > packages (or some statistics about the license used in open-source > software at large). > > Are you aware of such analyze? > > Thanks, > > Franklin > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531581: Critical problems on hppa and ia64 buildds
On Thu, 04 Jun 2009, Manoj Srivastava wrote: > If it is not a bug in the package (in other words, no change made > in the package would fix the issue), I see no point in keeping it > open. It would be nice, however, is a psuedo-package were created > for the buildds (or one per buildd, though that seems excessive) so > such issues can be tracked in a central location, rather than > scattered across the 9000 or so source packages. There is a buildd.debian.org psuedopackage.[1] [The buildd maintainers could arange to separate their bug list based on which buildd or arch was affected by the use of usertags and usercategories; if there are questions about that, contact ow...@b.d.o for assistance.] Don Armstrong 1: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=buildd.debian.org -- He no longer wished to be dead. At the same time, it cannot be said that he was glad to be alive. But at least he did not resent it. He was alive, and the stubbornness of this fact had little by little begun to fascinate him -- as if he had managed to outlive himself, as if he were somehow living a posthumous life. -- Paul Auster _City of Glass_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531871: ITP: python-peak.rules -- generic functions and business rules support systems for Python
On Thu, 2009-06-04 at 18:40 +0200, Stefano Zacchiroli wrote: > I'm packaging this is because PEAK Rules is one of the missing > dependencies for turbojson, no matter its being currently uploaded to > unstable. Without PEAK Rules, turbojson is currently useless and makes > in turn unusable both turbogears2 *and* turbogears 1 (which was > working in Lenny). This is the thing that replaces python-dispatch (ruledispatch source package), by the way. You may want to get rid of that one soonish (as in, ASAP). Thanks for your work! -- Gustavo Noronha Debian Project -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Work-needing packages report for Jun 5, 2009
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 383 (new: 5) Total number of packages offered up for adoption: 133 (new: 0) Total number of packages requested help for: 52 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: cflow (#531731), orphaned yesterday Description: Analyze control flow in C source files Installations reported by Popcon: 651 didiwiki (#531177), orphaned 5 days ago Description: simple wiki implementation with built-in webserver Installations reported by Popcon: 60 fondu (#531178), orphaned 5 days ago Description: convert between Mac and UNIX font formats Reverse Depends: open-font-design-toolkit Installations reported by Popcon: 130 mailscanner (#531317), orphaned 4 days ago Description: email gateway for virus scanning, spam and fishing detection Installations reported by Popcon: 269 straw (#531179), orphaned 5 days ago Description: desktop news aggregator for GNOME Installations reported by Popcon: 133 378 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 133 packages are awaiting adoption. See http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#470795), requested 448 days ago Description: Co-maintainer wanted Reverse Depends: ampache apache2 apache2-dbg apache2-mpm-event apache2-mpm-itk apache2-mpm-prefork apache2-mpm-worker apache2-prefork-dev apache2-suexec apache2-suexec-custom (162 more omitted) Installations reported by Popcon: 44472 ara (#450876), requested 571 days ago Description: utility for searching the Debian package database Installations reported by Popcon: 114 asymptote (#517342), requested 97 days ago Description: script-based vector graphics language inspired by MetaPost Installations reported by Popcon: 480 athcool (#278442), requested 1682 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 197 boinc (#511243), requested 147 days ago Description: BOINC distributed computing Reverse Depends: boinc-app-milkyway boinc-app-seti boinc-dbg Installations reported by Popcon: 1612 cvs (#354176), requested 1197 days ago Description: Concurrent Versions System Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsps cvsreport (11 more omitted) Installations reported by Popcon: 21766 dctrl-tools (#448284), requested 586 days ago Description: Command-line tools to process Debian package information Reverse Depends: aptfs debian-goodies dlocate haskell-devscripts hg-buildpackage ia32-archive ia32-libs-tools libsbuild-perl mlmmj simple-cdd Installations reported by Popcon: 11776 dpkg (#282283), requested 1656 days ago Description: dselect: a user tool to manage Debian packages Reverse Depends: alien alsa-source apt-build apt-cross apt-src backuppc biblatex biblatex-dw build-essential bzr-builddeb (216 more omitted) Installations reported by Popcon: 85128 elvis (#432298), requested 696 days ago Description: powerful clone of the vi/ex text editor (with X11 support) Reverse Depends: elvis elvis-console elvis-tools Installations reported by Popcon: 364 fglrx-driver (#454993), requested 544 days ago (non-free) Description: non-free AMD/ATI r5xx, r6xx display driver Reverse Depends: fglrx-amdcccle fglrx-atieventsd fglrx-control fglrx-driver fglrx-glx fglrx-glx-ia32 fglrx-kernel-src Installations reported by Popcon: 1995 flightgear (#487388), requested 348 days ago Description: Flight Gear Flight Simulator Installations reported by Popcon: 929 gentoo (#422498), requested 760 days ago Description: a fully GUI-configurable, two-pane X file manager Installations reported by Popcon: 278 gnat-4.3 (#475374), requested 420 days ago Description: help needed to execute test cases Reverse Depends: adabrowse adacontrol asis-programs ghdl gnade-bin gnat gnat-4.3 gnat-gps libadasockets-dev libahven16 (47 more omitted) Installations reported by Popcon: 900 gnat-gps (#496905), requested 280 days ago Description: co-maintainer needed
Re: Bug#531581: Critical problems on hppa and ia64 buildds
Don Armstrong wrote: > On Thu, 04 Jun 2009, Manoj Srivastava wrote: >> If it is not a bug in the package (in other words, no change made >> in the package would fix the issue), I see no point in keeping it >> open. It would be nice, however, is a psuedo-package were created >> for the buildds (or one per buildd, though that seems excessive) so >> such issues can be tracked in a central location, rather than >> scattered across the 9000 or so source packages. > > There is a buildd.debian.org psuedopackage.[1] [The buildd maintainers > could arange to separate their bug list based on which buildd or arch > was affected by the use of usertags and usercategories; if there are > questions about that, contact ow...@b.d.o for assistance.] The thing is that it is not a bug in the buildd chroot or buildd setup, it's a porter issue... Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531581: Critical problems on hppa and ia64 buildds
On Fri, 05 Jun 2009, Luk Claes wrote: > The thing is that it is not a bug in the buildd chroot or buildd > setup, it's a porter issue... I haven't really analyzed the bug (and only read this thread in the most superficial manner imaginable), so what I said previously (and say below) shouldn't be construed as categorizing this particular bug. That said, I have no problem creating pseudo packages for porter-specific issues as well, though presumably if they're porter-specific issues that primarily impact the buildds, they could be assigned to the buildds, and tagged with the appropriate porter usertag. [At least until the package which is causing the issue on the buildd that is porter specific is identified, anyway.] Don Armstrong -- In all matters of government, the correct answer is usually: "Do nothing" -- Robert Heinlein _Time Enough For Love_ p428 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531941: gpe-gallery: missing gpe-gallery.png icon for .the desktop file
On Fri, 05 Jun 2009 08:02:20 +0200 Luca Capello wrote: > Package: gpe-gallery > Version: 0.97-3 > Severity: minor > Hello, > > the .desktop file looks for gpe-gallery.png while only the .xpm version Bah - this is getting really annoying. If Debian is going to stick with two menu systems, why do we also have to stick with two icon formats? (And why did we choose the *BIGGER* icon format of XPM? It's *double* the size of the equivalent PNG for foo sake.) The other mystery is that the desktop icon shows up fine on my own Sid systems. Has something changed to allow the XPM to show up when a PNG doesn't exist in some cases? $ ls /usr/share/pixmaps/gpe-gallery.* /usr/share/pixmaps/gpe-gallery.xpm $ grep Icon /usr/share/applications/gpe-gallery.desktop Icon=gpe-gallery.png $ find /usr/share/ -name gpe-gallery.png $ Yet, I get an icon for the GNOME and Debian menus. Is this just an aberration (because the icon concerned is - visually - identical to the gthumb icon) or some new feature? (For the fix itself, I'm going to migrate those manual install rules into a gpe-gallery.install file and cut out all the extra stuff in debian/rules, then add the PNG.) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgphEzXzJ0ZRY.pgp Description: PGP signature
