Re: Providing a non-free alternative to a free package
debian-de...@liska.ath.cx (Olе Streicher) writes: > There is another version of this library available, where the (C) > sources are available (and put under GPL), but obfuscated, so that they > cannot go into "main" but would have to go into "non-free". However, I > am thinking about packaging this version as well. If it is obfuscated, then it is most probably not the preferred form of modification (and not the real source, but something derived from that), thus, them being GPL'd is invalid, and it's not even fit for non-free, as far as I see. I mean, if I write a program in C, and distribute the x86 assembly generated by gcc, and try to sell that as GPL (without providing access to the original C source), that's essentially the same thing, and won't work. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762fhaa6h.fsf@algernon.balabit
Re: Providing a non-free alternative to a free package
debian-de...@liska.ath.cx (Olе Streicher) writes: > Björn Esser writes: >> So I'd suggest name the free one slalib and the other one >> slalib-nonfree or vice versa (like the unrar example). > > The problem is that I want the dependent programs to be linked against > any of them. > > For example "saods9" would use slalib as a shared library, and I want to > git the user a choide to run it either with the free, or with the > non-free version. Are the two libraries actually ABI compatible? Somehow I doubt that, but I might just be too sceptic when it comes to non-free software. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjil8upl.fsf@algernon.balabit
Re: Providing a non-free alternative to a free package
debian-de...@liska.ath.cx (Olе Streicher) writes: > Gergely Nagy writes: >> debian-de...@liska.ath.cx (Olе Streicher) writes: >>> For example "saods9" would use slalib as a shared library, and I want to >>> git the user a choide to run it either with the free, or with the >>> non-free version. > >> Are the two libraries actually ABI compatible? Somehow I doubt that, but >> I might just be too sceptic when it comes to non-free software. > > They come from the same author, so I would assume (and test :-) ) that > they are compatible. Aha, I see. In this case... well, I don't think there's a solution that's entirely satisfactory. The closest thing I can think of, is that one is called libfooN, while the other libfooN-nonfree, they conflict & replace each other, and both provide the same filenames. So far, it's easy. The hard part is making sure that dpkg-shlibdeps does the right thing, and produces dependencies like libfooN (>= blah) | libfooN-nonfree (>= blah). I'll leave this part as an excercise for the reader. >;) -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87liod8pey.fsf@algernon.balabit
Re: how to manage d/changelog for updated but not yet sponsored package
Jakub Wilk writes:
> * Ben Finney , 2012-02-13, 13:40:
>>> I want to keep trace of it in the d/changelog by keeping my first
>>> version entry and adding a second entry. Can I do that ? Will it
>>> confuse some Debian robots ?
>>
>> It's fine. I consider uploading the package to ‘mentors.debian.net’
>> a release of the package, since at that point interested people
>> (e.g. reviewers) can rely on it, and the version should refer
>> uniquely to what I uploaded at that time.
>>
>> Be aware, though, that some people disagree (on the grounds that
>> it's not a new version until it enters Debian).
>
> I believe that vast majority of sponsors disagree.
Personally, I like the middleground best (though, I haven't been
practicsing this yet, but this is how things would work in my ideal
world): upload to mentors.d.n with incremental versions (when it makes
sense; if the reviewer/potential sponsor spots a bug in a version not
announced, that version is safe to resue as far as I'm concerned), but
fold it into one entry when uploading to Debian proper.
${VERSION}-${N}~mentors${X} for mentors, ${VERSION}-${N} for Debian
proper. A little more work on both sides, but we get the best of both
worlds with as little of the worst as possible.
--
|8]
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sjifgcao.fsf@algernon.balabit
Re: how to manage d/changelog for updated but not yet sponsored package
Boris Pek writes:
> Hi,
>
>> Personally, I like the middleground best (though, I haven't been
>> practicsing this yet, but this is how things would work in my ideal
>> world): upload to mentors.d.n with incremental versions (when it makes
>> sense; if the reviewer/potential sponsor spots a bug in a version not
>> announced, that version is safe to resue as far as I'm concerned), but
>> fold it into one entry when uploading to Debian proper.
>>
>> ${VERSION}-${N}~mentors${X} for mentors, ${VERSION}-${N} for Debian
>> proper. A little more work on both sides, but we get the best of both
>> worlds with as little of the worst as possible.
>
> VCS repo is very helpful in this case. It eliminates the need to increment
> the version of the package. And change log will show real history of package
> versions in Debian archive.
Depends on the situation. If it's a quick update, and I can followup
within moments, then indeed, there is no reason to increment the version
(see my "when it makes sense" comment above).
But if hours, or even days can pass between iterations, then I much
prefer a new version on mentors. That also has the advantage of me not
neccessarily being a bottle neck, and another sponsor can review it and
perhaps sponsor it too.
--
|8]
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87obt2hpyz.fsf@algernon.balabit
Re: how to manage d/changelog for updated but not yet sponsored package
Boris Pek writes: >> Depends on the situation. If it's a quick update, and I can followup >> within moments, then indeed, there is no reason to increment the version >> (see my "when it makes sense" comment above). >> >> But if hours, or even days can pass between iterations, then I much >> prefer a new version on mentors. That also has the advantage of me not >> neccessarily being a bottle neck, and another sponsor can review it and >> perhaps sponsor it too. > > Hmm, another sponsor also could look at commits in VSC to observe changes > since > last message. Isn't it? Yeah, if they're willing to do that. Personally, I'd rather use mentors.d.n, than a random $VCS repo (even if that repo is under .d.o), because I'm not interested in installing a new VCS, figuring out where the repo is (ok, its in the mail, and in the VCS-* fields, but it's easier to paste a package name than a repo URI, and if I have access to the VCS-* fields, then I have the sources anyway). I'll look at VCS repos if and when I'm already reviewing a package, and am in contact with the maintainer. But if I'm looking at something new, that I haven't looked at before, I find mentors.d.n more convenient, and I won't check it's VCS repo (if any). -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aa4mhlt1.fsf@algernon.balabit
Re: how to manage d/changelog for updated but not yet sponsored package
Nicolas Dandrimont writes:
> Le 13/02/2012 à 13:14, Gergely Nagy écrivit :
>>
>> ${VERSION}-${N}~mentors${X} for mentors, ${VERSION}-${N} for Debian
>> proper. A little more work on both sides, but we get the best of both
>> worlds with as little of the worst as possible.
>
> Hi,
>
> This scheme is something I was thinking about doing automatically for
> mentors (i.e. upload ${VERSION}-${N}, but get back
> ${VERSION}-${N}~mentors${X}).
>
> This would avoid the current clobbering of files from one upload to the
> other, and would allow us to present diffs between subsequent uploads of
> the packages.
I don't think that's a good idea. My wish with the ~mentors${X} would be
that it's used intentionally, when the maintainer changes something, and
uploads a new version, that gets a new changelog entry.
You can't automate this reliably.
To illustrate, here's a changelog snippet meant for mentors:
my-little-pony (1.0-1~mentors2) unstable; urgency=low
* Use debhelper (>= 9) to gain hardened build flags for free.
-- Pony Herder Tue, 07 Feb 2012 10:00:00 +0100
my-little-pony (1.0-1~mentors1) unstable; urgency=low
* Initial upload (Closes: #PONIES)
-- Pony Herder Mon, 06 Feb 2012 14:00:00 +0100
This makes it clear what changed between ~mentors1 and ~mentors2. But
~mentors2 is fairly pointless when uploading to Debian, so this would
get flattened into:
my-little-pony (1.0-1) unstable; urgency=low
* Initial upload (Closes: #PONIES)
-- Pony Herder Tue, 07 Feb 2012 10:00:00 +0100
If you'd automatically turn 1.0-1 into 1.0-1~mentors${X}, you'd have to
do some changelog diffing and altering. That's not going to work.
Plus, it would also prevent the sponsors from building & uploading the
maintainer prepared package without modifications. As a sponsor, I don't
want to modify packages I upload, I will review them, suggest or request
modifications, and let the maintainer do it, update my sources, and work
from there. Automatically munging the version would make this
impossible, or at least very inconvenient.
--
|8]
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762fahlec.fsf@algernon.balabit
Re: Files permission in the debian directory
fre...@free.fr writes: > What I especially like to know if this should be group-writable, but > maybe it's not important. They should not be. There is no reason to use anything but 644/755, respectively. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aa4mg086.fsf@algernon.balabit
Re: Files permission in the debian directory
Arno Töll writes: > Except debehelper in compatibility mode 9. There, debhelper > configuration files can be scripts (as you know), which are determined > by the +x bit. That's covered by 755. But executable dh files are not for the faint of heart, nor for beginners who need to ask these questions, so I intentionally didn't mention them. -- O8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fweeb9n1@luthien.mhp
Re: debian/rules default
Jerome BENOIT writes: > Hello List: > > What should be the default target for debian/rules ? I usually make a help target (or something similar) and make that the default. But now that you reminded me, I always wanted to make it display debian/README.source, so I'll just do that for my packages. Thanks for the reminder! :) -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkc41w2x.fsf@algernon.balabit
Re: build server at home?
Dmitry Smirnov writes: > Could any of you share experience of having your own private build server? > > I'm thinking of something which could build uploaded source for as many > architectures as possible on amd64 host, and ideally put the results to > 'reprepro'-managed tree. > > The goal is to simplify package deployment to internal infrastructure for > evaluation before upload to debian. > > Any hints for quick start please? I have a custom system that does something like this, it's pretty simple, and I'm working on automating even more of it. What I do, is that I have a couple of sbuild chroots (LVM snapshot thingies), with which I can build amd64 and i386 packages easily. I also build packages for a certain derivative distro, not only for Debian, so whenever I have a package to build, I run a script that does something like this: for arch in amd64 i386; do for dist in unstable squeeze lucid natty oneiric precise; do sbuild --arch $arch -d $dist --apend-to-version="~$dist" \ -m "MadHouse Project Autobuilder " \ $1 done done Then I collect the results and let reprepro do the rest. There are a few gotchas there, too, because in my case, I have an arch:all package that should be the same on all platforms, so I manually use reprepro's includedeb to add it everywhere. Same goes for the source. I used to have a few virtual machines, which I booted up from the same build script, ran a build in there, and shut them down, but turned out that there were no users for my arm and kfreebsd-* packages, so I stopped doing that. One of these days, I'll turn this setup into a buildbot setup or something similar. (Or even learn how buildd & wanna-build work, along with dak, which I need to learn anyway) -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vcms1vn9.fsf@algernon.balabit
Re: sponsorship-requests mails should not go to debian-mentors
Samuel Bronson writes: > It's getting to the point where I think it would be best if we do one > of two things: > > 1. Split out sponsorship-requests bug mail to a new mailing list. > > 2. Stop sending it anywhere, and let people subscribe through the PTS > if they care. > > How about you? I'd go with option two (but 1 is also acceptable), but the noise ration on -mentors is getting in the way indeed. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4x5ibke@luthien.mhp
Re: A "Review & Mentor" team
Thomas Goirand writes: > On 03/13/2012 06:18 PM, Gergely Nagy wrote: >> I would also love to see a "Review & Mentor" team, something that could >> work along and with the NM process, whose task would be to do just what >> the name suggests: reivew packages, help find a sponsor > > Oh, *that* is very interesting. And that gives me another idea. [...] > Now, what I'd be very glad to have would be that Debexpo knows about > tags, and that someone needing sponsoring would tag his package once > it's uploaded to Debexpo. This is something, I believe, that would be covered by the DebExpo GSoC project[1], which I referred to in my mail to -vote, too. ;) [1]: http://wiki.debian.org/SummerOfCode2012/Projects#Semantic_Package_Review_Interface_for_mentors.debian.net > A sponsor would, on his side, select what type of tags he is interested > in. For me for example, I'd be selecting server type of software, so I'd > for example select system::server. Then I would receive on my mail all > request for sponsoring server related RFS only, saving me the loss of > time browsing -mentors which is flooded with X-Window / GUI software > that I care less about. One thing we could do right now, is to usertag RFS bugs. While that's not as nice and easy as receiving only the tags you would subscribe to, but checking the "system::server" usertagged RFS bugs once in a while should be an improvement, I think. > Having all this would mean that the following change occurs: > 1/ Debexpo would allow sponsoree to edit tags on their software > 2/ Debexpo would allow sponsors to register for tags they are interested > in, and send RFS depending on matches with 1/ Since we're using the BTS fro RFS, we can already (user)tag things. What still needs to be improved is the way this information is delivered to sponsors. In the short term, it wouldn't be too hard to write a little script that polls the usertags of, say, debian-mentors@l.d.o, and mails the news to the appropriate people. If this script lived on a .d.o machine, sponsors could add their name and the tags they're interested in to a simple file, and done. It's certainly not the most modern solution, but until there's better, this could do. Then we only need to teach reportbug (or sponsorees) to usertag their RFS submissions well. If there's enough interest, I can throw this together in a couple of hours, I think. (Damn, I already have half of it written in my head, as I was writing this mail.. damn subconcious!) -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkbffpm2@luthien.mhp
Re: Elegant Debhelper way to specify files between runtime and debug library packages
Ben Finney writes: > What is the recommended way to specify packaging for a library package > and its corresponding debug symbols package? I use the following line at the top of my debian/rules: export DH_OPTIONS += --dbg-package=foo-dbg This appears to do the right thing with dh compat level >= 8, havent tested with earlier, but should work there too. Though, the few places I use this, are pure C libraries, which are, I assume, a bit different from what you're doing. > With a previous Debhelper (7.x), I could specify it with ‘debian/rules’ > in the ‘install’ and ‘override_dh_auto_install’ target: > > install: build > dh $@ > > override_dh_strip: > dh_strip --dbg-package=foo-dbg > > With the current Debhelper (in version 8 mode), that fails to put the > files in the right place AFAICT. I am now resorting to this less-elegant > solution: > > install: build > dh $@ --package=foo --exclude "*_d.so" > dh $@ --package=foo-dbg > > override_dh_strip: > dh_strip --dbg-package=foo-dbg Are you sure dh7 excluded _d.so? I failed to find anything in debhelper's git history that did that. > That's a step backward, because if I need more packages, the ‘install’ > rule starts to grow more special cases, defeating some of the > auto-detect features of Debhelper. You could do something like: install: build dh $@ --package=foo-dbg dh $@ --exclude "*_d.so" debhelper should know that it did install foo-dbg already, so in the second case, it won't install that again. (AFAIK, haven't tested, so I might be wrong here). -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87398vzs12.fsf@algernon.balabit
Re: Advice on use of patch system while hacking
Ross Boylan writes: > Short version: > > What's the best way to work with a dpatch-based package developing code > that will likely take many smallish iterations to get right? As the other reply said: the best way is not to. The long version of the same answer: dpatch is not a VCS, was never meant to be. The best way to work with it, is to ignore it until you really can't ignore it anymore. Which, in this case, probably means running debian/rules build over and over again, until you have something that works. I wouldn't bother building a package, just the binaries (assuming it has a sane build system, where, if you modify a file, it will rebuild it correctly), and either run the thing from the build tree if that is supported, or copy them to the appropriate place by hand. Or, as you considered below, even edit the installed file, if that's more convenient. > My patches also edit debian/changelog; I think that is an error and I > should simply edit the changelog without making a patch for it, or for > anything under debian. Is the rule "no patches for changes under > debian/" correct? Yep, that is correct. > At least for awhile my changes will likely be focussed in one python > file; I am considering simply editing it in place (where it's installed > in the system) as a way of getting it right. Would that be > reasonable? I do that fairly often. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k41zt7pg@luthien.mhp
Re: Any hint for help2man if programm does not accept help option
Andreas Tille writes: > Hi, > > I would like to add man pages to a program which does not accept any > help option but if you call it without any option it outputs the help > information which would be needed to create the man page. Is there > any trick to convince help2man to work on this anyway? help2man -h "" $program will probably do the trick. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwcnt7j4@luthien.mhp
Re: Any hint for help2man if programm does not accept help option
On Mon, Apr 2, 2012 at 00:29, David Prévot wrote: > Hi, > > Le 01/04/2012 18:24, Gergely Nagy a écrit : >> Andreas Tille writes: > >>> I would like to add man pages to a program which does not accept any >>> help option but if you call it without any option it outputs the help > >> help2man -h "" $program will probably do the trick. > > No: > > $ help2man -h "" help2man > help2man: can't get `' info from help2man That happens because help2man without arguments will output to stderr. Add --no-discard-stderr, and it will just work. Or try with a program that outputs to stdout. It does do the trick. > $ reportbug help2man > > may help to make it work one day. Or you can read the full output of the command you pasted: | algernon@luthien:~$ help2man -h "" help2man | help2man: can't get `' info from help2man | Try `--no-discard-stderr' if option outputs to stderr -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOcunHm=VSZ66t0SdrZUJuFCVtVv=wqsht26b7vezxregqh...@mail.gmail.com
Re: Advice on use of patch system while hacking
Ross Boylan writes: >> Which, in this case, probably means running debian/rules build over and >> over again, until you have something that works. > I thought debian/rules build would invoke the same patch logic, but I > tried it and it didn't. Thanks for the tip. It won't, because unpatching happens at clean time. If you don't clean, it won't unpatch. At build time, it WILL invoke the patching logic, but that's smart enough to keep stampfiles and not reapply a patch that's already there. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obray235.fsf@algernon.balabit
Re: Status of B-D-I ?
Mathieu Malaterre writes: > Hi mentors, > > I am starring at the buildd status page of mrmpi: > > https://buildd.debian.org/status/package.php?p=mrmpi > > I cannot make any sense of the results on armel, armhf, i386, ia64, > mips and powerpc. Why are those arch running *-indep rules ? They are running build, which in turn runs -indep, because that's how buildds work right now. Until they're changed to run build-arch, there are a number of workarounds, one of which I explained on my blog[1] a while ago. [1]: http://asylum.madhouse-project.org/blog/2012/01/26/buildd-workarounds/ -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87398mxkgd.fsf@algernon.balabit
Bug#663685: RFS: openvpn-auth-radius/2.1-4 -- updated packaging, hardening release goal
I had a look at this request, but sadly, the debdiff did not apply: $ patch -p1 <663685.debdiff patching file debian/rules Hunk #2 FAILED at 21. 1 out of 2 hunks FAILED -- saving rejects to file debian/rules.rej patching file debian/control patching file debian/changelog patching file debian/README.source patching file debian/copyright patching file debian/compat patching file debian/patches/build-with-debug-symbols Can you upload the whole source of -4 to, say, mentors.debian.net? That would make it a lot easier for me to grab it, and I can debdiff to -3 myself, to see the changes. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iphihreq@luthien.mhp
Re: alternate make file for dh tiny rules
Matt Zagrabelny writes: > On Wed, Apr 4, 2012 at 9:49 AM, Matt Zagrabelny wrote: >> Greetings, >> >> I am packaging up milter-regex. The upstream source has three makefiles: >> >> Makefile >> Makefile.linux >> Makefile.solaris >> >> The file, "Makefile", is for building in a BSD environment. If I specify >> >> make -f Makefile.linux > > Hmmm. > > I tried the following: I suggest reading man dh, in particular, it's EXAMPLES section, where this very question has already been answered. > Perhaps I don't understand the MAKE environment variable. I'm afraid you don't. The info documentation of make talks about this variable in section "5.7.1 How the `MAKE' Variable Works". -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehs32phj@luthien.mhp
Re: Bug#667506: RFS: install-debian/2.1.3 [NEW] -- command line installs Debian system non-interactively
Vladimir Stavrinov writes: > On Wed, Apr 04, 2012 at 09:11:03PM +0200, Didier Raboud wrote: > >> Debian already has one component named the Debian Installer [0,1], which is > > As usual, I was not satisfied with it and hence wrote my own installer Out of curiosity, what were your problems with d-i, that couldn't have been fixed via patches to d-i, that could only be solved by writing a new installer? (Note: I have not looked at your package.) -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aa2r2pbv@luthien.mhp
Re: alternate make file for dh tiny rules
Matt Zagrabelny writes:
> Thanks for the hint, Gergely. Unfortunately the man page, in
> particular the EXAMPLES section, does not address my *initial*
> question (AFAIK):
>
> ---{original question}---
> Is there an easy way to tell "dh" that it should
> use Makefile.linux instead of Makefile?
>
> Or do I need to perform override_dh_* for all the targets that need to be
> used?
> ---{end}---
>
> And really at this point my original question is making less and less
> sense as I think about it.
Ah, I missed the second part of the question. In that case, the answer
is: possibly. You can play dirty tricks by symlinking Makefile.linux to
Makefile in the build target, and removing the symlink in clean.
The other option is to, indeed, override every target that would want to
use the Makefile.
--
|8]
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehs2znl5@luthien.mhp
Re: Bug#659047: RFS: rpg - Readable Password Generator
Vladimir Stavrinov writes: > On Wed, Apr 04, 2012 at 01:39:07PM +0300, Timo Juhani Lindfors wrote: > >> I think rpg is very insecure since all local users of the system can see >> the passwords that you generate. All they need to do is to look for the >> "grep" commands that appear in the process list. > > Fixed. See: I'm terribly sorry to be the nitpicking bad guy, but I have issues with the name. RPG is commonly the abbreviation for role playing game, and indeed, if you do an apt-get search rpg, the majority of the results are indeed, games. (And even the exceptions mean the same thing when they mention RPG in their long descriptions) As such, I find rpg to be a too common and confusing name, as it has nothing to do with role playing games. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87limatfhe.fsf@algernon.balabit
Re: l18n?
debian-de...@liska.ath.cx (Olе Streicher) writes: > $ ls -l msgs/ > insgesamt 308 > -rw-rw-r-- 1 ole no 39129 2012-04-11 14:01 da.msg > -rw-rw-r-- 1 ole no 38259 2012-04-11 14:01 de.msg > -rw-rw-r-- 1 ole no 41958 2012-04-11 14:01 es.msg > -rw-rw-r-- 1 ole no 37107 2012-04-11 14:01 fr.msg > -rw-rw-r-- 1 ole no 76973 2012-04-11 14:01 ja.msg > -rw-rw-r-- 1 ole no 39144 2012-04-11 14:01 pt.msg > -rw-rw-r-- 1 ole no 25965 2012-04-11 14:01 zh.msg > > They are quite small. Shall I keep them in the main package, or would it > be useful to create individual i18n packages out of them? And, if yes, > is this as easy as Keep them in the main package. The overhead of language packs would almost be larger than the actual content. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5pzn1u7.fsf@algernon.balabit
Bug#669373: RFS: flactag/2.0.1-1 ITP #507876
owner 669373 alger...@madhouse-project.org tag 669373 + pending thanks Daniel Pocock writes: > We are looking for a sponsor for our package "flactag" > > * Package name: flactag >Version : 2.0.1-1 >Upstream Author : Andy Hawkins > * URL : http://flactag.sourceforge.net/ > * License : GPL v3 >Section : sound I have a big collection of whole-album flacs, and would like to see this package in Debian, so I'll do a review and handle the upload (once blocking issues - if any - are fixed, of course). -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wr5bbt4i.fsf@algernon.balabit
Re: Tarball Debian Policy
"bilibop project" writes: > I'm new on this list. > I plan to create a source package to build several binary packages > (including shell functions, shell scripts, udev rules and > documentation). This will be a Debian native package. My question is > about the tarball, especially files taking place outside of the > debian/ directory: You can do whatever you want outside of debian/. The tree can reflect what paths the files would have on the filesystem, or separate them by tool, or language, or role, or whatever else you find best. > or what ? Can I do as I want or have I to follow some good examples ? > I have browsed some other tarballs with different conclusions, and > read documentation, but never found something saying: "this is > required" or more simply "this is a good way", "this is wrong, > because..." or 'this is let at the discretion of the upstream > developer". Is it the case ? It is this last one. Upstream decides how the upstream tarball looks like. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4vinckg@luthien.mhp
Re: maximal or minimal deletion when creating dfsg tarball?
Paul Elliott writes: > It has been suggested by a respected reviewer that while I am removing the > unsourced binaries, I remove ALL of the "convenience copies of code". That > way > the unused code would not confuse anyone. > > I thought, that when creating a dfsg tarball, one should remove only the > files > with licensing problems. > > What is the proper procedure? Remove only the unsourced binaries, or all of > the unused code? I happen to be the 'remove as little as possible' camp, because I want to keep my diffs with upstream to a minimum, and removing convenience copies is too intrusive for my liking. To avoid confusion, debian/README.source is a perfect place to explain that the convenience copies are unused on Debian. On the other hand, if you have to repack, you might as well create a clean tarball too - that also has merit. I do not think there's a single 'right' way to do it, both methods have their pros and cons. I happen to think that the minimal changes approach has more pros than the other. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vhmyel7.fsf@algernon.balabit
Re: Modifications of the changelog.
Tomasz Muras writes: > On 04/22/2012 02:48 PM, Bernhard R. Link wrote: >> * Arno Töll [120421 11:51]: >>> The whole point of a changelog is a time dependent frozen point of view >>> at your package. Once you released a version of a package, you should >>> consider it untouchable >> >> I strongly disagree. First of all, a changelog is there to see what has >> changed when, i.e. it is a documentation of what important changed where >> done and when (i.e. which package version) they were done for. >> There is normally no reason to change older entries as most details get >> less important over time, but if there is anything importing misleading >> in them, something important incorrect or something important enough >> missing, then not correcting the changelog is not acceptable in my eyes. >> >> The new changelog should be about what was changed since the version >> before (that might be some hint that the older changelog was corrected >> if you prefer), but import changes in the old package should be in the >> part of the changelog for the old package. > > I fully agree with Bernhard - basically if there is a good reason to > improve old changelog entry, you should do it. I agree (to a point) with both. I believe old changelog entries should not be touched (apart from typo fixes and the like): adding or removing elements from old entries is Bad(tm). There are very few exceptions, when adding or removing an entry from an old changelog is acceptable, and in those cases, these changes should be documented in the new version aswell, so that those who do not follow the packages VCS, will know that an old entry was modified too, and they might wish to have another look at it. Something like "* Changelog for $VERSION updated to reflect reality" can work for me, as long as there is some indication in the new changelog that the old was modified. But - and I want to stress this - having to modify old changelogs should be a rare exception. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nsaye50.fsf@algernon.balabit
Re: error while building debpackage for web
karunakar medamoni writes: > cp: cannot stat `debian/tmp/usr/share/XAwu': No such file or directory > dh_install: cp -a debian/tmp/usr/share/XAwu > debian/xawu/var/www/htdocs/XAwu/ returned exit code 1 > make: *** [binary-install/xawu] Error 2 A bit more information would be appreciated. Where did you get the sources from, what command did you use to build, do you have all the build-depends installed, and so on and so forth? -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obqiwtjj.fsf@algernon.balabit
Re: packaging help
Whit Armstrong writes: > Thanks, Daniel. > > I would be looking for 6-64999, assuming my package eventually > made it into debian, I suppose it would need to have a 'globally > allocated' uid. The idea is simply not to give users executing an R > script on the machine root access. Why do you think you'd need a statically allocated id? Why wouldn't a dynamic one work? -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjftuunw.fsf@algernon.balabit
Re: packaging help
Whit Armstrong writes: > Matt, Ansgar, and Gergely, > > Thanks for the tips. > > Can you also help with some advice on the init.d script? > > The init.d script for deathstar launches a daemon which listens for > jobs, and one worker per core. > > Can I use the same pid file for all of those processes? I assume it has a main process, which when stopped, would result in the workers being killed too. If that is so, I do not think you need to store the pids of the workers anywhere. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k415ur40.fsf@algernon.balabit
Re: packaging help
Whit Armstrong writes: >> I assume it has a main process, which when stopped, would result in the >> workers being killed too. If that is so, I do not think you need to >> store the pids of the workers anywhere. > > Perhaps I'm confusing terminology here. The main deamon does not > spawn the workers. It and the workers are started by the init.d > script. The workers and the main daemon should be started and stopped > together. > > In that case, it seems like I should store the pid's... so I can kill > them upon stop. > > Have I understood correctly? Correct. As a suggestion, I'd store the pidfiles under /run/your-program-name/, under names like worker:0.pid, and main.pid or somesuch. start-stop-daemon can be of great help here, but unfortunately, I don't recall any package off the top of my head that would serve as a good example, even though I know I've met one or two.. :( -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aa21umvh.fsf@algernon.balabit
Re: Bug#669373: RFS: flactag/2.0.1-1 ITP #507876
Andy Hawkins writes: > Hi, > > In article > <87wr5bbt4i.fsf__16851.6493672088$1334852129$gmane$org@algernon.balabit>, > Gergely Nagy wrote: >> owner 669373 alger...@madhouse-project.org >> tag 669373 + pending >> thanks >> >> Daniel Pocock writes: >> >>> We are looking for a sponsor for our package "flactag" >>> >>> * Package name: flactag >>>Version : 2.0.1-1 >>>Upstream Author : Andy Hawkins >>> * URL : http://flactag.sourceforge.net/ >>> * License : GPL v3 >>>Section : sound >> >> I have a big collection of whole-album flacs, and would like to see this >> package in Debian, so I'll do a review and handle the upload (once >> blocking issues - if any - are fixed, of course). > > Just wondering if you'd had a chance to look at this yet? > > Can you assist with getting libmusicbrainz4 in as well? There is an old > libmusicbrainz4-dev package (that is broken and hence won't work) that means > the new once can't just drop in. Nope, didn't have a chance yet. Today or tomorrow I will have a little time and see what I can do. I'll investigate the libmb4 status too. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d36nrivz@luthien.mhp
Bug#671476: RFS: omphalos/0.99.3-3 [ITP] -- network enumeration and domination
reassign 671476 sponsorship-requests severity 671476 wishlist thanks nick black writes: > Package: rfs > Severity: normal When filing RFS bugs, please follow the guidelines[1], and file it against sponsorship-requests, with the appropriate severity (wishlist for new packages). I have reassigned and adjusted the severity this time, but please pay more attention in the future. [1]: http://mentors.debian.net/sponsors/rfs-howto -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqakyx5b@luthien.mhp
Re: (un)patching patched files
debian-de...@liska.ath.cx (Olе Streicher) writes: > Dear Mentors, > > For a package [1], I have to patch one file (Makefile.am) twice: once > from debian/patches, and the other times from debian/rules. The patch in > debian/patches is needed to bring allow the use of a standard automake > (upstream uses a patched version), while the patch done from > debian/rules contains a rename of all libraries built. It is done in the > following way: > > 8<- > override_dh_autoreconf: > sed s/libast/libstarlink_ast/g -i Makefile.am > AUTOMAKE="automake --foreign" dh_autoreconf > > override_dh_clean: > sed s/libstarlink_ast/libast/g -i Makefile.am > dh_clean > 8<- > Why not add the library renaming as a patch too? One patch to allow the use of standard automake, another to update the lib names. That should do the right thing in every case, I believe. > What is the proper solution to deal with this? Converting the patching > from debian/rules to a debian/patches patch is not a good solution, > since the library names are heavily used in the whole Makefile.am, and > the resulting patch would be huge, complicated (understanding the lines > in debian/rules is much easier) and fill fail on each small change. You can create a small script, or even a debian/rules target that takes a half-patched Makefile.am, does the sed magic, and produces the final result. Then each time you need to update the Makefile, you run this script to refresh the patch. The patch in debian/patches will be large, possibly complicated and whatnot, but you can explain how it is created in debian/README.source, and live happily ever after. There are cases where a bit of ugliness is acceptable. This is one such case. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5p0wclc.fsf@algernon.balabit
Re: Bug#669373: RFS: flactag/2.0.1-1 ITP #507876
Daniel Pocock writes: > Why the confusion? The old package is named after the ABI number in > SONAME, the new one is named after the code version. > > Both Debian packages are called libmusicbrainz4, yet > OLD: code v2.1.x, SONAME = libmusicbrainz.so.4, ABI = 4 > NEW: code v4.0.x, SONAME = libmusicbrainz4.so.3, ABI = 3 Shouldn't the new one be named libmusicbranz4-3 then? Because if the ABI gets bumped to 4, then we'll have libmusicbrainz4.so.4, but it's a different library than 4.so.3, thus, will need a different name anyway. As far as I can see, these kind stuff is named fooN-M (see glib: libglib-2.0-0, with the so being libglib-2.0.so.0). That would also resolve the package name clash, I believe. > Action items: > > - all those packages need a bug report filed against them to say that > they depend on the obsolete SONAME. All such packages must release a > fix into sid Correction, these would need a bugreport filed to rebuild against with updated build-deps, for the new library. Not just for the soname, that is. > - the old libmb4 package should be removed from the archive of Debian by > making a bug report as described here: > http://wiki.debian.org/ftpmaster_Removals > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671088 Once everything is rebuilt against the new one, the old one can be removed, indeed. > - as it is `API breakage' and not `ABI breakage', we should really try > to have a distinct package name for the -dev package, although this is > not necessary if the old package is removed from the Debian archive > completely > http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi If you want a smooth transition, then you need a differently named -dev package anyway, as until the reverse deps are not rebuilt, we will need both in the archive. > - according to the packaging guide and library best practices, we could > potentially use the following convention: > > ABI number = 5 > SONAME = libmusicbrainz.so.5 > Package version = 4.0.x > => Package name = libmusicbrainz5 and libmusicbrainz5-dev > > and filenames: > libmusicbrainz5_4.0.0-1_amd64.deb > libmusicbrainz5-dev_4.0.0-1_amd64.deb That would work too, so would the lmb4-0 naming. I kinda lost track, though (sorry, busy week): what's upstream's take on this? What soname do they use? -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762c2qyan@luthien.mhp
Bug#672701: partial review
Hi! I'd suggest we keep this to the bugreport, no need to Cc mentors: whoever is interested, can post to the bug. I haven't reviewed the whole bug log yet, but one part caught my attention: On Mon, May 14, 2012 at 5:58 PM, Andrew Shadura wrote: >> > > * You should also consider using DEP5 for your copyright. > >> > May be or may not be needed. It's optional at this moment, so I >> > don't use it widely (yet). > >> It's in the packaging manual, and it's been accepted. You should be >> taking it more seriously. It's perhaps not a requirement, but it's a >> good thing to have. > > It's been accepted but it wasn't promoted to thing which is required. > I see no real reason to use it yet, at least here, sorry. While it is, indeed, not required, a DEP5 copyright file has a number of advantages, which, I believe, make it strongly desirable, and worthy of spending effort converting to it. On one hand, some sponsors prefer DEP5, and wouldn't spend time looking at non-DEP5 sponsor requests (I'm one of these, see my other reasons further along). The main reason I prefer DEP5 is because it pretty much forces one to look through the licenses and copythights THROUGHLY, which makes both my job easier when reviewing, and the ftpmaster's job when they process the package through NEW. Being machine-readable is a good thing too, but the main selling point of DEP5 for me is its granularity. So many times I've seen copyrights and licenses missed in a debian/copyright file, because one did not look further than the top level LICENSE file... DEP5 makes one dig deeper. Of course, one can do that without the format, but.. if you're going through it all throughly, and documenting it anyway... might as well do so in a format that's standardized in Debian Policy. So I would strongly urge you to reconsider, and use DEP5. In the long run, I believe it's worth the effort. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caocunhmnlm9ivgmghym9mbra+f8opjosi2o-6+nwd+tg_m6...@mail.gmail.com
Re: Bug#669373: RFS: flactag/2.0.1-1 ITP #507876
noowner 669373 tag 669373 - pending thanks Andy Hawkins writes: > Gergely, Daniel has uploaded new packages for flactag (2.0.2-1) and > libmusicbrainz5 (5.0.1-1). Are you still considering sponsoring flactag? > Would you also consider sponsoring libmusicbrainz5? Now that its version > number has been bumped, there should be no blocking bugs stopping it from > being accepted. Sorry for the late reply - sponsoring and -mentors@ fell back on my daily routine and didn't have time to reply until now. It's probably best if I let someone else do the sponsoring, who has more time to see it through. It appears to require more time and thinking power I can spare at the moment. Apologies for the delay. If I have more time, and you still require help, I'll do what I can. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vgkjx5h.fsf@algernon.balabit
Re: Processed: Re: Bug#669373: RFS: flactag/2.0.1-1 ITP #507876
Andy Hawkins writes: > Hi, > > In article , >Debian Bug Tracking System wrote: >> Processing commands for cont...@bugs.debian.org: >> >>> noowner 669373 >> Bug #669373 [sponsorship-requests] RFS: flactag/2.0.2-1 ITP #507876 >> Removed annotation that Bug was owned by alger...@madhouse-project.org. >>> tag 669373 - pending >> Bug #669373 [sponsorship-requests] RFS: flactag/2.0.2-1 ITP #507876 >> Removed tag(s) pending. >>> thanks >> Stopping processing here. > > Am I reading this right, that Gergely was planning to sponsor this package, > and has now decided not to? I'd still like to, but I'm throwing ENOTIME all over the place, so I can't, and I was a bottleneck long enough as it is. -mentors@ was Cc'd too, with an explanation, by the way. It seems the BTS was faster this time than my mail to the list. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nr8jvki.fsf@algernon.balabit
Re: Getting rid of control messages revisited
Arno Töll writes: > What about creating a list as owner of the pseudo-package dedicated to > BTS traffic (including control messages) named > sponsorship-requests@l.d.o. Furthermore, the mentors list should still > get bug traffic (only). Therefore we would subscribe that list via PTS > subscription to bug reports only [*]. How does that sound to you? That sounds like a good idea, though closing mails would be useful on -mentors@ too, not sure whether that counts as bug traffic or control. But that's just a nice to have thing, in my opinion, one can always manually subscribe to interesting RFS bugs anyway. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vghhgrw.fsf@algernon.balabit
Re: RFS: new powertop version
Julian Wollrath writes: > David Bremner wrote: >> This kind of change (changing the copyright file format) is not usually >> acceptable in an NMU, unless cleared with the maintainer. > But how else should I address the missing license information for 'pevent/*', > 'src/perf/perf_event.h', 'src/tuning/iw.*' and 'src/tuning/nl80211.h'. I only > found for the machine readable format how source files with different > licenses > should be addressed in the debian/copyright file. If I am not supposed to > change the format, should I just add under the overall copyright notice, > something like this: > > The files foo/* are Copyright year 'copyright holder' > - Short license text - > > for the above mentioned files, since it gives me no lintian warnings, or > should > it be done in some totally different way? The above is correct. Without DEP-5, the format is entirely up to you. As long as it contains the necessary information, it's good enough. You can take a look at aalib's copyright file[1] for an example, which is very similar to what you yourself proposed above. [1]: http://packages.debian.org/changelogs/pool/main/a/aalib/current/copyright -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wr3vdpu7.fsf@algernon.balabit
Re: Architecture dependensie
Bas van den Dikkenberg writes: > Hello, > > I am trying to make burp work on HPPA and powerpcspe architectures and > there for I want to specify witch version of debhelper he must juse. You're trying to do the wrong thing: debhelper is arch:all, so it will be the same across architectures. If you see a build fail on hppa/powerpcspe that says something along the lines of: , | Dependency installability problem for burp on powerpcspe: | | burp (= 1.3.6-2) build-depends on one of: | - debhelper (= 9.20120528) ` That means that a suitable version of debhelper is not installable on the architecture. There's nothing you can, or need to do about it. Once the arch catches up (if ever), this problem will go away. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zk8objuq.fsf@algernon.balabit
Re: Getting rid of control messages revisited
Arno Töll writes: > Hi, > Jakub asked me to forward his comment from IRC to thhis list (where he's > not subscribed anymore as some might remember): > > 14:14 < jwilk> IME the problem with mailing lists that nobody reads is > that from time to time some misguided people will post to them. Worse, > they'll expect that somebody answers them... > 14:15 < jwilk> But yeah, separate list + forwarding bugs to d-mentors is > certainly better than status quo. FWIW, I will be subscribed to the new list, and if any poor soul might post there, I'll direct them to the appropriate place instead. I'm good at reassigning bugs, reassigning people shouldn't be all that different. *grins* -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4tva3ww.fsf@algernon.balabit
Re: dh >= 9 builds strange debug-pkg
Björn Esser writes: > Hello! > > Why does dh >= 9 (in paticular the latest version in sid) put the > debugging-symbols in > usr/lib/debug/.build-id/$(2-Byte-Random)/$(Random).debug when building > a lib with multi-arch-support? See #642158, for an explanation. The short story is, it's easier to support build-id (from a gdb PoV) than N+1 multi-arched paths. It should not cause any issues. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bokza0wc.fsf@algernon.balabit
Re: RFS: cl-asdf (updated package)
Faré writes: > Dear mentors, > > I am looking for a sponsor for > the new version 2:2.22-1 of my package "cl-asdf". Is there an easily accessible changelog to see what changed in 2.22-1 since the last upload? (VCS-Browser could work too, but a .changes file would be nice. Alternatively, pasting the changes to the RFS mail can go a long way aswell) -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pq93sj0u.fsf@algernon.balabit
Re: Bug#677277: lists.debian.org: new list: sponsorship-reque...@lists.debian.org
Don Armstrong writes: > On Wed, 13 Jun 2012, Ansgar Burchardt wrote: >> No, as far as I know the current plan was to change the maintainer for >> the pseudo-package and then subscribe -mentors@ to only the discussion >> part via the PTS (the "bts" keyword there, but not "bts-control"). > > Ah; I didn't realize the PTS split these out. Of course, that means > that anyone who subscribes to -mentors and -requests gets to get mail > twice, which is annoying. But that's an annoyance I can opt in to. Currently, if I don't care about sponsorship control messages (which, right now, I don't) I have to opt out, and filter them. I don't like opt-out, opt-in is much friendlier. And as far as duplicate messages count: no problem. I'll have context on the -requests list too, and "summary" on -mentors. I think that's a great feature, rather than an annoyance. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vfrqhjv.fsf@algernon.balabit
Re: Copyright problems for the opensource reimplementation of a closed-source library (ITP #679504)
Christophe-Marie Duquesne writes: > I am the author of an opensource library that reimplements a > closed-source library. [...] > PS: the project in question is more a "proxy" towards the closed > source library than a real reimplementation, but technically I > actually reimplement every function of their header. If you are > interested, it is hosted here [2]. If it is a proxy, then it is not a reimplementation. That you add a wrapper for every function, doesn't matter, you still call the original. If it would be a reimplementation, the best course of action would be to start with a program that uses the library, and reimplement the functionality based on what the program expects. If you base your work on existing headers, that's borderline derived work. If you proxy, that *is* derived work, and the whole excercise is rather pointless, as you will still be bound by the original license. That you dlopen() and not directly link, is irrelevant. (At least, that is my understanding of legalities, but as always, I'm not a lawyer.) -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mx3dxhf8@luthien.mhp
Re: Copyright problems for the opensource reimplementation of a closed-source library (ITP #679504)
Christophe-Marie Duquesne writes: > On Fri, Jul 6, 2012 at 2:40 PM, Roger Leigh wrote: >> To avoid any implication that anything from the headers has been >> copied, why not just use the output of "nm [-D]". This is the >> interface that programs use to link with the library, and is >> what you need to provide as a drop-in replacement. > > I am not sure I could use that. nm does get you the name of the > symbol, but it does not get you the signature. You get that from examining appropriately licensed source code that uses the library. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipe1xcv5@luthien.mhp
Re: Git and Quilt
Andreas Rönnquist writes: > I believe you have greater chances getting an answer to this on > debian-mentors@lists.debian.org - list CC'd. Actually, no, not really. The debian-mentors@ list is for Debian packaging, mostly, not for questions unrelated to that. I'd think -user or http://ask.debian.net/ or something similar is the most appropriate place to ask these kind of questions. Nevertheless: > On Mon, 09 Jul 2012 15:26:50 +0200 > Jimmy Thrasibule wrote: > >> I have a core project on which I maintain a set of patches using >> Quilt. This allows me to make changes to the project without touching >> the files so I can upgrade to new versions easily. >> >> I keep my patches and the core project in a Git repository. When I >> want to change something, I apply my patches using Quilt, then I >> revert all my changes and I just commit the resulting patch. >> >> I would like to have a branch where all my patches are applied to >> deploy the code but I can't find any good way to do this. >> >> If I create a new branch from master and apply the patches, I will >> have conflicts on the next merge. I need something to apply the >> patches before the merge (maybe using one of the hooks?). Last time I needed to do something like this, I had the following setup: one branch with the pristine upstream sources (remote branch works aswell, but I like to keep a local copy, just for clarity's sake), another with all patches applied. Whenever I wanted to upgrade, I just rebased the patched branch onto master, and that's about it. Rebase does pretty much what you described above: unapplies your patches, merges in master, and puts your patches on top. Exporting quilt-patches out of that if that's your thing is fairly easy, I believe. In my case, I needed debian/patches/ stuff, and gitpkg was helpful and enough for my needs. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3yd10tq.fsf@algernon.balabit
Re: modifications by sponsors
Bart Martens writes: > Is it OK that a sponsor adds modifications to a sponsored package ? Under certain conditions, it can be ok. An OK from the sponsoree is one such condition. > Is it OK that a sponsor adds him/herself to "Uploaders" ? Again, with the sponsoree's agreement, and if the sponsor will act accordingly in the future, then yes. Otherwise no. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87a9z6y0lz.fsf@algernon.balabit
Re: Bug#681230: RFS: gtkdataboxmm/0.9.1-1 [ITP]
"Daniele E. Domenichelli" writes: > Hello Andreas, > > On 16/07/12 16:15, Andreas Tille wrote: >> Could you try to implement this to enable me building with >> git-buildpackage easily? > > git-buildpackage should be fixed now, but I didn't import the pristine > tar, since it is exactly the same as tag v0.9.1 in master. > Is the branch necessary? The difference between pristine-tar and a tag is that pristine-tar is the tarball, gzipped and all that. If you want to recreate the *exact* same thing from a tag, that is considerably harder, as you need to have just the right timestamps and various other things that affect the result. If you store the tarball too, recreating it becomes a lot more straightforward. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mx2yxye2.fsf@algernon.balabit
Re: packaging C interpreter
Rustom Mody writes: > I use and am interested in packaging the C interpreter > http://www.linuxbox.com/tiki/node/149 > 1. Its not under GPL but a 'creative licence' >From the homepage, and the source, this 'creative license' appears to be the Artistic License, used by, for example, Perl. I do not think that will be a problem. > 2. It build does not use autotools but make with small edits. I guess I > could try putting it under autotools Please don't do that. There's absolutely nothing wrong with not using autotools. If minor edits is all the upstream build system needs, doing that is far less invasive than replacing the whole build system. Especially as there is no upstream to send the autotoolsification to, there is absolutely no need to do such an invasive change. > 3. Its an old project Now this is a bigger isse: with no upstream, possible bugs are all yours to fix. Are you willing and capable of acting as if you were the upstream author? > I still believe that for many students C is still a first language and > therefore having an interpreter to study would greatly help them up their > learning curve And this is another issue: why would a C interpreter help in any way? We already have battle-proven C compilers, which students will be exposed to anyway, since if they work under unix, chances are, they'll use gcc or clang anyway. I do not think a C interpreter adds any value, I'm afraid. Granted, it's code may be easier to understand than any other C compilers, but you don't need to study a compiler to understand the language. Especially not if its your first language. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87394lbp1x@luthien.mhp
Bug#678343: RFS: tilem/2.0-1 [ITP]
Benoît Knecht writes: > Hi Albert, > > Albert Huang wrote: >> I am looking for a sponsor for my package "tilem" >> >> * Package name: tilem >>Version : 2.0-1 >>Upstream Author : Benjamin Moody and Thibault Duponchelle ( >> tilem-de...@sourceforge.net) >> * URL : http://lpg.ticalc.org/prj_tilem/ >> * License : GPL, LGPL, GFDL >>Section : math >> >> It builds those binary packages: >> >> tilem - GTK+ TI Z80 calculator emulator > > Your package build-depends on versions of libticables-dev, > libticalcs-dev, libticonv-dev and libtifiles-dev that are not even in > debian, which of course means it fails to build. How come? Newer versions of those packages are waiting for sponsorship too. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4rxji7f@bombadil.mhp
Re: Plugin Sub-Packaging
"BRAGA, Bruno" writes: > The "hack" I am doing to get this working is to basically to alter the main > package bash_completion file, which is created with a variable prepared to > be tempered with by plugin installations: > > ... > opts="option1 ... optionN" > plugin_opts= > ... Would it not be better if you did something like: for f in /etc/somewhere/else.d/*.completion; do . $f done Where files in /etc/somewhere/else.d/ would be like this: plugin_opts="$plugin_opts option-plugin1" That way, plugins could drop a file in said dir, and the bash completion would pick it up, hopefully, and you don't have to modify any file from another package (which would be a horrible thing to do anyway). -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87a9wuf8ry.fsf@algernon.balabit
Re: debian/bug-control: report bug against unofficial debian packages
Jakub Wilk writes: > [I'm not subscribed, please Cc me on replies.] > > * Russ Allbery , 2012-11-05, 12:46: >>> what can happen if a user reports a bug against one of my packages >>> by using 'reportbug' ? >>> Must I explicitly add 'Send-To: quid...@poivron.org' in >>> debian/bug-control to avoid conflicts with Debian BTS ? >> I use Bugs: mailto: as a source package header in >> debian/control instead. > > Does this actually work? According to bug #448493, it does not. I'm using Bugs: mailto: for packages in my personal repository, reportbug from squeeze does the right thing (I assume it works similarly in wheezy and sid too, I didn't test): , | algernon@galadriel:~$ reportbug syslog-ng-core | Warning: no reportbug configuration found. Proceeding in novice mode. | Detected character set: UTF-8 | Please change your locale if this is incorrect. | | Using 'Gergely Nagy ' as your from address. | Getting status for syslog-ng-core... | Checking for newer versions at packages.debian.org... | Unknown origin MadHouse; will send to syslog...@lists.balabit.hu. | Maintainer for syslog-ng-core is 'Gergely Nagy '. | Looking up dependencies of syslog-ng-core... ` #448493 seems to be about Bugs: by the way, without the mailto:, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448493#21 -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nl36lrx.fsf@algernon.balabit
Re: Bug#716905: RFS: goodbye/0.3-1 [ITP]
Adam Borowski writes: > Let's add some WTF to FTPmasters' day! :) This package is a perfect fit for a personal archive, but if anyone wants to upload it: you're in for a race for the fastest REJECT ever. We have enough WTFs a day already, thankyouverymuch. But I'm in a good mood today, so here's some criticism: * debian/rules without arguments does not behave sanely: make: *** No targets. Stop. It should at least do something, but "no targets" is unexpected. It says the same when tcc is not installed too, instead of failing violently for build-deps not being present. * It unconditionally rewrites debian/control This is REJECT reason alone. You simply don't do that. * debian/rules with an invalid target name still works: debian/rules binary == debian/rules yranib It should produce an error. This kind of unexpected behaviour is confusing, and not something we want in the archive. We already have CDBS for that[1], thank you. * There is no error checking: Trying to build the package in a chroot that doesn't have enough space: it will result in an empty, invalid package. The return value of mkdir(), system() and all that needs to be checked, or you're not complying with Policy 4.6. * d/rules can be exploited by an overly long version string * The binary created by d/rules is invalid: algernon@hadhodrond:/tmp/b$ dget -x -u http://mentors.debian.net/debian/pool/main/g/goodbye/goodbye_0.3-1.dsc dget: retrieving http://mentors.debian.net/debian/pool/main/g/goodbye/goodbye_0.3-1.dsc % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 1440 100 14400 0 342k 0 --:--:-- --:--:-- --:--:-- 703k dget: retrieving http://mentors.debian.net/debian/pool/main/g/goodbye/goodbye_0.3.orig.tar.xz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 1824 100 18240 0 471k 0 --:--:-- --:--:-- --:--:-- 1781k dget: retrieving http://mentors.debian.net/debian/pool/main/g/goodbye/goodbye_0.3-1.debian.tar.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 3133 100 31330 0 133k 0 --:--:-- --:--:-- --:--:-- 145k dpkg-source: info: extracting goodbye in goodbye-0.3 dpkg-source: info: unpacking goodbye_0.3.orig.tar.xz dpkg-source: info: unpacking goodbye_0.3-1.debian.tar.gz algernon@hadhodrond:/tmp/b$ cd goodbye-0.3/ algernon@hadhodrond:/tmp/b/goodbye-0.3$ debian/rules binary ar: creating ../goodbye_0.3-1_all.deb doing: [binary]\n algernon@hadhodrond:/tmp/b/goodbye-0.3$ dpkg-deb -c ../goodbye_0.3-1_all.deb dpkg-deb: error: archive has no newlines in header And indeed, debian-binary contains "2.0\n", and no newline. * Debugging d/rules is unnecessarily hard I can' easily attach gdb to figure out what's wrong. stracing it is painful too. * root:root owner is not enforced in the control.tar.gz: algernon@hadhodrond:/tmp/b/goodbye-0.3$ tar tzvf control.tar.gz -rw-r--r-- algernon/algernon 723 2013-07-15 17:35 control This is reject worthy too. -- |8] [1]: I'm just picking on CDBS, because I can. Feel free to substitute anything else, dh short form, dbs, dpatch, dh-exec, you name it. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc4bq172.fsf@algernon.balabit
Re: Bug#716905: RFS: goodbye/0.3-1 [ITP]
Adam Borowski writes: >> * debian/rules without arguments does not behave sanely: >> >> make: *** No targets. Stop. >> >> It should at least do something, but "no targets" is unexpected. ACK. This wasn't a REJECT-worthy reason alone, many packages fail in similar ways, but if you're making an example package, make it better than what's already available, in my opinion. Or worse, if that's your goal. :P >> * It unconditionally rewrites debian/control >> >> This is REJECT reason alone. You simply don't do that. > > Thus I don't. Please tell me in what circumstances would it overwrite > debian/control. My mistake, I mixed up control and debian/control. But that highlights another problem with the package: it's kind of hard to follow what it does, and why. >> * debian/rules with an invalid target name still works: >> >> debian/rules binary == debian/rules yranib >> >> It should produce an error. This kind of unexpected behaviour is >> confusing, and not something we want in the archive. We already have >> CDBS for that[1], thank you. > > Policy 4.9 explicitely allows extra targets. Using any not defined in > the policy is undefined behaviour; a comment in "goodbye" mentions > that. Fair enough. >> * The binary created by d/rules is invalid: >> >> algernon@hadhodrond:/tmp/b$ dget -x -u >> http://mentors.debian.net/debian/pool/main/g/goodbye/goodbye_0.3-1.dsc >> dget: retrieving >> http://mentors.debian.net/debian/pool/main/g/goodbye/goodbye_0.3-1.dsc >> % Total% Received % Xferd Average Speed TimeTime Time >> Current >> Dload Upload Total SpentLeft Speed >> 100 1440 100 14400 0 342k 0 --:--:-- --:--:-- --:--:-- >> 703k >> dget: retrieving >> http://mentors.debian.net/debian/pool/main/g/goodbye/goodbye_0.3.orig.tar.xz >> % Total% Received % Xferd Average Speed TimeTime Time >> Current >> Dload Upload Total SpentLeft Speed >> 100 1824 100 18240 0 471k 0 --:--:-- --:--:-- --:--:-- >> 1781k >> dget: retrieving >> http://mentors.debian.net/debian/pool/main/g/goodbye/goodbye_0.3-1.debian.tar.gz >> % Total% Received % Xferd Average Speed TimeTime Time >> Current >> Dload Upload Total SpentLeft Speed >> 100 3133 100 31330 0 133k 0 --:--:-- --:--:-- --:--:-- >> 145k >> dpkg-source: info: extracting goodbye in goodbye-0.3 >> dpkg-source: info: unpacking goodbye_0.3.orig.tar.xz >> dpkg-source: info: unpacking goodbye_0.3-1.debian.tar.gz >> algernon@hadhodrond:/tmp/b$ cd goodbye-0.3/ >> algernon@hadhodrond:/tmp/b/goodbye-0.3$ debian/rules binary >> ar: creating ../goodbye_0.3-1_all.deb >> doing: [binary]\n >> algernon@hadhodrond:/tmp/b/goodbye-0.3$ dpkg-deb -c ../goodbye_0.3-1_all.deb >> dpkg-deb: error: archive has no newlines in header >> >> And indeed, debian-binary contains "2.0\n", and no newline. > > Uh? > > dpkg-deb -c ../goodbye_0.3-1_all.deb > drwxr-xr-x root/root 0 2013-07-15 22:42 usr/ > drwxr-xr-x root/root 0 2013-07-15 22:42 usr/share/ > drwxr-xr-x root/root 0 2013-07-15 22:42 usr/share/doc/ > drwxr-xr-x root/root 0 2013-07-15 22:42 usr/share/doc/goodbye/ > -rw-r--r-- root/root 476 2011-07-29 01:45 > usr/share/doc/goodbye/copyright > -rw-r--r-- root/root 203 2013-07-15 22:42 > usr/share/doc/goodbye/changelog.gz > -rw-r--r-- root/root 322 2013-07-15 22:42 > usr/share/doc/goodbye/changelog.Debian.gz > drwxr-xr-x root/root 0 2013-07-15 22:42 usr/share/man/ > drwxr-xr-x root/root 0 2013-07-15 22:42 usr/share/man/man1/ > -rw-r--r-- root/root 285 2013-07-15 22:42 > usr/share/man/man1/goodbye.1.gz > drwxr-xr-x root/root 0 2013-07-15 22:42 usr/bin/ > -rwxr-xr-x root/root 126 2011-07-29 01:45 usr/bin/goodbye > > Could you please tell me how did you get that effect? That would imply > make suddenly failing to unescape "\\"; any version of make in Debian > follows the same rules. I'm on wheezy/amd64, make 3.81-8.2, bash 4.2+dfsg-0.1, tcc 0.9.26~git20120612.ad5f375-6, with /bin/sh set to bash. The problem is that the echo behaviour you depend on is not something /bin/echo or bash support: (zsh): % echo '\n\n' % (bash): $ echo '\n\n' \n\n $ (dash): $ echo '\n\n' $ (/bin/echo): $ /bin/echo '\n\n' \n\n $ You will likely need to use either printf, or /bin/echo -e, or force SHELL to be dash, or any suitable shell. Once I changed my chroot to point /bin/sh to bash instead of dash, the package failed to build from source. This falls under the FTBFSIASW of the REJECT-FAQ[1]. [1]: http://ftp-master.debian.org/REJECT-FAQ.html >> * Debugging d/rules is unnecessarily hard >> >> I can' easily attach gdb to figure out what's wrong. stracing it is >> painful too. > > set follow-fork-mode > strace -f > tcc (or gcc, or clang ...) to a file > > On the other
Re: (override) dh_compress
Mathieu Malaterre writes: > I am trying to skip the dh_compress steps for the following package: > > http://packages.debian.org/sid/all/tbb-examples/filelist > > Instead of manually checking all possible combinations (-Xcpp > -Xpbxproj, -Xvcproj ... ), I thought I could just do: > > $ cat debian/rules > ... > # Makefiles should not be compressed (tbb-examples) > override_dh_compress-indep: > > Technically this is adapted from the dh man page. However this is an > error *not* to compress debian changelog. > > What would you do: > > - fill a bug report to dh, at least get the man page fixed ? The man page is correct, it states: "By default...". If you override it, the default will not be used. > - grep all possible extensions, watching out for conflict with > d/*changelog and pass that to dh_compress -X .. ? I would suggest one of the following: 1) Disable dh_compress, but do compress d/changelog: override_dh_compress-indep: dh_compress debian/$packagename/usr/share/doc/changelog* 2) Use a better exclude mechanism override_dh_compress-indep: dh_compress -X*/examples/* I have not tested either option, but both should work with just a little bit of modification, would I remember the syntax wrongly. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eh7vdgmg.fsf@algernon.balabit
Bug#710473: bats: 0.3.1 status?
Hi! I have recently started playing with the idea of using BATS, and came across your ITP and RFS. However, for my use, I'd need a more recent version (0.3.1+). Could you update your packaging to that version? I'd be happy to review and sponsor it afterwards. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc0b65wj@galadriel.madhouse-project.org
Bug#728716: RFS: xchroot/2.3.2-9 [ITP] -- Hi Debian!
Elmar Stellnberger writes: > Am 04.11.13 18:43, schrieb Paul Tagliamonte: >> >> >> >> On Mon, Nov 4, 2013 at 12:42 PM, Paul Tagliamonte >> mailto:paul...@debian.org>> wrote: >> >> On Mon, Nov 04, 2013 at 06:22:15PM +0100, Elmar Stellnberger wrote: >> > Is it really a problem? If yes then I can add an exception for >> > distributors like Debian. >> >> Perhaps you're interesting in reading our guidelines: >> >> http://www.debian.org/social_contract#guidelines >> >> point 8 is "License Must Not Be Specific to Debian". >> > We could possibly allow any distribution to distribute patches without > notifying the > "original authors" as far as the term "distribution" can be defined > clearly and > doubtlessly (i.e. to only apply this restriction to individuals and > organizations who > do not distribute their software for free to the public; if that would > help us). That will not be possible, due to DFSG#3 (derived works): "The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software." Which means that whoever gets the software through Debian MUST be able to redistribute it under the very same terms Debian did. Furthermore, there are many distributions derived from Debian, asking all of them to send you patches whenever they make the tiniest modification (even to packaging!) is not going to work, neither for you, nor for Debian, nor for any of the distributions based on it. I would strongly suggest you reconsider your license, or at least this requirement, as it will never, ever work as you expect it to: people will just not use your software, because requiring them to send patches back no matter what is so huge a pain in the backside that noone in their right mind will do it. It's a much smaller effort to find an alternative (like schroot, in this case) or roll your own. Furthermore, there's this part of the license: "If you want to develop a separate branch of this program you need to ask the original authors for permission." That goes against DFSG#4, which permits the author to require distribution under a different name, but still requires the license to allow distributing patched versions. The quoted paragraph prevents that, so much so, that it's far too strict even for non-free: if we ever want to do a non-maintainer upload for whatever reason, it's not possible, because that may very well mean "develop a separate branch", and thus require asking for permission. Furthermore, the quoted paragraph also has a loophole: it only requires one to ask the original authors for permission, it does not say that the permission needs to be granted too. In a strict reading of the text, just asking for permission and not waiting for an answer is ok. Even better, asking, but receiving a negative answer is still ok, because one asked. Going further: "Distribution of the program by third parties must be done free of charge apart from fees for the physical reproduction of the data medium" This goes against DFSG#1: "The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale." While this part may be okay for non-free, it definitely is a no-go for main. The exceptions given do not matter. The way distribution is defined is also a bit odd: "The term distribution describes shipping of a given set of software and its documentation with adherent materials." So if I strip away parts of the software (like documentation), and publish that, does that count as distribution? Strictly reading the license: no, because adherent materials are not shipped with it. "Availablity free of charge or costs includes tools, software and manuals needed to download or obtain the distribution in a finally usable state as well as the possibility to verify the integrity of the download securely but not general connectivity to the internet." This part is also quite vague. Lets imagine the following scenario: there's Joe Average user, installing GNU/Linux for the first time. He has absolutely no idea how to do it, so he buys a book about the topic. To install additional software, such as those covered by this license, he uses tools and techniques described in the manual, for which he paid for. In this case, the distribution is not allowed to let Joe Average install programs covered by this license, because he needed a paid-for manual to install the distribution and the software covered by the license in question. That's not going to work, either. >> > However what I want is being noticed somehow about changed versions >> > of my programmes. >> >> That's OK. It just means you need to upload to non-free. >> > I hope that will not pose an unnecessary restriction to the > re-distribution as > the
Bug#728716: RFS: xchroot/2.3.2-9 [ITP] -- Hi Debian!
Elmar Stellnberger writes: > S-FSL v1.3.3 uploaded at http://www.elstel.org/license/ > > Having clearly considered your critics I have published a reworked > edition > of S-FSL which should more strictly adhere to the terms of OSS-software. > As you can understand and as I have already partially described there are > still issues to me which discourage me from using an existing license like > f.i. GPL or BSD. I wouldn't mind hearing the full explanation, because I honestly see far more issues with a new license than with using any of the existing, battle-tested ones. I will review the current (1.3.3) license, but that's about as much time as I'm willing to spend on it. I would recommend getting your license OSI[1] approved, to make things much easier for distributors like Debian. [1]: http://opensource.org/approval So, about that review: This program may be used free of charge. It has been designed as research work and comes without claim for fitness to any particular usage purpose and completely without warranty or any kind of liability such as lost revenues, profits, harm or damage of any kind. So far, so good. The program may be distributed by a third party given that the program is distributed in its original state completely without any kind of modifications or patches. This fails DFSG#3 and DFSG#4, but... If you need to re-distribute a patched version of this program you need to distribute the patches separately from the original so that the pristine version can be restored at any time. Any derived work must carry the name of the distributor, vendor or the product in its name (or a unique shothand for it) preceded by the original unchanged name of the software and its version. With this clarification, it passes DFSG#3 and DFSG4, but only barely. Modifications applied to this program may not affect the name, original version, copyright or any reference given to the authors such as their email addresses or their web presence and/or page in any part of the program or any files attached to the program. What exactly does this mean? Does that mean that if someone makes a modification in form of a patch, he can't add his copyright to the modified files? Or does that mean that they can't modifiy the original copyright & license notes? Or, another question: what if a software under this license is included in something like Debian, where after the freeze, you're not supposed to upload new versions of the software, but the upstream webpage moves, or e-mail address changes, and for some reason, the maintainer wants to correct that in the package. She then has to modify the email addresses and URLs in the package, which would - in my reading - go against the license. You may only extend or modify this program given that you do also consent with the following terms. As far as you are not a public distributor you are oblidged to send a copy of your patches to the original authors referred to herein as the authors of the first version of the program as being listed in the changelog or program header whenever you publish or exchange your patches with other people. This is against DFSG6: no discrimination against fields of endeavor. It discriminates non-public distributors (whatever they may be), which makes the license non-free at best. It also is unclear about what a public distributor is (ok, that's explained a bit better later, see my comments there). Consider that Debian is not a legal entity, either. Software within Debian are distributed using a mirror network, some of which are operated by commercial entities. There are also private mirrors of Debian (my company has one too, for internal use), which would not be able to carry software under this license, since they're not public distributors. In this reading, it's not ok for non-free, either, as it cannot be distributed by Debian at all. Also, the wording is unclear: "whenever you publish or exchange your patches with other people" is very vague. If someone downloads the patches from a mirror, that can be considered exchange. Do I, as a distributor, need to send the same patch every time someone downloads it? Do I, as a developer, need to send the patch every time I send it in for internal review? Do I need to send work in progress patches too? (It's a patch, and I'm sharing it with collegues, after all!) That is unreasonable and unenforcable, and clearly goes against the spirit of free software. Furthermore, trying to force out such strict control of the software is very discouraging for potential contributors. By distributing patches you do consent apart from this that the original authors may incorporate your patches into future versions of this program. The patched parts of the program and the patches themselves will also become subject to this licensing and may even be used for free in other programs or in the same program under different licensing as soon as you ch
Re: Bug#728716: RFS: xchroot/2.3.3-3 [ITP] -- extended chroot with X11/Xorg forwarding and aufs/unionfs support for read only roots
Elmar Stellnberger writes: > Am 12.11.2013 10:24, schrieb Andrew Shadura: >> Hello, >> >> On 12 November 2013 10:22, Elmar Stellnberger wrote: >>> O.K. That is actually what is to be done next. >>> There are some people whom I know and who I am going to consult. >>> It will at last be necessary in my very own interest to assert that the >>> license will work in practice as intended. >>> I hope you are going to accept the results if and only if I consult >>> someone who is a lawyer. >>> Again, thanks for your contribution to the license. It was actually >>> necessary to make it fit for practical usage. >> Unfortunately, it's still unfit for use. >> > Could you tell me in a short why you do think so. A good number of people already told you, on multiple mailing lists and on other media, repeatedly. Go read them. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gccp9wo.fsf@algernon.balabit
Re: Restrictive Artwork License
Felix Natter writes: > (upstream) Freeplane 1.3.x will have new icons (application icon, > document icon), but the artist wants to keep all rights and only grant > the Freeplane project all rights of use. > --> Is that ok for Debian? No, it's not. See DFSG#1, #7, and possibly #8 too. But mostly #7. > --> Is it even compatible with the GPL-2+ license of Freeplane? It's early in the morning, but my gut feeling is that no, it would not be compatible. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y534jyvw.fsf@algernon.balabit
Re: generic debian/rules that creates directories
T o n g writes: > Hi, > > Is it possible to have a generic debian/rules that creates directories? > > The upstream Makefiles was not designed to install into $DESTDIR but > to /, so it assumes /usr/bin exists, while that creates problems for me: > > install -s -m 755 autogb /export/build/zh-autoconvert/bld/zh- > autoconvert-0.3.16/debian/tmp/usr/bin > install: cannot create regular file '/export/build/zh-autoconvert/bld/ > zh-autoconvert-0.3.16/debian/tmp/usr/bin': No such file or directory > > Is it possible to alter the following `debian/rules` file so that it > plays nicely with such upstream Makefiles? Yes. You want to use dh_installdirs(1). I suggest you read its manpage. Mind you, you won't need to touch debian/rules for that. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eh4rjngh.fsf@algernon.balabit
Re: Fw: Bug#756654: ITP: rohc -- RObust Header Compression (ROHC) library
Simon Paillard writes: > Furthermore, there is a lintian warning I can't get fixed: > W: librohc-dev: duplicate-changelog-files > usr/share/doc/librohc-dev/ChangeLog.gz usr/share/doc/librohc-dev/changelog.gz If you remove ChangeLog from debian/docs, that should get it fixed. dh_installchangelogs will pick up the upstream one. For the future, if you set DH_VERBOSE=1 when building the package, debhelper will tell you what it is doing, and you'll see which command is copying which file where. That should help you to resolve similar issues in the future. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874mxrm4ve@balabit.hu
Re: how to build debugging binaries
Thus spoke Jochen Voss <[EMAIL PROTECTED]> on 2001-01-28 18:52:37: > Hi, > > is there any standard way to create a version of a > debian package with debugging enabled (i.e. to use > the -g compiler switch during compilation)? you can do a DEB_BUILD_OPTIONS=debug dpkg-buildpcakge, packages should recognise the option and build with debugging symbols. Gergely Nagy \ mhp/|8] -- =]| [EMAIL PROTECTED] |[= . Powered by bread 'n water . pgpJd4wD768yv.pgp Description: PGP signature
Re: how to build debugging binaries
Thus spoke Matt Zimmerman <[EMAIL PROTECTED]> on 2001-01-28 16:14:47: > > s/packages should/packages conforming to policy version 3.2.0 or greater > should/ > > "should" referring to the Policy definition, meaning that this is optional > (though recommended) behavior. > Well. In this case: export CFLAGS=-g dpkg-buildpackage If something doesn't honour CFLAGS, it should be fixed :) Gergely Nagy \ mhp/|8] -- =]| [EMAIL PROTECTED] |[= . Powered by bread 'n water . pgpXZsOg1ooCk.pgp Description: PGP signature
Bug#771774: RFS: libmongo-client/0.1.8-2 [ITA]
> "Jörg" == Jörg Frings-Fürst writes: Jörg> I am looking for a sponsor for my package "libmongo-client" Jörg> Package name: libmongo-client Jörg> Version : 0.1.8-2 As the former maintainer and upstream, there are a few issues I see with the packaging (also sent earlier in private mail, but repeating here in case someone was looking at the package and wanting to sponsor it). * Instead of disabling the watch file, if you tweak the regexp to only match upstream releases, then it will work, and not catch my old debian/ tags: , | version=3 | | https://github.com/algernon/libmongo-client/releases .*/libmongo-client-([\d\.]+)\.tar\.gz ` * The build: target was there for a reason. Without it, we will build the arch-indep stuff by default too, which is something we want to avoid. For example, it will FTBFS on buildds, because they do not install build-depends-indep. And we really don't want doxygen and graphviz in B-D, because those pull in a shitload of stuff, to build docs that will be discarded by buildds anyway. * Why move --dbg-package from DH_OPTIONS to an override? -- |8] signature.asc Description: PGP signature
Bug#771774: RFS: libmongo-client/0.1.8-2 [ITA]
> "Jörg" == Jörg Frings-Fürst writes: >> * The build: target was there for a reason. Without it, we will build >> the arch-indep stuff by default too, which is something we want to >> avoid. >> >> For example, it will FTBFS on buildds, because they do not install >> build-depends-indep. And we really don't want doxygen and graphviz in >> B-D, because those pull in a shitload of stuff, to build docs that >> will be discarded by buildds anyway. Jörg> I fully agree with you. Jörg> But where are the problem? The package has no FTBFS and I don't change Jörg> your -arch / -indep division. Jörg> Please can you specify your minds. Ah, yes, now I remember. This was done for backporting purposes, so the package could be built on older releases where sbuild didn't call build-arch yet, but used build. For unstable, dropping the build target as you did is fine, indeed. >> * Why move --dbg-package from DH_OPTIONS to an override? Jörg> --dbg-package is only needed in dh_strip[1]. Yes. But it works fine in DH_OPTIONS too, without any ill side-effects, and is shorter there. (Personal thing, but I hate overrides, and if there's another way to do what I want, which isn't convoluted, I'd choose that) But override or DH_OPTIONS, in this case, doesn't matter. The updated package looks fine, good job! One thing you may wish to change is the "Source:" stanza in debian/copyright. While I intend to restore the git URL there (I just need to reinstall cgit), it currently doesn't work, and github is the canonical one nowadays. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87tx1av8x8@madhouse-project.org
Re: Bug#771774: RFS: libmongo-client/0.1.8-2 [ITA]
> "Jörg" == Jörg Frings-Fürst writes: Jörg> Hi Martin, Jörg> Am Mittwoch, den 08.07.2015, 09:47 -0400 schrieb Martin Michlmayr: >> * Jörg Frings-Fürst [2015-07-08 14:58]: >> > for the ftbfs bug I have upload a new version of >> > libmongo-client/0.1.8-2[1]. >> >> I sponsored this upload for the GCC 5 build failure but I won't be >> able to sponsor in the future, so you still need to find one. >> Jörg> Many thanks... While my response time has been terrible in the past when it came to libmongo-client sponsoring, I'll try to do better. Please ping me on IRC or via e-mail (off-list or CC'd) if you need sponsoring, and I'll see what I can do. -- |8] signature.asc Description: PGP signature
Re: Granting DM rights as a sponsor
> "Ole" == Ole Streicher writes: Ole> I want to grant DM rights for a package that I sponsored, and I am a bit Ole> confused how this works in real life. Ole> According to [1], I should create a file with the following format: Ole> --8< Ole> Archive: ftp.debian.org Ole> Uploader: Ole Streicher Ole> Action: dm Ole> Fingerprint: 1234567890ABCDEF1234567890ABCDEF Ole> Allow: plotly Ole> --8< Using yodack[1], this would look something like this: yodack on ftp-master.debian.org, \ for dm 1234567890ABCDEF1234567890ABCDEF, \ please allow uploading plotly. [1]: https://github.com/algernon/yodack It will do all the required steps. There may be better options, or in-debian tools that help you do the same thing, but yodack is what I know. I faintly remember there being a reason why yodack never made it into Debian (such as a better alternative), like this: dcut dm --uid 1234567890ABCDEF1234567890ABCDEF --allow=plotly But that's purely speculation, based on dcut(1). -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87mvyzm5ri@madhouse-project.org
Re: Upstream looks for a proper way to build the packages by itself
Toni Mueller writes: > On Tue, 31.05.2011 at 14:59:25 +0300, Andriy Senkovych > wrote: >> I'm an uploader of the buildbot and buildbot-slave Debian packages and >> a contributor to the buildbot project[1] itself. As you may wonder, >> buildbot is a distributed continious integration tool written in >> Python. And since this is a continious integration tool, it would be >> great if it could support building packages too. > ... >> distros. Buildbot architecture considers all work should be done on >> slaves and report the results to master which is great for >> multiplatform build process. This experience will also be useful for >> other projects willing to use buildbot. > > are you perchance aware of the efforts around Jenkins[1]? If so, what > do you like or dislike about it? To me, it looks like it could be > equally well expanded to build packages of all sorts, and non-python > packages, too (ie, a more general approach). BuildBot is perfectly able to build non-python packages[1] aswell - doesn't seem like a less general approach to me. Nevertheless, the intent here - in my opinion - is not to discuss the merits of BuildBot vs $something_else. [1]: http://build.chromium.org/p/chromium/console -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tyc93oxm@balabit.hu
Re: RFS: trophy (Adopted and updated package)
Kilian Krause writes: > 1. Using dh-autoreconf is ugly. Please try to avoid it and backport the > full regenerated configure in your patch to make sure the source is > identical on all buildds. IMHO dh-autoreconf is a solution for a local > build that you maintain for yourself outside of Debian, but not for an > official pacakge. I strongly disagree with this view. While dh-autoreconf may not be the best solution in all cases, it does have its uses (apart from the obvious case where the upstream tarball does not have generated files like configure & co). For example, running dh-autoreconf instead of including the regenerated configure and whatnot in the debian.tar.gz has the following advantages: * It's much much smaller. * It makes it easy to keep the generated files up to date. Which can easily benefit the buildds. * If autoreconf breaks the package build, no big deal: it probably needed an update anyway, if for nothing else, then to allow transitioning the old version of auto* out of Debian, so we won't have 5 or more versions of, say, automake in the distribution. The only downside from my point of view, is that it pulls in quite a bit of stuff, which places some extra burden on the buildds. Of course, if a package's build system has a tendency to break randomly when autoreconf'd, then regenerating configure & co with a known good version is advisable. But for most cases, where both configure and the Makefile.ams are dead simple, I see little harm, and that's far outweighted by having a small and clean .debian.tar.gz. I believe that touching as little as possible in the upstream sources is desirable, that the debian patches remain unobtrusive and reasonably compact. Regenerating configure & co goes against this, as it touches not only the sources, but generated files aswell. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739im1hm1@balabit.hu
RFC: git-flow
Hi! While I'm not looking for a sponsor for my package, git-flow, I would appreciate any comments regarding the packaging, and all ideas for improvement. * Package name: git-flow Version : 0.4.1-1~preview0 Upstream Author : Vincent Driessen , Kate Ward, Justin Hileman * URL : https://github.com/nvie/gitflow * License : BSD-2-clause, LGPL-2.1 & Expat Section : vcs It builds a single arch: all package: git-flow - Git extension to provide a high-level branching model The package is lintian clean, even with -iE --pedantic. The upload would close the ITP: #632640. My motivation for maintaining this package is explained in the RFP->ITP retitle, but long story short: I use git-flow both at work and for my personal projects, having it in Debian would simplify my $HOME setup considerably, among other things. It would also make it easier to persuade my co-workers to use the branching model. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/git-flow - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/git-flow/git-flow_0.4.1-1~preview0.dsc There are a few issues left to iron out still, like the ZSH completion not working unless sourced. This is known, and is under investigation. If all else fails, I'll ship the ZSH completion in, say /usr/share/git-flow/git-flow-completion.zsh, and mention it in README.Debian. The version is intentionally ~preview0, as I'm seeking comments and review only, not sponsorship. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aacpp145@luthien.mhp
Re: Nitpicking: you are doing it wrong
Thomas Goirand writes: >> On Fri, Jul 08, 2011 at 12:55 +0200, Jakub Wilk wrote: >> >> [...] but should be made explicit as the reasons not to use dh, for >> example, might mean that the helper is lacking functionality or >> behaves buggy in certain situations. > > I don't get it here... > > Do you think that debian/rules calling the emacs debhelper > when it's not needed 99.% of the times is a superior way > to do packaging? Or is using something fully automated where > you don't have to think or understand what's going on a better > way to do things? > > In what way not using dh has to be justified at all? I'd rather say > the opposite way! I really don't think that dh is "state-of-the-art" > (as Arno is saying later on in this thread). As someone who was very strongly against helpers in the past[0], please allow me to chime in. I do agree that whoever is packaging a piece of software needs to understand how the system works underneath. However, once that is understood, I now see no harm in using dh: I know what it will be doing, and that extra ~5 seconds spent calling helpers that do nothing is something I couldn't care less about. I much more prefer a ~6 line debian/rules, that works now, and thanks to the helpers, will very likely work a year from now, without me having to change it, because the helpers will adapt the package to current policy. One still needs to verify that the result is what one expects, but it's much easier to verify, than to migrate AND verify aswell. We have tools to serve us, let the tools do that! Or we can go out and build debs with tar and ar. (I actually had an applicant in the past who suprised me with a package that did just that. ;) Personally, I find dh to be very neat, and useful, as it allows me to keep my rules very short. Comparing my current packages to the ones I made a decade ago, the new ones are much easier to understand and update. I recently had a look at an old package of mine.. it was a mess. Two pages of gory, uninteresting, perfectly common commands instead of two lines of this: %: dh $@ I believe that when someone knows the underlying system, using helpers is the way to go, because it makes not only your task easier, it also makes it easier for others to understand the packaging. NMUing something with a complex, home-built debian/rules is a pain in the backside at best. And yes, one does sacrifice a lot of control on the altar of convenience. But I don't see that as a problem, there's nothing wrong with convenience. And while useless helper scripts add to the build time, that load is negligible. Even on the slowest machine I could get my hands on (emulated armel, with ~256Mb memory, running on an dual-core amd64 host, along with 4 other VMs), the difference between using dh $@ and explicit dh_* commands on an average package was about 3 seconds. Completely getting rid of debhelper and doing everything by hand made it 2 more seconds faster. I don't know about you, but for 5 seconds, I'm not going to give up convenience. There's also the case where the assumptions made by the helper tools work against the packager's wishes, and at that point, when the tools start to get in one's way, they should be either fixed, or dropped. When the effort spent on workarounds start to approach the time saved by the tools, it's time to reevaluate, and perhaps drop the helpers. But until then, why? Then again, the beauty of Debian is that people are allowed to tailor their packaging to their own liking (as long as it conforms to policy... sadly a debian/rules written in SHOOP does not). There's arguments for and against both helper-using and helper-less packaging, neither is a silver bullet. 0: http://lists.debian.org/debian-newmaint/2001/10/msg00021.html -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739iglbjm@luthien.mhp
Re: Nitpicking: you are doing it wrong
Thomas Goirand writes: > On 07/09/2011 05:14 AM, Gergely Nagy wrote: >> I believe that when someone knows the underlying system, using helpers >> is the way to go, because it makes not only your task easier, it also >> makes it easier for others to understand the packaging. >> > We were talking about mentoring, and you are talking about someone "who > knows the underlying system", and we should generalize and push them to > use dh because of that. Isn't there is something wrong here? I thought we were talking about sponsoring. Which is not the same as mentoring. There are people who have good knowledge of debian package building, yet, are sponsored. But even if it's one's first package, I'd rather push them towards dh as a starting point, becuase that's _simple_. Getting to know the underlying system takes time, and when you expose a new contributor to that, he might very well run away. In short, one needs to find out on a case by case basis which would be better. I see no point pushing someone who already has 10+ packages in Debian towards dh7, when he'd much rather just be done with it and use dh8. On the other hand, when someone's obviously inexperienced, and makes silly mistakes, explaining that mistake, and suggesting to play with dh7 (or even helper less) to understand the system better might be a good approach. But neither fits all cases. >> NMUing something with a complex, home-built debian/rules is a pain in >> the backside at best. >> > Come on! It's not. Most debian/rules using debhelper (and not CDBS or dh) > looks nearly the same, with very little tweaks. Most dh7 packages look similar enough, yes. Those are the least of one's worries, though. Nor do these fall under the 'complex, home-built debian/rules' category. >> I don't know about you, but for 5 seconds, I'm not going to give up >> convenience. >> > It really depends. If the package is really small, and if it takes 6 > seconds in total > to build, then skipping 5 seconds is a win. If it takes anyway 2 > minutes, then > yes, I don't care about 5 seconds. 5 seconds never matters. Ever. Not even if that 5 seconds is 90% of the build time. It won't stall the buildds, it won't make any difference at all. >> Then again, the beauty of Debian is that people are allowed to tailor >> their packaging to their own liking (as long as it conforms to >> policy... sadly a debian/rules written in SHOOP does not). There's >> arguments for and against both helper-using and helper-less packaging, >> neither is a silver bullet. >> > My point to give arguments about not using dh was *not* to start a troll > thread about what is best practices. It was simply to tell that there > are some > arguments for and against using dh, Agreed, there are arguments for and against dh. There's more for it than against it, though, and if one chooses to use dh, in the vast majority of cases, he shouldn't be discouraged, in my opinion. > For this, Jakub is 100% right. At best, this would be a sponsor > requirement (and for sure, it wont be mine, which is only to not use > CDBS which I don't understand). > > So don't take me wrong. I'm not vouching *against* dh, in some cases I > agree it might be convenient, but just not always, and at the end, > it's more a mater of preferences. We seem to agree then, it's just our preferences lying on other sides of the fence ;) -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tyavboau@luthien.mhp
Re: package with new soname: questions about .symbols and uploading
> But I still want to fix the .symbols file. However, I was not able to > find how I should do it in this case (new packagename). > Should I just generate a new file from scratch (I have not seen > incompatible api changes) or refer to the old version number for > functions which were available before. > Anyway, it's a general concern that I find little advice on how a > symbols file should actually look [1] - whether the one I made > previously was actually valid - so I was actually considering to > perhaps not include a symbols file anymore (better no file than one > which is possibly incorrect). > > So three questions: > 1) should I still have a symbols file? > 2) what are good references for building/maintaining it? > 3) should I recreate it from scratch - or refer to the old version of > the package? While I am no expert on library packaging, I always thought that the main use of the symbol file is to allow building programs that use symbols already present in the old version, to be compiled with the new, and still work with the former. (Eg, if foo@LIBBAR_1.0 is used by a program, and is linked against libbar1 1.2, it would still result in a libbar1 >= 1.0 dependency, since it doesn't use any new symbols) But since there's a SONAME change involved, I see no point in symbol files, as the program will need to depend on the new version, if for nothing else, then for the SONAME. Thus, in this case, I'd drop the symbol file, and use dh_makeshlibs -V instead. I don't think symbol files are of any use for libraries that follow this versioning scheme. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ei1tuqoc@balabit.hu
Re: RFC: git-flow
Hi! Kilian Krause writes: > On Fri, Jul 08, 2011 at 11:34:18AM +0200, Gergely Nagy wrote: >> While I'm not looking for a sponsor for my package, git-flow, I would >> appreciate any comments regarding the packaging, and all ideas for >> improvement. >> >> * Package name: git-flow >> - dget >> http://mentors.debian.net/debian/pool/main/g/git-flow/git-flow_0.4.1-1~preview0.dsc > > seems this one got lost by now. If you still need feedback, please point me > to a valid URL. It got uploaded to unstable, so I deleted it from mentors shortly afterwards. Suggestions are still welcome, though, and the sources can be simply apt-get source'd. ;) -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739hyc7tj@luthien.mhp
Re: Using dh to build >1 binary package with different configure options
Tony Houghton writes: > I'm pretty sure I once read something about how to get a single source > package to build multiple binary packages from the same source with > different configure options. Unfortunately I can't remember what I read > and it didn't apply to dh anyway. Can anyone recommend a guide to doing > this with dh? If you're using short form dh, this would be one way to do it: override_dh_auto_configure: install -d debian/build-gtk2 cd debian/build-gtk2 && ../../configure --with-gtk2 install -d debian/build-gtk3 cd debian/build-gtk3 && ../../configure --with-gtk3 override_dh_auto_build: cd debian/build-gtk2 && make cd debian/build-gtk3 && make override_dh_auto_install: cd debian/build-gtk2 && make install DESTDIR=$(CURDIR)/debian/pkg-gtk2 cd debian/build-gtk3 && make install DESTDIR=$(CURDIR)/debian/pkg-gtk3 And from this point on, it's just standard dh. If it's long-form debhelper, then instead of the overrides, do something similar in your configure, build and install targets. There might be nicer ways to do the same thing, but this is already fairly straightforward, in my opinion. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hb5nqbyr@balabit.hu
Re: Using dh to build >1 binary package with different configure options
Didier Raboud writes: > I'm doing it slightly differently, using the --builddirectory parameter of > dh: Yeah, that's pretty much the same thing, with a bit better style =) > And add rm -rf build-* to override_dh_auto_clean. Right, this part I completely forgot to mention. Thanks! -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3gbq8ef@balabit.hu
Re: Using dh to build >1 binary package with different configure options
Tony Houghton writes: > Yes, I'm using the short form. > > Thanks to everyone who showed me how to do this. But I'd also appreciate > some feedback on the question of whether it's sensible to provide two > versions of roxterm this way or should I pick one version and stick to a > simple rules file? I'd probably provide both. A rules file doing two configure && make && make install runs isn't all that complicated. The -gtk2 version can always be dropped later, either when upstream stops supporting it, or when the number of users drops to a level not worth the effort of maintaining two versions. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ty9mpzll@balabit.hu
Re: Downloading of test data
Asheesh Laroia writes: > Excerpts from Antonio Valentino's message of Sat Aug 13 07:09:57 -0400 2011: >> Hi mentors, >> I have a package (pyepr) that provides a small python extension written >> in cython. >> The upstream source includes a test suite that needs some data to be >> downloaded from the internet (398K) using wget. >> Note that data are only used for testing, they are not installed. > > It's not particularly sane to download data at package build time. You > could package that data separately, and then build-depend on the test > data. Another option is to package up the test data as a pyepr_$version.orig-testdata.tar.gz, and with a 3.0 source format, that'll be part of the source package, will get unpacked by dpkg-source into pyepr-$version/testdata/ and so on and so forth. I'd recommend doing this instead of introducing a separate package to build-depend on. Doing this also has an advantage over repacking the upstream sources to include the test data: you don't need to repack. (For an example of a very simple package that uses multiple upstream tarballs, see git-flow) -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrehv86e@luthien.mhp
Re: dh-autoreconf/autotools-dev questions
Oohara Yuuma writes: > I am packaging a software which uses autoconf and automake. I will > regenerate all autotool files with dh-autoreconf. > * The upstream tarball contains auto-generated files. Do I have to > save these files somewhere before calling dh_autoreconf and restore > them in the clean target, or is it enough to remove auto-generated > files in the clean target so that they are regenerated again > in the build target? Just call dh_autoreconf, nothing else to do. It takes care of restoring the original state, whatever that may have been. When using dh_autoreconf, it will _always_ regenerate the appropriate files, so you don't need to prepare the tree for it. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739h1o30h@balabit.hu
Re: dh-autoreconf/autotools-dev questions
Jakub Wilk writes: > * Gergely Nagy , 2011-08-16, 16:16: >>>I am packaging a software which uses autoconf and automake. I will >>>regenerate all autotool files with dh-autoreconf. >>>* The upstream tarball contains auto-generated files. Do I have to >>> save these files somewhere before calling dh_autoreconf and restore >>> them in the clean target, or is it enough to remove auto-generated >>> files in the clean target so that they are regenerated again in the >>> build target? >> >>Just call dh_autoreconf, nothing else to do. > > Err... from the manual pages: > > dh_autoreconf - Call autoreconf -f -i and keep track of the changed files > dh_autoreconf_clean - Clean all changes made by dh_autoreconf dh $@ --with autoreconf does the right thing. But you're correct, one does need to call dh_autoreconf_clean in the clean target too. But apart from this two (which I erroneously shortened to "call dh_autoreconf"), there's no other preparation neccessary. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ty9hmm1a@balabit.hu
Re: edbrowse
Jean-Philippe MENGUAL writes: > I'm not sure of release number, but I put -2 as -1 was > the NMU and I didn't want to remove this. Since the NMU never hit the archive, and -1 is not an NMU version number anyway, I'd merge the two changelogs into one. Also, looking at the changelog, I see this line: * New upstream version (3.4.7). Closes: #598162, #631027, #506613 To me, this tells that all three of that bugs were reports that a new upstream version exists, while they're not. The first is, but the second is an FTBFS, and the third is a problem with edbrowse failing to work with linksys web uis. I'd reword it a bit like this: * New upstream version (Closes: #598162). * [describe how this was fixed (Closes: #631027). * Now works with Linksys routers' UIs again (Closes: #506613) This has a few advantages, in my opinion: - It makes it obvious which bug is about what, and how they were fixed, instead of the changelog viewer having to look up each issue in the BTS and figure out what they're about. For someone who likes to see a _changelog_, that's a huge plus. - It doesn't mention the upstream version twice (it's already in the package version). - I like it better that way! Furthermore, I couldn't figure out how #631027 was eventually fixed. Perhaps because I'm not familiar with the packaging itself, but neither the changelog, nor debian/control tells me much about it. And while I'm here, a couple of other cosmetic nitpickings: - In override_dh_auto_clean, if you use rm -f, there's no need for the - prefix: the rm will never fail, thus, it is pointless to ignore its exit status. - Wouldn't it be better to simply patch the upstream manpage instead of tweaking it in debian/rules? - Wouldn't exporting CFLAGS="..." LIBS="..." JSLIB=".." STATICLIBS="..." LFLAGS=".." make the rules file simpler? With patching the upstream manpage and exporting instead of overriding, you could get rid of all the overrides, pretty much. Another option would be to modify the upstream Makefile - it is already patched anyway to add a clean target. - dh_installchangelog should recognise and install CHANGES as an upstream changelog, even without the override - Why is debian/compat 5 when you're using dh (ie, debhelper >= 7; with correct build-depends)? These are all minor improvements, but I felt like sharing since I'm poking around in the package anyway. That's all I could find with a quick glance.. Oh, and if you insist adding me to Uploaders (not neccessary, I believe, I don't think edbrowse would need two, and I'm perfectly happy being Just an Ordinary User of it :), please use alger...@madhouse-project.org. Thanks for taking care of the package! -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vqqojwm@balabit.hu
Re: RFS: i-news - GTK-based RSS Ticker
Emmanuel Thomas-Maurin writes: > I am looking for a sponsor for my package "i-news". While I'm not a DD at the moment, so couldn't sponsor even if I wanted to, but i-news - as already mentioned on -devel@ - is uncomfortably similar to inews (which is a pure virtual package at the moment, but still). news-rss-ticker was suggested earlier, that sounds like a good name to me, certainly less confusing and generic than i-news. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3fxlrq4@balabit.hu
Re: RFS: i-news - GTK-based RSS Ticker
Emmanuel Thomas-Maurin writes: > On 08/22/2011 11:29 AM, Gergely Nagy wrote: >> While I'm not a DD at the moment, so couldn't sponsor even if I wanted >> to, but i-news - as already mentioned on -devel@ - is uncomfortably >> similar to inews (which is a pure virtual package at the moment, but >> still). >> >> news-rss-ticker was suggested earlier, that sounds like a good name to >> me, certainly less confusing and generic than i-news. > > Yes but (IMHO) very long so not easy to remember nor to type. Since it's a GUI app, more often than not, it will be run from a menu, where the binary's name doesn't matter. I do not believe it would be typed more than once or twice. But even then, I'd suggest something other than i-news. Like "grssnews" or somesuch. Or just drop "news" altogether and come up with something creative like quite a few of the gnome stuff did (totem, cheese, etc). -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vqllnzi@balabit.hu
Re: RFS: pygtkplot
Gabriele writes: > I'm having some hard times correcting these two errors > > E: pygtkplot: changelog-file-not-compressed changelog > E: pygtkplot: manpage-not-compressed usr/share/man/man1/pygtkplot.1 > > Must I compress the file by hand? If i compress the changelog then debuild > says that it cannot find changelog. If I keep a copy of changelog along with > changelog.gz and use "dh_installchangelogs debian/changelog.gz" I get > > E: pygtkplot: changelog-file-not-compressed changelog > E: pygtkplot: changelog-file-not-compressed changelog.Debian > > So how am I supposedd to gzip -9 these files? dh_compress should take care of that. I would strongly suggest either converting to short-form dh, or - which would be even better - reading up on the various dh_* tools and what they do. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874o19ljo6@balabit.hu
Re: RFS: pygtkplot
Hi! A few comments and questions, if I may: * Why is the package packaged as Debian native, when it is definitely not Debian specific? * Why does it have an ubuntu distribution in debian/changelog, and an Ubuntu Section in debian/control, if it is meant to be uploaded to Debian? * Where is the debian/copyright file? * Why is there a debian/postinst which just exists with 0? * debian/rules looks like a horrible mess to me, but that might just be me. I prefer to remove useless things that the package building does not need (like a configure-stamp target when there is nothing done in it, and is not a required target) * lintian displays numerous errors, including, but not limited to: - The debian diff containing .bzr - no debian/compat (thus forcing debhelper to use the long obsolete compat level 1) - no debian/source/format - ancient standards version - changelog file still not compressed And so on, and so forth. There's a lot to be done still before the package is in a good enough shape. Running lintian and rigourously fixing everything it reports is a good first step. Then looking at the result and making it pretty (by removing junk that were left over from whatever source you used to base your packaging on) would be a very useful second step, in my opinion. Most - if not all - of the problems I outlined above are caught by lintian aswell, even older versions (tested with Ubuntu Lucid, as that's the newest thing I have at work at the moment). Lintian also provides very good hints how to go about fixing the issues it found. Take those to heart, they'll make the package a lot better, and they'll help you understand Debian packaging better too! -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjotjxil@balabit.hu
Re: RFS: i-news - GTK-based RSS Ticker
Emmanuel Thomas-Maurin writes: > On 08/22/2011 12:49 PM, Gergely Nagy wrote: >> Emmanuel Thomas-Maurin writes: >> >>> On 08/22/2011 11:29 AM, Gergely Nagy wrote: >>>> While I'm not a DD at the moment, so couldn't sponsor even if I wanted >>>> to, but i-news - as already mentioned on -devel@ - is uncomfortably >>>> similar to inews (which is a pure virtual package at the moment, but >>>> still). >>>> >>>> news-rss-ticker was suggested earlier, that sounds like a good name to >>>> me, certainly less confusing and generic than i-news. >>> >>> Yes but (IMHO) very long so not easy to remember nor to type. >> >> Since it's a GUI app, more often than not, it will be run from a menu, >> where the binary's name doesn't matter. I do not believe it would be >> typed more than once or twice. >> >> But even then, I'd suggest something other than i-news. Like "grssnews" >> or somesuch. Or just drop "news" altogether and come up with something >> creative like quite a few of the gnome stuff did (totem, cheese, etc). > > tickr ? apt-cache search returns nothing, and sounds good to me anyway. I'm much happier now, thanks! :] And while I can't sponsor the package (not a DD myself, either), I had a quick look at it (at least, on the latest version you posted here): * In debian/copyright, the paragraph separator dots are unindented - I'm not sure whether that's acceptable or not, but it looks a bit awkward. * debian/changelog is executable for some reason (o.O) * You don't need to list ChangeLog in debian/docs, dh_installchangelogs will install it as the upstream changelog by default. But.. do you really want to do that? Upstream ChangeLog is zero-length, and thus not really useful at this time. * And as someone already mentioned, there's common-install-indep:: in debian/rules which I believe is a cdbs-ism, and does not have any effect in the current packaging. Pretty minor stuff, but thought I'll have a look and contribute something else than nagging for a different package name O:) -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obzhe3ss@luthien.mhp
Re: RFS: pygtkplot
Gabriele writes: > I don't see the problem. I think I have already solved all those issues. In > fact: Hrm. I might have downloaded an earlier version then, I guess. Sorry for the noise then! On the other hand, I had a quick look at your updted 0.1-1 package, and while it does look a thousand times better, there's still an issue that I think can be solved better: You're installing the desktop file and the associated icon in the postinst, why? It really should be shipped in the .deb. Not to mention that it's the postinst that tries to remove it, which will not work, since postinst is not run when removing the package. This way, removing your package would leave cruft on the system. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4a5e3cx@luthien.mhp
Re: ITP: i-news (2nd request) -- GTK-based highly graphically-configurable RSS Ticker - Bug#638999
Emmanuel Thomas-Maurin writes: > Dear mentors, > > Thank you for your answers. Well, until/unless I find a better > alternative name, I will keep the current one at the moment. What was wrong with 'tickr' ? -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obzbz28q@luthien.mhp
Re: ITP: i-news (2nd request) -- GTK-based highly graphically-configurable RSS Ticker - Bug#638999
Emmanuel Thomas-Maurin writes: > On 08/27/2011 10:29 AM, Gergely Nagy wrote: >> Emmanuel Thomas-Maurin writes: >> >>> Dear mentors, >>> >>> Thank you for your answers. Well, until/unless I find a better >>> alternative name, I will keep the current one at the moment. >> >> What was wrong with 'tickr' ? >> > > Nothing at all. I just didn't get feedback. If you think 'tickr' is a > better choice and nobody else has objections, I will use it instead. I think it is a lot better, yes. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k49zz1pj@luthien.mhp
mentors.dn package removal request
Hi! The Q&A on mentors.d.n wasn't quite clear on whom I shall contact in cases like this, but figured there's no harm asking on -mentors@ either: Someone, somewhen uploaded a dpatch 2.0.31-1[1] package to mentors.d.n, before it became debexpo. That version is well.. lets just say, obsolete. However, it still shows up on the dpatch PTS page[2], which is kind of annoying. I've tried emailing the uploader at the end of July, but haven't heard back yet, so I'm asking here now: is there any way to remove that version from mentors.d.n, so that the PTS stops suggesting I sponsor it? Thanks in advance! [1]: http://mentors.debian.net/package/dpatch [2]: http://packages.qa.debian.org/d/dpatch.html -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obz9b8fw@luthien.mhp
Re: RFS: cvsconnect (QA upload)
Jeroen Schot writes: > On Tue, Aug 30, 2011 at 01:07:28PM +0200, Sven Hoexter wrote: >> On Tue, Aug 30, 2011 at 12:27:35PM +0200, Jeroen Schot wrote: >> > I: cvsconnect source: debian-watch-file-is-missing >> > >> > This is because the upstream source is no longer available. >> >> Well then kill the Homepage field from debian/control aswell and >> maybe add to the copyright field that this page is no longer >> available. > > Yes, that makes sense. What is the best way to add this to > (DEP5) debian/copyright? My suggestion would be: > [...] > Source: http://cvs.m17n.org/~akr/cvssuck/download.html (2011-08-30: dead) > > And in debian/watch: > # 2011-08-30: Upstream sources are no longer available. A CVS > # repository is still accessible at > # http://cvs.m17n.org/viewcvs/cvs/cvsconnect/ > > Or should I (also) mention the repo in debian/copyright? I'd mention the CVS repo in debian/copyright. A dead link, however historical it may be, is fairly useless. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrdvktb6@balabit.hu
Re: RFS: cvsconnect (QA upload) [new package]
Jeroen Schot writes: > On Tue, Aug 30, 2011 at 07:56:16PM +0200, Gergely Nagy wrote: >> Jeroen Schot writes: >> > On Tue, Aug 30, 2011 at 01:07:28PM +0200, Sven Hoexter wrote: >> I'd mention the CVS repo in debian/copyright. A dead link, however >> historical it may be, is fairly useless. > > I have to disagree with you here. The point of mentioning the source > of a package in debian/copyright is to document it's origin. The > original source URL can still be useful in combination with services > such as The Wayback Machine[1]. In that case, I would've suggested a link to the wayback machine, so that the link is something that exists at the time of upload. Not something that's known to be gone, and can only be unearthed via the wayback machine or similar services. In my interpretation, the Source field should document where the sources can be obtained from at the time of packaging, not some other place that disappeared years ago, even if that was the original source. Or, since one can include free-form explanation in the Source field aswell, it can be mentioned that CVS is available, but it used to be here-and-here. That way you document both the original source, and a place where it's still available from. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ippehr3d@balabit.hu
Re: RFS: gentoo (New upstream version: package already in Debian).
Marc Haber writes: > On Tue, Sep 13, 2011 at 04:17:12PM +0200, Innocent De Marchi wrote: >> I am looking for a sponsor for my package "gentoo". >> >> * Package name: gentoo >>Version : 0.19.11-1 >>Upstream Author : Emil Brink >> * URL : http://www.obsession.se/gentoo/ >> * License : GPL-2+ >>Section : x11 >> >> It builds those binary packages: >> >> gentoo - Fully GUI-configurable, two-pane X file manager > > I would strongly suggest choosing a different name, due to the > identically named Linux distribution. It's not a new package, and has been in Debian for quite some time, since 1998 to be exact, 4 years before the distribution of the same name appeared. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrdcjxp1@luthien.mhp
Re: RFS: glipper
Jose Ernesto Davila Pantoja writes: > I am looking for a sponsor for my package "glipper". > > * Package name: glipper > Version : 2.1-1 > Upstream Author : Laszlo Pandy > * URL : https://edge.launchpad.net/glipper > * License : GNU GPL v2 > Section : utils A few nitpickings from the sideline, if you don't mind (IANADD applies, and so on and so forth): * It would perhaps be a good idea to add a few more headers to debian/patches/01_license-headers.patch, like fill in the Author field, or add "Origin: Upstream CVS" or somesuch, to make it even clearer where it comes from. * debian/copyright has this text: "This package was debianized by Neil Williams on Thu, 14 Sep 2006 11:40:26 +0100. The current Debian maintainer is Davide truffa " This is obviously not the case, as the package is currently orphaned, and the changelog closes the appropriate bug too, so the current maintainer should be updated (by mentioning all former maintainers too, preferably). * debian/glipper.NEWS Why do you think that upstream NEWS (at least, that's what it seems to me) belong to debian/glipper.NEWS? Such dependency changes, I believe, are not interesting to end users, the package manager does the right thing with those. Unless this breaks existing functionality, or has other unexpected side-effects the users should be aware of, I do not think it's worthwile to bother people who upgrade the package with it. And even if it has unexpected side-effects, then those should be mentioned, not the dependency change. For a mere user, that means nothing. * debian/rules Very minor nitpicking, but... it's not a sample debian/rules anymore ;) Aaand that's all the nitpickings I could find with a quick look. Quite little, and most of it cosmetic. Good luck with finding a sponsor, and hope that my comments will be useful! -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5xj6ibi@luthien.mhp
Re: flashcache - call for resolution / seeking for a mentor
(Note: I didn't have a look at either package; I merely read the preceding discussion in the bug log) >From what I've read so far, my impression is that this is not a technical issue, but more a social / team-work... misunderstanding, perhaps. So read my comments below, with these things in mind. onlyjob writes: > So perhaps like many people before me I picked a software which I need > as a matter of urgency and packaged it for Debian > only to find unhappy maintainer who was doing similar work but > (arguably) didn't yet made as much progress. This is called duplication of effort, and while the ITP might not have been kept up to date, progress was being made. How much, I will not judge, as I'm not qualified to do so. Nevertheless, when one wants to package something, the first thing to do, in order to make it smooth and useful, is to see if there's anyone working on it already, and if so, how far they've got. This way, you don't have to start from scratch, and you're not stepping on anyone's toes, either. If all goes well, and most often it does, one can speed up the packaging process by joining the effort, instead of starting a competing one. > My bad, I should have find him and coordinate the effort but as a > newcomer I'm lacking some understanding of how things suppose to be > done > and hence I missed the chance to reduce our efforts. That happens at times, indeed. But not to worry! It's never too late to join forces, and get the best of both efforts (preferably without the bugs of either :P). > At this point my package is ready for review and as I'm been told, I'm > neither suppose to close someone else's ITP nor submit a duplicate > one. That is mostly correct. If there's someone already working on a package, it's generally not recommended to "hijack" and invalidate his efforts. The best practice is to strive for merging both works. Arno offered you the opportunity to do so, and I believe that's the best path to follow, regardless of what the technical state of each of your packages are. He started the work, he filed the ITP, it's pretty much his package at this time. And as you wouldn't want to upload a package managed by someone else, because it happens to have a bug or shortcoming that bothers you, the same treatment should be applied to ITPs aswell. > No doubts in the end there should be only one package left. Indeed. > It is indeed possible that something can be merged between those two packages. > (As a matter of fact, maintainer who first logged an ITP already > integrated some pieces of my work into his unfinished package) That's the way forward: merge the good parts from both efforts. > By the maintainer of the unfinished package (Arno Töll) I have been > told that my only option is to merge with him but not the other way. Does it really matter? In the end, the result should be the same either way: a package with the best parts of both. The question, I believe, is more about why Arno should be doing the merge, and not you. And the reason for that is simple: he started first. That you might have gotten further on your own, doesn't change the fact, that Arno was and still is working on packaging flashcache, and as such, one's not supposed to hijack his package. > However there are a few reasons why I don't like the idea of merging > with unfinished package at the moment: > > * Because I'm using the software I packaged, I will have to > maintain a working package until a suitable alternative will be > available in Debian. That's unfortunate, but if you start working with Arno, helping him in the merging effort instead of complaining and arguing against it, it will go much faster. And in the future, when you wish to contribute, you look for previous, ongoing efforts first, and try to join in, instead of going on your own, then it will be even easier and faster. > * Because it might be feasible to merge the other way and having > my package a primary one. (In this case there might be less work to > do) Since Arno is the owner of the ITP, and by common practice, the maintainer, it's his decision. > * Because I'm using fossil http://fossil-scm.org/ (git may be an > overkill just for several files) and merging to git will require a > substantial effort for me. The other way around would require similar efforts. Arno is willing to merge from you, and already merged a few things from your packaging that his missed, as far as I remember the bug log. For this reason, I support his decision to merge your packaging into his, and not the other way around: because he proved this works, and can bring the packaging effort forward. > * Because it seems wrong to made a decision about who should > merge with who merely by the ITP announcement date and not by the > technical examination. By that reasoning, it's not acceptable to start a competing packaging effort, when one is already in progress, because at the time you started, you had nothing, and Arno had v
