Bug#837210: marked as done (RFS: lua-torch-torch7/0~20160908-ge5ebac6-1)
Your message dated Sat, 10 Sep 2016 09:20:44 + (UTC) with message-id <586198311.4817837.1473499244...@mail.yahoo.com> and subject line Re: Bug#837209: RFS: lua-torch-nn/0~20160908-g9d7b9ea+dfsg-1 has caused the Debian Bug report #837210, regarding RFS: lua-torch-torch7/0~20160908-ge5ebac6-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.) -- 837210: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837210 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Debomatic-amd64: passing http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-torch7/0~20160908-ge5ebac6-1/buildlog Dear mentors, I am looking for a sponsor for my package "lua-torch-torch7" * Package name: lua-torch-torch7 Version : 0~20160908-ge5ebac6-1 Upstream Author : torch developers * URL : github.com/torch/torch7 * License : bsd-3-clause Section : interpreters It builds those binary packages: libtorch-luat - libluaT.so of Torch Package for Torch Framework libtorch-luat-dev - libluaT.so of Torch Package for Torch Framework (dev) libtorch-th - libTH.so of Torch Package for Torch Framework libtorch-th-dev - libTH.so of Torch Package for Torch Framework (dev) lua-torch-torch7 - Torch Package for Torch Framework lua-torch-torch7-dev - Torch Package for Torch Framework (dev) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lua-torch-torch7 Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lua-torch-torch7/lua-torch-torch7_0~20160908-ge5ebac6-1.dsc Changes since the last upload: lua-torch-torch7 (0~20160908-ge5ebac6-1) experimental; urgency=medium * Import upstream snapshot e5ebac6a3d6b14382e4641a8701f23b57e7d6e30. * Remove all patches that were merged to upstream. - fix-spelling-error - fix-32bit-system-abs-failure - TH-cmake-add-version - luaT-cmake-add-version * Use elegant dh_auto_configure instead of hardcoded commands. * Add patch fix-cmake-checkfunctionexists to fix cmake failure. * Refresh symbols control file. * Override lintian misreport. See #539066 * Maintainer is Debian Science Team. * Put myself to Uploaders. -- Best, Lumin --- End Message --- --- Begin Message --- Hi, > I am looking for a sponsor for my package "lua-torch-nn" > I am looking for a sponsor for my package "lua-torch-torch7" both done G.--- End Message ---
Bug#837209: marked as done (RFS: lua-torch-nn/0~20160908-g9d7b9ea+dfsg-1)
Your message dated Sat, 10 Sep 2016 09:20:44 + (UTC) with message-id <586198311.4817837.1473499244...@mail.yahoo.com> and subject line Re: Bug#837209: RFS: lua-torch-nn/0~20160908-g9d7b9ea+dfsg-1 has caused the Debian Bug report #837209, regarding RFS: lua-torch-nn/0~20160908-g9d7b9ea+dfsg-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.) -- 837209: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837209 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Debomatic-amd64: passing http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-nn/0~20160908-g9d7b9ea+dfsg-1/buildlog Dear mentors, I am looking for a sponsor for my package "lua-torch-nn" * Package name: lua-torch-nn Version : 0~20160908-g9d7b9ea+dfsg-1 Upstream Author : torch developers * URL : github.com/torch/nn * License : bsd-3-clause Section : interpreters It builds those binary packages: libtorch-thnn - libTHNN.so of Neural Network Package for Torch Framework libtorch-thnn-dev - libTHNN.so of Neural Network Package for Torch Framework (dev) lua-torch-nn - Neural Network Package for Torch Framework To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lua-torch-nn Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lua-torch-nn/lua-torch-nn_0~20160908-g9d7b9ea+dfsg-1.dsc Changes since the last upload: lua-torch-nn (0~20160908-g9d7b9ea+dfsg-1) experimental; urgency=medium * Import upstream snapshot 9d7b9ea4c9ba38e92dc0186af33ff7c0f323d2a4. * Remove patch 'fix-spelling-errors' which was merged to upstream. * Refresh symbols control file. * Override lintianW: symbols-file-contains-debian-revision due to #539066. -- Best, Lumin --- End Message --- --- Begin Message --- Hi, > I am looking for a sponsor for my package "lua-torch-nn" > I am looking for a sponsor for my package "lua-torch-torch7" both done G.--- End Message ---
Bug#837196: RFS: budgie-desktop/10.2.6-2
control: owner -1 ! control: tags -1 moreinfo >- add debugging symbols packages why? they are autogenerated now https://wiki.debian.org/AutomaticDebugPackages other stuff seems good G.
Bug#837196: RFS: budgie-desktop/10.2.6-2
Hi Gianfranco, the debug packages and symbols are not currently being created since I am using the pre v9 packaging mechanism. I'm sure you remember - budgie-desktop is just very weird under debian & ubuntu and the standard debhelper - all packages seem to be generated but the desktop never launches :/ I look forward to the future budgie-desktop where the maintainer is to recode using C and it should be then possible to throw away all the pre V9 stuff and use standard debhelper packaging techniques. As an aside, a new version of budgie-desktop is in the wings upstream - when this is officially released, I will retest with a standard debhelper packaging to see if the extensive changes in this new version fixes this weird debhelper build issue. David On 10 September 2016 at 10:30, Gianfranco Costamagna < locutusofb...@debian.org> wrote: > control: owner -1 ! > control: tags -1 moreinfo > > > >- add debugging symbols packages > > > why? they are autogenerated now > https://wiki.debian.org/AutomaticDebugPackages > > other stuff seems good > > G. >
Bug#837196: RFS: budgie-desktop/10.2.6-2
Hi, >I'm sure you remember - budgie-desktop is just very weird under debian & >ubuntu and the standard debhelper - all packages seem to be generated but the >desktop never >launches :/ yep I remember >I look forward to the future budgie-desktop where the maintainer is to recode >using C and it should be then possible to throw away all the pre V9 stuff and >use >standard debhelper packaging techniques. > >As an aside, a new version of budgie-desktop is in the wings upstream - when >this is officially released, I will retest with a standard debhelper packaging >to see >if the extensive changes in this new version fixes this weird >debhelper build issue. I hope this gets fixed soon, however I tried to remove the dh_strip calls and dbg packages. and uploaded your version on debomatic-amd64 and my version on debomatic-i386. I see dbg packages automatically generated http://debomatic-amd64.debian.net/distribution#unstable/budgie-desktop/10.2.6-2/buildlog http://debomatic-i386.debian.net/distribution#unstable/budgie-desktop/10.2.6-3/buildlog budgie-core-dbg1.1 MB .deb budgie-core-dev17.5 KB .deb budgie-core232.2 KB .deb budgie-desktop-doc16.5 KB .deb budgie-desktop3.7 KB .deb gir1.2-budgie-desktop-1.04.3 KB .deb libbudgie-plugin0-dbg35.3 KB .deb libbudgie-plugin08.8 KB .deb libbudgietheme0-dbg10.5 KB .deb libbudgietheme032.7 KB .deb libraven0-dbg540.5 KB .deb libraven0117.0 KB .deb budgie-core-dbgsym1.0 MB .deb budgie-core-dev17.6 KB .deb budgie-core249.9 KB .deb budgie-desktop-doc16.6 KB .deb budgie-desktop3.8 KB .deb gir1.2-budgie-desktop-1.04.4 KB .deb libbudgie-plugin0-dbgsym31.1 KB .deb libbudgie-plugin09.1 KB .deb libbudgietheme0-dbgsym8.5 KB .deb libbudgietheme032.8 KB .deb libraven0-dbgsym456.0 KB .deb libraven0128.5 KB .deb sizes are mostly the same, I don't know if you understand my point, because having them will probably mean a new trip in binary-new queue. And they will be deleted soon after. I prefer to just avoid this. (whenever possible of course) thanks G.
Bug#837196: RFS: budgie-desktop/10.2.6-2
Fully understand Gianfranco. thanks for the advice. The package has now been stripped of these dbg and symbols now and uploaded to mentors. Have done a test rebuild of the revised package together with a linitian -i -I of the sources and .deb packages and all looks as the same as the current budgie-desktop package in stretch David On 10 September 2016 at 12:02, Gianfranco Costamagna < locutusofb...@debian.org> wrote: > Hi, > > >I'm sure you remember - budgie-desktop is just very weird under debian & > ubuntu and the standard debhelper - all packages seem to be generated but > the desktop never >launches :/ > > > yep I remember > >I look forward to the future budgie-desktop where the maintainer is to > recode using C and it should be then possible to throw away all the pre V9 > stuff and use >standard debhelper packaging techniques. > > > >As an aside, a new version of budgie-desktop is in the wings upstream - > when this is officially released, I will retest with a standard debhelper > packaging to see >if the extensive changes in this new version fixes this > weird debhelper build issue. > > > I hope this gets fixed soon, however I tried to remove the dh_strip calls > and dbg packages. > > and uploaded your version on debomatic-amd64 > and my version on debomatic-i386. > > I see dbg packages automatically generated > > > > http://debomatic-amd64.debian.net/distribution#unstable/ > budgie-desktop/10.2.6-2/buildlog > > http://debomatic-i386.debian.net/distribution#unstable/ > budgie-desktop/10.2.6-3/buildlog > > budgie-core-dbg1.1 MB .deb > budgie-core-dev17.5 KB .deb > budgie-core232.2 KB .deb > budgie-desktop-doc16.5 KB .deb > budgie-desktop3.7 KB .deb > gir1.2-budgie-desktop-1.04.3 KB .deb > libbudgie-plugin0-dbg35.3 KB .deb > libbudgie-plugin08.8 KB .deb > libbudgietheme0-dbg10.5 KB .deb > libbudgietheme032.7 KB .deb > libraven0-dbg540.5 KB .deb > libraven0117.0 KB .deb > > budgie-core-dbgsym1.0 MB .deb > budgie-core-dev17.6 KB .deb > budgie-core249.9 KB .deb > budgie-desktop-doc16.6 KB .deb > budgie-desktop3.8 KB .deb > gir1.2-budgie-desktop-1.04.4 KB .deb > libbudgie-plugin0-dbgsym31.1 KB .deb > libbudgie-plugin09.1 KB .deb > libbudgietheme0-dbgsym8.5 KB .deb > libbudgietheme032.8 KB .deb > libraven0-dbgsym456.0 KB .deb > libraven0128.5 KB .deb > > sizes are mostly the same, > I don't know if you understand my point, because having them will probably > mean a new trip in binary-new queue. > And they will be deleted soon after. > > I prefer to just avoid this. > (whenever possible of course) > > thanks > > G. >
Bug#827397: RFS: vlc/2.0.3-5+deb7u3
Dear LTS team, Mateusz: On Thu, Jun 16, 2016 at 09:12:47AM +0200, Adam Borowski wrote: > On Thu, Jun 16, 2016 at 06:53:49AM +, Gianfranco Costamagna wrote: > > Hi Adam, > > (answering in general, not in this particular situation) > > > > > > >I've reviewed the upload, but I'm not sure if you coordinated it > > >with the LTS team. I find a contradition: > > > https://lists.debian.org/debian-lts/2016/06/msg00031.html > > >says vlc is no longer supported in wheezy, yet in > > > https://lists.debian.org/debian-lts/2016/06/msg00035.html > > >the quoted mail sounds as if the upload is expected. > > > > > >Should I proceed? > > > > I guess not > > > > In general, for security pocket, you need to do: > > - check/test the patch > > - wait for an ack from security team > > - upload (binary-upload, not sure if source only is allowed, but I think > > not IIRC) on security-master > > e.g. > > The docs on the LTS wiki suggest it is, but I asked to confirm. I think you also need to do the build with -sa, as you need to upload the full sources to security-master. > > BTW according to security tracker wheezy is EOL for that cve, no DSA is > > released, so I guess you won't > > have the ack > > https://security-tracker.debian.org/tracker/CVE-2016-5108 > > The discussion continued after the EOL was mentioned, and Mateusz was > obviously aware of it, thus I assume the RFS he filed was acked in parts of > the discussion that are missing from list archives. > > In any case, the patch is simple and works for me. > > > (well, since there is a patch and an upload ready they might give an > > exception, but I think > > asking before is the right way to deal with this bug) > > Right... which is exactly what I'm doing right now :) > Wheezy has been handed off from security to the LTS team. We haven't heard anything on this RFS for nearly 3 months. Can you see if there is anythin that you'd like. For example, I don't see a DLA enrty in dla-needed for VLC (nor I'd expect one considering VLC is not declared as support iirc). Anyway I suppose that a one-shot update can't really harm anybody. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
atomic_LIBS (was: FTBFS: how to test fixes)
hi, On 09/06/2016 12:44 PM, Christian Seiler wrote: [...] > I didn't think about adding -latomic to the linker flag list > directly via -Wl. I just tested your suggestion and it's really > funny; libtool does mangle your line and separate it into: > > -Wl,--push-state -Wl,--as-needed -Wl,-latomic -Wl,--pop-state > > but since there's no direct -l argument, it actually does work > and the things are kept together and in order. > > @Muri: use this line in the patch instead: > AC_CHECK_LIB([atomic], [__atomic_add_fetch_8], > [atomic_LIBS="-Wl,--push-state,--as-needed,-latomic,--pop-state"], > [atomic_LIBS=""]) > > That way, the libatomic dependency will only be picked up on > platforms where it's necessary. i've created a pull request for that change upstream[0], but the ci seems not to like the patch: https://travis-ci.org/dkopecek/usbguard/builds/158517934 - i'm not sure what to make of that, i don't really see a difference in the successfull builds and the ones that failed. [0] https://github.com/dkopecek/usbguard/pull/126 cheers, -- muri signature.asc Description: OpenPGP digital signature
Re: atomic_LIBS
On 09/10/2016 03:22 PM, Muri Nicanor wrote: > On 09/06/2016 12:44 PM, Christian Seiler wrote: > [...] >> I didn't think about adding -latomic to the linker flag list >> directly via -Wl. I just tested your suggestion and it's really >> funny; libtool does mangle your line and separate it into: >> >> -Wl,--push-state -Wl,--as-needed -Wl,-latomic -Wl,--pop-state >> >> but since there's no direct -l argument, it actually does work >> and the things are kept together and in order. >> >> @Muri: use this line in the patch instead: >> AC_CHECK_LIB([atomic], [__atomic_add_fetch_8], >> [atomic_LIBS="-Wl,--push-state,--as-needed,-latomic,--pop-state"], >> [atomic_LIBS=""]) >> >> That way, the libatomic dependency will only be picked up on >> platforms where it's necessary. > > i've created a pull request for that change upstream[0], but the ci > seems not to like the patch: > https://travis-ci.org/dkopecek/usbguard/builds/158517934 - i'm not sure > what to make of that, i don't really see a difference in the successfull > builds and the ones that failed. Ah, they are apparently using a version of binutils that doesn't support --push-state. In that case, you should use the following in configure.ac: AC_CHECK_LIB([atomic], [__atomic_add_fetch_8], [ __saved_LIBS="$LIBS" LIBS="$LIBS -Wl,--push-state,--as-needed,-latomic,--pop-state" AC_LINK_IFELSE([AC_LANG_PROGRAM()], [atomic_LIBS="-Wl,--push-state,--as-needed,-latomic,--pop-state"], [atomic_LIBS="-latomic"] ) LIBS="$__saved_LIBS" ], [atomic_LIBS=""]) AC_SUBST([atomic_LIBS]) That will check if the linker flags for --as-needed work, and if they don't, -latomic is just added unconditionally. This is not ideal on platforms where libatomic is available, but not required and ld doesn't support --push-state (because then a spurious dependency on libatomic will be added to the compiled program), but at the very least will that always produce a working binary. Regards, Christian
Bug#837319: RFS: cdist/4.3.1-2
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "cdist" * Package name: cdist Version : 4.3.1-2 Upstream Author : Nico Schottelius * Url : http://www.nico.schottelius.org/software/cdist/ * Licenses: GPL-3+,GPL-3 Section : admin It builds those binary packages: * cdist * cdist-doc To access futher information about this package, visit the following URL: http://mentors.debian.net/package/cdist Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/cdist/cdist_4.3.1-2.dsc Alternatively, you can access package debian/ directory via git from URL: https://anonscm.debian.org/cgit/users/kaction-guest/cdist.git More information about cdist can be obtained from http://www.nico.schottelius.org/software/cdist/ Changes since last upload: * Rebuild for unstable to get latest sphinx dependency (Closes: #837311) Regards, Dmitry Bogatov
Bug#837319: Bug#837312: nmu: cdist_4.3.1-1
Hi,
Mattia Rizzolo wrote:
> On Sat, Sep 10, 2016 at 03:03:42PM +0200, Axel Beckert wrote:
> > cdist-doc depends on "sphinx-common (<< 1.4.5.0~), sphinx-common (>=
> > 1.4.5)". This causes the following issues:
> >
> > * It's uninstallable in unstable
> > * sphinx doesn't migrate to testing[0]
> >
> > Rebuilding against sphinx 1.4.6-1 inside a clean chroot
> > (e.g. pbuilder) helps[1]. So please schedule a BinNMU on architecture
> > "all" for cdist:
> >
> > nmu cdist_4.3.1-1 . all . unstable . -m "Rebuild documentation against
> > sphinx 1.4.6"
[…]
> You need to ask for a full upload, perhaps by means of a RC bug (given
> that it's blocking other stuff, and it is uninstallable)
*sigh* I'd reopened and reassiged it if I were you. Not doing that now
myself because there is also a sponsorship request for cdist at
https://bugs.debian.org/837319 which will solve this anyways.
Dmitry: Will have a look at #837319. :-)
> While on it I'd investigate why it has such particular needs of a so
> weird depdency.
That's something the sphinx maintainers should have a look at it as
they seem to have decided that it's needed, otherwise they probably
wouldn't have made the effort to implement it.
Since not every sphinx reverse dependency which uses
${sphinxdoc:Depends} (about 527 source packages in unstable according
to [1]) seems to have that rather strict dependency (thanks to Mattia
for pointing that out on IRC :-), I wonder what makes cdist's package
build causing that strict dependency.
Regards, Axel
--
,''`. | Axel Beckert , http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#837319: Bug#837311: cdist: FTBFS with some additional packages being installed: ImportError: No module named sphinx_rtd_theme
Control: tag -1 + moreinfo unreproducible
Control: severity -1 minor
Hi Dmitry,
Dmitry Bogatov wrote:
> > cdist-doc depends on "sphinx-common (<< 1.4.5.0~), sphinx-common (>=
> > 1.4.5)" via ${sphinxdoc:Depends}. While this is generally fine, it also
> > means that cdist needs to be rebuilt against every new sphinx upstream
> > version.
> >
> > At the moment this causes the following issues:
> >
> > * cdist-doc is uninstallable in unstable.
> > * sphinx doesn't migrate to testing because it would break cdist-doc
> > there.
>
> Thanks for report. I will rebuild aganist sphinx/sid and upload new
> cdist revision.
Thanks. Will sponsor it (see below).
> > It though builds fine for me in pbuilder, i.e. inside a clean chroot
> > with just its build-dependencies and nothing else.
> >
> > So it seems that if Python 2.7 is also installed (and maybe some other
> > packages, too) but python-sphinx-rtd-theme (compared to the
> > build-dependency python3-sphinx-rtd-theme) is not installed, it doesn't
> > build, because Python 2.7 seems favoured over Python 3 and then
> > python-sphinx-rtd-theme would be needed instead of
> > python3-sphinx-rtd-theme.
>
> I can't reproduce it. Just built fine with python3-sphinx-rtd-theme
> installed, python-sphinx-rtd-theme not and with python2.7 installed.
Ok, that means there must be another package which causes this.
> > One probable solution which comes to my mind is a "Build-Conflicts:
> > python2.7", but I'm not sure if that's a really good idea.
>
> I am afraid of such measures. For example, it would mean, that I
> wouldn't be able to build without sbuild. (My computer have packages,
> that depends on python2.7)
Exactly that's why I think it's probably not a good idea.
> More input is welcome.
I'll dig deeper and let you.
But that also means that your upload at
http://mentors.debian.net/package/cdist will not fix this bug since
the bug is about a missing Build-Conflicts, not about the
uninstallability. The latter was just context on how I stumbled upon
that bug. #837312 is the actual uninstallability bug (which IMHO has
been prematurely closed by Mattia, because it won't work as BinNMU).
So please either drop the "(Closes: #837311)" from the changelog
completely or change it to "(Closes: #837312)".
Regards, Axel
--
,''`. | Axel Beckert , http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#837319: Bug#837312: nmu: cdist_4.3.1-1
> *sigh* I'd reopened and reassiged it if I were you. Not doing that now
> myself because there is also a sponsorship request for cdist at
> https://bugs.debian.org/837319 which will solve this anyways.
>
> Dmitry: Will have a look at #837319. :-)
Fine.
> > While on it I'd investigate why it has such particular needs of a so
> > weird depdency.
>
> That's something the sphinx maintainers should have a look at it as
> they seem to have decided that it's needed, otherwise they probably
> wouldn't have made the effort to implement it.
>
> Since not every sphinx reverse dependency which uses
> ${sphinxdoc:Depends} (about 527 source packages in unstable according
> to [1]) seems to have that rather strict dependency (thanks to Mattia
> for pointing that out on IRC :-), I wonder what makes cdist's package
> build causing that strict dependency.
dh_linktree. Replacing files (images, fonts, ...) with symbolic links
in deduplicate mode.
I could drop it, it would result in increased binary package size and,
what bothers me more, several instances of same file in my /usr.
Sorry, I do not follow very well about situation. I beleive -2
revision should solve issue, isn't it?
Bug#837319: Bug#837311: cdist: FTBFS with some additional packages being installed: ImportError: No module named sphinx_rtd_theme
> But that also means that your upload at > http://mentors.debian.net/package/cdist will not fix this bug since > the bug is about a missing Build-Conflicts, not about the > uninstallability. The latter was just context on how I stumbled upon > that bug. #837312 is the actual uninstallability bug (which IMHO has > been prematurely closed by Mattia, because it won't work as BinNMU). > > So please either drop the "(Closes: #837311)" from the changelog > completely or change it to "(Closes: #837312)". On mentors.
Bug#837319: Bug#837312: nmu: cdist_4.3.1-1
Hi Dmitry,
On Sat, Sep 10, 2016 at 05:09:20PM +0300, Dmitry Bogatov wrote:
> > Since not every sphinx reverse dependency which uses
> > ${sphinxdoc:Depends} (about 527 source packages in unstable according
> > to [1]) seems to have that rather strict dependency (thanks to Mattia
> > for pointing that out on IRC :-), I wonder what makes cdist's package
> > build causing that strict dependency.
>
> dh_linktree. Replacing files (images, fonts, ...) with symbolic links
> in deduplicate mode.
>
> I could drop it, it would result in increased binary package size and,
> what bothers me more, several instances of same file in my /usr.
Please drop it. dh_sphinxdoc replaces the JS files with correct symlinks,
so you do not need to care about it.
(It does not replace the images though, but they are few hundred bytes
each, so linking them will not have much sense.)
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#837319: Bug#837311: cdist: FTBFS with some additional packages being installed: ImportError: No module named sphinx_rtd_theme
Hi Dmitry, our mails once again have crossed each other. :-) Dmitry Bogatov wrote: > > So please either drop the "(Closes: #837311)" from the changelog > > completely or change it to "(Closes: #837312)". > > On mentors. Do you want me to upload this directly or do you want me to wait for the "Build-Conflics: python-sphinx" fix, too? Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#837319: Bug#837311: cdist: FTBFS with some additional packages being installed: ImportError: No module named sphinx_rtd_theme
> our mails once again have crossed each other. :-) > > Dmitry Bogatov wrote: > > > So please either drop the "(Closes: #837311)" from the changelog > > > completely or change it to "(Closes: #837312)". > > > > On mentors. > > Do you want me to upload this directly or do you want me to wait for > the "Build-Conflics: python-sphinx" fix, too? Now, I think. After all, build conflicts is internal problem, and uninstallable documentation is user-visible.
Bug#837319: Bug#837311: cdist: FTBFS with some additional packages being installed: ImportError: No module named sphinx_rtd_theme
Hi Dmitry, Dmitry Bogatov wrote: > > Do you want me to upload this directly or do you want me to wait for > > the "Build-Conflics: python-sphinx" fix, too? > > Now, I think. After all, build conflicts is internal problem, and > uninstallable documentation is user-visible. Will do then. Thanks for the feedback! Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#837319: Bug#837312: nmu: cdist_4.3.1-1
> On Sat, Sep 10, 2016 at 05:09:20PM +0300, Dmitry Bogatov wrote:
> > > Since not every sphinx reverse dependency which uses
> > > ${sphinxdoc:Depends} (about 527 source packages in unstable according
> > > to [1]) seems to have that rather strict dependency (thanks to Mattia
> > > for pointing that out on IRC :-), I wonder what makes cdist's package
> > > build causing that strict dependency.
> >
> > dh_linktree. Replacing files (images, fonts, ...) with symbolic links
> > in deduplicate mode.
> >
> > I could drop it, it would result in increased binary package size and,
> > what bothers me more, several instances of same file in my /usr.
>
> Please drop it. dh_sphinxdoc replaces the JS files with correct symlinks,
> so you do not need to care about it.
>
> (It does not replace the images though, but they are few hundred bytes
> each, so linking them will not have much sense.)
What is wrong with one revision of cdist on every *upstream* version
of sphinx? I took me no more then 20 minutes to make one.
I really, really dislike files duplication, however small they are.
Bug#837196: marked as done (RFS: budgie-desktop/10.2.6-2)
Your message dated Sat, 10 Sep 2016 16:25:56 + (UTC) with message-id <2025308401.5083600.1473524756...@mail.yahoo.com> and subject line Re: Bug#837196: RFS: budgie-desktop/10.2.6-2 has caused the Debian Bug report #837196, regarding RFS: budgie-desktop/10.2.6-2 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.) -- 837196: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837196 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 my package "budgie-desktop" * Package name: budgie-desktop Version : 10.2.6-2 Upstream Author : i...@solus-project.com * URL : https://github.com/solus-project/budgie-desktop * License : LGPL-2.1/GPL2.0 Section : x11 It builds those binary packages: budgie-core - Core package for Budgie-Desktop budgie-core-dbg - Debug core package for Budgie-Desktop budgie-core-dev - Development package for budgie-desktop budgie-desktop - Desktop package for budgie-desktop budgie-desktop-doc - documentation files for the budgie-desktop gir1.2-budgie-desktop-1.0 - GNOME introspection library for budgie-desktop libbudgie-plugin0 - Plugin library for budgie-desktop libbudgie-plugin0-dbg - Debug plugin library for budgie-desktop libbudgietheme0 - Theme library for budgie-desktop libbudgietheme0-dbg - Debug theme library for budgie-desktop libraven0 - Raven library for budgie-desktop libraven0-dbg - Debug Raven library for budgie-desktop To access further information about this package, please visit the following URL: https://mentors.debian.net/package/budgie-desktop Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/budgie-desktop/budgie-desktop_10.2.6-2.dsc Notes: upstream has produced a patch to fix the serious GNOME-3.21-->GNOME 3.22 build issue for budgie-desktop. This has been added to debian/patches Changes since the last upload: * Bug-fix release * bug-fix for GNOME 3.22 build (Closes: #837077) - add upstream maintainer patch to enable build due to mutter api change * bug-fix for nm-applet dbus-launch (Closes: #836083) - replace dbus-launch with dbus-run-session to display nm-applet on budgie-desktop panel * Packaging changes - maintainer change of email address - add debugging symbols packages * inc patch to display budgie-icon for lightdm greeter (LP:#1562182) Regards, David Mohammed --- End Message --- --- Begin Message --- Hi >Have done a test rebuild of the revised package together with a linitian -i -I >of the sources and .deb packages and all looks as the same as the current >budgie-desktop package in stretch I like this one, sponsored! G.--- End Message ---
Bug#834268: RFS: open-invaders/0.3-5 [NMU] [ITA]
On Wed, Aug 17, 2016 at 10:59:46PM +0200, Hanno 'Rince' Wagner wrote:
> I am packaging open-invaders, a clone of space invaders. I was able to
> "port" it (with a lot of help from friends) to gcc-6, but I have a
> problem with the used libraries.
>
> I am able to successfully compile and package open-invaders. But when
> I want to start it, the initialization of allegro4 seems to fail:
>
> [~]$ open-invaders
> /usr/share
> Segmentation fault
>
>
> I used gdb and found that open-invaders crashed while initializing
> allegro:
>
> (gdb) run
> Starting program: /usr/share/open-invaders/open-invaders
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> /usr/share
> [New Thread 0x7433a700 (LWP 7044)]
> [Thread 0x7433a700 (LWP 7044) exited]
>
> Thread 1 "open-invaders" received signal SIGSEGV, Segmentation fault.
> 0x77704cc7 in install_timer () from
> /usr/lib/x86_64-linux-gnu/liballeg.so.4.4
> (gdb) bt
> #0 0x77704cc7 in install_timer () from
> /usr/lib/x86_64-linux-gnu/liballeg.so.4.4
> #1 0xfbd5 in initialise_game () at init.cc:521
> #2 0x74f4 in main (argc=1, argv=0x7fffe668) at main.cc:81
> (gdb)
My splat is different:
[~]$ open-invaders
/usr/share
Allegro initialised...
Loading graphics...
Fatal error: Could not load file ship.pcx
Fatal error: Could not load file invader_top.pcx
Aborted (core dumped)
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
#1 0x7f679d2c740a in __GI_abort () at abort.c:89
#2 0x7f679df90101 in ?? () from /usr/lib/x86_64-linux-gnu/liballeg.so.4.4
#3
#4 0x7f679def975e in blit () from /usr/lib/x86_64-linux-gnu/liballeg.so.4.4
#5 0x565519e152db in load_data_files () at init.cc:92
#6 0x565519e0f8af in define_sprites () at graphics.cc:317
#7 0x565519e08377 in main (argc=1, argv=0x7ffdfb9aba98) at main.cc:89
Curiously, when you start the game from the directory you have unpacked the
sources to, it does work. As if, it tried to load sprites from the current
dir. Could that be?
.--[ src/init.cc lines 619..642 ]
BITMAP *oi_load_graphic(std::string filename, std::string defsymbol)
{
BITMAP *loaded_graphic;
ostringstream filenamebuffer;
filenamebuffer << "./data/" << filename;
loaded_graphic=load_bitmap(filenamebuffer.str().c_str(),NULL);
#ifdef ALLEGRO_LINUX
if(!loaded_graphic)
{
loaded_graphic=load_bitmap(defsymbol.c_str(), NULL);
}
#endif
if(!loaded_graphic)
{
cout << "Fatal error: Could not load file " << filename << "\n";
return NULL;
}
return loaded_graphic;
}
`
and the part that dies is:
.--[ src/init.cc lines 81..93 ]
switch(aliens)
{
case 0:
alienbuffer=oi_load_graphic("invader_top.pcx",GFX_ALIEN_TOP); break;
case 1:
alienbuffer=oi_load_graphic("invader_middle.pcx",GFX_ALIEN_MIDDLE); break;
case 2:
alienbuffer=oi_load_graphic("invader_bottom.pcx",GFX_ALIEN_BOTTOM); break;
case 3:
alienbuffer=oi_load_graphic("invader_bottom.pcx",GFX_ALIEN_BOTTOM); break;
}
for(int animframes=0; animframes<3; animframes++)
{
alien[aliens][animframes]=create_bitmap(64,64);
splat here-->
blit(alienbuffer,alien[aliens][animframes],animframes*64,0,0,0,64,64);
}
`
Thus:
1. please make the part that says "Fatal" indeed fatal; returning NULL does
nothing good if the return value never gets checked. It'd be good to die
immediately, gracefully restoring the screen resolution. At least XFCE and
Gnome 2[1] completely lose your screen setup in this case, I guess most if
not all of other window managers fail in similar ways. I need to manually
restore the resolution, turn on the other monitor, set the correct one as
primary, re-configure their layout, etc. Not nice.
2. you install everything (sprites and sounds) to /usr/share/open-invaders/
rather than ./data/, please make the code use packaged paths.
Meow!
[1]. I'm too lazy to check how others handle such failures these days.
--
Second "wet cat laying down on a powered-on box-less SoC on the desk" close
shave in a week. Protect your ARMs, folks!
Re: downtimed/1.0-1
On Tue, Aug 23, 2016 at 11:10:27PM +0200, Jörg Frings-Fürst wrote: > I have a new version of downtimed ready for a review. > The package is uploaded to mentors[1]. > Please can someone review this package? Uploaded. It looks like regular sponsors rely on automation these days, and requests without a RFS bug fall through the cracks. Thus, it'd be good if you filed RFSes in the future. Meow! -- Second "wet cat laying down on a powered-on box-less SoC on the desk" close shave in a week. Protect your ARMs, folks!
Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt
Dear Boyuan, Dmitry, On Thu, Sep 08, 2016 at 12:52:29PM +0300, Dmitry Ivanov wrote: > I am the upstream developer of QEverCloud library. Sorry for the > interference, I'd just like to clarify a bit what QEverCloudGenerator > is and how it is intended to work. Please don't apologise -- there's a reason Debian has these discussions in public. Thank you for your very valuable input. (I won't CC you after this message, so if you want to follow subsequent discussion please subscribe to the Debian bug report.) On Thu, Sep 08, 2016 at 06:36:48AM +0800, Boyuan Yang wrote: > He just told me it is not possible, since the generator needs to be > updated. Update in Evernote thrift files will simply leads to FTBFS > without the update in the generator. > [...] > Take a look at Evernote official SDK) and the backward compatibility > of the API. Not updating API will not cause problems, ^^ This is the most important part of your message. If an Evernote API change would cause qevercloud to become useless, it would make sense to package the Thrift IDL files separately. When those were updated, qevercloud would FTBFS, and that would be a good thing because it would alert us that the package was broken. However, as you say, it turns out that the Evernote API is backwards compatible. Even if qevercloud lagged behind other Debian packages using the Thrift IDL, we would want to keep qevercloud in Debian alongside those other packages, becauae QEverCloud would remain useful. So, in conclusion, it's okay to have multiple copies of the Thrift IDL files in the archive. > > I had some discussions to the current maintainer of QEverCloud about > > the possibility of updating thrift IDL files and regenerate again. > > https://github.com/d1vanov/QEverCloud/issues/5 In that GitHub thread, there is mention of a parsing tool called 'lemon'. Dmitry suggests packaging that separately, but you say it's not necessary. Could you explain why? Where can I find out about that tool? Please don't be afraid of increasing the number of packages in Debian. One of Debian's strengths, compared to other distributions, is binary package granularity. This is good for both package maintainers and users, for all sorts of reasons. > Are we talking about the same package? :p > > I ran `apt-get source ebib' and got ebib v4.5.2. The debian/rules is > nothing more > than one line of `dh $@ --parallel --with elpa'. Are you sure? There has never been ebib version 4.5.2. The version I meant was 2.6.3-1 in unstable. Try `debcheckout ebib`. * * * To summarise our discussion so far: - qevercloudgenerator should not be packaged separately because it is not useful for anything other than building qevercloud. - the source package containing qevercloudgenerator should embed a copy of the latest Thrift IDL that it is compatible with - ideally qevercloudgenerator will be run during the qevercloud package build, though a promise that it can be run is sufficient for the ftpmasters - status of lemon parser currently unclear Please let me know if I've misunderstood anything in writing this summary, and thanks again for the work you've both done. -- Sean Whitton signature.asc Description: PGP signature
git-import-orig: work around a .gitignore file ignoring debian/ ?
Hi, I maintain a package and the latest release tarball from source unfortunately contains a .gitignore file listing debian/. I can't import it in my git copy with "gbp import-orig --uscan" and patch it in debian/patches afterwards, since as soon as the new tarball would be imported, the whole debian/ directory would be ignored by git (it's a chicken and egg problem). Upstream has since removed that file from his GitHub repository and it won't be a problem for the next release, but still, I have to package this one for now. I initially thought to repack the source by slightly modifying debian/copyright and debian/watch, but many documentations say that repacking is rarely necessary outside of DFSG-compliance problems. After a bit fo googling, I couldn't find any kind of document listing the reasons that are considered as valid for repacking a source. So my question is: is there a better way to work around this problem, or is is a valid reason for repacking a source tarball ? Subsidiary question: if repacking is indeed the way to go, what would be a good repack suffix ? Thanks, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature
Re: git-import-orig: work around a .gitignore file ignoring debian/ ?
On Sat, 10 Sep 2016 23:53:40 +0200, Raphaël Halimi wrote: > I maintain a package and the latest release tarball from source > unfortunately contains a .gitignore file listing debian/. I can't import > it in my git copy with "gbp import-orig --uscan" and patch it in > debian/patches afterwards, since as soon as the new tarball would be > imported, the whole debian/ directory would be ignored by git (it's a > chicken and egg problem). % cat debian/gbp.conf [import-orig] filter = .gitignore Cheers, gregor -- .''`. Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Pink Floyd: The trial signature.asc Description: Digital Signature
Bug#832941: RFS: 4pane
control: tag -1 +moreinfo control: owner -1 ! Dear David, Thank you for your work to bring this new package to Debian! I can't sponsor the upload, but I hope this review is useful to you. I've split it into two sections: things that I would consider must-fixes before an upload to Debian, and suggested improvements. The latter aren't strictly necessary, but they would help demonstrate to a potential sponsor that you are committed to maintaining this package in Debian. Must-fixes/clarifications: 1. The changelog should contain exactly one entry, closing the ITP. The current changelog suggests that 4pane has already been uploaded to Debian. 2. Why doesn't 4pane work on archs other than i386, amd64, hurd-i386? (an eclectic list!) 3. The Vcs-* fields should point to a repo/branch containing the source package, not the upstream master branch. 4. I think that it would be clearer to express the wxWindows license as a dual-license: "GPL-2+ or wxWindows", with separate license paragraphs for each of those. Suggestions: 1. I'd be very grateful if you'd put this source package in a git repository. That way, I can use `git diff` to review changes that you've made in response to my comments. 2. At least PACKAGERS, README are missing a trailing newline. 3. The "but may be used by others" line in the manpage doesn't make much sense. Normally this is used to indicate that a manpage written by a Debian contributor is used in a Debian derivative, but of course any copy of a manpage written by *upstream* gets used by others. 4. Why is there an additional copy of the manpage in the debian/ subdir? 5. "As well as standard file manager things" I would suggest s/things/functionality/. Also, the scare quotes around 'terminal emulator', 'grep' etc. aren't needed and could be confusing. 6. Can Vcs-Git: use a secure protocol? https:// rather than git://. 7. The debian/* paragraph in d/copyright is redundant. 8. The Debian menu system is deprecated. You seem to be installing a FreeDesktop.org desktop file into /usr/share/4Pane/rc. Please install that as a desktop file that will be picked up by desktop environments -- see Debian Policy 9.6. 9. I think the html docs should go in /usr/share/doc/4pane/html. Then someone just looking for the changelog, README etc. need not hunt through the html files. 10. You're inconsistent about 4pane versus 4Pane. For example, you use /usr/share/4Pane but /usr/share/doc/4pane (with 4Pane as a symlink). Since the package is 4pane, you should use '4pane' in all directories the package uses (the compatibility symlinks from 4Pane to 4pane are fine). 11. I'm not familiar with wxWidgets practices, but is it unavoidable to include sections of code from the wxWidgets sources, as you describe in LICENSE? Is it not possible to call library functions instead? Since you link against libwxgtk I assume that it isn't possible to replace the copied code with library calls, but I'd appreciate it if you could confirm that. 12. Please consider using dh_autoreconf to ensure that the package's build system can be reproduced from the source code provided I haven't tried installing and running the package yet, but hopefully the above is enough to be going on with. -- Sean Whitton signature.asc Description: PGP signature
Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt
Hi Sean, 2016-09-11 5:46 GMT+08:00 Sean Whitton : > In that GitHub thread, there is mention of a parsing tool called > 'lemon'. Dmitry suggests packaging that separately, but you say it's > not necessary. Could you explain why? Where can I find out about that > tool? > "apt install lemon" will find the tool. It is part of sqlite3. > - status of lemon parser currently unclear This is fixed in the RFS of qevercloud before already. Of course we are using the lemon parser from Debian. The bundled source code of lemon is discarded in the source package. Sorry I didn't update the situation on that Github thread, which is a little bit outdated. > If an Evernote API change would cause qevercloud to become useless, it > would make sense to package the Thrift IDL files separately. When those > were updated, qevercloud would FTBFS, and that would be a good thing > because it would alert us that the package was broken. > > However, as you say, it turns out that the Evernote API is backwards > compatible. Even if qevercloud lagged behind other Debian packages > using the Thrift IDL, we would want to keep qevercloud in Debian > alongside those other packages, becauae QEverCloud would remain useful. > So, in conclusion, it's okay to have multiple copies of the Thrift IDL > files in the archive. I would like to return to the very beginning of the problem: QEverCloud upstream source code contains some generated cpp codes but did not provide the direct way to regenerate them *within the source code*. (Dmitry keeps the custom generator together with instructions of regeneration inside another public Git repository, and the thrift IDL files needed for regeneration is in another public Git repository kept by Evernote.) Since Debian Policy (or at least ftp-master) requires at least the possibility to regenerate all generated files (I believe they were thinking about files generated by autoconf/automake), so I repacked qevercloud and included qevercloudgenerator and evernote-thrift files inside qevercloud source repository. So far everthing is fine, but this is the point opinions diverge. You suggested the separate packaging of qevercloudgenerator, but now we seems to agree that since it is not useful for anything other than building qevercloud, it should not be packaged separately. Now the problem is focused on the separation of evernote-thrift files. I believe you suggested packaging thrift files alone, since the separated package can be used by other packages (most likely as a Build-Depend?), and to deal with the FTBFS of qevercloud after the version bump of evernote-thrift, we can include multiple copies. Did you suggest the coexistence of multiple versions of evernote-thrift in the Debian repository, for example, "evernote-thrift-1-25" and "evernote-thrift-1-28"? Or if I misunderstood, it is just one package "evernote-thrift" but provides different versions of files inside one binary package (e.g., /usr/share/evernote/thrift/1.25/foobar and /usr/share/evernote/thrift/1.28/foobar)? Personally I am against the separated package of evernote-thrift, and the main reason is that it is not useful; thrift files are technically used by no one other than evernote people; developers are encouraged/guided to use official Evernote SDK released by evernote, which is already a generated project from the thrift files; no one else is parsing thrift files by him/herself. There was a reason of FTBFS, but the coexistence of different versions can solve this problem. But don't forget that we only wanted to deal with the policy violation. I may package evernote-thrift files if you insist, but please tell me your preference on the coexistence of multiple version (as stated above). > Are you sure? There has never been ebib version 4.5.2. The version I > meant was 2.6.3-1 in unstable. Try `debcheckout ebib`. OK I got the correct version now (2.5.4 though, I am using testing). It is really weird, what was I looking at before? :-| > * * * > > To summarise our discussion so far: > > - qevercloudgenerator should not be packaged separately because it is > not useful for anything other than building qevercloud. Sure. > > - the source package containing qevercloudgenerator should embed a copy > of the latest Thrift IDL that it is compatible with > Yes. Personally I think the embedded copy has no special functions but to make sure the regeneration really works and makes ftp-master people and those who examines this package against Debian Policy happy. > - ideally qevercloudgenerator will be run during the qevercloud package > build, though a promise that it can be run is sufficient for the > ftpmasters Yes, and in current building instruction we are choosing to run the regeneration. After all this is a really interesting problem, a combination of automake/autoconf generated files and the versioning/packaging problem of shared libraries. I have heard that in the (unreleased) debhelper compat level 10 the regenerati
Bug#836709: RFS: 9wm/1.3.9-1 (For real this time)
Control: reopen -1 The upstream release issue has now been addressed. Apologies for posting this before it was ready but everything is good to go now To access further information about this package, please visit the following URL: https://mentors.debian.net/package/9wm Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/9/9wm/9wm_1.3.9-1.dsc Changes since the last upload: 9wm (1.3.9-1) unstable; urgency=medium * New upstream release * Fix manpage typo (Closes: #836314) -- Jacob Adams Sun, 04 Sep 2016 21:48:37 -0400 -- Jacob Adams GPG Key: AF6B 1C26 E2D0 A988 432B 94F4 24C0 2B85 B59F E5A9 signature.asc Description: OpenPGP digital signature
