Bug#676327: ITP: http-icons -- classic MIME icons
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: http-icons Version : 0~20041010 Upstream Author : Matt Comaione
Re: this bug .. bugs me
On Tue, Jun 05, 2012 at 11:52:52AM -0400, Joey Hess wrote:
> This bug is a textbook example of making the perfect the enemy of the
> good. It's disconcerting that we, or our users, are willing to put up
> with this.
I see what you mean and I absolutely agree with the general principle.
We have a tradition of being "perfectionists" in Debian, which is great,
but that couldn't be at stake with actually getting something (decently)
working to our users.
But in this specific case, in which I've been involved a bit encouraging
the recent course of action, I think that was not the only issue.
Rather, the "problem" seemed to be a mixture of what you mentioned + the
usual difficulty in acknowledging we are busy and the willingness of
letting it go our control a bit, so that others could chime in. It is
human, understandable, to some extent normal, and very well-known in
Debian.
The problem seems now on good track to be properly solved for Wheezy,
thanks to the work of Michael, Stephen, and Ove. But if there is some
sort of a take away message on this, I think it should rather be that
opening up package maintenance when we're busy and others are willing to
contribute is often the right way to go. There is very little to lose,
very little that cannot be undone, and often a lot to gain for our
users.
Even better, maintainers can prevent this kind of things from happening
by opening up *by default*, allowing commit to package maintenance Vcs
to all DDs, and documenting that commits there are welcome as long as
they follow some house rules.
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: this bug .. bugs me
On Tue, Jun 05, 2012 at 01:30:01PM -0400, Michael Gilbert wrote: > We are announcing our deferred uploads at least 10 days in advance > (unless RC) with git commit references, so Ove can review and/or > cancel/reject our work at any point. Thus, we haven't taken any of > his power away and it really can't be viewed as a "takeover". A few > of us are choosing to do the necessary work and review while Ove > doesn't have the time to do either himself. For some definition of "necessary" - still, thank you for doing *something*, even if it's sticking to the letter, if not the spirit, of some seemingly arbitrary rules. -- 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/20120606084730.GA9629@debian
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
Stephan Seitz writes: > On Tue, Jun 05, 2012 at 10:33:13AM +0200, Goswin von Brederlow wrote: >>Personally I thing DVD ISO images (downloaded) belong in your $HOME > > Donât you think this is getting quite ridiculous? Big temporary > files belong in your $HOME, but small temporary files in /tmp? Only to > switch /tmp from disk to RAM? No, I just don't consider a 4.7GiB download a temporary thing. I still have the mindset that that should take time, cost money and therefore be precious and should not be lost on reboot. >>somewhere. And locally generated should just pipe the image to the >>burner unless you want to upload the image somewhere, in which case > > Or you want to keep it safe, until you are sure the burned DVD is > working. > > Of course, if I want to keep the ISO it will be stored in $HOME, but > then it isnât a *temporary* file anymore. And /tmp *is* for > temporary files. > >>$HOME again. Just imagine a power failure after you painstackingly >>uploaded 99.9% of the iso and then you have to start from scratch again >>because a reboot cleans /tmp. > > TMPTIME exists and can be set according to your needs and your safety > concern. Yeah, as noticed somewhere else TMPTIME conflicts with tmpfs. Didn't even know that variable existed. So many hidden magic things to configure stuff ... >>Just out of interest: Do you have /tmp on /? Because if you do already >>have a seperate /tmp partition then that obviously stays used. > > I always have separate partitions for /, /usr, /var, /tmp, /usr/local > and /home (allright, with crappy software like udev and Co. which > starts wanting files in /usr needlessy at the early boot stages, I > will merge / and /usr in time). It isnât a problem for me. > > But we are talking about defaults. You wish to tell new users that > there two TB disk canât really be used as they wish because Debian > has a strange distinction between temporary files belonging in /tmp > and temporary files donât belonging in /tmp? But does the default have to be maximised for the dumbest possible user? Or should the default rather be for the intelligent user doing the right things? > According to the discussion the installer will create one partition > for swap and one for /. If this is true then the standard user has far > more space on disk than he has RAM. Just wait one more release and it will only be one partition with swap files. And lets give that partition a drive letter like "C:\". :) I realy don't like the direction DI is taking there. > Shade and sweet water! > > Stephan MfG Goswin -- 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/873968ajsk.fsf@frosties.localnet
Re: this bug .. bugs me
Simon McVittie writes: > On 05/06/12 16:52, Joey Hess wrote: >> This bug is a textbook example of making the perfect the enemy of >> the good. > > Yes, pretty much. On the bright side, multiarch and a modern Wine > version have both arrived (Wine 1.4 is admittedly only in experimental > right now, but I hope it'll reach testing before we freeze), meaning > this can finally work: > > archetype% dpkg --print-architecture > amd64 > archetype% wine --version > wine-1.4 > archetype% dpkg -s wine|grep Arch > Architecture: i386 > archetype% dpkg -s ia32-libs > Package `ia32-libs' is not installed and no info is available. > > ... so, thanks to everyone whose work and perseverance made that possible! > > S Juppey. Thanks to all the workers and the NMUers that made this possible. Now if wine 1.4 enters unstable we are finaly ready to kill ia32-libs for good. MfG Goswin -- 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/87y5o094xx.fsf@frosties.localnet
Bug#676344: ITP: cairosvg -- SVG converter based on Cairo
Package: wnpp Severity: wishlist Owner: Michael Fladischer -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: cairosvg Version : 0.4.3 Upstream Author : Kozea * URL : http://cairosvg.org/ * License : LGPL Programming Lang: Python Description : SVG converter based on Cairo CairoSVG is a SVG converter based on Cairo. It can export SVG files to PDF, PostScript and PNG files. The main part of CairoSVG is a SVG parser, trying to follow the SVG 1.1 recommandation from the W3C. Once parsed, the result is drawn to a Cairo surface that can be exported to various formats: PDF, PostScript, PNG and even SVG. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk/PNd0ACgkQeJ3z1zFMUGYoRACdE5dRfR2QXh68EleerCXqlC00 5FgAoJUWmkpQuXbObE5Wgr4vPNTxydxc =f0st -END PGP SIGNATURE- -- 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/20120606105007.5603.91491.report...@root.fladi.at
Re: this bug .. bugs me
On Wed, Jun 06, 2012 at 10:36:42AM +0200, Stefano Zacchiroli wrote: > On Tue, Jun 05, 2012 at 11:52:52AM -0400, Joey Hess wrote: > > This bug is a textbook example of making the perfect the enemy of the > > good. It's disconcerting that we, or our users, are willing to put up > > with this. May I bring in another example that bugs me: Source: mime-support Priority: standard Maintainer: Brian White Standards-Version: 3.1.1.1 -> standard package not team maintained not in Vcs According to changelog a typical upload is about one to two times a year mass closing several bugs. This might not be very spectacular, however when I scratched a bit on mime issues (Bug#497779) I and the submitter of a patch (non-DD) were contacted via PM by Brian White whether one of us want to maintain the package. I asked why he does not try to orphan or team maintain the package in case of admitted time constraints. His answer was that there is a difference between "any taker" and somebody who has an interested in it. This kind of handling things really bugs me as well. If a maintainer knows that he can not (fully) do the needed work but sitting silently because not trusting the community to provide proper help is something my English vocabulary is not sufficient to describe ... IMHO this perfectly fits in the sequence of cases we recently discussed here on this list which are a sign that something is broken in the way we handle maintainership. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120606112605.ga19...@an3as.eu
DUCK -the Debian Url Checker
Hi list, as I had some problems in the past finding upstream sources and homepages, I hacked up some scripts to monitor and display the results of the Upstream Homepage entries in the package control files. Please take a look at http://debian.tugraz.at/duck/ Currently the job runs once a day and the results are displayed. Maybe this is of some use for some maintainers and/or developers. One can also search for specific maintainers. Please tell me what you think about it - I have already some more features planned. Regards, Simon signature.asc Description: OpenPGP digital signature
Re: DUCK -the Debian Url Checker
Hi Dne Wed, 06 Jun 2012 15:24:50 +0200 Simon Kainz napsal(a): > as I had some problems in the past finding upstream sources and > homepages, I hacked up some scripts to monitor and display the results > of the Upstream Homepage entries in the package control files. > > Please take a look at http://debian.tugraz.at/duck/ Thanks, looks useful! > Currently the job runs once a day and the results are displayed. Maybe > this is of some use for some maintainers and/or developers. > > One can also search for specific maintainers. > > Please tell me what you think about it - I have already some more > features planned. Maybe you could also check URL found in debian/copyright? -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: this bug .. bugs me
On 06/06/2012 04:23 AM, Stefano Zacchiroli wrote: > Please don't spread incorrect information. The situation is by far not > the same (as in: it's *much* better now), and that is also thanks to the > discussion back then. -devel FTW, ... sometimes :-) > > Cheers. > I can see it, and I'm very happy of it! :) Thomas -- 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/4fcf75f2.7090...@debian.org
Bug#676384: ITP: libsort-key-top-perl -- select and sort top n elements
Package: wnpp Severity: wishlist Owner: Laszlo Kajan * Package name: libsort-key-top-perl Version : 0.06 Upstream Author : Salvador Fandiño * URL : http://search.cpan.org/~salva/Sort-Key-Top-0.06/lib/Sort/Key/Top.pm * License : Perl Artistic Programming Lang: Perl Description : select and sort top n elements in Perl The functions available from this module select the top n elements from a list using several common orderings and custom key extraction procedures. -- 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/20120606160231.26668.79895.reportbug@n0d.rostclust
Re: seeking co-maintainers for spamassassin
On Tue, Jun 05, 2012 at 10:48:23PM -0700, Noah Meyerhans wrote: > I'm perfectly happy to see patches attached to some of the open bugs, so > please don't hesitate to send them in. Ideally I'd like to get a > co-maintainer or two, though. BTW, this is bug #676317 in wnpp. Please follow up there if you'd like to help. noah signature.asc Description: Digital signature
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Wed, Jun 06, 2012 at 11:09:31AM +0200, Goswin von Brederlow wrote: Stephan Seitz writes: Don’t you think this is getting quite ridiculous? Big temporary files belong in your $HOME, but small temporary files in /tmp? Only to switch /tmp from disk to RAM? No, I just don't consider a 4.7GiB download a temporary thing. I still have the mindset that that should take time, cost money and therefore be precious and should not be lost on reboot. Well, everything you do with your computer will cost money. The download will take its time, yes, but you don’t have to wait for it to be finished. But for me your example still describes a temporary file *if* I want to delete the file after I burned the ISO. But does the default have to be maximised for the dumbest possible user? Or should the default rather be for the intelligent user doing the right things? But the intelligent user can change the default hisself, the dumbest can’t. And Debian does allow the inexperienced user to install his system. According to the discussion the installer will create one partition for swap and one for /. If this is true then the standard user has far more space on disk than he has RAM. Just wait one more release and it will only be one partition with swap files. And lets give that partition a drive letter like "C:\". :) I realy don't like the direction DI is taking there. ROTFL, yes maybe. I agree that I don’t like one big partition as well, but how do you want to partition a disk by default? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
> >But does the default have to be maximised for the dumbest possible user? > >Or should the default rather be for the intelligent user doing the right > >things? > > But the intelligent user can change the default hisself, the dumbest > can’t. And Debian does allow the inexperienced user to install his > system. Sometimes people are intelligent but that doesn't mean that they are willing to spend days just to fix these problems, maybe being intelligent doesn't make you interested in learning obscure switches for debian. (and knowing these doesn't make one intelligent). So it's not about stupid users, it's about having a configuration that works by default, without requiring people to go throu mailing lists to learn what they need to install debian and have it working. -- Salvo Tomaselli -- 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/201206061938.27022.tipos...@tiscali.it
Re: this bug .. bugs me
On 06/06/2012 04:36 PM, Stefano Zacchiroli wrote: > Even better, maintainers can prevent this kind of things from happening > by opening up *by default*, allowing commit to package maintenance Vcs > to all DDs, and documenting that commits there are welcome as long as > they follow some house rules. > Technically, is there a way to allow write access to all DDs on an Alioth Git repo, but not to anyone without upload rights? When in a team, it's easy, a bit of chmod g+w is enough, but for all DDs? Thomas P.S: I'm on the low threshold NMU list, and I'd welcome anyone to send me some git format-patch! :) -- 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/4fcf9ca8.4000...@debian.org
Re: this bug .. bugs me
Hi, Please forgive me if this is the wrong place to ask (or if I'm completely wrong here). On Wed, 2012-06-06 at 11:15 +0200, Goswin von Brederlow wrote: [...] > > Juppey. Thanks to all the workers and the NMUers that made this > possible. > > Now if wine 1.4 enters unstable we are finaly ready to kill ia32-libs > for good. > Reading this I assume ia32-libs will be removed from Debian (with which I completely agree btw), what about packages outside of Debian that currently depend upon ia32-libs? To name a certain package: skype. Its AMD64 package from the official website depends on it. Can we work around this somehow? I'm in no way affiliated with upstream here, but looking at their particular history I don't expect any update soon with a proper solution. Regards, Steven signature.asc Description: This is a digitally signed message part
Re: this bug .. bugs me
On Tue, 5 Jun 2012 16:12:31 -0400, Michael Gilbert wrote: >> They are members of pkg-wine already, so I think they can make changes >> that can improve the status but not limited to minimal changes for >> NMU. If Mike don't want to "hijack" at least for now, team upload is >> good enough. > >Hopefully this will make some people happy: I pushed the first team >upload of the 1.4 series to unstable about a half-an-hour ago :) Yay! Congrats! Greetings Marc, making a fresh backup of the notebook and upgrading -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- 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/e1scksq-0004n4...@swivel.zugschlus.de
Re: this bug .. bugs me
On Wed 06 Jun 2012 15:16:26 Steven Post escribió: [snip] > Reading this I assume ia32-libs will be removed from Debian (with which > I completely agree btw), what about packages outside of Debian that > currently depend upon ia32-libs? To name a certain package: skype. Its > AMD64 package from the official website depends on it. > Can we work around this somehow? I'm in no way affiliated with upstream > here, but looking at their particular history I don't expect any update > soon with a proper solution. Disclaimer: I'm not througly following multiarch stuff. Well, if Debian removes ia32-libs and friends, most surely Ubuntu will follow (if not there already). Then I think those third parties who depend on it should start thinking about doing the correct thing: release a new package. My two cents, Lisandro. -- 9: Que es el "Explorador" de Windows * El tipo que le roba las ideas a MacOs Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
dropping ia32-libs [Was, Re: this bug .. bugs me]
On Wed, Jun 06, 2012 at 04:14:56PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > On Wed 06 Jun 2012 15:16:26 Steven Post escribió: > [snip] > > Reading this I assume ia32-libs will be removed from Debian (with which > > I completely agree btw), what about packages outside of Debian that > > currently depend upon ia32-libs? To name a certain package: skype. Its > > AMD64 package from the official website depends on it. > > Can we work around this somehow? I'm in no way affiliated with upstream > > here, but looking at their particular history I don't expect any update > > soon with a proper solution. > Disclaimer: I'm not througly following multiarch stuff. > Well, if Debian removes ia32-libs and friends, most surely Ubuntu will follow > (if not there already). Then I think those third parties who depend on it > should start thinking about doing the correct thing: release a new package. > My two cents, Lisandro. Ubuntu has already had a release in which ia32-libs is a transitional package; and for the past two Ubuntu releases, the amd64 skype package has not integrated correctly with the desktop (because it has Recommends that must be satisfied by i386 packages that aren't part of ia32-libs). So I guess we shouldn't expect this situation to change in the near future. OTOH, if Debian drops ia32-libs entirely, then the wrong package won't be installable and users would *have* to install the right one (the i386 one), so there's that at least. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: this bug .. bugs me
On 06.06.2012 20:08, Thomas Goirand wrote: > On 06/06/2012 04:36 PM, Stefano Zacchiroli wrote: >> Even better, maintainers can prevent this kind of things from happening >> by opening up *by default*, allowing commit to package maintenance Vcs >> to all DDs, and documenting that commits there are welcome as long as >> they follow some house rules. >> > Technically, is there a way to allow write access to all DDs on an > Alioth Git repo, but not to anyone without upload rights? That's collab-maint. All developers have automatically commit access to it. This includes many non-DDs accounts too, who have applied explicitly into collab-maint, but so what? A commit can be reverted easily and people who abuse their rights probably won't have write access to collab-maint for a long. I fail to see why we would need /another/ repository for DDs only. You know we welcome everyone [1] apparently. [1] <20120606151810.gj4...@camblue.cbg.collabora.co.uk> -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#676438: ITP: libcatalyst-view-petal-perl -- Petal View Class for Catalyst
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: libcatalyst-view-petal-perl Version : 0.03 Upstream Author : Christian Hansen, * URL : http://search.cpan.org/dist/Catalyst-View-Petal/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Petal View Class for Catalyst Catalyst::View::Petal is the Catalyst view class for Petal. Your subclass should inherit from this class. -- 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/20120606221742.32286.88625.report...@auryn.jones.dk
Re: this bug .. bugs me
Le Thu, Jun 07, 2012 at 02:08:40AM +0800, Thomas Goirand a écrit : > On 06/06/2012 04:36 PM, Stefano Zacchiroli wrote: > > Even better, maintainers can prevent this kind of things from happening > > by opening up *by default*, allowing commit to package maintenance Vcs > > to all DDs, and documenting that commits there are welcome as long as > > they follow some house rules. > > > Technically, is there a way to allow write access to all DDs on an > Alioth Git repo, but not to anyone without upload rights? > > When in a team, it's easy, a bit of chmod g+w is enough, but for all DDs? Hello Thomas, this can be granted using ACLs. http://wiki.debian.org/Alioth/FAQ#How_do_I_give_write_permission_outside_my_Alioth_project_.3F Have a nice day, -- Charles Plessy Greetings from Singapore -- 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/20120606222904.gc23...@falafel.plessy.net
Re: Moving /tmp to tmpfs makes it useless
So RAMTMP now defaults to off. I know it can be hard to give ground on something you've invested a lot of work into, so Roger Leigh has my respect for taking this thread into consideration. A lot of people came down on the pro-tmpfs side in this thread. You have some good reasons to want to make it available to users. I just wanted to invite you to make it easier for users to enable tmpfs where appropriate -- d-i's partman component needs to gain support for managing tmpfs partitions (#245465). This would allow users to set up tmpfs at install time, to preseed it, and even to have recipes that include it. Partman is not the easiest thing to work on, but if you know how to use debconf, and shell script, and have some time and VirtualBox, this is well within your grasp. Last time I added a filesystem (btrfs) to partman, I did it by copying the partman-ext3 source and modifying appropriately[1]. It was really just a few hundred lines of code. If interested, contact me or debian-b...@lists.debian.org -- see shy jo [1] And then refactoring out a lot of common code of course. signature.asc Description: Digital signature
Re: DUCK -the Debian Url Checker
On Wednesday, June 06, 2012 03:24:50 PM Simon Kainz wrote: > Hi list, > > as I had some problems in the past finding upstream sources and > homepages, I hacked up some scripts to monitor and display the results > of the Upstream Homepage entries in the package control files. > > Please take a look at http://debian.tugraz.at/duck/ > > Currently the job runs once a day and the results are displayed. Maybe > this is of some use for some maintainers and/or developers. > > One can also search for specific maintainers. > > Please tell me what you think about it - I have already some more > features planned. FWIW, it already noticed the homepage for one of my packages was 404. I emailed the upstream and just heard back that they hadn't known the page had gone missing and will fix it. Thanks, Scott K -- 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/5253430.Z2GAZWrkTq@scott-latitude-e6320
