Re: Request help for mentoring
On Fri, Apr 5, 2019 at 12:59 PM Cyriac Biju wrote: > I am a novice developer and I was wondering as to where I can start off with > contributing to debian packages. I have basic knowledge of commands and > practices used in the development process and would like to request > mentorship for the same. Others have pointed you at the packaging documentation but I have some extra advice. A good way to contribute is to help out with packages that are important or interesting to you in some way. The how-can-i-help tool can help find packages installed on your system that need help in some way. https://wiki.debian.org/how-can-i-help Debian mostly does mentoring by having people ask specific questions in public and having people who know the answers reply in public. There are also a few opportunities for one-on-one mentoring: https://wiki.debian.org/Mentoring There are lots of other ways to contribute, including other technical options: https://www.debian.org/intro/help -- bye, pabs https://wiki.debian.org/PaulWise
Re: Request help for mentoring
On Fri, Apr 05, 2019 at 10:28:36AM +0530, Cyriac Biju wrote: > Sir, > I am a novice developer and I was wondering as to where I can start > off with contributing to debian packages. I have basic knowledge of > commands and practices used in the development process and would like to > request mentorship for the same. https://mentors.debian.net/intro-maintainers -- WBR, wRAR signature.asc Description: PGP signature
Re: Request help for mentoring
https://www.debian.org/doc/manuals/maint-guide/ https://www.debian.org/doc/manuals/debmake-doc/ http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html On Fri, Apr 5, 2019 at 11:29 AM Cyriac Biju wrote: > Sir, > I am a novice developer and I was wondering as to where I can start > off with contributing to debian packages. I have basic knowledge of > commands and practices used in the development process and would like to > request mentorship for the same. > Thanking you > Cyriac Biju N. > -- with regards *Ko Ko Ye`* +95 97989 22022 +95 94500 22022 +95 9731 47907 kokoye2...@gmail.com kokoye2...@ubuntu.com skype: kokoye2007 jitsi: kokoye2007 http://ubuntu-mm.net http://wiki.ubuntu.com/kokoye2007 http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm
Request help for mentoring
Sir, I am a novice developer and I was wondering as to where I can start off with contributing to debian packages. I have basic knowledge of commands and practices used in the development process and would like to request mentorship for the same. Thanking you Cyriac Biju N.
Bug#926306: RFS: socklog/2.1.0-9
On Thu, Apr 04, 2019 at 01:40:16PM +0200, Mathieu Mirmont wrote: > On Thu, Apr 04, 2019 at 12:48:43PM +0200, Adam Borowski wrote: > > A nice new process is described here: > >https://wiki.debian.org/PackageSalvaging > > but it's probably an overkill for a clear case like here. But, the old > > maintainer being the upstream means you need to at least communicate with > > him beforehand. > > I did reach out to Gerrit Pape (previous maintainer & upstream) of > course before doing anything. I offered to help and he was happy to hand > over the package to me. I'll file an ITS if you guys think I should. > > Adding Gerrit Pape to CC. Hi all, this is okay with me! I'm happy to hand over the package, sorry for not making this clear in advance. Best Regards, and have fun, Mathieu, with maintaining socklog.
Bug#926306: RFS: socklog/2.1.0-9
On Thu, Apr 04, 2019 at 01:30:30PM +0200, Mathieu Mirmont wrote: > On Thu, Apr 04, 2019 at 10:20:47AM +, Dmitry Bogatov wrote: > > * I know, it is pain, but there should be init.d script. You may want to > > take a look at bcron=0.11-8. > > Sure, no worries. How about systemd service files? It makes little sense > to run socklog along with systemd I think, but for the principle it may > be required to profile service files. What do you think? No point in adding .service if you already have an init script; that'd be useful only if you want to do something _different_ when running under systemd, or when you hit a systemd bug that makes it unable to handle a regular init script. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8" ⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs? ⠈⠳⣄
Bug#926306: RFS: socklog/2.1.0-9
On Thu, Apr 04, 2019 at 01:40:16PM +0200, Mathieu Mirmont wrote: > I did reach out to Gerrit Pape (previous maintainer & upstream) of > course before doing anything. I offered to help and he was happy to hand > over the package to me. Cool, that answers my question. It'll be enough to write "New maintainer" in the changelog then. > I'll file an ITS if you guys think I should. No point, you already have Gerrit's consent. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8" ⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs? ⠈⠳⣄
Bug#926306: RFS: socklog/2.1.0-9
On Thu, Apr 04, 2019 at 12:48:43PM +0200, Adam Borowski wrote: > On Wed, Apr 03, 2019 at 10:45:56AM +0200, Mathieu Mirmont wrote: > > * Package name: socklog > > Version : 2.1.0-9 > > Upstream Author : Gerrit Pape > > > Changes since the last upload: > > > > * Convert the package to debhelper (Closes: #857208) > > * patches: Import previous patches > > * patch: remove the chkshsgr test > > * watch: add the uscan watch file > > * socklog-run: migrate to dh-runit (Closes: #668718, #834089) > > * gitlab-ci.yml: add GitLab CI file > > * control: update the Vcs fields > > * doc-base: register the html documentation > > * lintian: add overrides > > This is a package hijack. In this case, the package is so neglected (no > maintainer upload in 11 years, long-standing RC bugs) that insisting on the > proper procedure would be a waste of time -- but it still should be done > consciously. No mention in the changelog suggests that it's not. > > A nice new process is described here: >https://wiki.debian.org/PackageSalvaging > but it's probably an overkill for a clear case like here. But, the old > maintainer being the upstream means you need to at least communicate with > him beforehand. I did reach out to Gerrit Pape (previous maintainer & upstream) of course before doing anything. I offered to help and he was happy to hand over the package to me. I'll file an ITS if you guys think I should. Adding Gerrit Pape to CC. Cheers, -- Mathieu Mirmont signature.asc Description: PGP signature
Bug#926306: RFS: socklog/2.1.0-9
On Thu, Apr 04, 2019 at 10:20:47AM +, Dmitry Bogatov wrote:
> * Please, do not use ${runit:Conflicts}. As suggested by Lintian, it is
> very strong relations. Use ${runit:Breaks} only. The very
> introduction of ${runit:Conflicts} was my mistake. It will make
> Lintian override unneeded.
Will do.
> * Please, consider merging bin:socklog-run into bin:socklog. Option
> `since' for dh_runit will be useful for it.
Ah that's what you meant, sorry I misunderstood. I will try to merge
them.
> * I know, it is pain, but there should be init.d script. You may want to
> take a look at bcron=0.11-8.
Sure, no worries. How about systemd service files? It makes little sense
to run socklog along with systemd I think, but for the principle it may
be required to profile service files. What do you think?
> * Please, add description to 0002-import-patch-tryto. It is unclear,
> what issue this patch resolves.
This one comes from the previous packaging scripts. I'll do some
digging.
> * In patch 0003-remove-chkshgrp you remove test, that fails on CI. Does
> it also fails in sbuild? If not, probably it should only be disabled in
> Gitlab CI?
It only fails in CI. I'll try to have it disabled in CI only, that would
be much better indeed.
> * It is matter of taste, but are you aware, that you can
>
> Build-Depends: debhelper-compat (= 12)
>
> and remove `debian/compat'?
I didn't know, thanks :)
> * Dep-5 would be nice.
Will do.
> * What is the purpose of 'log' user, you create with dh_sysuser? You
> know, that bin:runit provides user `runit-log' since -20, don't you?
I overlooked that, thanks.
> * All services run as same user, 'nobody'. It is unfortunate, since nobody is
> quite popular owner for NFS files.
>
> I believe there should be separate sysuser for socklog-* services.
> Ideally, separate sysuser for /every/ from socklog-* service, but I do
> not know, whehter it is possible.
Yeah good point. I tend to think that a single user for all socklog-*
services would be enough, but if you prefer I can add one user per
service.
> * I believe, README file is useless -- it contains copyright, authorship
> and homepage information only, which is already present in Debian
> package files.
Alright, I'll remove it.
Thanks for the review!
Cheers,
--
Mathieu Mirmont
signature.asc
Description: PGP signature
Bug#926306: RFS: socklog/2.1.0-9
On Wed, Apr 03, 2019 at 10:45:56AM +0200, Mathieu Mirmont wrote: > * Package name: socklog > Version : 2.1.0-9 > Upstream Author : Gerrit Pape > Changes since the last upload: > > * Convert the package to debhelper (Closes: #857208) > * patches: Import previous patches > * patch: remove the chkshsgr test > * watch: add the uscan watch file > * socklog-run: migrate to dh-runit (Closes: #668718, #834089) > * gitlab-ci.yml: add GitLab CI file > * control: update the Vcs fields > * doc-base: register the html documentation > * lintian: add overrides This is a package hijack. In this case, the package is so neglected (no maintainer upload in 11 years, long-standing RC bugs) that insisting on the proper procedure would be a waste of time -- but it still should be done consciously. No mention in the changelog suggests that it's not. A nice new process is described here: https://wiki.debian.org/PackageSalvaging but it's probably an overkill for a clear case like here. But, the old maintainer being the upstream means you need to at least communicate with him beforehand. Adding Mattia Rizzolo to CC -- he's not only handling MIA, but also happened to NMU this package a couple of years ago. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8" ⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs? ⠈⠳⣄
Bug#926306: RFS: socklog/2.1.0-9
[2019-04-03 10:45] Mathieu Mirmont
> Package: sponsorship-requests
> Severity: normal [important for RC bugs, wishlist for new packages]
>
> Dear mentors,
>
> I am looking for a sponsor for my package "socklog"
>
> * Package name: socklog
> Version : 2.1.0-9
> Upstream Author : Gerrit Pape
> * URL : http://smarden.org/socklog
> * License : BSD
> Section : admin
>
> It builds those binary packages:
>
> socklog - system and kernel logging services (programs)
> socklog-run - system and kernel logging services
>
> To access further information about this package, please visit the
> following URL:
>
> https://mentors.debian.net/package/socklog
>
>
> Alternatively, one can download the package with dget using this
> command:
>
> dget -x
> https://mentors.debian.net/debian/pool/main/s/socklog/socklog_2.1.0-9.dsc
>
> Changes since the last upload:
>
> * Convert the package to debhelper (Closes: #857208)
> * patches: Import previous patches
> * patch: remove the chkshsgr test
> * watch: add the uscan watch file
> * socklog-run: migrate to dh-runit (Closes: #668718, #834089)
> * gitlab-ci.yml: add GitLab CI file
> * control: update the Vcs fields
> * doc-base: register the html documentation
> * lintian: add overrides
* Please, do not use ${runit:Conflicts}. As suggested by Lintian, it is
very strong relations. Use ${runit:Breaks} only. The very
introduction of ${runit:Conflicts} was my mistake. It will make
Lintian override unneeded.
* Please, consider merging bin:socklog-run into bin:socklog. Option
`since' for dh_runit will be useful for it.
* I know, it is pain, but there should be init.d script. You may want to
take a look at bcron=0.11-8.
* Please, add description to 0002-import-patch-tryto. It is unclear,
what issue this patch resolves.
* In patch 0003-remove-chkshgrp you remove test, that fails on CI. Does
it also fails in sbuild? If not, probably it should only be disabled in
Gitlab CI?
* It is matter of taste, but are you aware, that you can
Build-Depends: debhelper-compat (= 12)
and remove `debian/compat'?
* Dep-5 would be nice.
* What is the purpose of 'log' user, you create with dh_sysuser? You
know, that bin:runit provides user `runit-log' since -20, don't you?
* All services run as same user, 'nobody'. It is unfortunate, since nobody is
quite popular owner for NFS files.
I believe there should be separate sysuser for socklog-* services.
Ideally, separate sysuser for /every/ from socklog-* service, but I do
not know, whehter it is possible.
* I believe, README file is useless -- it contains copyright, authorship
and homepage information only, which is already present in Debian
package files.
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#926330: RFS: cuba/4.2-1 [ITP]
Dear Francesco, Le mercredi 03 avril 2019 à 17:22 +0200, Francesco Montanari a écrit : > Package: sponsorship-requests > Severity: wishlist > I am looking for a sponsor for my package "cuba" > > * Package name: cuba > Version : 4.2-1 > > Upstream Author : Thomas Hahn > * URL : http://www.feynarts.de/cuba/ > * License : LGPL-3+ > Section : math Since you CC’d this bug report to the debian-science mailing list, I guess that you’d like to have this package maintained within the team (BTW, you should have rather used the X-Debbugs-CC pseudo-header, so that we get informed of the bug number). If this is indeed your intention, you should: 1. Set the Maintainer field to: Debian Science Team (and put yourself in the Uploaders field) 2. Put the packaging on salsa.debian.org in the science-team group https://salsa.debian.org/science-team (you’ll need someone to create the project for you, once you have joined the group; I can do that if you want) 3. Subscribe to debian-scie...@lists.debian.org And more generally, you should follow the rules described in the Debian Science Policy: https://science-team.pages.debian.net/policy/ In particular, in the future, sponsorship requests should be done by simply sending an adequately formatted message to debian-science@l.d.o. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
