Re: Drop testing
> It may sound a bit radical, but core points have been mentioned in the > thread already. I suggest to do it in a more radical way: > > - unstable lockdown in the freeze > - drop Testing and concentrate on work instead of wasting time on >synching stuff. This eliminates the need for testing-security. See >the last part of the paper for details. Doing this would result in many users who currently run testing fall back to stable + backports or switch to another distro (ubuntu being a likely candidate), which in turn, would result in less bugreports and a less stable distribution. I, for one, wouldn't run unstable on my parents' box, whereas testing proved to be quite reliable there. Freezing unstable will get you nothing compared to what we have now. Those who don't care about a release, will not care that way either, just their complaints will get louder and more frequent. Those who are willing to do the work neccessary for the release are already trying to. Remember, Debian is a volunteer project, you cannot force people to do something they do not want to. > - about the "filtering updates for frozen" - yes, some additional >manpower is required but that work must be done. The problems with >Testing synchronisation are not of pure technical nature, they are >social problem, and so they should be solved by people and not >scripts. Yes, testing synchronisation is not a purely technical matter. Nor is it purely social, so the testing scripts, which automatically keep stuff in sync, are a real help. On top of that, package maintainers coordinating with each other (the social part) is welcomed too, and should be encouraged. (And those who break a transition should be kicked in the ass, so they won't try it again :P) I firmly believe that fixing the problems with testing (mainly testing-security at this point in time) would be MUCH better than dropping testing and freezing unstable before the next release. -- Gergely Nagy
Re: Drop testing
rent system better - THAT would be very welcome. Like enhancing the logic of the testing scripts, which decide when and how a package migrates from unstable to testing, so migrations could get faster and large blocking stuff could be eliminated, that would help the release. Placing burden on people who already have more than enough to care and worry about won't help at all, methinks. > > Those who don't care about a release, will not care that way either, > > just their complaints will get louder and more frequent. Those who are > > How should they complain? "We cannot update foo in Sid because it has > been frozen for three weeks now, nya, nya". The answer would be some > analogue to RTFM (HTFR, help the f... release). Yes, that would be an answer. And how would that help the release? Would that answer make them more interested in a release? (No, they'd probably go back to their regular work, giving thanks to $DEITY that they don't have to care about their packages, since they won't get into sid anyway, therefore they can use the time they'd work on packages to do their paid work.) > > willing to do the work neccessary for the release are already trying to. > > Yeah... with Testing overhead throwing stones in their way. What kind of stones, if I may ask? And why not teach testing that throwing stones is a Bad Thing, instead of hiding in a cave, hoping that some day the blizzard that a frozen unstable generates goes away? > > Remember, Debian is a volunteer project, you cannot force people to do > > something they do not want to. > > Motivation is the only factor to make them do things. Having to care > about the release in order to continue the "fun work" leads to > motivation. Nope. Making unstable does not force them to care about the release. They'll find something else that statisfies them. If they don't want to care about the release, you will not be able to force them. > > >Testing synchronisation are not of pure technical nature, they are > > >social problem, and so they should be solved by people and not > > >scripts. > > > > Yes, testing synchronisation is not a purely technical matter. Nor is it > > purely social, so the testing scripts, which automatically keep stuff in > > sync, are a real help. On top of that, package maintainers coordinating > > They are overhead. How so? A release needs all architectures in sync, testing does that for us without much manual hackery. I don't see why it is so much an overhead. Agreed, it does have _some_ overhead, since a package needs time to migrate. But that's not neccessarily a bad thing. It's a compromise, and as far as I see, a good and useful one. So far I didn't hear _any_ convincing argument against it. > > with each other (the social part) is welcomed too, and should be > > encouraged. (And those who break a transition should be kicked in the > > ass, so they won't try it again :P) > > What's the problem? If you feel bored, go to #debian-bugs and help > fixing RC bugs. We could have a BSP every three days or so. There you > will have semi-social contact and can motivate each other to do the > actual work. ...and that can be done with testing in place, with all the benefits it provides. So far, the main complaint against testing is that sometimes packages get stuck. *Duh*, so fix the problem that made them stuck. That might need some social engineereing, as most of the time, stuckage is not caused by technical problems. Would you want to push the same larger update into a frozen unstable, you'd run into the very same problems anyway. -- Gergely Nagy
Re: mipsel drop / buildd situation Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]
On Tue, 2005-03-08 at 14:36 -0800, Clint Byrum wrote: > On Tue, 2005-03-08 at 22:22 +0100, Wouter Verhelst wrote: > > Op di, 08-03-2005 te 10:33 -0800, schreef Clint Byrum: > > > How much would it help with the current problems if we just picked 3 > > > arches(mipsel, s390, ???) > > > > This argument has been brought up so many times by now that I'm amazed > > people /still/ try it. > > > > The answer is, simply, 'not'. Go learn to use google if you want to know > > why. > > > > Good idea.. google is a great tool for this sort of thing. I put this > one in: > > site:lists.debian.org architectures sarge debian-devel [...] > Nope.. nope.. there aren't too many architectures! You're right. Just to chime in, not saying that maintaining a consistent state between architectures is an easy thing and presents no problems, but Debian is the only distribution that supports all these many architectures. This has the *HUGE* benefit of making the life of those of us who actually run quite a few different architectures, to have the same distribution on all our machines. So, from my point of view, there aren't too many architectures. Actually, the fact that Debian runs on so many architectures is in the top five reasons I'm a Debian user. -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mipsel drop / buildd situation Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]
On Tue, 2005-03-08 at 16:22 -0800, Steve Langasek wrote: > Hi Gergely, > > On Wed, Mar 09, 2005 at 12:56:10AM +0100, Gergely Nagy wrote: > > Just to chime in, not saying that maintaining a consistent state between > > architectures is an easy thing and presents no problems, but Debian is > > the only distribution that supports all these many architectures. This > > has the *HUGE* benefit of making the life of those of us who actually > > run quite a few different architectures, to have the same distribution > > on all our machines. > > > So, from my point of view, there aren't too many architectures. > > Actually, the fact that Debian runs on so many architectures is in the > > top five reasons I'm a Debian user. > > Out of curiosity, how many of these architectures are you running stable on? i386, arm, m68k, mipsel. (alpha, powerpc and possibly sparc will be added to the list when sarge releases; if amd64 was official, that would get added there too) -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFA: dpatch -- patch maintenance system for Debian source packages
retitle 264567 RFA: dpatch -- patch maintenance system for Debian source packages thanks I don't have time to properly maintain dpatch, nor do I use it anymore, so a new maintainer is probably justified, to say the least. You might consider this an O:, even. It is only RFA, because I do not want to upload a new, probably half-broken dpatch just to orphan it. -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFA: dpatch -- patch maintenance system for Debian source packages
> > >I don't have time to properly maintain dpatch, nor do I use it anymore, > > >so a new maintainer is probably justified, to say the least. > > > > > >You might consider this an O:, even. It is only RFA, because I do not > > >want to upload a new, probably half-broken dpatch just to orphan it. > > > > I would be willing to be part of a dpatch team, if I am considered > > acceptable by the other people wanting to take over the package. > > > > I do, however, neither have knowledge, expertise nor time to take the > > package alone. > > I am also interrested in being a part of it. What about > making a project on alioth like we did for fetchmail? It is already there, and has been from day 1. We didn't use the stuff provided by alioth though... Mostly the arch repo was in use, and nothing else. -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apply to NM? ha!
On Tue, 2005-01-25 at 15:00 +, Henning Makholm wrote: > Scripsit Helen Faulkner <[EMAIL PROTECTED]> [...] > > I do not believe that being thick-skinned enough to cope with people > > who are very agressive or insulting should be a requirement for > > involvement in Debian. > > I believe that it *should* be a requirement that one has enough calm > to most of the time respond to (percieved or actual) aggression and > insults in a less aggressive and insulting way than the other party > uses. Otherwise the project will surely die (film at 11!) from runaway > flamewar escalation. > > If you want to describe that as "thick-skinned enough to cope" (which, > based on my understanding of English, would not be a bad description), > then yes, somebody involved in Debian *should* be thick-skinned > enough to cope. Indeed. Even if all of us start to behave ourselves and avoid nasty flamewars (ha! in your dreams! :P), we still have to deal with the occassional bugreporter of Barbaric Communication School For 1337 People (the `f**k you, this piece of s***e doesn't work, go fix it or I'll be REAL angry and how you dare you release such a [EMAIL PROTECTED]' kind). It can help a lot when one can reply to such reports calmly and in a civilized manner. And a thick skin certainly helps a lot here. > > Shouldn't we be more interested in someone's technical skills, and > > their ability to work well with others? > > I'm lost here. It seems that you are arguing that you *don't* want > "ability to work well with others" (which in my book includes enough > thick-skinnedness not to escalate flamewars) to count? Same here.. If we ignore internal agression, one still needs a thick enough skin (although, a bit thinner as otherwise) to deal with occassional agression originating from outside (be that a bug report, a Debian or linux-flaming article somewhere on the net, etc), preferably calmly, without having ones blood pressure rise to unhealthy heights. -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apply to NM? ha!
On Tue, 2005-01-25 at 12:02 -0600, John Hasler wrote: > Gergely Nagy writes: > > Indeed. Even if all of us start to behave ourselves and avoid nasty > > flamewars (ha! in your dreams! :P), we still have to deal with the > > occassional bugreporter of Barbaric Communication School For 1337 People > > (the `f**k you, this piece of s***e doesn't work, go fix it or I'll be > > REAL angry and how you dare you release such a [EMAIL PROTECTED]' kind). > > That sort of hostility is much easier to deal with calmly than hostility > from fellow developers. That is roughly what I said later in that mail too. But it still needs thicker-than-average skin, I believe (which was the point I was trying to support, no more, no less). -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FTBFS for illegal archs
> does anyone knows a solution to let packages FTBFS on > buildd's which architecure are not supported by the > software? If the arch is not supported by the package, why is it in the packages Architecture: line to begin with? -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dependency on base package adduser ?
On Tue, 2005-05-10 at 09:12 +0200, Petter Reinholdtsen wrote: > [Matthijs Mohlmann] > > But i'm not really sure about it because adduser is a base > > package. And i thought you don't have to depend on a base package. > > Where did you get that idea? Any references to documentation stating > this? > > I suspect you confuse this with build-dependencies, where you can drop > dependencies on build essesials. A package is supposed to have a > complete and correct list of dependencies for its binary packages. > Just look at how all binaries depend on libc. It is a base package, > but still listed as a dependency. Furthermore, as adduser is used in preinst, the package must Pre-Depend on it (according to my reading of Policy 7.2). -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Changes to the weekly WNPP posting
On Thu, 2005-05-19 at 17:43 +0100, Martin Michlmayr wrote: > * Christoph Berg <[EMAIL PROTECTED]> [2005-05-19 18:40]: > > How about posting the announcements to -devel (instead of -d-a)? If > > only new entries are included, it wouldn't hurt much for those who > > are not interested. > > I agree that this might be a good idea. debian-wnpp is quite > cluttered with all the control messages from the BTS. > > What do other people think of this? Do you want a shorter WNPP > posting with only new entries on -devel? I think shorter WNPP postings with only new entries posted to -devel (or even -d-a) would be much better. I fall into the "doesn't read WNPP summaries because they're too friggin' long" category, but I'd certainly glance through them, would they be shorter and posted to a list I'm subscribed to most of the time. -- Gergely Nagy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: A new video-related section
On Fri, 2005-05-27 at 14:17 +0300, Cesar Martinez Izquierdo wrote: > El Viernes 27 Mayo 2005 14:09, Pierre Habouzit escribió: > > multimedia seems more appropriate. most of the video player actually are > > music player too, and some music player can show video with appropriate > > plugins (xmms e.g.) > > > > though, that would mean that 'sound' won't have that many package. so > > maybe we should rename sound into multimedia and populate it with video > > players too ? > > I support renaming sound into multimedia and include video and sound stuff > there... What about players that only play sound? Like mpg321 and friends? That's hardly multimedia... (and the set of libraries that deal with sound, bindings thereof, etc, etc, etc...) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: A new video-related section
On Fri, 2005-05-27 at 07:38 -0400, Roberto C. Sanchez wrote: > On Fri, May 27, 2005 at 01:26:59PM +0200, Gergely Nagy wrote: > > On Fri, 2005-05-27 at 14:17 +0300, Cesar Martinez Izquierdo wrote: > > > El Viernes 27 Mayo 2005 14:09, Pierre Habouzit escribió: > > > > multimedia seems more appropriate. most of the video player actually are > > > > music player too, and some music player can show video with appropriate > > > > plugins (xmms e.g.) > > > > > > > > though, that would mean that 'sound' won't have that many package. so > > > > maybe we should rename sound into multimedia and populate it with video > > > > players too ? > > > > > > I support renaming sound into multimedia and include video and sound > > > stuff > > > there... > > > > What about players that only play sound? Like mpg321 and friends? > > That's hardly multimedia... > > Not every package in gnome is actually GNOME. They are components that > are useful in a GNOME environment. Likewise, every package in a > multimedia section does not specifically need to provide all multimedia > functions itself. It simply has to be useful in a multimedia > environment. Then media players are just fine in graphics or sound, depending on which is their main focus (or they could even be in gnome or kde, or whatever). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: A new video-related section
On Fri, 2005-05-27 at 14:00 +0200, Philipp Kern wrote: > Gergely Nagy wrote: > > Then media players are just fine in graphics or sound, depending on > > which is their main focus (or they could even be in gnome or kde, or > > whatever). > > Please see it from a user's point of view. If one wants a media player > why should (s)he look in "gnome" or "kde"? And I personally would not > expect it in graphics either. In fact some players are currently in the > section of their corresponding desktop environment. > > But following your statement all media players should go into "sound", > as they play sound files and movies (which also have a sound track in them). I am looking from a users point of view. If I'm looking for a console based ogg player, the last section I'd check is multimedia. That belongs to sound, in my opinion. So do the various trackers and drum machines. You can't just rename sound, and move the media players from other sections there. You can't satisfy all users if one package can be only in one section, I believe. Eg, I'd expect Totem to be in Gnome, Multimedia, Sound and Graphics. Not any single one of those, but all of them. If you want to change something, make it right, and don't replace something inflexible with another inflexible half-solution, but aim for a better one, I'd say. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: A new video-related section
On Fri, 2005-05-27 at 14:13 +0200, Pierre Habouzit wrote: > Le Vendredi 27 Mai 2005 14:00, Philipp Kern a écrit : > > Gergely Nagy wrote: > > > Then media players are just fine in graphics or sound, depending on > > > which is their main focus (or they could even be in gnome or kde, > > > or whatever). > > > > Please see it from a user's point of view. If one wants a media > > player why should (s)he look in "gnome" or "kde"? And I personally > > would not expect it in graphics either. In fact some players are > > currently in the section of their corresponding desktop environment. > > > > But following your statement all media players should go into > > "sound", as they play sound files and movies (which also have a sound > > track in them). > > the right thing to do would be to switch from sections, to keywords, so > that kmplayer could live in sound + video + kde, instead of multimedia > that is not very informative. Now this, I'd second :) (OTOH, I'm not volunteering to implement support for this, I don't care about this that much :P) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[CFH] Please test new dpatch in experimental
Hi!
I've uploaded a new dpatch into experimental, with two new interesting
features in dpatch-edit-patch (thanks to Marc Haber) that I would like
to subject to extensive testing before I upload the package to unstable.
The package is available from both http://incoming.debian.org/ and
http://dpatch.alioth.debian.org/. It should hit the mirrors with the
next pulse.
As for the new features, the first - and probably less problematic one -
is that dpatch-edit-patch's default behaviour was changed slightly.
Before, it cleaned the source tree before copying it to a temporary
location. Now it does not do that. It copies the tree as-is, and cleans
the copied, temporary tree. This is very handy when one regularily works
on a half- or fully-built tree, and does not want to clean that.
However, the drawback is, that this way far more data gets copied, and
that might be slow. Therefore a --clean option is provided that restores
the old behaviour.
The other new feature, which in my optionion would need more testing (I
tested the other one as much as I could, but this other I can't. At
least, not easily). So, the second new feature is the --debianonly
option. This is for trees that consist only of a debian/ directory. The
original tarball will be searched for in the parent directory, and if
not found, dpatch-edit-patch tries to download it from the network
(using debian/watch and curl, or apt-get source). This is interesting
for those who only store the debian/ part of their packages under
revision control.
So, that's it! I believe these two are important usability features, so
I'd like to ask all you dpatch-edit-patch users to test this carefully,
so when it gets uploaded into unstable in a few weeks, all remaining
bugs (if any) will be ironed out already.
Thanks in advance,
Gergely Nagy
--
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [CFH] Please test new dpatch in experimental
> > The other new feature, which in my optionion would need more testing (I
> > tested the other one as much as I could, but this other I can't. At
> > least, not easily). So, the second new feature is the --debianonly
> > option. This is for trees that consist only of a debian/ directory. The
> > original tarball will be searched for in the parent directory, and if
> > not found, dpatch-edit-patch tries to download it from the network
> > (using debian/watch and curl, or apt-get source). This is interesting
> > for those who only store the debian/ part of their packages under
> > revision control.
>
> Please also look in .svn/deb-layout for a line like:
>
> origDir=/home/inet/debian/dev/tarballs
>
> That would be the most probable location for the orig tarball.
Done in the arch repo, thanks!
For interested parties, the patch is attached.
--
Gergely Nagy
--- orig/dpep/dpatch-edit-patch.functions
+++ mod/dpep/dpatch-edit-patch.functions
@@ -233,6 +233,9 @@
DPEP_ORIGTARGZ="$(readlink -f "../$ORIGTARGZ")"
elif [ -n "${DPEP_ORIGTARDIR}" ] && [ -f "${DPEP_ORIGTARDIR}/${ORIGTAGZ}" ]; then
DPEP_ORIGTARGZ="$(readlink -f "${DPEP_ORIGTARDIR}/${ORIGTAGZ}")"
+elif [ -f ".svn/deb-layout" ]; then
+ DPEP_ORIGTARGZ="$(readlink -f "$(cat .svn/deb-layout | sed -e "s,^origDir=,,")/${ORIGTARGZ}")"
+ return 0
elif [ -f "debian/watch" -a -x $(which curl) ]; then
if curl "$(< debian/watch sed -n "/^\\(http\\|ftp\\)/{s/^\\([^(]\\+\\)([^)]*)\\([^ ]*\\).*/\\1${UPSTREAMVERSION}\\2/;s///g;p;q;}")" > ../$ORIGTARGZ; then
DPEP_ORIGTARGZ="$(readlink -f "../$ORIGTARGZ")"
dpatch 2.0.0 uploaded to experimental
(Umm... err... *swallow*, *crowd laughs*, well...) Hello Nurse! I mean, PEOPLE! I always wanted to read my own post to debian-devel-announce, so I now take the opportunity to pollute^Wannounce a set of BIG changes in dpatch. There are significant changes in both the code and in how the source is managed. Since most of you are probably not interested in the latter, I will start explaining that. In short: the rewrite did not happen in CVS, and CVS probably will not be kept entirely up-to-date (meaning that only the releases will be committed there). Instead, I used `arch'[1] for version control. See the instructions[2] for how to obtain the sources from arch directly. So! After this short advertisement, let me continue with the more interesting developments! First of all: where to get it? dpatch 2.0.0 was uploaded to experimental today, and - just in case - is also available from http://people.debian.org/~algernon/. In short: dpatch has been rewritten, but from the users perspective it should be fully backwards compatible. That is, existing users will not find their packages broken by the rewrite. The rewrites main purpose was to collect the logic into one place, so only that one single point has to know how to deal with debian/patches. This - call it a library for now - provides an unified interface to scripts, so that they do not have to touch the patches directly at all. Ok, ok, I stop talking in pictures and go on with the glory details. All the logic is now in /usr/bin/dpatch. Most of the scripts have been converted to use this. `dpatch.make' has also been rewritten, it became a quite thin wrapper around /usr/bin/dpatch. What does this mean for existing users who are happy with how things were? Nothing. For them, dpatch will work exactly as it did before. And for those, who were not satisfied? Well, quite a few things... One of the benefits is that if you do not like the default patch-stamp, or the way dpatch.make did its stuff, you can easily change that now: you don't include dpatch.make, but write your own patch target: most of the time, it will be a one line call to dpatch. For example, if you want to have a file with the applied patches in, say, Emacs' outline format, you can do that. Either you write your `# DP:' comments appropriately, and use something like this: , | patch: | dpatch apply-all | dpatch cat-all --desc-only > Debian-patches.txt ` Or you add support for your dpatch scripts to handle a package-specific option, and use that. Before adding non-standard options, please think twice, and contact us, so we can prepare some sort of naming guideline. Anyways, all options with a `pkg-' prefix are reserved for the user, and are guaranteed that they will never ever be used by dpatch. If you go this route, the relevant entry in your debian/rules might look like this: , | patch: | dpatch apply-all | dpatch call-all --argument=pkg-info > Debian-patches.txt ` You could also add code to your apply command to have a side effect like this, but that is rude and is a colossal hack. Besides, you do that, and I'll send my tamagotchi to sit on you. There are probably far more cases where the new dpatch can do things the old one could not (like applying patches to a different tree than the current one and putting stamp files somewhere else than debian/patches), but we didn't think of yet. I can promise that the most interesting, weird or plain oh-my-god-this-is-disgusting ideas will appear in the examples shipped with dpatch. Oh, I need to mention the new ability of dpatch that makes it possible to pipe 00list through `cpp', so that one can write complex rules like this: , | #if !defined(DEB_BUILD_ARCH_i386) && !defined(DEB_BUILD_ARCH_m68k) | somepatch | #endif | | #include DPATCH_ARCH "/00list" ` And so on... This also allows C-style commands which is also a plus in my book. Please help us testing this release, by giving it a go, and checking if it does not break existing functionality or if there are more features wanted[3]! Cheers, -- Gergely Nagy [1] http://www.gnu.org/software/gnu-arch/ [2] tla register-archive [EMAIL PROTECTED] \ http://arch.debian.org/arch/dpatch/[EMAIL PROTECTED] tla get [EMAIL PROTECTED]/dpatch--mainline--2.0 \ dpatch-2.0 [3] How about gettextizing dpatch? :) [4] 404. There was no such link. pgpeP5VD52S3B.pgp Description: PGP signature
Re: Mass-filling against packages without MD5-sums? (was: debsums for maintainer scripts)
> * Michael Ablassmeier ([EMAIL PROTECTED]) [031201 19:55]: > > I think, at least Packages like "dpkg" or "gnupg" should call > > "dh_md5sums". I was wondering, if it would be usefull to make > > a mass bug-filling against these Packages. Before, it would be > > nice to have a List of Packages (maybe sorted by Maintainer) > > which do not call "dh_md5sums". > > > > IMHO Lintian should also check if "dh_md5sums" is called and > > print at least a warning if this is not the case. > > I agree with you, and I would support mass-filling, if first such a > list has been published here on d-d, together with the warning of > mass-filling. I disagree. Filing bugs on packages not having md5sums _might_ be ok, altough last time I checked, md5sums were only sugested, nowhere near a must in policy. Filing bugs based on missing calls to dh_md5sums is simply stupid. You don't need to build-depend on debhelper to have md5sums.
Re: forwarding bugs to other packages
> I could just close the bug against my package, but this means other > people will encounter the same problem and report the bug against my > package again (as it isn't always obvious that it isn't the fault of > my package). How about merging those bugs with the bug reported against the correct package? That'd result in your buggetting automatically closed when the bug is fixed in the other package, it would probably make filtering easier too, and the bug would normally appear on the bug page of your package, so users would notice it and won't report it again and again. HTH, -- Gergely Nagy
Possible mass filing of bugs, take #2.1
Hi!
Some time ago, I assembled a list of packages which were arch: all,
yet used binary-arch to build the package, and another list of
packages whose debian/copyright did not have a pointer to the full
license.
Unfortunately, I wasn't able to file the bugs at that time, so I redid
the test now. Since there were no objections last time, and I already
filed reports about these kind of bugs, I will start filing tonight.
As always, the results weren't checked by hand, so there might be
false positives (but I highly doubt it). I did not check the BTS
either, since I'm writing this offline. If I happen to submit
duplicate bugs, feel free to merge it or close it right away.
So! Here is the list, categorised by the type of the bug:
debian/copyright problems
=
In the following packages, debian/copyright does not include a
verbatim copy of their copyright and distribution license, nor any
pointers to /usr/share/common-licenses/{Artistic,GPL} or
/usr/share/doc/perl/copyright.
Since including a verbatim copy of the _whole_ license (with the
exception that in case of the GPL and some other selected licenses,
for which a pointer is enough) is a must, I believe this is at least
an important bug.
So, the packages with this kind of problem:
appconfig-perl, chatbot-eliza, ciphersaber, crypt-ssleay, delimmatch
freedb-disc-cover, glade-perl, hns2, html-munger, libacme-poe-knee-perl
libalgorithm-diff-perl, libalias-perl, libapache-authnetldap-perl
libapache-authznetldap-perl, libapache-configfile-perl
libapache-dbilogconfig-perl, libapache-dbilogger-perl, libapache-dbi-perl
libapache-reload-perl, libapache-session-perl, libarchive-tar-perl
libauthen-pam-perl, libbit-vector-perl, libboulder-perl
libbusiness-onlinepayment-tclink-perl, libcache-cache-perl, libcgi-pm-perl
libclass-autouse-perl, libcompress-zlib-perl, libconfig-ini-perl
libconvert-asn1-perl, libconvert-ber-perl, libconvert-units-perl
libcrypt-cracklib-perl, libcrypt-smbhash-perl, libcurses-perl
libdata-compare-perl, libdata-showtable-perl, libdate-calc-perl,
libdbd-mysql-perl
libdbd-pg-perl, libdbd-ram-perl, libdbd-sqlite-perl, libdbi-perl
libdevice-serialport-perl, libdigest-hmac-perl, libdigest-md2-perl
libdigest-md4-perl, libdigest-md5-perl, libdigest-perl, libdigest-sha1-perl
libemail-valid-perl, liberror-perl, libexpect-perl, libextutils-f77-perl
libfile-cache-perl, libfile-slurp-perl, libfilesys-diskfree-perl
libfile-tail-perl, libfilter-perl, libgd-gd2-perl, libgd-noxpm-perl, libgd-perl
libgnome-gnorba-perl, libhtml-embperl-perl, libhtml-format-perl
libhtml-parser-perl, libhtml-table-perl, libhttp-ghttp-perl,
libi18n-charset-perl
libimage-info-perl, libio-socket-ssl-perl, libio-stty-perl, libipc-run-perl
libipc-sharelite-perl, libjcode-pm-perl, liblingua-ispell-perl
liblog-agent-logger-perl, liblog-agent-perl, liblog-agent-rotate-perl
libmail-bulkmail-perl, libmail-cclient-perl, libmail-pop3client-perl
libmailtools-perl, libmath-basecalc-perl, libmd5-perl, libnet-daemon-perl
libnet-dns-perl, libnet-finger-perl, libnet-google-perl, libnet-ipnetmember-perl
libnet-jabber-perl, libnet-ldap-perl, libnet-netmask-perl, libnet-perl
libnet-ph-perl, libnet-rawip-perl, libnet-scp-perl, libnetserver-generic-perl
libnet-server-perl, libnet-smtp-server-perl, libnet-snmp-perl, libnet-snpp-perl
libnet-ssh-perl, libnet-ssleay-perl, libnet-telnet-perl, libnet-tftp-perl
libnet-whois-perl, libnet-whois-raw-perl, libnews-newsrc-perl
libparse-syslog-perl, libplot-perl, libplrpc-perl
libpoe-component-client-dns-perl, libpoe-component-client-http-perl
libpoe-component-irc-perl, libpoe-component-jobqueue-perl, libpoe-perl
libprpc-perl, librtf-document-perl, libschedule-cron-perl, libset-intspan-perl
libset-object-perl, libstorable-perl, libstring-random-perl, libsys-cpuload-perl
libtangram-perl, libtemplate-perl, libterm-shell-perl, libtest-harness-perl
libtest-unit-perl, libtext-kakasi-perl, libtext-template-perl
libtime-modules-perl, libunicode-japanese-perl, libunicode-map8-perl
libunicode-map-perl, libunicode-maputf8-perl, libunicode-string-perl
libxml-csv-perl, libxml-dom-perl, libxml-dumper-perl, libxml-filter-xslt-perl
libxml-generator-perl, libxml-grove-perl, libxml-libxml-perl,
libxml-libxslt-perl
libxml-parser-perl, libxml-sablot-perl, libxml-sax-machines-perl
libxml-sax-writer-perl, libxml-stream-perl, libxml-twig-perl, libxml-xerces-perl
libxtm-perl, mime-lite, net-hotline, pilot-link, soap-lite, timedate
binary-arch VS Arch: all
Some of the packages are fully Architecture: all, yet, they build the
.deb in the binary-arch target. Since policy states that
`binary-arch' builds the binary packages which are specific to
a particular architecture, and `binary-indep' builds those
which are not.
I consider this a policy violation, therefore a serious bug.
(Hint: one shouldn't follow the dh_make template blindly. A little
thought is always a good thing.)
And the list of packages who were caug
Re: Possible mass filing of bugs, take #2.1
> >> Rather than mass filing bugs, can you write a lintian check for it > >> instead? > > > > He filed a bug about Upstream Author(s), I fixed it, and then shaleh and > > others reverted it >:) > > > > I think we have better things to be nitpicky about. Besides, lintian tries to > only enforce policy. Spelling checks... But we had that argument already, interested parties can check the bug logs. pgpXmyamSAAic.pgp Description: PGP signature
Re: Possible mass filing of bugs, take #2.1
> On Tue, Aug 20, 2002 at 05:56:58PM +0200, Gergely Nagy wrote: > > Some time ago, I assembled a list of packages which were arch: all, > > yet used binary-arch to build the package, and another list of > > packages whose debian/copyright did not have a pointer to the full > > license. > > Rather than mass filing bugs, can you write a lintian check for it > instead? Well, how about writing a lintian check AND reporting? There is no guarantee that the maintainer will run lintian over the package, so I'd like to notify them. (No, I will not write a linda check, that is up to StevenK, if it is not done yet. :) pgpQAc1xupw8a.pgp Description: PGP signature
Bug#157449: lintian: check for missing reference to he perl license terms (Was: Re: Possible mass filing of bugs, take #2.1)
Package: lintian
Version: 1.20.17
Severity: wishlist
Tags: patch
> Rather than mass filing bugs, can you write a lintian check for it
> instead?
As promised, here is the check:
diff -u -urNad old/copyright-file new/copyright-file
--- old/copyright-file 2002-08-20 23:04:54.0 +0200
+++ new/copyright-file 2002-08-20 23:04:41.0 +0200
@@ -164,6 +164,11 @@
print "W: $pkg $type: copyright-does-not-refer-to-common-license-file
$1\n";
}
+if (m,(under )?(the )?(same )?(terms )?as Perl itself,i &&
+!(m,usr/share/common-licenses/, || m,usr/share/doc/perl,)) {
+print "E: $pkg: $type: copyright-file-missing-pointer-to-perl-license\n";
+}
+
exit 0;
# ---
diff -u -urNad old/copyright-file.desc new/copyright-file.desc
--- old/copyright-file.desc 2002-08-20 23:04:54.0 +0200
+++ new/copyright-file.desc 2002-08-20 23:04:36.0 +0200
@@ -112,3 +112,10 @@
Ref: policy 13.6
Info: In the directory name /usr/share/common-licenses, licenses is spelt with
an `s', not with as licences with a `c'.
+
+Tag: copyright-file-missing-pointer-to-perl-license
+Type: error
+Ref: policy 13.6
+Info: If your package is released under the same terms as Perl itself,
+ it should either refer to the Artistic and GPL files in the
+ /usr/share/common/licenses directory, or to /usr/share/doc/perl/copyright.
Obviously, this is tuned for Perl modules released under the same
terms as Perl itself.
The check is tested outside of lintian, and appears to work
correctly. I hope it'll work in lintian too.
Re: Symlinking /usr/share/doc/ is not allowed
> Unless someone can convince me that my interpretation of your policy is > wrong I'll start filing bugs against packages that symlink > /usr/share/doc/ to the directory of another package. Policy 13.3 says: ... `/usr/share/doc/' may be a symbolic link to another directory in `/usr/share/doc' only if the two packages both come from the same source and the first package Depends on the second. ... That is, symlinking this way is allowed. However, symlinking the directory of a package coming from another source, is not. I wonder if any package in Debian does that... -- Gergely Nagy
Re: moving a package from non-US/main to main?
If the source includes SHA, then it must remain in non-US, together with the binaries (iow: binaries compiled without SHA, from a source which has SHA in it must be in non-us still). At least, that's what I think, but I may be wrong. -- Gergely Nagy \ mhp/|8] pgpJ5XuclYybE.pgp Description: PGP signature
Re: NMU upload but I'm the maintainer! (was: Fixed in NMU of sparc-utils 1.8-2)
Hello! > Maintainer: Eric Delaunay <[EMAIL PROTECTED]> > Changed-By: Eric delaunay <[EMAIL PROTECTED]> ^ These are not the same, note the case... Cheers, -- Gergely Nagy \ mhp/|8] pgpzmOMLrgPk3.pgp Description: PGP signature
Re: questions on ITP
You can either Cc: debian devel, or add a X-Debbugs-Cc: header (works like Cc, but includes the bug# in the subject too). IIRC, it is documented somewhere in the doc-debian package. Cheers, -- Gergely Nagy \ mhp/|8] pgpWqyKFvBmI9.pgp Description: PGP signature
Re: building a new debian package
It seems to be an autoconf/automake based project, from what you included in your mail, how about using make install DESTDIR=$(CURDIR)/debian/tmp from the install target of your debian/rules? Or if that doesn't work, you can still use make install bindir=$(CURDIR)/debian/tmp/usr/bin or something like that.. Cheers, -- Gergely Nagy \ mhp/|8] pgpS3dP2SXClJ.pgp Description: PGP signature
Re: [The good, the bad and] The Ugly -- the cosmetic rant
> I can see where a patch.diff might come in. It may not always be the > result of a DD not cleaning out the debian/ directory before building. > It may even be an essential part of the build process. Yes, but probably with a more suitable name.. (note that I checked the patch.diff itself, and it was a patch against debian/postinst; I should have mentioned that) > Sometimes it's a good idea to have separated patch diffs around, rather > than applying them en masse to the source code (except at build time to > a copy of the source, usually generated by "cp -l"). This can make > handling complex packages much easier. Yes. I've done that a few times, and prefer patching the sources at build time, instead of having all the patches mixed in the .diff.gz. > Me? I leave the dh_make comments in for the next poor soul who may have > to mangle my packages, or for if I have to modify the build script in > the future to use one of the unused targets. Why not change them to something more appropriate then? Which wouldn't say what to add below a comment, but would describe what the following block is doing. IMO, that is far more useful when you give the package to someone else. pgpFXzg9oQ2ZP.pgp Description: PGP signature
Re: maintainer for cervisia is MIA
> I mailed the maintainer of the above package on the eleventh of december and > haven't got a reply yet. All the bugs of the package are pretty old, a new > version of the proggy is also available upstream, current version is > a year > old. He is my applicant, and has a new version ready (with a few bugs waiting to be sorted out). Try mailing him again, he might have missed your mail. pgpBVZcxJClkZ.pgp Description: PGP signature
Re: Debbugs and ACK messages
> Is there anyone out there who actually appreciates the storms of > "Information received" acks that debbugs generates? If not, it is > fairly simple to turn them off - we just need to decide to do so. I do. If lists are slow, I get an ACK back quickly, and won't wonder for hours if my mail got through (flaky connection, ISP & whatnot). pgppTrDzPoVES.pgp Description: PGP signature
Bug#755887: ITP: adderall -- a miniKanren implementation in Hy
Package: wnpp Severity: wishlist Owner: Gergely Nagy * Package name: adderall Version : 0.1.2 Upstream Author : Gergely Nagy * URL : https://github.com/algernon/adderall * License : LGPL Programming Lang: Hy Description : a miniKanren implementation in Hy This is a dependency of Hydiomatic, a Hy code transformer. But it's useful in its own right too. I've yet to come up with a reasonable long description, though. The module will be packaged under the umbrella of pkg-hy, along with its dependency (monaxhyd) and Hydiomatic. Binary packages created will likely be called python-hy-adderall and python3-hy-adderall. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140724095920.19466.74391.reportbug@angthalion
Re: Seeking help with OpenVPN scripts and systemd
Daniel Dickinson writes: > On 10/09/14 02:52 PM, Noel Torres wrote: >> >> Yes. Why to install OpenVPN which might not work? aptitude will tell you >> that >> they are not coinstallable and the sysadmin will then have the option of >> switching init system to a non default one, knowing what that means, and >> having a working OpenVPN config, instead of (possibly) having a failing >> config >> and no clue about why. >> > +1 with the caveat that this is not a *solution* but a recognition of > the fact of the matter until the situation is resolved by the much > harder task of geting openvpn's config to work with systemd. OpenVPN works just fine with systemd. Its init script does not, but for quite a few use cases, that is not an issue: the package just comes disabled by default, where the admin has to do some local configuration. There is no problem with that, at all. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87r3zicl37@balabit.hu
Re: Let's abandon debian-devel.
> "David" == David L Craig writes: David> On 14Nov10:2325+0900, Charles Plessy wrote: >> With most of the work done on topic mailing lists, trolls lose the lever effect >> they have when feasting on debian-devel or debian-vote. Let's make our project >> stronger by reducing thr attack surface for troublemakers. David> But weaker by becoming more non-public? At what point David> is the Social Contract undermined? What about transforming David> those lists into readable by all but open only to David> certain responsible posters instead? You do realize topic lists are public too, right? -- |8] signature.asc Description: PGP signature
Re: Let's abandon debian-devel.
>>>>> "David" == David L Craig writes: David> On 14Nov10:2154+0100, Gergely Nagy wrote: >> You do realize topic lists are public too, right? David> Yes, but most Debian users don't even know about David> them nor do they need to since the traditional David> lists have been doing their jobs for quite a David> while. If you shut them down, I expect most of David> the public will not find the topic lists. Most Debian users need not concern themselves with development lists, like they usually do not subscribe to debian-devel@ either. If they do want to find a list for a particular topic, it is not rocket science to do so. They will find it. -- |8] signature.asc Description: PGP signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
> "Raphael" == Raphael Hertzog writes: Raphael> Packaging branches and tags Raphael> === [...] Raphael> The Git repository listed in debian/control's `Vcs-Git` field should Raphael> usually have its HEAD point to the branch corresponding to the Raphael> distribution where new upstream versions are usually sent. For Debian, Raphael> it will usually be `debian/sid` (or sometimes `debian/experimental`). Raphael> QUESTION: some people have argued to use debian/master as the latest Raphael> packaging targets sometimes sid and sometimes experimental. Should we Raphael> standardize on this? Or should we explicitly allow this as an alternative? I'd suggest not standardizing on this, but having a list of recommendations instead, without naming one single name as THE recommended one. For different use cases, different HEAD makes sense. Also, I like to name my branches according to the distribution that it will target, which means I prefer debian/unstable over debian/sid. For me, that makes more sense, at least in the case of unstable and experimental. For anything else, codenames it is. Raphael> When releasing a Debian package, the packager should create and push Raphael> a signed tag named `/`. For example, a Debian maintainer Raphael> releasing a package with version 2:1.2~rc1-1 would create a tag named Raphael> `debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a package with Raphael> version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags should Raphael> point to the exact commit that was used to build the corresponding upload. Mmm... I disagree here too. I think following upstream tagging conventions would be the way to go here. So if upstream uses `-` tags, then debian releases would be tagged like `debian/foo-2%1.2_rc1-1`, if upstream is `foo-1.2rc1`. Raphael> Other recommendations Raphael> = [...] Raphael> What to store in the Git repository Raphael> --- Raphael> It is recommended that the packaging branches contain both the upstream Raphael> sources and the Debian packaging. Users who have cloned the repository Raphael> should be able to run `dpkg-buildpackage -b -us -uc` without doing Raphael> anything else (assuming they have the required build dependencies). Raphael> It is also important so that contributors are able to use the tool of their Raphael> choice to update the debian/patches quilt series: multiple helper tools Raphael> need the upstream sources in Git to manage this patch series as a Git Raphael> branch. I'd like to note that there are very good reasons for a debian-only, overlay-style packaging repository too. This section should, in my opinion, at least acknowledge that, and briefly mention it as an option. I find it a bit sad that it was outright discouraged. For the record, I used to hate that style, and was an advocate for storing upstream sources in the repo too. Then I started maintaining ~6 packaging branches: three upstream versions, two packaging branch variants of each. The overlay style proved to be far superior in this case. In short, I'd suggest having the DEP document both layouts, and recommend using one of them, while also recommending to document it in debian/README.source. -- |8] signature.asc Description: PGP signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
> "Jonathan" == Jonathan Dowland writes: Jonathan> On Wed, Nov 12, 2014 at 03:38:59PM +0800, Paul Wise wrote: >> Personally I wouldn't use anything other than debian-only repos, at >> least for those where I have a choice. I also actively avoid >> contributing to packages that don't use such repos. Jonathan> And I'm the exact opposite. Which is fine - both layouts have their pros and cons and use cases. There are some cases where I prefer upstream+debian in the same repo, too. Hence, providing both as options, without a clear recommendation of one of them, in DEP-14 would benefit us all, in my opinion. -- |8] signature.asc Description: PGP signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
>>>>> "Raphael" == Raphael Hertzog writes: Raphael> Hi Gergely, Raphael> On Wed, 12 Nov 2014, Gergely Nagy wrote: Raphael> When releasing a Debian package, the packager should create and push Raphael> a signed tag named `/`. For example, a Debian maintainer Raphael> releasing a package with version 2:1.2~rc1-1 would create a tag named Raphael> `debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a package with Raphael> version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags should Raphael> point to the exact commit that was used to build the corresponding upload. >> >> Mmm... I disagree here too. I think following upstream tagging >> conventions would be the way to go here. So if upstream uses >> `-` tags, then debian releases would be tagged like >> `debian/foo-2%1.2_rc1-1`, if upstream is `foo-1.2rc1`. Raphael> And if upstream uses v1.2.3 we should use debian/v1.2.3-1? Yes. Raphael> Do you know many upstreams using "foo-1.2.3" as tags? syslog-ng and syslog-ng-incubator uses foo-1.2.3, so does a few of my own (libmongo-client, riemann-c-client), and I came across a few others, but I haven't been keeping track. Raphael> I must say that I don't see the value that this brings. It might be Raphael> aestethically more pleasant when browsing the list of tags but for Raphael> everything else, it's just more painful. We lose the ability to Raphael> easily identify the commit of a given Debian release (instead Raphael> of a simple lookup operation, you have to scan all existing tags, and even Raphael> then if you have no clear mapping with the Debian version, you can't be Raphael> sure that you will find the correct tag). It's just two lookups, but I see your point. Sticking to the more common v$VERSION as a recommendation is good enough. >> I'd like to note that there are very good reasons for a debian-only, >> overlay-style packaging repository too. This section should, in my >> opinion, at least acknowledge that, and briefly mention it as an option. >> I find it a bit sad that it was outright discouraged. Raphael> I'm open to that, but IMO the only case where there are very good reasons Raphael> are the case where the upstream data is really huge and not easily Raphael> patchable anyway (i.e. the case of openarena-data that Simon Mc Vittie Raphael> described in https://lists.debian.org/debian-devel/2014/08/msg00582.html). Raphael> Are there other reasons that you consider good enough to impose the above Raphael> penalties on other possible contributors (i.e. making it impossible to use Raphael> gbp pq or similar tools to update debian/patches)? My reason for going debian-only is that I'm doing far more packaging work, than upstream. I hardly ever touch upstream, to be honest. But I actively maintain half a dozen packaging branches, and do merges between them. This would be a big headache if upstream sources were there, because some of these branches belong to different upstream versions. >> For the record, I used to hate that style, and was an advocate for >> storing upstream sources in the repo too. Then I started maintaining ~6 >> packaging branches: three upstream versions, two packaging branch >> variants of each. The overlay style proved to be far superior in this >> case. Raphael> Can you elaborate on how it was superior? See the use-case above. It was superior because I could do merges much easier, my history looks nicer, and upstream can use my debian-only repo as an overlay too, to build their own unofficial packages. It's very useful not only for the case when you have numerous active packaging branches, but in the case when you work with upstream on unofficial packages, too. With an overlay, they can just include it as a submodule, or use git-buildpackage with its overlay support, on top of pretty much any codebase they want, with minimal modifications. Raphael> I have put this for now: Raphael> @@ -195,6 +203,12 @@ choice to update the debian/patches quilt series: multiple helper tools Raphael> need the upstream sources in Git to manage this patch series as a Git Raphael> branch. Raphael> +When you have good reasons to only store the `debian` packaging directory Raphael> +(for example when the uptream sources are really huge and contains mostly Raphael> +non-patchable data), you can do so but you should then document Raphael> +this in `debian/README.source` along with some explanations of the tool Raphael> +to use to build the package. Raphael> + Raphael> Managing debian/changelog Raphael> - Raphael> Does that sound better? Better, but this still leaves it as a second-class citizen, with which I'm not entirely happy with. -- |8] signature.asc Description: PGP signature
Re: Being part of a community and behaving
> "Cameron" == Cameron Norman writes: >>> OK, so the system has syslog-ng installed. For what ever reason >>> syslog-ng >>> is not starting automatically, but starts manually by systemctl. >> >>> syslog-ng version 3.5.6-2 >>> systemd version 215-5+b1 >> >> Maybe some failure to sync status correctly? syslog-ng does ship >> with a >> service file. What does: >> >> systemctl status syslog-ng >> >> say? Particularly the Loaded and Active fields should have some >> hint as >> to what's going on that's preventing the service from starting >> automatically. Cameron> Apparently this is a known issue, and another person has experienced Cameron> it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760426 That and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769499 are closely related, and will be fixed in the next syslog-ng upload (likely early next week). I know how to fix both, but lacked the time to implement said fixes so far. -- |8] signature.asc Description: PGP signature
Re: Being part of a community and behaving
> "Cameron" == Cameron Norman writes: Cameron> Apparently this is a known issue, and another person has experienced Cameron> it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760426 >> >> That and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769499 are >> closely related, and will be fixed in the next syslog-ng upload (likely >> early next week). I know how to fix both, but lacked the time to >> implement said fixes so far. Cameron> This is a great chance to use the 'newcomer' tag recently added as an Cameron> official tag. It is for relatively simple bugs that a fix is known Cameron> for, but the maintainer just does not have the time. Please do Cameron> consider it in the future! Sadly, no, it's not a great chance. The problem is not all that simple, and sadly explaining in sufficient detail what the issue is (so that it can be fixed by a newcomer) is more time and effort than fixing the bug itself. But I do know about the tag, and will use it for other issues, when it is fitting. -- |8] signature.asc Description: PGP signature
Re: machine readable copyright v1 and "GPL version 2 or later"
Andreas Noteng writes: > Hello, in one of my packages I have multiple files paragraphs with > license GPL-2+, at the end I have a standalone license paragraph labeled > GPL-2, this generates a lintian warning about missing license paragraph > GPL-2+. Shouldn't lintian ignore the +, because it only means this > version or, at your choice, any later version? I think it would be wrong > to label the GPL-2 license paragraph GPL-2+, because this text is the > exact text of version 2, even if you can choose to use any later > version. Lintian is correct. GPL-2 and GPL-2+ are different, and in the License: section, you still need to expand the license, at least as far as the short "This program is free software..." paragraphs, and that MUST be different between GPL-2 and GPL-2+. > What if you have both GPL-2 and GPL-2+ files paragraphs? Then you will have to have a GPL-2 and a GPL-2+ License section, where one says: License: GPL-2+ This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 as published by the Free Software Foundation, or (at your option) any later version. [...] And the other: License: GPL-2 This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 as published by the Free Software Foundation. [...] Notice the difference between the two. -- |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/87sjgitgpx.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Igor Pashev writes: > I wonder no one mention Solaris SMF :-) Does a free port of that thing exist, which we could use? -- |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/87fwbru8p7.fsf@algernon.balabit
Re: Making -devel discussions more viable
Riku Voipio writes: > On Thu, May 03, 2012 at 01:23:29PM +0200, Stefano Zacchiroli wrote: >> 3) public, but contributors-only list > >> This has been implemented by other FOSS projects. A notable example is >> Ubuntu who have a split between ubuntu-devel (project members only + >> whitelisting) and ubuntu-devel-discuss (free for all). I've never asked, >> but I have always suspected that they've done so in an attempt to >> improve over the experience of debian-devel participants. > >> The obvious drawback of this "solution" is that non-contributors will >> need someone to vouch for them to be whitelisted. > > How about a "automated" contributors-only list. > > To post to debian-devel, one would have to either submit a patch to a > bug, close a rt ticket, commit to one of the scm.debian.org or upload a > package to debian. Require that for *every* post to debian-devel? That seems a tiiiny bit excessive. As good as it might be to increase contributions, I'm afraid this would have the opposite effect: decrease the posts to the list, while not gaining anything. It also rules out contributions done on this very list, which - despite the tone of some recent threads - is not without precedent. On the other hand, if I can participate in a thread by pre-seeding my bucket of contributions, that might work. And just for the heck of it, this mail, and any other mail in the thread would have been made possible by the following things: http://packages.qa.debian.org/d/dh-exec/news/20120503T114724Z.html https://github.com/algernon/dh-exec/compare/b893f1eab5...bccacdb201 Nevertheless, if we adopt something like this - which I hope we don't have to -, another problem arises: how recent the contributions must be? Does opening bugs count? What if the contribution would be answering a question on the list? What if upstream wants to chime in to a discussion about his software on devel? Truth be told, a moderated debian-devel@ would make me very, very sad, no matter how the moderation would work. There must be a less forceful way. -- |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/87ipgdxr91.fsf@algernon.balabit
Re: Making -devel discussions more viable
Stefano Zacchiroli writes: > 2) "don't feed the troll" + report abuses to listmasters and act >accordingly Of the three, this is the least disruptive, in my opinion. Of course, all the problems you mention (social awkwardity, effort from the community and extra burden on listmasters) apply, BUT! Perhaps a compromise could be to close threads forcibly, and temporarily ban everyone from posting to the list, if they attempt to post to a closed thread after its closing has been announced (a little window of error should be given, of course, half an hour tops, or thereabouts). This reduces the social awkwardness, as we'd be reporting bad threads instead of bad people, and threads don't mind. It would reduce the load on listmasters, as threads are fewer than people, and there's less emotion involved, and justification is easier. And if so need be, the temporary bans can gradually increase in length if one keeps on posting to closed threads. I've seen things like this work reasonably well on web-based forums, and while it is considerably harder to implement it on a mailing list (and probably impossible to make it entirely correct at that), something reasonably similar that works in most cases shouldn't be terribly hard to implement. People abusing the shortcomings of the solution can still be banned on a case-by-case basis. -- |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/87ehr1xqtp.fsf@algernon.balabit
Re: Licenses not in /usr/share/common-licenses
Michael Gilbert writes: > On Mon, May 7, 2012 at 11:55 AM, Michael Gilbert wrote: >> Would it be unreasonable if someone were to start an >> "uncommon-licenses" package? Then any package depending on that could >> use a reference to the license instead of including the full text in >> debian/copyright. > > I realize that this misses a certain aspect of interpreting the > legalize of licenses, which is that many believe the full text of a > license needs to accompany all source and binary files. > > So then an additional aspect of this solution could be a helper that > takes a copyright.in containing license file references and replaces > that with the appropriate full text. I can add support for something like this to dh-exec, but the usage will be slightly awkward, since executable debian/copyright is not supported, but an executable debian/$package.docs is. So I can write a dh-exec tool that pulls in the right license for you, and all you need to do to use it, is to not have a debian/copyright in the source, but (for example) a debian/copyright.in, and this in your debian/$package.docs: , | #! /usr/bin/dh-exec --with=copyright-magic | debian/copyright.in | copyright-magic | README.md | whatever-else-you want ` Of course the syntax would have to change a bit to make more sense, but I have a bus to catch. It might even be possible to have a debian/copyright and overwrite it via debian/$package.docs, but I haven't verified if that would work. -- |8D -- 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/87havs3qa5.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Patrick Lauer writes: > On 05/08/12 00:04, Marco d'Itri wrote: >> On May 07, Ben Hutchings wrote: >> >>> Means that services can be started (and stopped?) in response to events >>> such as hardware discovery, incoming network connections, the status of >>> other services, and so on. (With dependencies still taken into >>> account.) >> I want to add another major event: the service exiting. >> Being able to reliably monitor and automatically restart a failed >> service is critical. > well, that's another 10 lines of shell worst case. We haven't agreed on > how exactly to handle it and make it configurable and stuff (especially > as tools like monit cover that niche better) That's one of my issues with any init system that does not have this built in: it needs to be written. And if it needs to be written, in shell... > So, whenever a CGroup becomes empty we trigger a script. That script now > can do ... well ... everything. ...things will go terribly wrong, unless you have a strict control of the init scripts. Which you won't, if packages ship their own, without a central authority that tells them what can and what can't be done. While I dislike certain aspects of systemd, and initially disliked that it got rid of my trusty old shell-based initscripts, it is certainly MUCH harder to screw things up when you're given far less power. When the power is in the system itself, not given to individual scripts, that in my opinion, is much safer in the long run. >>> No, enough politeness. We get that you like the way Gentoo does things >>> (lots of options, you get to keep the pieces when they break), but some >>> of us are trying to make Debian better than that. We don't need more >>> half-assed options, we need a solution. >> AOL. >> > Y'all really want to play that game? > > Ok, let me play too. I like games. I thought we were talking about init systems. Don't bring other things into the thread, as that will get even uglier than it already became, and none of us will like it. > But, hey, that's not my fight. I won't stop you from being silly, I just > reserve the right to point and laugh at appropriate times. So do we. We have as much right doing that as you do ;) -- |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/878vh43pdr.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Stephan Seitz writes: > On Mon, May 07, 2012 at 03:30:11PM +0100, Ben Hutchings wrote: >>(lots of options, you get to keep the pieces when they break), but some >>of us are trying to make Debian better than that. We don't need more >>half-assed options, we need a solution. > > Well, it seems we have a problem to define what is „better”. Without > this definition we won’t get the right solution. I prefer several > half-assed options I can choose from instead of having one solution I > don’t like and I can’t change. Then I can use Windows again. FWIW, Debian provides a couple of init systems already, and has been for as long as I can remember. You certainly have the option to choose. It makes no sense to allow choice in the default - that would kind of defeat the purpose of being default, wouldn't it? -- |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/874nrs3pb0.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand writes: > On 05/08/2012 12:53 AM, Gergely Nagy wrote: >> FWIW, Debian provides a couple of init systems already, and has been for >> as long as I can remember. You certainly have the option to choose. >> > Sure, we have the init replacement packages, but nobody > supports them, so you can install upstart or systemd, but > then you wont be able to boot. So I wonder, what point you > are trying to make? I'm perfectly able to boot with systemd for one (some of my systems have been booting with it for the past couple of months fine, thank you very much), and I've booted with file-rc some ten years ago when I had that kind of fancy. That nobody supports them is a tiny bit of an exaggeration. So, my point is: they're packaged, and they do work. If they don't, at least both the systemd maintainer has been very helpful, so was its upstream, and the few issues I had with unit files that didn't come with systemd itself were also fixed by the relevant upstreams or maintainers. I call that very well supported. -- |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/87ipg7deke@luthien.mhp
Re: Licenses not in /usr/share/common-licenses
Joey Hess writes: > Gergely Nagy wrote: >> debian/$package.docs: >> | #! /usr/bin/dh-exec --with=copyright-magic >> | debian/copyright.in | copyright-magic >> | README.md >> | whatever-else-you want > > On the off chance this is not another long-delayed April 1 post, > let me mention that, since this relies on undocumented debhelper > internals (order dh_installdocs does stuff), I will not hesitate > to break it at any time. It only depends on the order if there is a debian/copyright, and .docs is used to override it. If there isn't one, then the order in dh_installdocs does not matter, I believe. I do agree though, that there are far superior ways to accomplish pretty much the same thing. My caffeine level was below a healthy amount yesterday, apologies! In light of that, please disregard my former mail, thanks! -- |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/87zk9j2j5f.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Stefan Fritsch writes: > On Monday 07 May 2012, Gergely Nagy wrote: >> > well, that's another 10 lines of shell worst case. We haven't >> > agreed on how exactly to handle it and make it configurable and >> > stuff (especially as tools like monit cover that niche better) >> >> That's one of my issues with any init system that does not have >> this built in: it needs to be written. And if it needs to be >> written, in shell... >> >> > So, whenever a CGroup becomes empty we trigger a script. That >> > script now can do ... well ... everything. >> >> ...things will go terribly wrong, unless you have a strict control >> of the init scripts. Which you won't, if packages ship their own, >> without a central authority that tells them what can and what >> can't be done. >> >> While I dislike certain aspects of systemd, and initially disliked >> that it got rid of my trusty old shell-based initscripts, it is >> certainly MUCH harder to screw things up when you're given far >> less power. >> >> When the power is in the system itself, not given to individual >> scripts, that in my opinion, is much safer in the long run. > > but sometimes it is necessary to do unusual things in init scripts to > properly intregrate a service into the system. How to deal with that? > Write shell wrappers that are executed from systemd? If absolutely neccessary, that is an option. So is fixing the service to play nice and be easy to start from systemd, which would be much more preferable. Off the top of my head, I can't think of a case where this latter wouldn't be the better option. For unusual, but not-horribly-complicated things, you might be able to get away with ExecStartPre & ExecStartPost and similar. (I abuse these to open a new VT, and attach gdb to the just started daemon - makes for very easy debuggability, and would be a pain in the backside to do in most sysvinit initscripts.) -- |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/87zk9ixtea@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
(Please try to respect M-F-T, and not Cc: me. If I want a CC, I'll set M-F-T appropriately, thanks) Stefan Fritsch writes: > On Tue, 8 May 2012, Gergely Nagy wrote: >>> but sometimes it is necessary to do unusual things in init scripts to >>> properly intregrate a service into the system. How to deal with that? >>> Write shell wrappers that are executed from systemd? >> >> If absolutely neccessary, that is an option. So is fixing the service to >> play nice and be easy to start from systemd, which would be much more >> preferable. Off the top of my head, I can't think of a case where this >> latter wouldn't be the better option. > > Apart from the fact that requirements will be different on different > systems. Putting functionality for all possible corner cases into the > daemon is not sensible for any upstream. That is what configuration files and similar things are for, I believe. I'd love to see an example where a complex init script is needed, and that can't be easily turned into systemd service files (for example). So far, I was told of two cases where the init script does more than a simple unit file does: one was nbd-client, which does funky stuff I dared not try to understand last night, the other is every package that supports starting multiple instances of the same service. The latter isn't hard to convert to systemd, and will even be simpler, as far as I see. > And the integrator/packager may not want to learn all the funny > languages that daemons can be written in (ocaml, haskell, java, ruby, > ...). Besides, init scripts are conf files on Debian for good reasons. So are unit files and configuration files. If the daemon can't be configured and started properly without an init script's help, then something's very broken. Exceptions do exist, of course, but that falls under the 'absolutely necessary' label. I'd love to hear about examples though. If for nothing else, than to try my hands at making them work with systemd, it sounds like an amusing challenge. -- |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/87r4ut21f9.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Philipp Kern writes: > On Wed, May 09, 2012 at 10:39:38AM +0200, Gergely Nagy wrote: >> > And the integrator/packager may not want to learn all the funny >> > languages that daemons can be written in (ocaml, haskell, java, ruby, >> > ...). Besides, init scripts are conf files on Debian for good reasons. >> So are unit files and configuration files. If the daemon can't be >> configured and started properly without an init script's help, then >> something's very broken. > > Technical nit: No, unit files aren't. AIUI a package would ship its > unit file in /lib/systemd/system (i.e. RedHat-style). If you need to > override it, you're of course free to copy it to /etc/systemd/system and > make the necessary adjustments. You will not, however, get a conffile > update prompt when the system file changes (e.g. to update your own > local copy to incorporate the fix). Nothing prevents us from shipping the symlinks in the debian package (which some packages do, like rsyslog). The symlinks can be marked as conffiles (which rsyslog does not do) and then modifications will be preserved. However, this still does not cover the case where the file in /lib changed, but there's not much that can be done about that, at least not easily. On the other hand, a changelog entry about a minor unit file fix should suffice, and it it's a major change, debian/NEWS or something similar can go a long way. -- |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/87ipg5zhp2.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Tollef Fog Heen writes: > ]] Philipp Kern > >> You will not, however, get a conffile update prompt when the system >> file changes (e.g. to update your own local copy to incorporate the >> fix). > > This is something I'm pondering if we should handle in either a systemd > trigger or a tool that packages shipping systemd files can call to tell > the user about any changes. (Basically a wrapper around ucf, probably.) Such a tool would certainly be very useful, but doing it right would be fairly hard, as far as I see. And it would require assistance from at least the package maintainer, to mark in which versions the unit file under /lib changed, so that it can trigger only when appropriate and not on every upgrade. (And there's possibly other corner cases to consider, but they escape me right now..) -- |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/87pqadxy8m.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Sven Joachim writes: > On 2012-05-09 14:01 +0200, Gergely Nagy wrote: > >> Philipp Kern writes: >> >>> On Wed, May 09, 2012 at 10:39:38AM +0200, Gergely Nagy wrote: >>>> > And the integrator/packager may not want to learn all the funny >>>> > languages that daemons can be written in (ocaml, haskell, java, ruby, >>>> > ...). Besides, init scripts are conf files on Debian for good reasons. >>>> So are unit files and configuration files. If the daemon can't be >>>> configured and started properly without an init script's help, then >>>> something's very broken. >>> >>> Technical nit: No, unit files aren't. AIUI a package would ship its >>> unit file in /lib/systemd/system (i.e. RedHat-style). If you need to >>> override it, you're of course free to copy it to /etc/systemd/system and >>> make the necessary adjustments. You will not, however, get a conffile >>> update prompt when the system file changes (e.g. to update your own >>> local copy to incorporate the fix). >> >> Nothing prevents us from shipping the symlinks in the debian package >> (which some packages do, like rsyslog). The symlinks can be marked as >> conffiles (which rsyslog does not do) and then modifications will be >> preserved. > > FWIW, marking symlinks as conffiles is not to be recommended currently, > since dpkg does not handle them the way most people would expect[1,2]. I know. But in case the symlink points to a non-conffile, even with the disadvantages, it's better to mark one as conffile than to overwrite user settings. At least until a tool exists that can handle the situation better, marking these symlinks as conffiles is the best I can think of. The only disadvantage I found so far, is that during upgrades, the user won't be notified, and a .dpkg-new file will be created if the symlink was modified in any way. That does not cause any ill side-effects, I believe, and the biggest issue is that the user is not notified. If the file from /lib was copied and modified, it can be diffed with .dpkg-new. If the symlink was altered, and the target changed too (due to another package upgrading), that's a problem, but nothing would save us from that, except putting the unit files under /etc to begin with. -- |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/87ipg5xwn2.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Uoti Urpala writes: > Roger Leigh wrote: >> Can't we just do things the Debian way, and just provide them directly >> as conffiles in /etc? It's nice that systemd provides its mechanism >> to symlink/include the units provided elsewhere, but is this either >> necessary or desirable on a Debian system? > > Not having the files in /etc by default does have technical advantages. > 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). You can use > ".include /lib/defaultsfile" then override some value, which in most > cases is more maintainable than the 3-way merging required by > "traditional" conffiles. Perhaps then the packages that right now ship symlinks to /lib/systemd/ stuff could be changed to ship a file that consists of a single .include line? That way, they can be treated as normal conffiles without any of the disadvantages of a symlink. diffing and whatnot will magically work, and we'd still have the benefit of having /lib/systemd/ separate from the /etc/systemd/ overrides. This at the cost of some extra processing due to the include. -- |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/87y5p1ryoh@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
Uoti Urpala writes: > Gergely Nagy wrote: >> Uoti Urpala writes: >> > Not having the files in /etc by default does have technical advantages. >> > 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). You can use >> > ".include /lib/defaultsfile" then override some value, which in most >> > cases is more maintainable than the 3-way merging required by >> > "traditional" conffiles. >> >> Perhaps then the packages that right now ship symlinks to /lib/systemd/ >> stuff could be changed to ship a file that consists of a single .include >> line? > > Note that the general case is not just about existing symlinks, but also > cases were /etc contains no file unless you want to override default > configuration, and the program then reads the default from /lib > instead. That is an easy case: the package shouldn't ship neither a symlink, nor any other override. Though, there's one more case where a symlink/override is required: when you're dealing with a package that implements a special service, such as a syslogd: those need to register themselves as syslog.service. >> That way, they can be treated as normal conffiles without any of the >> disadvantages of a symlink. diffing and whatnot will magically work, and >> we'd still have the benefit of having /lib/systemd/ separate from the >> /etc/systemd/ overrides. > > I don't see how this would avoid the need to improve dpkg diffing or add > another tool. It would only highlight the case where the /lib thing moved. Nothing else - but that's still an improvement. And if one uses include & overrides instead of copy & change, then bugfixes made to the original are more likely to get used. Pretty much how a snippet in /etc/default works - the init script including it can change, and you get no notice at all if you didn't change it. You only get notified when the /etc/default/$foo file changes too. For important stuff, there's NEWS.Debian still, and then we don't need any special tool. -- |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/87aa1hdobz@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
Steve McIntyre writes: > Uoti Urpala wrote: >> >>Who's the one choosing his preferred configuration format based on the >>limitations of his preferred packaging system here? Hint: it's not Red >>Hat. > > *yawn* > > When you've got something constructive to add to Debian development, > let us know. Until that point, please go away and stop trolling. There were a few useful lines in the mail you replied to, which, I believe, were constructive: ] Machine-specific configuration belongs in /etc. The default behavior of ] the tools doesn't. ] ] Josh Triplett provided multiple technical reasons why etc-overrides-lib ] is preferable. I happen to agree with the first assertion, for various (highly subjective) reasons, and Josh's reasons[1] are worthy of consideration too. [1]: http://lists.debian.org/debian-devel/2012/05/msg00365.html -- |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/873979dm25@luthien.mhp
Re: etc-overrides-non-etc configuration file model [Re: RFC: OpenRC as Init System for Debian]
Don Armstrong writes: > On Thu, 10 May 2012, Uoti Urpala wrote: >> Don Armstrong wrote: >> > The reason why it is relevant is because [...] >> >> I don't see how the following would make this comparison with rpm >> relevant. > > This is debian-devel, and we're talking about configuration file > handling in Debian, which makes ucf and dpkg relevant. > >> > Having configuration files in /etc and using ucf or similar >> > enables you to deal with this problem easily. >> >> Yes, you do need some tool improvements to be able to alert the user >> about changes. > > Right. So for every package which does this, you have to check to see > whether a configuration file in /etc has had it's corresponding > non-etc configuration file changed, and then offer to merge them > together. 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. We do not handle that case either, and I don't see how the default being outside of /etc would be any different. 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. > So there's basically no advantage to etc-overrides-non-etc unless one > hasn't bothered to implement proper configuration file handling. Then we already have a problem, because the conf.d/ and default stuff suffer from the same problems, and they're used widely all over the place. -- |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/87vck3de3i@luthien.mhp
Re: etc-overrides-non-etc configuration file model [Re: RFC: OpenRC as Init System for Debian]
Don Armstrong 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: RFC: OpenRC as Init System for Debian
Thomas Goirand 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 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 writes: > On Thu, 10 May 2012 21:30:56 +0300, Uoti Urpala > wrote: >> Marco d'Itri wrote: >> > On May 10, Bjørn Mork 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 w
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand 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
Tollef Fog Heen writes: > ]] Gergely Nagy > >> Tollef Fog Heen 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
Stephan Seitz 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
m...@linux.it (Marco d'Itri) writes: > On May 11, Gergely Nagy 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 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/. 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
Steve McIntyre 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 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
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand 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
Thomas Goirand 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
Thomas Goirand 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 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 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
SEEWEB - Marco d'Itri 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 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 writes: > ]] Gergely Nagy > >> Tollef Fog Heen 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
Thomas Goirand writes: > On 05/12/2012 03:29 AM, Gergely Nagy wrote: >> It's not etc-overrides-lib that is the problem. It's defaults changing >> without notice that is. > > Then, let me ask this: > Do you expect that systemd's default in /lib will change often? Nope. > The only thing is that I had no clue what started: nothing were > prompted on my screen. Is there a way to have it more verbose? If you remove 'quiet' from the kernel command line, yes. -- |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/87obpt8y4x@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
Thomas Goirand writes: > On 05/12/2012 03:19 AM, Gergely Nagy wrote: >> It's perfectly able to notice changes >> in /lib/systemd too, or pretty much anywhere else. >> > I thought these were only default which we shouldn't > have to care about?!? :) You don't change defaults, but if you get notified when they do change, that's nice. I personally don't care, because there's only two things I override (syslog.service and media.mount), and I couldn't care less of the default in either case. :P But since there were a lot of "but if it changes I get no notification!!!1!" shoutings going on in here, I figured I'll mention that this solution is suitable for that notification purpose as well. It will notify you of all two cases that'll happen in the next year or two! >:) -- |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/87havl8xy2@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
Josselin Mouette writes: > Le vendredi 11 mai 2012 à 11:25 +0200, Gergely Nagy a écrit : >> Thomas Goirand writes: >> > 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!). > > Utterly wrong. The stuff in /var/lib/gconf is autogenerated, and any > changes you do in it will not be preserved. > The system administrator’s overrides have to be put in /etc/gconf. Please read the "by the above definition" part. I know very well these are not configuration files, the same way /lib/systemd/system/ stuff isn't, either. I'm glad it can be overridden in /etc too, but that wasn't the point. >> Can we fix these first, where not even the overrides are in /etc, let >> alone the defaults? Please? > > Can we get rid of useless babbling on debian-devel? Please? Perhaps if you'd read what I was replying to, you would have noticed what I was attempting to do: show that how silly the configuration file definition quoted before was. >> 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. > > There is a huge difference between gconf, for which you can set one > specific setting in /etc, overriding the default in /usr (and in a way > that will not break the application if the schemas change), and > systemd/udev, which require to copy the *entire* file, leaving behind > any improvements that could made to it in ulterior versions. Not entirely true. You can override parts of the file too, without copying: include the original. This doesn't let you override everything, but for a lot of things, is good enough. For the rest, well, it's a bit of inconvenience, but nothing that can't be fixed with a clever script to warn about the original files changing. -- |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/87y5ow3qs5@luthien.mhp
Re: RFC: OpenRC as Init System for Debian
Josselin Mouette writes: > Le dimanche 13 mai 2012 à 20:00 +0200, Gergely Nagy a écrit : >> > There is a huge difference between gconf, for which you can set one >> > specific setting in /etc, overriding the default in /usr (and in a way >> > that will not break the application if the schemas change), and >> > systemd/udev, which require to copy the *entire* file, leaving behind >> > any improvements that could made to it in ulterior versions. >> >> Not entirely true. You can override parts of the file too, without >> copying: include the original. This doesn't let you override everything, >> but for a lot of things, is good enough. > > And then, when the original file changes, you lose the improvements and > you might even end up with a broken system. > > For example if a systemd unit file is updated to match a change of > behavior in a daemon. Say, from now it requires a pre-exec stanza to do > stuff it used to do at startup. Your modified file in /etc will not > include this new stanza and your daemon is broken. Same problem exists with conf.d/ snippets. It's nothing unique to systemd, nor to etc-overrides-lib. If you can override, include or otherwise configure your system in such a way that you do not get warned when one part changes incompatibly, it will likely break, indeed. That is what NEWS.Debian can be used for, for example. But in systemd's case, there are better options, as discussed in this thread elsewhere (and from what I've been told, with a little bit of postinst magic, this can easily become a non-issue, but I haven't tested that yet). -- |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/87ipfwphgs.fsf@algernon.balabit
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Chris Knadle writes: > On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote: >> On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote: >> > On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote: >> > > No, I hereby start saying good by to 3.0 >> > >> > I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also >> > found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last >> > few packages. >> >> I can't see any reason to use 1.0 anymore, ever. >> >> It is true that 3.0 (quilt) does have a great downside, quilt, but it also >> has a number of upsides. And working around quilt is simple: >> >> echo "single-debian-patch" >debian/source/options >> echo "/.pc" >>.gitignore >> echo "/debian/patches" >>.gitignore > > I'm confused concerning the above; the point of a VCS in this context is to > track changes to the source package, and the patches are themselves important > changes to the source package. If you have Git ignore the patches then Git > doesn't have a complete view of the source package anymore. Why would you > want to do that? Git does have a complete view. What the above does, is tell dpkg-source to fold any changes made to the upstream sources into a single patch. Since the git tree already has the patches applied (with upstream sources on a different branch, most probably), it has a full view. This basically folds whatever patches the git tree has over upstream, outside of debian/ into a single file. That's about it. Since that file is generated, it has no business staying in git. >> Except for nuking upstream debian/ dir which can mean a bit of lost work if >> the upstream is sane (and can save some if they're not), the 3.0 format is >> strictly better than 1.0. > > If debian/ is nuked then so is debian/patches, and if Git has been told to > ignore debian/patches then it cannot bring those files back. You're misreading this. "Nuking upstream debian/" means ignoring any debian/ directory upstream may have had. That is generally a Good Thing(tm), as we want to have our own packaging. The original is still available in both the upstream tarball, and the upstream branch. debian/patches in this case is irrelevant, as that is automatically generated by diffing the upstream tree against the current (git) tree and folding it into a single patch file. > Patching the source can be an effort especially concerning documenting > why the patches were done and the source of the patches, so these seem > like they'd be important to track rather than something to ignore. The reasons can - and should be - documented in git. Granted, that does not transfer to the debianized source package, which is unfortunate, but it's still better than fighting with integrating quilt with a VCS (in which case, everyone with a higher number of patches would go back to 1.0 and custom patching systems and ignore every other benefit of 3.0, because quilt and VCS generally don't play nice together). -- |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/871umioo6l.fsf@algernon.balabit
Re: What to do with bug reports against non-existing/removed packages
"Daniel Leidert" writes: > Hi, > > Our bug tracker contains items for packages, which do (not longer) > exist. What should happen to them? I see, that it might be a good idea > to keep them for the case, a package is re-introduced. But this might > happen only for a few packages. Most of them got removed because newer > versions were released. What about closing those reports, if an > RM-request is filed? This is a hard task, as there's no simple set of rules that would apply to all bugs. Some were filed against packages that existed at a time, but got removed without the bug being closed (this often happens when the source remains, it just stops building a particular binary package). In this case, the bug should be examined, and either reassigned if it still applies, or closed (preferably with a version) if it does not. Then there are the case of misfiled bugs: bugs filed against packages that never existed, but were installed from a third party repository (these should be closed with an appropriate message, urging the submitter to either contact the third party repo's maintainer, or upstream, whichever is more applicable); typos in package names, where a reapply would be best; bugs against packages not yet in the archive (but either in NEW, or in the archive, but so fresh its not known to the BTS yet): these should be left alone most of the time, but in certain cases, it might be a good idea to contact the maintainer, so he'll know about these reports, as the BTS will not notify him when the package enters the archive. If he doesn't check the BTS page, but relies on email, he won't know about the reports. There are probably a few other corner cases, but as you can see, it's not simple. That's why the list is so long still. On and off, a few people (myself included) try to shorten a bit, and so far, it seems we can handle the newly misfiled bugs. Any help with getting the backlog down to a much smaller number would be greatly appreciated. Updating the wiki[1] with guidelines and HOWTOs on how to handle specific cases would also be desirable, and I'm happy to help with either. [1]: http://wiki.debian.org/Teams/unknown-package/TODO -- |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/87mx55n5ho.fsf@algernon.balabit
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Thomas Goirand writes: > By the way, do other think that, even in this case, I should keep the > changes > as minimum as possible? Or is it ok, considering that all of our > toolsets have > changed since the last upload (eg: we now have pkg-php-tools and dh 8 > sequencer), that we do a bit more changes in the package than just the new > upstream release? Since the package has been unmaintained for years, and from what I've read so far, it does seem that it will end up under a team's umbrella anyway in a month's time, I wouldn't care about any possibly hurt feelings, and update the packaging to current practice. Quality and maintainability should come before the letter of any NMU recommendations and best practices. -- |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/878vg9eopq.fsf@algernon.balabit
Re: Planned changes to Debian Maintainer uploads
Bernd Zeimetz writes: > Which bad things happened that we have to change the current process? As far as I see, it's more about "what good things didn't happen" why we have to change the process. That is also addresses a few corner cases that could've gone bad, but never did is a side-effect. -- |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/87y5nssmbn.fsf@algernon.balabit
Re: Maintainers, teams, Uploaders, DMs, DDs, etc.
Ian Jackson writes: > So for example, DDs have enormous theoretical power but there are > strong and well documented social controls on how they should exercise > that. I think as a matter of principle that the same principle should > apply to DMs: it is easy to remove a misbehaving DM from Uploaders. For some values of easy. It requires a sourceful upload for possibly no other reason than to remove an uploader. That's a waste of time, not only for the maintainers, but the buildds and archive software too. Would the package take long to compile, it would be even worse. We can't compare this to the case of DD's, because DD upload rights are only governed by social customs and the keyring, the DMs have *additional* restrictions, which currently are tied to the source package. > So it is not necessary to have technical measures that prevent a DM > mentioned in Uploaders from violating the package's uploading rules, > bypassing review processes, or whatever. Instead, when a package team > or lead maintainer accepts someone into Uploaders we should clearly > communicate to the new uploader what is expected of them, and then we > should trust them to do as we have asked. Well, one of the reasons DMs are not DDs, is because they do not have the same rights as DDs do: they can't, and in my opinion, shouldn't be able to upload pretty much any package without further restrictions. If they would, they'd technically have the same upload rights as DDs do, with a fraction of the experience, and without going through NM. I don't think that would be wise. (No disprespect meant for DMs, mind you) However, this (whether we need the extra upload restrictions for DMs), I believe is not strictly related to the proposal, which, to my reading, was more about moving the DM-Allowed field out of the source package, and a few other things. > The questions that need to be answered for a package are: [..] > * Who makes final decisions about the package; this includes >arbitraring disputes, delegating authority, revoking such >delegation, etc. [...] >I'm going to call these people the maintainers of the package. >They might be DDs, DMs, or contributors without a key in the >keyring. > >Currently this information is sometimes in the Maintainer field; >sometimes in both the Uploaders and Maintainers fields; and >sometimes somewhere else completely (eg a team wiki page). > >Normally the maintainers would be the people who are doing most of >the work. Sometimes we have provisional maintainers who are >neither DD or DM; in those cases the maintainer works under the >supervision of their sponsors. So far, I agree. > c. Who is entitled to prepare a non-NMU upload of the package. > >This information needs to be accessible to the project as a whole. > >Particularly a potential drive-by sponsor needs to know whether the >upload they are sponsoring is by someone entitled to prepare such >an upload. And the archive software needs to know whether to >permit an upload. > >Currently this information is sometimes in the Maintainer field; >sometimes in both the Uploaders and Maintainers fields; and >sometimes somewhere else completely (eg a team wiki page). There's also the case of DM-Allowed: yes. If someone is listed as maintainer, but is not a DD, then my understanding is, that he is not entitled to upload. (Hence, should not be in Uploaders, either, unless DM-Allowed: yes is set) This looks silly, though, and inconsistent, and very easy to miss when sponsoring or working within a larger team. Nevertheless, in case the maintainer is not a DD, he either needs a sponsor, or must be a DM, with the package having DM-Allowed: yes. This also presents a problem when adopting packages, because if the adopter is a DM, someone must sponsor his first upload or set DM-Allowed: yes otherwise in a separate upload - neither of which is particularly friendly towards the DM (nor anyone else, really). Would this restriction get untied from the source, the former maintainer could grant upload rights without having to do a sourceful upload, and everyone wins, and no rights get harmed either. > e. What process should someone preparing a non-NMU upload follow? > >Eg, is there a VCS that everything should be committed to ? Are >non-emergency uploads supposed to be reviewed somewhere ? Are some >of the people who are entitled to upload supposed only to do so >after explicit indication by someone more senior that they should >do so ? > >Again this information doesn't generally need to be available to >people outside the packaging team. However, if there are >significant and important processes that should be followed, a >drive-by sponsor should be able to find them easily so that they >can double-check that the person preparing the upload (the sponsee) >seems to be doing the right thing. > >Currently this information is, if
Re: [RFC] Add upstream VCS info to control file
Gregor Jasny writes: > When one tries to fix a FTBFS bug a look into the upstream VCS is > often helpful. Sometimes a link to browse them is easily found on the > homepage linked from the PTS page. But often these links are deeply > buried in the linked website. > > What I'd like to see in the Debian control file are Vcs-Upstream > fields that work like their Vcs- pendents but point to the upstream > sources. These URLs would also be linked in the PTS. > > Does this sound reasonable? I'd rather put it in debian/README.source, I see no need of shoveling yet more fields into debian/control. (Yeah, yeah, having it there would make it possible to do debheckout --upstream or similar, but.. that would be rarely needed enough to use README.source instead). -- |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/87lijqowly.fsf@algernon.balabit
Re: [RFC] Add upstream VCS info to control file
Thomas Goirand writes: > On 06/15/2012 12:03 AM, Cyril Brulebois wrote: >> Anyway, here's what I've been doing for our 150+ X packages: >> >> $ cat xserver-xorg-video-ati.git/debian/watch >> #git=git://anongit.freedesktop.org/xorg/driver/xf86-video-ati >> version=3 >> http://xorg.freedesktop.org/releases/individual/driver/ >> xf86-video-ati-(.*)\.tar\.gz >> >> debcheckout gives you a debian-unstable branch by default. Then calling >> the tiny xsf-remote-add-upstream script gets the watch file parsed, and >> the upstream branch added: >> >> http://anonscm.debian.org/gitweb/?p=pkg-xorg/debian/xsf-tools.git;a=blob;f=xsf-remote-add-upstream >> > > That's really cool, but what would be even cooler would be something > standardized in Debian, so that we all do the same way. Probably > having your something like your xfs-remote-add-upstream script, but > built in debcheckout, git-buildpackage or something like that. > > Now that you tell about it, I agree that adding yet another field in > debian/control was short sighted. While having a standardized way would be useful, there's just so many workflows, that you can't possibly cover all of them with a single syntax, and in the end, you'd end up with having to call package-specific scripts in the source. We already have Vcs-*, to check out the debian branch. If debian/rules would have an optional target, similar to get-orig-source, that would finish checking out the repository, grabbing upstream stuff, and setting up branches too, that would solve your problem. debcheckout could be extended to check whether the target exists, and call it too, so in the end, you'd end up with using a single command, that gets you what you want. And we didn't attempt to cover every different case with a single syntax in debian/control, or another file. Call this target get-vcs-source or similar, and voila! -- |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/87boklrun1@luthien.mhp
Re: [RFC] Add upstream VCS info to control file
Ansgar Burchardt writes: > On 06/15/2012 11:33 AM, Thomas Goirand wrote: >> Yeah, a hook of any sorts is ok for me. The get-vcs-source in debian/rules >> seems quite ok to me. Should debcheckout be modified to call it? It's part >> of devscript, do you think it's ok if I submit a wishlist bug report against >> devscript to ask for such feature? > > No, running code from a repository during checkout is a bad idea. As you mentioned on IRC: cover the common cases with something machine-readable, and make it able to point people to d/rules get-vcs-source if it detects that extra work needs to be done? (This could be as easy as a flag in said machine-readable place) This way we get the best of both worlds. -- |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/87vcisrhfy@luthien.mhp
Re: Clarification on the Origin: field in the Patch Tagging Guidelines?
"Theodore Ts'o" writes: > P.S. One of the things I'm thinking about doing is writing a script which > automatically generates the debian/patches directory from the git > repository. So when I specify the base release (i.e., v1.42.4), it will > do something like git format-patch, but in a debian/patches Quilt 3.0 > format. That way I don't have to replicate the patches twice in my git > tree (once as the real commit, and once in the commits which create the > debian/patches/* files). FYI, gitpkg can do that, among other things, git-buildpackage's gbp-pq can do something similar aswell. So the script you wish for already exists, and is packaged. ;) -- |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/87pq90r8m2@luthien.mhp
Re: Recommends for metapackages
"Eugene V. Lyubimkin" writes: > On 2012-07-10 15:32, Josselin Mouette wrote: >> Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit : >> > What's wrong with Recommends: in that case? It seems to perfectly >> > match the "makes life easier for > > XXX>" scenario you describe. >> >> Recommends is wrong for metapackages because it gets upgrades very >> wrong. This is why it is used very marginally. > > Standards should not depend on implementation details. I see zero > reasons why metapackages are (or should be) specific here. Whatever $it > that gets upgrades wrong should be fixed instead. But the purpose of the meta-package is to pull stuff in. Depends does that, Recommends does not, therefore Recommends is not appropriate for the task. For the cases where one wants to have most of the stuff installed that the meta-package would pull in, but not all, solutions already exist. And like Josselin said in the same mail, there is a large overlap between those who want to push some of the stuff in Depends to Recommends, and those who can just make their own local meta-package within 5 minutes and be done with it. -- |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/87obnnzoly.fsf@algernon.balabit
Re: Recommends for metapackages
"Eugene V. Lyubimkin" writes:
> On 2012-07-10 16:18, Gergely Nagy wrote:
>> But the purpose of the meta-package is to pull stuff in. Depends does
>> that, Recommends does not, therefore Recommends is not appropriate for
>> the task.
>
> Surely Recommends does pull stuff in.
No. Only if installing recommends is turned on, which cannot be
guaranteed.
> It's clearly reflected in Debian policy
No, it is not.
"Recommends
This declares a strong, but not absolute, dependency.
The Recommends field should list packages that would be found together
with this one in all but unusual installations."
Nowhere does that say that whatever is in recommends, will be
installed. Therefore, tools will *not* pull those in, unless they are
asked to.
> and supported by most if not all high-level packages managers in
> Debian.
Yes, apt and aptitude supports Apt::Install-Recommends, and it is
enabled by default. But it can - and often is - turned off.
> Therefore it's totally appropriate for the task.
It is not, because the purpose of the meta package is to get things
installed *always*. If it would be an optional collection of stuff, it
wouldn't be a meta package.
But, to cut the story short, attached to this mail is a script you can
use to take any metapackage, and remove (or demote) any of its
dependencies. It echoes a control-file thingy, combining it with equivs
is left as an excercise to the reader.
Usage:
$ ./meta-gen.sh gnome-core network-manager-gnome
Build a local package out of that, use happily ever after. Our
meta-packages can continue depending on what upstream considers part of
a package suite, and those of you who want to have most, but not all of
it, can use the script to create a local meta package. Since it's
scripted, you can even keep the local thing reasonably up to date.
It took about ~5 minutes to write that script, would take another 10 or
so to make it build a local package too. I'm fairly sure this could be
hooked into apt via a Apt::Update::Post-Invoke: once apt-get update ran,
update the local meta packages, push it to a local repo, touch a stamp
file, and update again. But perhaps there's even a way to make this play
nicer, I didn't care that much.
Crude, but should work, with about ~20 minutes of total time spent on
it. Much less than pointless arguing on a list about something that's so
very easy to solve in a way that everyone wins.
--
|8]
#! /bin/sh
set -e
pkg="$1"
shift
dropdeps=",$(echo $@ | sed -e 's# #,#g'),"
if [ -z "${pkg}" ]; then
cat <
Re: Recommends for metapackages
"Eugene V. Lyubimkin" writes: > On 2012-07-10 18:10, Jonas Smedegaard wrote: >> The very purpose of a meta-package is to _ensure_ that a certain set of >> packages is installed, not just recommend them: All (not only most) >> users of that package need all its dependencies satisfied > > My definition of meta-package is less strict than yours. I as user > sometimes want '[meta]package X, but without packages Y and Z', and your > definition absolutely rules that out. That's not a meta package then. That's a collection of loosely coupled stuff, and by that definition, a meta package should not use depends at all, but always recommends, because someone may want to use metapackage X, but without A, B and C. Might aswell get rid of them then. > I saw many questions on forums like > > "I did '$packagemanager install $metapackage' and then after > '$packagemanager remove $singlepackage', why $packagemanager now wants > to remove all $metapackage?" > > , so I know I'm not alone. Using Recommends for non-core parts of > metapackages' dependencies would nicely solve that. Well, in case of GNOME, upstream considers n-m to be part of the core system, to the best of my knowledge. If upstream does so, so should we. Besides, the solution is very easy: don't want all the deps of the meta? Don't install it. If you still want to pull most in, but exclude some, see the script I posted earlier. It can easily be changed to echo an apt-get line instead of a modified control file, if that's more suitable. -- |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/874npfzi3e.fsf@algernon.balabit
Re: Recommends for metapackages
Sune Vuorela writes: > On 2012-07-10, Gergely Nagy wrote: >> No. Only if installing recommends is turned on, which cannot be >> guaranteed. > > There is many ways to break your system. turning off installation of > recommends is one of them. During the past ~14 years I've been using Debian with that setting turned off, nothing ever broke on my systems because of this setting. If it does, then I'll consider that a bug and report it appropriately. -- |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/87wr2by3c8.fsf@algernon.balabit
Re: Recommends for metapackages
Nikolaus Rath writes: > Gergely Nagy writes: >> But, to cut the story short, attached to this mail is a script you can >> use to take any metapackage, and remove (or demote) any of its >> dependencies. It echoes a control-file thingy, combining it with equivs >> is left as an excercise to the reader. > > If I'm not mistaken, that means that the demoted dependency will get > pulled in again on the next upgrade of the metapackage, or that I have > to put the metapackage on hold and will loose any demotions and > promotions of other packages in future metapackage versions. No, you name the local meta package differently. No need to put it on hold or anything. If you want to follow the original meta, set things up so that the local gets updated once in a while. That's doable with an Apt::Update::Post-Invoke hook, as I believe I said in the mail above. -- |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/87pq834dva@luthien.mhp
Re: Recommends for metapackages
Nikolaus Rath writes: > Gergely Nagy writes: >> For the cases where one wants to have most of the stuff installed that >> the meta-package would pull in, but not all, solutions already exist. > > What solutions do you mean? Installing the pieces one wants by hand, for one. Automating that with a custom meta-package as another, using my script for the automation as a third. Using equivs to create a dummy stub for the unwanted packages (eg, n-m) and using the meta package as-is as a fourth. There are probably other, similarly straightforward options, but four's enough for a start. -- |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/87liir4dsk@luthien.mhp
Re: Recommends for metapackages
"Eugene V. Lyubimkin" writes: > Moreover, despite me understanding the picture, I still > has no clean, safe and documented way to do what I'd want in case the > package maintainer chosed Depends. You have: install the pieces you want by hand. That's at least clean and safe. I do not think it is worth documenting explicitly. >> > Using Recommends for non-core parts of >> > metapackages' dependencies would nicely solve that. >> >> ...but I disagree that making meta-packages more elastic is a "nice" >> solution: is a hack covering over misguided users. Possible solutions >> could be improved documentation and improved design of package managers. > > ... And I disagree with that. No solution can override policy's "all > Depends must be satisfied". If one choose to support the "exclude from > metapackage" one either has to change the policy, remove packages from > Depends or use non-stock metapackage (which I personally don't like). Changing the policy would be stupid. Demoting to Recommends would be less so, but if upstream considers a package a core part of a platform, recommends *is* wrong. If you disagree with upstream, you have the tools and the ability to customize your system: use a non-stock meta package. It's not hard. I'd be very curious why you're so against it, perhaps we can come up with a solution that satisfies you? -- |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/874npexyso.fsf@algernon.balabit
Re: Recommends for metapackages
Henrique de Moraes Holschuh writes: > IMO, metapackages should "depend" on the absolutely required stuff (and many > times that will be the empty set), "recommend" the rest, and maybe even > "suggest" fringe packages. This achieves maximum usability for more > usecases, and malfunctions only in the unsupported case of "no install > recommends by default" -- you should skip recommends always in a > case-by-case basis. That also achives maximum annoyance, because if I want the full platform, I'll have to go recommends/suggest hunting. (No, I'm *not* going to turn on install-recommends.) > OTOH, metapackages from hell (like gnome or kde-full) based on Depends > require me to select them, go to the "will install these" screen, deselect > the meta package, and go over the list manually installing whatever isn't > going to be useless/unwelcome for my specific case. And I will never notice > if the metapackage changes its dependency tree later on. You could script all that, and keep your local list up-to-date with about ~10 minutes of work. -- |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/87zk76wk3o.fsf@algernon.balabit
Re: Recommends for metapackages
Andrei POPESCU writes: > On Ma, 10 iul 12, 18:43:03, Gergely Nagy wrote: >> >> During the past ~14 years I've been using Debian with that setting >> turned off, nothing ever broke on my systems because of this setting. If >> it does, then I'll consider that a bug and report it appropriately. > > Depending on how you do the package selection on your next installation > you might end up with rsyslog, but without logrotate[1]. I don't see how that would break anything. logrotate is not necessary for log rotation, not with the syslog daemon of my choice at least. And as you said yourself, log rotation isn't mandatory 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/87vchuwju9.fsf@algernon.balabit
