Re: packaging with git: automatic setup of remotes/upstream when cloning
I (used to) document the upstream branch location in debian/README.source. -- 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/20130306134716.GA11387@debian
Re: multi-tarball packages in version control
On Sat, Feb 16, 2013 at 09:57:16AM +0100, Tzafrir Cohen wrote: The only problem is that svn-buildpackage does not support this. Or rather: it should have, but a long standing bug (with a partial fix attached to it, to which the maintainer did not comment. But since uploaded one or two versions). I recently tried the most recent patch from #585658 when looking at 'love', another multi-source package, but it did not resolve the build failure for me. In that situation, I gave up, used dpkg-source to extract/merge the upstream tarballs, manually checked out ./debian, used debuild -i.svn -I.svn and avoided svn-buildpackage altogether. But that was for one patch on a package I don't regularly maintain, so I guess that doesn't scale. (I should probably update the bug.) If the patch is working for you, great! Sadly it's not comprehensive enough to work in all situations yet. -- 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/20130306135029.GB11387@debian
Re: Bug#700506: ITP: trinity -- A Linux System call fuzz tester
On Thu, Feb 14, 2013 at 11:37:03AM -0500, Scott Kitterman wrote: The chances of Trinity, the desktop environment, being packaged in Debian are very low. That may be the case, but it may still confuse users regardless. -- 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/20130215095727.GE19236@debian
Re: Go (golang) packaging, part 2
On Wed, Feb 06, 2013 at 09:23:02AM +, Neil Williams wrote: Then don't package Go at all and leave it entirely outside the realm of dpkg - no dependencies allowed in either direction, no files created outside /usr/local for any reason, no contamination of the apt or dpkg cache data. If what you want is complete separation, why is there even a long running thread on integration? That's one possible solution, and a low-risk one at that. The others carry the risk of doing the job badly, especially if there is not enough resource to implement them going forwards. Then why bother discussing packaging Go if it isn't going to be packaged, it's just going to invent it's own little ghetto in /usr/local? That seems pretty perjorative. The reason Go has invented it's own little ghetto is to solve the distribution problem. The reason they want to solve it is because, despite our best efforts, we haven't solved it. Pretending we have done helps nobody. From Go's perspective, we are a bit player. There's a pattern of misplaced arrogance and pride that permeates -devel from time to time whenever difficult integration discussions come up (systemd included) that really doesn't help. Let's not overstate our importance in the wider world, it does not help us one bit. Step by step we'll just close our doors to the rest of the Universe and slide further into irrelevance. If Go wants to be packaged, it complies by the requirements of packaging. Go doesn't want anything: It's a programming language and environment, not a sentient being. The authors of Go are probably not that bothered about it being packaged, seeing as they've put energy into solving the distribution problem themselves, at the same time making it more difficult to distribution-package. The people who want to see it packaged are people who want to see Debian users be able to conveniently interact with Go-land. -- 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/20130206094410.GA322@debian
Accepted chocolate-doom 1.7.0-3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 05 Feb 2013 22:17:17 + Source: chocolate-doom Binary: chocolate-doom Architecture: source amd64 Version: 1.7.0-3 Distribution: unstable Urgency: low Maintainer: Debian Games Team pkg-games-de...@lists.alioth.debian.org Changed-By: Jon Dowland j...@debian.org Description: chocolate-doom - Doom engine closely-compatible with vanilla doom Closes: 692762 Changes: chocolate-doom (1.7.0-3) unstable; urgency=low . * Remove deprecated dm-upload-allowed field from the control file. * Provides: doom-engine. Closes: #692762. * Remove duplicate upstream Changelog. This addresses: * duplicate-changelog-files usr/share/doc/chocolate-doom/ChangeLog.gz usr/share/doc/chocolate-doom/changelog.gz * Rework copyright file to current DEP-5 format. This addresses: * obsolete-field-in-dep5-copyright maintainer upstream-contact * obsolete-field-in-dep5-copyright name upstream-name * obsolete-field-in-dep5-copyright format-specification format * comma-separated-files-in-dep5-copyright paragraph * missing-license-paragraph-in-dep5-copyright public domain Checksums-Sha1: 658db98e1d0aff6e716ee0cde1420fb7518eae83 2091 chocolate-doom_1.7.0-3.dsc 4facace6b20ae5d6142e46277764105d8fbd8a8b 5852 chocolate-doom_1.7.0-3.debian.tar.gz bf0a4c80ea9f339c499b56cf944ac8ee5b58aaef 433386 chocolate-doom_1.7.0-3_amd64.deb Checksums-Sha256: 917af9a7f5a7a89940c37a0ef9b4d846b449a901fcccb6c4e10cfce0566e2ecd 2091 chocolate-doom_1.7.0-3.dsc b0bbd63183b96b1390c78345cfe875be477f58943427cbf1e0e4a3cc1a06000b 5852 chocolate-doom_1.7.0-3.debian.tar.gz 1c5f0f495afefcfe8a19f30f3d04eaced7ad7b9c15211d3571e3334bccfb1021 433386 chocolate-doom_1.7.0-3_amd64.deb Files: a3c8f14f5aaa5c04c0bd169616aba7fd 2091 contrib/games optional chocolate-doom_1.7.0-3.dsc 0efe6bad1463cb3d895a60672c601634 5852 contrib/games optional chocolate-doom_1.7.0-3.debian.tar.gz d05259f8c7475696651664fdae7435f9 433386 contrib/games optional chocolate-doom_1.7.0-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJREjHpAAoJEAkHQJYGFfMP/3tTJEZzE3fo5/P7zEOLzDKC 7rH044bl4yM5MLxQstEBia3hO/SR/eml1RfKYQ561le6PM0NBEVOJYxxm1P3WXX9 utt6Szhj2d/+9wEKIPwEoww2DC7kJlfX5SwfuDh2d5H89d3q5pd8kD9obQ9YpRZ9 Rp2yBsFPArvz9Q5UF2/E/DfSb+gJTv5ljP/YhOkINB61wWCrElpnn33jQc7esRh5 XMmlQyGCs4vy8AL3LczxgRzb9SINNvBfHyepGvx6odOR14YoxJLIbbM8Bn9+vgGw ygg7VNWWS09AK2p5CIYke4aFa+Bxmgf9qOT06ovX0pl/XdZiqLOIqEodssoJBigq OB3MVSq1X5bSqwN1fYh+lTfK0Rev7c3KesUkiM+5Mj1gtf2FDYylY3+1izQWLHxw OB1or7PPkd4LR81hcBPat8owYYmyFmPTwHwOdjz0iEtvviDnSjGzXQgkHOohjaYK z/SmSO98DAgMLmMLdcohEBpEeCze4tIK4ki8BJfzgBDWJHt14qdbZXgK+e7HNk/n 9Y7n0QvbPwzFYPU8LKHiu4z47Jx2BrpEfOBMGWRZi7FjrNU8gNJgaBJt2ru3poXq hrswMedg34B8FfnvEE0/teH3wvgoVQ8cButnZ/6Z022aA21JL8996OkHyGPwZzCg kf3zXIoGRbXHuZBJ0W/h =XH8y -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1u32xm-00078y...@franck.debian.org
Re: Go (golang) packaging, part 2
On Fri, Feb 01, 2013 at 01:27:05PM -0800, Russ Allbery wrote: Lennart Sorensen lsore...@csclub.uwaterloo.ca writes: Not all C libraries are distributed from one central site and they certainly don't expect you to use a central package installation system. So much more the shame for C. Those are *improvements* that Perl came up with (well, actually, that the TeX community came up with and Perl copied) that made the ecosystem much nicer. On that note, Rusty Russell's CCAN is interesting: http://ccodearchive.net/ -- 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/20130205172005.GA21754@debian
Re: Go (golang) packaging, part 2
On Fri, Feb 01, 2013 at 03:20:08PM -0500, Lennart Sorensen wrote: On Fri, Feb 01, 2013 at 10:00:32AM +, Jon Dowland wrote: As a Haskell developer, I find cabal much more convenient than nothing, in the situation where the library I want is not packaged by Debian yet. If I want my haskell libraries and programs to reach a wide audience, I need to learn Cabal anyway. If you are writing libraries to add to the language, then I don't consider you a normal developer using the language. Well, my point stands if I were writing a mere Haskell user-oriented program for that matter. You generally don't have to because things are in Debian archives already. It can be a chicken and egg problem. I see .debs often when a repository does exist (spotify, dropbox I think, google chrome) and many situations where a repository does not (humble indie bundle) If you want bleeding edge, then you are not a normal user and you certainly aren't a system administrator that wants to keep a controlled system they can reproduce. I must admit I'm losing touch of precisely what you are arguing here. I guess it's not everything that matters will be packaged with Debian hence the previous paragraph re: external apt repositories. Yet, I don't suppose you're arguing that availability in an external apt repository is any guarantee of quality (Or at least I hope you're not). I don't think we're necessarily talking about bleeding edge, either. If something is not packaged in Debian, it's not necessarily bleeding edge. I know dpkg --get-selections will tell me all the software installed on the system so I can do the same on another one. If yet another package maanger gets involved I have to know about it and do something different to handle that. That's not a good thing. True. But you also lose lots of other information, such as what is marked automatic, the contents of your debconf DB and corresponding changes in /etc, non-corresponding changes in /etc… dpkg --get-selections is not and has never been a solution to the problem you are describing. -- 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/20130205172651.GB21754@debian
Re: Go (golang) packaging, part 2
On Fri, Feb 01, 2013 at 12:38:16PM -0800, Russ Allbery wrote: Using Debian packages is a *means*, not an *end*. Sometimes in these discussions I think people lose sight of the fact that, at the end of the day, the goal is not to construct an elegantly consistent system composed of theoretically pure components. That's a *preference*, but there's something that system is supposed to be *doing*, and we will do what we need to do in order to make the system functional. And in particular, where a problem cannot be solved in pure Debian, I don't want Debian to interfere with the bit of the solution that lives outside of its domain. That may include not attempting to package/patch/alter/adjust upstream systems like Go that have a different philosophical approach. The worst case scenario IMHO is some people invest a lot of time to make the Debianized-Go stuff quite divergent from upstream, people's expectations of how things behave in Go-land are broken when they access Go-via-Debian, the job is never quite complete and so we get extra bugs, and a new upstream community relationship is marred. This is a much worse outcome than not attempting to package Go at all, IMHO. I guess I'd quite like the boundaries of responsibility to be very clear, when I'm forced to have such boundaries. -- 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/20130205173047.GC21754@debian
Re: Go (golang) packaging, part 2
On Fri, Feb 01, 2013 at 04:02:18PM -0500, Lennart Sorensen wrote: For cpan there is even dh-make-perl. The solution then is to make equivelant scripts for other languages. The solution is NOT to use some other package installation system. Although I've never used dh-make-perl myself, I'm lead to believe that it is perhaps *the* most successful tool of its type (that is, of things that create .debs from packages in an alternative repository system like CPAN, gems, cabal, etc.), and that it works as reliably as it does (which as Russ points out is not 100% by any means) by relying on data from CPAN. So it's hard to use it as an argument against such external package systems. -- 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/20130205173517.GD21754@debian
Re: Go (golang) packaging, part 2
On Wed, Jan 30, 2013 at 06:46:35PM -0500, Lennart Sorensen wrote: Absolutely. As a user I have a nice package management system that I know how to use and which works well. I don't need another one. As a Haskell developer, I find cabal much more convenient than nothing, in the situation where the library I want is not packaged by Debian yet. If I want my haskell libraries and programs to reach a wide audience, I need to learn Cabal anyway. It is not the job of a language developer to invent yet another bloody package distribution and installation system. And yet they do, and so we need to manage it. Remember that Debian does not just provide a package management system: it also provides repositories and dictates what goes in them according to the DFSG. Whilst adding new repositories is relatively simple for users (and growing in popularity for upstreams), installing bare .deb files is still not a very smooth process (although massively improved by e.g. gdebi these days) From an upstream POV, they want their software in the hands of end users. They don't want to have to learn and build a myriad of different package types (.deb, .rpm, etc.) and crucially neither do we. In many cases they don't want to have to wait for a distro to package their software for them either. In the Go case, their users are people who might have a shell/web account but not admin access on a shared host somewhere, running god knows what distro and version, hence having a self-contained fat binary that is guaranteed to run wherever libc is meets their goals. -- 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/20130201100032.GA12622@debian
Bug#699158: ITP: squishyball -- audio sample comparison testing tool
Package: wnpp Severity: wishlist Owner: Jon Dowland j...@debian.org * Package name: squishyball Version : 0.1~svn18785 Upstream Author : Monty mo...@xiph.org * URL : http://svn.xiph.org/trunk/squishyball/ * License : GPL Programming Lang: C Description : audio sample comparison testing tool squishyball is a simple command-line utility for performing double-blind A/B, A/B/X or X/X/Y (A/B/X with additional sample order randomisation) testing of audio samples on the command line. . The user specifies two input files to be compared and uses the keyboard during playback to flip between the randomized samples to perform on-the-fly comparisons. After a predetermined number of trials, squishyball prints the trial results to stdout and exits. . squishyball can be used to help establish what lossy audio codec settings are optimal for a particular combination of user and audio equipment. -- 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/20130128104531.GA22755@debian
Re: Linux Future
On Wed, Jan 23, 2013 at 10:46:33AM +0100, Josselin Mouette wrote: You might find this useful: http://np237.livejournal.com/33449.html I made this presentation in the hope to make such things easier to understand for the sysadmin. Just for the record I found it a good read, and mentally have it bookmarked for the next time I need it. -- 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/20130123131603.GA30151@debian
Re: Bug#696006: ITP: tinyos -- operating system for sensor motes and embedded devices
Hi - we have/had some modules here at Newcastle University using TinyOS and having it available in Debian may make it easier for us to deliver the teaching in future. Thanks! -- I pledge not to post to any systemd-related thread on -devel until (at least) 2013. -- 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/20121217111200.GA26408@debian
Re: Bug#695897: ITP: corekeeper -- Core file centralizer and reaper
These have been forcemerged. -- I pledge not to post to any systemd-related thread on -devel until (at least) 2013. -- 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/20121214095458.GA14161@debian
Re: GFDL in main
On Tue, Dec 11, 2012 at 01:04:22AM +0100, Jakub Wilk wrote: * Jakub Wilk jw...@jwilk.net, 2012-12-01, 12:10: Any volunteers to file bugs? I'll file them myself. Please collect them together with a usertag to help others who may wish to get involved. -- 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/20121211102843.GD17039@debian
Re: dput-ng/1.1 in unstable
On Thu, Dec 06, 2012 at 09:53:41AM +0800, Paul Wise wrote: Anything less than the full fingerprint (8, 7 or whatever) I hadn't noticed that 0xFEFACED was only 7 characters. That's cheating ☺ It might be worth noting that GPG does not accept less than 8 chars as an argument prefixed by 0x $ gpg --list-keys 0xDEFACED gpg: error reading key: malformed user id I've just learned that my key is uniquely identifyable by the last three bytes within (and only within) the current debian-keyring $ gpg --list-keys --with-colons|grep AAA: pub:u:4096:1:0907409606AA:2009-09-14:::u:Jon Dowland j...@debian.org::scESC: Not that this information is particularly useful to me. (the '4096' bit is serendipity too, since it's a 4096-bit RSA key.) -- I pledge not to post to any systemd-related thread on -devel until (at least) 2013. -- 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/20121206114436.GA15967@debian
Re: dput-ng/1.1 in unstable
On Thu, Dec 06, 2012 at 01:02:29PM +0100, Arno Töll wrote: Hint: gpg --list-keys --with-colons --keyring /usr/share/keyrings/debian-keyring.gpg --no-default-keyring No need, I have 'keyring /usr/share/keyrings/debian-keyring.gpg' in my ~/.gnupg/gpg.conf. Not sure though, why nion is listed with his old 1k key in the DD keyring. Doesn't count until he is… -- 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/20121206181840.GA19400@debian
Re: Packaging MATE for Debian
On Mon, Dec 03, 2012 at 03:39:03PM -0500, Jeremy Bicha wrote: What's so bad about evince that you need to use a forked version anyway? Or gnome-icon-theme, gnome-keyring, gnome-terminal, etc. This is drifting off the topic at hand, please, take it to another list if you want to continue down this line. -- I pledge not to post to any systemd-related thread on -devel until (at least) 2013. -- 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/20121203213602.GB6742@debian
Re: Packaging MATE for Debian
On Mon, Dec 03, 2012 at 02:06:03AM +0100, Adam Borowski wrote: You can use the upstream packaging, available at: deb http://packages.mate-desktop.org/repo/debian wheezy main Thanks but I'm interested in possibly helping an effort to package MATE in Debian, rather than run it myself. So from an _user_'s point of view, John Paul could just upload everything as-is and it'd be in a better shape than Gnome3 or XFCE already. I don't know about packaging internals here so I can't offer this kind of help, though. I think it's the packaging internals that I'm most likely to be able to help with. -- I pledge not to post to any systemd-related thread on -devel until (at least) 2013. -- 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/20121203213718.GC6742@debian
Re: Packaging MATE for Debian
On Sun, Dec 02, 2012 at 01:26:50PM +0100, John Paul Adrian Glaubitz wrote: Hey, On Wed, Nov 21, 2012 at 11:22:52AM +0100, John Paul Adrian Glaubitz wrote: I'd therefore like to ask if anyone here would be willing to help me to get MATE into Debian for Jessie. I'd like to ping back and see if there's anyone here who'd be interested in joining me to package MATE for Debian. If there was a git repo to check out I'd be happy to test packages and do some mild work, but not as a main commitment. -- 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/2012120143.GA24863@debian
Re: wheezy and gcc 4.3 (and maybe 4.5)
I feel your pain. I've tried to do much the same thing to diagnose old kernel bugs. I recommend installing squeeze on a small root partition entirely separately. (or older than squeeze if necessary) -- I pledge not to post to any systemd-related thread on -devel until (at least) 2013. -- 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/2012120258.GB24863@debian
Re: Really, about udev, not init sytsems
On Fri, Nov 30, 2012 at 12:19:22PM +0100, Salvo Tomaselli wrote: I am using systemd on my laptop, i have a very default system configuration, (except that i compile my own kernel to avoid initrd)… ^^ …if I, with a normal, standard desktop configuration I do not agree that reconfiguring your machine to avoid an initrd is a normal standard desktop configuration. There's also several other things about your setup which I would argue are not standard (see below) can find that many bugs in a software that is supposed to be extremely stable, how many bugs would people with more specific setups find in it? Despite the fact we're in freeze and the focus of attention for maintainers is to fix RC bugs and get wheezy out the door, ⅓ of the bugs you've submitted have been fixed. That sounds pretty good to me! It's also unfair to necessarily suggest that the three bugs you've filed are bugs in systemd itself. They could be bugs in the packaging of systemd, bugs in service files supplied by other packages, or bugs in other daemons that are exposed by running systemd. I suppose they could also not be bugs at all. That's certainly the maintainer's opinion for one of the ones you submitted. You also say in another bug yourself I know the bug is in wicd. I think you are being pretty disingengous about systemd and your experiences. (I've only briefly scanned over the three you have submitted: #694048¹, #661239² and #693522). So I honestly quite like systemd but I think it should be in alpha-testing right now. In Debian, that's essentially the situation right now. Nobody is arguing to make systemd the default init today. ¹ Indicates you don't have libpam-systemd installed, which means you have set apt install recommends to false: another deviation from standard desktop configuration. Also the last maintainer mail on the bug says This looks like a bug in the fetchmail init script. ² wicd? Another deviation from standard desktop configuration -- 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/20121130144908.GE5807@debian
Re: Candidates for removal from testing (2012-11-30)
Thanks for the update! -- I pledge not to post to any systemd-related thread on -devel until (at least) 2013. -- 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/20121130163906.GA21619@debian
Re: Really, about udev, not init sytsems
On Fri, Nov 30, 2012 at 12:55:13AM +0800, Thomas Goirand wrote: However, you are running Gentoo and rebuild your kernel, why would you bother with such thing as kernel modules and initrd? The thing is, many (most? all?) Gentoo user, as far as I understand (I'm not a Gentoo user), do not use kernel modules at all. In that situation, you'd be posting to gentoo-dev. -- 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/20121129171831.GB3605@debian
Re: Really, about udev, not init sytsems
I had a half-drafted message to the same effect, but deleted it earlier. Thanks Neil for speaking up. I have to say Thomas, many recent messages from you across many threads, mostly on -devel but also elsewhere, have seemed to have very little in the way of polite, constructive content, advancing the state of the various arguments taking place in Debian at the moment. I'd really appreciate it if you could think twice before contributing to the larger, more controversial threads going forward, and only hit the 'send' button if what you're writing is novel, new, and of interest to the rest of the Debian community (so not e.g. a correction to a point in one other individual's message, of interest really only to that individual, and not every other developer.) -- 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/20121128172742.GA8248@debian
Re: the right bug severity in case of data corruption
On Wed, Nov 28, 2012 at 03:34:32PM +, Darren Salt wrote: Having just viewed the raw text of my message (as sent), there's one other little wrinkle which I already knew but had failed to consider and which makes testing of this useless: gpg handles any 'From ' lines itself in a reversible manner, using '- ' as the prefix. Definitely reversible? How does it distinguish 'From ' from '- From' prior to signing? Ad infinitum down the rabbit hole… The following SHOULD be 0, 1, and 2 levels of quoting, first to last. It was for me (Maildir) -- 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/20121128172920.GB8248@debian
Re: the right bug severity in case of data corruption
On Wed, Nov 28, 2012 at 05:29:20PM +, Jon Dowland wrote: The following SHOULD be 0, 1, and 2 levels of quoting, first to last. It was for me (Maildir) Just rechecked, I'm wrong - the first line was quoted. -- 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/20121129075041.GB24783@debian
Re: the right bug severity in case of data corruption
For anyone else following along at home who is slightly puzzled by all this, http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/mail-mbox-formats.html explains the different mbox formats, what 'From_' means, etc. -- 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/20121127115625.GB8359@debian
Re: lib- prefix for non-library (was: Bug#693998: ITP: linux-minidisc -- Free software for accessing NetMD and HiMD MiniDisc devices)
On Mon, Nov 26, 2012 at 05:41:35PM -0400, David Prévot wrote: Seems weird to see another non-library ending up in the pool/main/libr/ directory of our archive (and yet another special case to handle for tools like deborphan). It would be nice to avoid the lib- prefix for non-library. Nice, yes, but not nice is contorting package names away from upstream's given name to work around a technical limitation in our pool structure/ package programs. Rightly or wrongly package names are still a key piece of information used in user package discovery. -- 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/20121127152612.GA10865@debian
Re: debian mate
On 22 Nov 2012, at 15:57, Ian Jackson ijack...@chiark.greenend.org.uk wrote: So if you don't like that decision it should be escalated to the Technical Committee. I'm surprised that *anyone* can refer issues to tech ctte. Has a non DD ever submitted something worthwhile? -- 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/95fe493f-c0c9-4a4c-ac7a-14c312f5e...@debian.org
Re: Re: debian mate
On Thu, Nov 22, 2012 at 11:51:06PM +0100, Stefano Karapetsas wrote: GNOME Classic is just as featureful and usable as GNOME Shell, which makes it very suitable for a default desktop on non-3D machines. But GNOME Fallback is going to be dropped soon. I'm surprised nobody has talked about forking *that*. -- 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/20121123075248.GA2@debian
systemd (was Re: Gentoo guys starting a fork of udev)
Hi - please change the Subject: of the thread if the topic of conversation has moved on. (We're all guilty of not doing this enough…) On Wed, Nov 21, 2012 at 12:07:29AM -0600, Kevin Toppins wrote: snip 32 line preamble I realise your intentions are good, here, but please, it is not much help. Writing concise and to-the-point messages is the best way to communicate on a list like this. Please don't answer with a reference to read some kind of documentation. Sadly it is obvious from the rest of this message that you are not up to speed on the topic here. If you want to usefully contribute to the topic, at a very least you should familiarise yourself with the prior threads about systemd to debian-devel. At a very, bare-minimum least. It would then of course be polite to other thread participants to make sure you are at least up to speed on what systemd is and how it works… I think it is categorically important to *identify* and *convey to the community*... - What role is systemd designed to facilitate? - Do we know why we want to prevent a process from forking? This is something that pretty much goes without saying, if you are familiar with the technology which underpins what we're talking about. - Let's hypothetically decide to prevent a fork on some conditional basis (as opposed to no forks at all).is it systemd's responsibility, or would that fall to the responsibility of the linux kernel? It's the init systems responsibility. Systemd's implementation relies on a kernel feature to work (cgroups). The division of responsibility seems very sensible here. - If simply checking that the daemon's permissions were set correctly before execution would solve this problem, then it would make sense that a system redesign need not be in order. It wouldn't. The UNIX permission model does not address this problem. - Enforcing permissions is the responsibility of the linux kernel. Not systemd. snip Why should this model be changed, and why should systemd enter into the authority architecture of the system? It isn't being changed. Systemd uses a kernel feature (cgroups) to achieve this. What you have written makes no sense. It's the kernel's job to enforce traditional UNIX permissions, but you need userland software like chmod to actually manipulate them. - Establishing and maintaining the permissions is the responsibility snip - POSIX capabilities is already in place to prevent/hamper runaway snip These questions are based on your flawed understanding of the relationship between the kernel, systemd and cgroups, my reply above essentially covers these. Well what if some modifications to the init scripts where made something along the lines of snip, and Why not just modify _autofs_ to check upon startup Here we go. You're saying I acknowledge feature X as useful. Instead of moving from existing software A, lacking feature X, to existing software B with feature X, let's alter software A to incorporate feature X. Oddly enough the authors of systemd decided against that route, as did the authors of upstart. It is no good us arguing hypotheticals. You or anyone else who favours this approach, go away and actually implement this stuff in sysvinit, and then when you can show that it works, we can debate along these lines. But I tell you, the upstart and systemd authors are not idiots. Nor the openrc people, nor the authors of a half-dozen other init replacements. If this was a feasible way forward, perhaps one of these enlightened engineers would have done it? In all honesty the one thing I don't think is up for debate anymore is that sysvinit needs to be replaced if we are to benefit from these newer features. And more importantly. why should systemd be involved in this? What does systemd do that the daemon's launch routine cannot accommodate? You need to read up on what systemd does. Why should systemd be involved in this? Not everybody has a need for autofs, likewise, not everybody should need systemd to handle a problem with autofs for autofs/them. You're half baked suggestions for sysvinit and autofs are the first steps on the road to writing systemd again. What's becoming clearer and clearer in your message is that what you object to in systemd is not what it does or how it does it (which you don't understand) but simply the name itself. You are a victim of the anti-hype. First the data in the volume won't be available until the fsck completes, so the server won't be able to give the data any faster than it takes to fsck the volume. Minimum time limit, unless you have a new filesystem check design to get around this, that is a rather unchangeable wait time until you can *serve* the data You might investigate why fsck takes the time it does and how could fsck be made faster. Having the server up even if the data partition is not ready yet can be useful in many situations. Not least aiding debugging if the fsck fails,
Re: debian mate
On Wed, Nov 21, 2012 at 04:03:33AM +0100, Michael Schmitt wrote: So much for the general rules... but exceptions ARE possible! And I just try to make a case here about how important it might be! IF you had a set of MATE packages all ready to go and you were asking for a freeze exception for them, then the release team would be in a position to consider an exception. But there are no such packages. We're arguing hypotheticals (as we often do on -devel, to my eternal dismay). There's still a lot of work to do in order to get MATE ready for Debian. I'm sorry, it's simply too late for wheezy. The last thing we want to do is delay the release at this point. Long drawn out freezes are horrendously demoralising for everyone. It's important we get wheezy out in a timely fashion. -- 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/20121121084843.GA28050@debian
Re: Packaging MATE for Debian
On Wed, Nov 21, 2012 at 11:22:52AM +0100, John Paul Adrian Glaubitz wrote: I'd therefore like to ask if anyone here would be willing to help me to get MATE into Debian for Jessie. As you know, there is already an effort to package MATE ongoing (at least #658783). The purpose of ITPs is to prevent people from duplicating each others work. If you want to encourage others to join the effort, it might be worth setting up a Debian packaging team (an Alioth project?), with a corresponding mailing list, and documenting the team and the team's processes on the Debian Wiki. That would make the fact there is a team that could be joined more visible, and the rules of engagement clear. Since it might be a while before MATE packages are acceptable to be uploaded to Debian proper, a separate package repository with the latest WIP packages is a good idea, lowering the amount of effort for someone to try it out and get involved. Also as you aren't the filer or owner of that ITP please make sure anything you do is agreeable to the actual ITP owner. -- 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/20121121120224.GB28050@debian
Re: debian mate
Please stop top-posting. -- 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/20121121151332.GA998@debian
Re: debian mate
On Wed, Nov 21, 2012 at 03:48:08PM +, Neil Williams wrote: MATE will not be in Wheezy and staying on Squeeze until Jessie is released is probably not suitable for most users. It's quite likely that if MATE packages make it into Debian at all, they will be provided in backports, so some users might end up doing GNOME2/squeeze → MATE/wheezy/backports → MATE/jessie However, if people choose to migrate to XFCE instead of GNOME3, then a migration to a GNOME2-alike in Jessie isn't as hard The Jury's out on that. -- 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/20121121164907.GA2935@debian
Re: New virtual packages: lv2-plugin and lv2-host
On 21 Nov 2012, at 17:27, Russ Allbery r...@debian.org wrote: don't know if Ian is, but I certainly would. We have a bunch of existing virtual packages that aren't really useful because they don't offer any sort of guaranteed interface, and therefore cannot be meaningfully used in package relationships (which is the whole point of a virtual package). Hear hear. We recently hit this problem with vpkg boom-engine and vavoom. I guess the interface that virtual packages provide should be defined somewhere, most likely in policy. Perhaps the .txt file needs to grow into something more structured. I'd be happy to make a start on a proof of concept if you agree. Is it best to take this to -policy list or is -devel ok for now? -- 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/e64ac7b4-7817-4055-8eac-94e2dbff0...@debian.org
Re: Gentoo guys starting a fork of udev
On Mon, Nov 19, 2012 at 01:25:38PM -0600, Steve Langasek wrote: The core components are always built (which includes systemd itself, as well as udevd and journald). For some uses the configure switches do not provide sufficient modularity. For example, they cannot be used to build only the man pages, or to build only the tmpfiles tool or udevd. I always have the feeling that everyone who is zealously advocating systemd simply didn't read the documentation first. From what I understand, the sentence above is assuming you are running make. Their makefile is well specified, so you can just build udevd by running make udevd. However, I have yet to see (and haven't tried) how easy it would be to actually build all of the udev components from the sysemd source in the context of a package. I.e., you could not rely on the output of make install putting the files you need into a given directory, I think you'd need to cherry-pick the files you *know* you need for udev, and tracking that set and changes to it may prove a real pain. (I think Matthias tried to make the same point, but I couldn't parse his email.) -- 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/20121120093535.GC10807@debian
Re: Fwd: procenv_0.9-1_source.changes REJECTED
On Tue, Nov 20, 2012 at 11:10:37AM +, Dmitrijs Ledkovs wrote: I currently do not have facilities to build the package in question with the host running Debian's kernel. So how can you prove that the package builds? -- 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/20121120114516.GA13984@debian
Re: debian mate
On Tue, Nov 20, 2012 at 06:37:48PM +0100, Michael Schmitt wrote: And whatever they or anybody else does in that regard, it will come to late for wheezy. All of MATE will come too late for Wheezy. It's already too late for Wheezy. -- 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/20121120220730.GB13984@debian
Re: RFC on MBF (non-freeness of The Software shall be used for Good, not Evil)
user j...@debian.org usertags 692614 + good-not-evil usertags 692619 + good-not-evil usertags 692624 + good-not-evil usertags 692625 + good-not-evil usertags 692627 + good-not-evil usertags 692628 + good-not-evil usertags 692629 + good-not-evil usertags 692630 + good-not-evil usertags 692631 + good-not-evil usertags 692613 + good-not-evil usertags 692615 + good-not-evil usertags 692626 + good-not-evil usertags 692621 + good-not-evil thanks On Fri, Nov 09, 2012 at 04:25:43PM +, Jon Dowland wrote: I've found one of these - #692614 - is the whole set collected together under a common usertag or similar? I couldn't find one so I created one, above, using the list of bugs Neil found for his wheezy-ignore tagging. Please let me know, and the release team probably, if we've missed one, and please use usertags in future to collect together bugs under a single MBF. -- 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/20121116194139.GA1220@debian
please change subject / trim accordingly (was Re: major linux problems summary 2012)
Every post to this thread makes my heart that little bit heavier. Can participants please a) consider whether this is on topic to -devel and move to -user if not; b) trim quotes appropriately; c) change Subject: when the subject under discussion changes Thanks in advance. -- 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/20121113150958.GC14192@debian
Accepted vavoom 1.33-5 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 13 Nov 2012 21:53:04 + Source: vavoom Binary: vavoom Architecture: source amd64 Version: 1.33-5 Distribution: experimental Urgency: low Maintainer: Debian Games Team pkg-games-de...@lists.alioth.debian.org Changed-By: Jon Dowland j...@debian.org Description: vavoom - Advanced Doom/Heretic/Hexen/Strife engine Closes: 676580 691741 Changes: vavoom (1.33-5) experimental; urgency=low . [ Jon Dowland ] * Reword the long description a bit. Thanks Filipus Klutiero. Closes: #676580. . [ Fabian Greffrath ] * Fix Vcs-Browser field in debian/control. * Install vavoom.desktop via vavoom.install file, instead of moving it around in debian/rules. * Try to avoid some unnecessary dependencies. * Add . and / to the -iwaddir parameters in the wrapper scripts. This allows to specify IWADs via the -iwad parameter by either relative and absolute path names, which is needed for the freedoom wrapper script to work. * Add postinst and prerm scripts to register vavoom as an alternative for doom and boom (Closes: #691741). Checksums-Sha1: 4e9613e661c42c4dcf13d6aec5e7f5acdd251204 2076 vavoom_1.33-5.dsc 79845b4abf954dbe4a46a9c77bf0fddcf4a174bf 10787 vavoom_1.33-5.debian.tar.gz e58a15b5303e644f692402710e122f07f016cbc8 3275442 vavoom_1.33-5_amd64.deb Checksums-Sha256: e381f336f7cd927088b04ae36f46ba4167203bcdb807e9f94bf907d0234a4769 2076 vavoom_1.33-5.dsc 49d4772a7a7b9b37bb849a60715e13557487c50d632a83d7d8da3844bf3579b0 10787 vavoom_1.33-5.debian.tar.gz 985027cf81438b8903b5f52439db92be176d28f36ffe19a97d4a3c7aa1cf61e2 3275442 vavoom_1.33-5_amd64.deb Files: 651881cf98b01fc5e255856b7a34b0b9 2076 games extra vavoom_1.33-5.dsc 577125eebd45bb70307fb8e4f42a0589 10787 games extra vavoom_1.33-5.debian.tar.gz 24c6f7eeaced5a7d1d8c04b316abb7c1 3275442 games extra vavoom_1.33-5_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQosdNAAoJEAkHQJYGgDYP/0MDjXOCssOb6RHcRG0itn7v YmJmkxpZqgVAV6GMSzYGAIHnFph/ozbKBoPFZVavBbGyXsXnB3X6yHuhL2RVwEEr zduqNGx0mJ62+qRbDWrLVR8sGApoGV3e48axjGNEp+8Y1VDLQOPykxZF+fro7f8m +8sM5vuYjuhmABvaA9rzUaLQyny1lXIe8X9VHv2q8DOviykEFEV2LqsbG3IOUXLH YS9dzUISqDTtiVCj/AMvpr8xlIi0G7lSG1RymACEFhY1d5lMVUCsVLTynYT+RqMy vsokQZDok9cqMoUwXuSe15qpniWbFzpde6yOE0FmeujxGsyJvW4luDS7RWE7mWiK oRjofwRvUNd+rlDZZdOi7gzP3cIN4Lc9rswhZZX9mbdHKq0+QL/hmRjzrZfmji08 gGUCLkPB356H6wZPtlRc8drXf1ihGI5JlmgHOnxN5RUA+2GWYvLQOs3OiR+mDmaE X/ssSGpptFVrwyAWJTlaS1UR/xddS893/igw106w96xPFKog5LJ4KGz+3OhvcLgm HlAwqBPuTPqWv/BwUZH4wMJGiCg4i48E6c7RGJMEYuGnty+7VPakbvMlE8gv7IqT KIYLhKLQFS1REuNbdqCLgh4uFemmU03g+Y9EWJuBL2bt7elFR5sf6JTHFmQOSdeV WxCf0y9SqRGsp8DHpXxe =nlb9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1typ2j-0003bx...@franck.debian.org
Re: Bug#692894: ITP: plum -- plum is a command line tool used to interact with the U-Boot netconsole of any LaCie product
On Sat, Nov 10, 2012 at 03:51:53PM +, Neil Williams wrote: lucie-uboot lucie-uboot-netconsole If upstream refer to it as 'plum', then eradicating plum from the package name entirely isn't sensible. -- 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/2012092443.GF23696@debian
Re: Bug#692830: ITP: nemo -- File manager for cinnamon
On Fri, Nov 09, 2012 at 05:06:57PM +0100, John Paul Adrian Glaubitz wrote: I don't think it is currently a sensible decision to introduce duplicate GNOME3 packages into Debian. Nautilus 3.4 is currently available through GNOME3, so this would introduce redundancy. wheezy will have 3.4 but 3.6 is already in experimental. So uploads targetting experimental only until post-freeze should address your concern. -- 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/20121109162316.GC23696@debian
Re: RFC on MBF (non-freeness of The Software shall be used for Good, not Evil)
CCing Ansgar On Thu, Nov 08, 2012 at 04:25:51PM +0100, Leo 'costela' Antunes wrote: Ansgar has recently made an MBF against all packages including the problematic JSON license term The Software shall be used for Good, not Evil. I've found one of these - #692614 - is the whole set collected together under a common usertag or similar? Thanks! -- 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/20121109162543.GD23696@debian
Re: Bug#692830: ITP: nemo -- File manager for cinnamon
On Fri, Nov 09, 2012 at 05:27:03PM +0100, John Paul Adrian Glaubitz wrote: Yes, that's correct. But that's only one of the points of my criticism. I am in general not very much convinced by the quality of the packages in Linux Mint. Neither am I. I did look at cinnamon and muffin briefly, saw many of the same issues you describe for mdm (muffin a regex-change-only version of mutter) and I couldn't see the point of muffin at all (why couldn't cinnamon be a client of mutter?) plus lots of copyright and documentation issues. However I expect things will improve given time, and/or input from people who care (Debian packagers). -- 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/20121109171711.GE23696@debian
Re: Bits from the release team - Freeze update
On Thu, Nov 08, 2012 at 10:40:18PM +0800, Paul Wise wrote: Which policy applies to #685913 (and all the other open unblocks)? The policy announced at the beginning of the freeze or the current policy? …or the time the unblock was filed? -- 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/20121108171855.GB3915@debian
Re: RFC on MBF (non-freeness of The Software shall be used for Good, not Evil)
On Thu, Nov 08, 2012 at 07:13:45PM +0100, Holger Levsen wrote: On Donnerstag, 8. November 2012, Jakub Wilk wrote: As far as I can see Mr Crockford _enjoys_ being asked to change his license. So no, please don't feed the troll. As much as I think this licence is stupid (from my free software point of view), I don't think he should be called a troll, just because he likes his users to do good - even if only by his own definition. I seem to recall reading something Crockford wrote about people who wanted him to change their license, and coming to the same conclusion as Jakub had, that Crockford was perpetuating the license purely to troll. However, I've just tried to find whatever it was I read, and I can't: I can only find him (famously) discussing the issue and how he granted a license exception to IBM (jsonsaga.ppt and http://news.ycombinator.com/item?id=763165), which is not enough for me to come to the same conclusion. Maybe I'm mis-remembering. -- 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/20121108203337.GA11858@debian
Re: Bits from the release team - Freeze update
On Thu, Nov 08, 2012 at 08:29:02PM +0100, Benjamin Drung wrote: Hm, I filed two unblock requests after that deadline, but before reading the announce mail about it. You don't state whether the decision impacts them or not, but so it goes… -- 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/20121108203530.GB11858@debian
Re: Bits from the release team - Freeze update
On Thu, Nov 08, 2012 at 07:21:30PM +, Neil McGovern wrote: Apologies for the lack of clarity in the d-d-a posting - the new acceptance criteria are for unblocks filed after 11:54:49 + today. No problem - thanks for the clarification! -- 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/20121108203550.GC11858@debian
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Mon, Nov 05, 2012 at 06:12:53PM -0200, Henrique de Moraes Holschuh wrote: Microcode updates will be applied immediately when the microcode packages are installed or updated: you don't have to reboot. You will have to keep the packages installed, though: as explained above, the microcode updates have to be reapplied at every boot. You can check which version of the microcode your processors are running by looking for microcode lines on /proc/cpuinfo. This information is only available on recent kernels (such as the Wheezy kernel). This did not appear to work for me automatically. I did not upgrade my kernel in the same aptitude session. Before: $ grep microcode /proc/cpuinfo microcode : 0x1b After installing intel-microcode and iucode-tool 0.8.3-1: $ grep microcode /proc/cpuinfo microcode : 0x1b After some manual fiddling # iucode_tool --scan-system -vv iucode_tool: cpuid kernel driver unavailable, cannot scan system processor signatures # modprobe cpuid # iucode_tool --scan-system -vv iucode_tool: trying to get CPUID information from /dev/cpu/0/cpuid iucode_tool: system has processor(s) with signature 0x000206a7 iucode_tool: trying to get CPUID information from /dev/cpu/1/cpuid iucode_tool: trying to get CPUID information from /dev/cpu/2/cpuid iucode_tool: trying to get CPUID information from /dev/cpu/3/cpuid iucode_tool: checked the signature of 4 processor(s) $ grep microcode /proc/cpuinfo microcode : 0x28 $ dpkg -S /boot/vmlinuz-$(uname -r) linux-image-3.2.0-4-amd64: /boot/vmlinuz-3.2.0-4-amd64 ii udev 175-7amd64/dev/ and hotplug management daem Shall I file a bug? -- 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/20121106143209.GB17743@debian
Accepted chocolate-doom 1.7.0-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 06 Nov 2012 21:28:00 + Source: chocolate-doom Binary: chocolate-doom Architecture: source amd64 Version: 1.7.0-2 Distribution: unstable Urgency: low Maintainer: Debian Games Team pkg-games-de...@lists.alioth.debian.org Changed-By: Jon Dowland j...@debian.org Description: chocolate-doom - Doom engine closely-compatible with vanilla doom Changes: chocolate-doom (1.7.0-2) unstable; urgency=low . * Add myself back to uploaders. Checksums-Sha1: e14463afa028d9155655e1b1e51386730ee68af4 2114 chocolate-doom_1.7.0-2.dsc cd51f2fd6a398c01e951b7fbcaf7efda17ccacd2 5767 chocolate-doom_1.7.0-2.debian.tar.gz c16d2e059d9a997fc364c68f2485c8f5d997db61 483090 chocolate-doom_1.7.0-2_amd64.deb Checksums-Sha256: 2bc4d41fcbbbc39e6cf7f295fb8571e1df0d3068a3e43171488d0df0b8e43cb7 2114 chocolate-doom_1.7.0-2.dsc f417e9fdcbe072fb861ad5863c9275d893f6357f30292e4ceefd8ce05bb8ee7a 5767 chocolate-doom_1.7.0-2.debian.tar.gz 05eb14ac69f5702af73e9de8063d3352a0b96920f7b8a67808a625ebefe9e22e 483090 chocolate-doom_1.7.0-2_amd64.deb Files: 56890d1cf93a2587bb4a0fec58e2570f 2114 contrib/games optional chocolate-doom_1.7.0-2.dsc e51ec19198fd718ddac5e81582393947 5767 contrib/games optional chocolate-doom_1.7.0-2.debian.tar.gz 06eed80ae64a592c384aee23d4f46353 483090 contrib/games optional chocolate-doom_1.7.0-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQmYRTAAoJEAkHQJYG40gP/juE1Wc33oy58tz/WggGzvp9 nPBPoJyHf8+yCt/1Z1bPZuKiKm499/asoR4P2C35tigkWeTAfwtv3EvTuBCpkUzc La3ksBZxiAl5UsZwWSnM4+5kBSjh12DVM/BOvx++mHMx3vyXalPVfwCNp4RKC5m6 1mW9sCDW+BhQTb3fhawHK9xv3BACV/SyMUxT5zpq8AFlgk6zoNTs6ECQfFYpC5z3 cZxVbRNLP6JqmIlUw4RFrelh/vLEcY8Xaf6JKgxMpVGehzaj+Ub3mt/IYJVwxW3Z 9Swji5QTNDjI5VIJaE7eLMQJEo4U43FwcTSNcTxDu7UnJ5rmRSeUZX2E3bf2pdln WfIQYh0ClXhafJvxMN+1fbqC4EUr1VyS8UsmpTJn3wIweia5LIFzY8to5OnKDBAg YJ6kCF7ZtjCEcmHypiaS3K8+MLsUOxlfa656Os8q5S2IkKue/fHCh+pcZ++WmyxV hD+4HICOlPysJnmw1Y50VbGQ5H5KNlfdghR9jLl8Xv/7oirni7zGwDiGUNhcoFKM IbW8PZVYRPBdtj917tF+JK8qtfuTlGa+7IRpVyF6ZdqiFbsw0hjyBGyXb91P7tSN 1i7Tnx7PkBkgozBtQSEBnj2PKbSmCd+LeXXRLAEIRsYKrBHIXu2WxR4pAWHwfEl4 0UdGe8HPCKkQzEwxW4Vn =zYQM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1tvreb-0003me...@franck.debian.org
Accepted bup 0.25~git2011.11.04-6 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 06 Nov 2012 22:50:59 + Source: bup Binary: bup Architecture: source amd64 Version: 0.25~git2011.11.04-6 Distribution: experimental Urgency: low Maintainer: Jon Dowland j...@debian.org Changed-By: Jon Dowland j...@debian.org Description: bup- highly efficient file backup system based on git Closes: 692009 Changes: bup (0.25~git2011.11.04-6) experimental; urgency=low . * Add --parallel to dh* calls to support parallel building. * Depend upon python-pyxattr and python-pylibacl so that bup meta works. Thanks Sascha Silbe. Closes: #692009. Checksums-Sha1: 3f0ac1350bc46785ec7b3bee57426985033b43af 2022 bup_0.25~git2011.11.04-6.dsc 20cdcd87f46861b40b6853cde2c9ebf62c0ee9ef 5379 bup_0.25~git2011.11.04-6.debian.tar.gz 13950ebd16b590e503ef74d443e7aebc0018ed49 162972 bup_0.25~git2011.11.04-6_amd64.deb Checksums-Sha256: 87cc4fd939835b6296d25e0c7153fa75ee6d346560694b6326dbf97b40a5dcf8 2022 bup_0.25~git2011.11.04-6.dsc 31098c78a3f1663d2c9c3c26064cc33e0f0928fefb4a8ab1a7c77efff046ddbe 5379 bup_0.25~git2011.11.04-6.debian.tar.gz b81ac903f4c2ddd093f44c33af7d80acbf7bc39ecd7bceb69de608610173857c 162972 bup_0.25~git2011.11.04-6_amd64.deb Files: ade8eb665aaf3d81efbe4a9b6fa98ce6 2022 admin extra bup_0.25~git2011.11.04-6.dsc 3c649439b5448be850778dfb86ce5ceb 5379 admin extra bup_0.25~git2011.11.04-6.debian.tar.gz 555cb806209c6492322a894cade32cd6 162972 admin extra bup_0.25~git2011.11.04-6_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQmZTeAAoJEAkHQJYGmKsP/2d/rfMyaET5tm77MSAdaGCs es+NYgpk4ixYghpgMLmyLjNlhIctbAAgCWFODzunkLDh+D/OSI7dneYqggs/cQxd y3a6zpNeqi3yIkSzdThVFgb4epeRNCKVNP0+G+ENV3S0FbbKzRXyO2Djh2vRJvjF uHtS+z0/9gkcXadspCCGpi/aeL+Cl4L+AYwf96rxlqnghkdzSAGhd4fAvW5lSAk5 GaCNQTqiGsplziqVnOKtUhlvwEF7oS7TZWb0aJzRFnfI2RI4R2yCWfM4o+XY7C9A FyzG7o0uyJRV+wTfHZCtBn8jMpP/TjGgpxS+g8Zd+6ttGp2OQmlrGp8JU2FVK68+ 1ZHcwe84yFLJHjRSM8mhtqsNYdW4R6swSCEhGdNZ7WVrbihDvX0Y1Gzw1rRIYlel NDm1mP+l4LyPXh2kzlcFxSVcPDNLhlHCM8/BDVKDjHsusfvwWdMRDvStlu9FMNBB aAlumxFMxPvsBDUloHm1/Fx+rVFtT4ZaPHyjCnQTRtBmVSeuURXVA8PtOpJ4uPGr 0LcpO/xJZ9q2J/seTRFfAMZ3UUpe0kOGrJrO6et4CQpOn6Jzig9cp6EzGeYGcdXD 0XKf9k6yCJnmmqkFiTPzuwYHB/rD3bN2DD1ZI/E1T5sX0HVHeV+cKSFoanPPrGuY SpKjraUYWPdNjMIt8MYt =UJE9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1tvsot-0004uq...@franck.debian.org
Accepted prboom 2:2.5.0+dfsg2-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 06 Nov 2012 23:09:00 + Source: prboom Binary: prboom Architecture: source amd64 Version: 2:2.5.0+dfsg2-1 Distribution: experimental Urgency: low Maintainer: Debian Games Team pkg-games-de...@lists.alioth.debian.org Changed-By: Jon Dowland j...@debian.org Description: prboom - clone of the legendary first person shooter Doom Closes: 579749 Changes: prboom (2:2.5.0+dfsg2-1) experimental; urgency=low . * Fix a bashism in fix_upstream.sh and use the URW-Bookman-Demi-Bold font for menu graphics in preference to Helvetica. Thanks Fabian Greffrath! * As a result, generate a new 'upstream' DFSG tarball. * Remove build-dependency on libsmpeg-dev which is superfluous (handled by libsdl-mixer1.2-dev). * Add build-dependency on libpng-dev. It currently links against this due to a dependency-of-a-dependency, but that might change (and we want this for PNG screenshot support). Closes: #579749. Checksums-Sha1: a8721ba6dcc11194c323ad3ba3f1bbd97b586247 2046 prboom_2.5.0+dfsg2-1.dsc 82f58f246fb0394c2b1bde1c79ada7fb66187410 1012396 prboom_2.5.0+dfsg2.orig.tar.gz a9e61e310871e5361d643598366b89b6a32849a8 10695 prboom_2.5.0+dfsg2-1.diff.gz 6d4145b9e3e74a0df59df587b425a03a1d08f9e9 516370 prboom_2.5.0+dfsg2-1_amd64.deb Checksums-Sha256: d97889ad65daca58e4cfad0aa1e51be4f1fd8f4f636900534ed56b3d08e82a7d 2046 prboom_2.5.0+dfsg2-1.dsc 25c9dd947a738ce840a2081fd01844f2283d95c4e3be52cf397a5760bc9af957 1012396 prboom_2.5.0+dfsg2.orig.tar.gz 0eccff691642369ab758c1b862bd52119dd8a9a97d45b2f5e9c734ef0ba4d092 10695 prboom_2.5.0+dfsg2-1.diff.gz a9ab4c8f7eea18e7b264118181e9bfde96146c9b91c3a6daa05321cce419e1dd 516370 prboom_2.5.0+dfsg2-1_amd64.deb Files: 814305bf7f19c17352a3da731de81d40 2046 games optional prboom_2.5.0+dfsg2-1.dsc 3ac6c6e02144e2a575a02638fb8d8433 1012396 games optional prboom_2.5.0+dfsg2.orig.tar.gz 83f9c7a2538d10c4279f858898c63bb5 10695 games optional prboom_2.5.0+dfsg2-1.diff.gz c1e7febd356bf59e0964a145080bae8b 516370 games optional prboom_2.5.0+dfsg2-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQmZnyAAoJEAkHQJYG6wsQAM9Dtw/VWHKY5YUkMEh0evVK 6j3BsMRQkes8SiawMHUdnzeZm5Qsg9tAn4gtzr/LoC+W18NErrCVpjd1pp/XPUrI WbaMQQzAA90eyeI4aLzi0LgT0KYaJcxlSuxapfxY/U3XwsCulRr/LUeQs0MIFfRG +GQ26kyeUhxAaFc587j5nY07Y5RRlSJIuDFtRD3SBCN2ytOwAQGCxZtQqpcp5JlD OWevn0d2lHraUSH4Ce2IIxN/paYcAl2d6saQMUMpnrNJEAlArKpOvrwOR6HRAyf3 UWaOUELQ9cxlirm1CxrzKQers67uWPPKCx3y4ddbYPVaGN3jb4kLhjgUCBSXeMZL EVsr1PwuYL57QEecvwzf/36PRSZcU7MMrHzzarQgc0BINw20zXv23OQXtT3T0ZXs 57QD50wBBSFSeNJDq4ZKdF4WUx5vEN5STwgBSO3DKV4hmGmYVOqfKK+3yWg+SrDH 4KVT7xPtpLuHiv/fm3Dlen3ETQfCBzto/ZiSxa+RGDyCv7wQnDwA6R8ZoMei5702 NmIoFre1iA804xc1ihqnZomGHJjuf4kkCu1eki2O6ZcaLn4/Onuj1UBcIrSom0wS JugOuBMX8ZSSR6vGu/ZRTcW5J1MpQQyp0hCPa62qvIMzkYkTDny4OGP+QGwmEhAw cIPgWHXWlfeHXz3uxSAR =hkoh -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1tvsdr-0007oa...@franck.debian.org
Re: Candidates for removal from testing (2012-10-30)
On Tue, Oct 30, 2012 at 04:53:24PM +0100, Jerome BENOIT wrote: does it make sense to establish a list of candidates for reintroduction to testing ? Is this not something best managed on a case-by-case basis? -- 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/20121030163630.GA20675@debian
Re: Bug#691624: ITP: dput-ng -- next generation Debian package upload tool
On Mon, Oct 29, 2012 at 03:53:42PM +0100, Wouter Verhelst wrote: Wrong. It will be a new thing, not related to the previous thing. It's evidently related: if not in terms of actual reused code but in terms of who is expected to use it and what it is to be used for. On Sun, Oct 28, 2012 at 01:19:31PM -0400, Michael Gilbert wrote: I don't see the harm in calling things what they actually are. It's rude. In your opinion. I disagree. -- 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/20121029145855.GA27366@debian
Re: Bug#691624: ITP: dput-ng -- next generation Debian package upload tool
On Sun, Oct 28, 2012 at 08:03:02AM +0100, Philipp Kern wrote: I'd prefer if such a tool could replace an existing one. Why not aim at replacing dput if there's a reason for it? I must concur. I can't see the reason for dput, dupload and dput-ng to co-exist. If dput-ng has the momentum and is a superset of the features of the previous two we should remove the previous two. I use the royal 'we', too often we hide behind our package-centric view of the world (package A is not actively maintained. Package B reimplements it. Removing Package A is inactive maintainer C's problem.). But having a plethora of similar-but-slightly-different tools to do the same job increase the surface area of stuff for beginners to navigate through and makes it that much harder for contributors to get a handle on things. -- 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/20121029151928.GB27366@debian
Re: Candidates for removal from testing (results)
Great stuff, thanks! -- 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/20121026160652.GC20294@debian
Re: Bugs filed in unexpected places
On Fri, Oct 26, 2012 at 07:39:52PM +0300, Andrei POPESCU wrote: On Vi, 26 oct 12, 15:38:03, Thibaut Paumard wrote: it is currently showed in the PTS: e.g. http://packages.qa.debian.org/a/alevt.html: problems How many non-DDs/DMs do you think are aware of the PTS? My guess is: not that many. IMVHO the BTS is much more visible, especially to users who do take the time to report bugs. How about how many non-DDs/DMs are aware of wnpp, versus the processed result of it (http://www.debian.org/devel/wnpp - which is not the same as b.d.o/wnpp, and could be auto-generated from e.g. a usertag or top-level tag just as easily as from b.d.o/wnpp) -- 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/20121026175244.GA22021@debian
Accepted freedoom 0.8~beta1-1 (source all)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Fri, 26 Oct 2012 08:08:25 +0100
Source: freedoom
Binary: freedm freedoom
Architecture: source all
Version: 0.8~beta1-1
Distribution: unstable
Urgency: low
Maintainer: Debian Games Team pkg-games-de...@lists.alioth.debian.org
Changed-By: Jon Dowland j...@debian.org
Description:
freedm - multiplayer-oriented maps for Doom
freedoom - free game files for the 3D game DOOM
Closes: 691399
Changes:
freedoom (0.8~beta1-1) unstable; urgency=low
.
[ Fabian Greffrath ]
* Add myself to Uploaders.
* Imported Upstream version 0.8~beta1. Closes: #691399.
* Do not install empty usr/share/games/{doom,freedoom} directories.
* Mangle the upstream version in debian/watch,
they use minus instead of tilde to indicate beta versions.
* Convert to 3.0 (quilt) source format.
* Convert debian/rules to dh7 style, bump debhelper compat to 9,
simplify things a bit.
* Change versioned Conflicts to Breaks.
* Run wrap-and-sort -asb.
* Compress binary packages with xz.
.
[ Jon Dowland ]
* Initial parallel build support (much more work needed)
* Bump standards version. Changes:
* fold Build-Depends-Indep into Build-Depends (not needed for
Architecture: all)
Checksums-Sha1:
93254a7e772b29675e28bd731cd57acfffdef73c 2067 freedoom_0.8~beta1-1.dsc
b2ce09b4bfe8df3c99979138e2ecb6f146324d72 15830881
freedoom_0.8~beta1.orig.tar.gz
5a201d73ce3764a2aa3564b1e61a9a5ab1ece782 6053
freedoom_0.8~beta1-1.debian.tar.gz
d565dc227bb8c982b076d625e0ac908389842391 4320408 freedm_0.8~beta1-1_all.deb
c711668336a72746eb40eb501b564ef3f14f0481 6860110 freedoom_0.8~beta1-1_all.deb
Checksums-Sha256:
1c017a4192765c9a22fea37392b72533d61fda4bfae32b0f022a1e6a035cf728 2067
freedoom_0.8~beta1-1.dsc
b901ecafd1fd7bfeca443f87db6f695077002ee51df22afe7bcd50a64eef4faf 15830881
freedoom_0.8~beta1.orig.tar.gz
c3990e8bc3fc7a553458d6dd408082d783693c622d9755d81420d8a9f878990b 6053
freedoom_0.8~beta1-1.debian.tar.gz
51bc88fa657706d3a0e2417ace4bbff9976b2233ef6061b70e5bbde378dcdcc1 4320408
freedm_0.8~beta1-1_all.deb
91295f336d4828720010615a0bc267457211e45434f5b99d8535ff736337668b 6860110
freedoom_0.8~beta1-1_all.deb
Files:
d735f304d569fa0d146b73c90c5a061d 2067 games optional freedoom_0.8~beta1-1.dsc
e567dfbbcdb5b07a6247c73829e1bf0d 15830881 games optional
freedoom_0.8~beta1.orig.tar.gz
79095fae6778fb2bc328bfd668104234 6053 games optional
freedoom_0.8~beta1-1.debian.tar.gz
44fbfd4a250a3cca65dcbc73670e272d 4320408 games optional
freedm_0.8~beta1-1_all.deb
bf90c3ab0673c857757e72df30862f02 6860110 games optional
freedoom_0.8~beta1-1_all.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBCAAGBQJQioz7AAoJEAkHQJYGF7AP/3i9R24ysJymGXG+c0OFH6Q3
TZKYMZZGnRhrIsez5uW4pCEXR5W9r9b0O89qJQ+w6gEIaq0+xBAtzyavd9xB6yG9
x/+Z2LQw63qAwIKr7PPBAeww9pYZHQ1v9iD/zeEyQPdzmoSEHQR16fg4L1A9pu8h
19gnpfTsvIFI4Gn+IYvP/j1z4Al4MPxudJxe23PN/72OSDP9QWAqiLR/DsAZYtMC
D5OFO86p0wUgRly6KX2q4HuW88eclr4kgmza/yFv1RYdocz9KK4hbkjYDbYSto4+
02+31VsGQ2IOLT4S9WvMb6Wi7qDQo+6dsaC93nWMuSh9790eApVheaA9ygF+AjX/
yoysgtK/T1s+2LYNC/256ICUkCVeYfHO1qkxC9ELi9/UupRCPFrUsSMNvrUXj6N3
jrjGZoE1B+cLM92q2lAJM/7O3DE618ESo9lfv01Kta+PtlzzaQky0K4s1EZ8f/Ww
gxaRuufBHCDOZBYVs0o5dt/hS3S5LuDafPap06ivzS/ateZpPYkIhtY3epMZmOLu
lbuBfj1AOUvtHX/mRZ9dA+UINBfJppVaEANe7IxFJnY2jM8rciW6HUy0Ckk4kejd
H7COQHcfzNh0lca4iJw/psz7Zpe1ecffT9Y5TKuUAFvesOJ1c7RjO96cgkBFUs53
G/a5A6IzbpjxpSmwI33Z
=BoAN
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1trk1l-0005df...@franck.debian.org
Accepted deutex 4.4.902-14 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 22 Oct 2012 16:09:33 +0100 Source: deutex Binary: deutex Architecture: source amd64 Version: 4.4.902-14 Distribution: unstable Urgency: low Maintainer: Debian Games Team pkg-games-de...@lists.alioth.debian.org Changed-By: Jon Dowland j...@debian.org Description: deutex - composition tool for doom-style WAD files Closes: 691152 Changes: deutex (4.4.902-14) unstable; urgency=low . * Recognise freedoom.wad as an IWAD. Thanks Fabian Greffrath. Closes: #691152. Checksums-Sha1: cea7dfc8d9f355c68ddc3a6018c356ac2aa4f217 1875 deutex_4.4.902-14.dsc 160cc6632497b90dcfd3756acfe80871237e72cc 5114 deutex_4.4.902-14.diff.gz 88e7aba995460a01bc6081e57f8424cb46a80c33 192870 deutex_4.4.902-14_amd64.deb Checksums-Sha256: a549efd15dc2bc5e6ef36d4f90d4bd39c1fdc975e5f0c9f24a3217c2ec996822 1875 deutex_4.4.902-14.dsc 80f9b1f4e3b33f918671d99568100c8fd79c238289b00c0c09c49f645adb8300 5114 deutex_4.4.902-14.diff.gz 6aabae8cb015f1a78c281ec6f3bf87db36f7b7237fd12d3427aa7bd1f761b2d7 192870 deutex_4.4.902-14_amd64.deb Files: 357df5d9a919957fe5e77ac455b168f1 1875 games optional deutex_4.4.902-14.dsc d42992edcc1d9c2a33faf91c3e72d5a2 5114 games optional deutex_4.4.902-14.diff.gz 2204c743b3bf2464bf5c3166e9f927b5 192870 games optional deutex_4.4.902-14_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQhvOMAAoJEAkHQJYGh9wP/iz9Q5Bw3aMAx4BQ1VzKYo01 U+XSJZnUA4Xhg27oW9lPUQmwoJDz5wtdhkHIKxGFu6limkXLhuKX5ktgQ8Tvdy3D 4AxXMbHtqnLKTGLBBAwF14d2rRbWNJX+RQY+NOerY2iPw+asQtqYX2V88KFZF4j0 2L7BBwLUJBL2ZP0WHnlq+hTqJMuxufv4lgY2yRep9ZsUoDxNDGxDvUQeisp0YpC2 l8fYR7HVbyqXfhZGtVzBwFphyuflplYFsxDIbVzfXY7U1qmZMwCz8Tq6CAe6X7L/ xYQD04lkQyERJs+t4/CeeCwtovwjwN8Hdv+fLrHzn609C0FmqHI0AxWlhwRbPxsy y69Qr5FbqxIRtyathfKa9RWfnCrHXic36P5rrIAMsqW4cpR5cwHSRhv+2JOCScpo X2ANRaqmoxDthYKXCqM11ohg7q6NYaiyPzIwCp6kbkPY55TizQquyupvZaQZDE97 JoZAY/TDWPUh1gS78mbUoP0zG/SmGrlqc7FTgNRFdrwdRNJsPADCrpIfzRVs0AJV C5JWHWYaThDj/MYnLtjBImLP3xJBMVEqP2yXSnL2VDEyn4WALzIvFjcFYG2hAFFF d8DEmsdovDRtJisSVokmfqyR4X+XXEtctzHaHWps7gbbTvlqJBVN061COqDLnjgq rERFXF9vSIzEKlYvqASF =n76T -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1tqkrj-00025t...@franck.debian.org
Re: (seemingly) declinging bug report numbers
On Fri, Oct 19, 2012 at 02:53:43AM +0200, Christoph Anton Mitterer wrote: Then again,... I wonder why Ubuntu exists, if they allegedly anyway want their changes into Debian. And still sounds like a fork in a respect that forks usually don't change everything. But I mean that discussion doesn't help... the question in the end will rather be, is Ubuntu becoming a thread to Debian (which it easily can by being more of a hype, by having commerical background, by focusing pretty much on what's cool like tablets and so on)... IMHO there are at least some sings for this. Such things have been endlessly discussed ever since Ubuntu was first released, eight years ago. I agree with you that discussion doesn't help here :) -- 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/20121022215811.GA13518@debian
Re: Report from the BSP in Alcester, GB
Great work, thanks all! Did you usertag any of the bugs you closed in that party? It would be kind-of interesting to see them. Does anyone else think that might be useful (either now or in future?) I suppose I could just scan debian-bugs-dist for the time period. -- 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/20121016155155.GC30695@debian
Re: Popularity of bzr-builddeb and dh-make
On Fri, Oct 12, 2012 at 04:03:53PM +1100, Craig Small wrote: Steve with his years of packaging experience is not probably a good sample of one to base this upon. I'd be curious to see if newer packagers use it or not. I don't bother with dh-make anymore. Like Steve the (mixed-case! Argh!) .ex (.EX) files just get on my nerves. A dh7+ rules file I can type from memory now and that just leaves the minor convenience of having the control file stanzas written out. -- 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/20121012083903.GB24924@debian
Re: Out of Date Package and Maintainer Absence
On Wed, Oct 03, 2012 at 10:27:22PM -0700, Vincent W. Chen wrote: I am willing to co-maintain the package with Manoj, or even maintain it by myself if he's no longer interested in dealing with it. But since there has been no reply from him I now turn to the list: any suggestion on what I should do now, or what I should have done? You should start preparing a newer version of the package, making as few changes to the packaging decisions made by Manoj (e.g. stick with pre-dh debhelper if that's what he's using; don't introduce cdbs or other packaging helper tools if they aren't already in use; stick to the VCS he's using, etc.) and putting your WIP somewhere public, both as a repo that can be cloned and attach a patch to the bug. Tag the bug 'patch', too. That way, we are talking in concrete, not abstract terms. Debian is a 'do-ocracy'. As for getting it into wheezy: I don't think odds are particularly high, but the release team will need to see a newer version of the package in order to decide whether to grant a freeze exception or not. -- 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/20121004065306.GA25088@debian
Re: Out of Date Package and Maintainer Absence
On Thu, Oct 04, 2012 at 09:54:05AM +0200, Arno Töll wrote: It is very unlikely they would unblock a package with major changes such as a new upstream version. Not to say Vincent should not work on it, but it won't be in time for Wheezy. Yes, agreed. There is the small-print reason that the existing version is long unsupported by upstream, but it would be the release team's call, and I agree that it is vanishingly unlikely. The work is worthwhile either way. -- 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/20121004095749.GA28116@debian
Re: Comments+blank line in debian/control: Clarification in policy or MBF?
On Mon, Oct 01, 2012 at 02:25:36PM +0100, Michael Tautschnig wrote: - the problem affects all packages *build-depending* on gnome-pkg-tools, thus I'd actually have to do an MBF (it's more than 160 packages) It would be worth looking at a) whether those 160 packages have a common maintainer, e.g. the Debian GNOME team, and b) whether those 160 packages have a VCS in common. It might be something that can be simply fixed with a single commit, in which case the beaurocracy of 160 bugs filed and then closed again would not be worth it IMHO. -- 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/20121001152555.GA21752@debian
Accepted game-data-packager 32 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 26 Sep 2012 22:04:45 +0100 Source: game-data-packager Binary: game-data-packager Architecture: source all Version: 32 Distribution: experimental Urgency: low Maintainer: Debian Games Team pkg-games-de...@lists.alioth.debian.org Changed-By: Jon Dowland j...@debian.org Description: game-data-packager - Installer for game data files Changes: game-data-packager (32) experimental; urgency=low . * hexen2: don't install strings.txt, progs.dat or progs2.dat; they're carried by the uhexen2 package. Thanks Gustavo Panizzo. Checksums-Sha1: cebe289f289e629b2b6f5f54754ead50082b41f4 1796 game-data-packager_32.dsc 950fc6057d49d431e5fbe83440073cf3444d70b4 34601 game-data-packager_32.tar.gz 247a0585b3b2b5e4bd281b874a521330c7f40e23 127890 game-data-packager_32_all.deb Checksums-Sha256: e1c3d02e5186f2403bf2288ded071b7ce858669052d30b2653c2def59c048371 1796 game-data-packager_32.dsc ff206ad895b738bc4309347c12999273ca58953ed5f15f5d1002cca6f065a162 34601 game-data-packager_32.tar.gz 10923c1601958d184272dc2a906443e2390779a28573fedc8adeddeb2081c557 127890 game-data-packager_32_all.deb Files: f057e7076ea7e1f638772826f1f7a0b7 1796 contrib/games optional game-data-packager_32.dsc e3b5f4a09e8db1a05d534b1c508df4d7 34601 contrib/games optional game-data-packager_32.tar.gz 6fc2167f8556e431afa24504225fe163 127890 contrib/games optional game-data-packager_32_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQY28xAAoJEAkHQJYGfbQP/RuzTGp2nSgXZjRB7EaEbV+D 0K0YJjFOHFAmSu3FCyBY/TgVD0MlZZWVqGM8NlW/Axz6pVBNsz/o4IwKyMfdF2Hz 1AD/+5HQw2dVO3hqzYBcnRXZyw5rbYysUyd/dbTpZvHqwy1oCyG5cQE2W13adO9H Fgoo8oaYeOeieGWDoywiijeVog0QbE3dOtnO2ejLsQJgQV8FVtlk2gqMCq2bNJ98 hR++myYZNGN5AKGrcmOWJM7sIF90vilwf5IWCyJUWWX3QbdB/OgrLaA53kPgvrx/ /P4ql6c34kFU1sRGHBRq4bvk3xYRmgiEeXLbsyI4OTy8j/Zt/0TOlEMKoSDuaI7C XyvULlwQWVvLbs2XtfZcuGLY29QXyNJPoUdJndqRWzLfcDb/vU+vpeUURZwRJRZr ue0g+IzU81Nzf1i8VrTpbgl4UkWHJKEXhvQtgS/ytpkKmPwuls8OnRR87BDK1qBn Z/QjqS2ipoDQhD/0m3YFc6oCxC5QVn4G70GNIwOm1FUg497RedzryFWzVyolWY4X eySHDwV4oMkBPJR+rYaChihqH6ciUAixfar4Ho8UmXmW8/iTE1t2wo3vDMRDiPzl 4ieEk6CsZCX3TBkggisoHVZBuVAmME6gV2WLP/lp+nRE3jcbf5k1LyZJousAHY6w AL+8VPYJtDRCBl3VjxQg =Fhmn -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1tgzda-0005yl...@franck.debian.org
Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
On Mon, Sep 24, 2012 at 11:08:31AM +1200, Chris Bannister wrote:
If it pulls in half of GNOME when you install it, its nice to have the
name gnome in there somewhere.
Well I disagree, but either way, it doesn't¹:
Depends: ${misc:Depends},
${python:Depends},
gir1.2-champlain-0.12,
gir1.2-gtkchamplain-0.12,
gir1.2-gtk-3.0,
gir1.2-glib-2.0,
gir1.2-clutter-1.0,
gir1.2-gdkpixbuf-2.0,
python-lxml,
gir1.2-gtkclutter-1.0
I don't see 'libgnome' anywhere.
¹ http://bazaar.launchpad.net/~sigurdga/maps/master/view/head:/debian/control
--
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/20120924093233.GA4417@debian
Re: Comments on Mate DE
That's not really of any interest to -devel, and I guess you're quoting info from private mail here. Please let's keep this list useful. -- 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/20120921144100.GC1374@debian
Re: Comments on Mate DE
Hello, Thank you for your mail. The reason MATE is not in Debian is that nobody has put the work in to make it so. In Debian, things happen thanks to developers putting effort in, usually in their spare time. Whilst it's true that some people believe MATE should not be included in Debian, they do so for technical reasons, not religious ones - and they won't prevent it being included so long as people are prepared to put the work in. Some people have started to put the work in - see http://bugs.debian.org/658783. However the timing is such that it will not be included in the next Debian stable release. It might make the one after that… -- 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/20120920104927.GA17882@debian
Re: status of eligibility of dug lists on lists.debian.org
Personally, I think l.d.o would be an appropriate home for such things, but I believe the decision is one for the list server admins. Having said that, I think efforts are underway so that the alioth-hosted lists are moved to the l.d.o infrastructure, precicely because it is recognised that running multiple list servers across the Debian community is counter-productive. IMHO the same reasoning applies here, but it is for the list admins to say authoratively. -- 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/20120920105112.GB17882@debian
Re: Bug#688066: ITP: rex -- What do you want to deploy today?
On Tue, Sep 18, 2012 at 10:52:29PM +0200, Mike Gabriel wrote: Description : What do you want to deploy today? A better short description is needed here. In a nutshell, what does it do? -- 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/20120919075255.GA2663@debian
Re: CD1 without a network mirror isn't sufficient to install a full desktop environment
On Tue, Sep 18, 2012 at 09:08:23PM +0200, Wouter Verhelst wrote: I'm so tired of these gnome2 vs gnome3 discussions... Stop proliferating them then! They are orthogonal to the point of this thread, and you will never shout down all the people who disagree with your point of view. -- 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/20120919075442.GB2663@debian
Re: CD1 without a network mirror isn't sufficient to install a full desktop environment
On Tue, Sep 18, 2012 at 12:45:36PM +0300, Serge wrote: There's no need to walk through the minefield, it's already done. Fedora lost more than half of the user base with the Fedora 15 release (GNOME3 and systemd). [citation-needed] They now bring GNOME2 back. [1] :) [1] https://fedoraproject.org/wiki/Features/MATE-Desktop MATE is not GNOME2, it's a fork of GNOME2, and there's no indication that they are planning to offer it as default, which is what we're discussing here. -- 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/20120918130657.GA16659@debian
Re: Creating and use Virtual IP Interfaces
On Tue, Sep 18, 2012 at 09:33:41AM +, Pietro Paolini wrote: I am not really sure this is the correct newsletter for my question, if not please apologize me and suggest me a right newsletter, thanks. It isn't - please try debian-user: https://lists.debian.org/debian-user/ -- 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/20120918131350.GB16659@debian
Re: Bug#687624: ITP: libdvdcss-pkg -- automated installer for libdvdcss
On Fri, Sep 14, 2012 at 01:26:19PM +0100, Simon McVittie wrote: game-data-packager, although that one is a bit different: it supports a relatively large number of game-data packages, and most of the data it works on is not freely downloadable, so it often has to support building the same package from various different releases (American vs. European publisher, original version vs. budget re-release, etc.) in order to support the particular disk/CD/DVD that a user owns. Indeed - I had envisaged game-data-packager growing into 'data-packager' at some point. The design was initially inspired by java-package, which IMHO was a better solution than run-as-root postinst (the flash installer method, and the one OP is proposing in this ITP). java-package since disappeared, as the sun java's could be packaged; that situation has sadly regressed so perhaps there's call for java support in (game-)data-packager once again. In this case, however, it seems as easy to install libdvdcss from debian-multimedia than to have hacks to build it from source. The hacky package would have to live in contrib anyway, so it's still not in Debian. -- 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/20120914154511.GB3124@debian
Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
On Mon, Sep 10, 2012 at 12:03:33PM +0200, Jean-Christophe Dubacq wrote: Let's acknowledge that the gnome-* prefix means to be used mostly in the GNOME Desktop environment and not officially endorsed by GNOME. Or something like that. We need to distinguish between what the situation is now, and what we think the situation should be. I believe 'gnome' should only be used by things which are part of the GNOME project, but I haven't done any researhc into how widespread the problem is, nor have I discussed it with the GNOME team, nor have I proposed it as a release goal for wheezy+1. Perhaps I (or we, or someone) should start this work before compounding the problem. -- 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/20120912124731.GA26534@debian
Re: CD1 without a network mirror isn't sufficient to install a full desktop environment
On Tue, Sep 11, 2012 at 01:06:22PM +0100, Ian Jackson wrote: I have encountered numerous people who have been complained (not in particular to me, just i general) about changes to GNOME. Not being a GNOME user myself I don't really appreciate these complaints. However, I have observed that these complainants have generally been told by their peers to switch to xfce and been broadly satisfied with the results. I haven't seen anyone in my social circles praise these changes as good for them. Based on this, I think there is at the very least no reason to reverse the decision to switch the Debian default to xfce. There is not a single Debian release with the version that is being complained about. Therefore the audience of stable have not yet tried it, and you're drawing conclusions from the anecdotes of a sample of users who may not be representative of our (stable) users. I feel that the decision to change from GNOME to something else, on the basis of complaints about GNOME 3, should only be considered after we've actually released with at least one version of GNOME 3. -- 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/20120911131116.GA31130@debian
Accepted game-data-packager 31 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 11 Sep 2012 22:00:44 +0100 Source: game-data-packager Binary: game-data-packager Architecture: source all Version: 31 Distribution: experimental Urgency: low Maintainer: Debian Games Team pkg-games-de...@lists.alioth.debian.org Changed-By: Jon Dowland j...@debian.org Description: game-data-packager - Installer for game data files Changes: game-data-packager (31) experimental; urgency=low . * Initial Hexen 2 support. * An initial regression test suite in the source. * Fixup 'slipstream' and adjust callers in Doom, Quake and Quake 3. * Some Quake tweaks to make e.g. building a 1.01 package from a directory or a 1.06 shareware package possible. * Re-Add myself to uploaders. * Bump standards version. Checksums-Sha1: 4190763fc746641bbc10dd3ce8f270fea4790c62 1796 game-data-packager_31.dsc 41bee90414d56118abc920449e558887fac0c4c9 34553 game-data-packager_31.tar.gz cd38425aa5044522ee96825e2b8417cd1b00fcd2 123560 game-data-packager_31_all.deb Checksums-Sha256: 63f3578147673d91cb5ec9c9421fababa156cb2799680c252a215d97c3097e45 1796 game-data-packager_31.dsc 4a1debeff585a36b65b2cddbddf909c1776de76a9c15ab6d40afa8d890d9c464 34553 game-data-packager_31.tar.gz 234510d6592bf47332e304c3e4914493ca83bafef0f72af55cccda809eff3fc5 123560 game-data-packager_31_all.deb Files: 5b522da7e9b2ea68bde3435e54f36568 1796 contrib/games optional game-data-packager_31.dsc 1467fe81ba286b20c05b7a470e22aa14 34553 contrib/games optional game-data-packager_31.tar.gz 784952a9a3c85e222b8c643e9111ca97 123560 contrib/games optional game-data-packager_31_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQT6gvAAoJEAkHQJYG9I8P/3S0mc453xrE1UQu4dMUzLXs qooCV/QrPEI3PDdxnTZaPquHkCBw8W34mQNaEUrzYtKpgQZnAeUDSY6UgV336WEz 2nucwjbq+n136pB47qns36ITMCbc0oX/nEM2tld0nLJxIZhbcQBeAMbwuV0o4txO 8p56kDpfzrdMeLzLHRxb2pyRuJUB329KcxoRcyVAE0zOD98OF3y5EmZyoK+8bNdm urFy3xWFK9Dxo2y4dPW8G9KxETBLXxMPPhW7KK66+bMZPcouHShEZdSAABgtlbr2 t5+v0OyJjAlJAaJWsmtxUKpbTNSRd41LqKZ+/nmzgykYMwlkLVOrZ5iVmMGJYr5d GktOQfrxhXm1dUdOC9k8O+EtH/wgE7O5fNAoOYsQgY5f/zuxDWciCoySpC0hgJgP 8oRAkpDSTQQpKkNvzQynvjDcl3qgbkiz+Q4zgyXnQlAXxluqgc8Z3JuzFeFw8JMv WeNlY40L+QCAtA51j1viuTBdnHNeLQDVFfSTijqrw//ZqRVngSXJ2/OsbUkFoaCK awzb5NIz3zN93/D65dOfp+TJ/P1QPAFl5AEnVHhatVRj4ko5uexmItDB6aNdH91S 9Z1cSTOKzpf0VbS3hSfeYUaUONOAdK3IORijVLpMzJz5L5POw1avON5YSbKuO3OJ pJV+MeAlHsotODfFObNC =mjtF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1tbxq2-0007sv...@franck.debian.org
Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
On Sun, Sep 09, 2012 at 10:42:35PM +0200, Alessio Treglia wrote: OK, so let's go on picking 'gnome-osm-maps'. Thank you all folks! No, one package in the archive with a misleading name doesn't mean we should have more! See also: gnuplot, not related to GNU, and no doubt many more. -- 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/20120910092648.GA26700@debian
Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
On Mon, Sep 10, 2012 at 06:45:42AM +0200, martin f krafft wrote: also sprach Luca Capello l...@pca.it [2012.09.09.2029 +0200]: Or, if this is tightened to OSM, 'gnome-osm-maps'. except the 'm' on osm is already a map, so maybe osm-client. I like dropping 'gnome', and not doubling-up map, but osm may not be clear enough to those who aren't intimately involved, how about openstreetmap-client? -- 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/20120910092816.GB26700@debian
Re: Bug#687001: ITP: optional-dev -- fake (empty) dev package
On Sat, Sep 08, 2012 at 10:01:17PM +1000, Dmitry Smirnov wrote: When building for as many architectures as we have, situation when some dependencies are missing (or can't exist) on some architectures is not rare. However we still want to build our packages with all features possible. You should have two (or more) binary targets, each of which excludes the architecture(s) that do not support the particular feature. E.g. if baz is not available on hurd: Package: foo Architecture: any !hurd Build-Depends: bar libbaz-dev (I forget the precise syntax for excluding an arch here) and Package: foo-hurd Build-Depends: bar Architecture: hurd Or possibly in some circumstances Package: foo-minimal Build-Depends: bar Architecture: any …where foo without baz might be useful for someone on any architecture. Explain the differences clearly in the package long description. -- 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/20120910124617.GF26700@debian
Re: Enabling uscan to simply remove files from upstream source
On Sat, Aug 25, 2012 at 05:18:57PM +0900, Charles Plessy wrote: I also considered, but the information of what files are excluded when creating the Debian source package is not relevant to upstream. More simply, I think that if debian/watch would radically change its format to YAML or the Debian control data file syntax, it would be a good place for the Files-Excluded field. The copyright file is, as the name suggests, for copyright information. The watch file is, as the name suggests, for watching for upstream releases. Can we please just have a new file for a new purpose, rather than overloading ones that are succinct, single-purpose and consistent? We can then pick a syntax that fits the problem, rathen than trying to bend and contort one that doesn't. -- 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/20120907125431.GC4705@debian
Re: Bug#686903: RFP: pass -- the standard unix password manager
On Fri, Sep 07, 2012 at 04:11:25AM +0200, Jason A. Donenfeld wrote: Subject: Re: Bug#686903: RFP: pass -- the standard unix password manager I realise this text comes from upstream, but the standard unix password manager is IMHO misleading for this program. A unix password manager is more accurate. UNIX seems superfluous though, perhaps A password manager, or something that describes the program, such as A command-line password manager. -- 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/20120907125744.GD4705@debian
Re: Discussion of uscan enhancement 1 (Was: uscan enhancement take 3: script hook)
On Wed, Sep 05, 2012 at 09:04:19AM +0900, Charles Plessy wrote: the machine-readable format does not mention trailing slashes at the end of directory names, and refers to the -path test of the GNU find command, Good. Having a trailing-slash be meaningful is very confusing. I especially hate this with rsync, where I now use trailing-slash on dirs exclusively, since I've memorized the behaviour when you do this and not when you don't. It frustrates me because foo and foo/ might differ but they are both names for the same thing - and the behaviour should not differ if the name for the same thing differs IMHO. which will fail with trailing slashes. I can understand why it would fail, since the argument to path is a pattern rather than a filename, and it is compared against find's list of paths which just so happen not to have trailing slashes. Having said that I wonder if this behaviour could be considered buggy. -- 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/20120905105227.GA31962@debian
Re: Minified javascript files
On Sat, Aug 25, 2012 at 12:27:02PM +0200, Jonas Smedegaard wrote: 1) We have the source for the parts that we ship in binary packages, yes. We do not, however, necessarily have the actual source for the minified files unused for binary packages yet redistributed by us in source tarballs: Just as with autotools files we generally do not verify that these files has same source as the source we instead use for our binary packages. That's true; however, it's a source of *potential* bugs, rather than definitely a bug in every such package, which is an improvement on the view that they violate the DFSG, where that would be the case. -- 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/20120904194043.GA15040@debian
Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
On Fri, Aug 31, 2012 at 10:57:10PM +0800, Thomas Goirand wrote: On 08/31/2012 06:55 PM, Riku Voipio wrote: How is that different from having a botched / or /boot ? Why do you think having a separate /usr will make / less prone to HD crashes? You have / on RAID5 while /usr isn't? Typically, I have / on 2 small RAID1 partitions making the array on the first 2 HDD (1 or 2 gigs), and /usr on a LVM on a much, much larger RAID array (I use mostly software RAID1 and RAID10, but in some cases, much bigger hardware RAID5). So yes, that's my usual server setup. Also, / is a partition on which almost nothing is read or written, while the others (eg: /usr, /var, /tmp, swap) are a lot more I/O intensive. Which means that / is less prone to failure. Often, the 2nd RAID array gets degraded, but / isn't. So it does make a lot of sense to setup things this way, and yes, / is less prone to HD crashes this way (I'm talking from 10 years of experience running about 100 servers this way, so it's not just theory, it's very practical experience). I'm struggling to understand this. In the situation you outline (/ ok, /usr, /var, /tmp, swap on another RAID which is hosed) -- whatever service the machine was offering is surely not being offered anymore (/ being too small to be useful for anything except a rescue environment). So / surviving whilst all your services/data are dead doesn't seem to be a big win to me at all. Am I missing a detail? -- 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/20120831150447.GD24379@debian
Re: [proposal] use xz compression for Debian package by default
On Wed, Aug 29, 2012 at 05:12:15PM +0200, Didier 'OdyX' Raboud wrote: We are building a binary distribution which main characteristic is to have the packages built _rarely_. As such, a useful but CPU-expensive operation is always worth it. The situation is slightly different for Debian-native packages. In that case, there's little value in not replacing the source PNGs with better-compressed alternatives. (games-thumbnails is such a native package.) And if the package building infrastructure comes in your way by enforcing unneeded repeated builds, then the problem resides in the package building infrastructure. Are we not required to provide a functional 'clean' target in our rules files? Should these not remove files that were generated as part of the build process? -- 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/20120830124633.GA23881@debian
Re: [proposal] use xz compression for Debian package by default
On Tue, Aug 28, 2012 at 12:56:47PM +0200, Vincent Lefevre wrote: Before wondering whether PNG files should have an additional compression level, is there any reason why a better PNG compression isn't used in the first place? For instance, optipng -o9 tries various parameters and keeps the best one. So recompress upstream PNGs and suffix +dfsg to the source version? There might be some disadvantages to this. If you are using VCS to manage the package, you are probably carrying the upstream PNGs in that already, so there's an appreciable increase in repository size to carry the optimized PNGs too. Another approach could be to inject optipng into the build process and treat the outputs like compiler output (packed into binary packages, thrown away on clean), but then repeated builds could be CPU-expensive. Perhaps getting upstream to carry better-compressed PNGs in their next release is a good idea. -- 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/20120829140143.GA22300@debian
Re: [proposal] use xz compression for Debian package by default
On Wed, Aug 29, 2012 at 03:17:15PM +0100, Dmitrijs Ledkovs wrote: I don't think it's worth +dfsg, and CPU cycles will only be wasted once on the maintainer side, since most of PNGs are in arch:all packages anyway. I used to hack on the games-thumbnails package a bit, which ran optipng as part of the build stage and removed the results as part of the clean stage.¹ It used to be quite a pain to run 'debuild' over and over, if you were making small, iterative packaging changes, because the 'clean' target would be run. I suppose I could have simply ran the build stage by hand repeatedly instead. ¹ It would appear that the package no longer does the remove stage, from a cursory glance at the rules file these days. This is no doubt a pragmatic decision, but one that might conflict with people's build expectations.) -- 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/20120829144701.GB22300@debian
Re: Enabling uscan to simply remove files from upstream source
On Thu, Aug 23, 2012 at 12:38:14PM -0500, Peter Samuelson wrote: ...Or add the exclude list to a file called 'debian/watch'. I struggle to see why. I suppose because uscan reads debian/watch, but the point of that file is to document where to find upstream sources, the name implies that, and putting lists of files to strip into it would seem counter-intuitive to me. -- 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/20120824083627.GA19780@debian
Re: Possible release note for systems running PHP through CGI.
On Mon, Aug 20, 2012 at 12:58:42AM +0200, Christoph Anton Mitterer wrote: But if anyone would lobby that (release goal: default to CGI/FCGI), they'd have definitely my support :) A bit late for wheezy, do you mean for +1? -- 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/20120820130646.GA28685@debian
Re: Bug#685064: ITP: non-daw -- please package non-things
On Thu, Aug 16, 2012 at 11:19:23AM +0200, rosea grammostolla wrote: Subject: Re: Bug#685064: ITP: non-daw -- please package non-things ^ You've filed an ITP (I Intent To Package) but your subject reads more like a Request For someone else to Package (RFP). Can you clarify which you meant? * Package name: non-daw … The Non DAW… The Non Mixer… The Non Sequencer… The Non Session Manager… The package name suggests you are packaging the DAW but the description covers the other three things too and suggests to some extent that they are separate. Would the mixer, sequencer and session manager be provided in the same package, or in separate packages? -- 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/20120817082430.GA17970@debian
Re: Change default PATH for Jessie / wheezy+1
On Wed, Aug 08, 2012 at 04:41:35AM +0200, Ulrich Dangel wrote: On 08/08/12 04:11, Marco d'Itri wrote: Fedora did it a few months ago, so probably we should do it as well to minimize the pain. As far as I know (based on https://bugzilla.redhat.com/show_bug.cgi?id=458176 / http://fedoraproject.org/wiki/Features/SbinSanity ) Fedora changed it in 2008. It seems that Ubuntu also has the sbin directories in PATH per default (via /etc/environment) since at least 2006. In which case any pain we were likely to suffer has been suffered already, so that's one fewer reason to make the change. -- 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/20120817082705.GB17970@debian
Re: Change default PATH for Jessie / wheezy+1
On Wed, Aug 08, 2012 at 12:40:42PM +0100, Roger Leigh wrote: Warning the user that they are using an obsolete tool is IMO entirely justified, particularly when there is a much better and more capable replacement. And there's plenty of precedent: $ ffmpeg ffmpeg version 0.8.3-6:0.8.3-4, Copyright (c) 2000-2012 the Libav developers built on Jun 26 2012 09:26:41 with gcc 4.7.1 *** THIS PROGRAM IS DEPRECATED *** This program is only provided for compatibility and will be removed in a future release. Please use avconv instead. (even if the above is somewhat misleading) And the wodim/cdrecord messages. -- 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/20120817083717.GC17970@debian
Re: Bug#685042: ITP: libpam-ssh -- Authenticate using SSH keys
It would be nice if your initial upload would resolve the multiple issues that were the cause for the package removal, rather than simply reintroduce them. -- 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/20120816083916.GA8134@debian
Re: node-like file conflicts
On Tue, Aug 07, 2012 at 01:00:38PM +0100, Ian Jackson wrote: /usr/games is a swamp for another time I think. I guess it contains an awful lot of things with clashing names. Last I checked the latest FHS drafts removed /usr/games entirely, so the morass might end up being dumped into /usr/bin at some point in the near future, where they are promoted from $PATH conflicts to actual binary conflicts. -- 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/20120815131520.GA10037@debian
Re: Modified http://wiki.debian.org/DebianDeveloper to mention non-packagers (Re: [CTTE #614907] Resolution of node/nodejs conflict)
On Thu, Jul 26, 2012 at 01:55:06PM +0100, Ian Jackson wrote:
Jon Dowland writes (Re: Modified http://wiki.debian.org/DebianDeveloper to
mention non-packagers (Re: [CTTE #614907] Resolution of node/nodejs
conflict)):
On Wed, Jul 25, 2012 at 12:15:15AM -0700, Russ Allbery wrote:
We are in the process of discussing a variety of constitutional amendments
to be raised by the tech-ctte that will hopefully end up creating a sort
of bundle of constitutional fixes to vote on. Perhaps it would be good to
include in that a terminology standardization on member for the places in
the constitution that we refer to voting project members rather than
specifically people who upload software.
Yes please!
I am not in favour of this change. The point about a Debian Developer
is that the basis of their claim to the rights and responsibilities
enumerated in the constitution, is that they help develop Debian.
I don't think the word Developer implies that one can't develop
Debian in other ways than by directly editing software.
The problem to solve is not that Developer implies a *limitation* of
responsibity for Developers; it's that non-packaging contributions are
not considered to carry the same value or esteem as traditional packaging.
I agree that 'developer' is a fine word to describe a valued contributor
to the project and does not — on its own — suggest packaging software,
but sadly the historical context does.
I'm not overly interested in the word developer being eradicated, but at
the very least having some consistency in Debian's documents would be
very welcome. ('New Maintainer' → route to 'Developer' vs. 'Debian
Maintainer' is another area of confusion). Perhaps an entirely new set
of nouns should be chosen, free of historical baggage?
--
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/20120726130545.GB14409@debian
