Re: libtiff borken - cannot build anymore?
On Tue, 21 May 2013, Ondřej Surý wrote: I did: $ grep tiff debian/control B-D: libtiff5-alt-dev | libtiff-dev, Note that sbuild only considers the first alternative, so libtiff-dev would be ignored for bin-nmu on official buildds. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20130522060717.gb12...@x230-buxy.home.ouaza.com
Re: Debian systemd survey
On 22/05/13 at 05:50 +0300, Uoti Urpala wrote: Lucas Nussbaum wrote: I went through the various init systems threads again during the last few days. My understanding of the consensus so far is the following: - Both systemd and upstart bring many useful features, and are a clear improvement over sysvinit. Yes, both are an improvement over sysvinit. It is not clear which one of systemd or upstart is the best on the technical level. Many of the differences have grounds in differences of philosophy, which can easily be seen as pros or cons. I think this is false, both as a description of fact and as a description of claimed consensus view. Systemd has advanced significantly further than upstart, and this is more a technical reality than a matter of opinion like something such as preferred GUI behavior; this is better compared to whether Linux or MINIX was a more promising platform for future development in the 1990s. There is a lack of consensus, rather than a consensus that it's a matter of opinion or philosophy with no clear technical arguments. We can argue for a long time about which one is technically better. The result of that discussion does not matter much (since you are invoking Linux vs MINIX, look at Hurd vs Linux). If I were you, I would be very worried about the risk that the decision will be taken not by looking at which one is the best, but by looking at which one is de-facto supported in Debian. In that area, systemd is very late, since: - AFAIK nobody has started the effort to document things in policy - there are 300+ upstart job files ready to be imported from Ubuntu So, please work on: - policy support - outlining how systemd and sysvinit can properly co-exist in the archive (this is required in any case for the duration of the transition) - outlining how the transition could be achieved, eased, and tracked Lucas -- 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/20130522061634.ga25...@xanadu.blop.info
Re: Upstart kFreeBSD port for Debian
Hi Guillem, On Wed, May 22, 2013 at 04:09:33AM +0200, Guillem Jover wrote: On Wed, 2013-05-22 at 01:47:42 +0100, Dmitrijs Ledkovs wrote: On 22 May 2013 01:16, Michael Biebl bi...@debian.org wrote: Am 22.05.2013 02:00, schrieb Dmitrijs Ledkovs: On 21 May 2013 21:53, Lucas Nussbaum lu...@debian.org wrote: On 20/05/13 at 18:19 +0200, Michael Stapelberg wrote: - Neither systemd nor upstart are likely to be ported to kfreebsd soon, as they both rely on many Linux-specific features and interfaces. Well, Colin Watson, Matthias Klose, Steve Langasek, James Hunt and I have discussed the state of the kfreebsd possibility a few times over the past year or so. I started porting libnih and upstart to GNU/kFreeBSD some months ago, just for fun, whenever I had nothing else to do. But then I'm not interested in assigning my copyright to a for-profit company that is not employing me (and no, this is not a job request); so I didn't post anything yet, because I don't use upstart, didn't want to promise anything (still don't), and it would present as an _interesting_ situation for the Debian upstart maintainers (either reject the patches or carry them forever as a small fork...). This is interesting to know. Out of curiosity, if you don't intend to license your patch under the Canonical CLA, what was your aim in doing this port? I'm not sure where that puts us; we're certainly interested in seeing a BSD port of upstart, but obviously being unable to integrate that port upstream is less than ideal. By chance is there anyone else among the BSD porters who would be more willing to do do such a port under the CLA terms? Or do you think Scott's original suggestion to maintain the bsd port as a separate branch (which for Debian's purposes might imply a separate source package; or else a patch stack in the source package that needs forward-ported after each upstream release) is viable? Oh, FYI, libnih is not covered by the Canonical CLA; Canonical is not the sole copyright holder on it, and Scott, not Canonical, is the upstream maintainer. As mentioned on the porting guide above, waitid() should be replaceable with kqueue's EVFILT_PROC anyway. While it's good in a general sense to know that there are comparable facilities that upstart *could* be ported to on BSD, I don't see a port being successful without direct engagement from a BSD porter. Certainly, I don't see Canonical being the ones to drive this forward. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
On advocating NM applicants
Hi, In the past few days and weeks there have been many advocacies, for new applicants and for DM-DD applicants. Please take advantage of the NM web interface where possible, as it makes the process much more streamlined for us. If the applicant doesn't have a record there yet, please wait patiently until they (or front desk) say go! and then do that. Your message will be sent on to debian...@lists.debian.org on your behalf, and meanwhile we get all the information required in one place. To advocate someone through the web interface: 1. Log in to https://nm.debian.org/ 2. Use the People tab to find the applicant of interest [1] 3. Choose something appropriate from the links at the top right of the page. Advocate for DD is normally what you're after. 4. Enter your message and if you're the first, also choose if this is to be an uploading or non-uploading application. You can still email your advocacy to front desk or debian-nm, but it will be copied into here in any case. Thanks for your assistance! 1: you will end up somewhere like https://nm.debian.org/public/person/jmw/ For front desk: -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 signature.asc Description: Digital signature
Re: libtiff borken - cannot build anymore?
Hi Norbert, Le mercredi, 22 mai 2013 02.20:22, Norbert Preining a écrit : On Di, 21 Mai 2013, Thorsten Glaser wrote: resolved *correctly*, with*out* introducing further security issues and RC bugs. CAN YOU ALL STOP BITCHING AROUND ABOUT A NON-EXISTING ISSUE?!?!?!?!?! Could you please stop yelling at debian-devel readers in upper-case and with inflated punctuation? Thanks in advance. Really, the next time you want to communicate your frustration about something, avoid doing it on that mailing list; it really doesn't help getting your point understood (much to the contrary in my opinion). Cheers, OdyX -- 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/201305220855.41334.o...@debian.org
Re: Automated piuparts when entering the archive (Was: Debian development and release: always releasable (essay))
On 2013-05-22 03:53, Michael Gilbert wrote: I think the first step would be get get pages like [0] to include version numbers of the packages tested (and preferably links to test logs). This should be put into a wishlist bug against piuparts-master ... If that were in place, then a patch to britney could block testing migrations for those package versions failed their wheezy2jessie upgrade test (for example). special case to consider: wheezy - fail wheezy2jessie - fail sid - pass Such a package should be allowed to migrate, as it fixes an uninstallable package. And it should be possible for the RT to add overrides to ignore a (minor) piuparts failure. Andreas -- 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/519c71b7.7060...@debian.org
Re: Debian systemd survey
On 05/21/2013 10:53 PM, Lucas Nussbaum wrote: - Neither systemd nor upstart are likely to be ported to kfreebsd soon, as they both rely on many Linux-specific features and interfaces. What about launchd? Wouldn't it be possible to port that to Debian/kFreeBSD? It's designed to run in a BSD userland, after all. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/519c7077.5040...@physik.fu-berlin.de
Re: On advocating NM applicants
Jonathan Wiltshire (Front Desk nm at debian.org writes: 3. Choose something appropriate from the links at the top right of the page. Advocate for DD is normally what you're after. Can’t see that. (I tried a half dozen people just to confirm…) bye, //mirabilos -- 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/loom.20130522t095801-...@post.gmane.org
Re: Bug#709237: ITP: meta-suckless-tools -- meta-package installs simple commands for minimalistic window managers
]] Dmitry Papchenkoff Additionally, there was requests for packaging for xssstatus, which is (by upstream) a part of suckless-tools too, but (as for other suckless-tools) have separate tarball. For example, if xsstools will be included in main package, then «tools for minimalist window managers» will depend on xscreensaver even if they also includes dumb x locker. So, at least two or three of the tools already have reasons for making separate packages for them, that's not good — it's better then packages for one vendor organized in some common way. You don't need to depend if only a minor functionality of the package depends on some other package, a suggests is fine. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=119517 With 3.0 (quilt), you can have multiple upstream tarballs too. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87r4gzbg3s@qurzaw.varnish-software.com
Re: simplifying running piuparts
Hi Charles, On 2013-05-22 06:05, Charles Plessy wrote: it is not fully related to your original question, but do you think that piuparts could support running Autopkgtests as well ? Theoretically yes, but I haven't looked into DEP8 so far ... reading ... Quoting from the autopkgtest specification: The cwd of each test is guaranteed to be the root of the source package, which will have been unpacked but not built. HOWEVER note Since piuparts does not know about source packages, this may be a bit more difficult. But it looks like it could be rather easy to have an --autopkgtest option for pbuilder/sbuild as they already have the matching sources at hand. And it could be done together with the archive wide rebuilds done by Lucas. Andreas -- 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/519c7785.80...@debian.org
Re: libtiff borken - cannot build anymore?
JFTR I already realized that and the new libgd2 upload has only libtiff-dev as B-D and D. Ondrej On Wed, May 22, 2013 at 8:07 AM, Raphael Hertzog hert...@debian.org wrote: On Tue, 21 May 2013, Ondřej Surý wrote: I did: $ grep tiff debian/control B-D: libtiff5-alt-dev | libtiff-dev, Note that sbuild only considers the first alternative, so libtiff-dev would be ignored for bin-nmu on official buildds. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20130522060717.gb12...@x230-buxy.home.ouaza.com -- Ondřej Surý ond...@sury.org -- 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/CALjhHG83_xZ=sx1Fbi=�sqvcldcp9msomjwyvl-g6oncl...@mail.gmail.com
Re: libtiff borken - cannot build anymore?
Norbert Preining preining at logic.at writes: That to prevent is what package relationships are for! And? I did lots of test, but forgot that texlive-lang will be in the NEW queue, thus full upgrades will not work. Please anyone else, correct me if I’m wrong, but I see the following scenario: Teχ consists of packages “foo” and “bar”. Norbert says he uploaded both but “bar” sits in the NEW queue, which is why the upgraded “foo” will not work. To me, this looks as if “foo” needs a versioned Depends on “bar” *and* “bar” possibly needs a versioned Breaks against older “foo”. Or “foo” needs a versioned Breaks against older “bar” and possibly a(n unversioned) Depends/Recommends/Suggests against “bar”, depending on the scenario. Forgetting that things could sit in the NEW queue is no excuse, as partial upgrades are supported by Debian. Or did I understand the issue wrong? If so, you have my apologies, Norbert. bye, //mirabilos -- 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/loom.20130522t100543-...@post.gmane.org
Re: libtiff borken - cannot build anymore?
On Wed, May 22, 2013 at 10:09 AM, Thorsten Glaser t...@debian.org wrote: That to prevent is what package relationships are for! And? I did lots of test, but forgot that texlive-lang will be in the NEW queue, thus full upgrades will not work. Please anyone else, correct me if I’m wrong, but I see the following scenario: Do a full analysis of the problem and send a patch, please. Proposing and solving hypothetical problems on d-d doesn't help anybody or anything. O. -- Ondřej Surý ond...@sury.org -- 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/caljhhg8ztutknn+xzyk8_c3n4auqn-hpeumkqnxrwrtr1zp...@mail.gmail.com
Re: Debian systemd survey
John Paul Adrian Glaubitz glaubitz at physik.fu-berlin.de writes: On 05/21/2013 10:53 PM, Lucas Nussbaum wrote: - Neither systemd nor upstart are likely to be ported to kfreebsd soon, as they both rely on many Linux-specific features and interfaces. And this is one more reason to continue supporting sysvinit with file-rc and sysv-rc: having a unique system across kernels. What about launchd? Wouldn't it be possible to port that to Debian/kFreeBSD? It's designed to run in a BSD userland, after all. Debian GNU/kFreeBSD has GNU userland, not BSD userland. That’s why it’s named like that. bye, //mirabilos -- 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/loom.20130522t100014-...@post.gmane.org
Re: libtiff borken - cannot build anymore?
Hi, On Wed, 22 May 2013, Thorsten Glaser wrote: Teχ consists of packages “foo” and “bar”. Norbert says he uploaded both but “bar” sits in the NEW queue, which is why the upgraded “foo” will not work. To me, this looks as if “foo” needs a versioned Depends on “bar” *and* “bar” possibly needs a versioned Breaks against older “foo”. And this is the case. On my system, texlive-lang-* were not upgraded and all of tex has been kept back except libkpathsea6 which Norbert forgot (and this resulted in the breakage). But that has been quickly fixed in texlive-bin (2013.20130521.30601-1) and you're now just showing us that you love to waste everyone's time by discussing things that you didn't bother to look into just to prove that you have some theoretical knowledge of how things are supposed to work. Please stop posting so often on debian-devel unless you have something interesting to say and unless you have done your homework about the topic that you're responding too. TIA. -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20130522083257.ge12...@x230-buxy.home.ouaza.com
Re: Debian systemd survey
Uoti Urpala wrote: A related point which I think is very important is the effect of Debian's decision on the larger community. Having Linux distributions permanently split in systemd and upstart camps would have major costs for the overall Linux community. Actually, in the EU this is called antitrust and considered a good thing for a âmarketâ, also increasing innovation by open competition. Systemd is already guaranteed to live, Yeah, in a proprietary RedHat world⦠could easily switch to. Maintaining and extending such a split between distros should be seen as a big negative, regardless of how upstart No, it should be seen as a bit *positive*, for the aforementioned reason as well as for reasons already seen on the list. IMO essentially irrelevant distractions such as effects on marginal systems like kFreeBSD shouldn't be brought up at all. Like it or not, but kFreeBSD *is* now part of the ecosystem. And I still think internal consistency is something desirable, so sysvinit should stay the default, with other init systems (yes this does include OpenRC) available for these who want to use it. As Debian, we have two different problems: 1. We need to decide which init systems we want to support, and how. 2. We need to decide which init system should be the default. We will have a GR about that. I don't think it's at all obvious that it would make sense to support more than systemd Debian is the Universal Operating System, not GNOME OS. If you want to develop GNOME OS, please do it as a Derivate or Blend, or something entirely separate. Really, reading this makes Rogerâs (IIRC) suggestion of removing it entirely all that more enticing⦠fit-for-use maintenance of all three systems sounds like a rather costly I see it like with new ports: if a new init system wants to be supported, they should help the package maintainers along in providing support, while the individual package maintainers should be gently encouraged to actually include said patches. And sysvinit is still the gold standard. (I personally like BSD stuff more, but from what Debian provides itâs the least evil or rather the one most people can agree to work with.) bye, //mirabilos -- 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/knhv7i$3vs$1...@ger.gmane.org
Re: Upstart kFreeBSD port for Debian
On 22 May 2013 03:09, Guillem Jover guil...@debian.org wrote: Hi! On Wed, 2013-05-22 at 01:47:42 +0100, Dmitrijs Ledkovs wrote: On 22 May 2013 01:16, Michael Biebl bi...@debian.org wrote: Am 22.05.2013 02:00, schrieb Dmitrijs Ledkovs: On 21 May 2013 21:53, Lucas Nussbaum lu...@debian.org wrote: On 20/05/13 at 18:19 +0200, Michael Stapelberg wrote: - Neither systemd nor upstart are likely to be ported to kfreebsd soon, as they both rely on many Linux-specific features and interfaces. Well, Colin Watson, Matthias Klose, Steve Langasek, James Hunt and I have discussed the state of the kfreebsd possibility a few times over the past year or so. I started porting libnih and upstart to GNU/kFreeBSD some months ago, just for fun, whenever I had nothing else to do. But then I'm not interested in assigning my copyright to a for-profit company that is not employing me (and no, this is not a job request); so I didn't post anything yet, because I don't use upstart, didn't want to promise anything (still don't), and it would present as an _interesting_ situation for the Debian upstart maintainers (either reject the patches or carry them forever as a small fork...). For libnih: fork it, push it, merge propose into https://github.com/keybuk/libnih As Steve already mentioned, Scott is the upstream for libnih. It boiled down to: if we have waitid inotify it should be possible to have a reasonable stab at doing a kfreebsd port for the system-wide upstart init (with libnih and mountall). For session init we currently do use prctl to set subreaper, but one can still have session upstart init without that syscall. Was there something else needed? Or can anyone else spot other big incompatible chunks of code? https://lists.debian.org/debian-bsd/2009/07/msg00122.html I think I've posted this multiple times, whenever those items lists are posted: http://www.hadrons.org/~guillem/debian/ports/porting And somehow I have missed it up until now. Very nice guide. I like it a lot. Concise pointers =) Regards, Dmitrijs. -- 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/CANBHLUhwJQKsshXv+_5UkrH=8kyxbdr3vmpr1otl0hu-eij...@mail.gmail.com
Re: jessie release goals
On 2013-05-19 09:17:31 +0200, Jean-Christophe Dubacq wrote: Le 16/05/2013 08:43, Vincent Lefevre a écrit : On 2013-05-15 20:27:09 +0200, Jean-Christophe Dubacq wrote: No. Your server comes unconfigured, you do configure it while the other is still working, and then you stop the service on the first, finish syncing the mailboxes, switch the MX record, and then you can go to rest. This is not possible, as I have only one server (which is sufficient for a personal server). If this is a first configuration, then the mail was not working before anyway. So you are not losing thousands of emails. It this is not, then you are already configured, and debconf will not touch your files. It was a complete reinstallation (not an upgrade). Of course, I could copy the configuration files. But if there were incompatible changes in the new version of postfix, things could break. So, I wanted to restart from clean config files and update them. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20130522091835.ga25...@xvii.vinc17.org
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh
On 22 May 2013 03:32, Paul Tagliamonte paul...@ubuntu.com wrote: On Wed, May 22, 2013 at 01:16:29AM +0100, Dmitrijs Ledkovs wrote: I have signed Canonical's and Python Software Foundation's contributor agreements. But I have no intention to assign copyright to FSF at the moment, given it's past well documented bad practices at doing things for the sake of it, instead of benefit of the wider free software community. The FSF's end goal is Free Software[1], whereas Canonical's is cold, hard, cash. Nothing wrong with that, but you have to admit that they don't really care about ideology or ethics, but providing a distro people will use (and buy services / devices / support for). I don't see how you can see the FSF as worse than Canonical in terms of respecting your code and end user freedom. Relatedly, the PSF is great. I responded with my Ubuntu address to drive this point home clearly - I support what Canonical and Ubuntu are doing; so much, in fact, I've spent over 5 years of my life helping make that happen. That being said, I don't grok your argument. [1]: OK. Not Free Software as such, but Free Software as a means to an end -- namely, free users. My stance is reverse. IMHO Canonical has done more to promote free software among people, companies, businesses, non-for-profits, governments and NGOs than any other free software company or organisation. It can be seen from the amount of pre-installed machines shipped with Ubuntu from all Tier-1 hardware vendors and many other smaller hardware vendors. Oracle is a company with a cold, hard, cash goal. Canonical whilst striving to be self-sustaining, evidently spends most of its profits/money on new ResearchDevelopment be it Linaro, Unity, Juju or the SaaS offerings like U1 Landscape suite of services. Some produce more open source software than others, and all of these will be ranked differently by each person differently, am I still yet to be screwed by Canonical's projects. Please correct me if I am wrong, but none of Canonical CA covered projects yet to (a) change their license or (b) go proprietary. Since Canonical's CA inception, it has been modified to grant less rights to canonical and counter keep more to the authors, thus adjusting the balance based on community feedback. And more and more software is released as open source. Contrast with what Oracle has been doing in the past years. FSF on the other hand: * GFDL fiasco - because clearly the world cannot live another day without RMS essay, and oh my one shouldn't generate GCC documentation from code comments * SSL licensing - the combination of gnutls going v3 v3 still being incompatible with OpenSSL and/or v2 * Clang/LLVM - moving gcc to v3 thus making Apple contribute/develop LLVM instead of continuing to use gcc (/me is on gcc camp, thus it's fsf's negative point. Others might cheer for this move, which gave the birth to Clang, eventually) * GNU Project mismanagement/micromanagement - (GnuTLS sed others) https://lwn.net/Articles/529522/ https://lwn.net/Articles/530460/ These are just a few grudges I have against FSF. I like FSF EU division though. As you say, Relatedly, the PSF is great. So CA alone, is really not a cause or reason for one's actions. In general, I like CAs as it assigns liability to a 3rd party that can afford lawyers. Regards, Dmitrijs. -- 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/canbhluiawahrejt6mpr_4c2gjdixpbjw+cjiizthkdyhthu...@mail.gmail.com
Re: On advocating NM applicants
Thorsten Glaser t...@debian.org (22/05/2013): Jonathan Wiltshire (Front Desk nm at debian.org writes: 3. Choose something appropriate from the links at the top right of the page. Advocate for DD is normally what you're after. Can’t see that. (I tried a half dozen people just to confirm…) Look again, picking people that can be advocated for DD. For example: https://nm.debian.org/public/people/dm Mraw, KiBi. signature.asc Description: Digital signature
Bug#709284: ITP: yorick-gy -- GObject introspection bindings for the Yorick language
Package: wnpp Severity: wishlist Owner: Thibaut Paumard thib...@debian.org Hi, * Package name: yorick-gy Version : 0.0.1 Upstream Author : Thibaut Paumard * URL : https://github.com/paumard/yorick-gy * License : GPL Programming Lang: C, Yorick Description : GObject introspection bindings for the Yorick language This Yorick plug-in exposes the GObject introspection library to Yorick, with particular interest in accessing the Gtk library. I propose to package it under the debian-science umbrella, like the rest of the Yorick packages. Regards, Thibaut. -- 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/20130522104830.11061.12383.report...@tantive-iv.obspm.fr
Re: On advocating NM applicants
Cyril Brulebois kibi at debian.org writes: Thorsten Glaser tg at debian.org (22/05/2013): Jonathan Wiltshire (Front Desk nm at debian.org writes: 3. Choose something appropriate from the links at the top right of the page. Advocate for DD is normally what you're after. Can’t see that. (I tried a half dozen people just to confirm…) Look again, picking people that can be advocated for DD. For example: https://nm.debian.org/public/people/dm Hm weird. I tried earlier, since my *intent* was on advocating RichiH, but now it worked, i.e. the link shows up in the upper-right corner, where it was not previously. *shrug* bye, //mirabilos -- 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/loom.20130522t125147-...@post.gmane.org
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh
On Wed, May 22, 2013 at 10:13:23AM +0100, Dmitrijs Ledkovs wrote: Some produce more open source software than others, and all of these will be ranked differently by each person differently, am I still yet to be screwed by Canonical's projects. Please correct me if I am wrong, but none of Canonical CA covered projects yet to […] When looking at copyright assignments to companies, the above is hardly the point, in my opinion. The problem (quotes because it's just the way things are) with companies is that they can be sold and bought, and the new management can have entirely different objectives, and strategies to reach it, than the former management you trusted. We have seen plenty of bad examples of this happening to open source companies in recent years, I'm surprised we haven't learned the lesson yet. Your historical record arguments here say vary little about what could happen in the future to CAA/CLAs you make to for-profit companies; the only guarantees you have are the terms of the agreements. Arguably, risks of changes in objectives and strategies exist also for non-profit organizations. But when they are much lower when those organizations have clear governance structures and contestable (it is left to the reader to judge whether FSF fits this definition). Also, the mere fact that you remove profit from the equation reduces quite a bit the overall pressure in changing objectives and strategies. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: simplifying running piuparts (was: Re: Debian development and release: always releasable (essay))
Hi, On Mittwoch, 22. Mai 2013, Charles Plessy wrote: it is not fully related to your original question, but do you think that piuparts could support running Autopkgtests as well ? I think we need another setup for this. Autopkgtests may destroy their environment (and might need more than a chroot) so they cannot be fully tested in our current piuparts.d.o setup. I'd rather do autopkgtests with jenkins.d.n (and be very happy to help anyone working on them). cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Bug#709237: ITP: meta-suckless-tools -- meta-package installs simple commands for minimalistic window managers
Hello, On Wed, 22 May 2013 00:11:20 +0400 Dmitry Papchenkoff dmitry.papchenk...@gmail.com wrote: 10 packages, excluding metapackage. This work was originally done for test-packages for mentors.debian.net as an effort to update and clean up suckless-tools. But after posting packages to mentors I was requested to make ITP-bugs for it. So, I'll post ITP just for two packages and wait if maintainer or other users find it useful (if any) I strongly disagree with this proposed split. The package is already too small for that. This split just adds unnecessary complexity and bloats the package manager lists, and also confuses users. Please don't. -- WBR, Andrew signature.asc Description: PGP signature
Bug#709294: ITP: fitsverify -- FITS File Format-Verification Tool
Package: wnpp Severity: wishlist Owner: Ole Streicher deb...@liska.ath.cx X-Debbugs-Cc: debian-devel@lists.debian.org,debian-scie...@lists.debian.org * Package name: fitsverify Version : 4.16 Upstream Author : NASA HEASARC * URL : http://heasarc.gsfc.nasa.gov/docs/software/ftools/fitsverify/ * License : BSD (have to verify) Programming Lang: C Description : FITS File Format-Verification Tool Read one or more input FITS files and verifies that the files conform to the specifications of the FITS Standard document (known as the NASA/Science Office of Standards and Technology 'Definition of the Current FITS Standard', document number, NOST 100-2.0, available online at http://fits.gsfc.nasa.gov/). This is the stand alone version of the FTOOLS 'fverify' program. It is maintained by the HEASARC at NASA/GSFC. I have setup a git repository at http://anonscm.debian.org/git/debian-science/packages/fitsverify.git Best Ole -- 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/519cad8e.2090...@liska.ath.cx
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh
On 22-05-13 13:06, Stefano Zacchiroli wrote: On Wed, May 22, 2013 at 10:13:23AM +0100, Dmitrijs Ledkovs wrote: Some produce more open source software than others, and all of these will be ranked differently by each person differently, am I still yet to be screwed by Canonical's projects. Please correct me if I am wrong, but none of Canonical CA covered projects yet to […] When looking at copyright assignments to companies, the above is hardly the point, in my opinion. No, that is *exactly* the point: yes, companies may have different objectives, but that doesn't mean they have to use different ways to get to those objectives. A contract is binding, whether one party to the contract is a nonprofit, a company, or a private person; if you receive promises (in writing) that they won't do a particular thing, and they then go ahead and do it anyway, you have perfect grounds to sue them for breach of contract. The problem (quotes because it's just the way things are) with companies is that they can be sold and bought, and the new management can have entirely different objectives, and strategies to reach it, than the former management you trusted. If you trusted the former management and didn't sign any contract with them, then that's your own fault, and you got entirely what you deserved. In contrast, if you signed a well-specified contract with the former management that specified explicitly what they could and could not do, and then the new management heads off and does it anyway, you still have the right to sue them. After all, you signed a contract with the company, not with the company's management. We have seen plenty of bad examples of this happening to open source companies in recent years, I'm surprised we haven't learned the lesson yet. The lesson, presumably, is don't trust (non-written) words, trust contracts. Your historical record arguments here say vary little about what could happen in the future to CAA/CLAs you make to for-profit companies; the only guarantees you have are the terms of the agreements. That much, of course, is true. [...] Also, the mere fact that you remove profit from the equation reduces quite a bit the overall pressure in changing objectives and strategies. For big multinational companies, perhaps. But not for smaller companies. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: OpenPGP digital signature
Bug#709295: ITP: seafile -- online file storage and collaboration server
Package: wnpp Severity: wishlist Owner: Ondřej Surý ond...@debian.org * Package name: seafile Version : 1.6.1 Upstream Author : Seafile Ltd. freepl...@gmail.com * URL : http://seafile.com * License : GPL3+ Programming Lang: C Description : online file storage and collaboration server Seafile enables you to build private cloud for file sharing and collaboration among team members in your company/organization. This is the client of the seafile system. . First you create a file library in the web and upload files to it. Then you share it into a team or with another user. . File libraries can also be synchronized among computers and mobile devices. You download a library to your PC. Whenever you add, delete or edit a file, the latest version be uploaded to the server automatically and then be synchronized to everyone's computer. . This package contains the seafile server. -- 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/20130522115009.7273.8567.reportbug@localhost6.localdomain6
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh
Hi, On Mittwoch, 22. Mai 2013, Dmitrijs Ledkovs wrote: FSF on the other hand: [...] You forgot their failure with this gnu unix system they were trying to build! This also didnt take off - what a bunch of loosers! cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: simplifying running piuparts (was: Re: Debian development and release: always releasable (essay))
* Holger Levsen hol...@layer-acht.org, 2013-05-22, 13:26: it is not fully related to your original question, but do you think that piuparts could support running Autopkgtests as well ? I think we need another setup for this. Autopkgtests may destroy their environment (and might need more than a chroot) so they cannot be fully tested in our current piuparts.d.o setup. FWIW, most of the packages don't need anything more than a chroot. Out of 116 packages that have DEP-8 tests, only 2 declare the breaks-testbed restrictions. (And, AFAICS, even the two with breaks-testbed don't currently need stronger isolation.) -- Jakub Wilk -- 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/20130522121418.ga3...@jwilk.net
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh
On Wed, May 22, 2013 at 01:35:54PM +0200, Wouter Verhelst wrote: No, that is *exactly* the point: yes, companies may have different objectives, but that doesn't mean they have to use different ways to get to those objectives. A contract is binding, whether one party to the contract is a nonprofit, a company, or a private person; if you receive promises (in writing) that they won't do a particular thing, and they then go ahead and do it anyway, you have perfect grounds to sue them for breach of contract. ... except that the examples being made were of activities that are permitted by the terms of the agreement. The discussion was about whether you should trust that a company won't do in the future activities that you consider bad (but which *are* permitted by the agreements), based on their past record of not doing so. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: simplifying running piuparts (was: Re: Debian development and release: always releasable (essay))
On Mittwoch, 22. Mai 2013, Jakub Wilk wrote: FWIW, most of the packages don't need anything more than a chroot. Interesting, thanks. signature.asc Description: This is a digitally signed message part.
Re: Debian systemd survey
]] Lucas Nussbaum If I were you, I would be very worried about the risk that the decision will be taken not by looking at which one is the best, but by looking at which one is de-facto supported in Debian. In that area, systemd is very late, since: - AFAIK nobody has started the effort to document things in policy - there are 300+ upstart job files ready to be imported from Ubuntu So, please work on: - policy support - outlining how systemd and sysvinit can properly co-exist in the archive (this is required in any case for the duration of the transition) - outlining how the transition could be achieved, eased, and tracked We're going to respond to those once the time period for the survey is up. Until then, could we please not be having this discussion? Thanks, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87ehczrz8n@qurzaw.varnish-software.com
Re: Debian systemd survey
Le mercredi 22 mai 2013 à 08:16 +0200, Lucas Nussbaum a écrit : - there are 300+ upstart job files ready to be imported from Ubuntu When you compare the time it takes to write an upstart job file or a systemd unit file, to the time it takes to proprely test it, I don’t think this argument makes any sense. If the only things we do for improving the distribution are to take stuff from Ubuntu because, well, it’s here, we might as well stop developing anything at all. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1369226754.12592.96.camel@pi0307572
Deciding on init systems (Was: Debian systemd survey)
On 22/05/13 at 08:22 +, Thorsten Glaser wrote: As Debian, we have two different problems: 1. We need to decide which init systems we want to support, and how. 2. We need to decide which init system should be the default. We will have a GR about that. (I assume that by about that, you mean (2). For (1), we only need people to do the work.) While this is a possible outcome, I think that this is rather unlikely. If it happens, it would be the most technical GR ever seen so far, and a failure, as we would not have been able to achieve a decision by other means. Also, it would be very inefficient to ask every DD to acquire sufficient knowledge about init systems to be able to take an informed decision about that. Instead, if the decision of which one should be the default is not consensual by the time we have made sufficient progress on supporting the various init systems (policy changes, understanding how they can coexist and how packages can migrate to them), I think that it would be a good solution to ask the technical committee to decide on that. Lucas signature.asc Description: Digital signature
Re: Bug#709237: ITP: meta-suckless-tools -- meta-package installs simple commands for minimalistic window managers
On Wed, May 22, 2013 at 5:00 PM, Andrew Shadura bugzi...@tut.by wrote:
I strongly disagree with this proposed split. The package is already
too small for that. This split just adds unnecessary complexity and
bloats the package manager lists, and also confuses users. Please don't.
+1.
Dmitry, Have you contact maintainer before proposing split? Please do.
And, package is in collab-maint. Feel free to propose patch(es) to it.
--
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com
--
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/capdygezfqumpfrn6ttozkfl43bryevpbhycxakz2uvrhu3c...@mail.gmail.com
Re: Debian systemd survey
On May 21, Lucas Nussbaum lu...@debian.org wrote: We don't need to select a single init system at this point, and it would As the maintainer of a package which is strongly tied to the init system, I disagree. Then, something I failed to find in the discussion was a discussion of how sysvinit / systemd / upstart could co-exist (not on a single system, but in the archive). I suggest that this is related to my first point. I understand that systemd replaces some parts of initscripts, could also replace syslog, etc. How do systemd supporters see that working in practice? What kind of feature duplication between init sytems should be expected? How much does it increase the maintenance effort? I am not strictly a systemd supporter but more like a modern init system supporter, and the duplication, increased mainteinance overhead and lack of QA are the reasons why I do not want to support multiple init systems in my packages and I do not think that Debian should either as a project. Is it realistic to dream about a generator that would automate the generation of sysvinit scripts, systemd .service files, and upstart job files for a majority of our packages (the easy ones)? The easy ones can continue using sysvinit scripts for a while, since they can coexist with both upstart and systemd configurations. (Maybe better in the systemd case.) -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#709237: ITP: meta-suckless-tools -- meta-package installs simple commands for minimalistic window managers
On Wed, May 22, 2013 at 07:17:34AM +0400, Dmitry Papchenkoff wrote: Maybe there should not be a separate package for each tool, but at least st and dmenu should be packaged separately. Why? Moreover, there IS a package named stterm in unstable which ships st separately (I've found it then published ITP for my version of st). It lacks Breaks/Conflicts with suckless-tools 38, but will overwrite it files. It predates suckless-tools in the archive. Therefore, suckless-tools should have renamed its st binary. Conflicts is not appropriate 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/20130522133146.GA20887@debian
Re: Debian systemd survey
On 05/22/2013 04:50 AM, Uoti Urpala wrote: Lucas Nussbaum wrote: I went through the various init systems threads again during the last few days. My understanding of the consensus so far is the following: - Both systemd and upstart bring many useful features, and are a clear improvement over sysvinit. Yes, both are an improvement over sysvinit. Hrmm, I have not tested systemd yet, but personally I'm not conviced about the advantages of upstart: - Stops booting *somtimes*, does not provide any information why. I didn't report a bug yet as an almost black screen won't help in any way how to figure out why it stopped. Already that stops without any further information why and where is a sufficiently big design issue, imho. (Btw, in the mean time I belive this issue is related to /etc/mtab, but I'm not sure yet.). - Updating/install programs in a chroot fails with weird messages that those programs (afaik for example X) cannot connect to upstart. Well, it is a chroot, what does it expect? - Personally I'm using unionfs-fuse as very first init script to mount /etc and /var and others on my development systems. So no need to modify an initrams, but a very simple approach and controllable using a boot script. But specifying a script to be run *before* anything else is not possible (yet?). Bernd -- 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/519cca74.9030...@aakef.fastmail.fm
Re: Debian systemd survey
Hi! On Wed, 2013-05-22 at 09:15:03 +0200, John Paul Adrian Glaubitz wrote: On 05/21/2013 10:53 PM, Lucas Nussbaum wrote: - Neither systemd nor upstart are likely to be ported to kfreebsd soon, as they both rely on many Linux-specific features and interfaces. What about launchd? Wouldn't it be possible to port that to Debian/kFreeBSD? It's designed to run in a BSD userland, after all. launchd relies heavily on Mach and Apple specific interfaces, and while there was a GSOC to port it to FreeBSD, funnily enough, in the end it might be easier to port it to GNU/Hurd! :) Also last I checked the upstream svn repo had not seen any update in a while, which might mean upstream practices might not be optimal. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130522135758.ga25...@gaara.hadrons.org
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh
On Wed, 2013-05-22 at 13:37 +0200, Holger Levsen wrote: Hi, On Mittwoch, 22. Mai 2013, Dmitrijs Ledkovs wrote: FSF on the other hand: [...] You forgot their failure with this gnu unix system they were trying to build! This also didnt take off - what a bunch of loosers! It is taking off, albeit slowly: (please join to make it happen faster:) http://www.debian.org/ports/hurd/hurd-news.en.html http://www.gnu.org/software/hurd/news/2013-05-debian_gnu_hurd_2013.html http://www.phoronix.com/scan.php?page=news_itempx=MTM3NzA http://news.slashdot.org/story/13/05/22/120258/debian-gnuhurd-2013-released -- 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/1369231279.8127.3.ca...@s1499.it.kth.se
Bug#709317: ITP: cpl-plugin-sinfo -- ESO data reduction pipeline for SINFONI
Package: wnpp Severity: wishlist Owner: Ole Streicher deb...@liska.ath.cx X-Debbugs-Cc: debian-devel@lists.debian.org,debian-scie...@lists.debian.org * Package name: cpl-plugin-sinf Version : 2.3.3 Upstream Author : Andrea Modigliani amodi...@eso.org * URL : http://www.eso.org/sci/software/pipelines/sinfo * License : GPL Programming Lang: C Description : ESO data reduction pipeline SINFONI This is the data reduction pipeline for the SINFONI instrument of the Very Large Telescope (VLT) from the European Southern Observatory (ESO). . SINFONI is a near-infrared (1.1 - 2.45 µm) integral field spectrograph fed by an adaptive optics module, currently installed at the Cassegrain focus of UT4. The spectrograph operates with 4 gratings (J, H, K, H+K) providing a spectral resolution around 2000, 3000, 4000 in J, H, K, respectively, and 1500 in H+K - each wavelength band fitting fully on the 2048 pixels of the Hawaii 2RG (2kx2k) detector in the dispersion direction. The spatial resolution is selectable from 0.25, 0.1 to 0.025 per image slice, which corresponds to a field-of-view of 8x8, 3x3, or 0.8x0.8 respectively. The instrument can be also used for seeing limited open loop observations. -- 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/519cd6e3.9020...@liska.ath.cx
Bug#709321: ITP: cpl-plugin-fors -- ESO data reduction pipeline for FORS
Package: wnpp Severity: wishlist Owner: Ole Streicher deb...@liska.ath.cx X-Debbugs-Cc: debian-devel@lists.debian.org,debian-scie...@lists.debian.org * Package name: cpl-plugin-fors Version : 4.9.23 Upstream Author : ESO * URL : http://www.eso.org/sci/software/pipelines/fors * License : GPL Programming Lang: C Description : ESO data reduction pipeline FORS FORS pipeline recipes for the reduction of data obtained with the FORS1 and FORS2 instruments in the LSS, MOS, MXU, PMOS, and direct imaging instrument modes. . FORS is the visual and near UV FOcal Reducer and low dispersion Spectrograph for the Very Large Telescope (VLT) of the European Southern Observatory (ESO). Two versions of FORS have been built, upgraded and moved to the Cassegrain foci of different telescopes in the past years. In April 2009, FORS1 was dismounted to make room for X-shooter, so only FORS2 is in operation. FORS is designed as an all-dioptric instrument for the wavelength range from 330 nm to 1100 nm and provides an image scale of 0.25/pixel (or 0.125/pixel with the high resolution collimator) in the standard readout mode (2x2 binning). FORS2 is installed on UT1 (Antu) and is by default equipped with a detector system that is optimised for the red with a very low level of fringes thanks to a mosaic of two 2k x 4k MIT CCDs (with 15 µm pixels). However, the blue-optimised detector system that was previously available on FORS1 has been commissioned on FORS2 and can be requested for Visitor Mode observation. The geometries of both detector systems are similar, with the optical axis falling ~30 above the gap and offsets of a few arc-seconds between the two chips. FORS2 has many modes, including multi-object spectroscopy with exchangable masks, long-slit spectroscopy, imaging and spectro-polarimetry and high-time resolution imaging and spectroscopy. -- 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/519cd80f.6020...@liska.ath.cx
Bug#709323: ITP: cpl-plugin-giraf -- ESO data reduction pipeline for GIRAFFE
Package: wnpp Severity: wishlist Owner: Ole Streicher deb...@liska.ath.cx X-Debbugs-Cc: debian-devel@lists.debian.org,debian-scie...@lists.debian.org * Package name: cpl-plugin-giraf Version : 2.11 Upstream Author : Ralf Palsa rpa...@eso.org * URL : http://www.eso.org/sci/software/pipelines/giraf * License : GPL Programming Lang: C Description : ESO data reduction pipeline for GIRAFFE This is the data reduction pipeline for the GIRAFFE instrument of the Very Large Telescope (VLT) from the European Southern Observatory (ESO). . GIRAFFE is a medium-high resolution (R=7500-3) spectrograph for the entire visible range 370-900 nm. GIRAFFE is aimed at carrying out intermediate and high resolution spectroscopy of galactic and extragalactic objects having a high spatial density. The name comes from the first design, where the spectrograph was standing vertically on a platform. -- 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/519cd951.6010...@liska.ath.cx
Bug#709329: ITP: cpl-plugin-amber -- ESO data reduction pipeline for AMBER
Package: wnpp Severity: wishlist Owner: Ole Streicher deb...@liska.ath.cx X-Debbugs-Cc: debian-devel@lists.debian.org,debian-scie...@lists.debian.org * Package name: cpl-plugin-amber Version : 4.2.2 Upstream Author : Armin Gabasch agaba...@eso.org * URL : http://www.eso.org/sci/software/pipelines/amber * License : GPL Programming Lang: C Description : ESO data reduction pipeline for AMBER This is the data reduction pipeline for the Amber instrument of the Very Large Telescope (VLT) from the European Southern Observatory (ESO). . AMBER is a near-infrared, multi-beam interferometric instrument, combining simultaneously up to 3 telescopes. AMBER can be used in Period 82 and following with UTs or ATs (see below for current performance specifications). All possible triplets of UTs are available, and a number of selected AT combinations. -- 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/519cdb27.6030...@liska.ath.cx
Bug#709330: ITP: cpl-plugin-hawki -- ESO data reduction pipeline for HAWK-I
Package: wnpp Severity: wishlist Owner: Ole Streicher deb...@liska.ath.cx X-Debbugs-Cc: debian-devel@lists.debian.org,debian-scie...@lists.debian.org * Package name: cpl-plugin-hawki Version : 1.8.12 Upstream Author : César Enrique García Dabó cgar...@eso.org * URL : http://www.eso.org/sci/software/pipelines/hawki * License : GPL Programming Lang: C Description : ESO data reduction pipeline for HAWK-I This is the data reduction pipeline for the HAWK-I instrument of the Very Large Telescope (VLT) from the European Southern Observatory (ESO). . HAWK-I is a near-infrared (0.85-2.5 µm ) wide-field imager. It is being offered for the first time in Period 81. The instrument is cryogenic (120 K, detectors at 80 K) and has a full reflective design. The light passes four mirrors and two filter wheels before hitting a mosaic of four Hawaii 2RG 2048 * 2048 pixels detectors. The final F-ratio is F/4.36 ( 1 arcsec on the sky corresponds to 169 µm on the detector). -- 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/519cdbca.3000...@liska.ath.cx
Re: Bug#709237: ITP: meta-suckless-tools -- meta-package installs simple commands for minimalistic window managers
On 14:31 Wed 22 May , Jonathan Dowland wrote:
On Wed, May 22, 2013 at 07:17:34AM +0400, Dmitry Papchenkoff wrote:
Maybe there should not be a separate package for each tool, but at
least st and dmenu should be packaged separately.
Why?
Moreover, there IS a package named stterm in unstable which ships st
separately (I've found it then published ITP for my version of st). It
lacks Breaks/Conflicts with suckless-tools 38, but will overwrite it
files.
It predates suckless-tools in the archive. Therefore, suckless-tools
should have renamed its st binary. Conflicts is not appropriate here.
Actually both suckless-tools with st and stterm existed together and
still exists together but as Dmitry says stterm doesn't overwrite st
files shipped by suckless-tools, it actually renames st files to
stterm. And new version of suckless-tools in experimental (39) does no
longer have st (will be uploaded soon to unstable).
I already replied to this ITP as I'm the maintainer of suckless-tools
but didn't Cc debian-devel but since the thread is still continuing here
is clarification from my side on the bug report [1]
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709237#28
--
Vasudev Kamath
http://copyninja.info
Connect on ~friendica: copyninja@{frndk.de | vasudev.homelinux.net}
IRC nick: copyninja | vasudev {irc.oftc.net | irc.freenode.net}
GPG Key: C517 C25D E408 759D 98A4 C96B 6C8F 74AE 8770 0B7E
signature.asc
Description: Digital signature
Re: Debian launchd survey
On Wed, May 22, 2013 at 09:15:03AM +0200, John Paul Adrian Glaubitz wrote: On 05/21/2013 10:53 PM, Lucas Nussbaum wrote: - Neither systemd nor upstart are likely to be ported to kfreebsd soon, as they both rely on many Linux-specific features and interfaces. What about launchd? Wouldn't it be possible to port that to Debian/kFreeBSD? It's designed to run in a BSD userland, after all. That doesn't seem like it would help at all with the concern about keeping our userspace aligned across kernels. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Debian systemd survey
On 22/05/13 at 14:45 +0200, Josselin Mouette wrote: Le mercredi 22 mai 2013 à 08:16 +0200, Lucas Nussbaum a écrit : - there are 300+ upstart job files ready to be imported from Ubuntu When you compare the time it takes to write an upstart job file or a systemd unit file, to the time it takes to proprely test it, I don’t think this argument makes any sense. If the only things we do for improving the distribution are to take stuff from Ubuntu because, well, it’s here, we might as well stop developing anything at all. Note that if it's there, and Ubuntu uses upstart, it has probably been tested. I was not suggesting that we blindly import upstart job files from Ubuntu, but a basis to start from is better than no basis at all. (I can see how my phrasing was a bit confusing -- sorry about that) Lucas -- 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/20130522154811.ga25...@xanadu.blop.info
using upstart in Debian [was, Re: Debian systemd survey]
On Wed, May 22, 2013 at 03:39:00PM +0200, Bernd Schubert wrote: On 05/22/2013 04:50 AM, Uoti Urpala wrote: Lucas Nussbaum wrote: I went through the various init systems threads again during the last few days. My understanding of the consensus so far is the following: - Both systemd and upstart bring many useful features, and are a clear improvement over sysvinit. Yes, both are an improvement over sysvinit. Hrmm, I have not tested systemd yet, but personally I'm not conviced about the advantages of upstart: - Stops booting *somtimes*, does not provide any information why. I didn't report a bug yet as an almost black screen won't help in any way how to figure out why it stopped. Already that stops without any further information why and where is a sufficiently big design issue, imho. (Btw, in the mean time I belive this issue is related to /etc/mtab, but I'm not sure yet.). Sorry you ran into trouble with upstart. Probably related to /etc/fstab, rather than /etc/mtab... Due to incomplete upstart integration of plymouth in Debian at present, if there are problems in /etc/fstab, mountall won't always be able to display any prompt to the user asking what to do (cf. http://web.dodds.net/~vorlon/wiki/blog/Plymouth_is_not_a_bootsplash/). Whereas sysvinit would eventually give up on trying to mount filesystems in /etc/fstab if they were missing at boot and continue booting without them, upstart takes the design decision that this is an error that the admin needs to deal with directly. This ensures that the system always boots reliably in the face of slow disks, which become more of a problem now that your init system is so fast that it can boot before your hardware has been probed. Feel free to file a bug report against the upstart package (with a copy of your /etc/fstab attached) so we can look at this further. - Updating/install programs in a chroot fails with weird messages that those programs (afaik for example X) cannot connect to upstart. Well, it is a chroot, what does it expect? This is bug #685779, which will be fixed in the next upload of sysvinit to unstable. - Personally I'm using unionfs-fuse as very first init script to mount /etc and /var and others on my development systems. So no need to modify an initrams, but a very simple approach and controllable using a boot script. But specifying a script to be run *before* anything else is not possible (yet?). I'm skeptical of the value of such a design in place of just using an initramfs, but the 'friendly-recovery' package in Ubuntu gives an example of to do this. You create an upstart job that's 'start on real-startup-event', runs your necessary pre-setup, and at the end calls 'initctl emit startup' to call into the rest of the boot sequence; then you pass '--startup-event=real-startup-event' to init on the kernel commandline. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Debian systemd survey
On Wed, May 22, 2013 at 02:45:54PM +0200, Josselin Mouette wrote: Le mercredi 22 mai 2013 à 08:16 +0200, Lucas Nussbaum a écrit : - there are 300+ upstart job files ready to be imported from Ubuntu When you compare the time it takes to write an upstart job file or a systemd unit file, to the time it takes to proprely test it, I don’t think this argument makes any sense. Please leave the FUD at the door. Writing upstart jobs is not difficult; while there are some gotchas currently with process lifecycle (which will be fixed soon), there is also very complete documentation (for these issues, and generally). http://upstart.ubuntu.com/cookbook/ If the only things we do for improving the distribution are to take stuff from Ubuntu because, well, it’s here, we might as well stop developing anything at all. Sure; obviously the right thing to do is to instead take stuff from GNOME and freedesktop.org without regard to integration with our existing system, because if Lennart says it's right it must be so. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Debian systemd survey
Am 22.05.2013 18:12 schrieb Lucas Nussbaum lu...@debian.org: On 22/05/13 at 14:45 +0200, Josselin Mouette wrote: Le mercredi 22 mai 2013 à 08:16 +0200, Lucas Nussbaum a écrit : - there are 300+ upstart job files ready to be imported from Ubuntu When you compare the time it takes to write an upstart job file or a systemd unit file, to the time it takes to proprely test it, I don’t think this argument makes any sense. If the only things we do for improving the distribution are to take stuff from Ubuntu because, well, it’s here, we might as well stop developing anything at all. Note that if it's there, and Ubuntu uses upstart, it has probably been tested. I was not suggesting that we blindly import upstart job files from Ubuntu, but a basis to start from is better than no basis at all. (I can see how my phrasing was a bit confusing -- sorry about that) Please also keep in mind that many upstream projects ship systemd service files. Therefore, most of the systemd work is already done too. Cheers, Matthias
Re: Debian systemd survey
Le mercredi 22 mai 2013 à 09:41 -0700, Steve Langasek a écrit : On Wed, May 22, 2013 at 02:45:54PM +0200, Josselin Mouette wrote: When you compare the time it takes to write an upstart job file or a systemd unit file, to the time it takes to proprely test it, I don’t think this argument makes any sense. Please leave the FUD at the door. Writing upstart jobs is not difficult; while there are some gotchas currently with process lifecycle (which will be fixed soon), there is also very complete documentation (for these issues, and generally). In which way do you disagree with what I wrote, exactly? Maybe my English was wrong, so let me explain it in simple words. Time to write an upstart job = short Time to write a systemd unit file = short Time to test an upstart job = long Time to test a systemd unit file = long Therefore: How much we should care of existing upstart jobs = little How much we should care of existing systemd unit files = little If the only things we do for improving the distribution are to take stuff from Ubuntu because, well, it’s here, we might as well stop developing anything at all. Sure; obviously the right thing to do is to instead take stuff from GNOME and freedesktop.org without regard to integration with our existing system, because if Lennart says it's right it must be so. Yes of course, because Debian is well-known for using fd.o and GNOME software as is, without patching it ever, and adopting new technologies blindly and very quickly, before they are well tested. Have it ever occurred to you that people might want to see systemd as default, not because Lennart said it, but because they think it is better than any alternative? Better than upstart *in the way it integrates with our existing system*, BTW. I understand it will be a pain for Ubuntu if Debian picks a different init system. I don’t think this is relevant for the discussion, though. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1369244732.13422.10.camel@tomoyo
Re: libtiff borken - cannot build anymore?
Russ Allbery r...@debian.org wrote: Jay Berkenbilt q...@debian.org writes: Ondřej Surý ond...@sury.org wrote: This results in: E: libgd-tools: binary-or-shlib-defines-rpath usr/bin/annotate /usr/lib/x86_64-linux-gnu/libtiff5-alt Yes, I'm afraid that's unavoidable. This issue is mentioned in the README.Debian file. This works by installing the .so file in a non-standard location so that it can coexist with libtiff4, and linking in that way with libtool the rpath to be embedded. Once the tiff transition is completed and the packages are rebuilt, this problem will go away. This shouldn't be required, since the two libtiff shared libraries can both go into /usr/lib (since they have different SONAMEs). The only thing that can't go into /usr/lib and has to go somewhere else is the *.so symlink, which doesn't require an rpath setting, only a -L flag during linking. The .so files (there are two libraries), static libraries, and .la files are already the only files in a non-standard location. Basically only the files whose names clash are in non-standard locations. (Tiff still can't remove its .la file yet, or at least it couldn't though I can't remember the exact details of when it's okay to remove the .la fileit has a lot of reverse dependencies It's the only package I maintain that still installs .la files.) I don't remember exactly what is causing the rpath to appear, but I remember having investigated it and determined, possibly incorrectly, that I couldn't fix it without modifying libtool. I will give it another look. It is my recollection that libtool is automatically adding the rpath when it finds the .so file in a non-standard location since it assumes that the actual shared library will be in the same directory as the .so file. In other words, the rpath is not actually being used hereit is pointing to a place where the libraries are not found. I am already adjusting the .so file manually in the installation to ensure that it points to the correct place: $ dpkg --contents libtiff5-alt-dev_4.0.2-6_amd64.deb | fgrep .so lrwxrwxrwx root/root 0 2013-01-26 12:33 ./usr/lib/x86_64-linux-gnu/libtiff5-alt/libtiff.so - ../libtiff.so.5.1.0 lrwxrwxrwx root/root 0 2013-01-26 12:33 ./usr/lib/x86_64-linux-gnu/libtiff5-alt/libtiffxx.so - ../libtiffxx.so.5.1.0 See the krb5-multidev and heimdal-multidev packages for how this is done. I'll give them a look and see if I can tell what they're doing differently. -- Jay Berkenbilt q...@debian.org -- 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/20130522141348.0222507418.qww314...@jberkenbilt-linux.appiancorp.com
Re: Debian systemd survey
* Josselin Mouette j...@debian.org [2013-05-22 15:03]: Le mercredi 22 mai 2013 à 08:16 +0200, Lucas Nussbaum a écrit : - there are 300+ upstart job files ready to be imported from Ubuntu When you compare the time it takes to write an upstart job file or a systemd unit file, to the time it takes to proprely test it, I don’t think this argument makes any sense. If the only things we do for improving the distribution are to take stuff from Ubuntu because, well, it’s here, we might as well stop developing anything at all. Actually it sounds like you propose to stop developing and take everything from Redhat, Lennart, Gnome because it's there and they say so. Seems to me that luckily not everybody agrees with that approach (CTTE #681834, CTTE #688772)... -- 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/20130522175034.gd13...@anguilla.debian.or.at
Re: Debian launchd survey
On 05/22/2013 05:51 PM, Steve Langasek wrote: On Wed, May 22, 2013 at 09:15:03AM +0200, John Paul Adrian Glaubitz wrote: What about launchd? Wouldn't it be possible to port that to Debian/kFreeBSD? It's designed to run in a BSD userland, after all. That doesn't seem like it would help at all with the concern about keeping our userspace aligned across kernels. I honestly don't think this is going to be a realistic goal considering the fact neither upstart or systemd are still not working on BSD or even Hurd and I don't see any serious efforts by anyone to see this happen anytime soon. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/519d0dad.2000...@physik.fu-berlin.de
Re: Debian systemd survey
Le mercredi 22 mai 2013 à 19:50 +0200, Martin Wuertele a écrit : Actually it sounds like you propose to stop developing and take everything from Redhat, Lennart, Gnome because it's there and they say so. Damn! I have been exposed. I admit to everything. I am merely an artificial creature, designed by Lennart and sent here by the GNOME cabal, to end Debian as it is and turn it into a useless system that is not the UNIX way™. Seems to me that luckily not everybody agrees with that approach (CTTE #681834, CTTE #688772)... Fortunately the CTTE failed to expose me before you did, since they ended up authorizing the dependency I surreptitiously introduced. kthxbye, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1369247299.13422.20.camel@tomoyo
Re: Debian systemd survey
On 05/22/2013 06:41 PM, Steve Langasek wrote: On Wed, May 22, 2013 at 02:45:54PM +0200, Josselin Mouette wrote: Le mercredi 22 mai 2013 à 08:16 +0200, Lucas Nussbaum a écrit : - there are 300+ upstart job files ready to be imported from Ubuntu When you compare the time it takes to write an upstart job file or a systemd unit file, to the time it takes to proprely test it, I don’t think this argument makes any sense. Please leave the FUD at the door. Writing upstart jobs is not difficult; while there are some gotchas currently with process lifecycle (which will be fixed soon), there is also very complete documentation (for these issues, and generally). systemd's unit files are still way simpler than upstart job files since these are just more or less a simple set of instructions to give systemd some hints on how to deal with the targets and services, it actually does most of the work automatically without the need of scripts at all (which are obviously still required for upstart). If the only things we do for improving the distribution are to take stuff from Ubuntu because, well, it’s here, we might as well stop developing anything at all. Sure; obviously the right thing to do is to instead take stuff from GNOME and freedesktop.org without regard to integration with our existing system, because if Lennart says it's right it must be so. Honestly, these personal accusations against Lennart are getting old and boring. Don't you really have any other good argument to bring up against systemd other than you dislike *one* of the systemd developers?* And while I don't support all of the decisions GNOME upstream makes, I fully support f.d.o as an actual free and independent organization which hosts the development of systemd. *When* there is one company that is trying to fragment the Linux world then it's Canonical with its urge to come up with one NIH project after another, be it Bazaar (which seems to have been abandoned by upstream with 2000 open bugs [1]) or the Mir display server which isn't supported by neither the X.org/DRM developers or any developers of desktops like KDE, Enlightment or GNOME. Adrian * As you may know, systemd is developed by a large amount of contributors. [1] https://bugs.launchpad.net/bzr -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/519d1008.3040...@physik.fu-berlin.de
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh
On Wed, May 22, 2013 at 04:01:19PM +0200, Svante Signell wrote: On Wed, 2013-05-22 at 13:37 +0200, Holger Levsen wrote: Hi, On Mittwoch, 22. Mai 2013, Dmitrijs Ledkovs wrote: FSF on the other hand: [...] You forgot their failure with this gnu unix system they were trying to build! This also didnt take off - what a bunch of loosers! It is taking off, albeit slowly: (please join to make it happen faster:) [...] I think you're missing Holger's point: FSF has had great success with the GNU project. This is independent of the Hurd kernel. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20130522183651.gf4...@decadent.org.uk
Re: Debian systemd survey
On 05/22/2013 07:50 PM, Martin Wuertele wrote: Actually it sounds like you propose to stop developing and take everything from Redhat, Lennart, Gnome because it's there and they say so. And another one. Why is it that almost anyone who isn't favor of systemd is directly going off insulting their developers or any of the organizations behind of it? You know why many projects are adopting many technologies that are developed by RedHat people? It's because RedHat is an excellent upstream and they are one of the largest contributors to the whole Linux software stack, be it the kernel or anything above. Distributions would adopt more innovative and useful technologies developed by Canonical, for example, if there were any. I can't actually think of anything by Canonical which has been widely adopted outside Ubuntu. Blame Canonical for being a bad upstream, not RedHat for being a good one! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/519d1163.9070...@physik.fu-berlin.de
Bug#709363: ITP: libmodule-build-cleaninstall-perl -- module to remove the old module before installing the new one
Package: wnpp Severity: wishlist Owner: Oleg Gashev o...@gashev.net * Package name: libmodule-build-cleaninstall-perl Version : 0.05 Upstream Author : Joel A. Berger joel.a.ber...@gmail.com * URL : https://metacpan.org/release/Module-Build-CleanInstall/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to remove the old module before installing the new one Module::Build::CleanInstall is a subclass of Module::Build with one additional feature, before upgrading the module from and old version to a new one, it first removes the files installed by the previous version. This is useful especially when the new version will not contain some files that the old one did, and it is necessary that those files do not remain in place. . Since it is a subclass of Module::Build it is used exactly like that module. Module::Build::CleanInstall does provide an additional action uninstall, but it need not be called separately; the action install will call it when invoked. . The uninstalling is done by removing the files in the installed module's packlist|ExtUtils::Packlist which is created when the module is first installed. -- 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/20130522185840.8065.63480.reportbug@localhost
Re: Debian systemd survey
Martin Wuertele m...@debian.org writes: * Josselin Mouette j...@debian.org [2013-05-22 15:03]: When you compare the time it takes to write an upstart job file or a systemd unit file, to the time it takes to proprely test it, I don’t think this argument makes any sense. If the only things we do for improving the distribution are to take stuff from Ubuntu because, well, it’s here, we might as well stop developing anything at all. Actually it sounds like you propose to stop developing and take everything from Redhat, Lennart, Gnome because it's there and they say so. Seems to me that luckily not everybody agrees with that approach (CTTE #681834, CTTE #688772)... This isn't appropriate. I'm quite confident that Josselin is making informed technical judgements in what he views as the best interests of the project and the best technological direction for Debian. It's certainly fair game to disagree with him about the wisdom of that direction, but please don't level these kinds of accusations. There are a lot of people who choose to use systemd on its own merits. I know of green-field Linux-based projects with no vested interest in any choice that have chosen systemd purely on its merits (and others that have not). This is not one of those decisions where there's an obvious correct choice and everyone else is just not looking at the problem properly. The CTTE bugs you cite were about a difficult tradeoff between integration and flexibilty, with strong usability arguments to be made on both sides. Just because the CTTE ended up disagreeing with the initial choice of the GNOME maintainers doesn't mean that Josselin did anything wrong. It means that we have a governance process for making controversial decisions; that's what it's there for. It's not always obvious what decisions will be controversial in advance, and different people working on different parts of the project can, completely in good faith, view the relative merits of different tradeoffs differently. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87li76lthk@windlord.stanford.edu
Re: Debian systemd survey
* John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de [2013-05-22 20:57]: On 05/22/2013 07:50 PM, Martin Wuertele wrote: Actually it sounds like you propose to stop developing and take everything from Redhat, Lennart, Gnome because it's there and they say so. And another one. Why is it that almost anyone who isn't favor of systemd is directly going off insulting their developers or any of the organizations behind of it? Actually it's just a response to the ongoing insulting by joss to variouse participants on mailinglists. As usual he has a way of mailing that i find disgusting. You know why many projects are adopting many technologies that are developed by RedHat people? It's because RedHat is an excellent upstream and they are one of the largest contributors to the whole Linux software stack, be it the kernel or anything above. In many projects yes, in some no. Current kernel development, tough an understandable way to compete with Oracle, is not as cooperative as it was. Distributions would adopt more innovative and useful technologies developed by Canonical, for example, if there were any. I can't actually think of anything by Canonical which has been widely adopted outside Ubuntu. Actually in ubuntu happened a lot of multiarch development before it ended up in debian. Blame Canonical for being a bad upstream, not RedHat for being a good one! Actually that is not true. With some projects they both do a good job while with others they suck, it depends mainly on the actual persons 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/2013052219.ge13...@anguilla.debian.or.at
Re: Debian systemd survey
* Josselin Mouette j...@debian.org [2013-05-22 20:45]: Le mercredi 22 mai 2013 à 19:50 +0200, Martin Wuertele a écrit : Seems to me that luckily not everybody agrees with that approach (CTTE #681834, CTTE #688772)... Fortunately the CTTE failed to expose me before you did, since they ended up authorizing the dependency I surreptitiously introduced. Seems like you haven't realised yet: only if a maintainer makes controversal decisions and several others disagree such a case comes before the CTTE. Having choices ending up twice within relatively short time before the CTTE should give the maintainer a hint. -- 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/20130522192730.gf13...@anguilla.debian.or.at
Re: On advocating NM applicants
On Wed, May 22, 2013 at 07:48:27AM +0100, Jonathan Wiltshire (Front Desk) wrote: Hi, In the past few days and weeks there have been many advocacies, for new applicants and for DM-DD applicants. Please take advantage of the NM web interface where possible, as it makes the process much more streamlined for us. If the applicant doesn't have a record there yet, please wait patiently until they (or front desk) say go! and then do that. Your message will be sent on to debian...@lists.debian.org on your behalf, and meanwhile we get all the information required in one place. To advocate someone through the web interface: 1. Log in to https://nm.debian.org/ 2. Use the People tab to find the applicant of interest [1] 3. Choose something appropriate from the links at the top right of the page. Advocate for DD is normally what you're after. 4. Enter your message and if you're the first, also choose if this is to be an uploading or non-uploading application. You can still email your advocacy to front desk or debian-nm, but it will be copied into here in any case. Thanks for your assistance! 1: you will end up somewhere like https://nm.debian.org/public/person/jmw/ For front desk: -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 s/debian-nm/debian-newmaint/ throughout, sorry for any confusion. Turns out the oldest habits die hardest. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 signature.asc Description: Digital signature
Re: ITP: opensmtpd -- Simple Mail Transfer Protocol daemon
Hello, As per policy 10.9 - Permissions and owners[0], opensmtpd requires some system users for running non-root-privileged processes. I propose to user the following dynamic accounts; opensmtpd, opensmtpq, opensmtpf. Also I will be co-maintaining this package with Ryan Kavanagh, who has already done some work packaging opensmtpd. Dan [0] http://www.debian.org/doc/debian-policy/ch-files.html -- 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/20130522201318.gh2...@sumdoave.com
Re: Debian systemd survey
Martin Wuertele m...@debian.org writes: Seems like you haven't realised yet: only if a maintainer makes controversal decisions and several others disagree such a case comes before the CTTE. Having decisions appealed to the CTTE is not a punishment. It just indicates that a decision is controversial and the project was unable to reach a consensus. It's not always possible (and indeed not always wise) to avoid controversial decisions. Having choices ending up twice within relatively short time before the CTTE should give the maintainer a hint. It is, for example, probably a hint that the maintainer is working on something important that a lot of people care deeply about and therefore have strong opinions about. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87d2sikbaf@windlord.stanford.edu
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh
On Mittwoch, 22. Mai 2013, Ben Hutchings wrote: I think you're missing Holger's point: FSF has had great success with the GNU project. This is independent of the Hurd kernel. Yet I'm happy to finally see a Debian GNU/Hurd release. Wow! Whohooo! signature.asc Description: This is a digitally signed message part.
Re: using upstart in Debian [was, Re: Debian systemd survey]
On 05/22/2013 06:19 PM, Steve Langasek wrote: I'm skeptical of the value of such a design in place of just using an initramfs, but the 'friendly-recovery' package in Ubuntu gives an example of to do this. live-config-upstart needs the same to be useful. personally i have no experience with upstart at all and would therefore welcome a patch to implement this properly in live-config, otherwise upstart support will be dropped with one of the next uploads. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.bauman -- 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/519d2bc5.7050...@progress-technologies.net
Re: Debian systemd survey
Hi, On 22/05/13 at 15:11 +0200, Marco d'Itri wrote: On May 21, Lucas Nussbaum lu...@debian.org wrote: We don't need to select a single init system at this point, and it would As the maintainer of a package which is strongly tied to the init system, I disagree. Then, something I failed to find in the discussion was a discussion of how sysvinit / systemd / upstart could co-exist (not on a single system, but in the archive). I suggest that this is related to my first point. I understand that systemd replaces some parts of initscripts, could also replace syslog, etc. How do systemd supporters see that working in practice? What kind of feature duplication between init sytems should be expected? How much does it increase the maintenance effort? I am not strictly a systemd supporter but more like a modern init system supporter, and the duplication, increased mainteinance overhead and lack of QA are the reasons why I do not want to support multiple init systems in my packages and I do not think that Debian should either as a project. I agree that ideally, a swift and uneventful transition to a single modern init system would be great. Unfortunately, we have two strong alternatives, and no clear collective understanding of which one is better now, and will be for the future. I fully understand that supporting more than one init system increases the maintenance effort and the QA needs significantly, and that this is unlikely to be sustainable on the long term. However, this is a possible compromise that buys us time while we gain a better understanding of the pros and cons of each solution. What I failed to understand so far is what it would mean to support sysvinit, systemd and upstart from the point of view of udev (and other key packages). Could you enlighten me? What are the main problems to expect? Lucas signature.asc Description: Digital signature
systemd .service file conversion
On Tue, May 21, 2013 at 10:53:43PM +0200, Lucas Nussbaum wrote: There was a GSoC project in 2012 about generating sysvinit scripts from systemd .service files. Was there some communication about its outcome? I had a look at this idea and its result. From what I saw, I do not believe a conversion process to be successful in a big enough fraction of actual .service files. This is because systemd (and for that matter upstart should we consider a job file conversion as well) actually provide more functionality than sysv does. Some of that functionality does not properly map to an init script conversion. * stdout/stderr to syslog redirection This is possibly implementable, but needs more than a line of shell. * supervision/service restart/heartbeat sysv simply does not provide this functionality. Other tools are needed to mimic this. An option could be djb's daemontools. Still you either end up with some supervision process with similar tasks as systemd/upstart or have a supervision process per service. * missing dependencies Due to the use of socket activation it is to be expected that services stop declaring their dependencies. In .service files this information commonly is not present, because it is not needed. * socket activation cont'd I guess that at some point services will expect that their sockets are already open when they are started, because this eliminates a privileged bind() operation. * resource/privilege limitations Service files provide a mechanism to describe and limit the required privileges or resources. Some of these map to shell commands, others don't. Arguably this part is non-essential to a conversion process. You can already see parts of these in action in current .service files, but it is to be expected that there will be more usage of these and other features. Is it realistic to dream about a generator that would automate the generation of sysvinit scripts, systemd .service files, and upstart job files for a majority of our packages (the easy ones)? Based on the above arguments, I believe that a conversion process will not work out. (I note that I may be wrong here.) Talking just about systemd and sysvinit, there is the possibility to create a .service interpreter to let sysvinit execute systemd .services. upstart already has such an interpreter. The necessary hooks in sysvinit/insserv already exist and are easily extensible. I therefore suggest to drop the idea of generating shell scripts. Also consider the amount of work required to fix a bug in a conversion utility compared to an interpreter. Are we really gonna rebuild all services (that only ship a .service file)? From my point of view this raises the question of interoperability between systemd and upstart. Is a conversion in either direction feasible? Possibly systemd - upstart, because we already have the job interpreter? Helmut -- 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/20130522203904.ga7...@alf.mars
Bwaaaaah I will tell my daddy^W^Wthe CTTE^W^Wa GR
Le mercredi 22 mai 2013 à 21:27 +0200, Martin Wuertele a écrit : Seems like you haven't realised yet: only if a maintainer makes controversal decisions and several others disagree such a case comes before the CTTE. Having choices ending up twice within relatively short time before the CTTE should give the maintainer a hint. A hint of what? That some people will appeal to the CTTE regardless (or to a GR, like it was hinted several times in this thread already) because they feel entitled to tell others what to do and how they should do it? Because they know better what an operating system should be? I do not accept this kind of intellectual terrorism, where a handful of low-throughput contributors (when they contribute at all), who never even try to understand the issues at hand, keep on bitching and whining endlessly, unsatisfied until others abandon whatever they were trying to improve. This behavior is toxic to the project. It leads to sclerosis, killing any kind of momentum that can be built around a given direction. You don’t get to define what Debian is. It is fortunate that the CTTE thinks twice before answering to such requests; and in the case of NM, despite heated discussions, the result ended up satisfying for all involved parties – except of course for those who just can’t stand the idea that NM could be installed on a Debian computer, but it’s not as if those who really develop Debian really cared for them. kthxbye, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1369256701.13422.37.camel@tomoyo
Re: ITP: opensmtpd -- Simple Mail Transfer Protocol daemon
On Wed, May 22, 2013 at 09:13:18PM +0100, Daniel Walrond wrote: As per policy 10.9 - Permissions and owners[0], opensmtpd requires some system users for running non-root-privileged processes. I propose to user the following dynamic accounts; opensmtpd, opensmtpq, opensmtpf. Thanks for CCing me, which I assume was in my rôle as base-passwd maintainer. I only really need to be involved if you need static IDs for some reason, rather than the normally-preferred method of using dynamic IDs via 'adduser --system'. If so, please give a short explanation of why that's the case. Policy 10.9 does say to check even dynamic names with the base-passwd maintainer, and I congratulate you for being one of the very few developers to read it in close enough detail to notice that. ;-) That wording should perhaps be revised, as neither I nor (as far as I know) any of my predecessors have kept a registry of all dynamic names used in Debian, only of the IDs we've allocated from the static ranges 0-99 and 6-64999, so we aren't really in a position to perform a reliable check for name uniqueness. I'd normally just require that statically-allocated user/group names should be obviously derived either from your package name or, occasionally, from the name of one of the commands you ship, and that's generally good practice for dynamically-allocated names too. The names you suggest are close enough to your package name, and that package name is distinct enough, that I think there's very unlikely to be a clash and you should be fine. So, if all you need is dynamically-allocated IDs, then go ahead. Cheers, -- Colin Watson [cjwat...@debian.org] -- 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/20130522210821.gf5...@riva.ucam.org
Re: ITP: opensmtpd -- Simple Mail Transfer Protocol daemon
Daniel Walrond deb...@djw.org.uk writes: As per policy 10.9 - Permissions and owners[0], opensmtpd requires some system users for running non-root-privileged processes. I propose to user the following dynamic accounts; opensmtpd, opensmtpq, opensmtpf. Also I will be co-maintaining this package with Ryan Kavanagh, who has already done some work packaging opensmtpd. We currently have no good policy about how to name system users, but despite that I personally would recommend against using simple alphanumeric usernames like those. (They are longer than eight characters, which avoids some local namespaces, but not all.) There are two conventions that other packages have used to make it less likely that system accounts will conflict with local usernames: * Append Debian- to the username, as in Debian-opensmtpd * Append an underscore, as in _opensmtpd I personally mildly prefer the latter just because it's simple, although it isn't as informative or robust against any namespace issue. Note that you will have to pass --force-badname to adduser to let you use an underscore in the name. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87fvxeiukt@windlord.stanford.edu
Re: Debian systemd survey
On Wed, May 22, 2013 at 3:30 PM, Russ Allbery r...@debian.org wrote: Martin Wuertele m...@debian.org writes: Seems like you haven't realised yet: only if a maintainer makes controversal decisions and several others disagree such a case comes before the CTTE. Having decisions appealed to the CTTE is not a punishment. It just indicates that a decision is controversial and the project was unable to reach a consensus. It's not always possible (and indeed not always wise) to avoid controversial decisions. Having choices ending up twice within relatively short time before the CTTE should give the maintainer a hint. It is, for example, probably a hint that the maintainer is working on something important that a lot of people care deeply about and therefore have strong opinions about. Well said. -mz -- 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/caolfk3wxeoscjz06nkqg1qtompftkegp3sb05tz5onng5en...@mail.gmail.com
Re: ITP: opensmtpd -- Simple Mail Transfer Protocol daemon
On Wed, May 22, 2013 at 02:16:34PM -0700, Russ Allbery wrote: We currently have no good policy about how to name system users, but despite that I personally would recommend against using simple alphanumeric usernames like those. (They are longer than eight characters, which avoids some local namespaces, but not all.) I've never been a fan of worrying about this, largely because the names that are really a practical problem are mostly the ones that have been around forever and that we're stuck with (things like man could well be a real name; I have a co-worker whose initials are apparently SSH; people occasionally try to use things like staff; and so on), while most of the ones that have been introduced more recently, and certainly the longer and/or more elaborate ones, are likely to be innocuous. Pragmatically, I wouldn't be inclined to lose any sleep over the chances of somebody having a local username called opensmtpd that wasn't actually for a local installation of this very same package. And our user/group namespace is such that it really almost has to be handled pragmatically. There are two conventions that other packages have used to make it less likely that system accounts will conflict with local usernames: * Append Debian- to the username, as in Debian-opensmtpd This was used by Debian-exim and not a lot else that I ever heard of. In my view this scheme rightly failed; plenty of simple system monitoring tools (top, ps, and the like) truncate long usernames in many modes or turn them into UIDs, and sticking a seven-character prefix on the front just seems to be trying to maximise the probability of trouble like this, even though it is certainly clear. Cheers, -- Colin Watson [cjwat...@debian.org] -- 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/20130522215516.gg5...@riva.ucam.org
Re: Debian systemd survey
On Wed, May 22, 2013 at 07:45:32PM +0200, Josselin Mouette wrote: Le mercredi 22 mai 2013 à 09:41 -0700, Steve Langasek a écrit : On Wed, May 22, 2013 at 02:45:54PM +0200, Josselin Mouette wrote: When you compare the time it takes to write an upstart job file or a systemd unit file, to the time it takes to proprely test it, I don’t think this argument makes any sense. Please leave the FUD at the door. Writing upstart jobs is not difficult; while there are some gotchas currently with process lifecycle (which will be fixed soon), there is also very complete documentation (for these issues, and generally). In which way do you disagree with what I wrote, exactly? Maybe my English was wrong, so let me explain it in simple words. Time to write an upstart job = short Time to write a systemd unit file = short Time to test an upstart job = long Time to test a systemd unit file = long Therefore: How much we should care of existing upstart jobs = little How much we should care of existing systemd unit files = little I see - yes, I misunderstood your argument, and thought you were claiming that upstart jobs take longer to write and test. The above makes more sense. I do think that in the context of Debian, upstart has the upper hand in terms of the testing owing to the fact that Ubuntu, which is very similar to Debian, has already worked out most of the kinks. But I'd rather demonstrate this instead of spending time arguing it, so... If the only things we do for improving the distribution are to take stuff from Ubuntu because, well, it’s here, we might as well stop developing anything at all. Sure; obviously the right thing to do is to instead take stuff from GNOME and freedesktop.org without regard to integration with our existing system, because if Lennart says it's right it must be so. Yes of course, because Debian is well-known for using fd.o and GNOME software as is, without patching it ever, and adopting new technologies blindly and very quickly, before they are well tested. There certainly have been cases of fd.o changes being dropped into Debian without dealing with the integration questions. mime - .desktop is a prime example of this. .desktop is clearly far superior - but that doesn't mean it's ok to drop the existing stuff on the floor. So if your comment is a fair critique of upstart proponents, then mine is an equally fair critique of systemd proponents. Have it ever occurred to you that people might want to see systemd as default, not because Lennart said it, but because they think it is better than any alternative? Better than upstart *in the way it integrates with our existing system*, BTW. Oh, it absolutely has occurred to me. And has it occurred to you that the upstart proponents likewise feel that theirs is the better alternative? I'd be happy to hear you expand on how you think systemd integrates better with the existing system in Debian. I certainly don't see that this is the case - particularly when the systemd dbus services, which people have told me are so essential a component of the GNOME desktop going forward, had no tested backend that integrated with the Debian locations for system-level config files until I provided one for Ubuntu. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: systemd .service file conversion
On Wed, May 22, 2013 at 10:39:06PM +0200, Helmut Grohne wrote: On Tue, May 21, 2013 at 10:53:43PM +0200, Lucas Nussbaum wrote: There was a GSoC project in 2012 about generating sysvinit scripts from systemd .service files. Was there some communication about its outcome? I had a look at this idea and its result. From what I saw, I do not believe a conversion process to be successful in a big enough fraction of actual .service files. This is because systemd (and for that matter upstart should we consider a job file conversion as well) actually provide more functionality than sysv does. Some of that functionality does not properly map to an init script conversion. Note that such conversion to a sysv init script is not supposed to provide all the features that upstart and systemd provide. Else there would be no need to move to systemd or upstart in the first place. * stdout/stderr to syslog redirection This is possibly implementable, but needs more than a line of shell. Do you know about logger(1)? If that itself is not good enough, it should be easy enough to make something that does what you want. * missing dependencies Due to the use of socket activation it is to be expected that services stop declaring their dependencies. In .service files this information commonly is not present, because it is not needed. It's not because it's not needed that we can't add this. If we already have this information there is no need to throw it away. * socket activation cont'd I guess that at some point services will expect that their sockets are already open when they are started, because this eliminates a privileged bind() operation. That would just mean that those don't work at all with sysv anymore, and since I think we still have to support sysv, we should fix them. Based on the above arguments, I believe that a conversion process will not work out. (I note that I may be wrong here.) Talking just about systemd and sysvinit, there is the possibility to create a .service interpreter to let sysvinit execute systemd .services. upstart already has such an interpreter. The necessary hooks in sysvinit/insserv already exist and are easily extensible. I therefore suggest to drop the idea of generating shell scripts. Also consider the amount of work required to fix a bug in a conversion utility compared to an interpreter. Are we really gonna rebuild all services (that only ship a .service file)? I would argue that if such a conversion script would exist, we can probably have more consistent init script implementations, and less bugs in them. I'm also not sure why fixing a conversion script is that much work. Plsese note that I'm not saying that such a script is a good or bad thing, just that I don't follow your arguments. Kurt -- 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/2013054745.ga9...@roeckx.be
Re: Debian systemd survey
Matthias wrote: Am 22.05.2013 18:12 schrieb Lucas Nussbaum lu...@debian.org: Note that if it's there, and Ubuntu uses upstart, it has probably been tested. I was not suggesting that we blindly import upstart job files from Ubuntu, but a basis to start from is better than no basis at all. (I can see how my phrasing was a bit confusing -- sorry about that) Please also keep in mind that many upstream projects ship systemd service files. Therefore, most of the systemd work is already done too. Most? Really? Do you have stats for that? -- Steve McIntyre, Cambridge, UK.st...@einval.com It's actually quite entertaining to watch ag129 prop his foot up on the desk so he can get a better aim. [ seen in ucam.chat ] -- 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/e1ufib9-0007zz...@mail.einval.com
Re: blhc and hardening flags (was: Re: jessie release goals)
That reminds me. Is there a way to get blhc to tell me *which* line in a build log makes it think that compiler flags are hidden? I agree that would be really useful https://buildd.debian.org/~brlink/packages/r/remctl.html is reporting that the compiler flags are hidden. So far as I know, this is false, but this package builds Perl, PHP, Python, and Ruby extensions, and it's possible that one of those build systems is misconfigured. But I can't tell from this page which line it's upset about. Usually what I do is to copy the whole page and pass it through the blhc on my local system. In your case I get this message: NONVERBOSE BUILD: compiling remctl.c Your build logs include: make[4]: Entering directory `/build/buildd-remctl_3.4-2-amd64-evcdS_/remctl-3.4/ruby' compiling remctl.c linking shared-object remctl.so make[4]: Leaving directory `/build/buildd-remctl_3.4-2-amd64-evcdS_/remctl-3.4/ruby' Seems like a valid warning to me -- =Do- N.AND -- 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/cann5kou4h4b6o4tqfshetkwb7yvbtkjue-tdndt4lhym1-m...@mail.gmail.com
Re: blhc and hardening flags
Nick Andrik nick.and...@gmail.com writes: Usually what I do is to copy the whole page and pass it through the blhc on my local system. In your case I get this message: NONVERBOSE BUILD: compiling remctl.c Your build logs include: make[4]: Entering directory `/build/buildd-remctl_3.4-2-amd64-evcdS_/remctl-3.4/ruby' compiling remctl.c linking shared-object remctl.so make[4]: Leaving directory `/build/buildd-remctl_3.4-2-amd64-evcdS_/remctl-3.4/ruby' Seems like a valid warning to me Aha! Thank you. So it's the Ruby build system that's hiding the flags here. I'll take a deeper look and see if a bug against ruby1.9.1-dev is in order. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/8738tepm2j@windlord.stanford.edu
Re: Debian systemd survey
On 2013-05-22 15:39:00 +0200, Bernd Schubert wrote: On 05/22/2013 04:50 AM, Uoti Urpala wrote: Lucas Nussbaum wrote: I went through the various init systems threads again during the last few days. My understanding of the consensus so far is the following: - Both systemd and upstart bring many useful features, and are a clear improvement over sysvinit. Yes, both are an improvement over sysvinit. Hrmm, I have not tested systemd yet, but personally I'm not conviced about the advantages of upstart: - Stops booting *somtimes*, does not provide any information why. I didn't report a bug yet as an almost black screen won't help in any way how to figure out why it stopped. Already that stops without any further information why and where is a sufficiently big design issue, imho. (Btw, in the mean time I belive this issue is related to /etc/mtab, but I'm not sure yet.). Well, a frozen boot without much information can also occur with sysvinit (e.g. due to udev). For instance, I had the following problem in the past: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606192 -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20130523003328.ga4...@xvii.vinc17.org
Re: Debian systemd survey
* As you may know, systemd is developed by a large amount of contributors. …as you may know, upstart is not only older than systemd, but is also used on a large amount of live systems, probably many times more the number of systems that have systemd installed.*⁾ Best regards, – Jubal *) Ubuntu, chromebooks, Kindles, RHEL6 and Centos6. -- Don't you have a home to go to?
Re: Debian systemd survey
On 23/05/2013 02:35, John Paul Adrian Glaubitz wrote: Sure; obviously the right thing to do is to instead take stuff from GNOME and freedesktop.org without regard to integration with our existing system, because if Lennart says it's right it must be so. Honestly, these personal accusations against Lennart are getting old and boring. Don't you really have any other good argument to bring up against systemd other than you dislike *one* of the systemd developers?* I didn't see that as a personal accusation against Lennart really. It looked more like an attack on the sheeple who follow blindly what Lennart says, simply because he said it therefore it must be right. [...] Bazaar (which seems to have been abandoned by upstream with 2000 open bugs [1]) [...]. On the other hand, it would be nice if you keep your FUD to the minimum. Bazaar doesn't look abandoned[1], and 2000 open bugs is not uncommon. Nautilus and Rhythmbox themselves have 1000 open bugs each. [1] https://code.launchpad.net/bzr -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: Debian systemd survey
I really like how this paragraph: On 23/05/2013 02:41, John Paul Adrian Glaubitz wrote: [...] And another one. Why is it that almost anyone who isn't favor of systemd is directly going off insulting their developers or any of the organizations behind of it? and this paragraph: Blame Canonical for being a bad upstream, not RedHat for being a good one! appear in the same post. The irony is strong here. Let not the pot call the kettle black. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
bzr (was: Re: Debian systemd survey)
On 22 May 2013 22:02, Chow Loong Jin hyper...@debian.org wrote: [...] Bazaar (which seems to have been abandoned by upstream with 2000 open bugs [1]) [...]. On the other hand, it would be nice if you keep your FUD to the minimum. Bazaar doesn't look abandoned[1], and 2000 open bugs is not uncommon. Nautilus and Rhythmbox themselves have 1000 open bugs each. [1] https://code.launchpad.net/bzr Two commits this year? The only thing that makes it not completely abandoned by upstream is that occasionally there are a few maintenance bugfix commits done. For the record, I do use bzr (with http://jameswestby.net/bzr/builddeb/user_manual/merge.html ) in my normal Ubuntu/Debian packaging workflow. I haven't figured out how to git to work as nicely for that usecase yet. Jeremy Bicha -- 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/caaajcmzsv+wibph7dmoce2fq4d3cmtaqoe48axuogzw+6pd...@mail.gmail.com
Re: Debian systemd survey
On 05/22/2013 04:53 AM, Lucas Nussbaum wrote: - Neither systemd nor upstart are likely to be ported to kfreebsd soon, as they both rely on many Linux-specific features and interfaces. Though it should be easy enough to port OpenRC to kFreeBSD and Hurd, once it completes its support for the current init.d scripts. You completely forgot that option. The only thing that worries me is the cgroup thing, but probably it should be possible to fallback to .pid files in such case (in an automated way). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/519d9aff.6040...@debian.org
Re: Debian systemd survey
Steve McIntyre st...@einval.com writes: Matthias wrote: Please also keep in mind that many upstream projects ship systemd service files. Therefore, most of the systemd work is already done too. Most? Really? Do you have stats for that? Given the fact that sysvinit scripts are supported by systemd out-of-the-box, the basic work is already done. So why would you need any stats? I run all of my servers with the (ancient, by this time) systemd shipped with wheezy. There are exactly zero init scripts on my machines which don't work at all, and only one (collectd) does not properly delegate to systemd when invoked directly. -- -- Matthias Urlichs -- 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/loom.20130523t063402-...@post.gmane.org
Re: Debian systemd survey
On 05/23/2013 01:45 AM, Josselin Mouette wrote: I understand it will be a pain for Ubuntu if Debian picks a different init system. I don’t think this is relevant for the discussion, though. It might be very relevant for many of us that our package works on *both* Debian and Ubuntu (and other derivative, including those who derive from Ubuntu, like for example Mint) without too much modifications. Some of my packages already incorporate some upstart script for that reason. I do all of my work in Debian, though whenever possible, I am happy to see that my development fits the (140+, according to distro watch) Debian derivatives. And I don't think I am the only one thinking this way (in fact, I *know* many other DD / DM think this way). So yes, being friendly for our downstream is very relevant to this discussion (even though obviously, that isn't the only point). Thomas P.S: Please note that I'm not taking any side above. Just replying to your point that it isn't relevant, which I think is simply not right. -- 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/519da071.8080...@debian.org
Re: bzr (was: Re: Debian systemd survey)
On Wed, May 22, 2013 at 11:31 PM, Jeremy Bicha jbi...@ubuntu.com wrote: On 22 May 2013 22:02, Chow Loong Jin hyper...@debian.org wrote: [...] Bazaar (which seems to have been abandoned by upstream with 2000 open bugs [1]) [...]. On the other hand, it would be nice if you keep your FUD to the minimum. Bazaar doesn't look abandoned[1], and 2000 open bugs is not uncommon. Nautilus and Rhythmbox themselves have 1000 open bugs each. [1] https://code.launchpad.net/bzr Two commits this year? The only thing that makes it not completely abandoned by upstream is that occasionally there are a few maintenance bugfix commits done. While I can't imagine anything good coming from discussing VCS choices on debian-devel, I'll venture a reply... I wouldn't say that bazaar is completely dead, I just had a commit merged this week. Though AFAICT, Canonical no longer employs anyone to work on it directly, but it seems some number of bazaar hackers are still employed in other positions there. I have no idea what their long term plans are, but I'd imagine that Launchpad and Ubuntu will continue to be consumers of bazaar for the foreseeable future. No one has stepped up to drive development, and I do wish Canonical would make some sort of official statement about their intentions. There have been a number of interesting retrospectives from former bazaar core developers, for those that are interested: https://lists.ubuntu.com/archives/bazaar/2012q4/075330.html http://www.stationary-traveller.eu/pages/bzr-a-retrospective.html https://lists.ubuntu.com/archives/bazaar/2013q1/075475.html I've been the Debian maintainer for a number of bzr plugins for the past few years, and I've recently picked up the maintenance of the bzr package as well. For the record, I do use bzr (with http://jameswestby.net/bzr/builddeb/user_manual/merge.html ) in my normal Ubuntu/Debian packaging workflow. I haven't figured out how to git to work as nicely for that usecase yet. I'd encourage anyone who cares about this workflow and these packages to continue any further discussion of bazaar in Debian over on pkg-bazaar-maint. Thanks! -- Andrew Starr-Bochicchio Ubuntu Developer https://launchpad.net/~andrewsomething Debian Developer http://qa.debian.org/developer.php?login=asb PGP/GPG Key ID: D53FDCB1 -- 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/CAL6k_AyPVeSrTVW=9bysfxvdtp4b-prsczm5fymouzmpz8r...@mail.gmail.com
Re: Debian systemd survey
On 05/23/2013 02:35 AM, John Paul Adrian Glaubitz wrote: Honestly, these personal accusations against Lennart are getting old and boring. Don't you really have any other good argument to bring up against systemd other than you dislike *one* of the systemd developers?* [...] * As you may know, systemd is developed by a large amount of contributors. If you are tired of seeing the same arguments, don't post things which have already been debunked as well. You are doing the very same thing that you are complaining about: I already posted in this list the git log stats, and Lennart owns more than 40% of all the commits. So no, Lennart is not just *one* of the systemd developers, he's the main one, and by far. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/519da160.1040...@debian.org
Re: Debian systemd survey
On Thu, May 23, 2013 at 12:37:35AM +0100, Steve McIntyre wrote: Matthias wrote: Am 22.05.2013 18:12 schrieb Lucas Nussbaum lu...@debian.org: Note that if it's there, and Ubuntu uses upstart, it has probably been tested. I was not suggesting that we blindly import upstart job files from Ubuntu, but a basis to start from is better than no basis at all. (I can see how my phrasing was a bit confusing -- sorry about that) Please also keep in mind that many upstream projects ship systemd service files. Therefore, most of the systemd work is already done too. Most? Really? Do you have stats for that? While it's a lot of work to query artibrary upstream projects, it is pretty easy to query a distribution. Fedora is likely the most unit-file-endowed distribution out there. According to repoquery, 724 distinct binary rpms provide unit files in /usr/lib/systemd/system, in Fedora 19. I'd guess that the majority of those files will be usable by Debian, which usually packages more than Fedora. This number must be compared with 1094 packages with scripts in /etc/init.d (quoting Lucas Nussbaum from earlier in the thread here), and packages having inetd or xinetd files. I'm not sure if this comes out to a majority, but it probably fairly close. Zbyszek -- 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/20130523045301.ga28...@in.waw.pl
Re: systemd .service file conversion
On Thu, May 23, 2013 at 12:47:46AM +0200, Kurt Roeckx wrote: On Wed, May 22, 2013 at 10:39:06PM +0200, Helmut Grohne wrote: On Tue, May 21, 2013 at 10:53:43PM +0200, Lucas Nussbaum wrote: There was a GSoC project in 2012 about generating sysvinit scripts from systemd .service files. Was there some communication about its outcome? I had a look at this idea and its result. From what I saw, I do not believe a conversion process to be successful in a big enough fraction of actual .service files. This is because systemd (and for that matter upstart should we consider a job file conversion as well) actually provide more functionality than sysv does. Some of that functionality does not properly map to an init script conversion. Note that such conversion to a sysv init script is not supposed to provide all the features that upstart and systemd provide. Else there would be no need to move to systemd or upstart in the first place. * stdout/stderr to syslog redirection This is possibly implementable, but needs more than a line of shell. Do you know about logger(1)? If that itself is not good enough, it should be easy enough to make something that does what you want. * missing dependencies Due to the use of socket activation it is to be expected that services stop declaring their dependencies. In .service files this information commonly is not present, because it is not needed. It's not because it's not needed that we can't add this. If we already have this information there is no need to throw it away. At least in case of systemd files, providing this information is often unwanted. Ordering dependencies can be specified explictly using Before= and After=, but if socket activation is used, services can be started in parallel. If one of the services then attempts to query the other, it'll hang (the kernel queues the packet) until the other service starts processing requests. Declaring the dependency explicitly doesn't gain anything, and can add an unnecessary slowdown. It is just better to have the dependencies solved automagically, and adding explicit requirements for the sake of sysvinit conversions is unlikely to be met with much enthusiasm. * socket activation cont'd I guess that at some point services will expect that their sockets are already open when they are started, because this eliminates a privileged bind() operation. That would just mean that those don't work at all with sysv anymore, and since I think we still have to support sysv, we should fix them. Based on the above arguments, I believe that a conversion process will not work out. (I note that I may be wrong here.) Talking just about systemd and sysvinit, there is the possibility to create a .service interpreter to let sysvinit execute systemd .services. upstart already has such an interpreter. The necessary hooks in sysvinit/insserv already exist and are easily extensible. I therefore suggest to drop the idea of generating shell scripts. Also consider the amount of work required to fix a bug in a conversion utility compared to an interpreter. Are we really gonna rebuild all services (that only ship a .service file)? I would argue that if such a conversion script would exist, we can probably have more consistent init script implementations, and less bugs in them. I'm also not sure why fixing a conversion script is that much work. Providing a conversion script which recreates all of systemd functionality would basically mean reimplemting a big part of systemd in shell. Providing an interpeter would man reimplementing a big part of systemd in whatever the interpreter is written in. Both options seem infeasible, unless only partial functionality is supported. [1] lists e.g. SystemCallFilter=, PrivateTmp=, PrivateNetwork=, CapabilityBoundingSet=, SecuritBits= which have security and correctness implications, and are IMHO pretty hard to recreate. Zbyszek [1] http://www.freedesktop.org/software/systemd/man/systemd.exec.html#Options -- 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/20130523051618.gb28...@in.waw.pl
Re: Bwaaaaah I will tell my daddy^W^Wthe CTTE^W^Wa GR
Hello, On Wed, 22 May 2013 23:05:01 +0200 Josselin Mouette j...@debian.org wrote: Subject: Bwah I will tell my daddy^W^Wthe CTTE^W^Wa GR Couldn't you please finally stop behaving like a five years old? -- WBR, Andrew signature.asc Description: PGP signature
Accepted gtk-vnc 0.5.2-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 22 May 2013 07:49:19 +0200 Source: gtk-vnc Binary: libgvnc-1.0-0 libgvnc-1.0-0-dbg libgvnc-1.0-dev libgtk-vnc-1.0-0 libgtk-vnc-1.0-0-dbg libgtk-vnc-1.0-dev libgtk-vnc-2.0-0 libgtk-vnc-2.0-0-dbg libgtk-vnc-2.0-dev gir1.2-gtk-vnc-2.0 python-gtk-vnc gvncviewer Architecture: source i386 Version: 0.5.2-2 Distribution: unstable Urgency: low Maintainer: Debian Libvirt Maintainers pkg-libvirt-maintain...@lists.alioth.debian.org Changed-By: Guido Günther a...@sigxcpu.org Description: gir1.2-gtk-vnc-2.0 - GObject introspection data for GTK-VNC. gvncviewer - VNC viewer using gtk-vnc libgtk-vnc-1.0-0 - VNC viewer widget for GTK+2 (runtime libraries) libgtk-vnc-1.0-0-dbg - VNC viewer widget for GTK+2 (debugging symbols) libgtk-vnc-1.0-dev - VNC viewer widget for GTK+2 (development files) libgtk-vnc-2.0-0 - VNC viewer widget for GTK+3 (runtime libraries) libgtk-vnc-2.0-0-dbg - VNC viewer widget for GTK+3 (debugging symbols) libgtk-vnc-2.0-dev - VNC viewer widget for GTK+3 (development files) libgvnc-1.0-0 - VNC gobject wrapper (runtime libraries) libgvnc-1.0-0-dbg - VNC gobject wrapper (debugging symbols) libgvnc-1.0-dev - VNC GObject wrapper (development files) python-gtk-vnc - VNC viewer widget for GTK+2 (Python binding) Closes: 675645 709166 Changes: gtk-vnc (0.5.2-2) unstable; urgency=low . * [c792964] Switch to Vala 0.20 (Closes: #709166, #675645) Checksums-Sha1: e94ae0302c07232be0605bed53fc578cd9aedf49 2233 gtk-vnc_0.5.2-2.dsc 632e20c05d8f9ff24319c05e3be8c6dff7b7c442 11713 gtk-vnc_0.5.2-2.debian.tar.gz fd280f288f0909f545f942e7a9ddf1f802aacb3b 68984 libgvnc-1.0-0_0.5.2-2_i386.deb 22a5a1bcbe9c232b088368b0739a56aa8b8c5672 158542 libgvnc-1.0-0-dbg_0.5.2-2_i386.deb a44609306e436e0628a1700dbd4fc2210fe60e71 24348 libgvnc-1.0-dev_0.5.2-2_i386.deb 005957045f17f48ae480b71588249c44000f6b17 33998 libgtk-vnc-1.0-0_0.5.2-2_i386.deb e2383fff6231adb8c702f9ed85e163746ea61dcf 81918 libgtk-vnc-1.0-0-dbg_0.5.2-2_i386.deb 18157341c252fe90aaa8de99b1c13a98fe62631a 10846 libgtk-vnc-1.0-dev_0.5.2-2_i386.deb 055ed5d205e15279ff2948a5cc99c8a73f649da3 33008 libgtk-vnc-2.0-0_0.5.2-2_i386.deb fce835c461d02ffd5f9bd5e2d71eb1333ce50be5 74472 libgtk-vnc-2.0-0-dbg_0.5.2-2_i386.deb 8ebf572da659e6995e60ed2a3920e3bf0389a991 16436 libgtk-vnc-2.0-dev_0.5.2-2_i386.deb fd8c6bdc343c79418420c14fc275d3e295d0ea43 17106 gir1.2-gtk-vnc-2.0_0.5.2-2_i386.deb 7fd706207f762479e95d88d4ddebdeef62a01ca0 16000 python-gtk-vnc_0.5.2-2_i386.deb 8a7df1fe6c66ac6a5c9307225804201b77254d12 22316 gvncviewer_0.5.2-2_i386.deb Checksums-Sha256: c84d6bf42fd174e1311db9111864e3f7a7ad85a57bac8e4fad9811fec5e7412c 2233 gtk-vnc_0.5.2-2.dsc 9d6b1ed75c53e62ecfa4d7dec4a0b9e4224a7305257866f19106cb43eebf93e7 11713 gtk-vnc_0.5.2-2.debian.tar.gz 20e84603cfa90f913d92ce763c1044ab24f06fe944e0a1f4b33c517a3eef4fbc 68984 libgvnc-1.0-0_0.5.2-2_i386.deb 82430a7af16a57914ace471548f96856f8213a4ba5c5b853ba250d151b5fd693 158542 libgvnc-1.0-0-dbg_0.5.2-2_i386.deb 7a02dc8171b911154330cacbd304ab458a56b9ccfd80341349ab38943cac1cce 24348 libgvnc-1.0-dev_0.5.2-2_i386.deb a437aac39a591542b54fea84c1bbf64ce3c5b0d97c847c45fec5f1bb9d017eee 33998 libgtk-vnc-1.0-0_0.5.2-2_i386.deb e13fcb524d806d141395b7aeb56ba1f526456c95aecddded1209ecb86ddef647 81918 libgtk-vnc-1.0-0-dbg_0.5.2-2_i386.deb c4c79b2956a6a1ca16215773cbbd2edad447ec742fc9793dc64bf103ef90931c 10846 libgtk-vnc-1.0-dev_0.5.2-2_i386.deb 29955cafed182803aa78e02a52b513e81018d6ead76f39df8ddcefa34e2feab4 33008 libgtk-vnc-2.0-0_0.5.2-2_i386.deb 82bf7c35514cfa0f8666923ea9855b2b763f9f7853b3d3ed578a3e770b49ddd5 74472 libgtk-vnc-2.0-0-dbg_0.5.2-2_i386.deb a6a92d57705bb91f1cf99f83e6c3223c603c053a7ab7c5f03a722a94b98b6646 16436 libgtk-vnc-2.0-dev_0.5.2-2_i386.deb cf8d72568a03b06cd2a795fe56138912a202dda9d3bb0c51752b20969f96ddb6 17106 gir1.2-gtk-vnc-2.0_0.5.2-2_i386.deb ff2ae891697cfbab4c3c132c49b2d221199f41c0690746b0e25e1c49491e8eae 16000 python-gtk-vnc_0.5.2-2_i386.deb f0ea4d1ee9878065372060a1df0e5722d705bf56ec103fe899363ac923ad098c 22316 gvncviewer_0.5.2-2_i386.deb Files: 9ab97ee65b0da94a27dc64e503e7a365 2233 gnome optional gtk-vnc_0.5.2-2.dsc 9f1fceeaac1da5038f00039228be7acf 11713 gnome optional gtk-vnc_0.5.2-2.debian.tar.gz 9888d6249343ab3c8cc8d1c70088 68984 libs optional libgvnc-1.0-0_0.5.2-2_i386.deb 7257305d777e391d90dd9c702fbe0ca2 158542 debug extra libgvnc-1.0-0-dbg_0.5.2-2_i386.deb 00c5f044531bfdced2d6ac7d0c96a432 24348 libdevel optional libgvnc-1.0-dev_0.5.2-2_i386.deb 4e9d447d4fc2ca19097bd6126a575fa3 33998 libs optional libgtk-vnc-1.0-0_0.5.2-2_i386.deb 71d2cbede530b1d6224ae77e4cc123be 81918 debug extra libgtk-vnc-1.0-0-dbg_0.5.2-2_i386.deb 6475bfe9484e1589ffa42ffa7193c283 10846 libdevel optional libgtk-vnc-1.0-dev_0.5.2-2_i386.deb 1b17ac1a45f40c73bd033ae47624ed1a 33008 libs optional libgtk-vnc-2.0-0_0.5.2-2_i386.deb 4ff869689269ea8c35b2a94ae2052dbe 74472 debug extra
Accepted xfburn 0.4.3-6 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 22 May 2013 07:42:04 +0200 Source: xfburn Binary: xfburn Architecture: source amd64 Version: 0.4.3-6 Distribution: unstable Urgency: low Maintainer: Debian Xfce Maintainers pkg-xfce-de...@lists.alioth.debian.org Changed-By: Lionel Le Folgoc mrpo...@gmail.com Description: xfburn - CD-burner application for Xfce Desktop Environment Changes: xfburn (0.4.3-6) unstable; urgency=low . [ Lionel Le Folgoc ] * debian/patches: - 03_fix-missing-include.patch: added, fix FTBFS with recent glib and libxfce4util versions. . [ Yves-Alexis Perez ] * debian/rules: - enable all hardening flags. * debian/control: - update standards version to 3.9.3. Checksums-Sha1: a76ebde1eac99a40fd16ac9b2fa56dc8433ddaea 1814 xfburn_0.4.3-6.dsc d0eda9f0af1d9e5c5dec3cf4e0b899952a090f33 32279 xfburn_0.4.3-6.debian.tar.gz 33510307e3cadd7a6796dd3b27f6056358f6795e 463428 xfburn_0.4.3-6_amd64.deb Checksums-Sha256: 37da8031e14803e7c9c92da87c033e6f640d54d8c309aa71e4442a8f9dce5d37 1814 xfburn_0.4.3-6.dsc b46bd7c0531684f63c7d6b91a571ee2e24f3e75102c1bed0491a399e736cef00 32279 xfburn_0.4.3-6.debian.tar.gz 72319a43515a99c531fb9f5fed4dfd71ee38628e71c2db6e31ff9a838f1e8b4c 463428 xfburn_0.4.3-6_amd64.deb Files: 80a114db136f337c999bb4fc603e7415 1814 xfce optional xfburn_0.4.3-6.dsc 64a67ca54dff446c5bb8f553a51f9194 32279 xfce optional xfburn_0.4.3-6.debian.tar.gz d98b4e049bcd8e0d2574ad4aa28b5a6e 463428 xfce optional xfburn_0.4.3-6_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCgAGBQJRnFunAAoJEG3bU/KmdcClpxsH+gOd5B2JRwPog2HJ6kKSlaU+ EuMOtP96qgC6r7xRMaIdE8vm3uomZzZTvFbdjL3VFTYO0FOSmbvKmYvtc4gn0dxv CJA7omKpbqdToV7xAeko2hBwxeVH7eQ9vL1KDwxXqB4GeIfK7HXnWHcek7SUWpc7 D5S0NA7pEfdYpDMT7PWYLKXvUxO/qxQ4qRIoJIzo/q/53SLFmp6GJ5fN1yKYSmn7 BS4qLLF0io/yPbTjXgvXwr+HvJJRamqLKCBNClYCO4TdxZTOm4mEihObp7QMGHfw CWrrDMV8WX310H1G6dJTagnweju9LFXZL5w8D9S6dzWMYiM0lB1H0ll6r4ul51Q= =V6wR -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/e1uf28y-0002eq...@franck.debian.org
Accepted xfce4-cpugraph-plugin 1.0.5-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 22 May 2013 07:55:04 +0200 Source: xfce4-cpugraph-plugin Binary: xfce4-cpugraph-plugin Architecture: source amd64 Version: 1.0.5-1 Distribution: unstable Urgency: low Maintainer: Debian Xfce Maintainers pkg-xfce-de...@lists.alioth.debian.org Changed-By: Lionel Le Folgoc mrpo...@gmail.com Description: xfce4-cpugraph-plugin - CPU load graph plugin for the Xfce4 panel Changes: xfce4-cpugraph-plugin (1.0.5-1) unstable; urgency=low . [ Lionel Le Folgoc ] * New upstream release. * debian/patches: - 0001-Revert-set-bars-orientation-to-opposite-of-panel-ori dropped, included upstream. . [ Yves-Alexis Perez ] * debian/rules: - enable all hardening flags. Checksums-Sha1: e0d9526b4e6a7e6d00d69eb1ea5e2b7cf38ca6ff 1839 xfce4-cpugraph-plugin_1.0.5-1.dsc 6286bcb91eb88a77e7d8965e80c0999a03afc2ae 328972 xfce4-cpugraph-plugin_1.0.5.orig.tar.bz2 bcb069612dc9a3e222166607a68d4674bf735365 3255 xfce4-cpugraph-plugin_1.0.5-1.debian.tar.gz 70e98ad1bd255ed13c155e7587ae5fa67d8a489e 83724 xfce4-cpugraph-plugin_1.0.5-1_amd64.deb Checksums-Sha256: 732a544cdca3ad8f52cc2fa107955434550aecf3742036e4f9c3343d5590be78 1839 xfce4-cpugraph-plugin_1.0.5-1.dsc 85da0ec89aacfd31e0bbafcefea37cdca618d62e681c1c9da8bdd492f028f4c7 328972 xfce4-cpugraph-plugin_1.0.5.orig.tar.bz2 21bae1fd46433c9a06d30c8392b06144ca75e7c5760a64596b477351fe305ae2 3255 xfce4-cpugraph-plugin_1.0.5-1.debian.tar.gz fd9d458bffb3b22a50785b74fc166141a4ccc20193a7d311511b59feaf96c751 83724 xfce4-cpugraph-plugin_1.0.5-1_amd64.deb Files: e631962b4747e1f7d854ab4435210423 1839 xfce optional xfce4-cpugraph-plugin_1.0.5-1.dsc f0ebfabb273adf69361b37a3fa4b7912 328972 xfce optional xfce4-cpugraph-plugin_1.0.5.orig.tar.bz2 7e134a34e65a1c70228f6890ad837336 3255 xfce optional xfce4-cpugraph-plugin_1.0.5-1.debian.tar.gz b2a6f98f1f226bc9e5c1d83f36f1a76e 83724 xfce optional xfce4-cpugraph-plugin_1.0.5-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCgAGBQJRnGE7AAoJEG3bU/KmdcClqgYH/0BIGr/ceAAhNfVLwjUNI6Tv XI4OgZkaAiHoC4qPYjjre3BMm1NVKliqHy1/UanzO7KAxsJqNl+KQooKzoTRJjXR O1o1tF2QlEAAVpd0bF6juihy0d02H8/T0c/zVKOl2i3AyacVje5UJBFsrAy76ZEU tf0zc5Fn2hCiB+nJbKePQvKiyfvsk2+k4PguM5Q7RFi0cUGvD6pzOy/4DZsefGll QnSDWJBHRAniW1OT3VBWX4/4LJs+zT+0CcLur/LG1eIqExTYQpxoNDDQmWSmol8U 56DjcXNPuUyQhCaFrnlBarz9iiLyzoNXefMzA/m/pbrLgWNpHR/4XQsnHjD0T1o= =jgWk -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/e1uf2mz-0005r6...@franck.debian.org
Accepted xfce4-systemload-plugin 1.1.1-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 22 May 2013 08:42:32 +0200 Source: xfce4-systemload-plugin Binary: xfce4-systemload-plugin Architecture: source amd64 Version: 1.1.1-2 Distribution: unstable Urgency: low Maintainer: Debian Xfce Maintainers pkg-xfce-de...@lists.alioth.debian.org Changed-By: Lionel Le Folgoc mrpo...@gmail.com Description: xfce4-systemload-plugin - system load monitor plugin for the Xfce4 panel Changes: xfce4-systemload-plugin (1.1.1-2) unstable; urgency=low . [ Lionel Le Folgoc ] * debian/control: - build-dep on libupower-glib-dev and recommend upower to enable the power saving feature. - add myself to Uploaders. . [ Yves-Alexis Perez ] * debian/rules: - enable all hardening flags. Checksums-Sha1: 9c981e69b35ffd663c1458afb37ca64363901a52 1916 xfce4-systemload-plugin_1.1.1-2.dsc 524ac8f22ca66d3b5eb9337d06bd8b543d082d16 3905 xfce4-systemload-plugin_1.1.1-2.debian.tar.gz 06965c0e1cf7d0f6eefd4496088c27a923b8 61018 xfce4-systemload-plugin_1.1.1-2_amd64.deb Checksums-Sha256: d9cd9a90eedac72709f62591d93f0286bb14ab274a8d91839dee02c45bedd744 1916 xfce4-systemload-plugin_1.1.1-2.dsc 7bf46d71652b63237217a271ebea245446a5854d0f5f8843ed2f4c3dd8318a29 3905 xfce4-systemload-plugin_1.1.1-2.debian.tar.gz 1839f130ee95acad27f273ccdc5ebfc1e9b7eae3d70746ce900890a59caefeae 61018 xfce4-systemload-plugin_1.1.1-2_amd64.deb Files: 0665393a09711bd86cef379cdc30854b 1916 xfce optional xfce4-systemload-plugin_1.1.1-2.dsc f3d73e81d6ba561c0782f01ca162f8ab 3905 xfce optional xfce4-systemload-plugin_1.1.1-2.debian.tar.gz 25a21c951830a1c5c4b148cc521009cf 61018 xfce optional xfce4-systemload-plugin_1.1.1-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCgAGBQJRnGlJAAoJEG3bU/KmdcClX3gH/0DZArt3I58gEzwUh70GTSUZ ie2pzjqTHUYLgV+DBmPMAM0aqkjZSOEvaXijfV2yi5af0Da+exuX6isnupX06UkN KlJ8vCzggzl/I/JbCXGbDVcid5JBOLL5io+3CfdL19113HqODuh1cvpK71lqYvPH LKMapvKlIA9f+CWKuLmvkw8Hu5COwW7MtXjLt8euSqaylu8m+MivFwQP9JTGq6/h uBFUvfFTOX2SkGKMdz5ocBLxwSaHmv3CCSM0kc0PCQ8ZfUFQudK7PSwrcLTFRk48 lLmrdfOVRY04dAdhwL/u5MYtnxtimYvBTxXekj9gobipziz38P64CdOxBqxq+0c= =ngkq -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/e1uf2qg-0003c7...@franck.debian.org
Accepted openssl 1.0.1e-3 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 20 May 2013 16:56:06 +0200 Source: openssl Binary: openssl libssl1.0.0 libcrypto1.0.0-udeb libssl-dev libssl-doc libssl1.0.0-dbg Architecture: source all amd64 Version: 1.0.1e-3 Distribution: unstable Urgency: low Maintainer: Debian OpenSSL Team pkg-openssl-de...@lists.alioth.debian.org Changed-By: Kurt Roeckx k...@roeckx.be Description: libcrypto1.0.0-udeb - crypto shared library - udeb (udeb) libssl-dev - SSL development libraries, header files and documentation libssl-doc - SSL development documentation documentation libssl1.0.0 - SSL shared libraries libssl1.0.0-dbg - Symbol tables for libssl and libcrypto openssl- Secure Socket Layer (SSL) binary and related cryptographic tools Closes: 658162 660971 676533 689093 698406 698447 Changes: openssl (1.0.1e-3) unstable; urgency=low . * Move openssl/opensslconf.h to /usr/include/$(DEB_HOST_MULTIARCH), and mark libssl-dev Multi-Arch: same. Patch by Colin Watson cjwat...@ubuntu.com (Closes: #689093) * Add Polish translation (Closes: #658162) * Add Turkish translation (Closes: #660971) * Enable assembler for the arm targets, and remove armeb. Patch by Riku Voipio riku.voi...@iki.fi (Closes: #676533) * Add support for x32 (Closes: #698406) * enable ec_nistp_64_gcc_128 on *-amd64 (Closes: #698447) Checksums-Sha1: 0cdd5e853a2d3080f8f03966d758acc8b354ee25 2200 openssl_1.0.1e-3.dsc 4194c26c6370ab305b38fa730fda07e2f005768b 9 openssl_1.0.1e-3.debian.tar.gz 00199638060866b67cfb21920b450d160a82bf56 1200462 libssl-doc_1.0.1e-3_all.deb 40a75de42f2d617bf23929f74874c361192a0eb8 696412 openssl_1.0.1e-3_amd64.deb e825fbeda27a9e4053af6ae1f4779ccd01f0188b 1242452 libssl1.0.0_1.0.1e-3_amd64.deb 98458be75200132129cc7a5cb80f283f30e04e82 625330 libcrypto1.0.0-udeb_1.0.1e-3_amd64.udeb 14798f4836c20008fde00d667c5663d5293ac415 1749248 libssl-dev_1.0.1e-3_amd64.deb cf364abda5750d682f88df654d99f54ecf214027 3073402 libssl1.0.0-dbg_1.0.1e-3_amd64.deb Checksums-Sha256: 1d4fd2b5aff62b3e67eec9ef6f0c235954a6436799211d231a4064b0c8dee457 2200 openssl_1.0.1e-3.dsc 1af8a464a6e07f0208161afeec5ec097a1c47243ffe8ca205c1d9bcbc8ac 9 openssl_1.0.1e-3.debian.tar.gz f6d492f560bd276c63f473965bf23620bc31edafc6d2336cbf1fafba93637c51 1200462 libssl-doc_1.0.1e-3_all.deb 339827d7162879b830abec3fca90fd15c3c62c59fa56d412cf71343bc41b 696412 openssl_1.0.1e-3_amd64.deb 7832269362e5d75b0ebfa48a8aa63dadd8a98bc3e200eba895ba34f2b31e222e 1242452 libssl1.0.0_1.0.1e-3_amd64.deb 7a0864676862dbcd69084fc458cff418c2921fef4470c9cf30a09c4bedc336a0 625330 libcrypto1.0.0-udeb_1.0.1e-3_amd64.udeb c302b692720a13a08290b1c5bb6cc94ce61d88966dbdb863463df6c875fe49af 1749248 libssl-dev_1.0.1e-3_amd64.deb 9b50fccdd23680198045ef068c0e33818b7aea7faac0800ad45b13204b23a11d 3073402 libssl1.0.0-dbg_1.0.1e-3_amd64.deb Files: b995f84e656da15c7cb6a7fbb2c48d37 2200 utils optional openssl_1.0.1e-3.dsc bf38683294e419f12420a57f54cd0211 9 utils optional openssl_1.0.1e-3.debian.tar.gz d14329a792122ed4e16d78d3912b 1200462 doc optional libssl-doc_1.0.1e-3_all.deb 368e4ce4f5722e1d77fe7a6648733173 696412 utils optional openssl_1.0.1e-3_amd64.deb d91ba356484ddbf2fef227a578c19864 1242452 libs important libssl1.0.0_1.0.1e-3_amd64.deb 2f3d40c71e8859648ed208541be06a8e 625330 debian-installer optional libcrypto1.0.0-udeb_1.0.1e-3_amd64.udeb 22fcaece815ab3b1b84ace8311259781 1749248 libdevel optional libssl-dev_1.0.1e-3_amd64.deb 8ad1e3b20627f30fcc07a58a8f7fc5d4 3073402 debug extra libssl1.0.0-dbg_1.0.1e-3_amd64.deb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJRnGnMAAoJEKGfLDAaVSLd10QQAIDy4HfPGxaPOvy2ktiHoN/u /BLzKaxnQtw3Exu+RFZR1HtxC0PlASjPc+/zUiNNZKj2KnjALG3zRm9He+cASdpL RlhyCeULd0+GiUw9KE7Ibc7z4WuD6ysEahT4vZntbMNMIDCDY07mBqH/tqag3uBW ap5gBBcsz7cm/JEqixqB8FLsasLJOItLzTnfxW3213xX5NAbAP+HoegbeItaXDLr bcBgLJh8feOOYlOEOWJBwISwR3Z8uaMtTNYsBo6JTWZ9u5QarWOHLxWoZzMKFqxX a0KXlctRV2zt9ZwFPvkSwPn0k5aHVSyIMlurBrtk+9KwlQ8oiD31nek12zbNU5b9 +8OkPYukt4yf9kUrBx/i8sIDAD2dJ+OYoeFABgKgckvzAM/Ze5Y8QbXHf/z0h+hq aHnTEeTUcyeLD8fX1oKXf8XAk3ohtFSpRIC8FDofI8fQM5Ww8SAvR7g16wMBlSM3 WNnRiMtqcvDXCCFdolBtY4umnommm0jzs8SQO5XCE/2GCPBPqyBRRwxsRj/eL6ZI CIAO1BecEcS0Q1NDZpT3IkzZwaO05u3JN+AaExdh94cL3I0FHBYlv+6DorUvxCHc rTRYX+BOkNz0agXQq5t1Tnb86jSgO07nJqVlxAaCYlqweOVlkz9qCeJn/vE+1UQE r6f7dCJaud/vfUMOsJ3r =cjky -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/e1uf34n-0006mo...@franck.debian.org
Accepted libtwin 13.05.03.15.06-g287d16c-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 19 May 2013 10:25:15 +0800 Source: libtwin Binary: libtwin-dev libtwin0 Architecture: source i386 Version: 13.05.03.15.06-g287d16c-1 Distribution: unstable Urgency: low Maintainer: Geoff Levand ge...@infradead.org Changed-By: Geoff Levand ge...@infradead.org Description: libtwin-dev - tiny window system (development files) libtwin0 - tiny window system (library) Changes: libtwin (13.05.03.15.06-g287d16c-1) unstable; urgency=low . * debian/compat: Update 8 - 9. * debian/control: Set debhelper (= 9). Update standards version to 3.9.4. Update Homepage, Vcs-Git, Vcs-Browser. Add Multi-Arch, Pre-Depends. * debian/copyright: Update Source. Add Copyright for new libtwin files. * debian/*.install: Update for multiarch. * debian/rules: Change from DEB_HOST_ARCH to DEB_HOST_ARCH_CPU. * libtwin: Update to latest release (13.05.03.15.06-g287d16c). Adds touch screen support. Checksums-Sha1: a93ea8a141c751fea01f34f2eb4903e659330051 2121 libtwin_13.05.03.15.06-g287d16c-1.dsc 6b9900f3ddaa8659eae98ef2ede3806cee32d150 464699 libtwin_13.05.03.15.06-g287d16c.orig.tar.gz 017417e1a21efdc75245d67093fc215b9dd7a46f 4453 libtwin_13.05.03.15.06-g287d16c-1.debian.tar.gz abf03022a2c8f245496aefb43e1a0350879f96c7 22678 libtwin-dev_13.05.03.15.06-g287d16c-1_i386.deb 14d45155f26c4d329aeabcf3dbd81ac0b28cb0db 72246 libtwin0_13.05.03.15.06-g287d16c-1_i386.deb Checksums-Sha256: 3c48b9ee718e2eefb688ca327a8db8c41f519f37df7f234425a13e03d188deff 2121 libtwin_13.05.03.15.06-g287d16c-1.dsc 3ba25ce801313153119b7e507e38aabd5a478e62e058f06a1f7975b87a112e8f 464699 libtwin_13.05.03.15.06-g287d16c.orig.tar.gz 5e49fe64d3c88c0279ad05e16ed65c29e7a33ef4055034c00a4373663e8ffe84 4453 libtwin_13.05.03.15.06-g287d16c-1.debian.tar.gz 960e1c2ea6f6af54edb512151c7f1a61a8e6504add744c96ffa7c836065f548f 22678 libtwin-dev_13.05.03.15.06-g287d16c-1_i386.deb 00c87d8762646b567133bd88b22f9caeec506d3d54f611d201b963ed360c5574 72246 libtwin0_13.05.03.15.06-g287d16c-1_i386.deb Files: 56f6f5cd6d29677c681e8ec04c777e7e 2121 libs optional libtwin_13.05.03.15.06-g287d16c-1.dsc aad4c470fb01265d2ac61f6c3ff64802 464699 libs optional libtwin_13.05.03.15.06-g287d16c.orig.tar.gz 16803394306284a914a5017b1a4fe3c6 4453 libs optional libtwin_13.05.03.15.06-g287d16c-1.debian.tar.gz 61de9a35a81ec0d0e612a469b27c62c1 22678 libdevel optional libtwin-dev_13.05.03.15.06-g287d16c-1_i386.deb bc63c60bba217a0d04b27f036f723e29 72246 libs optional libtwin0_13.05.03.15.06-g287d16c-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJRnHFQAAoJEPgLgUbQQog2H1AP/Ri6+HeZdKK52kT041TzcuP8 I4zVnlZUGZ1QWPiwUzMIu6r4aMQcKEeng8iNUl9h0ISRILNy1PiJGfOF9Wq7UY6a GqzGwrV1PhFwRQu5gcxRdLg+lxBa2IP11hgCdhTqg9ZRJZpNofwYlpoPEbQ5EB1F m+sDA61oa6AG7S2wKaW31U1CD9DFwVhkjGs1g2yJCWhFP7AmP5WA7mXO93E34XFP sUVXyvjw+li9u7T6PTpFPPcPji7IdUsdtdnzc90/rFqUK2nJo3j/MMwml3fIB7Ld vTUOaMOoXyqGyz5/osSH4bo3H38weC+TBEEqNxPuNYKxgow9pKoCLC1XVJTHM/4X 8/47C71I/arPmXbhE05N5xb+RrwupGtsZtvjg7Uy1WgTTGVR4MBeVgekFqXhC1m4 e26GvlH/eknIPFfzU25z8E+ZTiwCpoUzLFmahLaJMTiM/+p+Oe6FtWjccuOPViDP FxCv8PWTmW0ihq/xOW7BGW2KxiOI9qHNIlJMcUigzomNAf9vft5vuGefY6cuq9eB y/AQWCd0IcKmPjo7NAwhsRvjYj9EJ6nv4FTLaBUxwlJ/xGw0JrxnQDk9GY9W9vh9 KkptJxFer/CADUxB59tU0NrwTuq8C8r8U/pxZyalWV0xhQnp/S8BCGM6Hw+cwRpZ CkaQ7CVwZqfN/9y3GZ7c =lY+T -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/e1uf3y1-0004nn...@franck.debian.org
