Bug#836905: marked as done (RFS: dh-elpa/1.3 -- Debian helper tools for packaging emacs lisp extensions)
Your message dated Wed, 07 Sep 2016 11:52:46 +0200 with message-id <87eg4wc9zl@debian.org> and subject line Re: Bug#836905: RFS: dh-elpa/1.3 -- Debian helper tools for packaging emacs lisp extensions has caused the Debian Bug report #836905, regarding RFS: dh-elpa/1.3 -- Debian helper tools for packaging emacs lisp extensions 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.) -- 836905: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836905 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 a new release of dh-elpa. My co-maintainer is a DD but his key in the uploaders' keyring has expired and he can't replace it for a while. * Package name: dh-elpa Version : 1.3 Upstream Author : David Bremner & Sean Whitton * URL : https://pkg-emacsen.alioth.debian.org/ * License : GPL-3+ Section : devel Changes since the last upload: * Fix version comparison in elpa.pm. Quote "0.90" so that the trailing 0 is not lost. * Override debian-watch-file-in-native-package. Download with dget: dget -x http://mentors.debian.net/debian/pool/main/d/dh-elpa/dh-elpa_1.3.dsc Or build it with gbp: gbp clone https://anonscm.debian.org/git/pkg-emacsen/pkg/dh-elpa.git git checkout debian/1.3 git verify-tag debian/1.3 # if you have my key gbp buildpackage Thanks. -- Sean Whitton signature.asc Description: PGP signature --- End Message --- --- Begin Message --- Hi! On 2016-09-07 at 06:51 (CEST), Sean Whitton wrote: [...] > I am looking for a sponsor for a new release of dh-elpa. [...] Uploaded. Thanks for your contribution. -- Matteo F. Vescovi || Debian Developer GnuPG KeyID: 4096R/0x8062398983B2CF7A signature.asc Description: PGP signature --- End Message ---
Bug#836926: Fwd: RFS: opengm/2.3.6+20160905-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opengm" * Package name: opengm Version : 2.3.6+20160905-1 Upstream Author : The OpenGM developers * URL : http://hci.iwr.uni-heidelberg.de/opengm2/ * License : Expat Section : science It builds those binary packages: libopengm-bin - command line tools for OpenGM libopengm-dev - C++ template library for discrete factor graph models libopengm-doc - documentation and examples for OpenGM python-opengm - Python interface to OpenGM python-opengm-doc - documentation for the Python interface to OpenGM To access further information about this package, please visit the following URL: https://mentors.debian.net/package/opengm Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/opengm/opengm_2.3.6+20160905-1.dsc Successful builds on debomatic: http://debomatic-amd64.debian.net/distribution#unstable/opengm/2.3.6+20160905-1/buildlog Changes since the last upload: * New upstream snapshot. (Closes: #836413) Regards, Ghislain Vaillant
Bug#836926: marked as done (RFS: opengm/2.3.6+20160905-1)
Your message dated Wed, 7 Sep 2016 10:21:04 + (UTC) with message-id <445095593.1686030.1473243664...@mail.yahoo.com> and subject line Re: Bug#836926: Fwd: RFS: opengm/2.3.6+20160905-1 has caused the Debian Bug report #836926, regarding RFS: opengm/2.3.6+20160905-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.) -- 836926: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836926 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 "opengm" * Package name: opengm Version : 2.3.6+20160905-1 Upstream Author : The OpenGM developers * URL : http://hci.iwr.uni-heidelberg.de/opengm2/ * License : Expat Section : science It builds those binary packages: libopengm-bin - command line tools for OpenGM libopengm-dev - C++ template library for discrete factor graph models libopengm-doc - documentation and examples for OpenGM python-opengm - Python interface to OpenGM python-opengm-doc - documentation for the Python interface to OpenGM To access further information about this package, please visit the following URL: https://mentors.debian.net/package/opengm Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/opengm/opengm_2.3.6+20160905-1.dsc Successful builds on debomatic: http://debomatic-amd64.debian.net/distribution#unstable/opengm/2.3.6+20160905-1/buildlog Changes since the last upload: * New upstream snapshot. (Closes: #836413) Regards, Ghislain Vaillant --- End Message --- --- Begin Message --- Hi >I am looking for a sponsor for my package "opengm" I sponsored in deferred/2, to see the current one migrate in testing (I'm thrilled to see if it builds on BE architectures) G.--- End Message ---
Bug#836569: marked as done (RFS: node-js-yaml/3.6.1+dfsg-1 [RFP])
Your message dated Wed, 7 Sep 2016 14:02:28 + (UTC) with message-id <753268417.997968.1473256948...@mail.yahoo.com> and subject line Re: Bug#836569: RFS: node-js-yaml/3.6.1+dfsg-1 [RFP] has caused the Debian Bug report #836569, regarding RFS: node-js-yaml/3.6.1+dfsg-1 [RFP] 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.) -- 836569: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836569 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "node-js-yaml" * Package name: node-js-yaml Version : 3.6.1+dfsg-1 Upstream Author : Dervus Grim * URL : https://github.com/nodeca/js-yaml * License : Expat Section : web It builds this binary package: node-js-yaml - YAML 1.2 parser and serializer To access further information about this package, please visit the following URL: https://mentors.debian.net/package/node-js-yaml Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/n/node-js-yaml/node-js- yaml_3.6.1+dfsg-1.dsc For Debian packaging, it will eventually be found here: https://anonscm.debian.org/cgit/pkg-javascript/node-js-yaml.git Changes since the last upload: * Initial release (Closes: #805411) Regards, Ross Gammon -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial'), (100, 'xenial-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-24-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- Hi, >Il Domenica 4 Settembre 2016 8:09, Ross Gammon ha >scritto:> https://mentors.debian.net/package/node-js-yaml sponsored even if you have an empty dir drwxr-xr-x root/root 0 2016-09-04 07:16 ./usr/bin/ cheers, G.--- End Message ---
Bug#777651: RFS: syncterm/1.0+dfsg-1 [ITP]
control: tags -1 moreinfo
Hi
>remove gcc,
>let sdl 1.2 (remove unused sdl2)
>update versions from unstable
oh... no sdl2 ready code?
>>fixed.
>>i only can test in these archs, but i changed it to => any
>
>Depends: ${shlibs:Depends}, ${misc:Depends}, libsdl1.2 (>= 1.2.15)
libsdl1.2 explicit runtime dependency might be "droppable", did you test it?
just do a build, and open the deb file section debian/control
why libsdl1.2 is not picked up?
>> some (most) of them looks like embedded libraries
>
>it's part of uptream source. can i do something to make it better?
>
yes, remove them, repack the source (debian/copyright has a nice Files-Excluded
feature)
and drop them from copyright.
and package them separately if not yet in debian (and useful outside this
package)
>http://cvs.synchro.net/cgi-bin/viewcvs.cgi/src/sbbs3/zmodem.h?revision=1.54&view=markup
>
>Unfortunately, this was after 1.0 release date, and it was made through
>my work to contact everyone involved and good response from them.
ok, you might package an upstream snapshot, or clarify this in copyright file
>I think that can parse file by file to fine copyright settings.
>i update it, please check,
>I want to the package fit the debian legal requeriments, the code is
>gpl, lgpl and some files bsd. i think that all are dfsg
>The non-dfsg part was cryplib and was removed via patch (the app can be
>used without that lib)
ok
let me know how you want to proceed with the above points
cheers,
G.
Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt
control: owner -1 ! control: tag -1 +moreinfo Dear Boyuan, Thanks for this! Before I do a proper review let's talk about the source code/repacking situation. Are there/could there be other libraries that use code generated from the Evernote thrift files? For example, bindings for another language (python, haskell, perl)? If so, the Evernote thrift files should be in their own package, and this package can build-depend on it. That would clean things up a bit, but it wouldn't help with QEverCloudGenerator -- I guess that no packages other than qevercloud itself will use that, right? If it would be easier for you to maintain, you could put QEverCloudGenerator in its own package and build-depend on it, but that's your choice. It looks like you are have removed the files you are going to regenerate from the upstream tarball. That's okay, but you don't have to do it -- you can just delete them before you regenerate them/just overwrite them. See the ebib source package for a very simple example of regenerating a file without removing it from the upstream tarball. Let me know what you think of these suggestions. -- Sean Whitton
Bug#836959: RFS: usbguard/0.6.0+ds1-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "usbguard" * Package name: usbguard Version : 0.6.0+ds1-1 Upstream Author : Daniel Kopeček * URL : https://github.com/dkopecek/usbguard * License : GPL-2+ Section : utils It builds those binary packages: libusbguard-dev - USB device authorization policy framework - development files libusbguard0 - USB device authorization policy framework - shared library usbguard - USB device authorization policy framework usbguard-applet-qt - USB device authorization policy framework - qt applet To access further information about this package, please visit the following URL: https://mentors.debian.net/package/usbguard Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/u/usbguard/usbguard_0.6.0+ds1-1.dsc More information about hello can be obtained from https://dkopecek.github.io/usbguard/ Changes since the last upload: * New upstream release * d/control: - Remove nlohman-json from build-dependencies - Add protobuf build dependency - Change the architecture to linux-any - Add systemd to build dependencies (Closes: #836713) * d/rules - Add configure flag to enable building of the qt-gui - Add sysconfdir argument to configure * Add patch to link against libatomic if present (Closes: #836712) PS: I tried to test the build process on a qemu-mips machine, but i only could create a qemu-system-mips machine with 256MB ram, which was not enough for the build process. But christian said that he build-tested the patch and i trust his judgment. cheers, -- muri signature.asc Description: OpenPGP digital signature
Bug#836959: RFS: usbguard/0.6.0+ds1-1
Hi, On 07/09/16 16:24, Muri Nicanor wrote: > PS: I tried to test the build process on a qemu-mips machine, but i only > could create a qemu-system-mips machine with 256MB ram, which was not > enough for the build process. But christian said that he build-tested > the patch and i trust his judgment. [not directly related to the package but anyway...] This is an unfortunate problem with the MIPS Malta kernel currently, in that it doesn't auto-detect the amount of memory available. You have to use something like this to make it work: -m 2G -append 'mem=256m@0 mem=1792m@0x9000' There is a patch to fix this though - hopefully it will get into 4.9 for stretch: https://www.linux-mips.org/archives/linux-mips/2016-09/msg00095.html Thanks, James signature.asc Description: OpenPGP digital signature
Bug#836959: marked as done (RFS: usbguard/0.6.0+ds1-1)
Your message dated Wed, 7 Sep 2016 16:03:54 + (UTC) with message-id <1837522683.1538191.1473264234...@mail.yahoo.com> and subject line Re: Bug#836959: RFS: usbguard/0.6.0+ds1-1 has caused the Debian Bug report #836959, regarding RFS: usbguard/0.6.0+ds1-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.) -- 836959: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836959 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 "usbguard" * Package name: usbguard Version : 0.6.0+ds1-1 Upstream Author : Daniel Kopeček * URL : https://github.com/dkopecek/usbguard * License : GPL-2+ Section : utils It builds those binary packages: libusbguard-dev - USB device authorization policy framework - development files libusbguard0 - USB device authorization policy framework - shared library usbguard - USB device authorization policy framework usbguard-applet-qt - USB device authorization policy framework - qt applet To access further information about this package, please visit the following URL: https://mentors.debian.net/package/usbguard Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/u/usbguard/usbguard_0.6.0+ds1-1.dsc More information about hello can be obtained from https://dkopecek.github.io/usbguard/ Changes since the last upload: * New upstream release * d/control: - Remove nlohman-json from build-dependencies - Add protobuf build dependency - Change the architecture to linux-any - Add systemd to build dependencies (Closes: #836713) * d/rules - Add configure flag to enable building of the qt-gui - Add sysconfdir argument to configure * Add patch to link against libatomic if present (Closes: #836712) PS: I tried to test the build process on a qemu-mips machine, but i only could create a qemu-system-mips machine with 256MB ram, which was not enough for the build process. But christian said that he build-tested the patch and i trust his judgment. cheers, -- muri signature.asc Description: OpenPGP digital signature --- End Message --- --- Begin Message --- Hi, >I am looking for a sponsor for my package "usbguard" I sponsored in deferred/5, because I want to understand that systemd additions (it is wondering me, but seems correct) and all the stuff / functions changed/removed in the new release without a soname bump. Are you sure they aren't part of the API? thanks, G.--- End Message ---
Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt
Hello, 2016-09-07 23:15 GMT+08:00 Sean Whitton : > control: owner -1 ! > control: tag -1 +moreinfo > > Dear Boyuan, > > Thanks for this! Before I do a proper review let's talk about the > source code/repacking situation. > > Are there/could there be other libraries that use code generated from > the Evernote thrift files? For example, bindings for another language > (python, haskell, perl)? If so, the Evernote thrift files should be in > their own package, and this package can build-depend on it. If you are talking about bindings in other languages (python / haskell / perl /...) for *Evernote Cloud API*, then yes such projects do exist. For example, https://github.com/evernote/evernote-sdk-python and https://github.com/evernote/evernote-sdk-python3 and https://github.com/evernote/evernote-sdk-perl and https://github.com/evernote/evernote-sdk-csharp and https://github.com/evernote/evernote-sdk-cpp . Note that even Evernote developers does not use thrift code directly. All files are generated with some third-party generator. The motivation is clear: for interpreted languages (perl/python/...), parsing thrift description files in runtime is too time consuming and impossible. And for compiled languages (C/C++/C#/...), OK, they just don't bother with the regeneration process. It is a one-shot process, the generated c/cpp/c# source codes are still clear and readable, ready to be embedded into other projects or made into shared library. Packaging separately is useless to other people. Thrift files should be regarded as language-independent source code; It does not make sense for one package to Build-Depend to another package which only contains some source code. Those codes should be part of its own source code. Is there really any previous example in Debian, that one package *should* and *do* Build-Depend on another *binary* package that only contains some description files or source codes? > That would clean things up a bit, but it wouldn't help with > QEverCloudGenerator -- I guess that no packages other than qevercloud > itself will use that, right? If it would be easier for you to maintain, > you could put QEverCloudGenerator in its own package and build-depend on > it, but that's your choice. That would make things even more complicated and add another barely useless binary package into Debian, so I am not intended to pack QEverCloudGenerator separately. > It looks like you are have removed the files you are going to regenerate > from the upstream tarball. That's okay, but you don't have to do it -- > you can just delete them before you regenerate them/just overwrite > them. See the ebib source package for a very simple example of > regenerating a file without removing it from the upstream tarball. I checked ebib and find that I know nothing about emacs lisp and its debhelper. Where did it remove any file? What I do know is that I can override dh_clean and delete some files sooner or later. Overwriting seems reasonable, too. > Let me know what you think of these suggestions. Basically I just don't want to generate more binary packages. The current source structure is acceptable to me, and the only problem is to decide the proper way to regenerate source code and build the library. I may choose either to hack the debian/rules file or to patch cmake instructions. The current implementation is to hack debian/rules. Sincerely, Boyuan Yang
Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt
Dear Boyuan, On Thu, Sep 08, 2016 at 12:14:53AM +0800, Boyuan Yang wrote: > > Are there/could there be other libraries that use code generated from > > the Evernote thrift files? For example, bindings for another language > > (python, haskell, perl)? If so, the Evernote thrift files should be in > > their own package, and this package can build-depend on it. > > If you are talking about bindings in other languages (python / haskell > / perl /...) > for *Evernote Cloud API*, then yes such projects do exist. For example, > https://github.com/evernote/evernote-sdk-python and > https://github.com/evernote/evernote-sdk-python3 and > https://github.com/evernote/evernote-sdk-perl and > https://github.com/evernote/evernote-sdk-csharp and > https://github.com/evernote/evernote-sdk-cpp . > Note that even Evernote developers does not use thrift code directly. > All files are > generated with some third-party generator. The motivation is clear: > for interpreted languages (perl/python/...), parsing thrift > description files in runtime > is too time consuming and impossible. And for compiled languages > (C/C++/C#/...), > OK, they just don't bother with the regeneration process. It is a > one-shot process, > the generated c/cpp/c# source codes are still clear and readable, ready to be > embedded into other projects or made into shared library. Packaging separately > is useless to other people. > > Thrift files should be regarded as language-independent source code; It does > not make sense for one package to Build-Depend to another package which > only contains some source code. Those codes should be part of its own > source code. The issue is that then we then have multiple copies of the thrift files in Debian: a copy in each source package that needs them, either for regeneration or in debian/missing-sources/. Suppose there is an Evernote protocol change, or some other bug that means the thrift files get updated. If there is one copy of them in Debian, we just update that, and then binNMU all the packages that use it, and we're done. Otherwise, if there are lots of copies, we have to update each package separately. That's significantly more work, and can't be done by just one person, but needs the involvement of the maintainers of all those packages. This is especially relevant if we need to update the thrift files in a Debian stable release: updates to packages in a released version of Debian have to go through a careful vetting procedure, and this means we only have to do that once. That saves a lot of time (and indeed makes it feasible at all). It's possible I've misunderstood the purpose of the thrift files, though -- if there was an Evernote API change, they would have to change and the corresponding language-specific generators re-run, right? > Is there really any previous example in Debian, that one package > *should* and *do* Build-Depend on another *binary* package that only > contains some description files or source codes? I'm not sure about a package that only contains source code alone, but I can give you an example of one that contains source code plus some other stuff: dh-elpa. If you look in the emacsen-common folder of its source package, you'll find some scripts. Those get copied into every elpa-* binary package (with the package name substituted in). And dh-elpa is added to the elpa-* package's Built-Using field. Before dh-elpa, there was a copy of those emacsen-common scripts in every single Emacs lisp addon package (and in package that have not yet been converted, it's still there, e.g. s-el). That meant that fixing bugs in those scripts or improving/reworking the Emacs Lisp addon packaging policy[1] means updating every single Emacs Lisp addon source package, and re-uploading. Thanks to dh-elpa we can update the scripts in all elpa-* packages just by changing dh-elpa, and rebuilding the elpa-* packages.[2] > > That would clean things up a bit, but it wouldn't help with > > QEverCloudGenerator -- I guess that no packages other than > > qevercloud itself will use that, right? If it would be easier for > > you to maintain, you could put QEverCloudGenerator in its own > > package and build-depend on it, but that's your choice. > > That would make things even more complicated and add another barely useless > binary package into Debian, so I am not intended to pack QEverCloudGenerator > separately. That's fine. > > It looks like you are have removed the files you are going to > > regenerate from the upstream tarball. That's okay, but you don't > > have to do it -- you can just delete them before you regenerate > > them/just overwrite them. See the ebib source package for a very > > simple example of regenerating a file without removing it from the > > upstream tarball. > > I checked ebib and find that I know nothing about emacs lisp and its > debhelper. > Where did it remove any file? Take a look at the two overrides in d/rules. You shouldn't need to know anything abou
Bug#836987: RFS: hoichess/0.19.0-2 [QA]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "hoichess" * Package name: hoichess * Version : 0.19.0-2 * Section : games It builds those binary packages: hoichess - xboard compatible chess engine to play chess with To access further information about this package, please visit the following URL: https://mentors.debian.net/package/hoichess Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/hoichess/hoichess_0.19.0-2.dsc More information about hello can be obtained from https://www.example.com. Changes since the last upload: * QA upload * Suggest instead of Recommend xboard | scid. Closes: #820461 * Suggest gnome-chess as an alternative too * Import to collab-maint and set Vcs fields Thanks, Jeremy Bicha
Bug#836987: RFS: hoichess/0.19.0-2 [QA]
Control: tag 836987 moreinfo Hi Jeremy, I did an upload for this package some hours ago and I can sponsor this package again. A question: will you really put this package in Collab Maint? Regards, Eriberto 2016-09-07 17:30 GMT-03:00 Jeremy Bicha : > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "hoichess" > > * Package name: hoichess > * Version : 0.19.0-2 > * Section : games > > It builds those binary packages: > >hoichess - xboard compatible chess engine to play chess with > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/hoichess > > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/h/hoichess/hoichess_0.19.0-2.dsc > > More information about hello can be obtained from https://www.example.com. > > Changes since the last upload: > > * QA upload > * Suggest instead of Recommend xboard | scid. Closes: #820461 > * Suggest gnome-chess as an alternative too > * Import to collab-maint and set Vcs fields > > > Thanks, > Jeremy Bicha >
Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt
2016-09-08 0:52 GMT+08:00 Sean Whitton : > The issue is that then we then have multiple copies of the thrift files > in Debian: a copy in each source package that needs them, either for > regeneration or in debian/missing-sources/. > > Suppose there is an Evernote protocol change, or some other bug that > means the thrift files get updated. If there is one copy of them in > Debian, we just update that, and then binNMU all the packages that use > it, and we're done. Unfortunately things will not be the case, at least not for Evernote thrift files. 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 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. > Otherwise, if there are lots of copies, we have to update each package > separately. That's significantly more work, and can't be done by just > one person, but needs the involvement of the maintainers of all those > packages. > > This is especially relevant if we need to update the thrift files in a > Debian stable release: updates to packages in a released version of > Debian have to go through a careful vetting procedure, and this means we > only have to do that once. That saves a lot of time (and indeed makes > it feasible at all). > > It's possible I've misunderstood the purpose of the thrift files, though > -- if there was an Evernote API change, they would have to change and > the corresponding language-specific generators re-run, right? In this specific case, we also need to notice the slow evolvement of Evernote Cloud API (>= 3 years, longer than Debian stable release cycle. Take a look at Evernote official SDK) and the backward compatibility of the API. Not updating API will not cause problems, and it is the author of program (i.e., nixnote2 author) who has the responsibility to update the level of API itself uses. Even if the Evernote API is updated according to the new thrift files by packagers, the added methods will not be utilized until the program author decide to switch to the new API, and the changed/removed methods may lead to FTBFS. >> Is there really any previous example in Debian, that one package >> *should* and *do* Build-Depend on another *binary* package that only >> contains some description files or source codes? > > I'm not sure about a package that only contains source code alone, but I > can give you an example of one that contains source code plus some other > stuff: dh-elpa. If you look in the emacsen-common folder of its source > package, you'll find some scripts. Those get copied into every elpa-* > binary package (with the package name substituted in). And dh-elpa is > added to the elpa-* package's Built-Using field. > > Before dh-elpa, there was a copy of those emacsen-common scripts in > every single Emacs lisp addon package (and in package that have not yet > been converted, it's still there, e.g. s-el). That meant that fixing > bugs in those scripts or improving/reworking the Emacs Lisp addon > packaging policy[1] means updating every single Emacs Lisp addon source > package, and re-uploading. > > Thanks to dh-elpa we can update the scripts in all elpa-* packages just > by changing dh-elpa, and rebuilding the elpa-* packages.[2] Unfortunately Evernote thrift files are neither lisp nor shared libraries. I understand the advantage that common files get updated separately and a rebuild solves the rest of the problem, but this is not the current case. >> I checked ebib and find that I know nothing about emacs lisp and its >> debhelper. >> Where did it remove any file? > > Take a look at the two overrides in d/rules. You shouldn't need to know > anything about Emacs lisp to understand those. 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'. Sincerely, Boyuan Yang
Bug#836987: RFS: hoichess/0.19.0-2 [QA]
On Wed, Sep 7, 2016 at 5:53 PM, Eriberto wrote: > I did an upload for this package some hours ago and I can sponsor this > package again. A question: will you really put this package in Collab > Maint? Yes, the packaging is there now. The documentation says that when a new repo is created on Alioth, it takes up to 6 hours before the web view is live. https://anonscm.debian.org/git/collab-maint/hoichess.git/ Sorry about the 2nd upload in the same day but this fixes a long-time minor annoyance. :) Thanks, Jeremy
Bug#836987: RFS: hoichess/0.19.0-2 [QA]
Hi, 2016-09-07 19:39 GMT-03:00 Jeremy Bicha : > On Wed, Sep 7, 2016 at 5:53 PM, Eriberto wrote: >> I did an upload for this package some hours ago and I can sponsor this >> package again. A question: will you really put this package in Collab >> Maint? > > Yes, the packaging is there now. The documentation says that when a > new repo is created on Alioth, it takes up to 6 hours before the web > view is live. Ok. > https://anonscm.debian.org/git/collab-maint/hoichess.git/ > > Sorry about the 2nd upload in the same day but this fixes a long-time > minor annoyance. :) No problem. Thanks a lot for you work. Uploaded. Regards, Eriberto
Bug#836987: marked as done (RFS: hoichess/0.19.0-2 [QA])
Your message dated Wed, 7 Sep 2016 20:00:20 -0300 with message-id and subject line Re: Bug#836987: RFS: hoichess/0.19.0-2 [QA] has caused the Debian Bug report #836987, regarding RFS: hoichess/0.19.0-2 [QA] 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.) -- 836987: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836987 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 "hoichess" * Package name: hoichess * Version : 0.19.0-2 * Section : games It builds those binary packages: hoichess - xboard compatible chess engine to play chess with To access further information about this package, please visit the following URL: https://mentors.debian.net/package/hoichess Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/hoichess/hoichess_0.19.0-2.dsc More information about hello can be obtained from https://www.example.com. Changes since the last upload: * QA upload * Suggest instead of Recommend xboard | scid. Closes: #820461 * Suggest gnome-chess as an alternative too * Import to collab-maint and set Vcs fields Thanks, Jeremy Bicha --- End Message --- --- Begin Message --- Hi, 2016-09-07 19:39 GMT-03:00 Jeremy Bicha : > On Wed, Sep 7, 2016 at 5:53 PM, Eriberto wrote: >> I did an upload for this package some hours ago and I can sponsor this >> package again. A question: will you really put this package in Collab >> Maint? > > Yes, the packaging is there now. The documentation says that when a > new repo is created on Alioth, it takes up to 6 hours before the web > view is live. Ok. > https://anonscm.debian.org/git/collab-maint/hoichess.git/ > > Sorry about the 2nd upload in the same day but this fixes a long-time > minor annoyance. :) No problem. Thanks a lot for you work. Uploaded. Regards, Eriberto--- End Message ---
Bug#837040: RFS: btrfs-progs/4.7.1-1~bpo8+1 [RC NMU]
Package: sponsorship-requests Severity: grave Dear mentors, I am looking for a sponsor for an urgent NMU of "btrfs-progs". Upstream has marked this as an "urgent fix" < https://btrfs.wiki.kernel.org/index.php/Changelog#btrfs-progs-4.7.2_.28Sep_2016.29 > Sept 5th I filed bug #836778 notifying the maintainer of the issue. Package name: btrfs-progs Version : 4.7.1-1~bpo8+1 Section : admin It builds these binary packages: btrfs-progs - Checksumming Copy on Write Filesystem utilities btrfs-progs-dbg - Checksumming Copy on Write Filesystem utilities (debug) btrfs-progs-udeb - Checksumming Copy on Write Filesystem utilities (udeb) (udeb) btrfs-tools - transitional dummy package btrfs-tools-dbg - transitional dummy package To access further information about this package, please visit the following URL: https://mentors.debian.net/package/btrfs-progs Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/btrfs-progs/btrfs-progs_4.7.1-1~bpo8+1.dsc It is also available here: https://github.com/sten0/btrfs-progs.git Changes since the last upload: * Non-maintainer upload. * New upstream release. (Closes #836778) Regards, Nicholas signature.asc Description: Digital signature
Bug#837040: RFS: btrfs-progs/4.7.1-1~bpo8+1 [RC NMU]
On Thu, Sep 08, 2016 at 12:57:32AM -0400, Nicholas D Steeves wrote: > Package: sponsorship-requests > Severity: grave > > I am looking for a sponsor for an urgent NMU of "btrfs-progs". Upstream > has marked this as an "urgent fix" < > https://btrfs.wiki.kernel.org/index.php/Changelog#btrfs-progs-4.7.2_.28Sep_2016.29 > Package name: btrfs-progs > Version : 4.7.1-1~bpo8+1 Except, you see, it's 4.7 and 4.7.1 which are the buggy versions, 4.6.1 is unaffected. So you demand, with a grave severity, to overwrite a known-good version with one with a data loss bug. -- 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#837040: RFS: btrfs-progs/4.7.1-1~bpo8+1 [RC NMU]
On Thu, Sep 08, 2016 at 07:11:31AM +0200, Adam Borowski wrote: > On Thu, Sep 08, 2016 at 12:57:32AM -0400, Nicholas D Steeves wrote: > > Package: sponsorship-requests > > Severity: grave > > > > I am looking for a sponsor for an urgent NMU of "btrfs-progs". Upstream > > has marked this as an "urgent fix" < > > https://btrfs.wiki.kernel.org/index.php/Changelog#btrfs-progs-4.7.2_.28Sep_2016.29 > > > Package name: btrfs-progs > > Version : 4.7.1-1~bpo8+1 > > Except, you see, it's 4.7 and 4.7.1 which are the buggy versions, 4.6.1 is > unaffected. So you demand, with a grave severity, to overwrite a known-good > version with one with a data loss bug. > > -- > Second "wet cat laying down on a powered on box-less SoC on the desk" close > shave in a week. Protect your ARMs, folks! I hit "r" instead of "g", so my last reply didn't make it to the bug-tracker. This is an error in my bug submission, and I am embarassed I made that mistake (too late here, I'm going to sleep). It should read: Package name: btrfs-progs Version : 4.7.2-0.1 5 Sept (I think, it might have been earlier) I asked Gianfranco to cancel my bpo in the deferred queue because of this issue. Thank you, Nicholas signature.asc Description: Digital signature
Bug#837040: RFS: btrfs-progs/4.7.2-0.1 [RC NMU]
Control: retitle -1 'RFS: btrfs-progs/4.7.2-0.1 [RC NMU]' Was almost asleep and then realised this; here is the correct link: dget -x https://mentors.debian.net/debian/pool/main/b/btrfs-progs/btrfs-progs_4.7.2-0.1.dsc Humble regards, Nicholas signature.asc Description: Digital signature
