Re: sbcl ppc64le bootstrap
On Tue, Jul 12, 2022 at 04:48:11PM -0300, Athos Ribeiro wrote: Hello, We (sergiodj and I) will bootstrap the sbcl lisp compiler for ppc64le for kinetic. This message is intended to be a heads-up for any interested party and a reference for the archive admins for whenever we need new binaries accepted as a consequence of this bootstrapping process. Below we provide more context for the matter and describe how the bootstrap process will be performed. While working on pgloader, we realized that the package does not build for ppc64le. Further investigation showed that there are no sbcl binaries for some architectures, such as s390x and ppc64le. Since sbcl build depends on itself, bootstrapping is needed to make those binaries available. While there is evidence of recent work on the s390x bootstrapping in Debian (please refer to the package changelog), the ppc64le package has been available in Debian for a while now, but was never bootstrapped in Ubuntu. We will now bootstrap sbcl for ppc64le by performing a first sbcl build with clisp. Once it is accepted in the archive, we will revert the ppc64le-with-clisp changes and rebuild sbcl using the clisp-built version of sbcl. After the bootstrapping process is completed, there should be no delta left in the sbcl package and the next Debian upload should be a potential sync. With that in mind, we will use the approach proposed back in May [1] and set the version string with a "maysyncX" suffix. Hence, we will - Change the source package to build with clisp for ppc64le and upload sbcl "2:2.2.3-2maysync1"; and - once the new ppc64le binary is accepted, revert the previous change and upload sbcl "2:2.2.3-2maysync2" Then, the next Debian upload will be a sync. If a Debian upload happens in between "2:2.2.3-2maysync1" and "2:2.2.3-2maysync2", it will just mean "2:2.2.3-2maysync2" is no longer necessary. As a matter of fact, we will only upload a "2:2.2.3-2maysync2" version to ensure the new ppc64le binary is also built using sbcl, as the already available binaries for the other platforms. Once "2:2.2.3-2maysync2" is available, we will proceed to perform no-chage-rebuilds for the platform dependent sbcl reverse build dependencies. These are, in a first level: buildapp cafeobj And in a second level (both depend on buildapp): pgloader pgcharts (multiverse) The bootstrap process will be tracked in LP: #1968579. The current change proposal for the bootstrapping process is available at https://salsa.debian.org/athos/sbcl/-/commits/ubuntu-bootstrap [1] https://www.mail-archive.com/ubuntu-devel@lists.ubuntu.com/msg10417.html -- Athos Ribeiro This bootstrap process is now complete. -- Athos Ribeiro -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: rsyslog trigger?
Hi Andreas, On Wed, Jul 20, 2022 at 10:49:42AM -0300, Andreas Hasenack wrote: > I was working on a few packages that had bugs related to rsyslog > logging, and noticed that they don't seem to restart or reload rsyslog > after they install a config snippet in /etc/rsyslog.d/*.conf. I think it's bad/surprising behaviour to automatically end up in a state where the actually running configuration doesn't match the configuration in /etc. That would lead to user surprises and/or regressions on reboot or on a further package upgrade (to rsyslog in this case). > Would it make sense to use dpkg triggers to restart rsyslog everytime > a file is updated in /etc/rsyslog.d/*.conf? That sounds like the appropriate way to fix it to me. Robie signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: rsyslog trigger?
Never mind, the trigger exists already :) On Wed, Jul 20, 2022 at 10:49 AM Andreas Hasenack wrote: > > Hi, > > I was working on a few packages that had bugs related to rsyslog > logging, and noticed that they don't seem to restart or reload rsyslog > after they install a config snippet in /etc/rsyslog.d/*.conf. > > For example, haproxy even has this note in its README.Debian: > ``` > The default HAProxy configuration in Debian uses /dev/log for logging and > ships an rsyslog snippet that creates /dev/log in HAProxy's chroot and logs > all > HAProxy messages to /var/log/haproxy.log. To take advantage of this, you must > restart rsyslog after installing this package. > ``` > I checked a few others and the only restart/reload I see is in the > logrotation, which might not even kick in if there is no log file yet, > or if it's empty. > > Would it make sense to use dpkg triggers to restart rsyslog everytime > a file is updated in /etc/rsyslog.d/*.conf? -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
rsyslog trigger?
Hi, I was working on a few packages that had bugs related to rsyslog logging, and noticed that they don't seem to restart or reload rsyslog after they install a config snippet in /etc/rsyslog.d/*.conf. For example, haproxy even has this note in its README.Debian: ``` The default HAProxy configuration in Debian uses /dev/log for logging and ships an rsyslog snippet that creates /dev/log in HAProxy's chroot and logs all HAProxy messages to /var/log/haproxy.log. To take advantage of this, you must restart rsyslog after installing this package. ``` I checked a few others and the only restart/reload I see is in the logrotation, which might not even kick in if there is no log file yet, or if it's empty. Would it make sense to use dpkg triggers to restart rsyslog everytime a file is updated in /etc/rsyslog.d/*.conf? -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[ubuntu-studio-devel] Ubuntu Studio daily CD health check
This is a daily health check report on the Ubuntu Studio CD images. If you have any questions, contact Colin Watson . ubuntustudio/dvd: kinetic-dvd-amd64.iso oversized by 58306048 bytes (5058306048) -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: +1 maintenance
On Sat, Jul 9, 2022 at 5:19 AM Steve Langasek wrote: > > +1 maintenance shift, July 4-8. July 4 is a national holiday in the US, so > this was a short cycle. > ... > > osmcoastline: stuck in -proposed and blocking libgdal30 transition because > pandoc is out of date on armhf and s390x, and no solution seems to be > forthcoming. osmcoastline has no reverse-dependencies, so removed the armhf > and s390x binaries from the release pocket to let this migrate. > Hi, I think I might have recently seen another failure [1] due to that. Was it appearing as a broken build depends only on armhf & s390x in your case as well? like: Missing build dependencies: pandoc-data (< 2.9.2.1-3ubuntu2.~) Should we consider removing [2] from proposed to un-break other builds until this can be resolved in pandoc for real? [1]: https://launchpad.net/ubuntu/+source/xen/4.16.1-1/+build/24186367 [2]: https://launchpad.net/ubuntu/+source/pandoc/2.9.2.1-3ubuntu3 ... > > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developer https://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Christian Ehrhardt Senior Staff Engineer, Ubuntu Server Canonical Ltd -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
