Bug#950718: RFS: depthcharge-tools/0.3.1-1 [ITP] -- Tools for ChromeOS firmware/bootloader integration
Hey,
Alper Nebi Yasak (2020-03-03):
> I've uploaded a new version of depthcharge-tools to mentors.debian.net.
>
> General changes:
> - New upstream release v0.3.1, set version to 0.3.1-1
> - Use *.{service,init} symlinks to install systemd/init.d files
> - Export build-configuration variables in debian/rules
> - Change GPL-2.0+ to GPL-2+ in debian/copyright
>
> Installer changes:
> - Temporarily disable our initramfs hook if it already exists
> - Fix warning on nonexistent /proc/device-tree/model file
> - Add a template to override machine detection
> - Clarify initramfs compression template (to match my patch at #950086)
>
> Also, it's now possible to test debian-installer integration in a QEMU
> virtual machine with a kernel cmdline like [0], by generating a d-i image
> with localudebs including depthcharge-support-installer and partman-cros,
> and installing both deb packages from this to the target before the
> installer step is run.
>
> [0] console=tty0 priority=low live-installer/enable=false
> partman-cros/enable=true
> depthcharge-support-installer/machine="Google Kevin"
partman-* is of course fine for udebs shipping partman stuff, but
depthcharge-support-installer strikes me as something that could be
named depthcharge-support-udeb, or maybe just depthcharge-udeb?
(Unfortunately I don't have any time to review this more thoroughly to
figure out exactly which part does what etc., but I thought sending
this quick note wouldn't hurt.)
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
Bug#845311: Bug#843775: jessie-pu: package mdadm/3.3.2-5+deb8u2
(dropping debian-boot@, adding 845311@) Hi Jens, Jens Sauer (2016-11-22): > Thank you for reviewing this package. It was my first time doing this, > I hope everything is alright. It looks to me everything was right on the first attempt. :) > I opened a RFS to find a sponsor for the upload: > https://bugs.debian.org/845311 According to my inbox it's possible to perform source-only uploads for jessie-proposed-updates (at least it worked for src:debian-installer), so I've just sponsored your package this way. Please close the RFS if it gets queued as expected; otherwise I'll re-sponsor the package with a binary build included. KiBi. signature.asc Description: Digital signature
Re: Bug#685042: ITP: libpam-ssh -- Authenticate using SSH keys
Antti-Juhani Kaijanaho (16/08/2012): > There is no ambiguity. The package is present in unstable and thus is not > "removed" in the sense that word is commonly used without qualifiers. (The > proper way to describe what happened to the package is "removed from testing" > - > a release engineering action that doesn't imply any change in a package's > maintainership.) $ ssh release.debian.org dak ls libpam-ssh libpam-ssh |1.92-14 |stable | source, amd64, armel, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc $ rmadison libpam-ssh libpam-ssh | 1.92-14 | squeeze | source, amd64, armel, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc $ wget http://ftp-master.debian.org/removals-2011.txt -q -O - | grep libpam-ssh -B 10 -A 1 --- Reason --- ROM; unmaintained, somewhat obsolete -- Also closing bug(s): 381023 539727 610827 633152 Also closing WNPP bug(s): = = [Date: Fri, 02 Dec 2011 16:51:17 +] [ftpmaster: Alexander Reichle-Schmehl] Removed the following packages from unstable: libpam-ssh |1.92-14 | source libpam-ssh | 1.92-14+b1 | amd64, armel, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc Closed bugs: 650644 Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#669717: PLEASE DO NOT SPONSOR libextractor/1:0.6.3-4 [ITA]
Bertrand Marc (21/04/2012): > Dear mentors, > > I am looking for a sponsor for my package "libextractor" Please don't sponsor this package. It's currently involved in the exiv2 transition, and it's painful enough already. Please make sure to wait for an ACK from the release team to #672117. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: libconfig (requires transition)
Hi Jonathan, Jonathan McCrohan (26/01/2012): > apt-rdepends lists the following reverse dependencies: > > libconfig8 > Reverse Depends: guestfish (1:1.14.8-3) > Reverse Depends: guestmount (1:1.14.8-3) > Reverse Depends: libconfig8-dev (= 1.3.2-2) > Reverse Depends: libguestfs-tools (1:1.14.8-3) > Reverse Depends: lldpad (0.9.43+git20111215.c0498b-1) > Reverse Depends: qwo (0.5-2) > Reverse Depends: sitplus (1.0.1-2) > Reverse Depends: yubiserver (0.1-1) > > libconfig++8 > Reverse Depends: flush (0.9.11-2) > Reverse Depends: ldc (0.9.1+hg1634-1) > Reverse Depends: libconfig++8-dev (= 1.3.2-2) > Reverse Depends: libffado2 (2.0.99+svn1995-3) do these only need a rebuild (binNMU) to get properly linked against the new binaries, or do they also need source changes? If some of them fail to build (due to the new libconfig, or due to other reasons), please report bugs and mention them in your reply. Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#608220: RFS: hugs98 (NMU, RC bugfix)
Felix Geyer (17/01/2011): > I didn't realize that you were talking about the patch itself. > Attaching it now. Thanks, sponsored. Thanks for spotting I failed to get it fixed in the first place, too. KiBi. signature.asc Description: Digital signature
Re: RFS: xserver-xorg-video-qxl
Hello Paul.
Paul Wise (05/05/2010):
> Should XSF packages have the team address in Maintainer?
Yes. That's the kind of stuff I'm going to detail later on while
reviewing this package.
> Any idea why upstream installs a .la file for the driver? Surely that
> isn't needed. Do the RedHat/Fedora install it? This generates a
> warning:
>
> dh_install: usr/lib/xorg/modules/drivers/qxl_drv.la exists in
> debian/tmp but is not installed to anywhere
That's the case for all Xorg drivers AFAICT. At least so says my
grepping my binary build logs after the few uploads performed lately.
> dpkg-gencontrol: warning: package xserver-xorg-video-qxl: unused
> substitution variable ${xinpdriver:Provides}
Expected. That's not an input driver, and the XSF build system (xsfbs)
is common to all drivers. See input drivers, ${xviddriver:Provides} is
unused there.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: RFS: xserver-xorg-video-qxl
Liang Guo (04/05/2010): > Hi! Hello! > Have you checked my package ? Any sugestion ? I've been quite busy lately (see the various X-related uploads), but I haven't forgotten about your package. I might come to it in a few days, if everything goes right. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: xserver-xorg-video-qxl
Hi! (Keeping you Cc'd for now, I'm not sure which lists you're subscribed to.) Liang Guo (21/04/2010): > - dget http://mentors.debian.net/debian/pool/main/x/xserver-xorg-video- > qxl/xserver-xorg-video-qxl_0.0.12-1.dsc I had a *very* quick look, and it didn't sound too bad. I'd have to double-check it of course, but it'd be nice if there were some git branches available somewhere, that'd ease reviewing. Maybe you could start by publishing your branches on alioth's collab-maint or as public user git repository there? Mraw, KiBi. signature.asc Description: Digital signature
Re: A meager copyright. Remotely acceptable?
Mats Erik Andersson (01/04/2010): > I probably prematurely responded to an RFP for 'oftpd', an FTP > server for only anonymous access, and only giving read access. Another questions comes to mind: do we need this package? I'd hope several of which we already have can be trivially configured in this way? Maybe opening wishlist (documentation) bugs with appropriate procedure to do so would satisfy the original need? Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: coffeescript
Christoph Egger (01/04/2010): > Do you think it's sensible to have that packaged in debian (and > it's stable releases)? That's a question (but the other one can be replied to with a dummy RC bug prevening migration until it's in shape for a stable release, should the instability be only temporary). Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: windowlab (updated package)
Hi, Christoph Egger (28/03/2010): > > I get the impression that S. Engelsman took the function > > interruptibleXNextEvent() from Mark J. Kilgard's contribution to > > Blender, and then Engelsman wrote the replacing call instead of > > XNextEvent(). > > So this patch is part of Debian's blender package? might be, but as upstream code, not as a Debian-specific patch. FWIW and AFAICT, Blender code is usually just GPL'd and copyright gets assigned to the Blender Foundation (see copyright notices, with contributors listed thereafter). Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: grub2-splashimages (updated package; 2nd try) [done]
Krzysztof Burghardt (26/03/2010): > AFAIR tga was supported earliest. OK, thanks. Upload on its way. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: grub2-splashimages (updated package; 2nd try)
Krzysztof Burghardt (24/03/2010): > The upload would fix these bugs: 509778, 534210, 565872 Hi, I'm wondering why you're pointing to tga files, given that default images are xpm.gz ones? I don't mind that much, just asking. ;) Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: grub2-splashimages (updated package)
Krzysztof Burghardt (20/03/2010): > Dear mentors, Hi, > I am looking for a sponsor for the new version 1.0.1 > of my package "grub2-splashimages". > > It builds these binary packages: > grub2-splashimages - a collection of great GRUB2 splashimages > > The package appears to be lintian clean. > > The upload would fix these bugs: 509778, 534210, 565872 that sounds like something I've been looking for a few days ago. I'll try and have a look soonish. Reminder-ping welcome in 2 days if you didn't hear from me. Mraw, KiBi. signature.asc Description: Digital signature
Re: lintian 2.3.3 warning: native-package-with-dash-version
Jari Aalto (02/03/2010): > [Please keep CC] [Done.] > Can anyone see any obvious errror, that eludes my eyes? Files > available at: $ cat dyndns-2010.0301+gitdd160bd/debian/source/format 3.0 (native) (Enjoy 3.0…) Mraw, KiBi. signature.asc Description: Digital signature
Re: create orig.tar.gz
Jaromír Mikeš (28/02/2010): > Exist some way to create _.orig.tar.gz from > -.tar.gz without complete debianization? And make > md5 for both files identical? Sure: mv does that. :) Mraw, KiBi. signature.asc Description: Digital signature
Re: CHowning files - or not?
Dominik George (26/02/2010): > OK, as it is done in postinst, there does not seem to be a > difference to my current chown setup. dpkg-statoverride will make > sure that the permissions are set everytiem the file is > re-installed, but chown in postinst will as well ... And will nuke possible local changes? Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: scim-array [done]
Cyril Brulebois (07/01/2010): > I might take a look later today. IRC ping (KiBi) or private mail > ping appreciated. Uploaded, thanks. Let's hope I didn't miss anything. First 3.0 package I'm uploading. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: scim-array
Wen-Yen Chuang (01/01/2010): > The upload would fix 1 minor bug which is listed below. Hi, I might take a look later today. IRC ping (KiBi) or private mail ping appreciated. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: s5 (more DFSG free, refreshed Debian packaging)
Peter Pentchev (07/01/2010): > Dear mentors, Hi, > I would be glad if someone uploaded this package for me. if nobody beats me to it, I could have a look tonight (UTC+1). IRC ping (KiBi) or private mail ping appreciated, I only read -mentors from time to time these days. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: gmfsk (NMU, fixes ftbfs)
Christoph Egger (08/12/2009):
> I'm rather tempted to sponsor your fixed package.
Good call. ;)
As for config.{guess,sub}, no need to conditionalize the
'cp'. autotools-dev is in Build-Depends and if it'd stop shipping
those files, or in different locations, you want to know about this
through an FTBFS report rather than silently using ancient config.*
files.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: RFS: pgpool2 (updated package)
Rodolphe Quiédeville (02/12/2009): > http://mentors.debian.net/debian/pool/main/p/pgpool2/pgpool2_2.2.5-2.dsc For -mentors@'s record, I reviewed this package and made a few remarks, being integrated/worked on. Please hold on any upload. Mraw, KiBi. signature.asc Description: Digital signature
Re: Buildd failed: C compiler cannot create executables
Felipe Sateler (27/11/2009): > Which would be...? That KiBi should have checked facts better when reporting the FTBFS bug. The B-D was indeed there. Lalala. :) (Sorry for the lag, I only open -mentors@ from time to time.) Mraw, KiBi. signature.asc Description: Digital signature
Re: Graphviz 2.24.0
David Claughton (28/11/2009): > So, rather than jumping straight in with a ITA, I wonder if I could > ask someone to take a look at what I've done and see if it looks OK? > If it's not too far off the mark, I'd be interested in maintaining > it. OTOH if the response is "go away and come back when you know > what you're doing" then fair enough :-) Even without jumping to an ITA, you could mention your possible interest in the O: bug (#536245), and this thread. This might avoid duplicated work. (Just passing by…) Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: mppenc (NMU, fixes ftbfs)
(Getting rid of all Cc's…) Cristian Greco (26/11/2009): > Please file a bug against the pseudo-package ftp.debian.org > requesting mppenc to be removed from the archive, then. It'd be nice to update #540131 accordingly, I almost sponsored the source package linked there. Sounded like nice work, by the way. ;) And when replying to a bug, please Cc the submitter, who won't see your reply otherwise (unless having subscribed to the bug in the meanwhile). Mraw, KiBi. signature.asc Description: Digital signature
Re: linux-any arch
Benoit Mortier (21/11/2009): > So my question is can we use linux-any today or do we have to fix > the problem an other way ? Keep “Architecture: any” for now, possibly FTBFS very early when not on a Linux architecture (you could use a check on DEB_HOST_ARCH_OS in debian/rules), and get your package added to P-a-s[1]. 1. http://wiki.debian.org/PackagesArchSpecific Mraw, KiBi. signature.asc Description: Digital signature
Re: Buildd failed: C compiler cannot create executables
Joachim Wiedorn (27/11/2009): > thanks for this informations! Nice to see you noticed the FTBFS yourself. I opened a bug anyway (before opening my =debian-mentors/ folder). :) Mraw, KiBi. signature.asc Description: Digital signature
Re: Buildd failed: C compiler cannot create executables
Felipe Sateler (26/11/2009): > Your package build-depends on ccache, and it actively enforces it in > the debian/rules file. Why is that? > > I would be willing to bet money that the problem is that buildd's > have no (writable) home directory, so ccache fails. Drop the ccache > stuff, or if it _absolutely_ necessary, setup a bogus $HOME so that > ccache can work in the buildds. I shall collect your money. Next time, check the facts. Mraw, KiBi. signature.asc Description: Digital signature
Re: QA uploadable packages for GNU/kFreeBSD
Cyril Brulebois (28/08/2009): > > > #322207 audiooss: FTBFS on GNU/kFreeBSD > > I think that one is mostly OK, but I wanted to double-check > something too. Uploading. Also, people wanting to work on those packages may want to join #debian-kbsd (OFTC) to coordinate and avoid double-work. Mraw, KiBi. signature.asc Description: Digital signature
Re: QA uploadable packages for GNU/kFreeBSD
Sandro Tosi (28/08/2009): > On Fri, Aug 28, 2009 at 14:19, Cyril Brulebois wrote: > > Sandro Tosi (28/08/2009): > >> Since everyone can do QA uploads (it's not only the QA team ;) I > >> think this is a perfect task for any perspective maintainer to do > >> some packaging job. I'm adding mentors in the loop (quiting your > >> email in toto), > > > > (What did you drink?) (Petr reads -bsd@ anyway.) > > s/quiting/quoting/ anyhow > > The target is Petr (yes, directly) and mentors (to look for packagers, > hence the full quote) > > Hope this clarify, if not be specific. There is no need to be > sarcastic all the times. quiting + toto made me smile, sorry for being amused. Mraw, KiBi. signature.asc Description: Digital signature
Re: QA uploadable packages for GNU/kFreeBSD
Sandro Tosi (28/08/2009): > Hi Petr, > thanks for your email. (For those wondering, I had it privately some days ago, but the reply I was writing got lost.) > Since everyone can do QA uploads (it's not only the QA team ;) I > think this is a perfect task for any perspective maintainer to do > some packaging job. I'm adding mentors in the loop (quiting your > email in toto), (What did you drink?) (Petr reads -bsd@ anyway.) > so that maybe some guy there wants to prepare the upload and ask for > sponsorship (I'd say here and on -bsd). Please don't forget -bsd@, see below. A test build on one kfreebsd-* arch would be nice, no need to upload to fix an FTBFS and get another build failure. > > #379778 fte: FTBFS on GNU/kFreeBSD (due to unsatisfied Build-Depends on > > libgpmg1-dev) Without looking back to the packages, I seem to recall that: this patch was quite intrusive and would need double-checking. > > #542592 libvncserver: FTBFS on GNU/kFreeBSD ( "-s" have to passed to > > debhelper) This doesn't work. dh gets -a + -s and no matter in which order, that fails. > > #322207 audiooss: FTBFS on GNU/kFreeBSD I think that one is mostly OK, but I wanted to double-check something too. > > - orphaned: Didn't look at those yet. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: jabberd14 (updated package) (fix a FTBFS)
Miguel Landaeta (18/08/2009): > I am looking for a sponsor for the new version 1.6.1.1-3 of > package jabberd14. The upload would fix this bug: 542131. Hi, please keep the submitter Cc'd when replying to some bug, or you're not going to receive any feedback, except in rare cases. (And I'd have sponsored you right away. ;)) Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: anyremote (updated package)
Juan Angulo Moreno (21/01/2009): > http://mentors.debian.net/debian/pool/main/a/anyremote/anyremote_4.15-1.dsc Here we go, based on the source package only: - debian/anyremote-doc.docs: + Extra newline (cosmetic, doesn't hurt) - debian/control: + I don't think anyremote-doc should depend on anyremote. One can browse its documentation without having the anyremote binary installed, no? + Both long descriptions could be rewrapped (see e.g. 2 lines that are ~ 20-character wide). + You could use a slightly different long description for anyremote-doc, saying it contains documentation. - debian/copyright: + See the source diff, the author now writes his full first name, I'd suggest you do the same there. + “Copyright (C)” is OK, but “(C)” alone isn't. You need one of those: “Copyright”, “Copr.”, “©” for your packaging. [1] + Missing year bump? (e.g. © 2008-2009) - debian/rules: + I'm usually not using ifneq/endif statements, so that I'm sure the build breaks if autotools-dev isn't installed (e.g. it's not mentioned in Build-Depends). Not updating those means possible portability issues on some platforms, so it's better to know. + The distclean line is prefixed with an hyphen, which means it can fail without the build failing, which is bad. Removing the hyphen would do the trick. - debian/watch: + Strange line. What about: http://sf.net/anyremote/anyremote-([0-9.]+)\.tar\.gz [1] Caught by lintian, too: | I: anyremote-doc: copyright-with-old-dh-make-debian-copyright | I: anyremote: copyright-with-old-dh-make-debian-copyright Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: anyremote (updated package)
(Not sure the Cc was needed, keeping it just in case.)
Bernd Zeimetz (21/01/2009):
> I'll take care of this. Btw Juan, you could ping me directly, I'll
> happily sponsor packages for my NMs.
Hello here,
as discussed on IRC, I finally will do. Note that I'm already sponsoring
{g,k}anyremote, so that makes sense. I'll report back to Bernd, though,
beware!
Review in a few hours.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net
Neil Williams (19/01/2009): > It is simple to pass the -v option to dpkg-buildpackage and then dpkg > includes all the changes since the specified -v into the .changes file > and the bugs get closed just fine. It is very simple to overlook/forget about passing once one is (finally!) satisfied with a package that needed more than a second iteration (see Ben's remark in another subthread). Mraw, KiBi. signature.asc Description: Digital signature
Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net
Ben Finney (19/01/2009): > Yes, that's exactly what I was hoping to get from my packages (and > thought it was my responsibility to do so; I wasn't fully aware that > the sponsor re-builds the package and uploads the result). (Just for completeness, from a pratical point of view:) Well, you upload a source package. Even if they wanted to, sponsors can't sign the _source.changes (which is what contains Closes et al.) and upload it as is, they have to build (at least) a binary, otherwise dak's going to reject the upload (and I'm sure _source.changes are available from mentors.d.n, though I didn't check). (One may suggest they could build the binary-only part and use mergechanges, but…) Which means that indeed, it's the sponsors' “responsibility” to use a proper -v when needed. > Now that I better understand how that all happens, I will communicate > with sponsors explicitly about this for future package releases, and > find out how they want to proceed. I think that's a good idea, yes. Mraw, KiBi. signature.asc Description: Digital signature
Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net
Ben Finney (19/01/2009):
> latest_debian_version=$(rmadison --suite ${suitename} ${packagename} \
> | cut -d'|' -f 2 | sed -e 's/^[[:space:]]+//')
Beware, you need to limit that to the source (in case there's a binary
built that has the same name, and in case there are some archs out of
sync), e.g.:
| $ rmadison --suite unstable guile-1.6
| guile-1.6 |1.6.8-6 | unstable | hppa, m68k, sparc
| guile-1.6 | 1.6.8-6.1 | unstable | source, alpha, amd64, arm, armel,
hurd-i386, i386, ia64, mips, mipsel, powerpc, s390
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net
Paul Wise (19/01/2009):
> As a sponsor, usually I would do stuff like this:
>
> dget http://mentors.foo...-3.dsc
> apt-get source foo
> interdiff -z -p1 foo...-1.diff.gz foo...-3.diff.gz | less
Why aren't you using “debdiff foo*-{1,2}.dsc”?
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: Introducing spurious revisions during sponsorship considered harmful (by some of us)
Neil Williams (19/01/2009): > > Do you, as a developer, bump the debian revision each time you build > > a package, are ready to upload it, and discover one final problem > > with it? Do you, under that scenario, write in the changelog a new > > bullet point "Oh, I botched the rules file writing `rm -rf $(CURDIR) > > /usr/lib`, fixed now", or rather just fix it silently? Why should > > sponsored pepole not get to do the same? > > My problem with that is that it wasn't the maintainer who spotted that > error. If the maintainer finds the botched line, the maintainer fixes > it locally - just as a DD can fix their own packages locally. > > I've made plenty of mistakes in my packages - it's all in the > changelogs - but if I've made an upload then the package should have > been good enough for an upload and if it contains a bug, I'll fix it > with another upload. > > As far as a maintainer is concerned, mentors.debian.net is the final > upload destination - it is only a sponsor who can take it from there > to Debian. If the package turns out not to be good enough after upload > to mentors, a maintainer I'm sponsoring fixes it in precisely the same > way as I'd fix a botched upload to Debian - with a new version. > > The need for a new version is instructional - it helps maintainers > improve their pre-upload check procedures by treating > mentors.debian.net as if it was ftp-master.debian.org. I disagree. mentors.debian.net is somewhere you push your files to so that they get peer-reviewed (and possibly uploaded to the archive when possible). I don't recall using it before I became DD (and was asked to try an upload there to check whether it was working properly), and I've always pushed my package candidates to my alioth's public space. How is that different from publishing a package with a possible fix, asking e.g. porters to check whether it fixes an FTBFS? Then the porter gets back to you, yelling that the patch isn't applied because you forgot to add the target magic to debian/rules. Will you re-upload with an increased version number? Then, because you were really tired, it is reported that it was forgotten to add the patch to the series file. Reupload and increment again? And then the patch doesn't apply because a typo slipped in while tweaking the comment/header/whatever. Reupload and increment again? Now comes the time to upload it to ftp-master. You then have (free form, but you get the idea): | foo (bar-5): | | Fix baz patch. | | foo (bar-4): | | Add baz patch to the series file. | | foo (bar-3): | | Fix targets so that patches are (un)applied when relevant. | | foo (bar-2): | | Introduce baz patch to fix quux. Don't you think it's adding a *little* *bit* *too* *much* *noise* to the universe, increasing entropy and killing kittens for no added benefit? Ah, yes, the package was exposed to a set of 1-2 persons, and “uploaded” somewhere. > > * history: I haven't seen this argument fly be in (this and other > > instances of) this discussion, but the answer is that the proper > > place to record that you had an extra and fatal space in your > > rules file is your VCS. (And FWIW, I think much of this > > discussion would go away if sponsorship was VCS-based rather > > than dsc+diff.gz based.) > > Oh no, not the git bike-shed thread again. ;-) I only use VCS for > debian/ when I also use VCS for the rest of the package - and in that > case, it is always the same VCS and I really don't like the idea of > putting all debian/ into VCS - especially not git. That's just me. I may be blind, but I don't see git mentioned anywhere. Also, why is storing debian-only relevant? AFAICT, a source package is a tarball plus a debian/ directory… Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: dict-jargon (updated package)
Ruben Molina (18/01/2009): > > - You are *not* allowed to change past changelog entries. The changelog > Why not? I was unable to find any reference to this on the policy or > the developers reference... Indeed, looks like I cannot back up that claim either. Ongoing discussion on debian-de...@. I probably assimilated it as bad practice after some discussions on IRC. I'm sorry, I'm lacking time to look at the other points you mentioned. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: adtool (bugfix)
Jonathan Wiltshire (18/01/2009): > I've also added DM-Upload-Allowed to debian/rules too, in advance of > applying for DM status, unless you want it missed out for now. Hi, I'd like to see how the things go on debian-newmaint@ first; so I don't really want to add it preventively. I'll gladly do so once you're in the DM keyring though. > The dsc is on mentors as usual, at: > http://mentors.debian.net/debian/pool/main/a/adtool/adtool_1.3-3.dsc > > If you can take a look sometime that would be great. I'll be taking a look later today. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: dict-jargon (updated package)
Ruben Molina (17/01/2009): > I am looking for a sponsor for the new version 4.4.7-1 of my package > "dict-jargon". Hello, only had a quick look since I'm missing time, but: - You want to say Build-Depends rather than Depends in the changelog. - You are *not* allowed to change past changelog entries. The changelog diff should always be about adding new entr(y|ies) on the top, not about changing newlines, indentation, etc. in previous entries. Mraw, KiBi. signature.asc Description: Digital signature
Re: dpatch and .diff.gz files
Charles Plessy (16/01/2009): > > Examine the ‘foo.diff.gz’ > > cat foo.diff.gz | lsdiff, for instance I think you wanted “zcat”. Anyway, no need to waste a fork: | lsdiff -z foo.diff.gz Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: gxemul (new upstream)
George Danchev (03/01/2009):
> > (let me know if you'd prefer a version bump).
>
> I do prefer version bump myself (since that avoids repetitive
> reviewing from scratch, which to be honest turned out to gain over
> some leftover improvements ;-), but I'm not that picky and leave that
> at sponsoree's own discretion, so it is fine with me.
Just for the record:
| mkdir 1 && dcmd mv foo.dsc 1
| dget url && debdiff {1/,}foo.dsc
is what I've been using since ages, and that doesn't seem much of a
hassle.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: RFS: gtkperf
Evgeni Golov (03/01/2009): > Dear mentors (and KiBi o<), Taking it. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: adtool (adoption) [done]
Jonathan Wiltshire (27/12/2008): > Same package version is on mentors, if you've time to take a look. After some nitpick on IRC, uploaded. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: adtool (adoption)
Jonathan Wiltshire (27/12/2008): > Ok, I'll address those now - would you like a version bump? No need, but I can live with it. You can also point poke me on IRC if you like. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: adtool (adoption)
Cyril Brulebois (27/12/2008):
> I'm willing to take a look, I'll get back to you soonish.
So, here it goes:
- there were some changes to upstream sources in the previous revision,
they went away but you're not mentioning it anywhere. Did you lost
them or did you trash them on purpose?
| $ lsdiff -z ../adtool_1.3-1.diff.gz|grep -v /debian/|grep -v config
| adtool-1.3/src/tools/adtool.c
| adtool-1.3/src/etc/adtool.cfg.dist
| adtool-1.3/src/lib/active_directory.c
- config.{guess,sub} are no longer updated during the build, I suggest
you copy them from the autotools-dev package, before the build, and
trash them in the clean target. Note that I'm not familiar with dh 7
yet, but maybe there's a nice way to do that.
- debian/dirs is only needed when the build system doesn't create those
directories, and that's almost never needed when autotools are used.
- not directly related to your packaging, it looks like CSS are missing
on your gitweb.
I'm quite happy with the other modifications.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: RFS: adtool (adoption)
Jonathan Wiltshire (27/12/2008): > I am seeking a sponsor for my adoption of the package 'adtool' (1.3-2). I'm willing to take a look, I'll get back to you soonish. Mraw, KiBi. signature.asc Description: Digital signature
Re: Considering package removal [glademm]
Christoph Egger (21/12/2008): > Jup I know the procedure, I was more in trouble wether it is > reasonable. There is no need I guess to have this done for lenny. You can propose/ask for opinion on debian...@. Mraw, KiBi. signature.asc Description: Digital signature
Re: ITS: xf86-input-tslib (updated package)
Neil Williams (19/12/2008):
> I'm only mentioning this as a caution - I don't consider it a
> practical problem for these particular changes to these particular
> packages. Once Lenny is released and we migrate both tslib and the
> xorg driver into unstable and thence into testing, it would be best if
> either the build-depends change was reverted or that the driver had a
> stricter dependency on that version of tslib by using this change in
> debian/control for the binary package:
>
> - Depends: ${shlibs:Depends}, ${misc:Depends}, ${xserver:Depends}
> + Depends: libts-0.0-0 (>= 1.0-5), ${shlibs:Depends}, ${misc:Depends},
> ${xserver:Depends}
That's ugly. Use shlibs.local (Policy §8.6.5) instead.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: Still the rejected package
Pietro Battiston (20/12/2008): > an ftp master told me that I can find the reason of the rejection of > the package I'm working on (python-shapely, for those who didn't read > the "Non free license?" thread) in folder > /srv/ftp.debian.org/queue/reject/ of server merkel.debian.org. It > should be a file named python-shapely_1.0.4-1_all.reason or something > similar. You should have got a mail about it. > Could a DD tell me the content of it? k...@merkel:/srv/ftp.debian.org/queue/reject$ ls *shapely* ls: *shapely*: Aucun fichier ou répertoire de ce type Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: gxemul segfault bugfix
Jonathan Wiltshire (18/12/2008): > No problem by me :-) Uploaded as is. I'm assuming you know about lintian and possible enhancements for this package (and that you already fixed that in unstable), and that you chose the minimalist approach for this tpu upload. :) Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: gxemul segfault bugfix
Jonathan Wiltshire (18/12/2008): > Hi George Hello both of you, > Release have approved the debdiff and asked for the upload; it's on > mentors at [1] if you have a chance. Cheers :-) > > [1] > http://mentors.debian.net/debian/pool/main/g/gxemul/gxemul_0.4.6.3-1+lenny1.dsc I can do the upload if you like, unless you have a preference for George's doing it. Ping on IRC is OK too. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: webcpp
Russ Allbery (11/12/2008): > ancient-libtool was added at the explicit request of the porters > because they were seeing obscure bugs and issues on some architectures > unless a current version of libtool was used. These sorts of bugs > unfortunately are the kind that can be hidden or cause weird failures. > I really think this one should be fixed. You know I'm a porter[1], right? :) 1. http://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=1;submitter=cyril.brulebois%40enst-bretagne.fr#_4_3_5 Fixing the bug in unstable-only (because being along with other cosmetic possible fixes, so why would it migrate?) doesn't really mean any gain to me? Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: webcpp
Raphael Geissert (11/12/2008):
> If it is lintian warning or error then chances are high that there
> *is* a bug.
Chances.
> 1) ancient-libtool is about porting,
is there an FTBFS bug open? Said otherwise: is there an arch where there
is an actual FTBFS?
> 2) debhelper-but-no-misc-depends is about missing dependencies,
is there really a missing dependency that gets added once the
${misc:Depends} is added, and the package rebuilt?
> 3) patch-system-but-direct-changes-in-diff and
> configure-generated-file-in-source are both, in this case, related to
> the same bug: lack of proper cleanup.
which doesn't necessarily break double-build support, so that looks
cosmetic enough to me not to be called a “bug”.
> If the diffstat is not large, and the changes are not just cosmetic,
> it is very likely that it will get unblocked.
My point exactly. All the above look cosmetic to me unless a real bug is
actually found.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: RFS: webcpp
Raphael Geissert (11/12/2008): > Why? there's no need to wait until work piles up. If work is committed in $VCS, then no work is piled up. No need to generate buildd, mirror, and upgrade noise only to fix some lintian warnings with no real bug IMHO. But YMMV. Mraw, KiBi. signature.asc Description: Digital signature
Re: Someone to 'proofread' a .deb please
Neil Williams (11/12/2008): > Packages created by the upstream team are generally exceptionally poor > quality. Even if the upstream team is or includes the Debian > maintainer, there is no justification for having a .deb on the > upstream download page - leave it to the packagers. And packagers may then provide .deb files to put there. Yes, there's a good reason. NEW processing time. Mraw, KiBi. signature.asc Description: Digital signature
Re: Someone to 'proofread' a .deb please
Andy Hawkins (11/12/2008): > I'm not sure I understand why the debian directory shouldn't be part > of my 'main' release? What problems does this cause? Hello, see [1] for some reasons. Have a nice reading. 1. http://kitenet.net/~joey/blog/entry/on_debian_directories_in_upstream_tarballs/ Mraw, KiBi. signature.asc Description: Digital signature
Re: Uploads to experimental instead of unstable
Thomas Weber <[EMAIL PROTECTED]> (11/12/2008): > Am Donnerstag, den 11.12.2008, 13:09 + schrieb Neil Williams: > > Everyone has to take account of transitions and blocks in unstable > > between releases, the release freeze itself is just another issue to > > consider with regard to unstable. Unstable isn't 100% available > > every single day between freezes, there are constant issues that > > mean that uploads need to be delayed or put into experimental. > > That's why we have experimental. ^^^ (emphasis is mine.) > http://www.debian.org/doc/developers-reference/resources > "The experimental distribution is a special distribution. It is not a > full distribution in the same sense as stable, testing and unstable are. > Instead, it is meant to be a temporary staging area for highly > experimental software where there's a good chance that the software > could break your system, or software that's just too unstable even for > the unstable distribution (but there is a reason to package it > nevertheless). Users who download and install packages from experimental > are expected to have been duly warned. In short, all bets are off for > the experimental distribution." > > Sorry, but your description doesn't match at all with both devref and > the warning about experimental packages. Indeed. I would rather say “that's what one is supposed to use experimental for, according to the current way of dealing with the freeze, testing, and unstable”. Experimental is not by definition the unstable staging area during freezes, but became such a de facto staging area. (Neil loves using Latin. :))) Mraw, KiBi. signature.asc Description: Digital signature
Re: VCS-Git branch
Resul Cetin <[EMAIL PROTECTED]> (11/12/2008): > Sry, but it is not possible to move head because otherwise upstream > will kill me. (It is a shared repository with upstream) Just had a quick look at debcheckout's code, it looks like you would need to open a bug against it so that you can specify the appropriate branch somewhere in the Vcs-Git URL. I think it's already going this way for topgit, but I didn't look too much those days, so ask them. :) Mraw, KiBi. signature.asc Description: Digital signature
Re: VCS-Git branch
Resul Cetin <[EMAIL PROTECTED]> (11/12/2008): > I want that debcheckout will checkout debian instead of master. Tweak HEAD in the repository to point to the wanted branch (yeah, that shouldn't even exist in a bare repository, etc., but that does exactly what you need, so… enjoy). Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: webcpp
Jonathan Wiltshire <[EMAIL PROTECTED]> (09/12/2008): > This upload adds the VCS-* fields to debian/control and fixes some > minor lintian warnings. Hi, thanks for your attention to details. That doesn't really look like needing an upload right now, though. I'd wait for a bugfix or a new upstream release to push those fixes (get them uploaded) if I were you. Mraw, KiBi. signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
Neil Williams <[EMAIL PROTECTED]> (09/12/2008):
> You're talking about the shlib, as explained in my other message, I
> was inadvertently folding the two into one. My mistake.
Finally.
> > You *do* understand the concept of SONAME and shlibs, right?
>
> Yes, but adding symbols "properly" includes the shlib change and I
> wasn't thinking of it as a separate step, just a routine part of
> adding a symbol. Upstream bias.
*shrug*. Knowing the Debian Policy would help compensate that bias. Not
to mention that you aren't advising upstreams here, but Debian
packagers, so I'd even expect good knowledge of the Policy.
> I use symbols instead now and that is a far better system - easier to
> manage upstream too.
Still, knowing the basics...
> The RC bugs in question are not against my own packages, I was merely
> reviewing the existing bugs to try and get Lenny released.
Oh, you were adding random noise (buggy severity change, tag addition)
to #50707{1,2}? Then I do recognize my mistake assuming you were the
maintainer.
> [Various stats, etc.] I don't think a genuine mistake is grounds to
> disrespect my contribution.
As I already stated, what I hate is your repeating you're right (“Cyril,
we've had this discussion before” etc.) when you're being clueless.
> > Again, wrong.
>
> Umm, adding symbols properly does not require a SONAME bump - you've
> said so yourself. The confusion is what is meant by "properly" - I
> considered "properly" as including the shlibs (or preferably symbols)
> support, not as a separate task. Dumping new symbols into the library
> without any packaging support is not a good idea, I've never doubted
> that. (Just didn't expect others to be neglecting it).
So you claim you're doing your job right (note that I'm not questioning
that), by playing with symbols while you didn't know anything about
shlibs (read it as “confusing them with SONAME”) before some minutes
ago? Impressive.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: Listing dependencies with specific versions
Andy Hawkins <[EMAIL PROTECTED]> (09/12/2008): > My .deb however doesn't depend on a specific version of libflac, is > that because there are no versions prior to this available? It is because currently, libflac doesn't declare its shlibs properly. Once this is fixed, and once your package has been rebuilt against it, your package's dependencies against libflac will gain a (>= $version). Mraw, KiBi. signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
Paul Wise <[EMAIL PROTECTED]> (10/12/2008): > > Specify the strict version ahead of shlib:Depends and dpkg-shlibdeps > > does the right thing. > > Thats a hack. Another workaround for broken shlibs is > debian/shlibs.local. A very dirty one. The other being the one recommended by the Policy, but I don't really want mentored people to try and handle this kind of problem this way, especially if mentored by clueless people (I'm not thinking about you, Paul :) you already know that we agree on this topic). Mraw, KiBi. signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
Neil Williams <[EMAIL PROTECTED]> (09/12/2008): > Adding a new function (or several hundred new functions) has > absolutely ZERO impact on the SONAME as long as the new functions do > not overlap existing functions, change existing functions or require > any changes elsewhere in the library that remove or modify existing > symbols. And I said ZERO things about the SONAME, would you please learn to read? And yes, Gtk people are good at not breaking the ABI. But that has ZERO things to do with the current topic. Please (re)focus. > Cyril, we need to sort this out for that RC bug that doesn't exist but > which you raised the severity - adding a new symbol is NOT a bug, as > long as it is done properly (as above). It wasn't in your packaging. Again, shlibs. Again, shlibs!=SONAME. Maybe you've got a broken strcmp() implementation? > It is up to the package using the library to build-depend on the right > version and use a strict dependency on that version or later that > supercedes the plain dependency. > > i.e. exactly what I recommended for this package. > > Specify the strict version ahead of shlib:Depends and dpkg-shlibdeps > does the right thing. What if you read the Policy? Like e.g. 8.6 (more specifically 8.6.3). I thought it was a prerequisite for doing Debian stuff. Mraw, KiBi. signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
Neil Williams <[EMAIL PROTECTED]> (09/12/2008): > > Looks like you just found an RC bug in libflac++6 - includes new > > symbols in version 1.2.1-1 according to mole but the shlibs does not > > depend on that version: > > That is not a bug - the package building against it merely has to > require that version. That is. > The bug only arises if symbols are removed or function prototypes are > changed in existing symbols. Wrong. > > Please file a bug about this. > > Please don't - it is not a bug. Please do. > If it was, we'd be on libglib.so.7787.0.0 by now. You *do* understand the concept of SONAME and shlibs, right? You *do* understand that those are different things, right? Given some RC bugs against some of your packages, I start doubting it. Too bad you're being so vocal on this list, and so self-confident. > > Hopefully more libraries will adopt the new dpkg symbols stuff so > > that this can be detected and fixed more often. > > The fix is only necessary if the symbol has CHANGED - added symbols > can be managed perfectly well without a SONAME bump. Again, wrong. Mraw, KiBi. signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
Neil Williams <[EMAIL PROTECTED]> (09/12/2008): > > Short version: “Fix your shlibs.” > > Cyril, we've had this discussion before - merely adding symbols does > NOT require a SONAME bump. Neil, read. Mraw, KiBi. signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
Andy Hawkins <[EMAIL PROTECTED]> (09/12/2008): > > Please file a bug about this. > > Umm, I'll try. I'm not sure exactly what that bug report should say! > Kind of new to all this Debian packaging stuff (as of this time last > week I knew nothing about it!). Short version: “Fix your shlibs.” Slightly longer version: “Remember to bump your shlibs whenever symbols get added. Please fix.” People that maintain libraries should be able to cope with the shorter version. If they don't, they probably shouldn't maintain libraries, or should be mentored for that particular matter. > I should add at this point that the package I'm using is one I > compiled myself, not an 'official' Debian package. Can't remember > whether it came from Debian or whether I compiled up the .debs direct > from the FLAC sources. In that case, one would be pretty welcome to check one's findings against the packages that are actually in the archive. In this particular case, as pointed out by Paul, the bug is present in the packages shipped by Debian, so let's report it. Mraw, KiBi. signature.asc Description: Digital signature
Re: Listing dependencies with specific versions
Eugene V. Lyubimkin <[EMAIL PROTECTED]> (09/12/2008):
> > package-has-a-duplicate-relation depends: libflac++6, libflac++6 (>= 1.2.1)
>
> According to the man dpkg-gencontrol, just place 'libflac++6(>=1.2.1)'
> before the '${shlibs:Depends}', and dpkg-control with throw away less
> strong dependency.
Wrong way to go. Fix libflac (as Paul explained) instead.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: RFS: commons-vfs (updated package) [done]
Damien Raude-Morvan <[EMAIL PROTECTED]> (30/11/2008): > - dget http://mentors.debian.net/debian/pool/main/c/commons-vfs/commons- > vfs_1.0-3.dsc Heh, please don't wrap URL lines. :) > I would be glad if someone uploaded this package for me. Sure, looks fine, uploading. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: sqlline (updated package) [done]
Damien Raude-Morvan <[EMAIL PROTECTED]> (30/11/2008): > http://mentors.debian.net/debian/pool/main/s/sqlline/sqlline_1.0.2-2.dsc > > I would be glad if someone uploaded this package for me. Hi Damien, it's fine, uploading it. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: freespeak
Luca Bruno <[EMAIL PROTECTED]> (28/11/2008): > I would be glad if someone uploaded this package for me. Taken care of after some modifications. Mraw, KiBi. signature.asc Description: Digital signature
Re: Preferred version format for svn revisions?
Sandro Tosi <[EMAIL PROTECTED]> (09/11/2008): > yes it it: you have to provide a programmatical way to > retrive/generate the orig.tar.gz […] FSVO “have to”. It is clearly tagged as optional in Policy §4.9. Mraw, KiBi. signature.asc Description: Digital signature
Re: debconf questions
On 10/11/2008, Adeodato Simó wrote: > Hm, I thought you're not supposed to use debconf to display notes, and that > NEWS.Debian is preferred. Yeah, otherwise Christian is coming after you; and you don't want that. Mraw, KiBi. signature.asc Description: Digital signature
Re: Please clarify: to bugreport or not bugreport
Kumar Appaiah <[EMAIL PROTECTED]> (01/11/2008): > The most foolproof way of testing whether the package in question > builds in pbuilder. pbuilder starts with a clean chroot, downloads the > build dependencies, installs them and then copies and builds your > package in that clean environment. If the package you suspect fails to > build on a pbuilder environment, then that most likely points to a > serious bug. Incomplete. pbuilder's (Build-)Dependency resolution differs from sbuild's, which is the tool used on buildds, so making sure the package builds in pbuilder (although usually sufficient) doesn't ensure it will do on buildds. BTW, setting sbuild chroots isn't really hard nowadays, so people may want to give it a try. :) Mraw, KiBi. signature.asc Description: Digital signature
Re: Please clarify: to bugreport or not bugreport
Paul Wise <[EMAIL PROTECTED]> (02/11/2008): > If the build-deps are satisfied and build-essential is installed, the > package should build, so yeah, file bugs at severity serious please. For reference: Do folks think #505040 is RC or should at least be fixed for lenny? KiBi: nope, the package in etch builds in etch, the one in lenny builds in lenny, so it's not considered RC, though fixing it won't harm Mraw, KiBi. signature.asc Description: Digital signature
Re: [RFS] python-osd (updated)
Mauro Lizaur <[EMAIL PROTECTED]> (22/09/2008):
> BTW, if you sponsor this package, the only thing left is to contact
> RMs explaining the situation, right?
Mostly, yes.
> [0] http://lusers.com.ar/packages/python-osd_0.2.14-4.dsc
Hmm, many remarks:
- debian/rules modifications aren't documented at all in the changelog.
- the libxosd2 dependency should be pulled by ${shlibs:Depends}, you
should never have to include a dependency manually like that.
- you didn't document that you dropped Conflicts and Replaces, nor why.
- you didn't document that you added a debian/watch file.
- your not mentioning the case change (s/python/Python/) in the first
line of the long description is OK, though.
So you've got to fix some bits before someone can sponsor this.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: [RFS] python-osd (updated)
Kel Modderman <[EMAIL PROTECTED]> (22/09/2008): > > BTW, Since the bug in the previous revision practically renders > > pyosd unusable, in order to have the chance to update this package > > on Lenny would be OK to change the severity from 'normal' to > > 'important' and/or the urgency to 'high'? Any advice is welcome. I'd bump the bug severity to serious. > iirc, the release managers stated that urgency is not to be raised to > higher priorities for this purpose. See: > > http://lists.debian.org/debian-devel-announce/2008/07/msg6.html Indeed, but I'd use medium in this case, so that the package doesn't get hold too long in unstable (assuming the RMs grant it a freeze exception). If you don't find a sponsor, you're welcome to get back to me tomorrow or so. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: hpl [hold]
Cyril Brulebois <[EMAIL PROTECTED]> (21/09/2008): > as you may know, I'm going to be more available nowadays. :) As discussed, please people hold on, and don't upload it, since the package name is going to change. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: sqlline [uploaded]
Damien Raude-Morvan <[EMAIL PROTECTED]> (29/07/2008): > I am looking for a sponsor for my package "sqlline". Again, after some private mails, finally uploaded. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS and ITA: jzlib (updated package) [uploaded]
Damien Raude-Morvan <[EMAIL PROTECTED]> (04/08/2008): > I am looking for a sponsor for the new version 1.0.7-1 > of package "jzlib". As said through private mail, finally uploaded. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS : Mina [Uploaded]
Damien Raude-Morvan <[EMAIL PROTECTED]> (29/07/2008): > I am looking for a sponsor for my package "mina". As said through private mail, finally taken care of. Mraw, KiBi. signature.asc Description: Digital signature
Re: How to remove package completely?
Krzysztof Burghardt <[EMAIL PROTECTED]> (17/09/2008): > I'd like to remove bluetooth-alsa and libsbc from Debian completely. > It was already removed (at my request) from unstable, but it is still > in Lenny. How can I remove it from Lenny? Reportbug tell me that > package does not exist when trying to request removal. Should I send > my request to release team. (Offline right now, no direct link available but:) search for “ftpmaster removal” on wiki.debian.org, that's explained extensively. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: arping (updated package)
Giuseppe Iuculano <[EMAIL PROTECTED]> (02/09/2008): > My usual sponsor is Cyril Brulebois (kibi), I've tried asking him for > an upload several time, but never gotten a response You had on IRC, and that was “too busy to sponsor anything for now”. Mraw, KiBi — M-x catchup-mode signature.asc Description: Digital signature
Re: RFS: mpop - POP3 mail retriever (updated version) (second try)
Carlos Martín Nieto <[EMAIL PROTECTED]> (04/09/2008): > I am looking for someone to upload an updated version of mpop. Cyril > Brulebois originally reviewed it, but it has been more than a month > since that (I've been away from my computer and my keys), so I'm > asking in general again. Yes, sorry for that. I'm catching up, expect it soonish. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: gnome-art-ng
Julien Lavergne <[EMAIL PROTECTED]> (16/09/2008): > I am looking for a sponsor for my package "gnome-art-ng". > The goal of Gnome-art-ng is to replace gnome-art (non maintained > upstream, see http://www.miketech.net/gnome-art/index.php). It provides > the same features: […] Maybe you could keep the original name, then? Or at least provide an upgrade path from the no-longer-maintained package (to coordinate with the maintainer(s) of that latter)? Mraw, KiBi. signature.asc Description: Digital signature
Re: deb/debian suffixes in packages
Al Nikolov <[EMAIL PROTECTED]> (16/09/2008): > OTOH, devreference is not a collection of common used practices (what > is may be sad) I beg to differ. Once a practice is common enough, it'd quite interesting to have it documented so that others can easily follow what de facto consensus has been reached. > IMHO, which is more suitable for such things inclusion into is Debian > Wiki. Which is something that cannot be installed and used/browsed offline, while policy and devref can. Mraw, KiBi. signature.asc Description: Digital signature
Re: deb/debian suffixes in packages
Charles Plessy <[EMAIL PROTECTED]> (17/09/2008): > the best way to figure out is to send a patch and see if it is > accepted ;) IIRC, a bit of standardization got discussed already (on -devel), so a potential patch sender may want to check that first. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: hpl
Jean Parpaillon <[EMAIL PROTECTED]> (09/09/2008): > Dear mentors, Salut Jean, > I would be glad if someone uploaded this package for me. as you may know, I'm going to be more available nowadays. :) See you tomorrow, KiBi. signature.asc Description: Digital signature
Re: RFS: elfrc
Krzysztof Burghardt <[EMAIL PROTECTED]> (18/09/2008): > It builds these binary packages: > elfrc - program to convert arbitrary files into elf objects In addition to Patrick's comments, I'd suggest to “s/program to //” this description. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: sqlline
Damien Raude-Morvan <[EMAIL PROTECTED]> (13/08/2008): > Cyril, did you have time to sponsor this package (if it's ok for you, > of course)? Here are some comments: - I assume libjline-java will pull the needed java machinery so you don't have to depend on a java runtime environment; is that correct? - I assume ant doesn't call any java-ish stuff in the clean target; otherwise you would have to move java-gcj-compat-dev to B-D. - Please add full stops at the end of the sentences of your long description. The other dots are only here for “folding” (see RFC (2)822). - Nothing important, but you have trailing spaces in debian/copyright, you may want to use show-wspace.el if you're an Emacs user. - Not sure whether you're pointing at the BSD license is sufficient, usually (at least for GPL), a blurb is needed (3 paragraphs). But if you're confident enough, I leave that up to ftpmasters. :) - Also, when packaging something under a “liberal” license (like the BSD licenses), you may want to license the packaging under the same license, that might help upstream integrate patches, and so on. - I'd s/(C)/©/ in your copyright statement (about Debian packaging) since only “Copyright”, “Copr.”, and “©” are legally recognized. - You may want to limit the line length of your README.Debian to <= 80 characters; might improve readibility, especially on servers with only the default 80x25 console. - No space before “:”, “;”, “!”, etc. in English (same file). - Also, s/take/takes/. - README.source (whitespaces again) can disappear. All copyright info must be in debian/copyright, so please move its contents there. - debian/rules: - whitespaces line 2. - if you're using dh_install in “install/sqlline:”, no need to add this directory to the “dirs” file. - you could modify this target like that: - put the jar file and its location in an “install” file. - do the same for the wrapper. - only do a “mv” in this target. - the “dirs” file can go away. - I think we already discussed the presence of svn-deblayout so I won't insist on it. :) That was only a review of the most important things of the source part, I'll have a look at the build/binary part once you've addressed some of those points. ;-) Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#491858: RFS and ITA: jzlib (updated package)
Damien Raude-Morvan <[EMAIL PROTECTED]> (07/08/2008): > I've uploaded a new package to mentors.debian.net, you should dget it. Oops, sorry for the lag, will be reviewed tonight. Mraw, KiBi. signature.asc Description: Digital signature
Re: [DONE] RFS: qmmp
"Eugene V. Lyubimkin" <[EMAIL PROTECTED]> (08/08/2008): > I've found the sponsor. Thanks to let us know, but that'd be handy to send such mails to their respective RFS threads, so that one can easily check which are [DONE]. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: sqlline
Ola Lundqvist <[EMAIL PROTECTED]> (05/08/2008): > Ok with me. On both parts. :) Thanks for your comments, Ola. Just FTR, I intend to review/sponsor this package, since I'd like to have a better view over Damien's work. Mraw, KiBi. signature.asc Description: Digital signature
Re: Preferred way to do a chown on package's dirs ?
Russ Allbery <[EMAIL PROTECTED]> (07/08/2008): > I'm surprised that this doesn't work. Shouldn't fakeroot handle this > case and do the right thing? Or am I confused about what fakeroot is > capable of? First guess would be missing -X in dh_fixperms call. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS and ITA: jzlib (updated package)
Cyril Brulebois <[EMAIL PROTECTED]> (06/08/2008): > Since I'd like to familiarize myself with Damien's work, I intend to > review this package. Okay, here we go for a first round: - No need to mention the upstream release number in your first changelog entry, although it does no harm. - You didn't mention bumping debhelper compat level (debian/compat + the versioned B-D) from 4 to 5 in your changelog. - You didn't mention adding Homepage, Vcs-* either. - You could mention you've switched from kaffe. - You should mention you're now using ant (and that you've added a build.xml file accordingly, at least that's how I understand it). - You could mention you've deleted the override since you fixed the copyright file. - You could mention you've deleted unneeded files (and which, like copyright.in). - You should mention you're now shipping examples. - Your comment at the top of debian/rules doesn't look like necessary to me (although it does no harm). - Should debian/svn-deblayout be really included in the source package? I seem to recall it's possible to set an svn property on the debian directory, so that this additional file isn't visible in the source package. - I tend not to specify “debian uupdate” in my watch files, but I may be missing some nice features. Just saying so that you can consider whether you need those bits. - debian/rules again: - Not sure the exports are needed (though I didn't build your package yet). - You could use cdbs variables instead of computing package and version yourself. Grep for UPSTREAM under /usr/share/cdbs/1/*/* if you don't have the docs at hand. Then grep for PACKAGE (probably only in the single file you've just found rather than through all cdbs files). That's only after having checked the source debdiff. Please poke me back if you have questions about the above points, and/or when you think you have a new candidate. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS and ITA: jzlib (updated package)
Damien Raude-Morvan <[EMAIL PROTECTED]> (04/08/2008): > I am looking for a sponsor for the new version 1.0.7-1 > of package "jzlib". Since I'd like to familiarize myself with Damien's work, I intend to review this package. Mraw, KiBi. signature.asc Description: Digital signature
