Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
On 4/13/2019 12:49 PM, Aurelien Jarno wrote: > The process to inject all packages to debian-ports is to get all the > deb, udeb and buildinfo files from the archives (main and debug) and > associate them with the .changes files that are hosted on coccia. We'll > also need to fetch all the associated GPG keys used to sign the changes > files. Then we can inject that in the debian-ports archive. I'm curious how the GPG bit works given that there is no guarantee that the signature can be validated at any other point in time than ingestion on ftp-master - especially considering the rotation/expiry of subkeys and buildd keys. In this case the files already come from a trusted source and should be ingested as-is, I guess? (Not that I particularly like the fact that it's only a point in time validation.) Kind regards Philipp Kern
Re: Debian Buster release to partially drop non-systemd support
On 2018-10-19 08:39, Narcis Garcia wrote: El 18/10/18 a les 22:07, Bernd Zeimetz ha escrit: For my packages I can state that I do not have a single machine which is not using systemd - and to be honest - I won't waste my time in writing/debugging initscripts. Most of people want to use a GNU operating system. You particularly seem to only need a Systemd operating system. So what you want is https://www.gnu.org/software/shepherd/? Kind regards Philipp Kern
Re: Debian Buster release to partially drop non-systemd support
suppose one answer would be a cron generator. Given that policy
specifies naming schemes for /etc/cron.{hourly,daily,weekly,monthly,d},
there could probably be a mapping from filename to timer. But the cron
language itself does not contain identifiers, so there's still the
question what to do if you encounter multiple lines and how you'd map
them. Init scripts with their 1:1 mapping and metadata headers were much
easier to handle. Plus we'd need a way to tell cron not to execute those
cronjobs in case systemd is running, which I guess means adding systemd
guards to /etc/crontab (a conffile). And you'd of course still have cron
wake up to execute the shell statement.
But it's not like timer units are forbidden. Just like my
introductionary statement of "but if you use a different system not
considered an init system, you are fine", there's nothing in policy
mandating periodic jobs to work in a particular way. It just talks about
what to do if you do ship a cronjob.
Kind regards
Philipp Kern
Re: Debian Buster release to partially drop non-systemd support
On 2018-10-16 14:36, Ian Jackson wrote:
Philipp Kern writes ("Re: Debian Buster release to partially drop
non-systemd support"):
Could someone reiterate about what the current state of init diversity
is supposed to be? Is it assumed to be best effort of every maintainer
being required to ship an init script next to the systemd unit that is
actually used by default[1]?
I think describint that as `effort' is rather much.
I don't understand. If I submit a merge request to the maintainer, it's
on me to test what I submit actually works. So if I add stuff for a
completely different init system I have to test it. The question is: Is
the package buggy if it does not contain an init script but a systemd
unit and it seems to be the case. Note that there are a *lot* of useful
options in a systemd unit that would need emulation to make properly
work with sysvinit.
Can we rely on sysvinit users to report the
bugs with the scripts or how intensively do they need to be tested?
You should rely on users to report bugs.
Okay. In this case I contributed to the package of someone else and
don't want to make it buggy.
Similarly, are maintainers allowed to ship timer units in lieu of
cronjobs? As an example I invested some time in
prometheus-node-exporter[2] to run textfile collectors of monitoring
data (SMART, apt) in the background. Would I have been required by
policy to make sure that all of this also works on a system with
sysvinit?
Obviously it would be better to make ti work with cron. Ideally it
would go into cron.daily which I assume works with systemd too.
It'd need to run much more often (every 15 minutes). So cron.daily
wouldn't fit. For the sake of the argument it'd need to be a shell
script that checks multiple conditions (see [1]). And we currently don't
have timer/cron deduplication, unfortunately. That means it'd also need
to disable itself on systemd systems (but of course cron would still
invoke the script periodically). Similarly - as a more general remark -
having it as a cronjob doesn't let you monitor it in quite the same way.
But if you do just the systemd thing, I think if someone sends you a
patch to make it work with cron I think you should accept and carry
that patch.
In this case that might be feasible because if it breaks that user is
hopefully going to monitor it anyway, because it's a monitoring thing.
But there is a cost to carrying such things (such as cron confusingly
invoking something whose output isn't used at all because it's going to
be short circuited at startup).
Kind regards
Philipp Kern
[1]
https://salsa.debian.org/go-team/packages/prometheus-node-exporter/merge_requests/1/diffs#229e10b19f8b27233d2301c8bb553b6bdd8e5b1a
Re: Debian Buster release to partially drop non-systemd support
On 2018-10-16 13:27, Matthew Vernon wrote: So: http://www.chiark.greenend.org.uk/mailman/listinfo/debian-init-diversity It's a standard mailman list with a public archive. I'm hoping people interested in init system diversity in Debian can use it as a place to co-ordinate. I don't want it to be used to slag off $init_system or $distribution_or_derivative. Could someone reiterate about what the current state of init diversity is supposed to be? Is it assumed to be best effort of every maintainer being required to ship an init script next to the systemd unit that is actually used by default[1]? Can we rely on sysvinit users to report the bugs with the scripts or how intensively do they need to be tested? Similarly, are maintainers allowed to ship timer units in lieu of cronjobs? As an example I invested some time in prometheus-node-exporter[2] to run textfile collectors of monitoring data (SMART, apt) in the background. Would I have been required by policy to make sure that all of this also works on a system with sysvinit? Note that this includes the usage of file presence checks and OnBootSec, so I suppose that'd mean both anacron and cron as well as an actual shell script that checks for the preconditions. Would anacron and cron need to be depended upon in that case or would they could they even just be recommended? Both would not be needed on a default Debian system that ships with systemd. Kind regards and thanks Philipp Kern [1] "Alternative init implementations must support running SysV init scripts as described at System run levels and init.d scripts for compatibility." [https://www.debian.org/doc/debian-policy/ch-opersys.html#alternate-init-systems] [2] https://packages.qa.debian.org/p/prometheus-node-exporter/news/20181015T165248Z.html
Re: Re-evaluating architecture inclusion in unstable/experimental
On 03.10.2018 18:01, John Paul Adrian Glaubitz wrote: >> For s390x I can say that the port was driven without any commercial >> interest on both Aurelien's and my side > The question is though: Is there quantifiable amount of users that is > running Debian on such big iron instead of one of the Linux enterprise > distributions on the market? If the argument is about maintenance burden, > then does it justify to support Debian on s390x when the number of users > is small? And, if yes, why does that not apply to ppc64, for example? > (I would mention sparc64 here as well, but there is actually a valid > blocker which is the lack of supply of new hardware for DSA). I cannot speak to ppc64. ppc64el is useful as I'm told POWER can be competitive to Intel/AMD-based services. But I don't know how many users would run Debian. For s390x, IBM does not publicly admit that there are people running Debian, but there are a few. Almost all of them turn popcon off - most of the VMs can't talk to the internet. Of course I don't know if the availability of Ubuntu significantly changed that. They were able to invest much more time into polishing the port and most people just want some kind of Debian derivative. Historically the base system has been very well maintained by IBM, though. So the effort to keep it running has been relatively small. This recently changed somewhat, given that the primary focus is on enterprise distributions, in that stuff like Javascript interpreters don't work well. Essentially it boils down to server workloads that companies need to run, so as Docker and Go became popular, IBM implemented support for it. The same happened for v8 as used by Node. OpenJDK 9 finally comes with a JIT, so you don't have to use IBM Java anymore. And to IBM's credit, they even contributed some bits back to d-i. Although some of those still await testing and merging. The Ubuntu changes did not flow back / were not mergable as-is into Debian. It's always a tradeoff between how much work is necessary to keep the port alive and how many people use it. As long as the port keeps itself working, that's sort of fine in my experience. Once you need to sheperd a lot of things that all break (like the MIPSens historically had to, even working around broken CPUs) or need to deal with 2 GB virtual address space or don't have modern languages like Go or Rust around, it quickly approaches the point where it's not worth it anymore. Kind regards Philipp Kern
Re: isc-dhcpd vs udhcpd
On 23.10.2017 09:36, Ondřej Surý wrote: > while revising bind9 udebs, KiBi suggested that non-Linux architectures > might be using isc-dhcpd instead of udhcpd due some problems and it > might be a good idea to revise the decision now that we have a busybox > maintainer? Ubuntu has used dhclient for a long time now in d-i. I think there are at least two parts to it: a) consistency across architectures - it is weird to support two completely different implementations and b) actually use the same implementation than the installed system would rather than something embedded that has less features. I recall times at work where we had severe issues with dhclient not staying around in the background refreshing the lease. I have no idea if this is still the case, I just recall that -1 behavior was kind of a mess. Back then we bumped the lease duration. If picking udhcpc means that we can address such issues more easily, that's better. At the same time people know how to configure dhclient and can use a similar config as in the installed system. My understanding is that udhcpc has essentially no options at all (like sending additional DHCP options). netcfg also did not receive that much love in recent times and I wonder if something more integrated wouldn't be better than the hacks layered on top of each other to make it work we have today. But at the same time I know that something modern like systemd-networkd won't work for d-i either because of architecture consistency. :/ Kind regards Philipp Kern
Re: [Stretch] Status for architecture qualification
On 2016-06-15 00:37, Dimitri John Ledkov wrote: There is openmainframe project https://www.openmainframeproject.org/ , which I believe offers access to z/VM instances hosted by Marist colledge. At the openmainframeproject EU meetup, it was indicated that SUSE joined with indication that Open Build Service might be able to use resources hosted by Marist. I wonder if it makes sense to reach out, and see if there are resources available to use as porter boxes & build boxes. That way Debian might be able to get such donated resource available on ongoing basis and hopefully with some hw support. Debian already makes use of Marist's resources. The challenge was/is to get redundancy as DSA very sensibly insists on. Kind regards Philipp Kern
Re: [Stretch] Status for architecture qualification
On Mon, Jun 13, 2016 at 07:33:56PM +, Niels Thykier wrote: > Philipp Kern: > > On 2016-06-05 12:01, Niels Thykier wrote: > >> * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el, > >>s390x > >>- *No* blockers at this time from RT, DSA nor security. > >>- s390, ppc64el and all arm ports have DSA concerns. > > What is the current DSA concern about s390x? > The concern listed as: "rely on sponsors for hardware (mild concern)" > > As I recall the argument went something along the lines of: > > "Debian cannot replace the hardware; if any of the machines dies, we > need a sponsor to replace it. If all of them dies and we cannot get > sponsored replacements, we cannot support the architecture any longer" > > (My wording) Yeah, but that's unfortunately one of the universal truths of this port. I mean in theory sometimes they turn up on eBay and people try to make them work[1]. It also seems true for other ports where we commonly relied on sponsors to hand us replacements. But maybe it's only ppc64el these days, maybe there are useful builds available for the others (including arm64 and mips) on the market now. Kind regards and thanks Philipp Kern [1] https://www.youtube.com/watch?v=45X4VP8CGtk (Here's What Happens When an 18 Year Old Buys a Mainframe)
Re: [Stretch] Status for architecture qualification
On 2016-06-05 12:01, Niels Thykier wrote: * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el, s390x - *No* blockers at this time from RT, DSA nor security. - s390, ppc64el and all arm ports have DSA concerns. What is the current DSA concern about s390x? Kind regards and thanks Philipp Kern
Re: binNMUs: please exercise some care
On Fri, Oct 23, 2015 at 02:46:23PM +0200, Thorsten Glaser wrote: > On Fri, 23 Oct 2015, Adam D. Barratt wrote: > > and testing), so the only way to be certain what binNMU number to use is to > > check manually. In practice what actually happens is that people forget > > about > Maybe wb could do a “dak ls” and whatever the equivalent for dpo mini-dak is. Unfortunately it is not being run on the same host as dak either. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Bug#768188: Jessie Installer hangs after processing DHCPv6 stateful addressing
On Wed, Feb 18, 2015 at 10:05:27PM +, Steven Chamberlain wrote: We did expect that during freeze, some regressions may be introduced that affect only GNU/kFreeBSD, and we'd have to fix things up in our unofficial release, perhaps rolling packages back to an older version, or uploading a patched version with +kfreebsd suffix. So, I'm happy if you decide to revert this. At first glance, it reads like a limitation of udhcpc/dhcp6c only? Killing it sounds like a workaround (which perhaps creates other issues), and an ifdef linux also seems wrong in this context (and for Ubuntu). kill-all-dhcp could be told never to kill ISC dhclient, but that too is wrong, as this is also used to implement the 'Cancel' button in the netcfg dialogs. Maybe there is still a better solution? Or perhaps we could add something that kills *only* udhcpc/dhcp6c, could clearly annotate it as this is a workaround for bug #768188. Then it shouldn't affect Ubuntu, or derivatives/ports using ISC DHCP at all. And if many years pass before someone comes back to look at this, they should understand why it's there. Not killing the DHCP clients is the right thing to do. Leases really should be refreshed during d-i, everything else is madness. But that's not even what's happening with dhclient because it's being run in one-shot mode (-1) and will exit after it acquired a lease successfully. The revert I supposed would've been for jessie as the DHCPv6 hang is quite a nasty regression on Linux. But for the future we should really a) use one client on all the platforms and b) let it renew the lease properly. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Bug#757711: netcfg: promptly kills dhclient, deconfigures interface
On Fri, Sep 05, 2014 at 09:55:24AM +0200, Cyril Brulebois wrote: Steven Chamberlain ste...@pyro.eu.org (2014-08-31): On 31/08/14 07:00, Philipp Kern wrote: Is perhaps the same true for stop_rdnssd() on the next line? So Steven committed a patch in to git, getting rid of the dhcp part; Philipp, should I upload that and we'll figure out the rdnssd part another time? ACK. I wanted to look at it today, but meh. rdnssd isn't as critical as it won't take your interface down if you kill it. You just won't get updated DNS information. Kind regards and thanks Philipp Kern signature.asc Description: Digital signature
Re: Bug#757711: netcfg: promptly kills dhclient, deconfigures interface
On Fri, Aug 29, 2014 at 11:25:28PM +0200, Cyril Brulebois wrote: I'd be slightly happier if Philipp would comment on this since he seems to be the one having committed this change. See: | commit 8802ca520d9e91542d92bbfa5b2fc412a31cf2e2 | Author: Matt Palmer mpal...@hezmatt.org | Date: Sun Jan 30 22:29:42 2011 +1100 | | IPv6 support for using rDNS to preseed hostnames | | A lot of refactoring to make the code cleaner and simpler, but the | IPv6-specific changes were actually relatively small. | | Rebased-and-modified-by: Philipp Kern pk...@debian.org http://anonscm.debian.org/cgit/d-i/netcfg.git/commit/?id=8802ca520d9e91542d92bbfa5b2fc412a31cf2e2 I did some archeology and I'll spare you the details. That kill_dhcp_client is totally wrong where it is now, so LGTM. Thanks. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Architecture qualification
On Wed, May 30, 2012 at 12:01:21PM +0200, Samuel Thibault wrote: What is a problem is not appearing on buildd.debian.org. That makes maintainers way less receptive to patches or even fix their package themselves. I wonder how that makes a difference, even psychologically. We don't mail failed builds for hurd-i386 to maintainers for example. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: hurd-i386 qualification for Wheezy
On Sat, May 19, 2012 at 08:20:13PM +0200, Andreas Barth wrote: For security updates (i.e. after release), we need two DSAed buildds. Having DSAed buildds allows also to do autosigning, which shortens the time span for getting builds into the archive. This isn't strictly required, but not doing so will sometimes lead to annoying delays for testing transitions (when the architecture is in testing, and the mark this arch is too slow removed). The security team basically already requires autosigning for security suites. But given that we only build security on DSAed buildds, the two can go hand in hand. Just a very minor clarification. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: [dd-list] Please use Architecture: linux-any
[Followup-To: header set to gmane.linux.debian.devel.general.] On 2011-08-20, Robert Millan r...@debian.org wrote: 2011/8/20 Samuel Thibault sthiba...@debian.org: ntfs-3g This is FUSE-based, no reason it can't be ported to GNU/kFreeBSD AFAICT (I suggest linux-any kfreebsd-any untill Hurd has FUSE). Or just build-depend on the lib that's not available and it won't start building until it gets available? Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnj4v605.gvv.tr...@kelgar.0x539.de
Re: Moving hurd back to buildd.debian.org
On Mon, Oct 12, 2009 at 11:33:30PM +0200, Samuel Thibault wrote: Hello, mozart and bach are back online, I could generate rsa keys for them, here they are, could you install them for buildd_hurd-i...@buildd.debian.org ? ssh-rsa B3NzaC1yc2EBIwAAAQEA1zsSKHuDppXUFTa7mGamWp89+r6X9ndYSBnND4kVk5w1JggYOBdfewaeuG9d3J4VYFCBHTe/ezV0sBrYB60X5HSlzZHGGwC37GsD3N/RAGv5KyZkPcYOOs5N5tJBkxEKks6dQQPIlomTLkPaRrqoQHnYSJsTQT2FjIKrlM9QOtxUi0c8iPi+J6NJPVVBXkf91tWK8kO9vHfvgKZKu7kfK7wiuMrwZrTQtFU89QTZcdQHmgKzdO7WJyTvxtJRCsFfgOzjEuLwYwRbquvVDzzsqx0DcZlFO79rv4fvn7icIHr6bspjAMd04hoEl99xQgaDHm/h6ru9OVEPwu38UyuzZQ== bui...@mozart ssh-rsa B3NzaC1yc2EBIwAAAQEAqOtYWxjudXSnR52hjNrrMEo4Zci1mHyEeoY5AcmP75AUUSHvPQVe4EclElAYPPYeJ+0kZjH7LTcD3DFl7a+1Svf7nwkVYfx9qJj6kMgcqceJ1HHuAFxYCm2OE5CYES7Q5FHTV3DBBm7NXblrFCZNB4shPBt+GVKw3AaJZ+jdqFs0MR/ERJ8blCePjtGiupqqO3wvufME7+zpkAaKP5SCQCmQbkyEEXKXe4uw5K1EXGdP9y7mFqOuKcHhUWfs/qUFB/j/Bs73A9BO8nwcizSjH48hf3HY1U1Q8KdewkgUTjlrutez8VIGtALkGzrKZ0Agczqya1msNkhcN53VMJlasQ== bui...@bach Both are now active, together with rossini. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: Moving hurd back to buildd.debian.org
Hi Samuel, On Sun, Sep 27, 2009 at 07:11:47PM +0200, Samuel Thibault wrote: Here it is again, signed. Samuel Thibault, le Sun 27 Sep 2009 17:45:12 +0200, a écrit : 192.33.98.55 for rossini 80.87.129.151 for both bach mozart (they are Xen domains) ssh-dss B3NzaC1kc3MAAACBAOp+ROMyuV/cJp5abowxGStdasV5cvi6rAc/ft1AVHkIBxIKEqUB3dWLRX3+wCuCNPNofR6KkEAcoiGL1zUMlzb/h63ope2cNIipuarz8PKCbMOURCheaB/nuc1nVmGfRVXSqPMwMlojMqLjOcWiKyv9flfMWV/O45RiyDAU2yKVFQCst00VaxmMjYQEbDAKPfz73M4dcwAAAIEApTydVT49Ud6ZS30OEvBnZwIw3vYKziVfYDmDaeQal/f76YG3Pk1YCgbRTtJq4ykeaBVzC1zVdAZXOpFYtN/W10KChKFRcvRXZCLQloI7qDFXiMOYN3fqWHCLD/RCUujCubm2hZr4kK6QmYL9NUcspHIj8kcED1MSbJk3X0CkfS8AAACBAItRSZ970DiDhuj5qNzXZntz6TcuLmgdW/qEwqqm6BPJue6+cnEvBfkb0nwVzwE/+NjmYDh2tC/H5TRxPZwkKEs25FNBcj3chWITWRXD/ZQsklpob6dAQvRwjE87Gkq1g4dJHpUnrsVhsACqa+d8yQuO+RyZhANlMZlqmGXKMqsE bui...@mozart ssh-dss B3NzaC1kc3MAAACBAPlxjWb/+CImaviGewd5shVbMVUOC3wzzBKm2y8Ch5A/itSaJ/daS/cIx3XSQAatxJFKLO/6fZOQ8WtNJ5neoDiOHcIAQJGi7BTJ2PDHyMprUkQ4K6DfwP1kSWFqHAFDe5UQokJ8sQG4KIaUY5FjmC3/g7MTBRAE5VQpswzoZRkVFQCdSbPPxgnQuiHpu1qAm3LhumthdwAAAIEAp7ltmYLXGAHnoJsKYengizKjebEUchKfnlbc5GDsTDRA+UZ2Zv0D0pSzWh0ovb3oV6Kt2CmP5ffNraAe6N5CHZVcu+QkcIKeL+zh+DwNyIIjd+5eGcOACl8E6ZO0pAkKnOoQKkbvCdyIh3waMLtBH/tVTHy7y2MBN3twNubGvA0AAACAb1Y6B6DkJvx7COEATMEjgruU1Zcugo03z75Seg4OH+Wi0oaFhGSDgorwBAkVOd7u0L52GeLmXM0uPUSBMdcVJgLvNIqGsC1yMMI9YUTwioAmMgtOSB8Fbn18rOuYRI35WVKuXShbKlIAwYxYhCfRZxefsLyEkuMTRIeOSTZSPaw= bui...@bach ssh-dss B3NzaC1kc3MAAACBAJgfHqcK3KrzJfQgpbkKesiOaggj//YPM0WZOHfiK13Akkb1rF7mGL8LQjjqYeSnFqqudqOdXGHA7b6bBZZ0ott4yQtoSHWsu/7G8RRi42msskHpbpnwl76YeFnTON6OfrwOoGVG003i3UrxM2oLHLDVKfFJK94b7UOlqrB7+Yx9FQCLI2v7kmR+dqS60Ww9BQVryzandQAAAIAUHrvOoLgzF4Zv+WUb23Up+ax76anP6iZ75/dJ68yfD/bH0XCDe4j0hpIx6NuQyTjzZ1Jk1VLW+ojtg6ebIMaMrS3m9PwYma5J4DkC/JuGbqumFzWPHLbo+35397URwaIQOgtUgN9KhbNnCM3QKscQ7GbPzIXtuFk/1CEAo7dvMQAAAIEAkGIu8jxzJH0V/mUmio64KtoFWCZH+QwMngx6I63k8y0j0qNBb1nQdBsJMAB5ATjWnIAX1qV9bmozHIGYQa2nJgrKLIrLt4r0DqdjxRVyHPZxsbvpGRBi/qxr/cj8lmmhL7uPR6VGKUTIQuHAbiprqYkYwSltkrcaLxtjWag1hmE= bui...@rossini please give us ssh-rsa keys instead. The Debian admins does not like allowing ssh-dsa keys access to debian.org hosts. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
