Re: [RFC] Add upstream VCS info to control file
Hi, On Thu, Jun 14, 2012 at 02:59:26PM +0200, Gregor Jasny wrote: > Hello, > > When one tries to fix a FTBFS bug a look into the upstream VCS is > often helpful. Sometimes a link to browse them is easily found on > the homepage linked from the PTS page. But often these links are > deeply buried in the linked website. > > What I'd like to see in the Debian control file are Vcs-Upstream > fields that work like their Vcs- pendents but point to the upstream > sources. These URLs would also be linked in the PTS. > > Does this sound reasonable? We can think of 3 candidate files. #1, debian/copyright #2, debian/watch #3, debian/control (Not for me but you suggested) debian/copyright in DEP-5 form has information on the upstream source tar ball site but in human parsable format under "Source:". Requesting to add "Source-VCS:" field or something similar to debian/copyright seems most natural. debian/watch has information on the upstream source tar ball with computer parsable regular expression format. I will not oppose to add some extension of this format to support such needs, too. debian/control file has information on Debian package. (not for upstream tar ball). This is the least likely place to use for such purpose. Regards, Osamu -- 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/20120616105803.GE23133@goofy.localdomain
Re: [RFC] Add upstream VCS info to control file
Le Sat, Jun 16, 2012 at 07:58:03PM +0900, Osamu Aoki a écrit : > > We can think of 3 candidate files. > #1, debian/copyright > #2, debian/watch > #3, debian/control (Not for me but you suggested) I would like to add debian/upstream to the list. It is machine-readable, documented, gathered, and later this year I think I will more formally propose it as a DEP. See http://lists.debian.org/debian-devel/2012/06/msg00505.html for a longer agumentation. Please do not hesitate to tell me of any objections you have for this file, so that we can attempt to work them out. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20120616114003.gd6...@falafel.plessy.net
Re: [RFC] Add upstream VCS info to control file
On Sat, 2012-06-16 at 20:40:03 +0900, Charles Plessy wrote: > Le Sat, Jun 16, 2012 at 07:58:03PM +0900, Osamu Aoki a écrit : > > > > We can think of 3 candidate files. > > #1, debian/copyright > > #2, debian/watch > > #3, debian/control (Not for me but you suggested) > > I would like to add debian/upstream to the list. It is machine-readable, > documented, gathered, and later this year I think I will more formally > propose it as a DEP. > > See http://lists.debian.org/debian-devel/2012/06/msg00505.html for a > longer agumentation. > > Please do not hesitate to tell me of any objections you have for this file, > so that we can attempt to work them out. I've mentioned this before, to me the fact that it's using yaml instead of rfc2822-like syntax (the standard for Debian package metadata) is a problem, it means we need to use yet another different parser. thanks, guillem -- 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/20120616132733.ga18...@gaara.hadrons.org
Bug#677740: ITP: urbi -- Urbi operating system to control robots
Package: wnpp Severity: wishlist Owner: Adam Oleksy * Package name: urbi Version : 2.7.5 Upstream Author : Gostai S.A.S. * URL : http://www.gostai.com/downloads/urbi/2.7.5/ * License : AGPL Programming Lang: C++ Description : Urbi operating system to control robots -- 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/20120616154631.4815.44223.reportbug@muon
Re: Maintainers, teams, Uploaders, DMs, DDs, etc.
I demand that Arno Töll may or may not have written... [snip] > 2) ... Drive-by sponsoring does not work. It's annoying and back-breaking > to the sponsored maintainer to have a package containing lots of fixes and > maybe a new upstream version but nobody who uploads the you've been working > on (yes, that happens) mercurial-buildpackage. I recall being told that it should be rewritten in another language. I don't disagree *but* that would involve more change and, possibly, make the changes a lot less reviewable (and might introduce Many Bugs™). My choice here is to get what I've done to it in the archive before any re-implementation is done. (Incidentally, I'm using it for maintenance of the various xine packages.) > 3) It's not helpful because the sponsor, at best, has a rough and cursory > understanding how the package works. There's possibly a case for enabling DMUA without requiring a sponsored upload. But it would have to be case-by-case, and it's definitely not something to be done lightly. > 4) It's not clear at all how a bug fix could be uploaded to Debian at all, > so the package might be in bad shape soon as nobody who /could/ upload > feels responsible for it and those who care /can't/ upload. Packages get left to rot. DMs don't bother with them because they've been (effectively) ignored before; some may create external repositories for the packages instead... [snip] -- | _ | Darren Salt, using Debian GNU/Linux (and Android) | ( ) | | X | ASCII Ribbon campaign against HTML e-mail | / \ | http://www.asciiribbon.org/ Press SPACE or click mouse to continue -- 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/52a6383cc4%lists...@moreofthesa.me.uk
ifupdown's changed hook handling breaks other packages.
reassign 656584 ifupdown found 656584 0.7 severity 656584 grave retitle 656584 changed hook handling breaks other packages thanks On 16.06.2012 18:35, Andrew Shadura wrote: > reassign 656584 network-manager > thanks > > Hello, > > On Sat, 16 Jun 2012 17:52:01 +0200 > Michael Biebl wrote: > >> This bug was reassigned to network-manager without further >> justification, why, so I'm going to reassign it back. > > Reassigning it back as it really is a bug in NetworkManager. I've asked for further justification. Just saying "really" isn't. If it is a bug in NetworkManager, then please show me where. >> The 3 minute hangs are caused by the ifupdown hooks. Simply removing >> network-manager is no indication that is actually a network-manager >> bug. With the same reasoning I've could have just deleted the >> ifupdown hooks. > > No, they're caused by NetworkManager abusing /etc/network/interfaces > and ifupdown's hooks. Where is NetworkManager abusing ifupdown's hooks? >> Apparently this breakage was caused by an upgrade / changed behaviour >> of ifupdown. > >> If this was broken by the ifupdown update, then this is a grave bug in >> ifupdown i would say. > > Apparently not, it's ifupdown now a bit more strict regarding the > syntax. And it seems this breaks existing packages. This is not acceptable behaviour imho. Especially not, without coordination with affected packages. If you suddenly decide to change the behaviour of ifupdown, then please co-ordinate such a change and get affected packages fixed beforehand. And let packages know what they need to change. You keep repeating that this is a bug in network-manager, then be so decent and show me where and provide me with the necessary documentation of the changed ifupdown behaviour so I know how to fix it. Or better, provide a patch. And if necessary add corresponding Breaks to ifupdown so our users aren't bitten by this. So far you failed to provide any of this and only, stupidly re-assign the bug back to network-manager. Taking this to debian-devel, as I think as maintainer of ifupdown you need to act a bit more responsible in such a case and I think you disagree and consider this actions ok. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Why is irqbalance package so out of date?
On Sat, 16 Jun 2012, Aníbal Monsalve Salazar wrote: > On Fri, Jun 15, 2012 at 08:54:23AM -0700, Stephen Hemminger wrote: > >Irqbalance project has moved to http://code.google.com/p/irqbalance/ > >The current Debian package is back at 0.56 (over 2yrs old) > >and upstream is now at version 1.0.3 > > Uploaded 1.0.3-1. Thanks. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120616171110.gb21...@khazad-dum.debian.net
Re: ifupdown's changed hook handling breaks other packages.
Hello, On Sat, 16 Jun 2012 19:05:06 +0200 Michael Biebl wrote: > > Reassigning it back as it really is a bug in NetworkManager. > I've asked for further justification. > Just saying "really" isn't. > If it is a bug in NetworkManager, then please show me where. auto eth0 #NetworkManager#iface eth0 ... is not a valid syntax. So when we have interfaces 'defined' like this, initscripts' hook thinks we've got all 0 interfaces up so it can start. Of course, this needs to be fixed so it won't even try to do so. But the source of the problem is that NetworkManager was abusing a bug in ifupdown's parser. If you really wanted to 'hide' an interface, you should have commented out all the 'auto' and 'allow-' lines, not 'iface', leaving 'auto' intact, which apparently doesn't work. Also calling ifupdown's hooks at random moments isn't a good idea either. > If you suddenly decide to change the behaviour of ifupdown, then > please co-ordinate such a change and get affected packages fixed > beforehand. And let packages know what they need to change. That wasn't suddenly. It's been documented always but didn't work a little bit as expected. Exploiting a bug in a parser is always bad, and there's no excuse for doing that. I can't possibly know every person who's tried to misuse this software, and that's really a problem of those persons. Or shouldn't bugs get fixed at all then if anyone exploits them all the time? I think that reassigning a bug to network-manager in a first place was a clear enough message that something needs to be changed, so reassigning it back multiple times isn't a good way of communication either. -- WBR, Andrew signature.asc Description: PGP signature
Re: ifupdown's changed hook handling breaks other packages.
Hello, On Sat, 16 Jun 2012 19:05:06 +0200 Michael Biebl wrote: > If you suddenly decide to change the behaviour of ifupdown, then > please co-ordinate such a change and get affected packages fixed > beforehand. And let packages know what they need to change. Also, it's network-manager who tries to be a replacement somehow compatible with ifupdown, not vice versa, so NM maintainers should take care of their package to do things are they're supposed to be done in a compatible way. -- WBR, Andrew signature.asc Description: PGP signature
Bug#677750: RFH: gnokii -- Datasuite for mobile phone management
Package: wnpp Severity: normal Hi, I haven't had the need to use gnokii for years and am currently a bit too swamped with Real Life™ to dedicate the necessary time to its packaging, even though it's relatively low-maintenance. If there's anyone out there who still uses gnokii and has the time to lend a hand, your help would be really appreciated! Cheers Leo -- 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/20120616173614.3778.98541.reportbug@inertia.local
Bug#677821: ITP: wordwarvi -- A retro-styled side-scrolling shoot'em up arcade game
Package: wnpp Severity: wishlist Owner: Joseph Nahmias * Package name: wordwarvi Version : 1.00 Upstream Author : Stephen M. Cameron * URL : http://smcameron.github.com/wordwarvi/ * License : GPL2, CC-SA-2, CC-SA-3 Programming Lang: C Description : A retro-styled side-scrolling shoot'em up arcade game Word War vi is your basic side-scrolling shoot 'em up '80s style arcade game. You pilot your "vi"per craft through core memory, rescuing lost .swp files, avoiding OS defenses, and wiping out those memory hogging emacs processes. Includes joystick support with force-feedback. -- 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/20120617001109.4466.27186.report...@brain.nahmias.net
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On 16/06/2012 03:43, Serge wrote: > 2012/6/15 Jean-Christophe Dubacq wrote: > This is often seen as not a good move to have a user-writable directory on the system partition(s), since this provides for easy DOS >>> >>> DoS like what? /tmp on disk have a 5% safety limit available for system, >>> user can "DoS" only his own processes, and he can do that anyway. But >>> /tmp on tmpfs is even worse move, since it does not have 5% safety. >> >> 1) With 2TB disks, I certainly do not use 5% any more > > How is that? Isn't it a default value for 2TB disks any more? Or you mean > that you manually reduced it to e.g. 1%? Yes. That's the thing I do on most partitions (large ones). >> 2) Mysql, apache, postfix, all kind of vital systems, do not run as >> root. And if /tmp is full (and mounted on /), / is full (and so is >> /var). All kind of mayhem may happen there (I have seen it). > > You talk about mysql/apache/postfix, so I assume you mean a server. > And since it's about users filling /tmp I assume it's a multiuser server > (or rather at-least-one-user server). Then putting /tmp on tmpfs is a bad > idea there, because doing that will force users to use /var/tmp for large > files and will (not "can", but "will", since /var/tmp is not cleaned) > eventually fill /var partition, which is exactly what you need to prevent. Strangely enough, most users do not seem to know about /var/tmp. So, when they put large files, they tend to do that in (IMO better) other places: * $HOME/Desktop * $HOME * $HOME/Downloads * $HOME/theplaceIamworking which is better in terms of system management (except that it is also on NFS, and they suffer terrible pain because of that). Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
