Bug#872147: RFS: lirc/0.10.0-2 NMU
On Wed, 16 Aug 2017 02:01:12 +0500 Andrey Rahmatullin wrote: > On Tue, Aug 15, 2017 at 10:32:55PM +0200, Alec Leamas wrote: > > > Why does the report title say "NMU"? > > > > Perhaps it shouldn't - large parts of the debian workflow is still a mystery > > for me. > Please read > https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu > If you are the package maintainer you don't do NMUs, but plain uploads. Done, got it. I was confused by the fact that while I am the maintainer, I havn't done the uploads myself. > > > How are those two upstream bugs fixed? > > > > They was fixed by the experimental 0l.10.0-rc3 upstream release, which > > eventually became 0.10.0 by upstream and pushed to sid as 0.10.0-1. This > > should have been mentioned in -1, but was not, hence the -1 note. > If they are fixed in an old version, why are they mentioned in this upload > entry? Please read > https://www.debian.org/doc/manuals/developers-reference/ch06.en.html#bpp-debian-changelog Just because I missed to document it in the correct -1 entry. Would it be better to update the -1 changelog entry? > > > I haven't looked at the package itself, but wtf is happening in prerm? > > Removing files not owned by the package any more (but left on install to > > niot remove anything user-edited). > Why are they not owned by the package? Basically because the package from 0.9.4 is systemd-centric. > Obsolete conffiles should be > removed by dpkg-maintscript-helper rm_conffile. Looking at rm_conffile at [1] this doesn't look relevant here (?) The current code is basically a left-over from the disruptive change from 0.9.0 which is several versions beyond current version. So the checksums from previous version is not available. Current code just makes sure everything is cleaned up on a final remove. > I've also noticed the priority: extra field, which means when you updated > Standards-Version to 4.0.1 in the previous upload you haven't actually > consulted > https://www.debian.org/doc/debian-policy/upgrading-checklist.html Indeed, I was not aware of it. Checking, updated Priority: to optional. Thanks for pointers to relevant documents, very helpful! Uploaded a new version to mentors, for now with irrelevant sources included. Have not been able to verify the upload, but sends this reply anyway - will be way for the day and cannot send it until this evening otherwise. Cheers! --alec
Bug#872182: RFS: budgie-desktop/10.4-1
thanks. I have doubled checked the bug number in the 10.2.9-3 release - this was released to unstable whilst 10.3 was in experimental. I've updated the changelog to reflect this. I've pulled the budgie 10.4 release notes from the upstream announcement and added it to the changelog-announcement.txt Ack 4.0.1 and Standards-Version. I've double checked 4.0.1 and 4.0.0 to double check. bookmarked this checklist as well for the future. I've done a further rebuild to confirm that the changelog changes are ok. Also uploaded to mentors. On 15 August 2017 at 21:48, Andrey Rahmatullin wrote: > On Tue, Aug 15, 2017 at 09:33:48PM +0100, foss.freedom wrote: >> - Merge changelog for 10.2.9-3 Stretch bug-fix release; >> v10.2.9-3 is a hotfix for Stretch released after the v10.3.x >> series was uploaded to testing > 10.2.9-3 is not in stretch. > We don't upload to testing. > We don't prepend "v" to package versions. > >> - debian/rules: add override_dh_installchangelogs with >> debian/changelog-announcement.txt to describe >> where to find the upstream announcement and description of changes > This is is wrong, it should contain the upstream changelog directly if > present. > >> >> - debian/control: standards version 4.0.0 >> >Current one is 4.0.1. >> >> My unstable build is up-to-date as of today. Building does not >> recognise 4.0.1 > Please read what does this field mean: > https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Standards-Version > >> I've updated the standards-version as requested though > You shouldn't blindly update it, you should go through > https://www.debian.org/doc/debian-policy/upgrading-checklist.html and make > sure the package actually conforms to the new policy version. > > -- > WBR, wRAR
Bug#872147: RFS: lirc/0.10.0-2 NMU
Control: retitle -1 RFS: lirc/0.10.0-2 On Tue, Aug 15, 2017 at 10:32:55PM +0200, Alec Leamas wrote: > > Why does the report title say "NMU"? > > Perhaps it shouldn't - large parts of the debian workflow is still a mystery > for me. Please read https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu If you are the package maintainer you don't do NMUs, but plain uploads. > > How are those two upstream bugs fixed? > > They was fixed by the experimental 0l.10.0-rc3 upstream release, which > eventually became 0.10.0 by upstream and pushed to sid as 0.10.0-1. This > should have been mentioned in -1, but was not, hence the -1 note. If they are fixed in an old version, why are they mentioned in this upload entry? Please read https://www.debian.org/doc/manuals/developers-reference/ch06.en.html#bpp-debian-changelog > > I haven't looked at the package itself, but wtf is happening in prerm? > Removing files not owned by the package any more (but left on install to > niot remove anything user-edited). Why are they not owned by the package? Obsolete conffiles should be removed by dpkg-maintscript-helper rm_conffile. I've also noticed the priority: extra field, which means when you updated Standards-Version to 4.0.1 in the previous upload you haven't actually consulted https://www.debian.org/doc/debian-policy/upgrading-checklist.html -- WBR, wRAR signature.asc Description: PGP signature
Bug#872182: RFS: budgie-desktop/10.4-1
On Tue, Aug 15, 2017 at 09:33:48PM +0100, foss.freedom wrote: > - Merge changelog for 10.2.9-3 Stretch bug-fix release; > v10.2.9-3 is a hotfix for Stretch released after the v10.3.x > series was uploaded to testing 10.2.9-3 is not in stretch. We don't upload to testing. We don't prepend "v" to package versions. > - debian/rules: add override_dh_installchangelogs with > debian/changelog-announcement.txt to describe > where to find the upstream announcement and description of changes This is is wrong, it should contain the upstream changelog directly if present. > >> - debian/control: standards version 4.0.0 > >Current one is 4.0.1. > > My unstable build is up-to-date as of today. Building does not > recognise 4.0.1 Please read what does this field mean: https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Standards-Version > I've updated the standards-version as requested though You shouldn't blindly update it, you should go through https://www.debian.org/doc/debian-policy/upgrading-checklist.html and make sure the package actually conforms to the new policy version. -- WBR, wRAR signature.asc Description: PGP signature
Bug#872182: RFS: budgie-desktop/10.4-1
Thanks Andrey. I've revised the packaging as follows: New changelog: * New upstream release * Packaging Changes - remove all unneeded triggers - debian/control: standards version 4.0.1 - debian/control: Add build dependency sassc - debian/control: add minimum meson version to build - debian/control: Add Build-Depends alternate libmutter-1-dev for GNOME 3.26 builds - debian/control: correct typo in Vcs-Git - drop all patches since now dealt with in new release - update library symbols files with 10.4 changes - Rename binary package gir1.2-budgie-desktop-1.0 to match the typelib gir1.2-budgie-1.0; To ensure a smooth upgrade, debian/control updated with Replaces/Breaks for the new package and budgie-desktop with a restriction for 10.4 and later for the new package - Add man-page for new binary budgie-desktop-settings - Updated debian/copyright for all source files - Merge changelog for 10.2.9-3 Stretch bug-fix release; v10.2.9-3 is a hotfix for Stretch released after the v10.3.x series was uploaded to testing - debian/rules: add override_dh_installchangelogs with debian/changelog-announcement.txt to describe where to find the upstream announcement and description of changes - add budgie-core.lintian-override with comment to describe the rpath lintian error; the error has not been overridden in this file since it is valid but without any workaround >> I have double checked lintian -i -I for the built .dsc > This checks only the source package which is wrong. You need to check the binary .changes. Also, you've missed -E --pedantic. Correct - my bad. I really should not be packaging well past midnight! > E: budgie-desktop changes: orig-tarball-missing-upstream-signature > budgie-desktop_10.4.orig.tar.xz Strange - I've redownloaded the .asc and it now appears to be uploaded correctly > I: budgie-desktop source: testsuite-autopkgtest-missing I'll discuss this with upstream as some point >P: budgie-desktop: no-upstream-changelog >P: libbudgietheme0: no-upstream-changelog fixed >I: libbudgietheme0: no-symbols-control-file usr/lib/libbudgietheme.so.0.0.0 fixed >P: libbudgie-plugin0: no-upstream-changelog fixed >I: libbudgie-plugin0: no-symbols-control-file usr/lib/libbudgie-plugin.so.0.0.0 fixed >P: budgie-desktop-doc: no-upstream-changelog fixed >I: libraven0: spelling-error-in-binary usr/lib/libraven.so.0.0.0 Udpating >Updating This is an debug message - no change required >P: libraven0: no-upstream-changelog fixed >X: libraven0: shlib-calls-exit usr/lib/libraven.so.0.0.0 seems to be an experimental lintian issue - no change made >I: libraven0: no-symbols-control-file usr/lib/libraven.so.0.0.0 fixed >P: budgie-core-dev: no-upstream-changelog fixed >P: gir1.2-budgie-1.0: no-upstream-changelog fixed >I: gir1.2-budgie-1.0: typelib-not-in-multiarch-directory >usr/lib/girepository-1.0/Budgie-1.0.typelib >usr/lib/x86_64-linux-gnu/girepository-1.0 The last time I tested budgie-desktop with multiarch compilation the desktop refused to initialise. Multiarch is something upstream does not do - so I prefer here to keep to the way upstream builds and tests the desktop >I: budgie-core: spelling-error-in-binary usr/bin/budgie-panel overriden >overridden This is a debug message - no change required >E: budgie-core: binary-or-shlib-defines-rpath usr/bin/budgie-wm >/usr/lib/x86_64-linux-gnu/mutter I've added a linitian-override file with an explanation for this - I haven't actually overridden the message since its valid. No change possible here. >I: budgie-core: spelling-error-in-binary >usr/lib/budgie-desktop/plugins/org.budgie-desktop.applet.status/libstatusapplet.so > Udpating Updating This is a debug message - no change required >P: budgie-core: no-upstream-changelog fixed >I: budgie-core: desktop-entry-lacks-keywords-entry >usr/share/applications/budgie-desktop-settings.desktop >I: budgie-core: desktop-entry-lacks-keywords-entry >usr/share/xsessions/budgie-desktop.desktop I'll discuss this with upstream at some point. No change made >> Changes since the last upload: >> >> * New upstream release >> - Software Highlights: >> - Fix Highlights: >Please don't describe upstream changes in debian/changelog. Deleted >> - debian/control: standards version 4.0.0 >Current one is 4.0.1. My unstable build is up-to-date as of today. Building does not recognise 4.0.1 - sid appears to be at 4.0.0. So a bit confused here. I've updated the standards-version as requested though >> - debian/control: Add alternate libmutter-1 version for GNOME 3.26 >Add where? Updated the changelog to explain >> - drop all unnecessary library symbols files >Why are they unnecessary? I've reverted this - symbols have been updated with 10.4 changes >>> - Merge changelog for 10.2.9-3 bug-fix release >What does this mean? I've explained this further in the changelog. Hopefully this cl
Bug#872147: RFS: lirc/0.10.0-2 NMU
Hi! Thanks for feedback! I seem to have lost some chunk of messages, or possibly I just missed your reply and removed it. Sorry for that. That said, here we go: On Mon, 14 Aug 2017 23:26:47 +0500 Andrey Rahmatullin wrote: > Control: tags -1 + moreinfo > > Why does the report title say "NMU"? Perhaps it shouldn't - large parts of the debian workflow is still a mystery for me. > On Mon, Aug 14, 2017 at 05:41:45PM +0200, Alec Leamas wrote: > > * Restore parallel builds, accidentally disabled in -2 > debian/compat says 10, so --parallel is the default. yes... OTOH, at some point when 0.9.4c (last version before 0.10.0) was built locally the builds was indeed parallel. Now, it seems like it uses make -j1. But it turns out that this is the case using --parallel or not, so adding it makes actually no sense. Removing it. > > * Fixed upstream bus #294 (VPATH build issues, in -1). > s/bus/bug/ Fixed. > There are three new patches in debian/patches that are not mentioned in > debian/patches/series. Old garbage, an oversight. Removed. > How are those two upstream bugs fixed? They was fixed by the experimental 0l.10.0-rc3 upstream release, which eventually became 0.10.0 by upstream and pushed to sid as 0.10.0-1. This should have been mentioned in -1, but was not, hence the -1 note. > I haven't looked at the package itself, but wtf is happening in prerm? Removing files not owned by the package any more (but left on install to niot remove anything user-edited). > And you shouldn't call python3 -m compileall in postinst. Fixed Uploaded new version to mentors [1] --alec [1] https://mentors.debian.net/package/lirc
Re: NMU help.
You already filed an RFS and you haven't answered the feedback there. Also, why are you calling this a NMU? -- WBR, wRAR signature.asc Description: PGP signature
NMU help.
Dear list, Gianfranco, who usually kindly offers me reviews and also actually uploads my lirc packahes is in a well deserved holiday. During his holiday, we have a new bug in the recently uploaded lirc-0.10..0-1. It's kind of bad, a FTBS in packages compiled against lirc. It surfaced in the libirman package. I have prepared a RFS bug [1]. It's a simple bugfix + some administrative data updates. Is there anyone on this list which could help me with uploading this so that dependent packages can be compiled again? Cheers! --alec [1] https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1540599.html
Bug#871693: RFS: tinymux/2.10.1.14-1 [RC]
On Tue, Aug 15, 2017 at 11:48 AM, Andrey Rahmatullin wrote: > Are you sure you need autotools-dev? > Removing. > By the way, binutils (>= 2.28.0) is wrong, as 2.28-1 is not >= 2.28.0. > Fixing. > So now to talk about the dpkg-shlibdeps warningsI think the problem > is really dh_makeshlibs. > I don't think so. > You were correct. Fixed it with -l option
Bug#871693: RFS: tinymux/2.10.1.14-1 [RC]
On Mon, Aug 14, 2017 at 02:55:57PM -0600, Stephen Dennis wrote: > Ah. missed the compat level because I changed the it to version 10 in the > debian/control file. Next upload will have debian/compat of 10, and > debian/control has "Build-Depends: debhelper (>= 10.0.0), binutils (>= > 2.28.0), autotools-dev (>= 20161112.1)" Are you sure you need autotools-dev? By the way, binutils (>= 2.28.0) is wrong, as 2.28-1 is not >= 2.28.0. > So now to talk about the dpkg-shlibdeps warnings. The Debian package > installs the binaries (libmux.so and others) > under usr/lib/tinymux/game/bin, and then for a specific game, one runs > tinymux-install script to install a symbolic link into the current > directory. The install scripts creates a minimal game tree from which to > start a game. So, the server itself never runs directly from the > /usr/lib/tinymux/game/bin directory. That's why it works despite these > warnings. That doesn't matter, as the libs are not searched for in the current dir/the dir of the dependent binary. > But, I agree that suppressing or fixing these warning is a good thing > except that nothing I Google and no man pages I read describe how to > actually go about doing this. dh_shlibdeps(1)/dpkg-shlibdeps(1) "It tells dpkg-shlibdeps (via its -l parameter), to look for private package libraries in the specified directory" > dh_makeshlibs does run but it isn't picking > up the location where libmux.so is placed. The man page for dh_shlibdeps > describes this exact scenario and suggests to run dh_makeshlibs first as > the obvious solution, but that is already happening and it doesn't work. No, it describes a scenario with a public shared lib in a separate package. Your problem is caused by a private shared lib in a private path. > Solutions point to using override_dh_shlibdeps, but then, I need to pass it > all the right arguments and I think the problem is really dh_makeshlibs. I don't think so. -- WBR, wRAR signature.asc Description: PGP signature
Bug#871693: RFS: tinymux/2.10.1.14-1 [RC]
Found a way to suppress/fix the warnings. On Mon, Aug 14, 2017 at 2:55 PM, Stephen Dennis wrote: > Ah. missed the compat level because I changed the it to version 10 in the > debian/control file. Next upload will have debian/compat of 10, and > debian/control has "Build-Depends: debhelper (>= 10.0.0), binutils (>= > 2.28.0), autotools-dev (>= 20161112.1)" > > So now to talk about the dpkg-shlibdeps warnings. The Debian package > installs the binaries (libmux.so and others) under usr/lib/tinymux/game/bin, > and then for a specific game, one runs tinymux-install script to install a > symbolic link into the current directory. The install scripts creates a > minimal game tree from which to start a game. So, the server itself never > runs directly from the /usr/lib/tinymux/game/bin directory. That's why it > works despite these warnings. > > But, I agree that suppressing or fixing these warning is a good thing > except that nothing I Google and no man pages I read describe how to > actually go about doing this. dh_makeshlibs does run but it isn't picking > up the location where libmux.so is placed. The man page for dh_shlibdeps > describes this exact scenario and suggests to run dh_makeshlibs first as > the obvious solution, but that is already happening and it doesn't work. > Solutions point to using override_dh_shlibdeps, but then, I need to pass it > all the right arguments and I think the problem is really dh_makeshlibs. > Nothing I've found describes how dh_makeshlibs does its job or how to > control it. Sorry, but I'm always at a loss for how to control these builds. > > On Mon, Aug 14, 2017 at 12:15 PM, Andrey Rahmatullin > wrote: > >> On Thu, Aug 10, 2017 at 11:11:26PM +0500, Andrey Rahmatullin wrote: >> > The build logs says: >> > >> > dpkg-shlibdeps: warning: cannot find library libmux.so needed by >> > debian/tinymux/usr/lib/tinymux/game/bin/stubslave (ELF format: >> > 'elf64-x86-64' abi: '0201003e'; RPATH: '') >> > dpkg-shlibdeps: warning: cannot find library libmux.so needed by >> > debian/tinymux/usr/lib/tinymux/game/bin/sample.so (ELF format: >> > 'elf64-x86-64' abi: '0201003e'; RPATH: '') >> > dpkg-shlibdeps: warning: cannot find library libmux.so needed by >> > debian/tinymux/usr/lib/tinymux/game/bin/sqlproxy.so (ELF format: >> > 'elf64-x86-64' abi: '0201003e'; RPATH: '') >> > dpkg-shlibdeps: warning: cannot find library libmux.so needed by >> > debian/tinymux/usr/lib/tinymux/game/bin/netmux (ELF format: >> 'elf64-x86-64' >> > abi: '0201003e'; RPATH: '') >> > dpkg-shlibdeps: warning: cannot find library libmux.so needed by >> > debian/tinymux/usr/lib/tinymux/game/bin/sqlslave.so (ELF format: >> > 'elf64-x86-64' abi: '0201003e'; RPATH: '') >> > dpkg-shlibdeps: warning: cannot find library libmux.so needed by >> > debian/tinymux/usr/lib/tinymux/game/bin/sum.so (ELF format: >> 'elf64-x86-64' >> > abi: '0201003e'; RPATH: '') >> This is still happening. How are these libs going to find libmux.so? If >> you thnk nothing needs to be fixed at the upstream side then please tell >> dh_shlibdeps where to look for this lib. >> >> > Please switch to the debhelper compat level 10. >> debian/compat is still 9. >> >> -- >> WBR, wRAR >> > >
Bug#867727: RFS: parlatype/1.5.1-1 [ITP] follow-up
Follow-up after uploading new version 1.5.2-1. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/parlatype Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/parlatype/parlatype_1.5.2-1.dsc Changes since last upload to mentors: * New upstream bugfix release * Bump standards version to 4.0.1 (no changes) * Switch compat level 9 to 10 * Bump debhelper to 10 in Build-Depends * Remove dh-autoreconf from Build-Depends * Remove --with autoreconf in rules * Update install path for help files * Update install path for AppStream data * Update icon names (install and copyright) * Install DBus service * Install symbolic icon * Override lintian's hardening-no-fortify-functions: false positive * Add Build-Depends appstream-util and desktop-file-utils for checks * Copyright: change URL format to https Anyone willing to sponsor or review? Regards Gabor Karsay
Bug#872019: marked as done (RFS: dcm2niix/1.0.20170724-1)
Your message dated Tue, 15 Aug 2017 07:50:06 + (UTC) with message-id <1392866842.2383144.1502783406...@mail.yahoo.com> and subject line Re: Bug#872019: RFS: dcm2niix/1.0.20170724-1 has caused the Debian Bug report #872019, regarding RFS: dcm2niix/1.0.20170724-1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 872019: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872019 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for the following package: * Package name: dcm2niix Version : 1.0.20170724-1 Upstream Author : Chris Rorden * URL : https://github.com/rordenlab/dcm2niix * License : BSD Section : science One can check out the package by visiting the following URL: https://anonscm.debian.org/git/debian-med/dcm2niix.git Changes since the last upload: * Upgrade watch file to version 4 * New upstream version 1.0.20170724 * Bump standards version to 4.0.1, no changes required * Add missing get-orig-source target * Build with JPEG support using TurboJPEG Regards, Ghis --- End Message --- --- Begin Message --- >* Package name: dcm2niix G.--- End Message ---
Bug#872196: RFS: dtkwm/0.1.0~20170815-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "dtkwm" * Package name: dtkwm Version : 0.1.0~20170815-1 Upstream Author : Deepin Technology Co., Ltd. * URL : https://www.deepin.org/ * License : GPLv3+ Section : libs It builds those binary packages: libdtkwm-dev - Deepin graphical user interface library (development files) libdtkwm2 - Deepin graphical user interface library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dtkwm Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dtkwm/dtkwm_0.1.0~20170815-1.dsc More information about dtkwm can be obtained from https://github.com/linuxdeepin/dtkwm . Changes since the last upload: dtkwm (0.1.0~20170815-1) unstable; urgency=medium * Initial release (Closes: #871982) Regards, Yangfl