Bug#961836: transition: openbabel
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello, I would like to request a transition slot for openbabel (experimental -> unstable). Current ben tracker [1] is fine. Transition affects two packages in testing: v-sim and xdrawchem. They build successfully without patching, thus binNMUing them will be sufficient. Best, Andrius [1] https://release.debian.org/transitions/html/auto-openbabel.html signature.asc Description: OpenPGP digital signature
Bug#961833: buster-pu: package openstack-debian-images/1.36
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Dear release team,
tl;dr: if not using a DHCP to boot VMs, cloud-init would get the DNS
addresses from the configdrive, which only works if resolvconf is
installed. The attached patch fixes this.
I'd like to add the "resolvconf" package to the official Debian OpenStack
image for Buster. Doing so is done by simply adding the package to the list
in openstack-debian-images/1.36. See attached debdiff. Once the package
reaches Buster, the new OpenStack image will include resolv.conf. Hopefully,
I can ask Steve to use the updated openstack-debian-images/1.36+deb10u1
before openstack-debian-images moves from proposed-updates to Buster.
Rational for fixing this can be found here:
https://bugs.launchpad.net/cloud-init/+bug/1850310
and in this debian-cloud thread (not only the first message, but also
the follow-ups):
https://lists.debian.org/debian-cloud/2020/05/msg00086.html
Also, the launchpad bug above mention tests from multiple people, which
is why it feels like a safe change.
Since I don't think a DHCP-less cloud system is uncommon, it'd be really
nice to fix this (by adding the resolvconf package in the default
OpenStack image, which implies fixing the openstack-debian-images in
Buster).
Your thoughts?
Cheers,
Thomas Goirand (zigo)
>From 5a386303ba1ab60acd062c800d6bc16223483c08 Mon Sep 17 00:00:00 2001
From: Thomas Goirand
Date: Sat, 30 May 2020 01:46:11 +0200
Subject: [PATCH] * Add the resolvconf if installing cloud-init, needed in
case a VM gets the DNS configuration from configdrive instead of DHCP.
More on this can be found here:
https://bugs.launchpad.net/cloud-init/+bug/1850310.
---
build-openstack-debian-image | 2 +-
debian/changelog | 8
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/build-openstack-debian-image b/build-openstack-debian-image
index 0e54937..50341e9 100755
--- a/build-openstack-debian-image
+++ b/build-openstack-debian-image
@@ -456,7 +456,7 @@ else
fi
NEEDED_PACKAGES=${NEEDED_PACKAGES},dbus,ntp,unscd
if [ "${CLOUD_INIT}" = "yes" ] ; then
- NEEDED_PACKAGES=${NEEDED_PACKAGES},cloud-init,cloud-utils
+
NEEDED_PACKAGES=${NEEDED_PACKAGES},cloud-init,cloud-utils,resolvconf
fi
fi
diff --git a/debian/changelog b/debian/changelog
index a78dd2e..190f1aa 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+openstack-debian-images (1.36+deb10u1) unstable; urgency=medium
+
+ * Add the resolvconf if installing cloud-init, needed in case a VM gets the
+DNS configuration from configdrive instead of DHCP. More on this can be
+found here: https://bugs.launchpad.net/cloud-init/+bug/1850310.
+
+ -- Thomas Goirand Sat, 30 May 2020 01:44:38 +0200
+
openstack-debian-images (1.36) unstable; urgency=medium
* Fix-up bondvlan with OVS bridge option.
--
2.20.1
Bug#961442: stretch-pu: package libclamunrar/0.102.3-0+deb9u1
On 2020-05-28 22:10:38 [+0100], Adam D. Barratt wrote: > Please go ahead. thx, uploaded. > Regards, > > Adam > Sebastian
Bug#961440: stretch-pu: package clamav/0.102.3+dfsg-0~deb9u1
On 2020-05-27 22:17:28 [+0100], Adam D. Barratt wrote: > Please go ahead. thx, uploaded. > Regards, > > Adam Sebastian
Bug#961439: buster-pu: package clamav/0.102.3+dfsg-0+deb10u1
On 2020-05-27 22:16:11 [+0100], Adam D. Barratt wrote: > Please go ahead. thx, uploaded. > Was the intent that the updates be pushed via -updates? Yes, please. If you need any additional information please let me know. > Regards, > > Adam > Sebastian
Bug#961441: buster-pu: package libclamunrar/0.102.3-0+deb10u1
On 2020-05-28 21:56:25 [+0100], Adam D. Barratt wrote: > Please feel free to go ahead. thx, uploaded. > Regards, > > Adam Sebastian
Re: Debian 10.0 works with third generation Ryzen
Mick Ab wrote: > https://www.phoronix.com/scan.php?page=article=3900x-linux-distros=1 > > The above article shows that Debian 10.0 works okay with a third generation > Ryzen CPU. > > I understood that there were problems with Buster using third generation > Ryzen. > > Has this problem been overcome by installing AMD firmware ? > > Also does the particular BIOS used on the motherboard help to overcome the > problem ? I haven't got any problems at all with a Ryzen 5 3600. Motherboard: ASRock X570 Phantom Gaming 4 No BIOS updates of any kind. amd64-microcode/stable 3.20181128.1 is installed. Everything was perfectly smooth. Similar experiences obtained with Ryzen R1505G, Ryzen 3400G, and a Ryzen laptop. Built-in graphics wanted AMD graphics firmware. -dsr-
Debian 10.0 works with third generation Ryzen
https://www.phoronix.com/scan.php?page=article=3900x-linux-distros=1 The above article shows that Debian 10.0 works okay with a third generation Ryzen CPU. I understood that there were problems with Buster using third generation Ryzen. Has this problem been overcome by installing AMD firmware ? Also does the particular BIOS used on the motherboard help to overcome the problem ?
Debian 10.0 works with 3rd generation Ryzen
https://www.phoronix.com/scan.php?page=article=3900x-linux-distros=1 The above article shows that Debian 10.0 will work with a third generation Ryzen CPU. I understood that the stable release of Buster had problems with such CPUs. Has the problem been overcome by installing appropriate AMD firmware ? Has the BIOS setting of the motherboard also played a part ?
Bug#955211: release.debian.org: Transition r-base for 4.0.0
On 29 May 2020 at 07:51, Dylan Aïssi wrote: | Hi, | | Le jeu. 28 mai 2020 à 18:58, Dirk Eddelbuettel a écrit : | > | > Thanks everybody for the help with the transition: 4.0.0-3 is now in testing. | > | | \o/ | | Both transition trackers (r-api-4.0 and r-api-bioc-3.11) were not very | useful to determine the order to update Bioconductor packages. | Some Bioconductor packages were green in the first tracker but red in | the second one, because they were automatically rebuild without an | upgrade. | So, it was not possible to use the first tracker to follow the upgrade | order of Bioconductor packages. | And the second tracker did not consider the r-api-4.0 rebuild order, | so some packages in the first levels were not buildable until the | dependency chain was ready for r-api-4.0. | | Next time there is a transition with these two r-api virtual packages, | we should use a unique ben file for them, something like this: | | title = "r-api"; | is_affected = .depends ~ "r-api-3.5" | .depends ~ "r-api-4.0" | | .depends ~ "r-api-bioc-3.10" | .depends ~ "r-api-bioc-3.11"; | is_good = .depends ~ "r-api-4.0" | .depends ~ "r-api-bioc-3.11"; | is_bad = .depends ~ "r-api-3.5" | .depends ~ "r-api-bioc-3.10"; Good point. Probably worth trying if the next transition once again has BioC within a week (which is common). Nobody knows what will be in R 4.1.0 next year. With some luck we may get by without a transition (a la R 3.6.0). Cheers, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: Bug#960600: buster-pu: package asunder/2.9.3-3+deb10u1
On Thu, 14 May 2020 14:25:03 +0200, Andreas Ronnquist wrote: The corresponding change has come in an upstream release too now, and I have uploaded that (and removed my Debian patch) in unstable. See the upstream changelog at the bottom of https://littlesvr.ca/bugs/show_bug.cgi?id=2 -- Andreas Rönnquist mailingli...@gusnan.se gus...@debian.org
Bug#961776: marked as done (nmu: openrc_0.42-1)
Your message dated Fri, 29 May 2020 09:23:28 +0200 with message-id and subject line Re: Bug#961776: nmu: openrc_0.42-1 has caused the Debian Bug report #961776, regarding nmu: openrc_0.42-1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 961776: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961776 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Since the last upload of package openrc was not a source-only upload, I'm requesting a binNMU to have amd64 packages rebuilt on buildd. nmu openrc_0.42-1 . amd64 . unstable . -m "Rebuild on buildd" -- Regards, Boyuan Yang --- End Message --- --- Begin Message --- On Fri, 29 May 2020 at 07:06, Boyuan Yang wrote: > Since the last upload of package openrc was not a source-only upload, > I'm requesting a binNMU to have amd64 packages rebuilt on buildd. > > nmu openrc_0.42-1 . amd64 . unstable . -m "Rebuild on buildd" Scheduled, thanks!--- End Message ---
