Re: Starting services in runlevels 0 and 6
[Christian Perrier] > From what I see, having this will not happen for etch. Do you think it > could be a release goal for etch+1? I believe it should be a release goal for etch+1 to switch sysv-rc to use a dependency based sequencing, yes. > With that already decided and widely accepted, it wouldn't probably > be very hard to begin a campaign to make packages include dependency > information just after we release etch It is already happening, so I am confident we will get even more scripts to include those headers after Etch. The nice thing about the change is that it only add a comment to the script, so the change is very low-risk. Lintian already give a warning for init.d scripts without these headers, and this help a lot of maintainers to notice the problem. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Starting services in runlevels 0 and 6
[Jörg Sommer] >> It was pointed out to me, that even the scripts starting with S are >> called with argument 'stop' for runlevels 0 and 6 by /etc/init.d/rc. >> However, the reason why it is implemented that way is still not clear. > > Because the S scripts are run after the K scripts. This way it is > possible to run special scripts at very last. Well, it is not really a good explanation, as the ordering of K01 S01 could also be done with K01 K02. No need to use start-symlinks as stop scripts to get the proper ordering. I've been told that the sysv-rc system behave the way it does because Solaris did it when the Debian boot system was written, and it was used as the example. I guess that is as good explanation as any on the historical reasons for the strange setup in the Debian boot system. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: delay of the full etch freeze
Steve Langasek <[EMAIL PROTECTED]> wrote: > According to http://ftp-master.debian.org/new.html, the oldest package in > NEW is 3 weeks old. 3 weeks ago was more than a full month after the > original proposed base freeze date for etch[1]. That might be misleading, because the date is reset when you do a new upload. The two packages that were oldest for a while (latex-cjk and friends, now they are processed) have been in there for nearly a month, but then we made an upload that only changed the maintainer e-mail address, and they suddenly looked young... > Sorry, no, I'm not going to > lose any sleep over such packages not making it into etch before the freeze. I agree. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
[VAC-RFH] tagcoll2 on Alpha
Hello, I have a problem with the package tagcoll2: it builds on all architectures: http://people.debian.org/~igloo/status.php?email=enrico%40debian.org except Alpha: http://buildd.debian.org/fetch.cgi?pkg=tagcoll2;ver=2.0.3-2;arch=alpha;stamp=1160679986 I already spent quite some time some months ago trying to debug a similar problem of tagcoll on alpha: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358493 I tried to apply the same work-around in the 2.0.3-2 upload, but it evidently didn't work out. tagcoll2 is quite important because it's a build-dep for libept, which is a build-dep for the new version of debtags, which has a redesigned update method that gets rid of apt-index-watcher. apt-index-watcher is bad, shouldn't go in a stable release, and after the last upload of libapt-front, is not built anymore. Now, I won't have time to debug this for another 10 days, because I'm leaving to Venezuela for a conference (YAY! :) : http://foromundial.solve.net.ve/?q=node/10 Since time starts to becoming an issue, I'm asking a favour: can someone please look at this while I'm away? The goal would be to have debtags 1.6.2 reach testing as soon as possible. If you need help, know-how on the tagcoll/ept codebase usually hangs out in the #ekhis IRC channel on freenode. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: gdm/Gnome/KDE and device permissions
Qua, 2006-10-11 às 23:17 +0200, Tim Dijkstra escreveu: > One problem is that a user can launch a daemon that keeps the device file > open before she logs out > Also I was referring to how pam_group works, but I find this way of > handling permissions even more broken than pam_group. For example, > what happens if somebody logs in on another VT? You know, sometimes I have the weird idea that interaction with these devices should be by some way proxied by the X server. The X server seems to be the only to knows who is in which VT at which time... it already have to proxy access to the video card, it isn't exactly insane to it proxy the access to other devices... For sound it's easy, X server would implement what is done by sound daemons today, but for other devices I don't know... But yeah, I consider it a weird idea... daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lack of transparency of automatic actions
On Friday 13 October 2006 17:18, John Goerzen wrote: > Even worse, you again have to use KDE or Gnome to take advantage of > network-manager. Why are we leaving CLI users out in the cold? It is > quite possible to use mutt, ssh, and ftp on a laptop. And it's > frustrating to know that my network setup will be useless when I'm not > running in X. Ifplugd and wpa_supplicant works fine on my laptop. All actions are sh scripts, so you can configure the behavior to fit your needs. -- Jean-Philippe Garcia Ballester pgpFpc4a9DyxE.pgp Description: PGP signature
Bug#392904: ITP: bkhive -- dumps the syskey bootkey from a Windows NT/2K/XP system hive
Package: wnpp Severity: wishlist Owner: "Adam Cécile (Le_Vert)" <[EMAIL PROTECTED]> * Package name: bkhive Version : 1.0.0 Upstream Author : Nicola Cuomo <[EMAIL PROTECTED]> * URL : http://www.studenti.unina.it/~ncuomo/syskey/ * License : GPL Description : dumps the syskey bootkey from a Windows NT/2K/XP system hive This tool is needed by ophcrack, "a Microsoft Windows password cracker using rainbow tables". -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (400, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-1-amd64 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Re: How should we deal with 'pointless-on-this-arch' packages?
On Sat, Oct 14, 2006 at 02:30:14AM +0100, Wookey wrote: > In general debian builds everything for every architecture. This is a > very good plan and finds a lot of bugs. Agreed. > However there are some packages which are clearly not sensible on some > arches. Numerical analysis software in general on arm is a good > example of this class. Arm hardware is generally slow and more seriously has > no > floating point hardware (except very exceptionally). Same for m68k. Additionally such packages like flightgear don't make much sense on those archs. > No-one in their right mind would run numerical analysis on an arm box, > for any purpose other than testing that they could. ... or to find bugs. > Now in an ideal world we would gratutiously build these packages > anyway, just to check that they do build on said architecture, but > there is a cost to doing this. Buildd time and archive space. Buildd > time particularly, for slow arches, is a resource we don't have a huge > abundance of. Very true, especially before freeze when every maintainer uploads frequently to get new and hopefully bug-fixed version in... > So, 'is pretty much pointless' has not to date been deemed a reason to > mark a package 'not for us'. However, It seems to me that if the porters > _and_ the package maintainer agree that there really is no real point in > building a package for a particular arch, and it takes signifcant > resources to do so, that it is best to mark such packages 'not for us'. Placing a package in N-F-U is mostly done for FTBFS reasons or if upstream doesn't support that arch. > However I don't think we should just start doing this unilaterally, > so I am posting here to canvass opinion. Should inappropriateness be a > criterion for deciding a package is not-for-us? I think "yes, it should be... to some degree at least..." > Should we perhaps have a more general mechanism than such ad-hoc > marking to indicate innappropriate combinations of package and > architecture? > An example of this genre is fityk, which currently times out on arm, > trying to build large C++ files. It is curve-fitting software. It > could probably be built, but one wonders if it is worth the effort. > The author is happy to not have it built for arm. > I'm sure there are others in the same situation, although I have not > done extensive research to try and produce a list. I believe the Vancouver proposal went into wrong direction by excluding (slower) archs from releases. Of course, dropping archs is a quick and easy way to lighten the load for a release, but IMHO it is wrong, because it's damaging and destroying one of Debians biggest strengths: being an universal OS that can be run on nearly every arch. Of course nobody wants to extent the releases beyond any sane time just due to some slower archs. The question is: how can Debian release more frequently and on time even when some slower archs are falling behind and can't keep up with >6100 source packages? The answer is quite simple: reduce the load for those archs by not forcing them to build *every* package, but only a certain subset of them. I think everyone will agree that every arch should have a basic set of packages to be suitable to use it like some shells, some editors, ssh, debian-installer, compilers, linkers, etc. It doesn't make much sense to build all Desktop related packages for an arch that is mainly used remotely or as an embedded device. I don't think that anyone will run KDE on top of an NSLU2 or on a Linksys WRT54G. Same may be valid for m68k, although there *are* users that are using their m68ks as an X-Terminal or such. But those are rare. So, it's better, IMHO, to reduce the number of packages for those archs by defining some sort of requirements: - what is *required* to make use of that arch (f.e. example packages in section base, admin or with priority required)? - what is commonly used on those archs? popcon can gives some hints like MTAs, fetchmail, UUCP, DHCP-stuff or similar things (gcc, debugger, ...) - what is rarely used? (Desktop Environments, Browsers, numerical analysis tools) - what is unuseable on that arch? (qemu, Xen, flight simulators, cluster software, ...) When an arch doesn't need to have *all* of the archive to build, like KDE, Gnome, the arch (and the porters!) have more resources to get the important packages being build. *If* resources aren't exhausted, the arch *can* build stuff that isn't that necessary for that arch and its users. And even more, if it can be released with the other archs, the users are happy and being able to compile needed packages on their own if they need some other packages, that haven't found their way into the release for that arch. M68k was the first port that got released by Debian and it's the first arch that got dropped from the release. And it showed now that it's unclear how the port should be handled after the drop. Can it be released in a point-release later? Does it need t
Bug#392905: ITP: samdump2 -- dumps Windows 2k/NT/XP password hashes
Package: wnpp Severity: wishlist Owner: "Adam Cécile (Le_Vert)" <[EMAIL PROTECTED]> * Package name: samdump2 Version : 1.0.0 Upstream Author : Nicola Cuomo <[EMAIL PROTECTED]> * URL : http://www.studenti.unina.it/~ncuomo/syskey/ * License : GPL w/ OpenSSL exception | OpenSSL-like Description : dumps Windows 2k/NT/XP password hashes This tool is needed by ophcrack, "a Microsoft Windows password cracker using rainbow tables" -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (400, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-1-amd64 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Bug#392906: ITP: ophcrack -- Microsoft Windows password cracker using rainbow tables
Package: wnpp Severity: wishlist Owner: "Adam Cécile (Le_Vert)" <[EMAIL PROTECTED]> * Package name: ophcrack Version : 2.3.3 Upstream Author : Philippe Oechslin <[EMAIL PROTECTED]> Cedric Tissieres <[EMAIL PROTECTED]> * URL : http://ophcrack.sourceforge.net/ * License : GPL w/ OpenSSL exception Description : Microsoft Windows password cracker using rainbow tables Ophcrack is a GTK-based Windows password cracker based on a time-memory trade-off using rainbow tables. This is a new variant of Hellman's original trade-off, with better performance. It recovers 99.9% of alphanumeric passwords in seconds. . Homepage: http://ophcrack.sourceforge.net/ -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (400, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-1-amd64 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Re: How should we deal with 'pointless-on-this-arch' packages?
Hello, I agree with most of what Wookey and you said, but would like some clarification on this: On Sat, 14.10.2006 at 12:06:20 +0200, Ingo Juergensmann <[EMAIL PROTECTED]> wrote: > But sadly, I have very little hope that Debian will change anything it's > release structure soon. *sigh* Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
On 2006-10-14 12:06 +0200, Ingo Juergensmann wrote: > On Sat, Oct 14, 2006 at 02:30:14AM +0100, Wookey wrote: > I believe the Vancouver proposal went into wrong direction by excluding > (slower) archs from releases. Of course, dropping archs is a quick and easy > way to lighten the load for a release, but IMHO it is wrong, because it's > damaging and destroying one of Debians biggest strengths: being an universal > OS that can be run on nearly every arch. > > Of course nobody wants to extent the releases beyond any sane time just due > to some slower archs. The question is: how can Debian release more > frequently and on time even when some slower archs are falling behind and > can't keep up with >6100 source packages? > > The answer is quite simple: reduce the load for those archs by not forcing > them to build *every* package, but only a certain subset of them. > I think everyone will agree that every arch should have a basic set of > packages to be suitable to use it like some shells, some editors, ssh, > debian-installer, compilers, linkers, etc. > It doesn't make much sense to build all Desktop related packages for an arch > that is mainly used remotely or as an embedded device. I don't think that > anyone will run KDE on top of an NSLU2 or on a Linksys WRT54G. No - but they might well run it on an Iyonix, and maybe even a balloon. Even though arm is mostly-embedded there are a few desktop machines (which merely illustrates the problem of general package classifications). > Same may be valid for m68k, although there *are* users that are using their > m68ks as an X-Terminal or such. But those are rare. As you say m68k is leading the way in terms of still being a useful arch but not able to cope with 'all of debian'. Arm is following. > So, it's better, IMHO, to reduce the number of packages for those archs by > defining some sort of requirements: > > - what is *required* to make use of that arch (f.e. example packages in > section base, admin or with priority required)? > - what is commonly used on those archs? popcon can gives some hints like > MTAs, fetchmail, UUCP, DHCP-stuff or similar things (gcc, debugger, ...) > - what is rarely used? (Desktop Environments, Browsers, numerical analysis > tools) > - what is unuseable on that arch? (qemu, Xen, flight simulators, cluster > software, ...) Clearly something like this could be a general solution to the problem. I do think there is value in defining characteristics of packages so that choice can be made, but it is not an easy thing to do. Even on a slow arch which is not normally used as a desktop, desktop packages are often needed. Should such classification be done per-arch, or generally. Should we perhaps have 'core' and 'other' (like ubuntu's main and multiverse (or whatever it which)). Perhaps debtags could be used as an appropriate classification mechanism. Perhaps embedded debian could be developed to fill the 'smaller machine' niche, although that is not necessarily a very good fit (emdebian is about shrinking all packages as well as subsetting). And any such descisions have implications for how the release process is managed. Nevertheless I think it is clear that we do need mechanisms to keep the load and package set appropriate for slower arches. If we design the mechanism properly I would hope it could be useful for various categorisation/subsetting purposes within debian. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
On Sat, Oct 14, 2006 at 12:21:35PM +0200, Toni Mueller wrote: > I agree with most of what Wookey and you said, but would like some > clarification on this: > On Sat, 14.10.2006 at 12:06:20 +0200, Ingo Juergensmann <[EMAIL PROTECTED]> > wrote: > > But sadly, I have very little hope that Debian will change anything it's > > release structure soon. *sigh* What do you want to hear? What clarification do you need? I think it is known that some changes in Debian needs a lng time. Adding amd64 to the archive is an example. -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij/public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
Hi, On Saturday 14 October 2006 12:51, Wookey wrote: > Nevertheless I think it is clear that we do need mechanisms to keep > the load and package set appropriate for slower arches. If we design > the mechanism properly I would hope it could be useful for various > categorisation/subsetting purposes within debian. Isn't it up to the maintainer to say $package is not suited for $architecture? And aren't maintainers happy to receive hints (e.g. from porters or users of a certain package), which specific package is not suited for a specific architecture? regards, Holger pgpp06gZIloAl.pgp Description: PGP signature
Re: How should we deal with 'pointless-on-this-arch' packages?
On Sat, Oct 14, 2006 at 07:30:15PM +0200, Holger Levsen wrote: > > Isn't it up to the maintainer to say $package is not suited for > $architecture? > And aren't maintainers happy to receive hints (e.g. from porters or users of > a certain package), which specific package is not suited for a specific > architecture? > I would think that by definition a user of a package is the last person who would be qualified to make a determinitation as to whether a particular pacakge is suitable for a particular architecture. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Packages up for adoption
Hi Steve, On Tue, Oct 10, 2006 at 08:25:26PM +0100, Steve Kemp wrote: >* flawfinder >* pscan As I haven't gotten around to do too much audit work, I'll at least take care of a few audit tools: flawfinder and pscan. It seems rats already has a new maintainer... Cheers, Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org signature.asc Description: Digital signature
Re: Packages up for adoption
On Sat, Oct 14, 2006 at 10:52:41PM +0200, Uwe Hermann wrote: > Hi Steve, > > On Tue, Oct 10, 2006 at 08:25:26PM +0100, Steve Kemp wrote: > >* flawfinder > >* pscan > > As I haven't gotten around to do too much audit work, I'll at least take > care of a few audit tools: flawfinder and pscan. It seems rats already > has a new maintainer... Great - thanks a lot. Once I've gotten all the packages adopted I'll be able to dedicate at least one evening a week to doing auditing work. Steve -- signature.asc Description: Digital signature
Processed: reassign
Processing commands for [EMAIL PROTECTED]: > reassign 391118 general Bug#391118: The longer you hold down keyboard keys, the faster they should repeat Warning: Unknown package 'unknown' Bug reassigned from package `unknown' to `general'. > -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
On Sat, Oct 14, 2006 at 02:30:14AM +0100, Wookey wrote: > In general debian builds everything for every architecture. This is a > very good plan and finds a lot of bugs. Hi Wookey, endian bugs, 32/64 bit bugs, int size bugs, more eyes on bad code, more users on bad code, low-mem compiling, low-mem installs, more testing of the Debian infrastrure (apt,debconf,pre/post install scripts) and providing 'practice' for porters x-) These are the 'good' reasons not to do this. > > However there are some packages which are clearly not sensible on some > arches. Numerical analysis software in general on arm is a good > example of this class. Arm hardware is generally slow and more > seriously has no floating point hardware (except very exceptionally). As you say there are lists. I'm aware of p-a-s and n-f-u lists which provide mechanism for things not being built. I'd also be interested in Ingo's wonderful buildd.net that can provide 'what are the top N things that are taking the longest to build' (per arch) (although this does not take into account something like 'kde' which depends upon many bits to be built) I've read that the ftpmasters consider it a bug if someone adds an arch to p-a-s unless there is substantial reason, and n-f-u has a specific use case that would not be suitable for this either. So maybe a new list for packages that are buildd intensive and would not benfit the arch use case for being built -- may call it packages-that-are-too-resource-intensive as I dont see some tiny 10k package being dropped but only large ones. Also, from the graphs on % of packages built, it is normally in 80%+ range for short periods of time while is is more often in the 93%+ range. And the 'cut-off' is IIRC 95%+ as the 'release' requirement. So it should only require the removal of a handfull of very intensive packages to get that number up to release status. > > No-one in their right mind would run numerical analysis on an arm box, > for any purpose other than testing that they could. The question is who should decide and by what criteria? ftp masters, the maintainers, the porters ? > > Now in an ideal world we would gratutiously build these packages > anyway, just to check that they do build on said architecture, but IIRC the buildds do not have a weight attached to each package to determine its order in the buildd queue. Would the introduction of a weight, where resource intensive packages get put on the bottom and are built at 'slow' periods help? > there is a cost to doing this. Buildd time and archive space. Buildd > time particularly, for slow arches, is a resource we don't have a huge > abundance of. > > So, 'is pretty much pointless' has not to date been deemed a reason to > mark a package 'not for us'. However, It seems to me that if the porters > _and_ the package maintainer agree that there really is no real point in > building a package for a particular arch, and it takes signifcant > resources to do so, that it is best to mark such packages 'not for us'. There are currently 'release goals' for the entire project. Would it make sense to have 'arch goals' that would include the exclusion of certain packages that are 'not-for-us' with the 'us' being the team that is familiar with the uses of the arch and what should be build? > > However I don't think we should just start doing this unilaterally, > so I am posting here to canvass opinion. Should inappropriateness be a > criterion for deciding a package is not-for-us? > just my 2 centieuros, Kev -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org | signature.asc Description: Digital signature
Bug#391118: This probably belongs in the kernel bug tracker
I would think that keyboard repeat rate is the domain of the kernel's keyboard driver. Since there are multiple kernels which can underly Debian, I don't see how this is feasible. Especially since each will have its own mechanism for that sort of thing. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Request for virtual package ircd
Aurélien GÉRÔME <[EMAIL PROTECTED]> writes: > Hi, > > On Thu, Oct 12, 2006 at 12:10:51AM +0200, Mario Iseli wrote: >> as described in >> http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt >> I announce here my idea of the virtual package ircd. When I count >> correctly are at the moment 7 different IRC-daemons in Debian and they >> logically conflict with each other. So I would think an official virtual >> package would be a fine solution. There are also IRC services which work >> in general with all ircds, so it would be easier if those packages also >> could only depend on "ircd". > > As the (co-)maintainer of 2 IRCd packages and 2 IRC services packages, > I completely disagree. > > Some IRC servers do *not* conflict, so a virtual package is > unnecessary. The Conflicts and Provides are orthogonal. Certainly, you can conflict with the same package you provide, but this is not needed here. > If they conflict, like ircd-hybrid and dancer-ircd, it is up to the > maintainer to manage the conflicts. Yes, or even better to arrange things such that they no longer conflict. > Some services, if not all, are designed to work on a specific > IRCd. For instance, hybserv is supposed to only run with ircd-hybrid > and dancer-services to only run with dancer-ircd. I do *not* want to > undertake the maintenance of a services package on other IRC servers > that the one for which it is designed. Then in this special case you would continue to depend upon the specific package, rather than the virtual package. Why is this a problem? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgptE3tMQwycZ.pgp Description: PGP signature
Re: How should we deal with 'pointless-on-this-arch' packages?
Le Sat, Oct 14, 2006 at 11:51:49AM +0100, Wookey a écrit : > > Perhaps debtags could be used as an appropriate classification > mechanism. Hi all, As a maintainer of scientific packages, I agree with this idea. I always feel sorry to see my packages sitting in the queue of slow arches while I am very confident that nobody will use them on such computers. The interest with debtags is that it allows to change the policy for a package without needing an upload or the intervention of the maintainer. This way, the decision of not building could be taken by the maintainer, and it could be reverted quickly by somebody else if a user requested the package on an excluded arch. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Orphan party
I'm orphaning the following packages. I'm no longer interested in maintaining them unless the project pays me for it. * h5utils * hdf5 - very useful tool for finding ICEs in gcc. Otherwise, fragile library which implies working around bugs introduced by incompetent upstream developers hiding behind a help desk for any interaction. * libctl * libpng - nightmare of the security team. Upstream developers seem to have recently understood some packaging issues, but with their erratic behavior and stupid things libpng-using applications do, it is likely to break at each new upstream release. Anyone sane should consider reimplementing it from scratch instead of packaging it. * mpb * sdl-mixer1.2 -- Josselin Mouette/\./\ "Do you have any more insane proposals for me?" signature.asc Description: Ceci est une partie de message numériquement signée
Re: Experiment: orphanining some of my packages (third round)
On Mon, Oct 02, 2006 at 11:21:45AM +0200, Aurelien Jarno wrote: > Aurelien Jarno wrote: > >Hi all, > > > >As Debian^WDunc-tank experiments with funding, I have loosed motivation > >to spend so much time on my packages. I have therefore decided to > >experiment with orphaning a few of my packages in the hope I will have > >more time to contribute to other Free Software projects. > > > >Here is the list of packages I have orphaned in a first round, please > >feel free to adopt them: > > The following packages are also available: > - quiteinstane > - quiteinsanegimpplugin > - zziplib > The results of *all 4 GR* show me that I don't share the goals of the project anymore, so I loosed my motivation a bit more. I am therefore orphaning the following packages, please feel free to adopt them: - kid3 - kwave - lineakd - lineak-defaultplugin - lineak-xosdplugin - lineak-kdeplugins Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Results for Position statement clarifying DFSG
Greetings,
This message is an automated, unofficial publication of vote results.
Official results shall follow, sent in by the vote taker, namely
Debian Project Secretary
This email is just a convenience for the impatient.
I remain, gentle folks,
Your humble servant,
Devotee (on behalf of Debian Project Secretary)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Starting results calculation at Sun Oct 15 00:01:14 2006
Option 1 "DFSG 2 applies to all programmatic works"
Option 2 "Further Discussion"
In the following table, tally[row x][col y] represents the votes that
option x received over option y.
Option
1 2
=== ===
Option 1 136
Option 2149
Looking at row 2, column 1, Further Discussion
received 149 votes over DFSG 2 applies to all programmatic works
Looking at row 1, column 2, DFSG 2 applies to all programmatic works
received 136 votes over Further Discussion.
Option 1 Reached quorum: 136 > 47.4341649025257
Dropping Option 1 because of Majority. 0.913 (136/149) < 1
The Schwartz Set contains:
Option 2 "Further Discussion"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The winners are:
Option 2 "Further Discussion"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
The voters have spoken, the bastards... --unknown
DEbian VOTe EnginE
digraph Results {
ranksep=0.25;
"DFSG 2 applies to all programmatic works\n0.91" [ style="filled" ,
color="pink", shape=octagon, fontname="Helvetica", fontsize=10 ];
"Further Discussion" -> "DFSG 2 applies to all programmatic works\n0.91" [
label="13" ];
"Further Discussion" [ style="filled" , color="powderblue", shape=egg,
fontcolor="Navy Blue", shape=diamond, fontcolor="Red", fontname="Helvetica",
fontsize=10 ];
}
pgpnCfmdS2Bsi.pgp
Description: PGP signature
Results for General Resolution: Re-affirm support to the Debian Project Leader
Greetings,
This message is an automated, unofficial publication of vote results.
Official results shall follow, sent in by the vote taker, namely
Debian Project Secretary
This email is just a convenience for the impatient.
I remain, gentle folks,
Your humble servant,
Devotee (on behalf of Debian Project Secretary)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Starting results calculation at Sun Oct 15 00:01:35 2006
Option 1 "Re-affirm DPL, wish success to unofficial Dunc Tank"
Option 2 "Re-affirm DPL, do not endorse nor support his other projects"
Option 3 "Further Discussion"
In the following table, tally[row x][col y] represents the votes that
option x received over option y.
Option
1 2 3
=== === ===
Option 1 177 227
Option 2128 226
Option 3 9379
Looking at row 2, column 1, Re-affirm DPL, do not endorse nor support his other
projects
received 128 votes over Re-affirm DPL, wish success to unofficial Dunc Tank
Looking at row 1, column 2, Re-affirm DPL, wish success to unofficial Dunc Tank
received 177 votes over Re-affirm DPL, do not endorse nor support his other
projects.
Option 1 Reached quorum: 227 > 47.4341649025257
Option 2 Reached quorum: 226 > 47.4341649025257
Option 1 passes Majority. 2.441 (227/93) > 1
Option 2 passes Majority. 2.861 (226/79) > 1
Option 1 defeats Option 2 by ( 177 - 128) = 49 votes.
Option 1 defeats Option 3 by ( 227 - 93) = 134 votes.
Option 2 defeats Option 3 by ( 226 - 79) = 147 votes.
The Schwartz Set contains:
Option 1 "Re-affirm DPL, wish success to unofficial Dunc Tank"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The winners are:
Option 1 "Re-affirm DPL, wish success to unofficial Dunc Tank"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
The voters have spoken, the bastards... --unknown
DEbian VOTe EnginE
digraph Results {
ranksep=0.25;
"Re-affirm DPL, wish success to unofficial Dunc Tank\n2.44" [ style="filled" ,
color="powderblue", shape=egg, fontcolor="Navy Blue", fontname="Helvetica",
fontsize=10 ];
"Re-affirm DPL, wish success to unofficial Dunc Tank\n2.44" -> "Re-affirm DPL,
do not endorse nor support his other projects\n2.86" [ label="49" ];
"Re-affirm DPL, wish success to unofficial Dunc Tank\n2.44" -> "Further
Discussion" [ label="134" ];
"Re-affirm DPL, do not endorse nor support his other projects\n2.86" [
style="filled" , fontname="Helvetica", fontsize=10 ];
"Re-affirm DPL, do not endorse nor support his other projects\n2.86" ->
"Further Discussion" [ label="147" ];
"Further Discussion" [ style="filled" , shape=diamond, fontcolor="Red",
fontname="Helvetica", fontsize=10 ];
}
pgpiKOR4i1bfV.pgp
Description: PGP signature
Results for General Resolution: Recall the project leader
Greetings,
This message is an automated, unofficial publication of vote results.
Official results shall follow, sent in by the vote taker, namely
Debian Project Secretary
This email is just a convenience for the impatient.
I remain, gentle folks,
Your humble servant,
Devotee (on behalf of Debian Project Secretary)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Starting results calculation at Sun Oct 15 00:01:49 2006
Option 1 "Recall the project leader"
Option 2 "Further Discussion"
In the following table, tally[row x][col y] represents the votes that
option x received over option y.
Option
1 2
=== ===
Option 1 48
Option 2277
Looking at row 2, column 1, Further Discussion
received 277 votes over Recall the project leader
Looking at row 1, column 2, Recall the project leader
received 48 votes over Further Discussion.
Option 1 Reached quorum: 48 > 47.4341649025257
Dropping Option 1 because of Majority. 0.173 (48/277) < 1
The Schwartz Set contains:
Option 2 "Further Discussion"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The winners are:
Option 2 "Further Discussion"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
The voters have spoken, the bastards... --unknown
DEbian VOTe EnginE
digraph Results {
ranksep=0.25;
"Recall the project leader\n0.17" [ style="filled" , color="pink",
shape=octagon, fontname="Helvetica", fontsize=10 ];
"Further Discussion" -> "Recall the project leader\n0.17" [ label="229" ];
"Further Discussion" [ style="filled" , color="powderblue", shape=egg,
fontcolor="Navy Blue", shape=diamond, fontcolor="Red", fontname="Helvetica",
fontsize=10 ];
}
pgpBqNH4AuAn6.pgp
Description: PGP signature
Results for General Resolution: Handling source-less firmware in the Linux kernel
Greetings,
This message is an automated, unofficial publication of vote results.
Official results shall follow, sent in by the vote taker, namely
Debian Project Secretary
This email is just a convenience for the impatient.
I remain, gentle folks,
Your humble servant,
Devotee (on behalf of Debian Project Secretary)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Starting results calculation at Sun Oct 15 00:02:08 2006
Option 1 "Release Etch even with kernel firmware issues"
Option 2 "Special exception to DFSG 2 for firmware as long as required [3:1]"
Option 3 "Further Discussion"
In the following table, tally[row x][col y] represents the votes that
option x received over option y.
Option
1 2 3
=== === ===
Option 1 196 271
Option 2110 199
Option 3 42 111
Looking at row 2, column 1, Special exception to DFSG 2 for firmware as long as
required [3:1]
received 110 votes over Release Etch even with kernel firmware issues
Looking at row 1, column 2, Release Etch even with kernel firmware issues
received 196 votes over Special exception to DFSG 2 for firmware as long as
required [3:1].
Option 1 Reached quorum: 271 > 47.4341649025257
Option 2 Reached quorum: 199 > 47.4341649025257
Option 1 passes Majority. 6.452 (271/42) > 1
Dropping Option 2 because of Majority. 1.793 (199/111) < 3
Option 1 defeats Option 3 by ( 271 - 42) = 229 votes.
The Schwartz Set contains:
Option 1 "Release Etch even with kernel firmware issues"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The winners are:
Option 1 "Release Etch even with kernel firmware issues"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
The voters have spoken, the bastards... --unknown
DEbian VOTe EnginE
digraph Results {
ranksep=0.25;
"Release Etch even with kernel firmware issues\n6.45" [ style="filled" ,
color="powderblue", shape=egg, fontcolor="Navy Blue", fontname="Helvetica",
fontsize=10 ];
"Release Etch even with kernel firmware issues\n6.45" -> "Further Discussion"
[ label="229" ];
"Special exception to DFSG 2 for firmware as long as required [3:1]\n1.79" [
style="filled" , color="pink", shape=octagon, fontname="Helvetica", fontsize=10
];
"Further Discussion" -> "Special exception to DFSG 2 for firmware as long as
required [3:1]\n1.79" [ label="-88" ];
"Further Discussion" [ style="filled" , shape=diamond, fontcolor="Red",
fontname="Helvetica", fontsize=10 ];
}
pgpH3bPhIvIcb.pgp
Description: PGP signature
Re: How should we deal with 'pointless-on-this-arch' packages?
"Roberto C. Sanchez" <[EMAIL PROTECTED]> writes: > On Sat, Oct 14, 2006 at 07:30:15PM +0200, Holger Levsen wrote: >> >> Isn't it up to the maintainer to say $package is not suited for >> $architecture? >> And aren't maintainers happy to receive hints (e.g. from porters or users of >> a certain package), which specific package is not suited for a specific >> architecture? >> > I would think that by definition a user of a package is the last person > who would be qualified to make a determinitation as to whether a > particular pacakge is suitable for a particular architecture. > > Regards, > > -Roberto I think that the maintainer is qualified saying "This source can't support an arch. Porting/maintaining the stuff is too difficult." The proters are probably qualified saying "This package is insane, nobody in his/her right mind will want to run this." E.g. the arch just lacks the hardware and processing power to run a realtime 3D game. The porters should also be the best judge about lack of speed on the buildds. A user is qualified saying "I want to run this software on my arch. I can't live without it even if it crawls." I think it should be in the porters control what packages to build for an arch with some guidelines what sort of packages can be removed without loosing release status. For example removing KDE would not be OK. Removal should be reserved for extreme cases though. Things that just need long to build should be put into weak_no_auto and limited to the stronger buildds of an arch. Maybe someone could come up with a britney patch that would allow an arch to make a list of package non-blocking for the testing transition. A package like axiom should not be blocked from testing because m68k hasn't build it yet. It should be perfectly save to remove it for m68k till such a time that the buildds catch up. Things that the porters/maintainer are reasonably sure noone will miss but we try to build it just in case anyway. I think a lot of the potential excludes fall under this category. Just my 2c. Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
On Sun, 15 Oct 2006, Charles Plessy wrote: The interest with debtags is that it allows to change the policy for a package without needing an upload or the intervention of the maintainer. This way, the decision of not building could be taken by the maintainer, and it could be reverted quickly by somebody else if a user requested the package on an excluded arch. How would you implement with with debtags? Are the buildd's paying attention to this now? Maybe I misunderstand. Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 [EMAIL PROTECTED]http://www.iit.edu/~segre[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/06 00:03, Goswin von Brederlow wrote: > "Roberto C. Sanchez" <[EMAIL PROTECTED]> writes: > >> On Sat, Oct 14, 2006 at 07:30:15PM +0200, Holger Levsen wrote: [snip] > I think it should be in the porters control what packages to > build for an arch with some guidelines what sort of packages can > be removed without loosing release status. For example removing > KDE would not be OK. Removal should be reserved for extreme cases > though. Things that just need long to build should be put into > weak_no_auto and limited to the stronger buildds of an arch. Why *shouldn't* KDE, GNOME, Firefox/Iceweasel, Tbird, and anything that requires Mesa/OpenGL, and all of Charles Plessy's scientific packages be marked do_not_build on 68k/Coldfire & ARM? If an Amiga (using the unaccelerated fb driver?) is running as an X Terminal for a powerful, modern box, the Amiga would need to process the OpenGL commands, no? - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFMdGhS9HxQb37XmcRAqDRAJ9vMAMZ8ZxvVXByqtZ9BRGGB2wifwCgqebl V68y29Jjbv9UJ+57ZDhDxsA= =wexU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
