Re: etc-overrides-non-etc configuration file model [Re: RFC: OpenRC as Init System for Debian]
Don Armstrong d...@debian.org writes: On Thu, 10 May 2012, Gergely Nagy wrote: FWIW, /etc/default/* and /etc/$package/conf.d/* and similar already do something *very* close to what etc-overrides-non-etc does. To the point that changing a file under /etc/default, or adding a snippet to conf.d/ can break just as well when the underlying default changes as if that upstream happened to be outside of /etc. That's true. I suspect that much of conf.d/* and default/* are a consequence of the lack of easy 3-way merge support in dpkg. But that's kind of an orthogonal issue. I don't think that is so. It's also there to allow other packages to drop snippets there. Modifying another package's conffile would be against the policy, so conf.d/-style snippets are the obvious solution. Nothing to do with the lack of merge in this case. Even if dpkg gains fabulous merge support that never fails, ever, conf.d/ will still be used because we need the ability to add snippets from unrelated packages. Except it's easier to follow, since the default is never modified by the admin, while if it's in /etc too, like in plenty of cases in the archive, both can change, and we end up with even scarier situations that can't be resolved sanely. I'm unable to follow. In the etc-overrides-non-etc case, we would be increasing the number of cases where we had copies in /etc and in non-etc. If things were just in /etc, they wouldn't be in non-etc, and you'd only have one copy in all cases. True, if the non-etc stuff were simply copied, we'd have a single copy. With all the disadvantages that brings, like not being able to override the default from another package, as that would mean we have to modify a configuration file. In the case of systemd, you need to be able to override the default from another, unrelated package. At least for things like the syslog service. At the moment, systemd has /lib/systemd/system/syslog.service, which starts the journal. If I want to override that, I need to override the syslog.service, which is done by placing a file in /etc/systemd/system/syslog.service (whether a symlink, or a file, doesn't matter; the syslog daemons in debian place a symlink). If we didn't have etc-overrides-lib, how would you do this? How would you make it able to override a single service, from another package? Play dpkg-divert tricks? Or use conf.d/-style stuff? The latter suffers from the same issue etc-overrides-non-etc suffers from, the former makes it much harder for admins to override services, and I don't like the idea of dpkg-divert'ing config files all over the place either.. -- |8] -- 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/873977s1lq@luthien.mhp
Re: mass bug filing: debcheckout fails
On 2012-04-24 18:22, Ansgar Burchardt wrote: | | I noticed you started to file bugs for non-working debcheckouts. Was | this discussed anywhere as suggested by the developer's reference[1]? Hi Ansgar, There are only handful of packages that mistakenly have their Vcs-* headers set up incorrectly so a minor bug reports and corrective instructions were sent. In this regard I dind't consider it worthy of mass bug filing process although it may have been in place. | imagine a new lintian check could also achieve. Correct. The problem is that Lintian's returned severity level does not adequately correspond to the problem level this error is causing. Many package maintainers don't even see the Lintian warnings if they don't crank up the reporting levels. I've asked Lintian maintainer to reconsider the severity of the Vcs header check. This particular case directly affects usability because every debcheckout command fails for all non-members that don't have development access to Vcs repositories. A minor bug report serves as a reminder to make maintainers aware of the problem and to consider including a fix in future uploads. Jari | [1] http://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#submit-many-bugs -- 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/20120511055436.gi13...@taiko.cante.net
Re: RFC: OpenRC as Init System for Debian
]] Uoti Urpala Hi, Wrong: as mentioned in this thread before, one of the advantages of the etc-overrides-lib model is the option of having a file in /etc that first includes the one in /lib, then overrides just one particular value. This allows handling more updates without needing manual changes, as you can automatically pick up other updated values while keeping the override, without needing to do 3-way merges. This doesn't always work, though. For instance, for systemd, you'd have no way to get rid of an ExecStartPre line, since you can have multiple of them. It's probably not that common, but it's a use case I want to support. Cheers, -- 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/87vck3ns91@qurzaw.varnish-software.com
Re: RFC: OpenRC as Init System for Debian
OoO Pendant le journal télévisé du jeudi 10 mai 2012, vers 20:29, Jean-Christophe Dubacq jean-christophe.dub...@ens-lyon.org disait : I do not know about trivially merging changes in the etc-overrides-lib model, but in the current model, I am presented with the dpkg prompt about conffiles for some programs where I added (or changed) only one line (off the top of my head: only the servers list in roundcube, for example), and dpkg does not propose to merge the two files: I am either stuck with keeping my old file, taking the new, or using a shell. All these things are interactive and prevent unattended upgrades without disruption of services. roundcube uses ucf for its main configuration file and therefore, you should have a prompt with possibility to merge. -- Vincent Bernat ☯ http://vincent.bernat.im printk(KERN_WARNING %s: Short circuit detected on the lobe\n, dev-name); 2.4.0-test2 /usr/src/linux/drivers/net/tokenring/lanstreamer.c pgputTalXJ2N9.pgp Description: PGP signature
Re: Directory /boot/console-setup
]] Steve Langasek My complaint is that this is excessively ugly. For persistent variable data that needs to be available during early boot, even when this is binary data that the user won't edit, /etc is the normal place to keep it - it's the creation of a a .cache subdirectory that I object to. Very strongly agreed, if we could outright ban using dot directories in packages for anything packaged (except dotfiles in people's ~, which should generally not be something that the packaging cares about), I think that would be a good idea. -- 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/87r4urnqk2@qurzaw.varnish-software.com
Re: RFC: OpenRC as Init System for Debian
On May 11, Nikolaus Rath nikol...@rath.org wrote: Wrong: since you have to copy the whole file to override it, and files in /lib have no conffiles handling, after an upgrade you will not know what was changed by you and what was changed upstream. I think everyone here agrees with that. The interesting case is when files in /etc/ can either explicitly include the /lib file, or implicitly override the /lib settings. I do not know about any package which work this way, but there is any then the problem is not different from packages which support multiple configuration file fragments in /etc, ship the default configuration in /etc and allow it to be modified by other configuration fragments in /etc (e.g. Apache). -- ciao, Marco signature.asc Description: Digital signature
Re: RFC: OpenRC as Init System for Debian
On Thu, 10 May 2012 21:30:56 +0300, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: Marco d'Itri wrote: On May 10, Bjørn Mork bj...@mork.no wrote: Agree. Copying a large set of default policies into /etc just because they *can* be overridden is not user friendly. And it does not make the defaults any more configuration either. It just hides important local changes and makes it difficult both for the user and the application itself to distinguish between defaults and configuration overrides. Wrong: You're not addressing what he said about the generally desirable /etc semantics at all, only talking about what current Debian tools would do without modifications. Do you have a reason to oppose beyond this would need some tool changes? Yes -- it scatters configuration state outside /etc (thus hiding it from etckeeper and sysadmins alike), it makes the packages surprising to people familiar with Debian but not familiar with the package (Hint: we have a _lot_ of packages -- nobody is familiar with all of them. Requiring people to become familiar with all the packages before they can safely do an upgrade is part of what explains the number of rotting RedHat systems I see than nobody is brave enough to upgrade). since you have to copy the whole file to override it, Wrong: as mentioned in this thread before, one of the advantages of the etc-overrides-lib model is the option of having a file in /etc that first includes the one in /lib, then overrides just one particular value. This allows handling more updates without needing manual changes, as you can automatically pick up other updated values while keeping the override, without needing to do 3-way merges. This is the real problem with the etc-overrides-lib approach. For a sysadmin to know what to expect from a particular set of configuration files they need to be intimately familiar with the package in question, and why the change was made. Does the package allow partial overrides with includes or otherwise? Is the existence of an empty file deeply significant (think the udev persistent net thing). Did some default appear in lib that needs to be carried into etc? etc. etc. The traditional Debian approach to /etc is largely self documenting, to the extent that one can generally walk into a site cold and (having established that they have decent backups) cheerfully do an upgrade on their Debian servers without anything breaking (I do this regularly). The sources of potential breakage are highlighted by the packaging system, at which point you can read up on any package that needs attention with which you're not already familiar, while ignoring the ones that upgrade cleanly. Having exceptions to that is deeply unhelpful, and the more exceptions we accumulate the less maintainable and upgradable Debian becomes. Your assert that etc-overrides-lib is technically superior -- I and many others dispute that, but even if it were true, using that as a justification is equivalent to pointing out that driving on the left is safer[1] so Norway should make arrangements to allow visitors from the UK to drive on the left while the rest of the country continues on the right. When it's pointed out that that's a disastrous idea you respond by saying that all we need to do is fit some clever (as yet unbuilt) collision avoidance system to all the roads. Obviously this is not a problem for Red Hat since they do not support upgrades between major releases. Why would this cause problems for Debian, except at most needing some changes to tools to better support this case? Or do you think implementing that would be hard? Are you volunteering to do that? If not then stop making assertions that simply require someone else to do a load of work to pander to your unusual tastes. If you are volunteering, then that's somewhat better (although I would prefer that we simply fix the packages to behave themselves in a proper Debian way instead). Cheers, Phil. [1] see: https://en.wikipedia.org/wiki/Right-_and_left-hand_traffic#Safety_factors I believe Japan also did tests -- I don't really care if you disagree, just swap Left/Right and UK/Norway throughout the example and relax. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgp9a7nnyxdyw.pgp Description: PGP signature
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 12:53 AM, Uoti Urpala wrote: The reason why most old applications do not follow that approach (at least not yet) is pretty obvious: their authors never considered it. etc-overrides-lib semantics have only become a seriously considered alternative fairly recently. No. The reason is that we have FHS and the policy, so that packages *have* to behave the same way, and for very valid reasons which have been well described in this thread. You have absolutely everyone (this includes very experienced DDs) against your idea of changing a well established Debian policy, well written in the debian policy manual. Please stop. It's going nowhere. 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/4faccc7d.3010...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 04:04 AM, David Weinehall wrote: On Fri, May 11, 2012 at 02:44:45AM +0800, Thomas Goirand wrote: On 05/10/2012 04:52 AM, Steve McIntyre wrote: No, really - please *do* do this. The fact that a lot of the software coming out of RedHat development seems to be designed solely for their use, including working around the missing/broken features of RPM, is seriously annoying. Configuration belongs in /etc, we know this. We have a well-designed and implemented set of tools in Debian based on that standard. I agree 100% with the above. On 05/10/2012 05:22 AM, Uoti Urpala wrote: Josh Triplett provided multiple technical reasons why etc-overrides-lib is preferable. The ONLY technical reason you gave to prefer traditional conffiles was that there already is a set of tools for that in Debian. No, it's because this way, I am warned by the package manager of a change on the default file, and I can merge by hand when I see it. Otherwise, you are silently changing the default, and potentially, I will miss the new options. Besides this, configuration files in /etc is written in the stones of our bible^Wpolicy-manual. Has anyone argued for having the configuration files anywhere else? It's all in the semantics of course, but to me, the configuration files are the files that the administrator changes to change a configuration. The files that go in /lib are the defaults. If the admin wants to override something they do so in /etc, just like before. From: http://en.wikipedia.org/wiki/Configuration_file In computing, configuration files, or config files configure the initial settings for some computer programs. They are used for user applications, server processes and operating system settings. The fact that these files are in /lib and shouldn't be touched by the admin doesn't make them less configuration files. They still match the above definition from Wikipedia. If the old file in /lib isn't equal to the new file being installed to /lib, and there's a user supplied file in /etc rather than just the default (which would only include the version in lib), then prompt the user. If the user is running a non-interactive upgrade, fire off an e-mail or something. For any major changes to the /lib files (stuff that are likely to trigger user actions), NEWS.Debian should of course, as usual, contain a heads up. No need to explain again, again and again the same thing. We did understand what your point is, but still, we don't agree with you and Uoti. Move on. Just because something isn't supported currently in our tools doesn't make it impossible to support it. The very reason why our tools don't support it, is because *we don't want it*. It's designed like this on purpose, and we are happy with the way things are right now. Why can't you implement something like amavis, grub2, or apache are doing? Especially Amavis, where the default config is a conffile, but you can override what you need by using a higher number in the file name. It works well, it is integrated with Debian and the way things work... And debian-policy isn't set in stone. Otherwise it wouldn't have last been revised in February 2012 :) The debian-policy maybe, but the FHS, and config files in /etc *is* a very strong policy that you will not change in Debian, and for very valid reasons already described in this thread. 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/4facd03a@debian.org
Re: etc-overrides-non-etc configuration file model [Re: RFC: OpenRC asInit System for Debian]
On 05/11/2012 04:21 AM, Uoti Urpala wrote: Advantages I mentioned earlier would still be there: It's easier to see what is local non-default configuration. Original default file is always available in a known location (and very easy to revert to, temporarily for testing or permanently). As I wrote to you *already*, the place where to put such default configuration to keep it from being overwritten is /usr/share/doc/$package/examples. Many packages are doing this, for example: /usr/share/php5/php.ini-production (which is the exact same file as /etc/php5/apache/apache2/php.ini). I'm ok with discussing things, but you are repeating yourself, and forcing others to do the same. That's annoying and not moving to the right direction. 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/4facd2ce.1070...@debian.org
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: On 05/11/2012 12:53 AM, Uoti Urpala wrote: The reason why most old applications do not follow that approach (at least not yet) is pretty obvious: their authors never considered it. etc-overrides-lib semantics have only become a seriously considered alternative fairly recently. No. The reason is that we have FHS and the policy, so that packages *have* to behave the same way, and for very valid reasons which have been well described in this thread. Neither the FHS, nor the policy says anything about etc-overrides-lib as far as I can see. Neither pro or con. Do feel free to point me to the relevant section, would I be mistaken. The stuff in /lib are package defaults. Where the default is, in the program, embedded, or in some file, doesn't really matter, it's an implementation detail. Overrides (ie, configuration) *is* in /etc, as mandated by policy. You have absolutely everyone (this includes very experienced DDs) against your idea of changing a well established Debian policy, well written in the debian policy manual. Please stop. It's going nowhere. Erm, no. It's not written in the debian policy for a start, and not everyone agrees that etc-overrides-lib is a bad idea. I for one think it's a good idea in selected cases (systemd being one such), and no worse - in some ways, even better - than some other existing practice (the conf.d/ stuff I mentioned a few times elsewhere in this thread already). -- |8] -- 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/87wr4jumk6.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Tollef Fog Heen tfh...@err.no writes: ]] Uoti Urpala Hi, Wrong: as mentioned in this thread before, one of the advantages of the etc-overrides-lib model is the option of having a file in /etc that first includes the one in /lib, then overrides just one particular value. This allows handling more updates without needing manual changes, as you can automatically pick up other updated values while keeping the override, without needing to do 3-way merges. This doesn't always work, though. For instance, for systemd, you'd have no way to get rid of an ExecStartPre line, since you can have multiple of them. It's probably not that common, but it's a use case I want to support. In that case, the including file can be changed (by the admin) to be a separate file, that does not include, and get the usual conffile conflict dpkg prompt. -- |8] -- 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/87sjf7umhf.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Philip Hands p...@hands.com writes: On Thu, 10 May 2012 21:30:56 +0300, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: Marco d'Itri wrote: On May 10, Bjørn Mork bj...@mork.no wrote: Agree. Copying a large set of default policies into /etc just because they *can* be overridden is not user friendly. And it does not make the defaults any more configuration either. It just hides important local changes and makes it difficult both for the user and the application itself to distinguish between defaults and configuration overrides. Wrong: You're not addressing what he said about the generally desirable /etc semantics at all, only talking about what current Debian tools would do without modifications. Do you have a reason to oppose beyond this would need some tool changes? Yes -- it scatters configuration state outside /etc (thus hiding it from etckeeper and sysadmins alike), it makes the packages surprising to people familiar with Debian but not familiar with the package (Hint: we have a _lot_ of packages -- nobody is familiar with all of them. Requiring people to become familiar with all the packages before they can safely do an upgrade is part of what explains the number of rotting RedHat systems I see than nobody is brave enough to upgrade). I'll turn this around: how do you handle cases where the defaults of packages like apt, exim or syslogd change? Where the defaults are embedded in the executable. You don't. That systemd has the defaults in files under /lib is an implementation detail. It's no different than any other default other software comes with, except that this one is easier to see and notice when it changes: it's possible to craft a trigger that'd fire in those cases. It's not possible to do that for cases where the default is hidden, which is the case for the vast majority of software. Yet, I do not see anyone jumping on those, and demanding they move *all* their defaults to /etc. since you have to copy the whole file to override it, Wrong: as mentioned in this thread before, one of the advantages of the etc-overrides-lib model is the option of having a file in /etc that first includes the one in /lib, then overrides just one particular value. This allows handling more updates without needing manual changes, as you can automatically pick up other updated values while keeping the override, without needing to do 3-way merges. This is the real problem with the etc-overrides-lib approach. For a sysadmin to know what to expect from a particular set of configuration files they need to be intimately familiar with the package in question, and why the change was made. Does the package allow partial overrides with includes or otherwise? Is the existence of an empty file deeply significant (think the udev persistent net thing). Did some default appear in lib that needs to be carried into etc? etc. etc. The same could be said of various conf.d/-style hacks that plague the archive. Do snippets override the things they change, or do they get merged? One must be familiar with the particular program to figure it out. This problem exists in every piece of software that can be configured, and does not use a single monolithic configuration file. The traditional Debian approach to /etc is largely self documenting, to the extent that one can generally walk into a site cold and (having established that they have decent backups) cheerfully do an upgrade on their Debian servers without anything breaking (I do this regularly). I'm afraid my experience disagrees, see above: the conf.d/-style hacks vary between packages, and there is *no* common ground. Some override settings completely, some get merged, it largely depends not only on the package in question, but in the setting aswell: even within a package, some settings get merged, some get overwritten. Sometimes it is even an error to try and override parts of the main configuration within a snippet - and you can't tell that only by looking at the files. You have to know the software in question, and how its configuration works. etc-over-lib is no different to existing practice. The only difference is where the defaults live, nothing else. The sources of potential breakage are highlighted by the packaging system, at which point you can read up on any package that needs attention with which you're not already familiar, while ignoring the ones that upgrade cleanly. Like I said elsewhere in the thread: conf.d/-style snippets. They're widely used, show the same problems. etc-over-lib is no worse. Having exceptions to that is deeply unhelpful, and the more exceptions we accumulate the less maintainable and upgradable Debian becomes. etc-over-lib is no exception. It's configuration in /etc, that overrides or changes default. Like *every* other piece of configuration that is in /etc. Where the default is, doesn't matter. We *never* get notification when defaults change, unless the default
Re: RFC: OpenRC as Init System for Debian
]] Gergely Nagy Tollef Fog Heen tfh...@err.no writes: ]] Uoti Urpala Hi, Wrong: as mentioned in this thread before, one of the advantages of the etc-overrides-lib model is the option of having a file in /etc that first includes the one in /lib, then overrides just one particular value. This allows handling more updates without needing manual changes, as you can automatically pick up other updated values while keeping the override, without needing to do 3-way merges. This doesn't always work, though. For instance, for systemd, you'd have no way to get rid of an ExecStartPre line, since you can have multiple of them. It's probably not that common, but it's a use case I want to support. In that case, the including file can be changed (by the admin) to be a separate file, that does not include, and get the usual conffile conflict dpkg prompt. How would that work? I have /lib/systemd/system/foo.service and want to change something in it, I then create /etc/systemd/system/foo.service with a copy of the /lib one plus whatever changes I want. The version in /lib is then updated. How is the admin notified? (This is the problem I want to fix with some yet unwritten tool.) -- 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/87k40jnjmv@qurzaw.varnish-software.com
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: From: http://en.wikipedia.org/wiki/Configuration_file In computing, configuration files, or config files configure the initial settings for some computer programs. They are used for user applications, server processes and operating system settings. The fact that these files are in /lib and shouldn't be touched by the admin doesn't make them less configuration files. They still match the above definition from Wikipedia. Can I point you to /usr/share/glib-2.0/schemas/, /usr/share/gconf/defaults and similar? These are by the above definition, configuration files. Yet they are not under /etc. They are used to load the initial configuration of software, and can be overridden elsewhere (funny thing is, the gconf defaults can be overridden with stuff in /var/lib/gconf/debian.* - even the overides are outside of /etc!). Can we fix these first, where not even the overrides are in /etc, let alone the defaults? Please? Just because something isn't supported currently in our tools doesn't make it impossible to support it. The very reason why our tools don't support it, is because *we don't want it*. It's designed like this on purpose, and we are happy with the way things are right now. Are you happy with dropping a snippet into a conf.d/ directory, and your software breaking on an upgrade without notice? Because that can happen even now, with software that uses only /etc, and /etc alone for their configuration, without any kind of default anywhere else. Why can't you implement something like amavis, grub2, or apache are doing? Especially Amavis, where the default config is a conffile, but you can override what you need by using a higher number in the file name. It works well, it is integrated with Debian and the way things work... It certainly does not work all that well. We came to live with it over the years, is all. And debian-policy isn't set in stone. Otherwise it wouldn't have last been revised in February 2012 :) The debian-policy maybe, but the FHS, and config files in /etc *is* a very strong policy that you will not change in Debian, and for very valid reasons already described in this thread. And in etc-overrides-lib, config files still remain in /etc. Its just the defaults that live elsewhere. That the defaults are files, and are under /lib, is an implementation detail, similarly how gconf defaults live under /usr/share/gconf/defaults. FHS and Policy are obeyed. -- |8] -- 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/87bolvul1l.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
On May 11, Gergely Nagy alger...@balabit.hu wrote: And in etc-overrides-lib, config files still remain in /etc. Its just the defaults that live elsewhere. That the defaults are files, and are under /lib, is an implementation detail, similarly how gconf defaults live under /usr/share/gconf/defaults. This is not similar to how gconf works, because gconf allows you to only set the directives you need in the new file, while udev and systemd require copying the whole file from /lib. -- ciao, Marco signature.asc Description: Digital signature
Re: RFC: OpenRC as Init System for Debian
On Fri, May 11, 2012 at 10:52:25AM +0200, Gergely Nagy wrote: Neither the FHS, nor the policy says anything about etc-overrides-lib as far as I can see. Neither pro or con. Do feel free to point me to the relevant section, would I be mistaken. To be honest, I still don’t really understand what the files in lib are: - Are they configuration examples with all possible settings and their default values and the application works fine without these files? Then they should be in /usr/share/doc/package. - Or doesn’t the application start without these files? Then they are undoubtedly configuration files and according to FHS and Debian policy configuration files belong in /etc The stuff in /lib are package defaults. Where the default is, in the program, embedded, or in some file, doesn't really matter, it's an implementation detail. It does matter. In the end it is the same situation as the firmware problem. For the hardware it doesn’t matter if the firmware is placed in an EEPROM on the hardware or loaded from the FS by the driver. But for Debian and its policy it is a difference. So if you don’t want a default configuration from a file, because you don’t want to put a file in /etc, then you must compile the program with your default settings. worse - in some ways, even better - than some other existing practice (the conf.d/ stuff I mentioned a few times elsewhere in this thread already). I like conf.d. It makes things easier for e.g. rsyslog or sysctl. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: RFC: OpenRC as Init System for Debian
On Fri, May 11, 2012 at 11:25:10AM +0200, Gergely Nagy wrote: Are you happy with dropping a snippet into a conf.d/ directory, and your software breaking on an upgrade without notice? Because that can happen even now, with software that uses only /etc, and /etc alone for their configuration, without any kind of default anywhere else. Yes, because I know that something is wrong when it breaks. This is better than the software is working but not anymore as you expect. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: RFC: OpenRC as Init System for Debian
Tollef Fog Heen tfh...@err.no writes: ]] Gergely Nagy Tollef Fog Heen tfh...@err.no writes: ]] Uoti Urpala Hi, Wrong: as mentioned in this thread before, one of the advantages of the etc-overrides-lib model is the option of having a file in /etc that first includes the one in /lib, then overrides just one particular value. This allows handling more updates without needing manual changes, as you can automatically pick up other updated values while keeping the override, without needing to do 3-way merges. This doesn't always work, though. For instance, for systemd, you'd have no way to get rid of an ExecStartPre line, since you can have multiple of them. It's probably not that common, but it's a use case I want to support. In that case, the including file can be changed (by the admin) to be a separate file, that does not include, and get the usual conffile conflict dpkg prompt. How would that work? I have /lib/systemd/system/foo.service and want to change something in it, I then create /etc/systemd/system/foo.service with a copy of the /lib one plus whatever changes I want. The version in /lib is then updated. How is the admin notified? NEWS.Debian, like with any significant default change. Other than that, the best I can think of is keeping track of what version of the package a default changed in, and triggering something from preinst, when upgrading from a version that is older than the change. This however, requires a lot of manual work, might aswell shovel the whole thing from under /lib to /etc then, but then we still didn't solve the problem: suppose there is a unit file that supports starting multiple instances, by way of symlinking. I start to use this feature, I change nothing, just symlink files around. At some point, this feature gets removed, my upgrade succeeds, but my instances won't start anymore, and the best notification I have is something that scrolled by that a conffile was upgraded. In this case, we have a succesful upgrade resulting in a broken system, because a default changed, and the user was not adequately notified. Which gets us back to NEWS.Debian being the best solution. There simply are cases where no automatism can be clever enough. -- |8] -- 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/877gwjujxr.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
On 11/05/2012 08:47, Vincent Bernat wrote: OoO Pendant le journal télévisé du jeudi 10 mai 2012, vers 20:29, Jean-Christophe Dubacq jean-christophe.dub...@ens-lyon.org disait : I do not know about trivially merging changes in the etc-overrides-lib model, but in the current model, I am presented with the dpkg prompt about conffiles for some programs where I added (or changed) only one line (off the top of my head: only the servers list in roundcube, for example), and dpkg does not propose to merge the two files: I am either stuck with keeping my old file, taking the new, or using a shell. All these things are interactive and prevent unattended upgrades without disruption of services. roundcube uses ucf for its main configuration file and therefore, you should have a prompt with possibility to merge. Never got it. But I can quote other (courier, for example). Even /etc/default/locale was updated (only to include a bunch of comments). Is it really necessary ? BTW, for standard workstations, there is less and less need to change things in /etc. My current quota is 1346 files in /etc for about 30 of them with local changes. This is quite a bad signal/noise ratio. If dpkg kept a copy of the original configuration file (to be retrieved at all times), it would be easier to spot local changes. I use etckeeper to do that, but it's a bit tiresome to isolate all local changes (I have to save the diffs somewhere) (and a lost hope if you do install etckeeper late in the workstation life). My git-fu is probably not good enough (I am probably looking for a pristine branch and a rebased local branch used in production). -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: RFC: OpenRC as Init System for Debian
On Fri, May 11, 2012 at 12:07:55PM +0200, Jean-Christophe Dubacq wrote: BTW, for standard workstations, there is less and less need to change things in /etc. My current quota is 1346 files in /etc for about 30 of them with local changes. This is quite a bad signal/noise ratio. Well, a standard workstation has many configuration changes I would say, but these changes are all user settings for their WM/DM or application configuration like pidgin or audacious that reside in /home/user. But if you don’t configure files in /etc, why is it a problem if you have many files in /etc? Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
Re: RFC: OpenRC as Init System for Debian
Stephan Seitz stse+deb...@fsing.rootsland.net writes: On Fri, May 11, 2012 at 11:25:10AM +0200, Gergely Nagy wrote: Are you happy with dropping a snippet into a conf.d/ directory, and your software breaking on an upgrade without notice? Because that can happen even now, with software that uses only /etc, and /etc alone for their configuration, without any kind of default anywhere else. Yes, because I know that something is wrong when it breaks. This is better than the software is working but not anymore as you expect. You do realize that the only difference between the two cases is that when the default happens to be in /etc, you get a Configuration file updated thing scroll by? Other than that, things break exactly the same way, and you will have no more information, and the one you have is of little use, as it happily overwrote the unmodified default, so you'll have to hunt down the former version anyway, to see the difference. -- |8] -- 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/87vck3t483.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Jean-Christophe Dubacq wrote: If dpkg kept a copy of the original configuration file (to be retrieved at all times), it would be easier to spot local changes. I use etckeeper to do that, but it's a bit tiresome to isolate all local changes (I have to save the diffs somewhere) (and a lost hope if you do install etckeeper late in the workstation life). My git-fu is probably not good enough (I am probably looking for a pristine branch and a rebased local branch used in production). You might be interested in a proposal at UDS this week: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-dpkg-pristine-conffiles -- Steve McIntyre, Cambridge, UK.st...@einval.com You can't barbecue lettuce! -- Ellie Crane -- 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/e1ssnta-0007af...@mail.einval.com
Re: RFC: OpenRC as Init System for Debian
m...@linux.it (Marco d'Itri) writes: On May 11, Gergely Nagy alger...@balabit.hu wrote: And in etc-overrides-lib, config files still remain in /etc. Its just the defaults that live elsewhere. That the defaults are files, and are under /lib, is an implementation detail, similarly how gconf defaults live under /usr/share/gconf/defaults. This is not similar to how gconf works, because gconf allows you to only set the directives you need in the new file, while udev and systemd require copying the whole file from /lib. But by the wikipedia definition, the gconf defaults are config files too. My point was to make it clear that blindly following that definition might not lead to desirable results. But, a few more examples of config files, or snippets from directories different than /etc: * /usr/share/X11/xorg.conf.d/: I would especially like to quote these lines from the 50-synaptics.conf file from there: , | # DO NOT EDIT THIS FILE, your distribution will likely overwrite | # it when updating. Copy (and rename) this file into | # /etc/X11/xorg.conf.d first. ` While said file also says it is an example, looking at xorg.conf.d(5), it suggests that X11 will behave somewhat similar to systemd, and search for override-able config snippets in directories outside of /etc. According to the manpage: When the same information is supplied in more than one way, the highest precedence mechanism is used. In other words, it does *exactly* the same thing systemd is criticised for. * /usr/share/alsa/alsa.conf.d/: Files herein will be processed by alsa-lib, according to the README. They are obviously config file snippets, and as such, if following the wikipedia definition, should be in /etc. I assume - though, haven't checked - that files in /etc can override these settings. I could probably find more, but just two off the top of my /usr/share seemed enough for now. It seems to me that etc-overrides-non-etc is already existing practice, if X11 and ALSA use it too, among others. In light of this, systemd is no different. It just has more defaults in files under /lib. Long story short, I still don't see what the fuss is about. -- |8] -- 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/87obpvt313.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Stephan Seitz stse+deb...@fsing.rootsland.net writes: On Fri, May 11, 2012 at 10:52:25AM +0200, Gergely Nagy wrote: Neither the FHS, nor the policy says anything about etc-overrides-lib as far as I can see. Neither pro or con. Do feel free to point me to the relevant section, would I be mistaken. To be honest, I still don’t really understand what the files in lib are: - Are they configuration examples with all possible settings and their default values and the application works fine without these files? Then they should be in /usr/share/doc/package. They are default settings for a particular service, and the application does not work without them. - Or doesn’t the application start without these files? Then they are undoubtedly configuration files and according to FHS and Debian policy configuration files belong in /etc It is indeed true, that these are settings the application does not work without. So are many things under /usr/share, some of them similarly configuration files (/usr/share/X11/xorg.conf.d/; /usr/share/alsa/alsa.conf.d/ to name just two). That a default happens to be in a file does not make it a configuration file. A configuration file is something you *change* to alter a programs behaviour. With systemd, these files are under /etc. That the defaults are split out into separate files is an implementation detail, nothing more. You do *NOT* change the defaults. You change the settings. The stuff in /lib are package defaults. Where the default is, in the program, embedded, or in some file, doesn't really matter, it's an implementation detail. It does matter. In the end it is the same situation as the firmware problem. For the hardware it doesn’t matter if the firmware is placed in an EEPROM on the hardware or loaded from the FS by the driver. But for Debian and its policy it is a difference. Policy governs configuration. It never talks about default settings, it does not mandate anywhere where and how defaults are to be set. So if you don’t want a default configuration from a file, because you don’t want to put a file in /etc, then you must compile the program with your default settings. What happens if your defaults are open-ended? When you *can't* compile them all in, because third party packages are able to extend the set of default settings? You can't compile in the defaults in that case. You could compile in the subset shipped with the package, and you could make it so that third party packages only use stuff in /etc, but that would needlessly complicate matters for no real benefit. worse - in some ways, even better - than some other existing practice (the conf.d/ stuff I mentioned a few times elsewhere in this thread already). I like conf.d. It makes things easier for e.g. rsyslog or sysctl. They also suffer from the very same problem the defaults in /lib/systemd do. Namely, if you did not change the default, and it changes under you, your system can break without any kind of warning or notice, and very little trace as to what went wrong. -- |8] -- 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/87k40jt2l2.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 04:52 PM, Gergely Nagy wrote: Neither the FHS, nor the policy says anything about etc-overrides-lib as far as I can see. Neither pro or con. Do feel free to point me to the relevant section, would I be mistaken. Section 10.7.2 of dpm: Any configuration files created or used by your package must reside in |/etc|. The policy never talks about etc-overrides-lib configuration files, it only tells that all configuration files should go in /etc, and there's no exception, and it is also a must. 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/4facf2d8.5050...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 05:25 PM, Gergely Nagy wrote: And in etc-overrides-lib, config files still remain in /etc. No. -- 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/4facf398.2010...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 06:39 PM, Gergely Nagy wrote: In other words, it does *exactly* the same thing systemd is criticised for. Which doesn't mean that it's a good practice. 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/4facf423.1090...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 06:39 PM, Gergely Nagy wrote: Long story short, I still don't see what the fuss is about. The fuss is about we're being told that there will be silent overwriting of configuration files without being prompted about changes, which potentially, will make it horrible to manage upgrades in a decent way without knowing the corner cases. On top of that, we're being told that this is the reason why we should use this system, which is totally the inverse of what we've been doing in Debian for years. 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/4facf4fd.8000...@debian.org
Re: RFC: OpenRC as Init System for Debian
Steve McIntyre st...@einval.com writes: Jean-Christophe Dubacq wrote: If dpkg kept a copy of the original configuration file (to be retrieved at all times), it would be easier to spot local changes. I use etckeeper to do that, but it's a bit tiresome to isolate all local changes (I have to save the diffs somewhere) (and a lost hope if you do install etckeeper late in the workstation life). My git-fu is probably not good enough (I am probably looking for a pristine branch and a rebased local branch used in production). You might be interested in a proposal at UDS this week: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-dpkg-pristine-conffiles So basically, we'd have a directory of files under /etc that are not conffiles, and even made 0440. Amusing proposal. Why not move them outside of /etc then, if they are not configuration files, and should not be touched by the user? (Yeah, sure, they can be moved out of /etc, but that doesn't stop the original proposal being amusing, sorry.) -- |8] -- 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/87fwb7t1vo.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: On 05/11/2012 04:52 PM, Gergely Nagy wrote: Neither the FHS, nor the policy says anything about etc-overrides-lib as far as I can see. Neither pro or con. Do feel free to point me to the relevant section, would I be mistaken. Section 10.7.2 of dpm: Any configuration files created or used by your package must reside in |/etc|. The policy never talks about etc-overrides-lib configuration files, it only tells that all configuration files should go in /etc, and there's no exception, and it is also a must. But these are default settings, not configuration files. The configuration files *are* in /etc. Configuration files are stuff you want to change, defaults are things upstream (or at worst, the package maintainer) decides them to be, and the user has no business touching them. That is what configuration is for, to change the defaults. That the defaults happen to be files instead of some compiled in thing, is an implementation detail. But be my guest, if you take this seriously, please file a bug against X11 (see xorg.conf.d(5) for a reason) and other packages that do the same thing systemd does. -- |8] -- 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/87bolvt1f6.fsf@algernon.balabit
Strange bug in Qt program after build with gcc 4.7
Hi all, There is no any reply in debian-mentors mailing list, so I am forwarding my message here. Please Cc me in replies, I am not subscribed to debian-devel. begin original message 2012-05-10 21:08, Boris Pek wrote: Hi everyone, I have strange problem with my package eiskaltdcpp-qt. When I compile this binary file using gcc 4.6 program works fine. But when I compile it using gcc 4.7 program crashes at launch time. Full backtrace from gdb shows that segmentation fault is in Qt library [1]. Bug was also confirmed in Fedora and Arch Linux. C++11 is actively used in eiskaltdcpp-qt. Could it causes the bug? I have tried to make minimum reproducible example but without success. Could anyone look on my package? Any suggestions are welcome. Package can be found on m.d.n [2][3]. Or you could get sources directly from upstream [4]. Problem exists in all last releases since 2.2.5 (I have not checked earlier versions). Also what mailing list is relevant for such bugs? Maybe debian-devel or another one? Best regards, Boris PS: I use Debian Sid with all recent updates. [1] See eiskaltdcpp-qt.gdb.bt_full.log in attachment [2] http://mentors.debian.net/package/eiskaltdcpp [3] http://mentors.debian.net/debian/pool/main/e/eiskaltdcpp/eiskaltdcpp_2.2.6-4.dsc [4] https://github.com/negativ/eiskaltdcpp end original message $ gdb eiskaltdcpp-qt GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/eiskaltdcpp-qt...done. (gdb) run Starting program: /usr/bin/eiskaltdcpp-qt [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/i386-linux-gnu/i686/cmov/libthread_db.so.1. Installing handler for: Segmentation fault Installing handler for: Aborted Installing handler for: Bus error Installing handler for: Terminated Signal handlers installed. [New Thread 0xb2d09b70 (LWP 2935)] [New Thread 0xb2508b70 (LWP 2936)] Loading: Hash database [New Thread 0xb1bcfb70 (LWP 2937)] [Thread 0xb2508b70 (LWP 2936) exited] Loading: Shared Files [New Thread 0xb2508b70 (LWP 2941)] Loading: Download Queue Loading: Users [New Thread 0xb13ceb70 (LWP 2942)] UserList icons has been loaded Application icons has been loaded [New Thread 0xb0024b70 (LWP 2943)] [New Thread 0xaf823b70 (LWP 2944)] [New Thread 0xaf022b70 (LWP 2945)] [New Thread 0xae821b70 (LWP 2946)] [New Thread 0xae020b70 (LWP 2947)] Program received signal SIGSEGV, Segmentation fault. __strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:52 52 ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S: No such file or directory. (gdb) bt full #0 __strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:52 No locals. #1 0xb5c414e5 in XSetCommand () from /usr/lib/i386-linux-gnu/libX11.so.6 No symbol table info available. #2 0xb5c45ee3 in XSetWMProperties () from /usr/lib/i386-linux-gnu/libX11.so.6 No symbol table info available. #3 0xb70ab646 in QWidgetPrivate::create_sys(unsigned long, bool, bool) () from /usr/lib/i386-linux-gnu/libQtGui.so.4 No symbol table info available. #4 0xb705582f in QWidget::create(unsigned long, bool, bool) () from /usr/lib/i386-linux-gnu/libQtGui.so.4 No symbol table info available. #5 0xb7724c77 in ?? () from /usr/lib/i386-linux-gnu/libQtGui.so.4 No symbol table info available. #6 0xb7725a91 in ?? () from /usr/lib/i386-linux-gnu/libQtGui.so.4 No symbol table info available. #7 0xb7725bea in ?? () from /usr/lib/i386-linux-gnu/libQtGui.so.4 No symbol table info available. #8 0xb770dac8 in QSystemTrayIcon::setVisible(bool) () from /usr/lib/i386-linux-gnu/libQtGui.so.4 No symbol table info available. #9 0x0827519a in show (this=optimized out) at /usr/include/qt4/QtGui/qsystemtrayicon.h:108 No locals. #10 Notification::enableTray (this=this@entry=0x972dbd0, enable=true) at ../../eiskaltdcpp-qt/src/Notification.cpp:136 menuAdditional = 0x97836d0 actSupressTxt = 0x8e27838 menu = 0x978fbb0 actSupressSnd = 0x8e29160 show_hide = optimized out setup_speed_lim = 0x97b1910 close_app = 0x97736d0 sep = 0x8e29fd8 #11 0x08275590 in Notification::Notification (this=0x972dbd0, parent=0x0) at ../../eiskaltdcpp-qt/src/Notification.cpp:41 No locals. #12 0x08178fda in dcpp::SingletonNotification::newInstance () at ../../dcpp/Singleton.h:47 No locals. #13 0x080d8bfc in main (argc=1, argv=0xb1a4) at ../../eiskaltdcpp-qt/src/main.cpp:172 app = {QtSingleCoreApplication = {QApplication = {No data fields}, static staticMetaObject = {d =
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: On 05/11/2012 06:39 PM, Gergely Nagy wrote: In other words, it does *exactly* the same thing systemd is criticised for. Which doesn't mean that it's a good practice. Tell me what you would gain, if there were no files under /lib/systemd, and all of these were compiled into the binary, please. Because that's the other option, as you *do not* let users change the defaults. You let them override them, you let them configure the system. (And that *is* being done in /etc.) There are *very* few programs that come without any kind of default, and even less, that let you change the default too. apt does not let you change the defaults, nor does dpkg. Both allow you to change their settings, but without recompiling, you can't change the defaults. Same happens with systemd, the difference is that it's easier to see the defaults, as they're broken out into files that are easy to copy and change as needed. -- |8] -- 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/874nrnt155.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Philip Hands wrote: The traditional Debian approach to /etc is largely self documenting, to the extent that one can generally walk into a site cold and (having established that they have decent backups) cheerfully do an upgrade on their Debian servers without anything breaking (I do this regularly). If you walk into a site cold, how do you tell if they have weird local configuration for something? It's much easier to check if there's something under /etc than to start checking whether the files match what's expected for the package version, if the the default files are always there even if nothing has been configured. The sources of potential breakage are highlighted by the packaging system, at which point you can read up on any package that needs attention with which you're not already familiar, while ignoring the ones that upgrade cleanly. And why would this have to be any worse with etc-overrides-lib? Why would this cause problems for Debian, except at most needing some changes to tools to better support this case? Or do you think implementing that would be hard? Are you volunteering to do that? If not then stop making assertions that simply require someone else to do a load of work to pander to your unusual tastes. If you are volunteering, then that's somewhat better (although I would prefer that we simply fix the packages to behave themselves in a proper Debian way instead). No, I'm not volunteering, mainly because I don't want to program in shell (which ucf seems to be implemented in). I can still estimate what such an implementation would need to do. You can't argue that everything which has not already been implemented would be a huge fundamental problem. If you want to argue that etc-overrides-lib would be fundamentally bad, hard to support, or undesirable to even try to support in Debian, then you should say more about implementation difficulties than just it's not implemented at the moment. George Danchev gave a proposed implementation of change alerts in an earlier mail: http://lists.debian.org/201205110212.30503.danc...@spnet.net While there are things you'd want to improve in a real implementation for packager convenience and better user interface (and the ucf part looks like it'd incorrectly create the file under /etc by default), I think that's enough to demonstrate this is not a particularly hard problem. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1336737949.2227.181.camel@glyph.nonexistent.invalid
Re: RFC: OpenRC as Init System for Debian
On Fri, May 11, 2012 at 04:39:22PM +0800, Thomas Goirand wrote: [snip] From: http://en.wikipedia.org/wiki/Configuration_file In computing, configuration files, or config files configure the initial settings for some computer programs. They are used for user applications, server processes and operating system settings. The fact that these files are in /lib and shouldn't be touched by the admin doesn't make them less configuration files. They still match the above definition from Wikipedia. Since when did Wikipedia have any relevance on Debian? If the old file in /lib isn't equal to the new file being installed to /lib, and there's a user supplied file in /etc rather than just the default (which would only include the version in lib), then prompt the user. If the user is running a non-interactive upgrade, fire off an e-mail or something. For any major changes to the /lib files (stuff that are likely to trigger user actions), NEWS.Debian should of course, as usual, contain a heads up. No need to explain again, again and again the same thing. We did understand what your point is, but still, we don't agree with you and Uoti. Move on. Talking about yourself in pluralis majestatis now? Just because something isn't supported currently in our tools doesn't make it impossible to support it. The very reason why our tools don't support it, is because *we don't want it. It's designed like this on purpose, and we are happy with the way things are right now. Yes, I get it that you are. Or are you somehow assuming that you can speak for all of Debian? I guess you're aware of the fact that I'm a DD too? Why can't you implement something like amavis, grub2, or apache are doing? Especially Amavis, where the default config is a conffile, but you can override what you need by using a higher number in the file name. It works well, it is integrated with Debian and the way things work... A solution with configuration files in /etc including, or overriding, defaults elsewhere works well too. gconf is a good example. Tollef's example of how to handle the case of a setting that can be set multiple times is probably needs some thought though, but that particular case can be solved by copying rather than including, if needs be. Anyway, I'm neither systemd maintainer nor upstream, so I don't believe I'm the right person to speak to. Then again, neither are you TTBOMK :) And debian-policy isn't set in stone. Otherwise it wouldn't have last been revised in February 2012 :) The debian-policy maybe, but the FHS, and config files in /etc *is* a very strong policy that you will not change in Debian, and for very valid reasons already described in this thread. Sigh. The config files remain in /etc. The defaults are not. There's nothing in FHS that contradicts such a behaviour. Regards: David -- /) David Weinehall t...@debian.org /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- 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/20120511122856.gg10...@suiko.acc.umu.se
Re: RFC: OpenRC as Init System for Debian
On May 11, Gergely Nagy alger...@balabit.hu wrote: Long story short, I still don't see what the fuss is about. Apparently the reason is that you do not understand the problem, since you keep getting back to the not relevant issue of software which supports placing configuration directives in multiple directories. This is not what etc-overrides-lib is about: with udev and systemd, if you create a file in /etc then the file with the same name in /lib is ignored. -- ciao, Marco signature.asc Description: Digital signature
Re: RFC: OpenRC as Init System for Debian
On May 11, Thomas Goirand z...@debian.org wrote: Long story short, I still don't see what the fuss is about. The fuss is about we're being told that there will be silent overwriting of configuration files without being prompted about changes, which potentially, will make it horrible to manage upgrades in a decent way without knowing the corner cases. No, not even that: if you edit files in /lib without being aware of the consequences then you are an idiot and deserve to suffer for it. The problem with etc-overrides-lib is that a file must be copied in full from /lib to /etc to be modified, and then future changes to the same file in /lib will be ignored (so maybe the package will break because these changes are required, etc). -- ciao, Marco signature.asc Description: Digital signature
Re: RFC: OpenRC as Init System for Debian
]] Thomas Goirand On 05/11/2012 06:39 PM, Gergely Nagy wrote: Long story short, I still don't see what the fuss is about. The fuss is about we're being told that there will be silent overwriting of configuration files without being prompted about changes, which potentially, will make it horrible to manage upgrades in a decent way without knowing the corner cases. I've not yet seen anybody saying that, so could you provide a reference, please? Preferably by somebody who is actually going to be doing some of the work. -- 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/87fwb6oq1x@qurzaw.varnish-software.com
Re: RFC: OpenRC as Init System for Debian
Am 11.05.2012 14:30, schrieb Marco d'Itri: The problem with etc-overrides-lib is that a file must be copied in full from /lib to /etc to be modified, and then future changes to the same file in /lib will be ignored (so maybe the package will break because these changes are required, etc). You can either copy the file or use the .include directive (which was already mentioned) and only override the settings you need. So systemd provides both semantics and you can chose which one you want/need. Michael signature.asc Description: OpenPGP digital signature
Bug#672480: ITP: prooftree -- proof tree visualization for Proof General
Package: wnpp Owner: Hendrik Tews hend...@askra.de Severity: wishlist * Package name: prooftree Version : 0.9 Upstream Author : Hendrik Tews * URL or Web page : http://askra.de/software/prooftree/ * License : GPL-3 Description : proof tree visualization for Proof General Prooftree draws proof trees during interactive proof development with Proof General. One can inspect goals and proof commands and check where existential variables were introduced and instantiated. Currently, Prooftree does only work for Coq. Actually Prooftree requires Coq 8.4, which has not been released yet. There is also work on supporting HOL Light, but this has not been released either. However, there is a good chance that Coq 8.4 and/or the HOL Light support in Proof General will get included in the next Debian release. Given the time it takes to get a new package into Debian, it is probably not too early to start now with packaging Prooftree. Even if Coq 8.4 and the HOL Light support in Proof General will not be included in the next Debian release, it would be good to have Prooftee in the archive. Users would then only need to install Coq or Proof General manually and could rely on the Prooftree package. Bye, Hendrik -- 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/6x3976vqt0@blau.inf.tu-dresden.de
Configuration file handling (was: RFC: OpenRC as Init System for Debian)
On Fri, May 11, 2012 at 11:53:34AM +0100, Steve McIntyre wrote: Jean-Christophe Dubacq wrote: If dpkg kept a copy of the original configuration file (to be retrieved at all times), it would be easier to spot local changes. I use etckeeper to do that, but it's a bit tiresome to isolate all local changes (I have to save the diffs somewhere) (and a lost hope if you do install etckeeper late in the workstation life). My git-fu is probably not good enough (I am probably looking for a pristine branch and a rebased local branch used in production). You might be interested in a proposal at UDS this week: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-dpkg-pristine-conffiles I'm unconvinced that this would be workable. How many programs and configuration files reference absolute paths under /etc? Which wouldn't be overridable using the proposed mechanism. Is this going to concern itself only with init.d scripts or all conffiles? Bind mounting the prinstine copy over the broken copy is probably the safest way--it keeps all the paths consistent, though you'd lose /all/ configuration if you bind over the whole /etc rather than just parts of it. A unionfs overlay might also be an option, then the /etc-only files can show through; but all these are still far too fragile for my liking. I would much rather we had a more general mechanism of storing the real configuration files (as opposed to just md5s) by dpkg itself, which would enable proper merging of admin changes between old and new conffiles, and perhaps also allow dpkg to implement ucf-like conffile handling (or remove the need for ucf entirely). These could be stored under /var/lib/dpkg/conffiles (for example). For the pristine initscripts use case, it would be possible to mirror a subset under /lib or /etc. But how often does anyone make their system unbootable even with the most extreme init script hacking? We already have rescue boot CDs etc. to cater for this eventuality in any case--why introduce a pile of complexity into the system when it's already redundant? On a related note... While we might criticise rpm for its bad conffile handling, dpkg is itself fairly woeful, and if we change one thing for wheezy+1, it should be sane conffile handling. dpkg should never forget about conffiles; the fact that maintainer scripts have to take care of purging such files is a glaring defect, and possibly the source of the greatest fragility in our maintainer scripts--it's impossible for maintainer scripts to get this right all the time given all the corner cases like downgrades and being taken over by other packages. If this was implemented robustly, the maintainer script should never need to concern itself with such cleanup, or indeed any manual work with conffiles at all, except maybe for deletion ahead of purge where this is needed. And given the frequency this is needed, a defined mechanism to do this would be useful. Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120511124132.gn23...@codelibre.net
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: On 05/11/2012 06:39 PM, Gergely Nagy wrote: Long story short, I still don't see what the fuss is about. The fuss is about we're being told that there will be silent overwriting of configuration files without being prompted about changes, which potentially, will make it horrible to manage upgrades in a decent way without knowing the corner cases. There will be no overwriting of configuration files. There might be changes to defaults, like in every piece of software that is out there. When defaults change, unless care is being taken, things will break, indeed. That is not specific to systemd, and has nothing to do with its defaults being under /lib/systemd. Let me tell you three scenarios, just to demonstrate what I'm getting at: We have three programs: * We have a program, that has a few defaults compiled in, and reads its configuration from /etc/program.conf. Lets call this the 'def-etc' program. * We have another, that has no built in defaults, ships a config file in /etc/program/defaults.conf, and includes snippets from /etc/program/conf.d/. We'll call this 'def-conf.d'. * We have a third program that comes with no compiled-in defaults, but has them in /lib/program instead. It reads configuration from snippets under /etc/program/. We'll call this 'def-lib'. In the first case, since there is a single config file, lets assume we modified that. In the other two cases, we placed snippets in the appropriate directory, and did not touch the config file that contains the default config. When the first program changes its default, since it is compiled in, you get no notofication, no prompt, no nothing - it wasn't in a config file, it was compiled in. When the second program changes its default, since you did not modify the default config, that will be overwritten, and the only notice you get is a Configuration file updated scrolling by, no prompt whatsoever, no visible news, just something you've grown to expect, and trust your tool to handle right. When the third program changes its default, since you can't modifiy the default config, you get no notification, no prompt, no nothing. In all three cases, you get no prompt at all, because no tool in Debian can handle the change of default settings. We're not prepared for that, nor can we ever be. We can handle configuration change, but defaults are *not* configuration. Configuration is things you're allowed to change. On top of that, we're being told that this is the reason why we should use this system, which is totally the inverse of what we've been doing in Debian for years. I can't speak for anyone else who thinks etc-overrides-non-etc isn't the work of the $devil, I merely think that this is a valid way to treat default (unchangeable by the user) settings. It will not work for everyone, nor should it. But for specific cases, it is useful, and makes sense. That is all. -- |8] -- 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/87zk9esxu3.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Am 11.05.2012 14:30, schrieb Marco d'Itri: The problem with etc-overrides-lib is that a file must be copied in full from /lib to /etc to be modified, and then future changes to the same file in /lib will be ignored (so maybe the package will break because these changes are required, etc). This argument goes both ways, though. I've received more than one bug report about uses fiddling with their sysv init scripts, then blindly pressing ok during the upgrade or using non-interactive mode (which kept the locally modified version) and the daemon failed to start due to required changes being missing in the locally modified version. Also, the recent discussions somehow make it look like you constantly need to change the systemd .service files. This should only be necessary in the rarest of cases. Those systemd .service are in the vast majority of cases really simple (most just containing the path to the executable and the type) and comparable in complexity with dbus (system-)service files which have been installed in /usr/share/dbus/ forever. Michael signature.asc Description: OpenPGP digital signature
Getting power saving to work by default in wheezy
I think it would be nice if power saving options (SATA,USB,wireless etc.) were turned on by default when running on laptop. Powertop can report which kernel tunables are set (and you can use it to turn individual options on/off). Laptop task installs pm-utils by default. There is also optional laptop-mode-tools with some overlap with pm-utils. TLP Linux Advanced Power Management is another option (not yet in Debian) https://github.com/linrunner/TLP/wiki/TLP-Linux-Advanced-Power-Management -- 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/20120511125924.GA25057@lisko
Re: RFC: OpenRC as Init System for Debian
]] Gergely Nagy Tollef Fog Heen tfh...@err.no writes: ]] Gergely Nagy In that case, the including file can be changed (by the admin) to be a separate file, that does not include, and get the usual conffile conflict dpkg prompt. How would that work? I have /lib/systemd/system/foo.service and want to change something in it, I then create /etc/systemd/system/foo.service with a copy of the /lib one plus whatever changes I want. The version in /lib is then updated. How is the admin notified? NEWS.Debian, like with any significant default change. So you won't get the dpkg conffile conflict prompt, then? Can you explain what the scenario you talked about would look like, since it's apparently not the scenario I was thinking about? Other than that, the best I can think of is keeping track of what version of the package a default changed in, and triggering something from preinst, when upgrading from a version that is older than the change. This is basically what the tool I'm suggesting to write will do. This however, requires a lot of manual work, might aswell shovel the whole thing from under /lib to /etc then, but then we still didn't solve the problem: suppose there is a unit file that supports starting multiple instances, by way of symlinking. I start to use this feature, I change nothing, just symlink files around. At some point, this feature gets removed, my upgrade succeeds, but my instances won't start anymore, and the best notification I have is something that scrolled by that a conffile was upgraded. You'll get a notification, since the file will have changed, then. -- 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/87boluopkt@qurzaw.varnish-software.com
Re: RFC: OpenRC as Init System for Debian
On May 11, Michael Biebl bi...@debian.org wrote: You can either copy the file or use the .include directive (which was already mentioned) and only override the settings you need. Not with udev or kmod. The problem with etc-overrides-lib is that a file must be copied in full from /lib to /etc to be modified, and then future changes to the same file in /lib will be ignored (so maybe the package will break because these changes are required, etc). This argument goes both ways, though. I've received more than one bug report about uses fiddling with their sysv init scripts, then blindly pressing ok during the upgrade or using non-interactive mode (which kept the locally modified version) and the daemon failed to start due to required changes being missing in the locally modified version. But this is a user error. The point is that with etc-overrides-lib there is no prompt at all when the upstream configuration changes. This is good for Red Hat, because they can guarantee that no relevant changes will appear until the next major release, but is bad for us who actually support system upgrades. -- ciao, Marco signature.asc Description: Digital signature
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 08:30 PM, Marco d'Itri wrote: On May 11, Thomas Goirand z...@debian.org wrote: Long story short, I still don't see what the fuss is about. The fuss is about we're being told that there will be silent overwriting of configuration files without being prompted about changes, which potentially, will make it horrible to manage upgrades in a decent way without knowing the corner cases. No, not even that: if you edit files in /lib without being aware of the consequences then you are an idiot and deserve to suffer for it. The problem with etc-overrides-lib is that a file must be copied in full from /lib to /etc to be modified, and then future changes to the same file in /lib will be ignored (so maybe the package will break because these changes are required, etc). Yes, that's exactly what I don't like, and what I want to avoid!!! I want to be prompted, shown a diff, so I can see what's going on, and then take my own decision based on this diff. So, in fewer words: the current normal behavior in Debian. 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/4fad0f7a.2020...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 08:33 PM, Michael Biebl wrote: Am 11.05.2012 14:30, schrieb Marco d'Itri: The problem with etc-overrides-lib is that a file must be copied in full from /lib to /etc to be modified, and then future changes to the same file in /lib will be ignored (so maybe the package will break because these changes are required, etc). You can either copy the file or use the .include directive (which was already mentioned) and only override the settings you need. So systemd provides both semantics and you can chose which one you want/need. Michael But upon upgrades, it's still a silent thing. The configuration file in /lib is overwritten and users wont know about the changes. 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/4fad0fc2.4010...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 08:28 PM, David Weinehall wrote: Talking about yourself in pluralis majestatis now? Yes, I get it that you are. Or are you somehow assuming that you can speak for all of Debian? I guess you're aware of the fact that I'm a DD too? By reading other replies, I thought there was only yourself and Uoti. Now I can see that Gergely is also on your side, and then I don't think there's a large consensus anymore. 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/4fad11f1.40...@debian.org
Bug#672482: ITP: gedit-projects -- Manage projects in gedit
Package: wnpp Severity: wishlist Owner: B. Clausius ba...@gmx.de * Package name: gedit-projects Version : 1.1 Upstream Author : B. Clausius ba...@gmx.de * URL : https://launchpad.net/gedit-projects * License : GPL-3+ Programming Lang: Python Description : Manage projects in gedit For this plugin a project is just a directory path. A list of last opened files is stored in the user config directory. In the project directory itself no data is stored or changed by the plugin. In the sidebar are two lists: * Open Projects: projects with at least one open file * All projects: project directories that are known to the plugin, projects that contain subprojects are shown in a tree structure . In the context menu you can perform some actions, including: * Open Project: restore all recently opened files of a project * View Project Folder: the project folder is opened with the default program * Close Project: all project files are closed (the file list is preserved) * Add Folder, Remove Folder: specify which folders are known as a project * Find Subprojects: search within the project folder for nested projects After installing and activating the plugin, you can invoke the settings dialog. There you can set up a directory that can be scanned for projects. Project directories are recognized by specific file names within the directory like VCS folders or files for build systems. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120511132146.2976.85609.reportbug@System7
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 07:04 PM, Gergely Nagy wrote: Steve McIntyre st...@einval.com writes: Jean-Christophe Dubacq wrote: If dpkg kept a copy of the original configuration file (to be retrieved at all times), it would be easier to spot local changes. I use etckeeper to do that, but it's a bit tiresome to isolate all local changes (I have to save the diffs somewhere) (and a lost hope if you do install etckeeper late in the workstation life). My git-fu is probably not good enough (I am probably looking for a pristine branch and a rebased local branch used in production). You might be interested in a proposal at UDS this week: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-dpkg-pristine-conffiles So basically, we'd have a directory of files under /etc that are not conffiles, and even made 0440. Amusing proposal. Why not move them outside of /etc then, if they are not configuration files, and should not be touched by the user? (Yeah, sure, they can be moved out of /etc, but that doesn't stop the original proposal being amusing, sorry.) The setting of unix rights 0440 is indeed very amusing. The only nice point about this proposal is that it's going to make happy hard drive factories: they will be able to sell bigger hard drive for no valid good reasons. Seriously, can't someone who broke his configuration wget the package, and use mc to get into the .deb and get the original configuration file??? Overall, all this proposal assumes that users are idiots who love to change things they don't understand, and aren't smart enough to restore. I can't believe that newbies favorite game would be changing randomly the content of /etc/init. And at the same time, I can't believe that experts tweaking upstart jobs wouldn't know how to restore them. 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/4fad144c.1050...@debian.org
Bug#672484: ITP: gedit-classbrowser3g -- Class Browser for gedit
Package: wnpp Severity: wishlist Owner: B. Clausius ba...@gmx.de * Package name: gedit-classbrowser3g Version : 1.0 Upstream Author : B. Clausius ba...@gmx.de * URL : https://launchpad.net/gedit-classbrowser3g * License : GPL-3+ Programming Lang: Python Description : Class Browser for gedit The class browser is located in the side pane and lists functions, classes, etc. in a tree view. The default parser uses exuberant ctags to support a wide range of languages. Special parsers are used for Python, HTML, XML/Mallard/DocBook, Diff, Ruby and Markdown. -- 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/20120511133251.3329.87504.reportbug@System7
Re: Getting power saving to work by default in wheezy
On 11.05.2012 14:59, Touko Korpela wrote: I think it would be nice if power saving options (SATA,USB,wireless etc.) were turned on by default when running on laptop. Powertop can report which kernel tunables are set (and you can use it to turn individual options on/off). Laptop task installs pm-utils by default. There is also optional laptop-mode-tools with some overlap with pm-utils. TLP Linux Advanced Power Management is another option (not yet in Debian) https://github.com/linrunner/TLP/wiki/TLP-Linux-Advanced-Power-Management pm-utils contains the pm-powersave tool, which is triggered via upower when the AC state changes. pm-powersave applies power saving settings, see the hooks in /usr/lib/pm-utils/power.d/ Some of those are disabled by default, like the sata_alpm hook, since they were reported to cause issues on certain hardware / driver configurations in the past. We also removed hooks which have not proven to be effective. Our decisions which hooks to enable/disable were also based on Colin Kings fine work on that topic, who did actually measure the influence of this settings on the power consumption: https://blueprints.launchpad.net/ubuntu/+spec/hardware-p-kernel-power-management http://zinc.canonical.com/~cking/power-benchmarking/pm-utils-results/results.txt Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: RFC: OpenRC as Init System for Debian
m...@linux.it (Marco d'Itri) writes: On May 11, Nikolaus Rath nikol...@rath.org wrote: Wrong: since you have to copy the whole file to override it, and files in /lib have no conffiles handling, after an upgrade you will not know what was changed by you and what was changed upstream. I think everyone here agrees with that. The interesting case is when files in /etc/ can either explicitly include the /lib file, or implicitly override the /lib settings. I do not know about any package which work this way, Well, systemd has been mentioned one or two times here in the last weeks. but there is any then the problem is not different from packages which support multiple configuration file fragments in /etc, ship the default configuration in /etc and allow it to be modified by other configuration fragments in /etc (e.g. Apache). I agree, and therefore I'm surprised that some people are getting so aggravated about this if the default configuration is installed in /lib rather than /etc. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- 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/8762c27shc@inspiron.ap.columbia.edu
Re: Getting power saving to work by default in wheezy
On Friday 11 May 2012 06:29 PM, Touko Korpela wrote: I think it would be nice if power saving options (SATA,USB,wireless etc.) were turned on by default when running on laptop. Powertop can report which kernel tunables are set (and you can use it to turn individual options on/off). Laptop task installs pm-utils by default. There is also optional laptop-mode-tools with some overlap with pm-utils. TLP Linux Advanced Power Management is another option (not yet in Debian) https://github.com/linrunner/TLP/wiki/TLP-Linux-Advanced-Power-Management For laptop-mode-tools, it is enabled by default. We have a whilelist of modules that are ON when you install. And all of what you have mentioned is already in the whitelist. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. signature.asc Description: OpenPGP digital signature
Re: RFC: OpenRC as Init System for Debian
* Thomas Goirand z...@debian.org [120511 04:45]: On 05/11/2012 04:04 AM, David Weinehall wrote: From: http://en.wikipedia.org/wiki/Configuration_file In computing, configuration files, or config files configure the initial settings for some computer programs. They are used for user applications, server processes and operating system settings. The fact that these files are in /lib and shouldn't be touched by the admin doesn't make them less configuration files. They still match the above definition from Wikipedia. And debian-policy isn't set in stone. Otherwise it wouldn't have last been revised in February 2012 :) The debian-policy maybe, but the FHS, and config files in /etc *is* a very strong policy that you will not change in Debian, and for very valid reasons already described in this thread. The FHS is very specific that /etc is for *Host-specific* system configuration, not upstream defaults or distribution-specific configuration. The clear intent is that this is where files that are intended to be modified by the local system administrator are placed. Files containing distribution-specific defaults, whether they match some definition of configuration file or not, do not belong here unless the they are also intended to be edited by the local sysadmin. Using a Wikipedia definition must be done with careful consideration, as they are often either over generalized or too specific. In this case I believe the Wikipedia definition is not in the least relevant to the subtleties being disputed here. Debian policy does not explicitly differentiate between host-specific configuration and Debian-provided default configuration, but it does say, Typically, configuration files are intended to be modified by the system administrator (if needed or desired) to conform to local policy or to provide more useful site-specific behavior. Following the FHS is, however, a must in Debian policy except where policy explicitly provides an exception or conflicts with the FHS. It is clear to me that etc-overrides-non-etc is perfectly compliant with Debian policy as long as the sysadmin does not need to modify the non-etc files to obtain the desired behavior. I have been using Debian since 1998, and IME the cases where changes to the Debian-supplied configuration files would have caused breakage if the Debian defaults had been in /usr/lib/package and only local modifications were in /etc have been rare. On the other hand, the cases where this model would have both obviated the need for a manual merge and resulted in exactly the configuration I intended are extremely common. Gergely Nagy has shown elsewhere in this thread that no matter which configuration model you use, there are cases where you might not get a notification of incompatible default configuration from dpkg on upgrade. On the other hand, the etc-overrides-non-etc model significantly simplifies most of the common default-configuration-change cases. For clarity, the etc-overrides-non-etc model that I am talking about is where the file in /etc can override individual values, not where the file in /etc must replace the entirety of the non-etc configuration. While I agree that etc-overrides-non-etc may not be the best model for all software, it is the best for some and at least as good for many other packages. ...Marvin -- 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/20120511150832.ga7...@cleo.wdw
Bug#672499: ITP: rake-compiler -- Rake-based Ruby Extension (C, Java) task generator
Package: wnpp Owner: Youhei SASAKI uwab...@gfd-dennou.org Severity: wishlist * Package name: rake-compiler Version : 0.8.1 Upstream Author : Luis Lavena * URL or Web page : http://github.com/luislavena/rake-compiler * License : Expat Description : Rake-based Ruby Extension (C, Java) task generator The rake-compiler is first and foremost a productivity tool for Ruby developers. It's goal is to make the busy developer's life easier by simplifying the building and packaging of Ruby extensions by simplifying code and reducing duplication. . It follows *convention over configuration* by advocating a standardized build and package structure for both C and Java based RubyGems. . Rake-compiler is the result of many hard-won experiences dealing with several diverse RubyGems that provided native extensions for different platforms and different user configurations in different ways. Details such as differences in code portability, differences in code clarity, and differences in project directory structure often made it very difficult for newcomers to those RubyGems. --- Youhei SASAKI uwab...@gfd-dennou.org uwab...@debian.or.jp GPG fingerprint: 4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07 -- 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/87ipg2d83j.wl%uwab...@gfd-dennou.org
Bug#672501: ITP: ruby-albino -- Ruby wrapper for pygments
Package: wnpp Owner: Youhei SASAKI uwab...@gfd-dennou.org Severity: wishlist * Package name: ruby-albino Version : 1.3.3 Upstream Author : Chris Wanstrath * URL or Web page : http://github.com/github/albino * License : Expat Description : Ruby wrapper for pygments Albino is a ruby wrapper for python-pygmentize. . Pygments aims to be a generic syntax highlighter for general use in all kinds of software such as forum systems, wikis or other applications that need to prettify source code. --- Youhei SASAKI uwab...@gfd-dennou.org uwab...@debian.or.jp GPG fingerprint: 4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07 -- 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/87havmd802.wl%uwab...@gfd-dennou.org
Bug#672503: ITP: ruby-classifier -- Ruby module to allow Bayesian and other types of classifications
Package: wnpp Owner: Youhei SASAKI uwab...@gfd-dennou.org Severity: wishlist * Package name: ruby-classifier Version : 1.3.3 Upstream Author : Lucas Carlson, David Fayram II, Cameron McBride * URL or Web page : http://classifier.rufy.comp * License : LGPL-2.0+ Description : Ruby module to allow Bayesian and other types of classifications Classifier is a general module to allow Bayesian and other types of classifications. . This package provides Bayes classifier and Latent Semantic Indexer. Bayesian Classifiers are accurate, fast, and have modest memory requirements. Latent Semantic Indexing engines are not as fast or as small as Bayesian classifiers, but are more flexible, providing fast search and clustering detection as well as semantic analysis of the text that theoretically simulates human learning. --- Youhei SASAKI uwab...@gfd-dennou.org uwab...@debian.or.jp GPG fingerprint: 4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07 -- 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/87fwb6d7v1.wl%uwab...@gfd-dennou.org
Re: Configuration file handling
Roger Leigh rle...@codelibre.net writes: I would much rather we had a more general mechanism of storing the real configuration files (as opposed to just md5s) by dpkg itself, which would enable proper merging of admin changes between old and new conffiles, and perhaps also allow dpkg to implement ucf-like conffile handling (or remove the need for ucf entirely). These could be stored under /var/lib/dpkg/conffiles (for example). Yes, this. The current method for restoring a deleted or modified configuration file to its original state in the absence of add-on tools like etckeeper is relentlessly obscure. I've had to walk very experienced UNIX admins through it, since the various things you have to do are very unintuitive. We need to do better, including a top-level, user-visible command to easily restore the pristine configuration of a package. We could get some of the way there by having a standard option to apt-get and aptitude to reinstall a package with --force-confnew --force-confmiss, but better support at the dpkg layer lets us also do other interesting things, as you note. On a related note... While we might criticise rpm for its bad conffile handling, dpkg is itself fairly woeful, and if we change one thing for wheezy+1, it should be sane conffile handling. dpkg should never forget about conffiles; the fact that maintainer scripts have to take care of purging such files is a glaring defect, and possibly the source of the greatest fragility in our maintainer scripts--it's impossible for maintainer scripts to get this right all the time given all the corner cases like downgrades and being taken over by other packages. If this was implemented robustly, the maintainer script should never need to concern itself with such cleanup, or indeed any manual work with conffiles at all, except maybe for deletion ahead of purge where this is needed. And given the frequency this is needed, a defined mechanism to do this would be useful. Agreed. The criticisms of rpm are nice for making us feel better ourselves and helping get rid of the lingering trauma of having used Red Hat (speaking for myself at least *grin*), but they don't make Debian any better. We have some significant problems ourselves that we could fix. -- 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/87aa1e7lbw@windlord.stanford.edu
Bug#672505: ITP: ruby-fast-stemmer -- Ruby module of Fast Porter stemmer based on a C version algorithm
Package: wnpp Owner: Youhei SASAKI uwab...@gfd-dennou.org Severity: wishlist * Package name: ruby-fast-stemmer Version : 1.0.1 Upstream Author : Roman Shterenzon * URL or Web page : http://github.com/romanbsd/fast-stemmer * License : Expat Description : Ruby module of Fast Porter stemmer based on a C version algorithm Fast-stemmer is simply a wrapping around multithreaded Porter stemming algorithm. . This module adds a String::stem method, and it's in order of magnitude faster (and uses much less memory) than the pure Ruby implementation of stemmer. --- Youhei SASAKI uwab...@gfd-dennou.org uwab...@debian.or.jp GPG fingerprint: 4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07 -- 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/87ehqqd7pu.wl%uwab...@gfd-dennou.org
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: Section 10.7.2 of dpm: Any configuration files created or used by your package must reside in |/etc|. Configuration file is a term of art that is previously defined in the Policy document. It doesn't mean what you're taking it to mean. There isn't anything about etc-overrides-lib that violates the letter of Policy. (The expectations of a Debian administrator are another question.) -- 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/8739767l76@windlord.stanford.edu
Bug#672506: ITP: ruby-directory-watcher -- Watch directory/files and Generate events by file change
Package: wnpp Owner: Youhei SASAKI uwab...@gfd-dennou.org Severity: wishlist * Package name: ruby-directory-watcher Version : 1.4.1 Upstream Author : Tim Pease * URL or Web page : http://gemcutter.org/gems/directory_watcher * License : Expat Description : Watch directory/files and Generate events by file change The directory watcher operates by scanning a directory at some interval and generating a list of files based on a user supplied glob pattern. As the file list changes from one interval to the next, events are generated and dispatched to registered observers. . Three types of events are supported - added, modified, and removed. --- Youhei SASAKI uwab...@gfd-dennou.org uwab...@debian.or.jp GPG fingerprint: 4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07 -- 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/87d36ad7k0.wl%uwab...@gfd-dennou.org
Bug#672507: ITP: ruby-posix-spawn -- Ruby Implementation of posix_spawn(2) for faster process spawning
Package: wnpp Owner: Youhei SASAKI uwab...@gfd-dennou.org Severity: wishlist * Package name: ruby-posix-spawn Version : 0.3.6 Upstream Author : Ryan Tomayko, Aman Gupta * URL or Web page : http://github.com/rtomayko/posix-spawn * License : LGPL-2.1+, Expat Description : Ruby Implementation of posix_spawn(2) for faster process spawning The posix-spawn library aims to implement a subset of the Ruby 1.9 `Process::spawn` interface in a way that takes advantage of fast process spawning interfaces when available and provides sane fallbacks on systems that do not. . `fork(2)` calls slow down as the parent process uses more memory due to the need to copy page tables. In many common uses of fork(), where it is followed by one of the exec family of functions to spawn child processes (`Kernel#system`,`IO::popen`, `Process::spawn`, etc.), it's possible to remove this overhead by using the use of special process spawning interfaces (`posix_spawn()`, `vfork()`, etc.) --- Youhei SASAKI uwab...@gfd-dennou.org uwab...@debian.or.jp GPG fingerprint: 4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07 -- 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/87bolud7d6.wl%uwab...@gfd-dennou.org
Bug#672508: ITP: ruby-redcarpet -- Fast, safe and extensible Markdown to (X)HTML parser written in Ruby
Package: wnpp Owner: Youhei SASAKI uwab...@gfd-dennou.org Severity: wishlist * Package name: ruby-redcarpet Version : 2.1.1 Upstream Author : Natacha Porte', Vincent Marti * URL or Web page : http://github.com/tanoku/redcarpet * License : Expat Description : Fast, safe and extensible Markdown to (X)HTML parser for Ruby Redcarpet is Ruby library for Markdown processing. This library provides fast, safe and extensible Markdown to (X)HTML parser. --- Youhei SASAKI uwab...@gfd-dennou.org uwab...@debian.or.jp GPG fingerprint: 4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07 -- 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/87aa1ed6yg.wl%uwab...@gfd-dennou.org
Bug#672509: ITP: jekyll -- Simple, blog aware, static site generator written in Ruby
Package: wnpp Owner: Youhei SASAKI uwab...@gfd-dennou.org Severity: wishlist * Package name: jekyll Version : 0.11.2 Upstream Author : Tom Preston-Werner * URL or Web page : http://github.com/mojombo/jekyll * License : Expat Description : Simple, blog aware, static site generator written in Ruby Jekyll is a simple, blog aware, static site generator. It takes a template directory (representing the raw form of a website), runs it through Textile or Markdown and Liquid converters, and spits out a complete, static website suitable for serving with Apache or your favorite web server. . This is also the engine behind GitHub Pages(http://pages.github.com), which you can use to host your project's page or blog right here from GitHub. --- Youhei SASAKI uwab...@gfd-dennou.org uwab...@debian.or.jp GPG fingerprint: 4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07 -- 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/878vgyd6up.wl%uwab...@gfd-dennou.org
Re: RFC: OpenRC as Init System for Debian
On 11/05/2012 15:29, Thomas Goirand wrote: The setting of unix rights 0440 is indeed very amusing. Yes. Maybe the mean to chmod a-w everything, for some applications will not work with so large modes (sudo, for example). The only nice point about this proposal is that it's going to make happy hard drive factories: they will be able to sell bigger hard drive for no valid good reasons. Come on! Less than 20M, it could trivially be compressed. Seriously, can't someone who broke his configuration wget the package, and use mc to get into the .deb and get the original configuration file??? Not necessarily. 1) Many configuration files are dynamically generated through debconf questions, which root may not be able to rerun to obtain the same result. 2) What if you borked your network configuration? What if the malfunction is due to a complex interaction between several packages (let's say, a FORCESSL option on some service A, and a libssl upgrade breaks A but only if the FORCESSL option is used?) Being able 3) I think etckeeper could do the job without much development. However, it will make the hard drive factories happy (according to you). Overall, all this proposal assumes that users are idiots who love to change things they don't understand, and aren't smart enough to restore. I can't believe that newbies favorite game would be changing randomly the content of /etc/init. And at the same time, I can't believe that experts tweaking upstart jobs wouldn't know how to restore them. I find your attitude assumes users always have the knowledge and the time to investigate everything. This is not the reality. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 11:08 PM, Marvin Renich wrote: For clarity, the etc-overrides-non-etc model that I am talking about is where the file in /etc can override individual values, not where the file in /etc must replace the entirety of the non-etc configuration. This case is much much more acceptable to me. I wouldn't see any problem with it. I just don't want that new configuration values to be silently ignored upon upgrades, that's all I'm saying. 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/4fad3cb8.1080...@debian.org
Re: Bug#672507: ITP: ruby-posix-spawn -- Ruby Implementation of posix_spawn(2) for faster process spawning
On Sat, May 12, 2012 at 01:12:37 +0900, Youhei SASAKI wrote: Package: wnpp Owner: Youhei SASAKI uwab...@gfd-dennou.org Severity: wishlist * Package name: ruby-posix-spawn Do you really need a whole package for a single syscall wrapper? Cheers, Julien signature.asc Description: Digital signature
Re: RFC: OpenRC as Init System for Debian
On 05/12/2012 12:22 AM, Jean-Christophe Dubacq wrote: I find your attitude assumes users always have the knowledge and the time to investigate everything. This is not the reality. Sincerly, Not at all. Anyone without the knowledge will not be able to restore anything anyway. Anyone with the knowledge will know how to get the original file. Yes, it will take more time to do that, but do you think this is the kind of operation you need to do every day? I'd say, once every 5 years maybe? Very rarely, I do a purge then reinstall, but never it happened to me that my system was in such state that I had to recover by hand a configuration file, using the single user boot. Did this happen to you at some point? Anyone else? I'm not bashing the idea so much, as it is a harmless one, I just think it is simply a useless feature, and I don't think it's worth investing any human time on this. 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/4fad4670.5030...@debian.org
Re: RFC: OpenRC as Init System for Debian
On 11/05/2012 19:03, Thomas Goirand wrote: On 05/12/2012 12:22 AM, Jean-Christophe Dubacq wrote: I find your attitude assumes users always have the knowledge and the time to investigate everything. This is not the reality. Sincerly, Not at all. Anyone without the knowledge will not be able to restore anything anyway. Anyone with the knowledge will know how to get the original file. Yes, it will take more time to do that, but do you think this is the kind of operation you need to do every day? I'd say, once every 5 years maybe? Very rarely, I do a purge then reinstall, but never it happened to me that my system was in such state that I had to recover by hand a configuration file, using the single user boot. Did this happen to you at some point? Anyone else? Yes, several times indeed. Most times when upgrading network packages at the same time. I'm not bashing the idea so much, as it is a harmless one, I just think it is simply a useless feature, and I don't think it's worth investing any human time on this. I think it would be really great to have some program being able to output all manual differences to all /etc files really useful for maintenance. I used to do that, but some rapidly evolving configuration files make it quickly unmaintainable (php.ini comes to mind: I always have to put back the upload_max_filesize to a superior value, and this one-line difference makes something that should be really, really simple (upgrading php, even using stable+security) a pain because one gets manually prompted about the differences, even if they are trivial to merge. -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: Seriously, can't someone who broke his configuration wget the package, and use mc to get into the .deb and get the original configuration file??? FWIW, I'd love an easier way to keep track of my /etc, where upstream changes and my own are on a separate branch. So the idea is not entirely silly, and would be useful even for folk like myself, who - at least I dare hope so - are not entirely clueless. The solution, however, is very simple: wrap dpkg calls, and have a list of files to watch for. Whenever a package touches a file that's on the list, fire a trigger, that can run a hook. Said hook can be something provided by etckeeper or similar, that would extract the appropriate file from the deb, and commit it to the upstream branch of /etc, for example. Then proceed on, and do whatever else needs to be done. And boom! We have a way to allow experienced users to keep track of their /etc properly, that does not fall on its face when I notice a bad config change in the upstream config two updates later. Oh, and this whole thing need not live in /etc at all, and can follow anything, not just config files. It's perfectly able to notice changes in /lib/systemd too, or pretty much anywhere else. I actually just implemented that (it took 10 minutes, becuase I screwed up first), and will be testing how it works over the next few weeks. -- |8] -- 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/87y5oyr0eq@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
m...@linux.it (Marco d'Itri) writes: On May 11, Thomas Goirand z...@debian.org wrote: Long story short, I still don't see what the fuss is about. The fuss is about we're being told that there will be silent overwriting of configuration files without being prompted about changes, which potentially, will make it horrible to manage upgrades in a decent way without knowing the corner cases. No, not even that: if you edit files in /lib without being aware of the consequences then you are an idiot and deserve to suffer for it. The problem with etc-overrides-lib is that a file must be copied in full from /lib to /etc to be modified, and then future changes to the same file in /lib will be ignored (so maybe the package will break because these changes are required, etc). And...? If it were somewhere under /usr/share/doc/$package/examples, how would that be different? (Assuming that the *default* would then be wired into the binary) You'd still need to copy the file, and if the defaults change under you, you're screwed. Even worse if you have to dig out the possible options, and their defaults from (possibly stale) documentation. But even if everything is in /etc, you can still easily screw yourself over: conf.d/ can very easily break the exact same way. It's not etc-overrides-lib that is the problem. It's defaults changing without notice that is. With the defaults being broken out into files, making a tool that notifies the user preemptively when a default will change, and stops the upgrade, is possible, and is not even hard. You can't do that when the defaults are either unavailable, or subject to change by the admin. -- |8] -- 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/87r4uqqzwt@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: On 05/11/2012 08:33 PM, Michael Biebl wrote: Am 11.05.2012 14:30, schrieb Marco d'Itri: The problem with etc-overrides-lib is that a file must be copied in full from /lib to /etc to be modified, and then future changes to the same file in /lib will be ignored (so maybe the package will break because these changes are required, etc). You can either copy the file or use the .include directive (which was already mentioned) and only override the settings you need. So systemd provides both semantics and you can chose which one you want/need. Michael But upon upgrades, it's still a silent thing. The configuration file in /lib is overwritten and users wont know about the changes. Likewise for *every* other case where the default changes. There's nothing different. Nothing. Nada. Except you can write a tool to warn in *this* case, because the defaults are available in a diffable format. -- |8] -- 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/87mx5eqztf@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
OoO Peu avant le début de l'après-midi du vendredi 11 mai 2012, vers 13:20, Gergely Nagy alger...@balabit.hu disait : In other words, it does *exactly* the same thing systemd is criticised for. Which doesn't mean that it's a good practice. Tell me what you would gain, if there were no files under /lib/systemd, and all of these were compiled into the binary, please. Because that's the other option, as you *do not* let users change the defaults. You let them override them, you let them configure the system. (And that *is* being done in /etc.) There are *very* few programs that come without any kind of default, and even less, that let you change the default too. apt does not let you change the defaults, nor does dpkg. Both allow you to change their settings, but without recompiling, you can't change the defaults. Same happens with systemd, the difference is that it's easier to see the defaults, as they're broken out into files that are easy to copy and change as needed. Yes, that's very true. We are just used that the kind of defaults in init to be in /etc. But nothing is set in stone. I was first against this etc-override-lib behaviour but your arguments are sound and I am now convinced that we should keep the way systemd is doing things. Moreover, in the case of systemd, there are other mechanisms that can be used to customize a configuration file for the more common modifications (handling dependencies and ordering) using symbolic links. This way, there is no need to copy the file from /lib in /etc to do the modifications. Still in the case of systemd, a README put in /etc/systemd may be used to explain the whole etc-override-lib to users that are not expecting such behaviour. A README is not a configuration file but there is one in /etc/init.d as well. -- Vincent Bernat ☯ http://vincent.bernat.im #if 0 2.2.16 /usr/src/linux/fs/buffer.c pgpOoyGiMli3V.pgp Description: PGP signature
Re: RFC: OpenRC as Init System for Debian
SEEWEB - Marco d'Itri m...@seeweb.it writes: But this is a user error. The point is that with etc-overrides-lib there is no prompt at all when the upstream configuration changes. Bzzt. There's no prompt ever when upstream defaults change. Unless *all* the defaults are laid out in /etc, *AND* the user modified that particular file. If suddenly /etc/$program.conf, which I never modified changes, and I have custom snippets under /etc/$program.d/*.conf, those snippets might very well break. Do I get a prompt? No. The closest I get is that $program.conf was upgraded. I see no diff, unless I keep track of my /etc in other ways. -- |8] -- 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/87ipg2qzmc@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand z...@debian.org writes: On 05/11/2012 11:08 PM, Marvin Renich wrote: For clarity, the etc-overrides-non-etc model that I am talking about is where the file in /etc can override individual values, not where the file in /etc must replace the entirety of the non-etc configuration. This case is much much more acceptable to me. I wouldn't see any problem with it. I just don't want that new configuration values to be silently ignored upon upgrades, that's all I'm saying. I agree, that seeing the defaults change would be lovely. With the defaults being in /lib, it's possible to write a tool that notifies you. With the defaults being in a monolithic blob, possibly inside a binary, it is not. -- |8] -- 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/87ehqqqzeu@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
Tollef Fog Heen tfh...@err.no writes: ]] Gergely Nagy Tollef Fog Heen tfh...@err.no writes: ]] Gergely Nagy In that case, the including file can be changed (by the admin) to be a separate file, that does not include, and get the usual conffile conflict dpkg prompt. How would that work? I have /lib/systemd/system/foo.service and want to change something in it, I then create /etc/systemd/system/foo.service with a copy of the /lib one plus whatever changes I want. The version in /lib is then updated. How is the admin notified? NEWS.Debian, like with any significant default change. So you won't get the dpkg conffile conflict prompt, then? Can you explain what the scenario you talked about would look like, since it's apparently not the scenario I was thinking about? I believe we're talking about the same scenario, and I was hasty to suggest that NEWS.Debian is the only way - see below. Other than that, the best I can think of is keeping track of what version of the package a default changed in, and triggering something from preinst, when upgrading from a version that is older than the change. This is basically what the tool I'm suggesting to write will do. During my trip back home, I wrote that tool. It's very crude and hackish at the moment, but with a little bit of support from, say, apt (or perhaps dpkg, but that's less likely), it could be made into something nice. Basically, I divert dpkg, and catch all -i calls, see what debs we're called on, list the files therein. If any of the files are on the watchlist, I launch the triggers, with apropriate parameters. The only trigger I have implemented so far will extract the files that triggered it, and put them in version control, onto the appropriate upstream branch. Then proceed on. I could enhance it to abort the installation, or send mail, or pause and do some ucf magic, to check whether overrides in /etc exist at all, and so on and so forth. I only needed the shovel-into-a-vcs-branch thing, so that's what I have. Adding the rest isn't hard, either. The advantage here, is that the packager need not keep track of what changed in which version, and admins can extend the watchlist, and change the triggered actions too, to make it better suit their own needs. This also means that in case of bugs, we don't need to fix maintainer scripts, just a single application. -- |8] -- 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/87aa1eqz1g@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
On Fri, May 11, 2012 at 11:08:32AM -0400, Marvin Renich wrote: The FHS is very specific that /etc is for *Host-specific* system configuration, not upstream defaults or distribution-specific configuration. The clear intent is that this is where files that are intended to be modified by the local system administrator are placed. No, this is a total retcon. When the FHS was written, this was definitely NOT a shared understanding of a difference between host-specific configuration and upstream defaults / distribution-specific configuration. Distribution defaults still would go in /etc whenever it was expected that an admin might want to edit the file. This has been the convention for more than a decade. Files containing distribution-specific defaults, whether they match some definition of configuration file or not, do not belong here unless the they are also intended to be edited by the local sysadmin. Yes. The issue is not that either system is a violation of the standard, because intent is relevant here. If the upstream *intends* the file to be a template that's overridden using a separate file, then /usr is the right place. If the upstream intends the user to edit the provided file to make their changes, it belongs in /etc. If the defaults are built into the binary, that's perfectly fine too. What *is* an issue is when upstreams decide to ship their defaults in /usr, but require users to duplicate information between /usr templates and /etc config files and ignore the contents of /usr in favor of the contents of /etc. This is also not a violation of FHS, but it IS a crappy design. When software is not able to override configuration *settings* with fine granularity via /etc, the entire thing should go under /etc. Doing otherwise makes this horrible for upgrades. -- 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: RFC: OpenRC as Init System for Debian
Steve Langasek vor...@debian.org writes: What *is* an issue is when upstreams decide to ship their defaults in /usr, but require users to duplicate information between /usr templates and /etc config files and ignore the contents of /usr in favor of the contents of /etc. This is also not a violation of FHS, but it IS a crappy design. When software is not able to override configuration *settings* with fine granularity via /etc, the entire thing should go under /etc. Doing otherwise makes this horrible for upgrades. Yes, this, with the caveat that coming up with a new tool that would do the right thing, as Tollef discussed, would be a reasonable substitute for putting everything in /etc. -- 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/87sjf6ih8l@windlord.stanford.edu
Re: RFC: OpenRC as Init System for Debian
* Steve Langasek vor...@debian.org [120511 16:17]: On Fri, May 11, 2012 at 11:08:32AM -0400, Marvin Renich wrote: The FHS is very specific that /etc is for *Host-specific* system No, this is a total retcon. When the FHS was written, this was definitely NOT a shared understanding of a difference between host-specific configuration and upstream defaults / distribution-specific configuration. I obviously read more into host-specific than was intended. Distribution defaults still would go in /etc whenever it was expected that an admin might want to edit the file. This has been the convention for more than a decade. Agree completely. See the next sentence. Files containing distribution-specific defaults, whether they match some definition of configuration file or not, do not belong here unless the they are also intended to be edited by the local sysadmin. Yes. The issue is not that either system is a violation of the standard, because intent is relevant here. If the upstream *intends* the file to be a template that's overridden using a separate file, then /usr is the right place. If the upstream intends the user to edit the provided file to make their changes, it belongs in /etc. If the defaults are built into the binary, that's perfectly fine too. I agree completely. I was responding specifically to the assertion that the definition of configuration file from Wikipedia meant that Debian must put files containing distribution-specific defaults in /etc, regardless of whether or not they were intended to be modified by the local sysadmin. What *is* an issue is when upstreams decide to ship their defaults in /usr, but require users to duplicate information between /usr templates and /etc config files and ignore the contents of /usr in favor of the contents of /etc. This is also not a violation of FHS, but it IS a crappy design. Again, I agree completely. See the part of my message that you did not include where I clarified to which etc-overrides-non-etc model I was referring. When software is not able to override configuration *settings* with fine granularity via /etc, the entire thing should go under /etc. Doing otherwise makes this horrible for upgrades. Absolutely. Again, see my clarification of how I was using etc-overrides-non-etc. I did not go into what I think is wrong with default in /usr, copy entirety to /etc and edit in order to override a single setting because I was specifically trying to address the other poster's assertion that placing anything that matches the Wikipedia definition of configuration file anywhere other than /etc was a violation of a must in Debian policy. ...Marvin -- 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/20120511210825.gc7...@cleo.wdw
Bug#672549: ITP: libballoontip-java -- Balloon Tips for Java
Package: wnpp Severity: wishlist Owner: Stefan Handschuh handschuh.ste...@googlemail.com * Package name: libballoontip-java Version : 1.2.1 Upstream Author : Bernhard Pauler bernhard_pau...@dev.java.net, Tim Molderez nfe...@dev.java.net * URL : http://java.net/projects/balloontip * License : BSD Programming Lang: Java Description : Balloon Tips for Java Provides balloon-tips for use in Java Swing applications to be laid over any kind of swing-component such as JButton. -- 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/20120511222824.5669.99716.reportbug@m1330
Re: Licenses not in /usr/share/common-licenses
On Tue, May 8, 2012 at 1:49 PM, Matthew Woodcraft wrote: Russ Allbery wrote: I think the core question is: why is base-files special? Yes, it's essential and all, but that doesn't address the case of packages being downloaded separate from Debian, or unpacked by hand, in which case we don't include a license. If we're legally fine with that, I'm having a hard time seeing the clear distinction between that and a dependency on another package including the license. Surely this has been discussed before? I don't remember seeing it on the debian-policy list since I started working on Policy. There's a fairly lengthy discussion starting at http://lists.debian.org/debian-policy/2000/11/msg00235.html So, I think [0] is the most astute message in that thread. Succinctly, the copyright file itself is irrelevant in the source package since the upstream source should have all of that information already, and at least for the GPL you can distribute source packages as is. Thus, the issue is reduced to the need for full license texts only in all binary packages. That doesn't seem to be a current requirement and copyright file symlinks are often used today, so perhaps a first step would be to make that a part of the Debian policy? Secondly, since the copyright file in the source package doesn't actually need full license text, license file references should be allowable there; as long as appropriate helpers are written that can take those (reference only) source copyright files and fill in the appropriate full license texts for the binary files that it generates. Eliminating the tedium of copying, pasting, and reformatting license texts would be a wonderful simplification and time reducer. Best wishes, Mike [0] http://lists.debian.org/debian-policy/2000/11/msg00251.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/CANTw=morcraz-_5bi0bfo82e6ekhdkpp_g1cyoedcpgs_qh...@mail.gmail.com
Re: Configuration file handling (was: RFC: OpenRC as Init System for Debian)
On Fri, 2012-05-11 at 13:41:32 +0100, Roger Leigh wrote: On Fri, May 11, 2012 at 11:53:34AM +0100, Steve McIntyre wrote: Jean-Christophe Dubacq wrote: If dpkg kept a copy of the original configuration file (to be retrieved at all times), it would be easier to spot local changes. I use etckeeper to do that, but it's a bit tiresome to isolate all local changes (I have to save the diffs somewhere) (and a lost hope if you do install etckeeper late in the workstation life). My git-fu is probably not good enough (I am probably looking for a pristine branch and a rebased local branch used in production). You might be interested in a proposal at UDS this week: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-dpkg-pristine-conffiles I've just skimmed over this, and at first sight I'm not planning on merging something like that into dpkg. I would much rather we had a more general mechanism of storing the real configuration files (as opposed to just md5s) by dpkg itself, which would enable proper merging of admin changes between old and new conffiles, and perhaps also allow dpkg to implement ucf-like conffile handling (or remove the need for ucf entirely). These could be stored under /var/lib/dpkg/conffiles (for example). This has been discussed before, it's on dpkg's roadmap, there's even some draft code by Sean Finney, but the semantics where not right. I started reworking it some time ago, and it's on my short term TODO, either for 1.16.x or 1.17.x. regards, 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/20120512020303.ga23...@gaara.hadrons.org
Re: Licenses not in /usr/share/common-licenses
Michael Gilbert michael.s.gilb...@gmail.com writes: So, I think [0] is the most astute message in that thread. [0] http://lists.debian.org/debian-policy/2000/11/msg00251.html I thought that too when I first read it, but later in the thread are very cogent arguments for why it's wrong and providing a complete copy of the GPL with binaries is required. -- 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/87bolu16gr@windlord.stanford.edu
Re: Licenses not in /usr/share/common-licenses
Le Fri, May 11, 2012 at 10:10:17PM -0400, Michael Gilbert a écrit : Succinctly, the copyright file itself is irrelevant in the source package since the upstream source should have all of that information already, and at least for the GPL you can distribute source packages as is. Thus, the issue is reduced to the need for full license texts only in all binary packages. Hi all, given that the source and binary packages are considered a single entity -- otherwise we would be violating the GPLs v1 and v2 -- the Debian copyright file is not necessary from a strictly legal point of view. It is therefore a facility to our infrastructure and a service to our users, and it is up to us as a project to decide its contents. One unwritten rule is that it has to contain all the necessary information for the FTP team to review the package. A first step in order to lift the requirement to include a verbatim copy of all licenses that are not distributed in /usr/share/common-licenses would be to ask the FTP team their opinion on that matter. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120512023757.gb29...@falafel.plessy.net
Re: Licenses not in /usr/share/common-licenses
Charles Plessy ple...@debian.org writes: given that the source and binary packages are considered a single entity -- otherwise we would be violating the GPLs v1 and v2 -- the Debian copyright file is not necessary from a strictly legal point of view. I don't see the logical justification for this statement. Our compliance with the GPL does not rely on considering source and binary packages as a single entity. The GPL explicitly permits us to treat them as two separate entities and distribute the source separately (which is what we do). -- 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/87r4uqyuui@windlord.stanford.edu
Re: Licenses not in /usr/share/common-licenses
Le Fri, May 11, 2012 at 07:52:05PM -0700, Russ Allbery a écrit : Charles Plessy ple...@debian.org writes: given that the source and binary packages are considered a single entity -- otherwise we would be violating the GPLs v1 and v2 -- the Debian copyright file is not necessary from a strictly legal point of view. I don't see the logical justification for this statement. Our compliance with the GPL does not rely on considering source and binary packages as a single entity. The GPL explicitly permits us to treat them as two separate entities and distribute the source separately (which is what we do). After reading again point 3 a) of the GPL v1 and v2, I see that I probably misunderstood what medium customarily used for software interchange meant. Sorry for the noise. -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120512030419.gc29...@falafel.plessy.net
Accepted lxpolkit 0.1.0-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 11 May 2012 07:43:05 +0200 Source: lxpolkit Binary: lxpolkit lxpolkit-dbg Architecture: source i386 Version: 0.1.0-2 Distribution: unstable Urgency: low Maintainer: Debian LXDE Maintainers lxde-deb...@lists.lxde.org Changed-By: Daniel Baumann dan...@debian.org Description: lxpolkit - LXDE PolicyKit authentication agent lxpolkit-dbg - LXDE PolicyKit authentication agent (debug) Changes: lxpolkit (0.1.0-2) unstable; urgency=low . * Updating maintainers field to move the package to the LXDE maintainers, thanks and welcome Sergey to the team. * Updating vcs fields. * Adding myself to uploaders. * Updating package to debhelper version 9. * Updating package to standards version 3.9.3. * Making build-depends unversioned where already fulfiled as of squeeze. * Updating homepage field. * Updating copyright file to machine-readable format version 1.0. * Rediffing missing-glade.patch with common diff options. * Rediffing potfiles-skip.patch with common diff options. * Harmonizing rules file. * Switching to xz compression for both the source and the binary packages. * Sorting depends field. * Avoiding to repeat the policykit-1 description in the package descriptions. * Replacing debhelper install file with an override for the install destdir in rules. Checksums-Sha1: 12aacfa7f93938f3a11c1dd47e9d1ff412c44379 1377 lxpolkit_0.1.0-2.dsc b3d8b112fb2ccb1467654ced22b3f44d5afb6060 154296 lxpolkit_0.1.0.orig.tar.xz 0fc9a580cab21829ddaea44fdc44b0c5dec59dd3 3408 lxpolkit_0.1.0-2.debian.tar.xz c0c99457e5a6fd5f9695dc0a66a90a539ce71c26 2234 lxpolkit_0.1.0-2_i386.deb 7db5a153ebf8db6efb40a2989def9c0c77ace6df 2278 lxpolkit-dbg_0.1.0-2_i386.deb Checksums-Sha256: 9b93debacc22ac33304b9ace05426880c6a25aa9b671de7ce72e0b61221df523 1377 lxpolkit_0.1.0-2.dsc 2c27570c779aa0effaed776b4f22cc0625b4c9919cac1a52b77ce539618723a7 154296 lxpolkit_0.1.0.orig.tar.xz e638122d78684fab275a2ff2bb53d83b02421655d170bb71d40e2f04b9d49d65 3408 lxpolkit_0.1.0-2.debian.tar.xz 5dd192771d46564a5cf2d5c0d3cf5ed9837b1a677dd00c9449d71965d0b61a5d 2234 lxpolkit_0.1.0-2_i386.deb 2b3d525a09323822fd7fa374ea6f2e8cff4605d054f830ac77d12ff0cdd9a268 2278 lxpolkit-dbg_0.1.0-2_i386.deb Files: 16df8b9881f55ac4560cbd0099c98cd8 1377 x11 optional lxpolkit_0.1.0-2.dsc 3d68f06277386a4ac152ace1e950f9ae 154296 x11 optional lxpolkit_0.1.0.orig.tar.xz b5bd93f938d0da4ce0e6797d24a77f30 3408 x11 optional lxpolkit_0.1.0-2.debian.tar.xz c55562299f4c61f9ee7401047e6e82dd 2234 x11 optional lxpolkit_0.1.0-2_i386.deb e503ebd52647fd41189902711f84bda6 2278 debug extra lxpolkit-dbg_0.1.0-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk+sp0AACgkQ+C5cwEsrK54N7gCgwViEdT7M7hBo8tgTURd9+vIw V2UAn1W517Mp/O/PG9ZCEQ3zO4TJcf4P =2dHK -END PGP SIGNATURE- Accepted: lxpolkit-dbg_0.1.0-2_i386.deb to main/l/lxpolkit/lxpolkit-dbg_0.1.0-2_i386.deb lxpolkit_0.1.0-2.debian.tar.xz to main/l/lxpolkit/lxpolkit_0.1.0-2.debian.tar.xz lxpolkit_0.1.0-2.dsc to main/l/lxpolkit/lxpolkit_0.1.0-2.dsc lxpolkit_0.1.0-2_i386.deb to main/l/lxpolkit/lxpolkit_0.1.0-2_i386.deb lxpolkit_0.1.0.orig.tar.xz to main/l/lxpolkit/lxpolkit_0.1.0.orig.tar.xz -- 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/e1ssiwu-0003dc...@franck.debian.org
Accepted conky 1.9.0-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 09 May 2012 19:27:20 -0700 Source: conky Binary: conky conky-std conky-cli Architecture: source all amd64 Version: 1.9.0-2 Distribution: unstable Urgency: low Maintainer: Vincent Cheng vincentc1...@gmail.com Changed-By: Vincent Cheng vincentc1...@gmail.com Description: conky - highly configurable system monitor (transitional package) conky-cli - highly configurable system monitor (basic version) conky-std - highly configurable system monitor (default version) Changes: conky (1.9.0-2) unstable; urgency=low . * Add debian/patches/fix-kfreebsd-ftbfs.patch to fix FTBFS on kfreebsd. Checksums-Sha1: c9167ab868d81d3af6d9da3b00e7ed40d6ba0042 2365 conky_1.9.0-2.dsc 5eb1dc5c6af8bfbb14bed7e11fda8a50c0c95856 18054 conky_1.9.0-2.debian.tar.bz2 024d3df9f8c61e8f772cde35d5721f8a62c3dd4d 34032 conky_1.9.0-2_all.deb 1eb2dbb0e76e9c91f322d22ef3ad4cf7b241f0a2 414160 conky-std_1.9.0-2_amd64.deb b8bb3ac2a09cb0f6ec44347393b52760f3ca9ea2 261156 conky-cli_1.9.0-2_amd64.deb Checksums-Sha256: 09c72dbdf6a0396c2612c4eb9ab87c5287dfd833a7f2c5bbd16ee968d3cc5c99 2365 conky_1.9.0-2.dsc ddb35ae1d151484863fc03cc7470ce944123d1ddabac23e097235b21b884b499 18054 conky_1.9.0-2.debian.tar.bz2 8f400dd1ceb48e95a085de7a6b651f2e4a5e3a7d847b1ae37088b9bc0d4254c2 34032 conky_1.9.0-2_all.deb a2738d90a2e1ddcd88969afe2b4a2b1c5a2686728d0944c0b23cbe51fc8279e6 414160 conky-std_1.9.0-2_amd64.deb e1e70473bc93124b66ed4b68a5ad57900511c6e1cab0187d0bbf427d0e65259f 261156 conky-cli_1.9.0-2_amd64.deb Files: cc9b7f9713bf7e746f7b6923b3754b0f 2365 utils optional conky_1.9.0-2.dsc 2ea5fc383fcd89a5c22fa3576a7bbda6 18054 utils optional conky_1.9.0-2.debian.tar.bz2 7c87979844f1d720ac0aca321f37bc5b 34032 oldlibs extra conky_1.9.0-2_all.deb 6b2e26eeb951b4de7fe41ef923f3721f 414160 utils optional conky-std_1.9.0-2_amd64.deb 816b4084172774a8de8dc7a12eb40d76 261156 utils optional conky-cli_1.9.0-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJPrK59AAoJEDNV9NY7WCHM3wMP/1uXeWtPvf02NMHQFwiusTZz G62UklJP3aGWhIND9b7DZsi6Jz8TGqpoXobTNgJH5TMqJdiuLTPvXKdR+DbED9aM ZZh1JNUfgRiL38KO45DGPeuTNezkH0QLfMe9UpTzLAUN2m/r9EPhk+e1mt4tXhWD XiVQFnLZdKeQEF9+HZ9eeSiIh4mzeL+EfH80xOYMQd4VBM69yORHwPKMCJYek7Hv Y0VOxFe4TJp1xzOQ6aLXTGA+YihkHw0d9ichFOyVxDamr0EwO9ZCuCrDC0cASQe6 c7QTDbfTER39S1TEpMUGeIwbeH1+7jpFneXZeahQ/20did3ATHkfl4du5P/xH9j4 2pYH0fhIEO0UPo0oPwJ0mvHBiXZ2wfqAWaPWWAkyaM0GXK2hlh1NAltTz0q6JOVc VRUe4zlCoWpHFOVcyZsTLYYAVO+1JPPTHbT959shACXL7ahatWY7lS0yPaNj8Pv5 wJ847hLR/diI9YQtz02+sxliI4TtWl+K7Q5+IG+4xpG7Li40vDoYMb+Zei7P4Fs4 vd+RAYtcOgXbRfWjUPz9Oh8sRKztWnCwyDiqkY8rjcFDmQv5jb9uKETVMQzTd7lh SmL8JJLjID9MOMq6WTOj4mUKx55G+izcIbqSXoFxRKQJLb9dI064ncsjtp9qwOdj pnS4ZZkhwg4Ek34wFJ2f =KxSm -END PGP SIGNATURE- Accepted: conky-cli_1.9.0-2_amd64.deb to main/c/conky/conky-cli_1.9.0-2_amd64.deb conky-std_1.9.0-2_amd64.deb to main/c/conky/conky-std_1.9.0-2_amd64.deb conky_1.9.0-2.debian.tar.bz2 to main/c/conky/conky_1.9.0-2.debian.tar.bz2 conky_1.9.0-2.dsc to main/c/conky/conky_1.9.0-2.dsc conky_1.9.0-2_all.deb to main/c/conky/conky_1.9.0-2_all.deb -- 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/e1ssjoj-0005v7...@franck.debian.org
Accepted sitplus 1.0.3-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 11 May 2012 08:03:06 +0200 Source: sitplus Binary: sitplus sitplus-data Architecture: source amd64 all Version: 1.0.3-2 Distribution: unstable Urgency: low Maintainer: Debian Med Packaging Team debian-med-packag...@lists.alioth.debian.org Changed-By: Andreas Tille ti...@debian.org Description: sitplus- Free software framework for ludic-therapeutic activities sitplus-data - Data files for Sitplus, a framework for ludic-therapeutic activit Closes: 672033 Changes: sitplus (1.0.3-2) unstable; urgency=low . * Work around build failure with GCC 4.7. (Thanks for the patch to Matthias Klose d...@debian.org Closes: #672033. * Debhelper 9 (control+compat) Checksums-Sha1: 8c8d0b454c90f7036cb248c95083b87da07a3e05 1745 sitplus_1.0.3-2.dsc 9c4f4508c55aa9a3bb2d5ae62bb1904853637788 9607 sitplus_1.0.3-2.debian.tar.gz fb335d3ce8540b4962e4596cbc3c2cc25b498065 1218400 sitplus_1.0.3-2_amd64.deb 8a5af39ff940bfaefd933cd54555d888abb07342 17041554 sitplus-data_1.0.3-2_all.deb Checksums-Sha256: 65194952ab816233dae1247912c011e98b25497a2cd06d37e21a2c1973f3434d 1745 sitplus_1.0.3-2.dsc 1d29278e7bc6095d8905971a19eca1f2e6753b4481aed5569187cffa57519aef 9607 sitplus_1.0.3-2.debian.tar.gz 92b016176f8f031eba6c18ac067e5fa9590214149449cbdbd99c9b869b0dc200 1218400 sitplus_1.0.3-2_amd64.deb 190a20596a4dbe817029bd2790558c43b8ea8ecb71efe7b2e8c90d70080ba7ca 17041554 sitplus-data_1.0.3-2_all.deb Files: 0a94c20fd21b8716bded960ad55b5a13 1745 misc optional sitplus_1.0.3-2.dsc 0d0e3f9012b87d66e17d1a47ea9d5c77 9607 misc optional sitplus_1.0.3-2.debian.tar.gz c00643beb13ca510422d51b2ec491671 1218400 misc optional sitplus_1.0.3-2_amd64.deb a3faaa4362cc5080fb8773e2f92c2a85 17041554 misc optional sitplus-data_1.0.3-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk+ssRUACgkQYDBbMcCf01p2kgCgkCgaRb8RbtiCs/IpSNfQIz3f 4acAoKdBw10L1hQur82Va35h2a3RSa29 =YdXk -END PGP SIGNATURE- Accepted: sitplus-data_1.0.3-2_all.deb to main/s/sitplus/sitplus-data_1.0.3-2_all.deb sitplus_1.0.3-2.debian.tar.gz to main/s/sitplus/sitplus_1.0.3-2.debian.tar.gz sitplus_1.0.3-2.dsc to main/s/sitplus/sitplus_1.0.3-2.dsc sitplus_1.0.3-2_amd64.deb to main/s/sitplus/sitplus_1.0.3-2_amd64.deb -- 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/e1ssjfw-0006xd...@franck.debian.org
Accepted libgtkada 2.24.1-5 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 10 May 2012 23:49:34 +0200 Source: libgtkada Binary: libgtkada2.24.1-dev libgnomeada2.24.1-dev libgtkglada2.24.1-dev libgtkada-dbg libgnomeada-dbg libgtkglada-dbg libgtkada2.24.1 libgnomeada2.24.1 libgtkglada2.24.1 libgtkada-bin libgtkada-doc Architecture: source amd64 all Version: 2.24.1-5 Distribution: unstable Urgency: low Maintainer: Ludovic Brenta lbre...@debian.org Changed-By: Nicolas Boulenguez nicolas.bouleng...@free.fr Description: libgnomeada-dbg - Ada binding for the GNOME GUI (debugging symbols) libgnomeada2.24.1 - Ada binding for the GNOME GUI (dynamic library) libgnomeada2.24.1-dev - Ada binding for the GNOME GUI (development files) libgtkada-bin - Ada binding for the GTK+ GUI (development utilities) libgtkada-dbg - Ada binding for the GTK+ GUI (debugging symbols) libgtkada-doc - Ada binding for the GTK+ GUI (documentation) libgtkada2.24.1 - Ada binding for the GTK+ GUI (dynamic library) libgtkada2.24.1-dev - Ada binding for the GTK+ GUI (development files) libgtkglada-dbg - Ada binding for GTK+ OpenGL extensions (debugging symbols) libgtkglada2.24.1 - Ada binding for GTK+ OpenGL extensions (dynamic library) libgtkglada2.24.1-dev - Ada binding for GTK+ OpenGL extensions (development files) Closes: 669998 Changes: libgtkada (2.24.1-5) unstable; urgency=low . [Nicolas Boulenguez] * rules, *.gpr, ada_libraries: switched to dh_ada_library. * rules, control, compat: dh (= 9) should handle build target. * control: Standards-Version: 3.9.3 (no changes) -dev packages cannot be Multi-Arch: same as they embed a project file whose content mentions lib/TRIPLET subdirectories (Closes: #669998). -dbg packages can be Multi-Arch: same without Pre-Depends as they do not need the linker at install time. * rules: Standard /usr/share/dpkg/default.mk from dpkg-dev (= 1.16.1) Gprbuild now selects gnatgcc instead of gcc automatically. * tests: import versioned project, to test both versions in one go. * patches/include_only_glib_h: documented. . [Ludovic Brenta] * Build-Depend: dh-ada-library = 2 to avoid a bug affecting gtkada. Checksums-Sha1: 4f329797973e55ae50252402ff883372527ca146 2245 libgtkada_2.24.1-5.dsc e80ac9a24a77308f19cc6fe200afba1fec7b4c31 23372 libgtkada_2.24.1-5.debian.tar.bz2 6f4ec7c81d92a4fd195556ddea31cadb924ad515 8211672 libgtkada2.24.1-dev_2.24.1-5_amd64.deb b9fddb1921d6a4d835a66ef5ba913b2286ae5b8e 738174 libgnomeada2.24.1-dev_2.24.1-5_amd64.deb 65b60d047be364458b6e4b69c1ed64ac006b64aa 162316 libgtkglada2.24.1-dev_2.24.1-5_amd64.deb 3de6436660e4148bdb1914eb60ef7ae25a8758ec 2560162 libgtkada-dbg_2.24.1-5_amd64.deb e27b157cbf86b56197c3c54a5223df4c627c3d4f 216948 libgnomeada-dbg_2.24.1-5_amd64.deb c5b507cb822ae6151af42104e813c4b34e56b871 62464 libgtkglada-dbg_2.24.1-5_amd64.deb c839fc7246d7107b2be87462fc9cf8201bd4fb36 1302388 libgtkada2.24.1_2.24.1-5_amd64.deb d9119acfcf82db7cf4522d632867e332ca30348e 102614 libgnomeada2.24.1_2.24.1-5_amd64.deb 1b40ac935e2c21c3c0f235e9119407fad6690c82 33032 libgtkglada2.24.1_2.24.1-5_amd64.deb b93bb7d18d45d43baf2153f6603051c1dc2d3b2d 15200 libgtkada-bin_2.24.1-5_amd64.deb cb05f0dce25bca16624fef853efee306ad07fe11 422 libgtkada-doc_2.24.1-5_all.deb Checksums-Sha256: b8511908d923fab30d31a8754d214105552065cc66cf85225b280f03388bd7ed 2245 libgtkada_2.24.1-5.dsc 1d5d326d81bfffb558e88895e698fc820a1cacfaca1296a5b8c420f320694ee5 23372 libgtkada_2.24.1-5.debian.tar.bz2 b1bc86ebecf1c73855cf281dd88b204c1d900f47301d4e6c5602a8c457cb0c79 8211672 libgtkada2.24.1-dev_2.24.1-5_amd64.deb 3650965bd9eae46ade895854efbf99f4a629eea74d882d36c3d7f82556303384 738174 libgnomeada2.24.1-dev_2.24.1-5_amd64.deb aeadfe1e4c7786b8ec61bd50a4cd8bcf7962c742b3acad5763d4e165efd0a53f 162316 libgtkglada2.24.1-dev_2.24.1-5_amd64.deb 42859ffb60176eae462a394d7a4605513bb7b0e910e2fdb77a3ebe5a74c0a159 2560162 libgtkada-dbg_2.24.1-5_amd64.deb 82f240d73031c53db1c8ee2ad87f6f43371da51827ebdf2f8e035513eb677015 216948 libgnomeada-dbg_2.24.1-5_amd64.deb d8fbc52ced7e48c4920725320ac036cc740dc22f42545eac9a0f9890034c3b2b 62464 libgtkglada-dbg_2.24.1-5_amd64.deb 0022dd33ca690bcf2d82682170af68a88d2d9e79d1390c8f403792e5ed22ae6b 1302388 libgtkada2.24.1_2.24.1-5_amd64.deb dfdd1541648160af42303017d0f921b2498788198f94d50271ad98314db4f4e6 102614 libgnomeada2.24.1_2.24.1-5_amd64.deb 1e25760fbc5103d4200f5202a7c1de9718e9a3a6ced7160becd8182a63cf0a25 33032 libgtkglada2.24.1_2.24.1-5_amd64.deb 5db0db1e9207c15a2c2fb8b07e330f1f94b872fc58cb9838be04daee9345a6f9 15200 libgtkada-bin_2.24.1-5_amd64.deb 1b9c8b2214f6c96f88d86676e05d3d1a2a3ad6f6057f3f1e61579efffd57bd9b 422 libgtkada-doc_2.24.1-5_all.deb Files: 81be1f1fcd64cbf5cb0238f94f2f959c 2245 libs optional libgtkada_2.24.1-5.dsc fb2f3f951ea86c6bff3c77cd606d941d 23372 libs optional libgtkada_2.24.1-5.debian.tar.bz2 7fa272c577f8edecaf839e9f6268a658 8211672 libdevel optional
Accepted smarty-gettext 1.0b1-6 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 10 May 2012 20:49:21 +0200 Source: smarty-gettext Binary: smarty-gettext Architecture: source all Version: 1.0b1-6 Distribution: unstable Urgency: low Maintainer: Mike Gabriel mike.gabr...@das-netzwerkteam.de Changed-By: Mike Gabriel mike.gabr...@das-netzwerkteam.de Description: smarty-gettext - Gettext plugin enabling internationalization in Smarty Changes: smarty-gettext (1.0b1-6) unstable; urgency=low . * New maintainer. Checksums-Sha1: 586ebf600a2552393428ea0b2353a8f5993f19c8 1952 smarty-gettext_1.0b1-6.dsc a359f98533a5a7e8201e56524cd9efc66d94138a 2104 smarty-gettext_1.0b1-6.debian.tar.gz e02416ba7046af7bfcf70e548e466d5fbbda97fa 8786 smarty-gettext_1.0b1-6_all.deb Checksums-Sha256: 080ac2e7d6423b22389249ff59f73f11597fc7d9fcff1e0dd94374e2e282392b 1952 smarty-gettext_1.0b1-6.dsc a6fdc6640041f2c8c91088fc9d1a4445e17edf2a6dac2f4094b296eb1a1a5f5e 2104 smarty-gettext_1.0b1-6.debian.tar.gz 0a87d67b9fe2eb227fc9e8f416301f97d1c47bab6092e1c30db629bb42b04f70 8786 smarty-gettext_1.0b1-6_all.deb Files: c3f351a7891ecb7c70566d776dcaf34a 1952 web optional smarty-gettext_1.0b1-6.dsc 9a1715bf397622583a34a4ae52d25af2 2104 web optional smarty-gettext_1.0b1-6.debian.tar.gz 6facb21b741e309a43c67e8a5b661c44 8786 web optional smarty-gettext_1.0b1-6_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Signed by Raphael Hertzog iQIcBAEBCAAGBQJPrMKjAAoJEOYZBF3yrHKas4cP/jNDSxF59udGgZBxJaVHpW1z Ov98MzarjHXm0cJWS0wBjMnVRyvxaxNwwuob17Di3aje6h3emKzFe57MIHGMFicH 9PFv/hTCpmoaq6jf8ITjoDV1paiVXmJ51Y93np9j3V0ip3bPTHdrrSmtHYidE6uA 8u0P7WvVYWDu1WW4jyC2TST13EQMxG7lEr6AKPkUbpd3l9JAPtMiMNfiXcFuiVww jfkH5wUfg+4o+vtK57AAOMpSs/BM1eMnFy6ep8iuJZ+qg4LbP2fUdTnKCn/Mup2d jgHNt349+bF1JNbivcBdAWc1yAZJFkeEt2VajjV16jkJh6r3ekE9oglyV9XCeUd9 aWgtX39Jt6x02LMPFSnC4cV7lZ+MBdjN5RJREmKX4C5oQdLmvX3RjVJZKYfNyOoP lwcryiSjhUal37tp5fZiKRaYG6iHruqyiE1G9VTDWmxxgYAqg4ASw9YbLuxMzW7V vidlOYiZmXVonkqELez+Qw68QMU6JIZ3CgWoc9IkBOcATH4IF+IKywHzpLXhq+er XTTiFpr9dROx7oUJkZbsssaNVmwbC3hL2xLrwFOX6ixzQmtkKO50Cxw+ISAri+1A VO0CwKNwZa9QSjM7sTQAJ978NFAJ5mZjVZAx5WyHAzs3djzTT5VUa27vyBomnmty JnxZIexgQ2chVjg/QRIN =NUwf -END PGP SIGNATURE- Accepted: smarty-gettext_1.0b1-6.debian.tar.gz to main/s/smarty-gettext/smarty-gettext_1.0b1-6.debian.tar.gz smarty-gettext_1.0b1-6.dsc to main/s/smarty-gettext/smarty-gettext_1.0b1-6.dsc smarty-gettext_1.0b1-6_all.deb to main/s/smarty-gettext/smarty-gettext_1.0b1-6_all.deb -- 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/e1sskio-00047w...@franck.debian.org
Accepted db 5.1.29-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 11 May 2012 10:10:08 +0200 Source: db Binary: db5.1-doc libdb5.1-dev libdb5.1 db5.1-util db5.1-sql-util libdb5.1++ libdb5.1++-dev libdb5.1-tcl libdb5.1-dbg libdb5.1-java-jni libdb5.1-java libdb5.1-java-gcj libdb5.1-java-dev libdb5.1-sql-dev libdb5.1-sql libdb5.1-stl-dev libdb5.1-stl Architecture: source all amd64 Version: 5.1.29-2 Distribution: unstable Urgency: low Maintainer: Debian Berkeley DB Group pkg-db-de...@lists.alioth.debian.org Changed-By: Ondřej Surý ond...@debian.org Description: db5.1-doc - Berkeley v5.1 Database Documentation [html] db5.1-sql-util - Berkeley v5.1 SQL Database Utilities db5.1-util - Berkeley v5.1 Database Utilities libdb5.1 - Berkeley v5.1 Database Libraries [runtime] libdb5.1++ - Berkeley v5.1 Database Libraries for C++ [runtime] libdb5.1++-dev - Berkeley v5.1 Database Libraries for C++ [development] libdb5.1-dbg - Berkeley v5.1 Database Libraries [debug] libdb5.1-dev - Berkeley v5.1 Database Libraries [development] libdb5.1-java - Berkeley v5.1 Database Libraries for Java libdb5.1-java-dev - Berkeley v5.1 Database Libraries for Java [development] libdb5.1-java-gcj - Berkeley v5.1 Database Libraries for Java (native code) libdb5.1-java-jni - Berkeley v5.1 Database Libraries for Java libdb5.1-sql - Berkeley v5.1 Database Libraries [SQL runtime] libdb5.1-sql-dev - Berkeley v5.1 Database Libraries [SQL development] libdb5.1-stl - Berkeley v5.1 Database Libraries [STL runtime] libdb5.1-stl-dev - Berkeley v5.1 Database Libraries [STL development] libdb5.1-tcl - Berkeley v5.1 Database Libraries for Tcl [module] Closes: 670011 Changes: db (5.1.29-2) unstable; urgency=low . * Split libdb5.1-java to arch independent libdb5.1-java and move JNI libraries to libdb5.1-java-jni (Closes: #670011) Checksums-Sha1: d71a7aa79804dfa3f928936eb3ecb72155d9bad0 2118 db_5.1.29-2.dsc cc119449f82af1071c828efd046d38ca985ed3b3 28242 db_5.1.29-2.debian.tar.gz 1b15cfe36a27b30fabb5df440a06a97e4bc7300e 17311544 db5.1-doc_5.1.29-2_all.deb 7b7d5276eb03d35a81921359fdcfe64ffa939917 881574 libdb5.1-dev_5.1.29-2_amd64.deb 76dbbeb1f7bcc7b22d049bd67c47c4b8ac535b66 722688 libdb5.1_5.1.29-2_amd64.deb fe9616612c7a81eead78d769daf7df611434c70f 87426 db5.1-util_5.1.29-2_amd64.deb 71d04b8c53dfc5c3a1b7ef703c48b86ffa101589 22024 db5.1-sql-util_5.1.29-2_amd64.deb 67432de6f90ba2210203471a93e7c65be7e8ec65 756738 libdb5.1++_5.1.29-2_amd64.deb 4cd6322aaef64440d87cc90183836ca604a7a4ae 1802322 libdb5.1++-dev_5.1.29-2_amd64.deb f9fc7312f4d5e98986a803e4d82d951a33f0ee9d 2695252 libdb5.1-tcl_5.1.29-2_amd64.deb f9450a29bc8542cd54e8e4946364859032e4b0ec 28004872 libdb5.1-dbg_5.1.29-2_amd64.deb 5c57762dd60e64eabce094ae50b58cea9a6ed6bc 526192 libdb5.1-java_5.1.29-2_amd64.deb de5b2cffeb6a364ee35921e24ff8d7d923568548 798640 libdb5.1-java-gcj_5.1.29-2_amd64.deb 9e8cccf4cd9b3e1e8fb81778f038b09b7c82c251 904498 libdb5.1-java-dev_5.1.29-2_amd64.deb 38cce64effb1e2195f4fc2fe4a4d996148e55115 2305744 libdb5.1-sql-dev_5.1.29-2_amd64.deb 1ba39ba5aae490a1456f3e691fcb0d0b895de111 959630 libdb5.1-sql_5.1.29-2_amd64.deb 9f1f49acd45313b63309af8144fb5d648222bf29 1963554 libdb5.1-stl-dev_5.1.29-2_amd64.deb 399c0061842ba82009603f01d3482d6455710ecb 786002 libdb5.1-stl_5.1.29-2_amd64.deb Checksums-Sha256: 5911e40b2eb6a0e923a8cb62131c2b2c2e55f581f78510e21940bf7d43979e73 2118 db_5.1.29-2.dsc e937bd9ad94e5d73870a9e70d7db575aa2a4a7b087dd92aadf538851127b9e38 28242 db_5.1.29-2.debian.tar.gz a174a5b46d5838554c47c79e8ba7136449e2ec2953f54b6a8d0ff62f68ade2d7 17311544 db5.1-doc_5.1.29-2_all.deb 5696d277dfea0d19ac581fcebfb8e9882d1b36130579ef9bc8488244f54729d5 881574 libdb5.1-dev_5.1.29-2_amd64.deb 77e3b77bd6a998693eb12bb7d9f1a572b130a520e26ee8a09c1669b8b25d9656 722688 libdb5.1_5.1.29-2_amd64.deb 8c4f824e91fee0afbdd12b4ca6fbf2dba8c4d8d76206a11f11ed029b75678444 87426 db5.1-util_5.1.29-2_amd64.deb e40f156562581d4e97ec70872929d002e2c3e64d800775cedfb47f4108d18f69 22024 db5.1-sql-util_5.1.29-2_amd64.deb a678b302ee2f264f633dee47fe8408f92bfe54a754b122f6d30ec2c24d2909ea 756738 libdb5.1++_5.1.29-2_amd64.deb 97e5763ae71ba9e70552643a3f24155033b4507c0fb256e399ccdbabdc1e4ede 1802322 libdb5.1++-dev_5.1.29-2_amd64.deb c0291d711923276b46ac054f721aa55b65a3767371f1ab4bfbbd81d451461685 2695252 libdb5.1-tcl_5.1.29-2_amd64.deb 746c597d9810b5467d2d59f777f0e81597b385803b72ae22ee8c16ed0ad9d8aa 28004872 libdb5.1-dbg_5.1.29-2_amd64.deb ad198c00f2578c523ddee0c6cd38cc6f4b6c21dd54dc2de8d6663cdd759ab93e 526192 libdb5.1-java_5.1.29-2_amd64.deb 7cf6cd285c4813ab79c5c98a1177b88ef0dae4baeef56ea126b8317cfe73100b 798640 libdb5.1-java-gcj_5.1.29-2_amd64.deb 093815f7e8bd24697a11d6fe68c76e1697aca6c2572df1f166a0a5fa957ea2ca 904498 libdb5.1-java-dev_5.1.29-2_amd64.deb e812eedd48299b9a567b3f8038e82d09ba44ad77909447d0bba3c972dd7d7f9c 2305744 libdb5.1-sql-dev_5.1.29-2_amd64.deb 8f563459e4efd5e5e25f8d2d95da6d50fe03687a3314648c89b6a3c944a0d9f0 959630
Accepted libiscsi 1.4.0-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 04 May 2012 12:05:48 +0400 Source: libiscsi Binary: libiscsi1 libiscsi-dev libiscsi-bin Architecture: source i386 Version: 1.4.0-1 Distribution: unstable Urgency: low Maintainer: Michael Tokarev m...@tls.msk.ru Changed-By: Michael Tokarev m...@tls.msk.ru Description: libiscsi-bin - iSCSI client shared library - utilities libiscsi-dev - iSCSI client shared library libiscsi1 - iSCSI client shared library Changes: libiscsi (1.4.0-1) unstable; urgency=low . * new upstream version * build-depend on debhelper 9~ * update Standards-Version to 3.9.3 (no changes needed) Checksums-Sha1: 90f54a3a82cab6425cc2193fe771e97ad36f0722 1306 libiscsi_1.4.0-1.dsc ab337f6d5236c4cec54027cae2a9ce16b8e5a432 98937 libiscsi_1.4.0.orig.tar.gz a9e7fc64f4a7f6c66f5ecd0dadffdfd27b5cf772 2354 libiscsi_1.4.0-1.debian.tar.gz be7a426f05d0b8ac60e5ff785ad5aeb2cdaf35fb 39860 libiscsi1_1.4.0-1_i386.deb c8561b2e83da11dc14107fffb4a1c6a675198a32 48660 libiscsi-dev_1.4.0-1_i386.deb c7ba28ffb95c21d9b99acae780d0eabb575b0e7a 11308 libiscsi-bin_1.4.0-1_i386.deb Checksums-Sha256: 16dba5af11294a3d03a871b3290ba2c463742805344d50e14615b2f364cb4d95 1306 libiscsi_1.4.0-1.dsc 87eaa197f7d5420d5d0deed65ae0814ee79e31f732ee81e006b06365d62298c8 98937 libiscsi_1.4.0.orig.tar.gz 9b16a234568767d7a52956d52bfb0682c9963b5e930db1ad2a3d0eb32730d59f 2354 libiscsi_1.4.0-1.debian.tar.gz 358f3aae57db961e943b7f30a639dbdb001ee80301e8d729d1fcc6da8bd396cf 39860 libiscsi1_1.4.0-1_i386.deb 8929f10d0bf796f7c8421a1e0437b0a5fcdf50f33e3cf4ffa5f8d886ca269601 48660 libiscsi-dev_1.4.0-1_i386.deb 89f4d50a517b1c5a875253c551952a3725ec80c8d0d59e9d01b91d25cbf73636 11308 libiscsi-bin_1.4.0-1_i386.deb Files: 6eb1a335eb63ddf80ccba0204e6b0c8f 1306 net optional libiscsi_1.4.0-1.dsc 19abf4e40e95c521f473ce8a26479282 98937 net optional libiscsi_1.4.0.orig.tar.gz fe3731872e851cc5ddbe835b681ad230 2354 net optional libiscsi_1.4.0-1.debian.tar.gz 0b34e6aab14c3daf61e77364741a8616 39860 libs optional libiscsi1_1.4.0-1_i386.deb 50678d0c7c2a7a264a94f7af822a5389 48660 libdevel optional libiscsi-dev_1.4.0-1_i386.deb 522a53d1fc9469f64e21124ab8f061d4 11308 net optional libiscsi-bin_1.4.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iJwEAQECAAYFAk+szWUACgkQUlPFrXTwyDgyWAP9HYO7aWSPkbOmyjEdvVtjDJpu ZyePGrl4lXhhT2h6lDgNA0D7MzYwBnnQUhdZ7DxX0GQ6bMQ2Za/96bDEXVLoWqya 6pbk9j3ngrW9BePuJ+n6iKBqtZ8FSo4cBZk1r/FORRbMKiyLghQ4sdgWpygCSkgY xaj7whdYU1ryVEOsaNc= =h4jK -END PGP SIGNATURE- Accepted: libiscsi-bin_1.4.0-1_i386.deb to main/libi/libiscsi/libiscsi-bin_1.4.0-1_i386.deb libiscsi-dev_1.4.0-1_i386.deb to main/libi/libiscsi/libiscsi-dev_1.4.0-1_i386.deb libiscsi1_1.4.0-1_i386.deb to main/libi/libiscsi/libiscsi1_1.4.0-1_i386.deb libiscsi_1.4.0-1.debian.tar.gz to main/libi/libiscsi/libiscsi_1.4.0-1.debian.tar.gz libiscsi_1.4.0-1.dsc to main/libi/libiscsi/libiscsi_1.4.0-1.dsc libiscsi_1.4.0.orig.tar.gz to main/libi/libiscsi/libiscsi_1.4.0.orig.tar.gz -- 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/e1sslv6-ea...@franck.debian.org
Accepted lua-cgi 5.1.4+dfsg-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 01 May 2012 11:45:05 +0200 Source: lua-cgi Binary: lua-cgi liblua5.1-cgi0 liblua5.1-cgi-dev Architecture: source all Version: 5.1.4+dfsg-2 Distribution: unstable Urgency: low Maintainer: Enrico Tassi gareuselesi...@debian.org Changed-By: Enrico Tassi gareuselesi...@debian.org Description: liblua5.1-cgi-dev - Transitional package for lua-cgi liblua5.1-cgi0 - Transitional package for lua-cgi lua-cgi- CGI library for the Lua language Changes: lua-cgi (5.1.4+dfsg-2) unstable; urgency=low . * Update dependency on liblua5.1-socket2 - lua-socket Checksums-Sha1: d533ff8ccbfb3eaf6ca31f3f31667f37af534f29 1347 lua-cgi_5.1.4+dfsg-2.dsc 188bd3527705946b391f05e9c496a88ede3ab857 5115 lua-cgi_5.1.4+dfsg-2.debian.tar.gz 15d58a00daf0cb80ffc8e27ae3cda1abfc7286a1 133236 lua-cgi_5.1.4+dfsg-2_all.deb 0e517e2fdc16be5ea39fd82fb557676aa049ca41 3010 liblua5.1-cgi0_5.1.4+dfsg-2_all.deb 2e96cc30d06d59eb85d56c1dff4d1b284006d598 3010 liblua5.1-cgi-dev_5.1.4+dfsg-2_all.deb Checksums-Sha256: 4e3f2ccbcd31978103bc03b18abca14e8c04fa157e2a22cf546e62086475133d 1347 lua-cgi_5.1.4+dfsg-2.dsc 02467ebf977315954314d08665b679a32ad43caf9103bccc18c2a7b9735fb66e 5115 lua-cgi_5.1.4+dfsg-2.debian.tar.gz 3543849ea569be3935fefcad82bbabce457076f935ae7d5e5c81ff06511f7b8a 133236 lua-cgi_5.1.4+dfsg-2_all.deb 6b0eb6db6dc311c295bf6a9ec53eb99ab6e0ecc19e435ebe1aea6dad19578b1d 3010 liblua5.1-cgi0_5.1.4+dfsg-2_all.deb fa4d5e7309e7e1b9adb107606e3f563dc5cd0765985cd57dc79a8d60b8545b56 3010 liblua5.1-cgi-dev_5.1.4+dfsg-2_all.deb Files: 7846ed72ebdc46fd2094a544fa47bf7c 1347 interpreters optional lua-cgi_5.1.4+dfsg-2.dsc 06bf0bf533c865c0a20d6f6e79075bd2 5115 interpreters optional lua-cgi_5.1.4+dfsg-2.debian.tar.gz 3edfd753b7e39cb7fd4a89e6a48cd45f 133236 interpreters optional lua-cgi_5.1.4+dfsg-2_all.deb 763d8136b134b88d07891044004595d0 3010 oldlibs extra liblua5.1-cgi0_5.1.4+dfsg-2_all.deb 3da1f49578bf8cffb9ede7e426cf9254 3010 oldlibs extra liblua5.1-cgi-dev_5.1.4+dfsg-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk+sw28ACgkQ7kkcPgEj8vKDCgCffF24gSWVlJwDq2GLJjgQ770U KpoAoKCSdxUSZJTen3WBQBPgXozrkPwZ =8wom -END PGP SIGNATURE- Accepted: liblua5.1-cgi-dev_5.1.4+dfsg-2_all.deb to main/l/lua-cgi/liblua5.1-cgi-dev_5.1.4+dfsg-2_all.deb liblua5.1-cgi0_5.1.4+dfsg-2_all.deb to main/l/lua-cgi/liblua5.1-cgi0_5.1.4+dfsg-2_all.deb lua-cgi_5.1.4+dfsg-2.debian.tar.gz to main/l/lua-cgi/lua-cgi_5.1.4+dfsg-2.debian.tar.gz lua-cgi_5.1.4+dfsg-2.dsc to main/l/lua-cgi/lua-cgi_5.1.4+dfsg-2.dsc lua-cgi_5.1.4+dfsg-2_all.deb to main/l/lua-cgi/lua-cgi_5.1.4+dfsg-2_all.deb -- 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/e1sslvf-q1...@franck.debian.org
Accepted lua-copas 1.1.6-5 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 03 May 2012 20:49:47 +0200 Source: lua-copas Binary: lua-copas liblua5.1-copas0 liblua5.1-copas-dev Architecture: source all Version: 1.1.6-5 Distribution: unstable Urgency: low Maintainer: Enrico Tassi gareuselesi...@debian.org Changed-By: Enrico Tassi gareuselesi...@debian.org Description: liblua5.1-copas-dev - Transitional package for lua-copas liblua5.1-copas0 - Transitional package for lua-copas lua-copas - Copas is a dispatcher of concurrent TCP/IP requests Changes: lua-copas (1.1.6-5) unstable; urgency=low . * Update depends on liblua5.1-socket2 - lua-socket Checksums-Sha1: 62cd3ea77d7a3dd30113694dd67965613ad9cdd1 1342 lua-copas_1.1.6-5.dsc 24135fc383f749302a608871a2cf180fef07b02e 2809 lua-copas_1.1.6-5.debian.tar.gz 8e9a1e5149190489321abf43f9ec564faa0783a0 25246 lua-copas_1.1.6-5_all.deb ac194a2b32ce83165b04cb9ce5a49ca8c828d3a1 2666 liblua5.1-copas0_1.1.6-5_all.deb c66609a8e7b996eac9c3aff62d94f9c82d4fef22 2670 liblua5.1-copas-dev_1.1.6-5_all.deb Checksums-Sha256: ad91a1d62100fa55ce74efe212d3d95178503ecd00505134aab0bdd57c51368a 1342 lua-copas_1.1.6-5.dsc 03a530d9fe104bddbe3e32660d78b45b0ebebc12dcd472bf7e61b69fc60021f7 2809 lua-copas_1.1.6-5.debian.tar.gz df5790afc9487a3ff6579c13fc20184ffd36bffd9145c8bde1a52bed66cfda3d 25246 lua-copas_1.1.6-5_all.deb 4529b3a91ae3b4ad0bef2f09db30445d208feb67fd7e78d6ce3836311e7a07bc 2666 liblua5.1-copas0_1.1.6-5_all.deb 7fcd51921a3d231cb993ec824cd7f8e8caa95e6af64f0102f01e6b94f558fa59 2670 liblua5.1-copas-dev_1.1.6-5_all.deb Files: 571aad75d9890fd0b1e446f25fbebc2e 1342 interpreters optional lua-copas_1.1.6-5.dsc 320e05a78e9cea5b118d3963e2663d79 2809 interpreters optional lua-copas_1.1.6-5.debian.tar.gz 175f32bd1f8be444122e71b2f00f2114 25246 interpreters optional lua-copas_1.1.6-5_all.deb 45f52de922a9a98abf42f1cb8f5c44b7 2666 oldlibs extra liblua5.1-copas0_1.1.6-5_all.deb 0f95e7a2ee88f26a7916659c5aa855ba 2670 oldlibs extra liblua5.1-copas-dev_1.1.6-5_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk+sxg4ACgkQ7kkcPgEj8vJYAgCgt+3PndfZQgrzpYbMaeJdnwfG xVUAoJZpAPG06YU9F7ShYFg0uK2ydJdq =A3Se -END PGP SIGNATURE- Accepted: liblua5.1-copas-dev_1.1.6-5_all.deb to main/l/lua-copas/liblua5.1-copas-dev_1.1.6-5_all.deb liblua5.1-copas0_1.1.6-5_all.deb to main/l/lua-copas/liblua5.1-copas0_1.1.6-5_all.deb lua-copas_1.1.6-5.debian.tar.gz to main/l/lua-copas/lua-copas_1.1.6-5.debian.tar.gz lua-copas_1.1.6-5.dsc to main/l/lua-copas/lua-copas_1.1.6-5.dsc lua-copas_1.1.6-5_all.deb to main/l/lua-copas/lua-copas_1.1.6-5_all.deb -- 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/e1sslvw-xa...@franck.debian.org
Accepted lua-svn 0.4.0-6 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 30 Apr 2012 13:08:21 +0200 Source: lua-svn Binary: lua-svn lua-svn-dev liblua5.1-svn1 liblua5.1-svn-dev Architecture: source amd64 all Version: 0.4.0-6 Distribution: unstable Urgency: low Maintainer: Enrico Tassi gareuselesi...@debian.org Changed-By: Enrico Tassi gareuselesi...@debian.org Description: liblua5.1-svn-dev - Transitional package for lua-svn-dev liblua5.1-svn1 - Transitional package for lua-svn lua-svn- Subversion library for the Lua language lua-svn-dev - Development files for the Subversion library for the Lua language Changes: lua-svn (0.4.0-6) unstable; urgency=low . * Update depends on liblua5.1-socket2 - lua-socket Checksums-Sha1: 88ee598f5bc88e8228a86e99f8d62747f918c42b 1434 lua-svn_0.4.0-6.dsc 2df72eeaed7f48257a206725ac8e291ee1c1d6c7 4220 lua-svn_0.4.0-6.debian.tar.gz 5a0a6e2952e2b9adf8fcc1146302ddd9eefa0d3e 17362 lua-svn_0.4.0-6_amd64.deb b217f592c9f5cf17ec753ae09a3131faa4a5 23234 lua-svn-dev_0.4.0-6_amd64.deb e341ada50f8346ec1dea0a7f9eb9f4f10f0e4263 3024 liblua5.1-svn1_0.4.0-6_all.deb 1924b0fb2f9490a20110b2575646c057b3b239e6 3030 liblua5.1-svn-dev_0.4.0-6_all.deb Checksums-Sha256: 81cb7c3c6c0b7a50ddcaa798020cd954e08b7f7dd730042c691b4d738bd4929f 1434 lua-svn_0.4.0-6.dsc 663105cfba2c52f88f63f8bbdc2b4a9fc14b344b0e8ed4d8519f52b6a4fafa2f 4220 lua-svn_0.4.0-6.debian.tar.gz 942652048757a55b455881e2818d7b13985ef4fcaa0fd7a331f10cb443a3c4b0 17362 lua-svn_0.4.0-6_amd64.deb 96b7e159bc40a58d60cf4af4c2942687c734103e74384a428ebe86b016c23806 23234 lua-svn-dev_0.4.0-6_amd64.deb 210086af89a6a2806dea4536b0aabce109f78798d6c168879b01623305fc37ab 3024 liblua5.1-svn1_0.4.0-6_all.deb 3b7a20aa68bdb4b5da2538ac7f904a5a3bfb9f4c72d9d030eebde8c7ed95f764 3030 liblua5.1-svn-dev_0.4.0-6_all.deb Files: 5a441c1b19b6620b8d01dc484739c397 1434 interpreters optional lua-svn_0.4.0-6.dsc a36e0bbffe48c130a20c81edb2fd 4220 interpreters optional lua-svn_0.4.0-6.debian.tar.gz 7f4d64647e15dc52e9c4a168b5e035ae 17362 interpreters optional lua-svn_0.4.0-6_amd64.deb fdd51b6412c37d2a77100be6f23f458f 23234 libdevel optional lua-svn-dev_0.4.0-6_amd64.deb c5954229ae260b84a43bf53940574ce2 3024 oldlibs extra liblua5.1-svn1_0.4.0-6_all.deb 6cd65626cee4a0283418cc2f8b47112e 3030 oldlibs extra liblua5.1-svn-dev_0.4.0-6_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk+sxXkACgkQ7kkcPgEj8vJb3wCgpI3ecg4qFKDqkmK99E6it3mw 4RIAnjiK+2CQMsGHtKqSvZEMfi8LIBrs =Xui1 -END PGP SIGNATURE- Accepted: liblua5.1-svn-dev_0.4.0-6_all.deb to main/l/lua-svn/liblua5.1-svn-dev_0.4.0-6_all.deb liblua5.1-svn1_0.4.0-6_all.deb to main/l/lua-svn/liblua5.1-svn1_0.4.0-6_all.deb lua-svn-dev_0.4.0-6_amd64.deb to main/l/lua-svn/lua-svn-dev_0.4.0-6_amd64.deb lua-svn_0.4.0-6.debian.tar.gz to main/l/lua-svn/lua-svn_0.4.0-6.debian.tar.gz lua-svn_0.4.0-6.dsc to main/l/lua-svn/lua-svn_0.4.0-6.dsc lua-svn_0.4.0-6_amd64.deb to main/l/lua-svn/lua-svn_0.4.0-6_amd64.deb -- 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/e1sslwh-ge...@franck.debian.org
Accepted nvidia-cuda-toolkit 4.2.9-1 (source all amd64 i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 11 May 2012 10:32:07 +0200 Source: nvidia-cuda-toolkit Binary: nvidia-cuda-toolkit nvidia-cuda-doc nvidia-cuda-gdb nvidia-visual-profiler nvidia-cuda-dev nvidia-opencl-dev libcudart4 libcublas4 libcufft4 libcusparse4 libcurand4 libnpp4 libcuinj4 libcupti4 libcupti-dev libcupti-doc Architecture: all amd64 i386 source Version: 4.2.9-1 Distribution: unstable Urgency: low Maintainer: Debian NVIDIA Maintainers pkg-nvidia-de...@lists.alioth.debian.org Changed-By: Andreas Beckmann deb...@abeckmann.de Description: libcublas4 - NVIDIA CUDA BLAS runtime library libcudart4 - NVIDIA CUDA runtime library libcufft4 - NVIDIA CUDA FFT runtime library libcuinj4 - NVIDIA CUDA INJ runtime library libcupti-dev - NVIDIA CUDA Profiler Tools Interface development files libcupti-doc - NVIDIA CUDA Profiler Tools Interface documentation libcupti4 - NVIDIA CUDA Profiler Tools Interface runtime library libcurand4 - NVIDIA CUDA Random Numbers Generation runtime library libcusparse4 - NVIDIA CUDA Sparse Matrix runtime library libnpp4- NVIDIA Performance Primitives runtime library nvidia-cuda-dev - NVIDIA CUDA development files nvidia-cuda-doc - NVIDIA CUDA and OpenCL documentation nvidia-cuda-gdb - NVIDIA CUDA GDB nvidia-cuda-toolkit - NVIDIA CUDA toolkit nvidia-opencl-dev - NVIDIA OpenCL development files nvidia-visual-profiler - NVIDIA Visual Profiler Changes: nvidia-cuda-toolkit (4.2.9-1) unstable; urgency=low . * New upstream release 4.2 (April 2012). * New download URL: http://developer.nvidia.com/cuda-downloads * Update symbols files. * debian/copyright: Update NVIDIA license. * The toolkit now supports GCC 4.6 (but nothing newer). Add g++-4.6 and gcc-4.6 as preferred alternative dependencies. Checksums-Sha1: fe35dfd29393b4069d87a06aa729a6608820444b 2989 nvidia-cuda-toolkit_4.2.9-1.dsc e6eaf2c7c50105a773639e54e2fd9bc5036c1ed7 485193319 nvidia-cuda-toolkit_4.2.9.orig.tar.gz 8d93649c1198e0f15fa130c43a844615aff411b9 28066 nvidia-cuda-toolkit_4.2.9-1.debian.tar.gz 9c09beb9051e8d76a5984aeac56d49a4a86a96e5 22151280 nvidia-cuda-toolkit_4.2.9-1_amd64.deb 873c0312b6215e073222a13a5667b40e1f2742bd 2178826 nvidia-cuda-gdb_4.2.9-1_amd64.deb c528ef83ac2c521a4d9be82cc03e2b5b835f70e3 41750954 nvidia-visual-profiler_4.2.9-1_amd64.deb af09fd1716d3b453194661402b9eca597797a9ca 520942 nvidia-cuda-dev_4.2.9-1_amd64.deb 9b88233dc455f8239091bc273eb91642a9d9c937 12214 nvidia-opencl-dev_4.2.9-1_amd64.deb 7a3651f2e67eec9c04a76e83dca97325296147eb 140110 libcudart4_4.2.9-1_amd64.deb 9b9555c8991e80e2e29d4b6e54d26c3d219363ab 18078922 libcublas4_4.2.9-1_amd64.deb 6d163cc1c426cb01a1b7fabcecd2754e11f7249b 7316368 libcufft4_4.2.9-1_amd64.deb d780e6368b2c08d61ccee1a9a3849aa241e3d75e 25295914 libcusparse4_4.2.9-1_amd64.deb 4920665cfe5df6ae9f10bc2b9350ed3e5f02837d 18760488 libcurand4_4.2.9-1_amd64.deb ac71ed4ad5a9f8591f524bdbe146cb8eb39c1178 7668222 libnpp4_4.2.9-1_amd64.deb 6cc9a245507544b31f8d1599b07b3b5d20dfdb48 76184 libcuinj4_4.2.9-1_amd64.deb 523e9879aa264ea114de00a6d06a62c1b0b53404 89704 libcupti4_4.2.9-1_amd64.deb 3e18ecdd92fa09bc3ceccd1c9640340c43b9222b 48070 libcupti-dev_4.2.9-1_amd64.deb 08869b5de017fad11f89c38d0852816397e4a968 28768280 nvidia-cuda-doc_4.2.9-1_all.deb 8c010316c217dcaac5047a303b18cb94ec73d2e1 725670 libcupti-doc_4.2.9-1_all.deb 089dd06e60116d91faf7398efef773a8fd17d3d5 21088832 nvidia-cuda-toolkit_4.2.9-1_i386.deb 4b45e59616aeeac62dc0ecd3d6601920c5b8457b 1886456 nvidia-cuda-gdb_4.2.9-1_i386.deb f268b484f39143676e6bda9e0765fde089f98404 41590254 nvidia-visual-profiler_4.2.9-1_i386.deb a911264582a7d13041b3ddbfe709b6b2d7d56f4d 520946 nvidia-cuda-dev_4.2.9-1_i386.deb a636ebd249ce296b2d2e64a53d9cae2e3b2f1d30 12216 nvidia-opencl-dev_4.2.9-1_i386.deb 568e42484bb201689adeb0daf4e5144c5b05a4e5 122512 libcudart4_4.2.9-1_i386.deb 9e997799ab69d864645e920c041e25d7afdb90f4 17543922 libcublas4_4.2.9-1_i386.deb b1a76779790453c63f78fbbcfb34aacc3c03ad5a 6734834 libcufft4_4.2.9-1_i386.deb d8b83b871dfaca92257e27deadebc79229b38840 23276234 libcusparse4_4.2.9-1_i386.deb f985ca3028f0077d5ca9cc8d052c5725956f2eb6 18767094 libcurand4_4.2.9-1_i386.deb 83686923067571c90ed578b2583d9a7fd21c6baa 7074148 libnpp4_4.2.9-1_i386.deb 42c686c4323127b6f034aa0300b42edfe73e014d 73346 libcuinj4_4.2.9-1_i386.deb 6498395d29fc0883c39539a547e24622e65d53c3 95666 libcupti4_4.2.9-1_i386.deb b3bfe122ea7effb455aba12e17ab19df1a1099da 48060 libcupti-dev_4.2.9-1_i386.deb Checksums-Sha256: adc3f0ea08e797b05b11534061ed67f46b5541c296c5e1c5fb2ec8af2870d39c 2989 nvidia-cuda-toolkit_4.2.9-1.dsc ac9a10b4f2da24797e6f3aab31bdcdc2362dbd33e014a3d7b3615500d0dcb24a 485193319 nvidia-cuda-toolkit_4.2.9.orig.tar.gz 7ab88bd29b015b0c333e897f5ae78c51e15fb335f876985e040c6cbff52ddffb 28066 nvidia-cuda-toolkit_4.2.9-1.debian.tar.gz 291cfcde8c419b1aa18ab12b8d75238f6ed8d47afb8ee817c49c579819d08d14 22151280
Accepted smarty-validate 3.0.3-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 10 May 2012 21:01:53 +0200 Source: smarty-validate Binary: smarty-validate Architecture: source all Version: 3.0.3-2 Distribution: unstable Urgency: low Maintainer: Mike Gabriel mike.gabr...@das-netzwerkteam.de Changed-By: Mike Gabriel mike.gabr...@das-netzwerkteam.de Description: smarty-validate - Server-side form validation plugin for Smarty Changes: smarty-validate (3.0.3-2) unstable; urgency=low . * New maintainer. Checksums-Sha1: ea5d9ec7def73eee6db717a3f30c3a80f05f31c1 1966 smarty-validate_3.0.3-2.dsc ab666e20fee8ff34fa9a7be7d92f27fca6dfb8c6 1547 smarty-validate_3.0.3-2.debian.tar.gz 621389cab8bcfccbcfb38ef2560bee4d20e9ba1a 23418 smarty-validate_3.0.3-2_all.deb Checksums-Sha256: 6d893e0faafc27e60bff8985881e433795bca73d670ca48a77e98704ca223db3 1966 smarty-validate_3.0.3-2.dsc b34e5bb8122e7e128805b00bf018bb175332cf81477b75b5c4700574d055703e 1547 smarty-validate_3.0.3-2.debian.tar.gz 87d9da8ef276590aafc8fd6cf2f8d214064e8a33fe5b8fd28fe03d2e307f8a6b 23418 smarty-validate_3.0.3-2_all.deb Files: 2d8d8e0ef25fb86be621343b1b96d2ec 1966 web optional smarty-validate_3.0.3-2.dsc 2e0e5e79fbe97c08a5786c3a45347970 1547 web optional smarty-validate_3.0.3-2.debian.tar.gz 1e95ef7a709ab72c4dc835ff98f88aea 23418 web optional smarty-validate_3.0.3-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Signed by Raphael Hertzog iQIcBAEBCAAGBQJPrMNjAAoJEOYZBF3yrHKaKVMP/R6JG2UMy/pyydSvmTx0Kaaj Q53HfVXqw7BeHtKNbCqfNCwhJJ2AmHS3MZ8lxnAsB7ZiCnvwfK5dm8QA1PrN67Nb jwaMaYkcFCGvVs/icy6p1Tyron3oQJdzcqxox7CdAyWTtGiMKOHZOEWbTTIYEPlN JtBXfuh6kilL/kF/QkrYOewdGe4MdZcT6drjbp55fPczWfvK/QXQ+2XnMFIbRcEw Xnuj5BnPcUYTfh9dN4Mz0q0RR95k71Hgn7b6P0xLZ8ArG6Ip/5hTHMu+E7Uxylyg +Jap8eT8vycZgrnOeb7gZTnMckWy+X3JYzmCNJiedHDQP2en8TaRbMzKEYESpIPD sJLL5GoDTMRRTjgCk86fK11qT8+WnAXeMFATCrS2qn1HG3vq1wh6BPczqpZxjpd+ IJNMUm20qdn0g7tntlujARf4H7p3X2SzVpl1geCQ+k/dFmVBaPQiX8YxMrW/bNK4 5sOAFzCIX+LpkEw5P2p8ltOxynna4obWuqBIwO+jLZHFV/JSA9FyU+bNK+wwPC67 2pcRChb6u1RXT2IHdeFbw8Luq1IM8omMxPL+S/e9YoG7QqlYClAiPQDHwlzz537T PIFVYc5iw4YhH9LgTzDlYboSfIISlv7PnogqL4KKZZbIU6IqRaLYoNvvWX6hqm7L Ske20mCoE5HH87VkaFEk =Mu5g -END PGP SIGNATURE- Accepted: smarty-validate_3.0.3-2.debian.tar.gz to main/s/smarty-validate/smarty-validate_3.0.3-2.debian.tar.gz smarty-validate_3.0.3-2.dsc to main/s/smarty-validate/smarty-validate_3.0.3-2.dsc smarty-validate_3.0.3-2_all.deb to main/s/smarty-validate/smarty-validate_3.0.3-2_all.deb -- 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/e1ssm5j-0004f4...@franck.debian.org