Bug#822604: scanmem: depends on gksu which is deprecated
❦ 4 janvier 2017 19:25 +0100, Sebastian Parschauer : >>> Should I append the following lines to the new upstream release entry in >>> debian/changelog? >>> >>>+ Closes #618464 >>>+ Closes #689057 >>>+ Closes #822604 >>> >>> This should auto-close these bugs, right? >> >> Yes. You can compress to: "Closes #618464, #689057, #822604." >> > Done, thanks! A colon was missing to make Lintian happy: > + Closes: #618464, #689057, #822604 > > Will you upload now? It's uploaded. You should receive a mail soon. -- Take care to branch the right way on equality. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Bug#822604: scanmem: depends on gksu which is deprecated
On 04.01.2017 14:55, Vincent Bernat wrote: > ❦ 4 janvier 2017 12:08 +0100, Sebastian Parschauer : >> Should I append the following lines to the new upstream release entry in >> debian/changelog? >> >>+ Closes #618464 >>+ Closes #689057 >>+ Closes #822604 >> >> This should auto-close these bugs, right? > > Yes. You can compress to: "Closes #618464, #689057, #822604." > Done, thanks! A colon was missing to make Lintian happy: + Closes: #618464, #689057, #822604 Will you upload now? https://raw.githubusercontent.com/sriemer/scanmem-debian/source/scanmem_0.16-1.dsc Cheers, Sebastian
Bug#822604: scanmem: depends on gksu which is deprecated
❦ 4 janvier 2017 12:08 +0100, Sebastian Parschauer : >> Thanks, that hint was crucial. I've implemented all that and updated the >> source branch. Should be ready for upload now. >> >> https://raw.githubusercontent.com/sriemer/scanmem-debian/source/scanmem_0.16-1.dsc > > Andrea Stacchiotti (in CC) reported that the upload would fix all three > pending Debian bugs for the scanmem package. > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=scanmem > > It also fixes most issues seen here: > > https://tracker.debian.org/pkg/scanmem > > And of cause all four Ubuntu package bugs. > > All bugs are fixed by the new upstream version. > > Should I append the following lines to the new upstream release entry in > debian/changelog? > >+ Closes #618464 >+ Closes #689057 >+ Closes #822604 > > This should auto-close these bugs, right? Yes. You can compress to: "Closes #618464, #689057, #822604." -- Use library functions. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Bug#822604: scanmem: depends on gksu which is deprecated
On 04.01.2017 10:33, Sebastian Parschauer wrote: > Thanks, that hint was crucial. I've implemented all that and updated the > source branch. Should be ready for upload now. > > https://raw.githubusercontent.com/sriemer/scanmem-debian/source/scanmem_0.16-1.dsc Andrea Stacchiotti (in CC) reported that the upload would fix all three pending Debian bugs for the scanmem package. https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=scanmem It also fixes most issues seen here: https://tracker.debian.org/pkg/scanmem And of cause all four Ubuntu package bugs. All bugs are fixed by the new upstream version. Should I append the following lines to the new upstream release entry in debian/changelog? + Closes #618464 + Closes #689057 + Closes #822604 This should auto-close these bugs, right? Cheers, Sebastian
Bug#822604: scanmem: depends on gksu which is deprecated
On 02.01.2017 22:55, Vincent Bernat wrote:
> OK. In debian/control, ${python:Depends} already expands to python (>=
> 2.7), so you don't need to put it a second time (but that's really
> nitpicking). Also, I just noticed that gameconqueror is "Architecture:
> any" while it should be "Architecture: all" (there is nothing
> architecture-dependant in it). In this case, you should also replace the
> dependency on scanmem by:
>
> Depends: scanmem (>= ${source:Version}), scanmem (<<
> ${source:Upstream-Version}.0~)
>
> And the suggestion for gameconqueror by:
>
> Suggests: gameconqueror (= ${source:Version}
>
> The reasons are explained here:
> https://wiki.debian.org/binNMU
Thanks, that hint was crucial. I've implemented all that and updated the
source branch. Should be ready for upload now.
https://raw.githubusercontent.com/sriemer/scanmem-debian/source/scanmem_0.16-1.dsc
> I don't see any other problem. As per policy, there is a whole procedure
> to take over a package. However, Lu and Kartik were in copy of your
> intent to take over the package since April and didn't say a thing, I
> suppose they are fine with it.
Yep, they are fine with it. They both don't have the time to care for
this package any more. With the scanmem upstream on GitHub and new
contributors also upstream achieves faster progress and better stability
now. I took over upstream maintenance from Lu Wang in 2015.
Cheers,
Sebastian
Bug#822604: scanmem: depends on gksu which is deprecated
❦ 2 janvier 2017 21:49 +0100, Sebastian Parschauer :
> It is intended and requested upstream to provide a separate libscanmem
> so that further tools can be built against it. We'll have to rework the
> public API any ways in v0.17. So I've dropped the separate libscanmem
> package for now to get the package uploaded faster. Lintian is still
> happy this way and the packages are working fine.
OK. In debian/control, ${python:Depends} already expands to python (>=
2.7), so you don't need to put it a second time (but that's really
nitpicking). Also, I just noticed that gameconqueror is "Architecture:
any" while it should be "Architecture: all" (there is nothing
architecture-dependant in it). In this case, you should also replace the
dependency on scanmem by:
Depends: scanmem (>= ${source:Version}), scanmem (<<
${source:Upstream-Version}.0~)
And the suggestion for gameconqueror by:
Suggests: gameconqueror (= ${source:Version}
The reasons are explained here:
https://wiki.debian.org/binNMU
I don't see any other problem. As per policy, there is a whole procedure
to take over a package. However, Lu and Kartik were in copy of your
intent to take over the package since April and didn't say a thing, I
suppose they are fine with it.
--
Program defensively.
- The Elements of Programming Style (Kernighan & Plauger)
signature.asc
Description: PGP signature
Bug#822604: scanmem: depends on gksu which is deprecated
On 02.01.2017 12:04, Vincent Bernat wrote: > ❦ 2 janvier 2017 11:10 +0100, Sebastian Parschauer : >> See: >> https://github.com/sriemer/scanmem-debian/blob/source/scanmem_0.16-1.dsc > > This is not very convenient since I cannot use dget on this URL. But, I > have downloaded the source code successfully nonetheless. I am dropping > debian-release@ but keeping Emilio since he did a review before. Thank you very much for downloading and reviewing! I've implemented the requested changes and updated the source branch. Please use the following to get the reworked source: dget https://raw.githubusercontent.com/sriemer/scanmem-debian/source/scanmem_0.16-1.dsc Please provide feedback if you're fine with it now. TIA > - d/control: don't depends on libc6-dev, this is part of >build-essential > - d/control: short descriptions should be something like: > > locate and modify a variable in a running process (library) > locate and modify a variable in a running process (development) > locate and modify a variable in a running process > > - d/control: a "This package contains the development files" should be >appended to the long description for libscanmem-dev > - d/control: a library should not suggest its dependencies > - d/dirs: empty, remove it > - d/docs: README is automatically added, if TODO is not interesting for >end-users, you may consider to remove the whole file (but you are >free to keep it) Okay, I've removed both files. > - d/libscanmem-dev.install: except if you have some users for that, >remove the .a. > - d/changelog: don't use urgency=high (this is for security updates), >keep urgency=low or urgency=medium (there is currently no difference >between them) > - d/copyright: the rule is last match wins, so you need to put the >"Files: *" section first I've implemented everything like requested and I've added a trivial upstream patch to fix an icon (replaced deprecated 'gtk-jump-to' with 'go-jump'). > Overall, I don't think that Emilio asked for a separate package for > libscanmem1. Since this is a private library, this can be kept in the > scanmem package. The only drawback would be that people using > gameconqueror will have to also install scanmem to get the lib. I don't > think you get a Lintian warning when doing that (since the library is > not installed in /usr/lib directly). But, it's up to you. Note that with > the two new binary packages, the upload will take some time since it > will be blocked in the NEW queue (expect at least a 1-week delay). It is intended and requested upstream to provide a separate libscanmem so that further tools can be built against it. We'll have to rework the public API any ways in v0.17. So I've dropped the separate libscanmem package for now to get the package uploaded faster. Lintian is still happy this way and the packages are working fine. Cheers, Sebastian
Bug#822604: scanmem: depends on gksu which is deprecated
❦ 2 janvier 2017 11:10 +0100, Sebastian Parschauer : > On 02.01.2017 10:48, Vincent Bernat wrote: >>> I don't know what else I should do. Please upload! >> >> Emilio may be currently busy. You have better chance of getting someone >> else helping with the upload if you provide a link to a .dsc so that >> people don't have to look at where the original tarball is. You can use >> mentors.debian.net for this. > > I've provided a source branch for that (all files generated by "debuild > -S"). > > See: https://github.com/sriemer/scanmem-debian/tree/source > See: > https://github.com/sriemer/scanmem-debian/blob/source/scanmem_0.16-1.dsc This is not very convenient since I cannot use dget on this URL. But, I have downloaded the source code successfully nonetheless. I am dropping debian-release@ but keeping Emilio since he did a review before. - d/control: don't depends on libc6-dev, this is part of build-essential - d/control: short descriptions should be something like: locate and modify a variable in a running process (library) locate and modify a variable in a running process (development) locate and modify a variable in a running process - d/control: a "This package contains the development files" should be appended to the long description for libscanmem-dev - d/control: a library should not suggest its dependencies - d/dirs: empty, remove it - d/docs: README is automatically added, if TODO is not interesting for end-users, you may consider to remove the whole file (but you are free to keep it) - d/libscanmem-dev.install: except if you have some users for that, remove the .a. - d/changelog: don't use urgency=high (this is for security updates), keep urgency=low or urgency=medium (there is currently no difference between them) - d/copyright: the rule is last match wins, so you need to put the "Files: *" section first Overall, I don't think that Emilio asked for a separate package for libscanmem1. Since this is a private library, this can be kept in the scanmem package. The only drawback would be that people using gameconqueror will have to also install scanmem to get the lib. I don't think you get a Lintian warning when doing that (since the library is not installed in /usr/lib directly). But, it's up to you. Note that with the two new binary packages, the upload will take some time since it will be blocked in the NEW queue (expect at least a 1-week delay). -- Talkers are no good doers. -- William Shakespeare, "Henry VI" signature.asc Description: PGP signature
Bug#822604: scanmem: depends on gksu which is deprecated
On 02.01.2017 10:48, Vincent Bernat wrote: >> I don't know what else I should do. Please upload! > > Emilio may be currently busy. You have better chance of getting someone > else helping with the upload if you provide a link to a .dsc so that > people don't have to look at where the original tarball is. You can use > mentors.debian.net for this. I've provided a source branch for that (all files generated by "debuild -S"). See: https://github.com/sriemer/scanmem-debian/tree/source See: https://github.com/sriemer/scanmem-debian/blob/source/scanmem_0.16-1.dsc The packages locally built with sbuild for testing-amd64 can be found here: https://github.com/sriemer/scanmem-debian/tree/testing-amd64 > As for the timing, the package already being in testing, you are not > concerned with the Jan 5th deadline (the deadline is only for new source > packages, not in testing at this date). Thanks for clarification. So 2017-02-05 is the deadline. I'd still prefer having some time for bugfixing in case something is found by review/testing. Testing version 0.13 doesn't make any sense IMHO as it is unsupported by upstream by now (too many bugs, too old, too slow). This is why all other distros already picked up more recent versions. Cheers, Sebastian
Bug#822604: scanmem: depends on gksu which is deprecated
❦ 2 janvier 2017 10:12 +0100, Sebastian Parschauer : >> Please upload! TIA > > We are reaching the new package submission deadline for Debian Stretch > 2017-01-05 very soon. > > More than 5 years old version 0.13 which is full of bugs and insecure > will be in Stretch if nobody uploads my new package from: > > https://github.com/sriemer/scanmem-debian > > See: https://packages.debian.org/stretch/scanmem > > I don't know what else I should do. Please upload! Emilio may be currently busy. You have better chance of getting someone else helping with the upload if you provide a link to a .dsc so that people don't have to look at where the original tarball is. You can use mentors.debian.net for this. As for the timing, the package already being in testing, you are not concerned with the Jan 5th deadline (the deadline is only for new source packages, not in testing at this date). -- Follow each decision as closely as possible with its associated action. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Bug#822604: scanmem: depends on gksu which is deprecated
On 17.12.2016 20:18, Sebastian Parschauer wrote: > Please upload! TIA We are reaching the new package submission deadline for Debian Stretch 2017-01-05 very soon. More than 5 years old version 0.13 which is full of bugs and insecure will be in Stretch if nobody uploads my new package from: https://github.com/sriemer/scanmem-debian See: https://packages.debian.org/stretch/scanmem I don't know what else I should do. Please upload! Involving my former colleagues Benjamin and Arno as well. Severity is important. I hope that's enough that you guys can upload as well. Or maybe you can provide me a hint how to finally get the new package in. TIA Cheers, Sebastian
Bug#822604: scanmem: depends on gksu which is deprecated
Hi Emilio, we haven't forgotten you. We've worked hard and we've released v0.16 with the requested changes. See: https://github.com/scanmem/scanmem/releases/tag/v0.16 See: https://github.com/sriemer/scanmem-debian Now I'm asking you to upload the package. TIA On 01.06.2016 23:14, Emilio Pozuelo Monfort wrote: >> Lintian is only still warning about the fact that libscanmem is not >> provided in a separate package. It is only there for better backend >> communication for GameConqueror. So this can be ignored. > > Hmm. If that's the case, you shouldn't install the libscanmem.so symlink. I > see > you use it for dlopening the lib in gameconqueror, but that could happen by > dlopening libscanmem.so.1. Also, it would be better if the library was > installed > into a /usr/lib/scanmem/ directory (or similar) so it wasn't on the default > library search path. Though I don't think that's strictly necessary. We've addressed this like you've proposed. GC uses an absolute path to libscanmem.so.1 as well now. The package libscanmem1 only installs *.so.1 and *.so.1.0.0 to /usr/lib/scanmem/. The libscanmem-dev package installs *.so and *.a. > gameconqueror depends on scanmem (>= 0.15.7). What prevents scanmem from being > upgraded to, say, 0.16, where libscanmem has changed incompatibly, while > gameconqueror stays at 0.15.7? You should probably add a strict versioning. The strict versioning has been added. > Other than that things look good. > > I'll upload as soon as those comments are addressed. I've updated the "master", "source" and "testing-amd64" branches of the scanmem-debian repo. These should contain everything to check that we've done our job. Lintian is happy. The packages work perfectly fine. So we're ready to upload. Please upload! TIA Cheers, Sebastian
Bug#822604: scanmem: depends on gksu which is deprecated
On 02/06/16 08:50, Sebastian Parschauer wrote: > Hi Emilio, > > no problem, we used the time to bring version 0.16 coming with ranges > search as well as Android and openSUSE support on its way. We can > release any time but it would be great if we could fix the window resize > bug and the example in the scanmem man page before doing so. Sure, no rush. > We've cleaned up files and documentation, fixed further GUI bugs + > warnings and improved scan performance a bit further. The most time > consuming part was updating the scanmem man page which has been > neglected for 6 years. > > Thanks for proposing solutions for remaining issues! Very much > appreciated. We'll address them with version 0.16 ASAP. > > Is there any known deadline for us? Let's try to get it in before the end of the year as the freeze is going to be early next year. Plenty of time until then. Cheers, Emilio
Bug#822604: scanmem: depends on gksu which is deprecated
Hi Emilio, no problem, we used the time to bring version 0.16 coming with ranges search as well as Android and openSUSE support on its way. We can release any time but it would be great if we could fix the window resize bug and the example in the scanmem man page before doing so. We've cleaned up files and documentation, fixed further GUI bugs + warnings and improved scan performance a bit further. The most time consuming part was updating the scanmem man page which has been neglected for 6 years. Thanks for proposing solutions for remaining issues! Very much appreciated. We'll address them with version 0.16 ASAP. Is there any known deadline for us? Cheers, Sebastian On 01.06.2016 23:14, Emilio Pozuelo Monfort wrote: >> Lintian is only still warning about the fact that libscanmem is not >> provided in a separate package. It is only there for better backend >> communication for GameConqueror. So this can be ignored. > > Hmm. If that's the case, you shouldn't install the libscanmem.so symlink. I > see > you use it for dlopening the lib in gameconqueror, but that could happen by > dlopening libscanmem.so.1. Also, it would be better if the library was > installed > into a /usr/lib/scanmem/ directory (or similar) so it wasn't on the default > library search path. Though I don't think that's strictly necessary. > > gameconqueror depends on scanmem (>= 0.15.7). What prevents scanmem from being > upgraded to, say, 0.16, where libscanmem has changed incompatibly, while > gameconqueror stays at 0.15.7? You should probably add a strict versioning. > > Other than that things look good. > >> I've tested scanmem and GC in fresh Debian "testing" VMs for amd64 and >> i386 with GNOME and MATE for now. All the upstream test cases have been >> passed. The packages are working like a charm and as expected. :-) No >> files are missing in the .deb packages and the GC icon is visible right >> away after installation. :-) > > Good. > >> This is done. Please use the "source" branch, build the packages from >> there and upload the new version. > > I'll upload as soon as those comments are addressed. > > Cheers, > Emilio >
Bug#822604: scanmem: depends on gksu which is deprecated
Hi Sebastian, sorry for the huge delay. On 28/04/16 01:59, Sebastian Parschauer wrote: > On 25.04.2016 17:58, Emilio Pozuelo Monfort wrote: >>> My plan is to become the new Debian scanmem package maintainer and to >>> provide latest versions myself. >>> >>> I already started with a packaging repo at: >>> https://github.com/sriemer/scanmem-debian >>> >>> I need supporters for this plan. Updating is the better choice IMHO. >>> >>> Can I count on your support? >>> >>> If yes, then I'll prepare the new package and send it to you for review. >> >> Yes, please send me a link to a .dsc when ready and I'll have a look. > > Hi Emilio, > > I'm ready. I've released and picked upstream version v0.15.7 as it > contains quite important security fixes found by Coverity and a security > researcher. So we'll jump from 0.13-1 to 0.15.7-1. > > I've prepared the new Debian packaging commits here: > > https://github.com/sriemer/scanmem-debian/commits/master > > Then I've gathered and extracted the upstream tarball and run > 'debuild -S' to provide the .dsc file to you: > > https://github.com/sriemer/scanmem-debian/tree/source > > I've built this for "testing" and "unstable" for i386 and amd64 in local > sbuild environments in the branches "unstable-amd64", "unstable-i386", > "testing-amd64" and "testing-i386". > > Lintian is only still warning about the fact that libscanmem is not > provided in a separate package. It is only there for better backend > communication for GameConqueror. So this can be ignored. Hmm. If that's the case, you shouldn't install the libscanmem.so symlink. I see you use it for dlopening the lib in gameconqueror, but that could happen by dlopening libscanmem.so.1. Also, it would be better if the library was installed into a /usr/lib/scanmem/ directory (or similar) so it wasn't on the default library search path. Though I don't think that's strictly necessary. gameconqueror depends on scanmem (>= 0.15.7). What prevents scanmem from being upgraded to, say, 0.16, where libscanmem has changed incompatibly, while gameconqueror stays at 0.15.7? You should probably add a strict versioning. Other than that things look good. > I've tested scanmem and GC in fresh Debian "testing" VMs for amd64 and > i386 with GNOME and MATE for now. All the upstream test cases have been > passed. The packages are working like a charm and as expected. :-) No > files are missing in the .deb packages and the GC icon is visible right > away after installation. :-) Good. > This is done. Please use the "source" branch, build the packages from > there and upload the new version. I'll upload as soon as those comments are addressed. Cheers, Emilio
Bug#822604: scanmem: depends on gksu which is deprecated
On 25.04.2016 17:58, Emilio Pozuelo Monfort wrote: >> My plan is to become the new Debian scanmem package maintainer and to >> provide latest versions myself. >> >> I already started with a packaging repo at: >> https://github.com/sriemer/scanmem-debian >> >> I need supporters for this plan. Updating is the better choice IMHO. >> >> Can I count on your support? >> >> If yes, then I'll prepare the new package and send it to you for review. > > Yes, please send me a link to a .dsc when ready and I'll have a look. Hi Emilio, I'm ready. I've released and picked upstream version v0.15.7 as it contains quite important security fixes found by Coverity and a security researcher. So we'll jump from 0.13-1 to 0.15.7-1. I've prepared the new Debian packaging commits here: https://github.com/sriemer/scanmem-debian/commits/master Then I've gathered and extracted the upstream tarball and run 'debuild -S' to provide the .dsc file to you: https://github.com/sriemer/scanmem-debian/tree/source I've built this for "testing" and "unstable" for i386 and amd64 in local sbuild environments in the branches "unstable-amd64", "unstable-i386", "testing-amd64" and "testing-i386". Lintian is only still warning about the fact that libscanmem is not provided in a separate package. It is only there for better backend communication for GameConqueror. So this can be ignored. I've tested scanmem and GC in fresh Debian "testing" VMs for amd64 and i386 with GNOME and MATE for now. All the upstream test cases have been passed. The packages are working like a charm and as expected. :-) No files are missing in the .deb packages and the GC icon is visible right away after installation. :-) This is done. Please use the "source" branch, build the packages from there and upload the new version. Thanks! Sebastian
Bug#822604: scanmem: depends on gksu which is deprecated
Control: tags -1 upstream fixed-upstream pending Hi Sebastian, On 25/04/16 17:37, Sebastian Parschauer wrote: > The whole PolicyKit/pkexec stuff is implemented already. We only > recently fixed a bug in it. Great! > There is even an upstream bug for the bad situation on Debian/Ubuntu. It > has the title: > "Debian and Ubuntu ship > 4 years old version 0.13 which is full of bugs". > > New upstream code location: https://github.com/scanmem/scanmem > Latest upstream version: 0.15.6 > See: https://bugs.launchpad.net/ubuntu/+source/scanmem > See: https://github.com/scanmem/scanmem/issues/149 > My own "game-cheating" Ubuntu PPA: > https://launchpad.net/~s-parschauer/+archive/ubuntu/game-cheating > > My plan is to become the new Debian scanmem package maintainer and to > provide latest versions myself. > > I already started with a packaging repo at: > https://github.com/sriemer/scanmem-debian > > I need supporters for this plan. Updating is the better choice IMHO. > > Can I count on your support? > > If yes, then I'll prepare the new package and send it to you for review. Yes, please send me a link to a .dsc when ready and I'll have a look. Cheers, Emilio
