Interface of `shutdown', 'halt', ... programs
Hello! Recently I asked for inclusion of 'runit-init' into init metapackage Pre-Depends: (#838480). Response, in particular mentioned, that since 'runit-init' does not provide 'halt', 'reboot' and other scripts, it would break things. Unfortunately, I did not received reply about following questions: - what exactly would break and what should I test? It is not clear for me, since I am fine without these scripts, running runit-init_2.1.2-8. - what exactly interface is expected from these scripts? For example, shutdown program is rather complex, involving timespecs, access control and tons of command line options, and, if I need to reimplement it (sigh), I would prefer to do as little, as possible. It was quite misleadingly mentioned on #838480 about sysvinit-like system. Runit is not, and while it support /etc/init.d/ scripts as good, as sysvinit, they are still fallback method of managing services. Any suggestions? -- X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch, Accept-Languages: eo,ru,en | at most once every 24 hours. If matter Accept: text/plain, text/x-diff| is urgent, you have my phone number.
Re: package builds crashing under fakeroot
* Svante Signell , 2016-10-04, 08:54: From memory I think this is due to usage of the default rule: %: dh $@ with no override_dh_auto_build and override_dh_auto_test rules. By default the tests are run under fakeroot, No, they're not. -- Jakub Wilk
Re: package builds crashing under fakeroot
* Alastair McKinstry , 2016-10-03, 15:50: What do DDs think should be done about this - move all tests outside binary-arch? Yes. Everything that doesn't require root privileges should be done in build*, not in binary*. In the long run, I'd love if Debian supported building packages without fakeroot at all. -- Jakub Wilk
Re: package builds crashing under fakeroot
On Tue, 2016-10-04 at 10:55 +0200, Jakub Wilk wrote: > * Svante Signell , 2016-10-04, 08:54: > > > > From memory I think this is due to usage of the default rule: > > %: > > dh $@ > > > > with no override_dh_auto_build and override_dh_auto_test rules. By default > > the > > tests are run under fakeroot, > No, they're not. Maybe the are not run by default. However, as I wrote I've encountered packages where the tests are run under fakeroot (and openmpi seems to be another one). Maybe you know exactly why it happens for these packages, I don't remember right now? It is definitely related to the dh_* tools.
Re: package builds crashing under fakeroot
Jakub Wilk, on Tue 04 Oct 2016 10:55:36 +0200, wrote: > * Svante Signell , 2016-10-04, 08:54: > >From memory I think this is due to usage of the default rule: > >%: > >dh $@ > > > >with no override_dh_auto_build and override_dh_auto_test rules. By default > >the tests are run under fakeroot, > > No, they're not. Err, I've seen them do. This actually triggered fixing some fakeroot bugs on hurd-i386 due to various package suddenly failing to build after some debhelper upgrade (I don't remember which versione exactly), just because the testsuite was failing to run inside fakeroot. Samuel
Re: Interface of `shutdown', 'halt', ... programs
Dmitry Bogatov writes ("Interface of `shutdown', 'halt', ... programs"):
> Recently I asked for inclusion of 'runit-init' into init metapackage
> Pre-Depends: (#838480). Response, in particular mentioned, that
> since 'runit-init' does not provide 'halt', 'reboot' and other
> scripts, it would break things.
>
> Unfortunately, I did not received reply about following questions:
>
> - what exactly would break and what should I test? It is not clear for me,
>since I am fine without these scripts, running runit-init_2.1.2-8.
>
> - what exactly interface is expected from these scripts? For example,
>shutdown program is rather complex, involving timespecs, access control
>and tons of command line options, and, if I need to reimplement it (sigh),
>I would prefer to do as little, as possible.
Quite.
> It was quite misleadingly mentioned on #838480 about sysvinit-like
> system. Runit is not, and while it support /etc/init.d/ scripts as
> good, as sysvinit, they are still fallback method of managing
> services.
>
> Any suggestions?
Is it possible to use a pointyclicky desktoppy widgety thing to reboot
a system with runit ? I guess from your mails you use the command
line.
I think the reference to "sysvinit-like" from Michael Biebl is mainly
there because GNOME expects either that or systemd. In practice you
might find that the right answer is to implement enough of `shutdown'
to satisfy GNOME.
I doubt there are many non-human callers of shutdown that use all the
exciting options, and those that do exist will probably not change
very much.
I think if I were you I would try installing a system with runit and
GNOME, make enough of an emulation that the GNOME shutdown and reboot
functions work, and call that "done".
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: package builds crashing under fakeroot
Samuel Thibault writes ("Re: package builds crashing under fakeroot"):
> Jakub Wilk, on Tue 04 Oct 2016 10:55:36 +0200, wrote:
> > >with no override_dh_auto_build and override_dh_auto_test rules. By default
> > >the tests are run under fakeroot,
> >
> > No, they're not.
>
> Err, I've seen them do. This actually triggered fixing some fakeroot
> bugs on hurd-i386 due to various package suddenly failing to build after
> some debhelper upgrade (I don't remember which versione exactly), just
> because the testsuite was failing to run inside fakeroot.
Clearly the different people in this thread have seen different
results. This is most likely because different people aren't looking
at the same packages or considering the same kinds of tests.
I don't think anyone is disputing that running tests during the binary
targets is a bad idea.
We have reports that there are (or have been) packages where this
happenened and no-seems to be suggesting that a general bug of this
kind has been fixed anywhere. So there are probably more cases
besides openmpi.
Although people have accused dh (or "some dh_* command") of doing
this, there has been little concrete evidence. I think we are only
going to be able to fix this problem by actually debugging it.
Alastair, can you figure out why the openmpi tests are running during
rules binary rather than rules build ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Bug#839210: ITP: bash-unit -- bash unit testing enterprise edition framework for professionals
On Fri, Sep 30, 2016 at 08:53:05AM +0200, Pascal Grange wrote: > Package: wnpp > Severity: wishlist > Owner: Pascal Grange > > * Package name: bash-unit > Version : 1.0.2 > Upstream Author : Pascal Grange > * URL : https://github.com/pgrange/bash-unit > * License : GPL > Programming Lang: Bash > Description : bash unit testing enterprise edition framework for > professionals > > bash-unit is a unit testing software for bash. My immediate thought was "how does this differ to shunit2", which is already packaged. You mention this later: > I am aware of one alternative Debian package providing similar > functionaltities: shunit2. bash_unit and shunit2 propose > different testing methods and workflow. It would be nice to expand on this a little, to help make the case that we need another shell unit testing framework (especially since shunit2 works for other shells too!) > It has been reported that people using bash_unit won't use shunit2 to write > their tests but I may not be objective about that ;) bash_unit officially > supports only bash where shunit2 tries to support more shells. This package > would improve bash unit testing support for Debian. > > I am the main developer of bash-unit. Objectivity is very important here IMHO. What are your motivations for packaging it in Debian? Is it a build-dependency for something else, or are you looking for a "signal boost" to raise the profile of bash-unit? -- Jonathan Dowland Please do not CC me, I am subscribed to the list. signature.asc Description: Digital signature
Re: Bug#839210: ITP: bash-unit -- bash unit testing enterprise edition framework for professionals
* Pascal Grange , 2016-09-30, 08:53: * URL : https://github.com/pgrange/bash-unit 404 -- Jakub Wilk
Re: Bug#839210: ITP: bash-unit -- bash unit testing enterprise edition framework for professionals
On Tue, Oct 4, 2016 at 12:22 PM, Jakub Wilk wrote: > * Pascal Grange , 2016-09-30, 08:53: >> >> * URL : https://github.com/pgrange/bash-unit > > > 404 https://github.com/pgrange/bash_unit
Re: [Artwork] Survey for the default artwork for Stretch
Hi, On Mon Oct 03, 2016 at 22:02:00 +, Niels Thykier wrote: > Hi, > > Slightly overdue, we have created a survey for the Stretch artwork. > > Please cast your vote at: > * > https://surveys.larjona.net/index.php?r=survey/index&sid=926823&lang=en_us > * Please be nice and vote only once! Did anyone actually tested the artworks against color vision deficiencies? With a quick look (using Chrome Spectrum plugin) at least two of the proposals look highly problematic to me. Cheers, Martin -- Martin Zobel-Helas Debian System Administrator Debian & GNU/Linux Developer Debian Listmaster http://about.me/zobel Debian Webmaster GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B
Re: package builds crashing under fakeroot
Control: tags 837915 help Hi! On 25/09/2016 13:21, Michael Banck wrote: as I just diagnosed this for a different package: the problem appears to be that mpirun is run during binary-arch, i.e. under fakeroot. Latest openmpi does not like that apparenlty and crashes. Not sure how to fix it for aster as apparently building the elements catalog is part of the upstream install run. Maybe the upstream build system can be modified to build that catalog during build, not install? I'm not really familiar with aster's build system. I happened to upload the last NMU in order to fix a build with PETSc. Any help would be appreciated. Regards Graham
Re: Creating a deb for a Java based project, and saying hi to the mailing list
On 2016-10-04 08:23 +0400, David Myers wrote: > Hello all. Welcome, more people helping out is good. > I have just taken on a task of creating a deb package for an open source Java > based project (runs in Tomcat or other embeded container). I can't answer most of your questions, but people at debian-java should be able to. Just to say that debian-mentors is a better list for 'help with packaging, especially people new to it' questions, than debian-devel which is for general development not including newbie packager questions. (I have done some java packaging, but know remarkably little about java). I've used java-helper and the debian policy and wiki info: https://www.debian.org/doc/packaging-manuals/java-policy/ https://wiki.debian.org/DebianJavaPackaging Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: [Artwork] Survey for the default artwork for Stretch
On Mon, Oct 03, 2016 at 10:02:00PM +, Niels Thykier wrote: >Hi, > >Slightly overdue, we have created a survey for the Stretch artwork. > >Please cast your vote at: > * >https://surveys.larjona.net/index.php?r=survey/index&sid=926823&lang=en_us > * Please be nice and vote only once! Awesome stuff Laura. :-) I've just voted (once)! -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
Bug#839748: ITP: golang-gopkg-flosch-pongo2.v3 -- Django-syntax like template-engine for Go
Package: wnpp Severity: wishlist Owner: Jonathan Dowland * Package name: golang-gopkg-flosch-pongo2.v3 Version : 3.0 Upstream Author : Florian Schlachter * URL : https://github.com/flosch/pongo2 * License : Expat Programming Lang: Go Description : Django-syntax like template-engine for Go This offers a template renderer compatible with the Django syntax but for the Go language. . pongo2 is the successor of pongo. This is a dependency for LXD and is being packaged via the pkg-go team.
Re: [Artwork] Survey for the default artwork for Stretch
Martin Zobel-Helas: > Hi, > > On Mon Oct 03, 2016 at 22:02:00 +, Niels Thykier wrote: >> Hi, >> >> Slightly overdue, we have created a survey for the Stretch artwork. >> >> Please cast your vote at: >> * >> https://surveys.larjona.net/index.php?r=survey/index&sid=926823&lang=en_us >> * Please be nice and vote only once! > > Did anyone actually tested the artworks against color vision > deficiencies? With a quick look (using Chrome Spectrum plugin) at least > two of the proposals look highly problematic to me. > > Cheers, > Martin > I have not checked any other them; nor do I have any experience with it (so I wouldn't know what to look for, how to test or determine which are good and which are not). But I would be very happy if someone with the skills/know-how could review them and present the results, so it can be taken into account. Thanks, ~Niels
Re: package builds crashing under fakeroot
* Graham Inggs , 2016-10-04, 12:33: Not sure how to fix it for aster as apparently building the elements catalog is part of the upstream install run. Maybe the upstream build system can be modified to build that catalog during build, not install? I'm not really familiar with aster's build system. I happened to upload the last NMU in order to fix a build with PETSc. Let me see: $ ./waf --help | grep buildelem buildelem : execute the build for elements catalog only using an installed Aster (also performed at install) So it should be a matter of adding "waf buildelem" to override_dh_auto_build... Nope, that would be too easy: $ ./waf buildelem Waf: Entering directory `/home/jwilk/aster-11.5.0+dfsg2/build' No function build_elements defined in /home/jwilk/aster-11.5.0+dfsg2/catalo/wscript I've filed a bug upstream: https://bitbucket.org/code_aster/codeaster-src/issues/84 -- Jakub Wilk
Plasma 5.8 LTS in debian 9(Stretch)
Hello, Quick question. Will the new plasma LTS release make it into the next stable? I think it would be a mistake if it did not. Sincerely, Brad
Re: Plasma 5.8 LTS in debian 9(Stretch)
Looping in the related people. AFAIR from discussions on IRC, yes. On 10/04/2016 03:16 PM, Bradley Robert Baago wrote: > Hello, > > Quick question. Will the new plasma LTS release make it into the next stable? > I think it would be a mistake if it did not. > > Sincerely, > > Brad > -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4
Re: Bug#835533: dasher: Please package Dasher 5.0 beta
(Cc-ing ftpmaster, debian-devel) On Tue, Oct 04, 2016 at 07:05:09PM +0200, Emilio Pozuelo Monfort wrote: > (Cc-ing debian-a11y) > > Hi, Hi Emilio, > On 30/09/16 13:03, Andreas Henriksson wrote: > > While the patch would solve the RC bug and get dasher back into > > testing, I'm hesitant to assist in uploading it because the > > question "Do we *want* to ship dasher in it current state?" is > > not something your patch addresses. If we do get dasher back > > into testing we'll likely have to also support it for the > > lifetime of stretch. If we're struggling now to find people > > willing to invest any time into dasher maintenance how will > > we be able to make any guarantees about being able to support > > it for the lifetime of stretch? > > > > Until we have a somewhat enthusiastic maintainer it's probably > > better to make dasher available "on the side" rather than in > > the main distribution IMHO. Could you tell me your view on > > this and what your motivation for posting the patch was to better > > help me understand your situation? > > dasher is a critical piece of software for some people who couldn't use their > computer without it. Other than this FTBFS, I don't think it's in a bad state > (unless I missed something). So I'd say we should fix this bug and ship it, or > let the accessibility team (co-)maintain this (as they do with Orca) and give > us > a hand with it, if they want to do that. you are too late. Andreas did not apply my trivial patch to fix the RC bug.[1] Even though Andreas was worried about noone being available to maintain dasher,[2] he did not follow my suggestion to send a WNPP bug.[3] Andreas succeeded in getting dasher removed from Debian,[4] conveniently not mentioning that he could have fixed the "has not been part of testing" by applying my trivial fix. Andreas claiming "there's noone willing to commit to actually taking care of the package" in the removal request is also quite at odds with him being completely silent on my suggestion to file a WNPP bug. The ftp admins were fast enough to not give anyone a realistic chance to react to the removal request. It is a problem for users when software that is in one stable release disappears in the next stable release, and I guess dasher can forever serve as a good example of critical software having been removed from unstable without a single good reason. I am also personally unhappy that creating a patch for the RC bug triggered removal from unstable instead of getting the fix applied. > Cheers, > Emilio cu Adrian [1] https://bugs.debian.org/811640#24 [2] https://bugs.debian.org/835533#15 [3] https://bugs.debian.org/835533#25 [4] https://bugs.debian.org/839735 -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#839782: ITP: sagenb-export -- Convert SageNB Notebooks
Package: wnpp Severity: wishlist Owner: Jerome Benoit * Package name: sagenb-export Version : 2.0 Upstream Author : Volker Braun * URL : https://github.com/vbraun/ExportSageNB * License : GPL Programming Lang: Python Description : Convert SageNB Notebooks This is a tool to convert SageNB notebooks to other formats, in particular IPython/Jupyter notebooks.
Re: Plasma 5.8 LTS in debian 9(Stretch)
On 4 October 2016 at 16:40, Simon Quigley wrote: > On 10/04/2016 03:16 PM, Bradley Robert Baago wrote: >> Hello, >> >> Quick question. Will the new plasma LTS release make it into the next stable? >> I think it would be a mistake if it did not. >> > Looping in the related people. > > AFAIR from discussions on IRC, yes. > Yay! :-D I've also been wondering this. Are there any relevant trackers/pages in addition to the following: http://pkg-kde.alioth.debian.org/ (unmaintained?) https://qa.debian.org/developer.php?login=debian-qt-...@lists.debian.org https://qa.debian.org/developer.php?login=pkg-kde-ext...@lists.alioth.debian.org Cheers, Nicholas
RE : Bug#839210: ITP: bash-unit -- bash unit testing enterprise edition framework for professionals
Ouch! That's a stupid mistake ;( Thank you for your feedback. The correct URL is with an underscore instead of a dash : https://github.com/pgrange/bash_unit Message d'origine De : Jakub Wilk Date : 04/10/2016 12:22 (GMT+01:00) À : 839...@bugs.debian.org Cc : debian-devel@lists.debian.org Objet : Bug#839210: ITP: bash-unit -- bash unit testing enterprise edition framework for professionals * Pascal Grange , 2016-09-30, 08:53: >* URL : https://github.com/pgrange/bash-unit 404 -- Jakub Wilk
