Re: Confusing our users - who is supporting LTS?
On Sat, 2018-10-27 at 20:51 +, Luca Filipozzi wrote: > On Sat, Oct 27, 2018 at 09:41:43AM +0200, Wouter Verhelst wrote: > > On Fri, Oct 26, 2018 at 01:02:57PM -0300, Thadeu Lima de Souza Cascardo > > wrote: > > > I meant that we would say that stable is supported by the security > > > team. And instead of saying that Jessie was supported by the LTS > > > team, we would say supported by Freexian. > > > > I would object to that, on the grounds that even though Freexian is > > currently the only company paying people to do LTS support, we should > > not encourage the idea that they have a monopoly on doing that. > > I agree that more than one consultancy should/could provide resources > for LTS. > > I find it inappropriate that that we (Debian) publicize solicitation of > donations to Freexian on debian.org websites [1] and, further, that we > the advertise their 'Extended LTS' commercial offering [2]. > > [1]: https://wiki.debian.org/LTS/Funding > [2]: https://wiki.debian.org/LTS/Extended Debian has long maintained references to consultants (like the paid LTS work) and commercial derivatives (like the ELTS) and I don't think that's inherently problematic. But the wording here could certainly be improved to make it clearer that Debian has no special relationship with Freexian. > > For the avoidance of doubt, I am not saying that Freexian is doing a > > bad job, or that they should be replaced, or anything of the sorts. > > Nor am I, but I do not find the lack of distinction between Debian and > Freexian to be appropriate. > > One way is for the funding for Debian LTS to flow through Debian's > Trusted Organizations, complete with the restrictions that might come > with that. Debian can't afford to pay developers in general, and previous proposals to pay specific developers were not well received. So, I don't this happening. Ben. > Another way is for Debian websites to not solicit for donations or to > advertise for their commercial offering (my preference). -- Ben Hutchings If you seem to know what you are doing, you'll be given more to do. signature.asc Description: This is a digitally signed message part
Re: salsa.debian.org: merge requests and such
Hi, > The consensus seems to be that people should enable email notifications in > salsa and open a bug when filing a merge request. That's indeed the best way to make the bridge between the BTS and the merge requests on Salsa. Note that you can enable the notification programmatically globally, at the team level or at the repo level using the API [1]. If you do end up writing a script for that, you could probably add it with the other nice salsa-related tools in the salsa-scripts repo [2]. Lately I've been wondering if it wouldn't be nice to see the open MR/issues on the DMD [3] or on tracker.d.o (haven't looked further but it might also be interesting to see it there). [1] https://docs.gitlab.com/ee/api/notification_settings.html [2] https://salsa.debian.org/mehdi/salsa-scripts [3] https://udd.debian.org/dmd/ Joseph
Re: Confusing our users - who is supporting LTS?
On Sat, Oct 27, 2018 at 09:41:43AM +0200, Wouter Verhelst wrote: > On Fri, Oct 26, 2018 at 01:02:57PM -0300, Thadeu Lima de Souza Cascardo wrote: > > I meant that we would say that stable is supported by the security > > team. And instead of saying that Jessie was supported by the LTS > > team, we would say supported by Freexian. > > I would object to that, on the grounds that even though Freexian is > currently the only company paying people to do LTS support, we should > not encourage the idea that they have a monopoly on doing that. I agree that more than one consultancy should/could provide resources for LTS. I find it inappropriate that that we (Debian) publicize solicitation of donations to Freexian on debian.org websites [1] and, further, that we the advertise their 'Extended LTS' commercial offering [2]. [1]: https://wiki.debian.org/LTS/Funding [2]: https://wiki.debian.org/LTS/Extended > For the avoidance of doubt, I am not saying that Freexian is doing a > bad job, or that they should be replaced, or anything of the sorts. Nor am I, but I do not find the lack of distinction between Debian and Freexian to be appropriate. One way is for the funding for Debian LTS to flow through Debian's Trusted Organizations, complete with the restrictions that might come with that. Another way is for Debian websites to not solicit for donations or to advertise for their commercial offering (my preference). Luca -- Luca Filipozzi
Re: salsa.debian.org: merge requests and such
> On Oct 27, 2018, at 09:20, Holger Wansing wrote: > > Hi all, > > how is the new Salsa collaborative concept supposed to work with the "old" > workflow in Debian? > > Means: it seems to me, that with Salsa there is a second parallel world is > getting evolved (in parallel to the old world: BTS, mailinglists ...), > containing things like patches in form of merge requests, which do not > interact > well with the old world (BTS, mailinglists). > It looks to me, that many merge requests are lying around on Salsa, but the > responsible package maintainers / teams are not aware of them. I started a thread about this a while back: https://lists.debian.org/debian-devel/2018/08/msg00231.html The consensus seems to be that people should enable email notifications in salsa and open a bug when filing a merge request. https://lists.debian.org/debian-devel/2018/08/msg00235.html https://lists.debian.org/debian-devel/2018/08/msg00259.html Jacob
Re: Installer: 32 vs. 64 bit
Why are they creating 32-bit virtual machines? At least with virtualbox 32-bit VMs can run on any host. 64-bit VMs require VT-x which is all too often disabled in the BIOS.
Bug#912041: grub-cloud-amd64: don't work around being tested by piuparts
Package: grub-cloud-amd64
Version: 0.0.2
Severity: important
Dear Maintainer,
in your postinst you are trying to detect whether it's being run in a
piuparts test, to workaround #912038 ("grub-cloud-amd64: fails to
install"), which is detected by piuparts but can also be triggered by
anyone installing it manually, with this code:
if [ ${PIUPARTS_TEST:-} ]; then
echo "Running Piuparts detected, exiting." >&2
exit 0
fi
This is bad, don't do that. piuparts tests stuff for a reason and as
#912038 shows, your package is still buggy.
In discussion on #-release before uploading grub-cloud 0.0.2 you claimed
that grub-cloud is only useful to install in cloud environments (which
are chroots) and thus detecting a chroot would not work. Still all packages
(aimed for a stable Debian release) must be installable in chroots, also
yours.
So instead of detecting whether the package is being tested by piuparts
you should detect whether grub-cloud-amd64 is being installed in a
cloud-chroot and only then do whatever it takes to active grub. For that
you can create some file while preparing the cloud chroot (say
/etc/.cloud_env) and only if that file is present you do those things
you now dont do if the variable $PIUPARTS_TEST is defined.
I've also filed a bug against lintian to detect maintainer scripts using this
variable as no maintainer script needs to do this. This is similar to
the lintian test detecting autokpkgtests just running "exit 0" or
"true". The bug against lintian is #912040.
--
cheers,
Holger
---
holger@(debian|reproducible-builds|layer-acht).org
PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
signature.asc
Description: PGP signature
salsa.debian.org: merge requests and such
Hi all, how is the new Salsa collaborative concept supposed to work with the "old" workflow in Debian? Means: it seems to me, that with Salsa there is a second parallel world is getting evolved (in parallel to the old world: BTS, mailinglists ...), containing things like patches in form of merge requests, which do not interact well with the old world (BTS, mailinglists). It looks to me, that many merge requests are lying around on Salsa, but the responsible package maintainers / teams are not aware of them. As far as I see it for installer team for example, the debian-boot mailinglist does not get a mail forwarded, when a installer repo gets a merge request. Isn't that the way, how it should work? Comparing Salsa with the BTS, it should work that way IMO. When writing comments on those merge requests, who gets those messages? I had the impression that the responsible people are not getting involved. Or similar seems to be the case for debian-doc, too... Maybe I'm completely wrong here, or it's just these few packages/teams, where this is not optimal? How is this all set up, how is it supposed to work? Holger -- Holger Wansing PGP-Finterprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Re: Confusing our users - who is supporting LTS?
On Fri, Oct 26, 2018 at 01:02:57PM -0300, Thadeu Lima de Souza Cascardo wrote: > I meant that we would say that stable is supported by the security team. > And instead of saying that Jessie was supported by the LTS team, we > would say supported by Freexian. I would object to that, on the grounds that even though Freexian is currently the only company paying people to do LTS support, we should not encourage the idea that they have a monopoly on doing that. If some other company decides that they are not happy with Freexian, then they are currently able to just start their own competing project and do things differently. This is a good thing. For the avoidance of doubt, I am not saying that Freexian is doing a bad job, or that they should be replaced, or anything of the sorts. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
