Re: unsubcribe
Please, send a mail to debian-mentors-requ...@lists.debian.org with subject 'unsubscribe' On 12/08/2024 14:38, Michael Hathaway wrote: OpenPGP_0x42F79A5E0A4D5598.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
On 31/07/2024 11:05, Boyuan Yang wrote: On Sun, 12 May 2024 15:05:05 -0300 Lucas Castro wrote: Sorry for top posting. The debian/control was modified to append Git fields, Cvs-Git and Cvs-Browser. Git repository is following the DEP-14 as suggested, I really appreciated that workflow. Changelog was improved. It reflects the all debian package modification right now. There's something to do yet, about the gbp as Daniel had mentioned, All things about debian branch and upstream branch for debian git. I had uploaded the package to mentors, https://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.21-1.dsc The package can be checked from the git repository too, the following uri Vcs-Browser: https://git.gnuabordo.com.br/foolsm.git Vcs-Git: https://git.gnuabordo.com.br/foolsm.git The debian/latest, debian/trixie and debian/unstable branches, all of them reflect debian package. I'm maintain all those branch right now, and all of them is identical. I'm thinking about to delete the unstable. I'll maintain just the debian/latest for development, debian/ for backports, security and propose-update and mentioned on DEP-14. Thanks, Lucas Castro I am picking up this leftover work. I think everything is fine now except for https://bugs.debian.org/1054086 , which is overdue and must be fixed. Once you prepare a new version that no longer installs files under /lib/, please notify me and I can sponsor the upload. Done. I had uploaded a new version to mentors along with modification fixing the bug mentioned. I had already fixed that but I got a regression when working on git-rebase. But right now, I got the packages reviewed, improved some others bits and it's already available for mentors review on mentors.d.n and Cvs-git. https://mentors.debian.net/package/lsm/ https://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.21-1.dsc Thanks, Boyuan Yang OpenPGP_0x42F79A5E0A4D5598.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
On 31/07/2024 11:05, Boyuan Yang wrote: On Sun, 12 May 2024 15:05:05 -0300 Lucas Castro wrote: Sorry for top posting. The debian/control was modified to append Git fields, Cvs-Git and Cvs-Browser. Git repository is following the DEP-14 as suggested, I really appreciated that workflow. Changelog was improved. It reflects the all debian package modification right now. There's something to do yet, about the gbp as Daniel had mentioned, All things about debian branch and upstream branch for debian git. I had uploaded the package to mentors, https://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.21-1.dsc The package can be checked from the git repository too, the following uri Vcs-Browser: https://git.gnuabordo.com.br/foolsm.git Vcs-Git: https://git.gnuabordo.com.br/foolsm.git The debian/latest, debian/trixie and debian/unstable branches, all of them reflect debian package. I'm maintain all those branch right now, and all of them is identical. I'm thinking about to delete the unstable. I'll maintain just the debian/latest for development, debian/ for backports, security and propose-update and mentioned on DEP-14. Thanks, Lucas Castro I am picking up this leftover work. I think everything is fine now except for https://bugs.debian.org/1054086 , which is overdue and must be fixed. Once you prepare a new version that no longer installs files under /lib/, please notify me and I can sponsor the upload. I'll review this ASAP and let you know when done. Thanks. Thanks, Boyuan Yang OpenPGP_0x42F79A5E0A4D5598.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Sorry for top posting. The debian/control was modified to append Git fields, Cvs-Git and Cvs-Browser. Git repository is following the DEP-14 as suggested, I really appreciated that workflow. Changelog was improved. It reflects the all debian package modification right now. There's something to do yet, about the gbp as Daniel had mentioned, All things about debian branch and upstream branch for debian git. I had uploaded the package to mentors, https://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.21-1.dsc The package can be checked from the git repository too, the following uri Vcs-Browser: https://git.gnuabordo.com.br/foolsm.git Vcs-Git: https://git.gnuabordo.com.br/foolsm.git The debian/latest, debian/trixie and debian/unstable branches, all of them reflect debian package. I'm maintain all those branch right now, and all of them is identical. I'm thinking about to delete the unstable. I'll maintain just the debian/latest for development, debian/ for backports, security and propose-update and mentioned on DEP-14. Thanks, Lucas Castro Em 11/05/2024 03:44, Tobias Frost escreveu: On Mon, May 06, 2024 at 08:02:17PM +0200, Daniel Gröber wrote: On Mon, May 06, 2024 at 02:10:53PM -0300, Lucas Castro wrote: [DEFAULT] debian-branch = gnuabordo/latest debian-tag = gnuabordo/%(version)s Please let me suggest to use DEP14 for branch naming: https://dep-team.pages.debian.net/deps/dep14/ -- tobi OpenPGP_0x42F79A5E0A4D5598.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Em 06/05/2024 11:31, Daniel Gröber escreveu: Hi Lucas, Hi d-mentors (there's a workflow question below), On Sun, Mar 24, 2024 at 05:16:54PM -0300, Lucas Castro wrote: The source builds the following binary packages: foolsm - Link connectivity monitor tool lsm - Link connectivity monitor tool - transitional package To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lsm/ Alternatively, you can download the package with 'dget' using this command: dget -xhttps://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.21-1.dsc I like using git since it makes dsc review easier. I've converted the upstream tarball history and your uploads to git using gbp and put them here: https://salsa.debian.org/debian/lsm I'm already using gbp, on my own repository server https://git.gnuabordo.com.br/foolsm.git/, I haven't created the salsa account yet. If you don't want to use git that's fine it's just a convinience for the me or the next DD to sponsor lsm but I'd be happy to help you figure out the Debian git workflow if you want. Package Review -- d/changelog: lsm (1.0.21-1) unstable; urgency=medium . * New upstream release (Closes: #1041221) * Usrmerge compliance (Closes: #1054086) Could be more specific. "Use dh_installsystemd to install units" maybe? * Package rename Use imperative in changelogs and be more specific: "Rename package to 'foolsm' to stay consistent with upstream" or some such. - Added transitional package for renaming process More specific please. I'd go with straight prose and not bullet-points myself. Say: "The old 'lsm' package is now transitional and installs the new 'foolsm' package. - Debian package was modified after upstream project rename. I'm not sure what you're trying to tell me here? * debian/watch updated * debian/patches/ cleaned out IMO these are implied. Ofc. we're going to do that when we update a package in Debian so while these would make good git commits I don't think they should be in d/changelog since that's mostly user-facing. Maybe that's just my git sensibilities showing and it's perfectly appropriate to note this in d/changelog for the old dsc focused workflow? Feel free to rebuttle this point. d/copyright: Files: * Copyright: 2009-2016 Mika Ilmaranta 2009-2015 Tuomo Soini licensecheck finds newer copyright dates, some ftp reviewers like to be pedantic here and since we'll make a trip through NEW its best to be exact here, should be: Copyright: 2009-2019 Mika Ilmaranta 2009-2021 Tuomo Soini Yep, Forgot about this copyright update. d/rules: DEBUG=true I'm not sure how to feel about this. Do you have a reason for turning it on? Seems the last upload had it commented out. From a quick codereivew it does look to just add more logging, so it's probably fine? Ops, built upon wrong git branch. = ) I'm going upload a new package. Looking at the generated maintainerscripts in the foolsm deb I don't see anything related to dpkg-maintscript-helper, are you sure that's hooked up right? Good job finding that obscurica BTW I didn't know about that myself :) that's applied for transitional package, conf path update. man says: When using a packaging helper, please check if it has native dpkg-maintscript-helper integration, which might make your life easier. See for example dh_installdeb(1). Hmm. I do see: $ cat debian/lsm.preinst.debhelper # Automatically added by dh_installdeb/13.11.4 dpkg-maintscript-helper mv_conffile /etc/lsm/lsm.config /etc/foolsm/foolsm.conf 1.0.21\~ -- "$@" # End automatically added section but that somehow doesn't seem to make it into the deb. Oh. The lsm.maintscript probably has to be called s/lsm/foolsm/ for it to work. Nope, the maintscript is right, should be ran just for lsm update, or somehow the lsm is installed but foolsm is available. The script will check if /etc/lsm/lsm.conf already exist, then it'll move the conf file. Random notes: I also noticed the upstream tarballs have started including a debian/ directory for a non-native packaging. Do you know what's up with that? I could see why they would include it if they packaged it as a "native" package but for non-native it just makes no sense. Could you talk to upstream to figure out what's up with that? Feel free to CC me. My guess is they would try update the package because I had missed. Just FYI: I'd appreciate git commits/patches on top of my repo above instead of an updated dsc dump. As I mentioned, I don't have a salsa account, I really would like to keep my own repository by now, maybe soon I'll create an account. Thanks, --Daniel Thanks. OpenPGP_0x42F79A5E0A4D5598.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
retitle 1064297 RFS: lsm/1.0.21-1 -- Link connectivity monitor tool As the source package has changed the package could be retrieve by the following url. The source builds the following binary packages: foolsm - Link connectivity monitor tool lsm - Link connectivity monitor tool - transitional package To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lsm/ Alternatively, you can download the package with 'dget' using this command: dget -xhttps://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.21-1.dsc Em 24/03/2024 16:50, Lucas Castro escreveu: Em 23/03/2024 13:08, Tobias Frost escreveu: Control: tags -1 moreinfo The source package name is still being renamed, and the source package rename is not explictly stated in the changelog. Source package already kept old project name, only binary renamed. I had talked about the source package rename on IRC, and no problem was pointed as serious then the my conclusion it wasn't going to be a problem. But, by the way, it's going to be kept as it was. (I think this renane shouldn't be done, to keep the history of the package, not only the tracker but also the BTS and all the other services working on source packages.) (You should also bump the timestamp in the d/changelog, when uploading a new package to mentors.) Timestamp bumped. The patch in package should be fowarded; as it only changes *comments*, consider dropping it completly. Dropped the patch, ASAP I'll forward to upstream. Already uploaded to mentors. -- tobi Thanks Tobias. On Thu, 14 Mar 2024 22:25:04 -0300 Lucas Castro wrote: Em 06/03/2024 05:49, Daniel Gröber escreveu: Hi Lucas, On Tue, Mar 05, 2024 at 03:29:49PM -0300, Lucas Castro wrote: Are you sure you want to change the source package name? Doing so fractures the history of the package on tracker.d.o and it's not really necessary. The upstream has changed software name but it's a good point about tracker.d.o. Right, so users will try to `apt install foolsm` in the future, but the source package name is largeley irellevant to them. Quick package review: - d/postinst: I don't think it's useful to print the message about editing the config. I've only seen packages do that in special circumstances, do you have a justification for it being necessary here? Really, really not. I really would like improve that, I guess to write good doc and manual pages is enough. I would argue users (sysadmins in this case) are going to be familiar with the concept of having to configure a package before it becomes useful and while the daemon not being started at package installation is unconventional in Debian automatic config reloading is by far not universal so any config change to make lsm useful is going to elicit a restart anyway. So I just don't see why we'd want a conspicuous message telling people what they already know :) - You declare Replaces+Conflicts on lsm but you don't seem to take any care for the new binary package to actually be compatible with the old one since the config location changed. I'm in doubt, when the old config exist, if set dpkg to copy the old config from old location to the new one or if I just print/show up a message to users notifying about path update requirement. I think an automatic upgrade is the way to go in this case as long as the config format is still fully compatible to the old lsm-1.0.4, but since copying will leave cruft behind for the user to cleanup manually I think we should mv the config. If it's good/allowed do the copy, it could be applied in postinst. I think print/show up message is rightest way. Consider that people upgrade Debian systems for many, many years without reinstalling. So every bit of cruft we leave behind due to transitions such as this accumulates. I don't see a technical need for not doing so in this case so I think we should clean up behind ourselves and move the config to the new location. You should then absoluteley print a message in the log to note this fact, but perhaps not as conspicuously as you're printing the "configure me" message. Something like "Moving $OLD_PATH to $NEW_PATH" should suffice since the package(s) involved should be obvious from the filenames. Just uploaded to mentors again, now the update occur smoothly. --Daniel Thanks for taking time on testing update. OpenPGP_0x42F79A5E0A4D5598.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Em 23/03/2024 13:08, Tobias Frost escreveu: Control: tags -1 moreinfo The source package name is still being renamed, and the source package rename is not explictly stated in the changelog. Source package already kept old project name, only binary renamed. I had talked about the source package rename on IRC, and no problem was pointed as serious then the my conclusion it wasn't going to be a problem. But, by the way, it's going to be kept as it was. (I think this renane shouldn't be done, to keep the history of the package, not only the tracker but also the BTS and all the other services working on source packages.) (You should also bump the timestamp in the d/changelog, when uploading a new package to mentors.) Timestamp bumped. The patch in package should be fowarded; as it only changes *comments*, consider dropping it completly. Dropped the patch, ASAP I'll forward to upstream. Already uploaded to mentors. -- tobi Thanks Tobias. On Thu, 14 Mar 2024 22:25:04 -0300 Lucas Castro wrote: Em 06/03/2024 05:49, Daniel Gröber escreveu: Hi Lucas, On Tue, Mar 05, 2024 at 03:29:49PM -0300, Lucas Castro wrote: Are you sure you want to change the source package name? Doing so fractures the history of the package on tracker.d.o and it's not really necessary. The upstream has changed software name but it's a good point about tracker.d.o. Right, so users will try to `apt install foolsm` in the future, but the source package name is largeley irellevant to them. Quick package review: - d/postinst: I don't think it's useful to print the message about editing the config. I've only seen packages do that in special circumstances, do you have a justification for it being necessary here? Really, really not. I really would like improve that, I guess to write good doc and manual pages is enough. I would argue users (sysadmins in this case) are going to be familiar with the concept of having to configure a package before it becomes useful and while the daemon not being started at package installation is unconventional in Debian automatic config reloading is by far not universal so any config change to make lsm useful is going to elicit a restart anyway. So I just don't see why we'd want a conspicuous message telling people what they already know :) - You declare Replaces+Conflicts on lsm but you don't seem to take any care for the new binary package to actually be compatible with the old one since the config location changed. I'm in doubt, when the old config exist, if set dpkg to copy the old config from old location to the new one or if I just print/show up a message to users notifying about path update requirement. I think an automatic upgrade is the way to go in this case as long as the config format is still fully compatible to the old lsm-1.0.4, but since copying will leave cruft behind for the user to cleanup manually I think we should mv the config. If it's good/allowed do the copy, it could be applied in postinst. I think print/show up message is rightest way. Consider that people upgrade Debian systems for many, many years without reinstalling. So every bit of cruft we leave behind due to transitions such as this accumulates. I don't see a technical need for not doing so in this case so I think we should clean up behind ourselves and move the config to the new location. You should then absoluteley print a message in the log to note this fact, but perhaps not as conspicuously as you're printing the "configure me" message. Something like "Moving $OLD_PATH to $NEW_PATH" should suffice since the package(s) involved should be obvious from the filenames. Just uploaded to mentors again, now the update occur smoothly. --Daniel Thanks for taking time on testing update. OpenPGP_0x42F79A5E0A4D5598.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Em 06/03/2024 05:49, Daniel Gröber escreveu: Hi Lucas, On Tue, Mar 05, 2024 at 03:29:49PM -0300, Lucas Castro wrote: Are you sure you want to change the source package name? Doing so fractures the history of the package on tracker.d.o and it's not really necessary. The upstream has changed software name but it's a good point about tracker.d.o. Right, so users will try to `apt install foolsm` in the future, but the source package name is largeley irellevant to them. Quick package review: - d/postinst: I don't think it's useful to print the message about editing the config. I've only seen packages do that in special circumstances, do you have a justification for it being necessary here? Really, really not. I really would like improve that, I guess to write good doc and manual pages is enough. I would argue users (sysadmins in this case) are going to be familiar with the concept of having to configure a package before it becomes useful and while the daemon not being started at package installation is unconventional in Debian automatic config reloading is by far not universal so any config change to make lsm useful is going to elicit a restart anyway. So I just don't see why we'd want a conspicuous message telling people what they already know :) - You declare Replaces+Conflicts on lsm but you don't seem to take any care for the new binary package to actually be compatible with the old one since the config location changed. I'm in doubt, when the old config exist, if set dpkg to copy the old config from old location to the new one or if I just print/show up a message to users notifying about path update requirement. I think an automatic upgrade is the way to go in this case as long as the config format is still fully compatible to the old lsm-1.0.4, but since copying will leave cruft behind for the user to cleanup manually I think we should mv the config. If it's good/allowed do the copy, it could be applied in postinst. I think print/show up message is rightest way. Consider that people upgrade Debian systems for many, many years without reinstalling. So every bit of cruft we leave behind due to transitions such as this accumulates. I don't see a technical need for not doing so in this case so I think we should clean up behind ourselves and move the config to the new location. You should then absoluteley print a message in the log to note this fact, but perhaps not as conspicuously as you're printing the "configure me" message. Something like "Moving $OLD_PATH to $NEW_PATH" should suffice since the package(s) involved should be obvious from the filenames. Just uploaded to mentors again, now the update occur smoothly. --Daniel Thanks for taking time on testing update. Lucas Castro. OpenPGP_0x42F79A5E0A4D5598.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Please mail to debian-mentors-requ...@lists.debian.org with a subject unsubscribe. Em 05/03/2024 19:50, Fred escreveu: PLEASE REMOVE ME FROM ALL LISTS! I tried to remove myself. It didn't work. I tried to contact the list admin. I did not get an answer. I'M GONNA SPAM YOUR LISTS UNTIL YOU REMOVE ME! On 05.03.24 19:29, Lucas Castro wrote: Em 05/03/2024 08:09, Daniel Gröber escreveu: Hi Lucas, On Mon, Feb 19, 2024 at 04:50:27PM -0300, Lucas Castro wrote: * Package name : foolsm Are you sure you want to change the source package name? Doing so fractures the history of the package on tracker.d.o and it's not really necessary. The upstream has changed software name but it's a good point about tracker.d.o. I'll take a look at some project that has changed the name too, BTW I already looked at some of them but not checked the source package name. Quick package review: - d/postinst: I don't think it's useful to print the message about editing the config. I've only seen packages do that in special circumstances, do you have a justification for it being necessary here? Really, really not. I really would like improve that, I guess to write good doc and manual pages is enough. - You declare Replaces+Conflicts on lsm but you don't seem to take any care for the new binary package to actually be compatible with the old one since the config location changed. I'm in doubt, when the old config exist, if set dpkg to copy the old config from old location to the new one or if I just print/show up a message to users notifying about path update requirement. If it's good/allowed do the copy, it could be applied in postinst. I think print/show up message is rightest way. - d/foolsm.init: Still has the old $CONFIG path That's true, I'll update and re-upload. --Daniel OpenPGP_0x42F79A5E0A4D5598.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Em 05/03/2024 08:09, Daniel Gröber escreveu: Hi Lucas, On Mon, Feb 19, 2024 at 04:50:27PM -0300, Lucas Castro wrote: * Package name : foolsm Are you sure you want to change the source package name? Doing so fractures the history of the package on tracker.d.o and it's not really necessary. The upstream has changed software name but it's a good point about tracker.d.o. I'll take a look at some project that has changed the name too, BTW I already looked at some of them but not checked the source package name. Quick package review: - d/postinst: I don't think it's useful to print the message about editing the config. I've only seen packages do that in special circumstances, do you have a justification for it being necessary here? Really, really not. I really would like improve that, I guess to write good doc and manual pages is enough. - You declare Replaces+Conflicts on lsm but you don't seem to take any care for the new binary package to actually be compatible with the old one since the config location changed. I'm in doubt, when the old config exist, if set dpkg to copy the old config from old location to the new one or if I just print/show up a message to users notifying about path update requirement. If it's good/allowed do the copy, it could be applied in postinst. I think print/show up message is rightest way. - d/foolsm.init: Still has the old $CONFIG path That's true, I'll update and re-upload. --Daniel OpenPGP_0x42F79A5E0A4D5598.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "foolsm": * Package name : foolsm Version : 1.0.21-1 Upstream contact : [fill in name and email of upstream] * URL :http://lsm.foobar.fi/ * License : GPL-2 * Vcs : [fill in URL of packaging vcs] Section : utils The source builds the following binary packages: foolsm - Link connectivity monitor tool lsm - Link connectivity monitor tool - transitional package To access further information about this package, please visit the following URL: https://mentors.debian.net/package/foolsm/ Alternatively, you can download the package with 'dget' using this command: dget -xhttps://mentors.debian.net/debian/pool/main/f/foolsm/foolsm_1.0.21-1.dsc Changes for the initial release: foolsm (1.0.21-1) unstable; urgency=medium . * New upstream release * debian/watch updated * debian/patches/ cleaned out Regards, -- Lucas Castro OpenPGP_0x42F79A5E0A4D5598.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Is valid for Debian a source code not in English? (was Help to know if a package is valid)
Em 16/08/2022 22:50, braulio escreveu: On 22/08/05 15:36, braulio wrote: Good afternoon. I need help with a situation. I packaged a program under the GPL-3+ license where Upstream wrote all the texts in its native language Pt-Br, and for the packaging, I did all the translation to English, creating a directory 'debian/locale/en' with your required files for the translation as the 'manual', 'README', example and strings of the --help command. I would like to know if my package is valid, since I didn't find any kind of content in Debian Policy. I guess any changes to upstream must be implements along with patch and anything under debian/ must be related to debian package only. So shouldn't debian/locale/ be related locate of debian package itself? Below is a link to the packaging in my salsa for further clarification. https://salsa.debian.org/braulio/md2term Sincerely, -- Braulio H. M. Souto E-mail:brau...@disroot.org / XMPP:brau...@suchat.org FB39 DE61 869F 49D5 CCC8 3AE0 D53A 15D9 83A1 0B94 After a few days the package was uploaded to the NEW queue and a few days later it was approved by the FTP Master, so it is possible to have such a package in Debian.
Bug#970246: RFS: lsm/1.0.4-2 [RC] -- Link connectivity monitor tool
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "lsm": * Package name : lsm Version : 1.0.4-2 Upstream Author : [fill in name and email of upstream] * URL : http://lsm.foobar.fi/ * License : GPL-2 Section : utils It builds those binary packages: lsm - Link connectivity monitor tool To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lsm/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.4-2.dsc Changes since the last upload: lsm (1.0.4-2) unstable; urgency=medium
Bug#847969: RFS: libpam-ldap/186-2
On 18-12-2016 10:30, Andrey Rahmatullin wrote: > On Sat, Dec 17, 2016 at 02:54:18PM -0300, Lucas Castro wrote: >> Ready for upload. > The changelog still says 3.6.8. > So, done. -- Lucas Castro signature.asc Description: OpenPGP digital signature
Re: Bug#847969: RFS: libpam-ldap/186-2
On 18-12-2016 10:30, Andrey Rahmatullin wrote: > On Sat, Dec 17, 2016 at 02:54:18PM -0300, Lucas Castro wrote: >> Ready for upload. > The changelog still says 3.6.8. Mind crashing, I've noticed just the 's' missing on standard[s]-version. -- Lucas Castro signature.asc Description: OpenPGP digital signature
Bug#847969: RFS: libpam-ldap/186-2
Ready for upload. On 14-12-2016 13:36, Andrey Rahmatullin wrote: > Please remove extra empty lines from the changelog entry. > Why did you enable DH_VERBOSE=1? >
Re: Bug#847969: RFS: libpam-ldap/186-2
Thank you Eriberto, On 14-12-2016 13:55, Eriberto wrote: > Standards-Version = 3.6.8? (debian/changelog) > > > 2016-12-14 14:36 GMT-02:00 Andrey Rahmatullin : >> Please remove extra empty lines from the changelog entry. >> Why did you enable DH_VERBOSE=1? >> >> -- >> WBR, wRAR
Bug#847969: RFS: libpam-ldap/186-2
On 14-12-2016 13:36, Andrey Rahmatullin wrote: > Please remove extra empty lines from the changelog entry. > Why did you enable DH_VERBOSE=1? > Already fixed. signature.asc Description: OpenPGP digital signature
Bug#847969: RFS: libpam-ldap/186-2
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libpam-ldap" * Package name: libpam-ldap Version : 186-2 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : admin It builds those binary packages: libpam-ldap - Pluggable Authentication Module for LDAP To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libpam-ldap Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libp/libpam-ldap/libpam-ldap_186-2.dsc Changes since the last upload: It fixes #844666 bug. Regards, Lucas Castro signature.asc Description: OpenPGP digital signature
Re: Problems creating babel-polyfill.min.js
On 07-11-2016 13:11, Andreas Tille wrote: > Hi Gianfranco, > > On Mon, Nov 07, 2016 at 03:57:27PM +, Gianfranco Costamagna wrote: >>> When doing a websearch this might mean that the JS contains errors - but >>> it seems there is a different converter which has no problems. Before >>> I start debugging what exactly happens in "npm install" I wonder whether >>> comebody could enlighten me what's the best way to get the minimized JS. >> npm install is something like pip install, or ruby gems install (or whatever >> are called). >> In this case, just package it separately as js module and use it. >> pkg-javascript has a lot (almost all of them) of single js libraries packaged >> separately and with a dh helper that does most of the work > Are you sure that it makes sense to add more and more JS packages - its > simply for a single package dependency for the moment. However, if > somebody confirms that this package is sensible also for other purposes > I might fire up npm2deb ... > > Kind regards > > Andreas. For the point of view of your single project is just for a single package dependence, but think about all the package that didn't get in Debian yet just because of that dependence. I want to start the works on babel modules packaging soon, jut got some issues about how to split all modules that comes all together in single tarball. -- Lucas Castro signature.asc Description: OpenPGP digital signature
RFS: node-everything.js/1.0.3-1
Package: sponsorship-requests Severity: optional Dear mentors, I am looking for a sponsor for my package "node-everything.js" * Package name: node-everything.js Version : 1.0.3-1 * License : BSD-3-Clause Section : web It builds those binary packages: node-everything.js - Contains every ECMA-262 edition 5.1 grammatical production To access further information about this package, please visit the following URL: https://mentors.debian.net/package/node-everything.js Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/n/node-everything.js/node-everything.js_1.0.3-1.dsc Regards, Lucas Castro signature.asc Description: OpenPGP digital signature
Re: Bug#823895: RFS: lsm/1.0.4-1
On 27-07-2016 14:23, Gianfranco Costamagna wrote: > Hi, > > >> Who missing? I've checked, it's okay. > > > you right > >> About that, it's a new version with some patches I've forwarded. >> I'll wait for this version get in Debian to investigate the new version >> changes. > > I can sponsor, or wait, let me know. If you can check what Adam Borowski had pointed, It'll be fine. > G. I uploaded a new version with spell patch. signature.asc Description: OpenPGP digital signature
Re: Bug#823895: RFS: lsm/1.0.4-1
On 27-07-2016 13:14, Gianfranco Costamagna wrote:
> Lets finish the review:
> 1)
>
> grep copyright . -Ri
>
> missing people
Who missing? I've checked, it's okay.
> 2)
> debian/upstream/changelog
>
> what^
> 3) did you forward patches upstream?
forwarded the changelog? His changelog is merged into spec file.
>
> if you can fix/answer the above I think we are good
>
> check-all-the-things review:
> $ codespell --quiet-level=3
> ./config.c:169: unkown ==> unknown
> ./lsm.c:137: occured ==> occurred
> ./lsm.spec:825: lisence ==> license, licence
It is a false-positive, because the changelog is merged into this file,
so it's fix report in changelog.
> ./debian/lsm.init:12: conection ==> connection
> ./debian/upstream/changelog:695: lisence ==> license, licence
this file is extract from changelog, so is the same one above.
I'll fix the others.
>
> $ find -type d \( -iname .bzr -o -iname .git -o -iname .hg -o -iname .svn -o
> -iname CVS -o -iname RCS -o -iname SCCS -o -iname _MTN -o -iname _darcs -o
> -iname .pc -o -iname .cabal-sandbox -o -iname .cdv -o -iname .metadata -o
> -iname CMakeFiles -o -iname _build -o -iname _sgbak -o -iname autom4te.cache
> -o -iname blib -o -iname cover_db -o -iname node_modules -o -iname '~.dep' -o
> -iname '~.dot' -o -iname '~.nib' -o -iname '~.plst' \) -prune -o -type f ! \(
> -iname '*.bak' -o -iname '*.swp' -o -iname '#.*' -o -iname '#*#' -o -iname
> 'core.*' -o -iname '*~' -o -iname '*.gif' -o -iname '*.jpg' -o -iname
> '*.jpeg' -o -iname '*.png' -o -iname '*.min.js' -o -iname '*.js.map' -o
> -iname '*.js.min' -o -iname '*.min.css' -o -iname '*.css.map' -o -iname
> '*.css.min' \) -exec env PERL5OPT=-m-lib=. spellintian --picky {} +
>
>
> $ env PERL5OPT=-m-lib=. uscan --report-status --no-verbose
> uscan: Newest version of lsm on remote site is 1.0.5, local version is 1.0.4
> uscan:=> Newer package available from
> http://lsm.foobar.fi/download/lsm-1.0.5.tar.gz
About that, it's a new version with some patches I've forwarded.
I'll wait for this version get in Debian to investigate the new version
changes.
> G.
--
Lucas Castro
signature.asc
Description: OpenPGP digital signature
Re: Bug#823895: RFS: lsm/1.0.4-1
On 22-07-2016 00:31, Adam Borowski wrote: > On Thu, Jul 14, 2016 at 04:25:00PM -0300, Lucas Castro wrote: >> I've got a little busy, but I uploaded a reviewed package, >> if you can take a look at it I'll thanks. >> >> https://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.4-1.dsc > Apologies on making you wait, but -ENOTIME these days :( No problem about that. > I've looked at the new version, it seems good to me. > > However, I have no experiences with proper systemd-vs-sysv daemon setup nor > conffile handling myself, so I'd need to fill holes in my knowledge first > which is hard under ENOTIME conditions. Thus, I'd prefer someone else to > finish sponsoring this package. > If no one helps, I'll do it, but not in the next few days. Fine. > > Meow! by the way, what means ENOTIME? signature.asc Description: OpenPGP digital signature
Re: Bug#823895: RFS: lsm/1.0.4-1
On 21-05-2016 12:21, Adam Borowski wrote: > On Sat, May 21, 2016 at 12:09:14PM -0300, Lucas Castro wrote: >> On 21-05-2016 11:59, Adam Borowski wrote: >>> On Fri, May 20, 2016 at 10:31:49PM -0300, Lucas Castro wrote: >>>> But I don't think I need to write a documentation how to setup >>>> the config file is easy to understand, just feeding back it's needed to >>>> setup to get working. >>>> what do you think? >>> I meant mostly what's needed to get the basics running. >> My problem I didn't noticed problem about setup needed because I've >> installed at a machine was already working. > Right, that's understandable. > > If you're going to make complex changes to the packaging, it'd be a good > idea to test it in virtual machines, both fresh and as upgrades. However, > if you believe you can make it work without, there's no need to do so -- > I'll test it for you as I already have an array of VMs, some simple, some > bridged/etc. And especially, some with systemd some with modular inits, > as this package has .service divergent from its init script. > >>> I got the impression you're -trying- to have it work out of the box, in >>> which case no action is needed. If I'm wrong and configuration is >>> required,k >>> then you need to 1. handle lack of such config gracefully, and 2. point the >>> user as to what needs to be done. >> I've done the most changed you pointed, either the feedback about that >> setup is needed to get it running. >> my question is just about user perspective, if I really need to write a >> documentation how to configure or >> just show to user they need to setup. Something like "Edit >> /etc/lsm/lsm.conf is needed to get it running." > Just that line included in the fail message would be enough, I think. > > I've got a little busy, but I uploaded a reviewed package, if you can take a look at it I'll thanks. https://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.4-1.dsc signature.asc Description: OpenPGP digital signature
Bug#823895: RFS: lsm/1.0.4-1
On 21-05-2016 11:59, Adam Borowski wrote: > On Fri, May 20, 2016 at 10:31:49PM -0300, Lucas Castro wrote: >> On 14-05-2016 20:45, Adam Borowski wrote: >>> Only upon checking the syslog I see: >>> May 15 00:30:37 umbar lsm[12853]: no targets found in config file >>> yet according to comments in /etc/lsm/lsm.conf: >>> # Defaults for the connection entries >>> # These are set in the code. You may override any values here. >>> which suggests there's no need to edit the config for basic functionality. >>> >>> If I read this wrong and some setup is needed, then the package shouldn't >>> try to start the daemon on initial install, and provide a feedback that >>> editing the config file is required. >>> >>> There's no documentation describing what's needed to get lsm running. >> I'm almost fishing. >> But I don't think I need to write a documentation how to setup >> the config file is easy to understand, just feeding back it's needed to >> setup to get working. >> what do you think? > I meant mostly what's needed to get the basics running. My problem I didn't noticed problem about setup needed because I've installed at a machine was already working. > I got the impression you're -trying- to have it work out of the box, in > which case no action is needed. If I'm wrong and configuration is required, > then you need to 1. handle lack of such config gracefully, and 2. point the > user as to what needs to be done. I've done the most changed you pointed, either the feedback about that setup is needed to get it running. my question is just about user perspective, if I really need to write a documentation how to configure or just show to user they need to setup. Something like "Edit /etc/lsm/lsm.conf is needed to get it running." > > signature.asc Description: OpenPGP digital signature
Bug#823895: RFS: lsm/1.0.4-1
On 14-05-2016 20:45, Adam Borowski wrote: > On Sat, May 14, 2016 at 12:22:13AM -0300, Lucas Castro wrote: >> On 13-05-2016 11:46, Adam Borowski wrote: >>>> On 10-05-2016 02:43, Lucas Castro wrote >>>>> I am looking for a sponsor for my package "lsm" >>>>> >>>>> dget -x >>>>> https://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.4-1.dsc >>> 2. The manpage seems mangled: >>> >>>While simple to configure, provides easy way reconfigure routes, >>> calling notifyscript >>> >>>lsmVery configurable, but doesn't support domain names yet. >> Thanks, fixed. > Hmm, it looks like you merely added a space and lowercased V: > >While simple to configure, provides easy way reconfigure routes, > calling notifyscript. > >lsm very configurable program, but doesn't support domain names yet. > > These two lines don't quite make sense... > > >>> 3. Typo: exectuble. >> if you mean man page typo, fixed. > It's still in the init script, line 32. > > > Too bad, when actually trying to install the package: > > [] Starting Link Monitor.: lsminvoke-rc.d: initscript lsm, action "start" > failed. > dpkg: error processing package lsm (--install): > subprocess installed post-installation script returned error exit status 1 > Processing triggers for man-db (2.7.5-1) ... > Errors were encountered while processing: > lsm > > [~]# /etc/init.d/lsm start > [] Starting Link Monitor.: lsm[~]# echo $? > 1 > (no newline, by the way -- init scripts shouldn't use "set -e") > > [~]# lsm --config /etc/lsm/lsm.conf > [~]# echo $? > 1 > > An error message describing what went wrong would be nice... > > Only upon checking the syslog I see: > May 15 00:30:37 umbar lsm[12853]: no targets found in config file > yet according to comments in /etc/lsm/lsm.conf: > # Defaults for the connection entries > # These are set in the code. You may override any values here. > which suggests there's no need to edit the config for basic functionality. > > If I read this wrong and some setup is needed, then the package shouldn't > try to start the daemon on initial install, and provide a feedback that > editing the config file is required. > > There's no documentation describing what's needed to get lsm running. I'm almost fishing. But I don't think I need to write a documentation how to setup the config file is easy to understand, just feeding back it's needed to setup to get working. what do you think? > > Also, it appears the only copy of upstream's changelog is hidden inside > lsm.spec (lines between "%changelog" and "#EOF"). Please cut this (with sed > or a similar tool) and install as /usr/share/doc/*/changelog.gz > > > In /usr/share/doc/lsm/examples/lsm.conf.sample, there are references to > /usr/libexec/lsm/ instead of /usr/share/lsm/, it'd be nice to sed that to > what's installed on Debian. > > >>> Meow! >> Done. > Hah! This was intended as an onomatopeia not an imperative, but I really > like your interpretation :) > signature.asc Description: OpenPGP digital signature
Bug#823895: RFS: lsm/1.0.4-1
On 13-05-2016 11:46, Adam Borowski wrote: >> On 10-05-2016 02:43, Lucas Castro wrote >>> I am looking for a sponsor for my package "lsm" >>> >>> * Package name: lsm >>> Upstream Author : Mika Ilmaranta >>> * URL : http://lsm.foobar.fi/ >>> >>> dget -x >>> https://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.4-1.dsc > From a superficial review: > > 1. Please delete (or fill out) debian/README.source removed. > 2. The manpage seems mangled: > >While simple to configure, provides easy way reconfigure routes, > calling notifyscript > >lsmVery configurable, but doesn't support domain names yet. Thanks, fixed. > > 3. Typo: exectuble. if you mean man page typo, fixed. > > Meow! Done. signature.asc Description: OpenPGP digital signature
Re: Bug#823895: RFS: lsm/1.0.4-1
Hello, I made some changes at the packages, if someone can sponsor I'll thanks. On 10-05-2016 02:43, Lucas Castro wrote > Package: sponsorship-requests > Severity: normal [important for RC bugs, wishlist for new packages] > > Dear mentors, > > I am looking for a sponsor for my package "lsm" > > * Package name: lsm > Version : 1.0.4-1 > Upstream Author : Mika Ilmaranta > * URL : http://lsm.foobar.fi/ > * License : GPL-2 > Section : utils > > It builds those binary packages: > > lsm - Link connectivity monitor tool > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/lsm > > > Alternatively, one can download the package with dget using this command: > > dget -x https://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.4-1.dsc > > signature.asc Description: OpenPGP digital signature
Bug#823895: RFS: lsm/1.0.4-1
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "lsm" * Package name: lsm Version : 1.0.4-1 Upstream Author : Mika Ilmaranta * URL : http://lsm.foobar.fi/ * License : GPL-2 Section : utils It builds those binary packages: lsm - Link connectivity monitor tool To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lsm Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.4-1.dsc signature.asc Description: OpenPGP digital signature
Re: Need help to fix hardening-no-relro and hardening-no-relro
Okay, confirmed, solved the hardening-no-relro, and Now I can see I make a mistake on subject, It was to be hardening-no-relro and hardening-no-fortify-functions. On Tue, Aug 11, 2015 at 11:50 AM, lucas castro wrote: > I'll do that, and send to mentors. > > On Tue, Aug 11, 2015 at 11:48 AM, Gianfranco Costamagna < > costamagnagianfra...@yahoo.it> wrote: > >> Yes, this is true. >> >> The problem is that the FTBFS is due to security flags, so it might be >> good >> to solve it anyway. >> >> However, commenting out LDFLAGS from Makefile.in should solve the issue. >> >> BTW that "-s" on the LDFLAGS shouldn't be there, it was a packaging >> problem >> fixed -6 upload and reintroduced in the version on mentors. >> >> Lucas can you please comment that line? >> >> thanks! >> >> Gianfranco >> >> >> >> >> >> Il Martedì 11 Agosto 2015 16:40, Alex Vong ha >> scritto: >> Hi Lucas, >> >> I am new in packaging. `hardening-no-relro' also happens to me. It >> turns out it is caused by the missing `-Wl,-z,relro' LDFLAGS. Maybe >> overriding CFLAGS and CPPFLAGS but not LDFLAGS will solve FTBFS. >> >> For example in debian/rules, >> >> CFLAGS = '-Ofoo' >> CPPFLAGS = '-Dfoo' >> LDFLAGS += '-lfoo' >> >> override_dh_auto_configure: >> dh_auto_configure -- --enable-foo >> >> Cheers, >> Alex >> >> >> 2015-08-11 21:05 GMT+08:00, lucas castro : >> > Gianfranco, >> > No problem about about that on irc. >> > I think I should take a time on another package, then mailed here. >> > and if anyone know about this, it's fine. I really spent much time on >> this >> > package, >> > and learned a lot with it. >> > >> > On Tue, Aug 11, 2015 at 9:49 AM, Gianfranco Costamagna < >> > costamagnagianfra...@yahoo.it> wrote: >> > >> >> Hi Lucas >> >> (sorry for not answering on irc, I was AFK) >> >> >> >> hardening-check debian/xmbmon/usr/bin/xmbmon >> >> >> >> >> >> d/rules: >> >> override_dh_auto_build: >> >> $(MAKE) CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" >> CXXFLAGS="$(CXXFLAGS)" >> >> LDFLAGS="$(LDFLAGS)" >> >> >> >> >> >> >> >> something like this seems to make autoconf aware of the flags (not sure >> >> if >> >> there is a >> >> better way, and for sure you do not need them all). >> >> >> >> However with hardening stuff enabled now it FTBFS: >> >> >> >> gcc -g -O2 -fPIE -fstack-protector-strong -Wformat >> >> -Werror=format-security >> >> -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now -o mbmon >> >> mbmon.c getMBinfo.o tyan_tiger.o pci_pm.o sensors.o getMB-via.o >> >> getMB-smb.o >> >> getMB-isa.o smbuses.o smbus_piix4.o smbus_amd.o smbus_ali.o >> smbus_amd8.o >> >> sens_winbond.o sens_via686.o sens_it87.o sens_gl52.o sens_lm85.o >> >> sens_lm80.o sens_lm90.o sens_lm75.o sens_wl784.o smb_extemp.o -lm >> >> mbmon.c: In function ‘uptime’: >> >> mbmon.c:122:11: error: ‘KERN_BOOTTIME’ undeclared (first use in this >> >> function) >> >> mib[1] = KERN_BOOTTIME; >> >> ^ >> >> >> >> >> >> cheers, >> >> >> >> Gianfranco >> >> >> > >> > >> > >> > -- >> > contatos: >> > Celular: ( 99 ) 9143-5954 - Vivo >> > skype: lucasd3castro >> > msn: lucascastrobor...@hotmail.com >> > >> >> >> -- >> To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org >> with a subject of "unsubscribe". Trouble? Contact >> listmas...@lists.debian.org >> Archive: >> https://lists.debian.org/CADrxHD_sW9Hf1c==-uhsa1ks6iay5zrfew7aqeoy3frbd-4...@mail.gmail.com >> > > > > -- > contatos: > Celular: ( 99 ) 9143-5954 - Vivo > skype: lucasd3castro > msn: lucascastrobor...@hotmail.com > -- contatos: Celular: ( 99 ) 9143-5954 - Vivo skype: lucasd3castro msn: lucascastrobor...@hotmail.com
Re: Need help to fix hardening-no-relro and hardening-no-relro
I'll do that, and send to mentors. On Tue, Aug 11, 2015 at 11:48 AM, Gianfranco Costamagna < costamagnagianfra...@yahoo.it> wrote: > Yes, this is true. > > The problem is that the FTBFS is due to security flags, so it might be good > to solve it anyway. > > However, commenting out LDFLAGS from Makefile.in should solve the issue. > > BTW that "-s" on the LDFLAGS shouldn't be there, it was a packaging problem > fixed -6 upload and reintroduced in the version on mentors. > > Lucas can you please comment that line? > > thanks! > > Gianfranco > > > > > > Il Martedì 11 Agosto 2015 16:40, Alex Vong ha > scritto: > Hi Lucas, > > I am new in packaging. `hardening-no-relro' also happens to me. It > turns out it is caused by the missing `-Wl,-z,relro' LDFLAGS. Maybe > overriding CFLAGS and CPPFLAGS but not LDFLAGS will solve FTBFS. > > For example in debian/rules, > > CFLAGS = '-Ofoo' > CPPFLAGS = '-Dfoo' > LDFLAGS += '-lfoo' > > override_dh_auto_configure: > dh_auto_configure -- --enable-foo > > Cheers, > Alex > > > 2015-08-11 21:05 GMT+08:00, lucas castro : > > Gianfranco, > > No problem about about that on irc. > > I think I should take a time on another package, then mailed here. > > and if anyone know about this, it's fine. I really spent much time on > this > > package, > > and learned a lot with it. > > > > On Tue, Aug 11, 2015 at 9:49 AM, Gianfranco Costamagna < > > costamagnagianfra...@yahoo.it> wrote: > > > >> Hi Lucas > >> (sorry for not answering on irc, I was AFK) > >> > >> hardening-check debian/xmbmon/usr/bin/xmbmon > >> > >> > >> d/rules: > >> override_dh_auto_build: > >> $(MAKE) CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" CXXFLAGS="$(CXXFLAGS)" > >> LDFLAGS="$(LDFLAGS)" > >> > >> > >> > >> something like this seems to make autoconf aware of the flags (not sure > >> if > >> there is a > >> better way, and for sure you do not need them all). > >> > >> However with hardening stuff enabled now it FTBFS: > >> > >> gcc -g -O2 -fPIE -fstack-protector-strong -Wformat > >> -Werror=format-security > >> -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now -o mbmon > >> mbmon.c getMBinfo.o tyan_tiger.o pci_pm.o sensors.o getMB-via.o > >> getMB-smb.o > >> getMB-isa.o smbuses.o smbus_piix4.o smbus_amd.o smbus_ali.o smbus_amd8.o > >> sens_winbond.o sens_via686.o sens_it87.o sens_gl52.o sens_lm85.o > >> sens_lm80.o sens_lm90.o sens_lm75.o sens_wl784.o smb_extemp.o -lm > >> mbmon.c: In function ‘uptime’: > >> mbmon.c:122:11: error: ‘KERN_BOOTTIME’ undeclared (first use in this > >> function) > >> mib[1] = KERN_BOOTTIME; > >> ^ > >> > >> > >> cheers, > >> > >> Gianfranco > >> > > > > > > > > -- > > contatos: > > Celular: ( 99 ) 9143-5954 - Vivo > > skype: lucasd3castro > > msn: lucascastrobor...@hotmail.com > > > > > -- > To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: > https://lists.debian.org/CADrxHD_sW9Hf1c==-uhsa1ks6iay5zrfew7aqeoy3frbd-4...@mail.gmail.com > -- contatos: Celular: ( 99 ) 9143-5954 - Vivo skype: lucasd3castro msn: lucascastrobor...@hotmail.com
Re: Need help to fix hardening-no-relro and hardening-no-relro
Gianfranco, No problem about about that on irc. I think I should take a time on another package, then mailed here. and if anyone know about this, it's fine. I really spent much time on this package, and learned a lot with it. On Tue, Aug 11, 2015 at 9:49 AM, Gianfranco Costamagna < costamagnagianfra...@yahoo.it> wrote: > Hi Lucas > (sorry for not answering on irc, I was AFK) > > hardening-check debian/xmbmon/usr/bin/xmbmon > > > d/rules: > override_dh_auto_build: > $(MAKE) CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" CXXFLAGS="$(CXXFLAGS)" > LDFLAGS="$(LDFLAGS)" > > > > something like this seems to make autoconf aware of the flags (not sure if > there is a > better way, and for sure you do not need them all). > > However with hardening stuff enabled now it FTBFS: > > gcc -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security > -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now -o mbmon > mbmon.c getMBinfo.o tyan_tiger.o pci_pm.o sensors.o getMB-via.o getMB-smb.o > getMB-isa.o smbuses.o smbus_piix4.o smbus_amd.o smbus_ali.o smbus_amd8.o > sens_winbond.o sens_via686.o sens_it87.o sens_gl52.o sens_lm85.o > sens_lm80.o sens_lm90.o sens_lm75.o sens_wl784.o smb_extemp.o -lm > mbmon.c: In function ‘uptime’: > mbmon.c:122:11: error: ‘KERN_BOOTTIME’ undeclared (first use in this > function) > mib[1] = KERN_BOOTTIME; > ^ > > > cheers, > > Gianfranco > -- contatos: Celular: ( 99 ) 9143-5954 - Vivo skype: lucasd3castro msn: lucascastrobor...@hotmail.com
Need help to fix hardening-no-relro and hardening-no-relro
I'm getting harderning issue on packaging xmbmon.
I already looked at https://wiki.debian.org/Hardening, but no success.
I uploaded the source to mentors[1], and the attachment is the build log.
[1] http://mentors.debian.net/debian/pool/main/x/xmbmon/xmbmon_2.05-8.dsc
--
contatos:
Celular: ( 99 ) 9143-5954 - Vivo
skype: lucasd3castro
msn: lucascastrobor...@hotmail.com
dpkg-buildpackage -rfakeroot -D -us -uc
dpkg-buildpackage: warning: using a gain-root-command while being root
dpkg-buildpackage: source package xmbmon
dpkg-buildpackage: source version 2.05-8
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Lucas de Castro Borges
dpkg-source --before-build xmbmon-2.05
dpkg-buildpackage: host architecture amd64
dpkg-source: info: applying fix_manpage_errors.patch
dpkg-source: info: applying fix_manpage_typos.patch
dpkg-source: info: applying restart_without_wait.patch
dpkg-source: info: applying manpage_read_mbmon-rrd.patch
dpkg-source: info: applying replace_mbmon-rrd.patch
dpkg-source: info: applying changed-readme_binaryname.patch
dpkg-source: info: applying changes_for_debian-makefile.patch
dpkg-source: info: applying fix_makefile_install.patch
dpkg-source: info: applying fix-autoreconf_missing_template.patch
dpkg-source: info: applying autotools-update.patch
fakeroot debian/rules clean
dh clean --with autoreconf
dh_testdir
dh_auto_clean
make -j1 distclean
make[1]: Entering directory '/QA/pkg-xmbmon/xmbmon-2.05'
rm -f *.o *.bak a.out core *.core *~ mbmon xmbmon testpci testsmb testhwm testfan mbmon_small
rm -f Makefile config.cache config.log config.h config.status
make[1]: Leaving directory '/QA/pkg-xmbmon/xmbmon-2.05'
dh_autoreconf_clean
rm -f -- ./config.h.in ./autom4te.cache/requests ./autom4te.cache/traces.1 ./autom4te.cache/output.0 ./autom4te.cache/output.1 ./autom4te.cache/traces.0 ./configure
rm -f debian/autoreconf.before debian/autoreconf.after
dh_clean
rm -f debian/xmbmon.substvars
rm -f debian/xmbmon.*.debhelper
rm -rf debian/xmbmon/
rm -f debian/mbmon.substvars
rm -f debian/mbmon.*.debhelper
rm -rf debian/mbmon/
rm -rf debian/.debhelper/
rm -f debian/*.debhelper.log
rm -f debian/files
find . \( \( \
\( -path .\*/.git -o -path .\*/.svn -o -path .\*/.bzr -o -path .\*/.hg -o -path .\*/CVS \) -prune -o -type f -a \
\( -name '#*#' -o -name '.*~' -o -name '*~' -o -name DEADJOE \
-o -name '*.orig' -o -name '*.rej' -o -name '*.bak' \
-o -name '.*.orig' -o -name .*.rej -o -name '.SUMS' \
-o -name TAGS -o \( -path '*/.deps/*' -a -name '*.P' \) \
\) -exec rm -f {} + \) -o \
\( -type d -a -name autom4te.cache -prune -exec rm -rf {} + \) \)
rm -rf debian/tmp
rm -f *-stamp
dpkg-source -b xmbmon-2.05
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building xmbmon using existing ./xmbmon_2.05.orig.tar.gz
dpkg-source: warning: ignoring deletion of file config.h.in, use --include-removal to override
dpkg-source: warning: ignoring deletion of file configure, use --include-removal to override
dpkg-source: info: building xmbmon in xmbmon_2.05-8.debian.tar.xz
dpkg-source: info: building xmbmon in xmbmon_2.05-8.dsc
debian/rules build
dh build --with autoreconf
dh_testdir
dh_autoreconf
find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a -type f -exec md5sum {} \; > debian/autoreconf.before
autoreconf -f -i
aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in'
find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a -type f -exec md5sum {} \; > debian/autoreconf.after
dh_auto_configure
./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu --libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode --disable-dependency-tracking
configure: WARNING: unrecognized options: --disable-silent-rules, --disable-maintainer-mode, --disable-dependency-tracking
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for a BSD-compatible install... /usr/bin/install -c
checking how to run the C preprocessor... gcc -E
checking for X... libraries , headers
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking build system type... x86_64-pc-l
Bug#792443: RFS: mirage/0.9.5.1-4 [QA]
All right now. Uploaded to mentors, On Tue, Jul 14, 2015 at 10:05 PM, Eriberto Mota wrote: > tags 792443 moreinfo > thanks > > > Hi Lucas, > > I will try help you. My considerations: > > 1. I can see some changes not registered in d/changelog. An example of > this is DH level change (from 7 to 9). I used the 'debdiff' command to > see the changes. Other files: debian/mirage.postinst, > debian/patches/remove_gimp_remote.patch, debian/pycompat > > 2. d/changelog: > > - I suggest you to organize better the ideas. Try to use a logical > order. You can sort the itens by events (Added, Changed, Removed, > Updated, etc) or by main events followed by files (debian/control, > debian/copyright, etc). For the latter case, you can see an example > here[1]. > > - Please, remove the unnecessary double spaces. > > - Use debian/ for all files inside the debian/ directory, as > debian/watch ans debian/patches/desktop_entry_issue.patch. > > - Use '$ spell changelog | sort -u' and '$ spell control | sort -u' to > search for spelling errors, as 'Dependeces'. > > [1] > http://metadata.ftp-master.debian.org/changelogs/main/l/lime-forensics/unstable_changelog > > 3. d/control: you found a new upstream homepage to use in d/watch. So, > why you removed the Homepage field from d/control? > > 4. debian/copyright: > > - The "updated" notice in d/changelog is a bit generic because you did > several modifications. > > - I found this text in upstream source code: > > mirage-Mirage is free software; you can redistribute it and/or modify > mirage-it under the terms of the GNU General Public License as published by > mirage-the Free Software Foundation; either version 3 of the License, or > mirage-(at your option) any later version. > > mirage.py-Mirage is free software; you can redistribute it and/or modify > mirage.py-it under the terms of the GNU General Public License as > published by > mirage.py-the Free Software Foundation; either version 3 of the License, or > mirage.py-(at your option) any later version. > > So, the source code is GPL-3+, not GPL-3. You need to use the > following command to check this situation: > > $ egrep -sriA25 '(copyright|public dom)' * > > - There are several authors in po/ directory. > > - You must to list all packagers in debian/* block. You can use the > following command to search for all: > > $ egrep '(--|\[)' debian/changelog > > 5. d/watch: your configuration produces notices about invalid > character in version number (two underscores). > > 6. You must always check the PTS[2] to search for bugs, tips etc. In > bugs list I can see a relevant bug that you can close: #773997. > > [2] https://packages.qa.debian.org/m/mirage.html > > Thanks for your work. > > Regards, > > Eriberto > > > 2015-07-14 17:09 GMT-03:00 Lucas Castro : > > Package: sponsorship-requests > > Severity: normal > > > > Dear mentors, > > > > I am looking for a sponsor for my package "mirage" > > > >This orphaned packages required some lintian corrections and I had > done, > >it already has two P lintians, but it is its homepage fields and > signature > >that I didn't found. > > > > * Package name: mirage > > Version : 0.9.5.1-4 > > Upstream Author : [fill in name and email of upstream] > > * URL : [fill in URL of upstreams web site] > > * License : [fill in] > > Section : graphics > > > > It builds those binary packages: > > > > mirage - fast and simple GTK+ image viewer > > > > To access further information about this package, please visit the > following URL: > > > > http://mentors.debian.net/package/mirage > > > > Alternatively, one can download the package with dget using this > command: > > > > dget -x > http://mentors.debian.net/debian/pool/main/m/mirage/mirage_0.9.5.1-4.dsc > > > > More information about hello can be obtained from > http://www.example.com. > > > > Changes since the last upload: > > > > * QA upload. > > * Updated watch > > * debian/control > > - Bumped Standards-Version to 3.9.6 > > - Homepage removed > > * debian/copyright updated > > * Added desktop_entry_issue.patch: Avoid > desktop-entry-lacks-keywords-entry. > > * Build-Dependeces: added dh-python. > > > > -- System Information: > > Debian Release: 8.1 > > APT prefers stable-updates > > APT p
Bug#792443: RFS: mirage/0.9.5.1-4 [QA]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "mirage" This orphaned packages required some lintian corrections and I had done, it already has two P lintians, but it is its homepage fields and signature that I didn't found. * Package name: mirage Version : 0.9.5.1-4 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : graphics It builds those binary packages: mirage - fast and simple GTK+ image viewer To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mirage Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mirage/mirage_0.9.5.1-4.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: * QA upload. * Updated watch * debian/control - Bumped Standards-Version to 3.9.6 - Homepage removed * debian/copyright updated * Added desktop_entry_issue.patch: Avoid desktop-entry-lacks-keywords-entry. * Build-Dependeces: added dh-python. -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=pt_BR.utf8, LC_CTYPE=pt_BR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150714200940.16904.7.reportbug@debian
