Re: Can we collaborate with Debian better?
There is a little bit more on "removing packages" here: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing_Packages So it's actually a 'must' to have a LP bug for getting a package removed. BR, Frank On Sun, May 5, 2024 at 7:32 PM Simon Quigley wrote: > Hi Dima, > > As a Debian Developer myself, I understand your concerns. Processes in > this respect could be slightly better, but it also comes down to the > differences between the two distributions. More detailed responses inline. > > On 5/2/24 10:56 AM, Dima Kogan wrote: > > Hello. > > > > I'm a Debian developer, and contribute to Ubuntu only indirectly: by my > > contributions to Debian being automatically pulled into Ubuntu. But > > since Ubuntu has more users than Debian, most of MY users use the Ubuntu > > packages. So I'd like to talk about improving the links between the two > > projects. In particular: > > Ubuntu and Debian package maintenance responsibilities are slightly > different; in Ubuntu, members of the Core Developers team are > collectively responsible for the packages in the Main and Restricted > components, and Masters of the Universe are collectively responsible for > packages in the Universe and Multiverse. The ratio of "maintainers > holding responsibility":"packages to be maintained" is much lower in > Ubuntu than it is in Debian. > > Once a package has landed in the Ubuntu archive, Ubuntu Developers now > collectively hold responsibility for that package. We ease much of this > work by autosyncing packages without deltas to Ubuntu in the first half > of each cycle; that being said, we sometimes drive major transitions in > Ubuntu before Debian, to align with our release cycle. > > Many Ubuntu Developers (myself included) are trained to give as much > back to Debian as we possibly can. If we fix a package that both exists > in Debian and has the same bug, we are encouraged to send that fix > upstream to the Debian bug tracker (or upstream itself, or both) to > ensure less friction when we have to merge new changes from Debian. Some > teams within Ubuntu do not follow this process at all, but I would > consider them the exception rather than the rule. > > The Debian maintainers of a package are not responsible for how their > packages are used in Ubuntu, that's Ubuntu's responsibility. That being > said, it is best practice to collaborate as much as we reasonably can, > with the time we are given. > > > 1. Debian and Ubuntu both have separate bug trackers. But for most > > Ubuntu packages, there's no "Ubuntu" maintainer: there's just the > > indirect one from Debian. In this case (which is most packages), it's > > unhelpful for the Ubuntu bug tracker to exist as a separate thing. If > > it must exist as a separate thing, those bugs should be forwarded > > automatically to the Debian bug tracker. And updates (including > > status updates) should be ingested back into the Ubuntu tracker. For > > my packages I do try to manually look at the Ubuntu bug reports, but > > I have no rights to close those bugs on launchpad. Probably I can > > sign up somewhere, but as the DEBIAN developer, I shouldn't need to > > do that. > > I disagree with this approach. Ubuntu and Debian are not ABI-compatible; > Ubuntu has a slightly different toolchain than Debian, and there are > core differences in e.g. dpkg. Not all Ubuntu bugs are Debian bugs, not > all Ubuntu teams want their bugs sent up to Debian, and many Debian > Maintainers don't care about Ubuntu. This is a reality of maintaining > separate distributions. > > In some common cases, yes this seems reasonable, we should forward bugs > to Debian. That being said, the first step is making sure the bug > actually exists in the Debian-built version of the package, which is not > always the case. > > Generally, I do think we can be better about triaging our bugs and > sending what we can up to Debian. That being said, I disagree with the > solution of completely automating it. > > > 2. As I just discovered, when Ubuntu rebuilds the archive for a release, > > packages that FTBFS are silently dropped. There's no bug report on > > either of the two bug trackers. I'm upstream for a project that has > > been excluded from 24.04 because of this gap in the process. There > > really should be a bug report filed, so that the problem can be fixed > > before the release (what Debian does for their releases). And this > > should be filed on the Debian bug tracker, if that's where the > > maintenance happens. > > This entirely falls on the Ubuntu Archive Administrators. To my > understanding as an Ubuntu Developer, if we want a package removed, it > is best practice to either have a Debian removal bug or an Ubuntu > removal bug explaining the rationale. Whether this is enforced is up to > the Archive Administrator doing the removal, since the only known public > documentation says nothing about filing bugs: >
Re: Update for openssl? (CVE-2023-0286)
Hi Philipp, I recommend having a look at the Ubuntu CVE Tracker, which shows status and details about CVE-2023-0286 https://ubuntu.com/security/cves?q=2023-0286 https://ubuntu.com/security/CVE-2023-0286 Bye, Frank On Sun, Feb 26, 2023 at 6:29 PM wrote: > This is my first time writing here. Please let me know if this is the > wrong place to ask this question: When can we expect an update for the > Focal (Ubuntu 20) openssl package to version 1.1.1t? The Security > Advisory to CVE-2023-0286 had a high severity level, so I'm a bit > nervous, and I don't know much about compiling myself. > > Philipp > > > -- > 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 > -- 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: MOTU application: Frank Heimes (continuation)
Many thx Utkarsh - and the entire DMB ! On Thu, Dec 1, 2022 at 9:36 AM Utkarsh Gupta wrote: > Hello, > > On Thu, Aug 25, 2022 at 1:20 AM Frank Heimes > wrote: > > Dear DMB, > > I would like to continue my MOTU application on Mo Sept the 5th. > > At the last meeting (2022-07-25) we were late and didn't had enough time > to finish. > > > > I've also added myself to the next DMB agenda. > > After some back and forth and finally voting via the mailing list (due > to lack of quorum during the meeting), DMB voted in Frank's favor and > thus we'd like to welcome Frank to the MOTU family. Congratulations > and welcome aboard. :) > > > Utkarsh, > On behalf of DMB > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Best practices for quilt patches
Hi Robie, I think it's great to have best practices for quilt patches. Since you also mentioned renaming of patches, this raises the question if there is also a best practice for a quilt patch naming scheme? (I'm at least not aware of one.) I noticed several different ones, just to name a few: .patch .patch .patch lp--.patch etc. (I think I also saw '.diff' as suffix instead of '.patch') What I personally liked most so far, for upstream patches (and adopted since then) is: -.patch But maybe different teams (or individuals) just have different preferences. And btw. I '+1' with Marc - also ran once into issues in the past, where offsets piled up too much. So it might be needed - in rare cases. (But understood - only in such rare cases...) Bye, Frank On Wed, May 25, 2022 at 5:31 PM Marc Deslauriers < marc.deslauri...@canonical.com> wrote: > > On 2022-05-25 10:50, Robie Basak wrote: > > Today on my SRU shift I spent some effort trying to see past quilt diff > > noise. Most of it seemed unnecessary and was only present because of > > gratuitous refreshes. > > > > I'm not sure we have best practices are documented anywhere. I'd like to > > define some guidelines that make reviews easier. I think many people > > stick to these already. Can we agree that they're a good thing and try > > to get more people to do them? > > > > Summary > > > > 1. Use dep3 headers (https://dep-team.pages.debian.net/deps/dep3/) > > > > 2. Use "-p ab --no-timestamps --no-index" or equivalent (as documented at > > https://wiki.debian.org/UsingQuilt#Environment_variables). > > > > 3. Try not to update or refresh any quilt patch unless specifically > > required (ie. a patch doesn't apply, or applies with fuzz). Exception: > > do update dep3 headers. > > > > Details and rationale: > > > > 1. Use dep3 headers (https://dep-team.pages.debian.net/deps/dep3/) > > > > This makes it easy for reviewers to correlate the patch against > > upstream, find any related upstream commentary or subsequent related > > commits, etc. > > > > 2. Use "-p ab --no-timestamps --no-index" or equivalent (as documented at > > https://wiki.debian.org/UsingQuilt#Environment_variables). > > > > This reduces diff noise in the future if an update becomes required. > > > > Exception: if taking the patch from upstream and it applies as-is, then > > using the upstream form of the patch reduces the initial diff further, > > so that's preferable. So this combines with 3: use these settings when a > > refresh is required or generating the patch from scratch, but don't > > refresh to apply the settings to reduce noise unless actually required. > > > > 3. Try not to update or refresh any quilt patch unless specifically > > required (ie. a patch doesn't apply, or applies with fuzz). Exception: > > do update dep3 headers. > > > > This reduces the size of any diff taken against any other version of the > > quilt patch. Hopefully to zero. > > > > If one patch needs refreshing, refresh just that one rather than all of > > them. > > > > If a patch applies with offset, that's not a reason to refresh it. > > I kind of disagree with this, I've hit issues before when the offsets were > big > enough that adding another patch before one with offsets would result in > the > patch being applied to the wrong function. > > While nobody should be refreshing patches for no reason to keep the debdiff > changes to a minimum, I think it's reasonable to refresh newly added > patches, > and I would disagree with any best practice that states the opposite. > > > > > Example 1: you can append ".patch" to an upstream Github URL, download > > that to debian/patches/, rename and add dep3 headers but without > > modifying the patch itself. Then a reviewer can look at the dep3 > > header, identify that the origin was GitHub, diff against that same URL, > > and easily confirm that the patch hasn't been modified. > > > > Example 2: if I'm reviewing an SRU to multiple releases and the quilt > > patches are exactly identical, then I only have to review the patch > > itself once[1]. But if you've unnecessarily refreshed the patch on each > > upload, now I have a bunch of noise I have to review to verify that there > > is no functional change introduced. > > > > Does this sound reasonable to everyone to follow in general, such that > > we can document these as guidelines somewhere? I wouldn't expect them to > > be enforced as a hard rule, but once documented I also think it'd be > > reasonable for any reviewer to choose to push back where non-adherence > > is causing an actual problem. > > > > Anything to change, or anything to add? > > > > Thanks, > > > > Robie > > > > > > [1] The context outside the patch itself might be different and I do > > have to consider that too, but if I know the patches are identical, that > > is also made easier. > > > > > > Marc. > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: >
Re: Bumping the baseline on ppc64el in jammy to POWER9
Hi John, do you have Scalingstack or Canonistack in mind? Scalingstack is the base for the builders and autopkg tests etc and is now all on P9 level. These systems were setup by IS and the infra. on top by the IS and LP team. In case you need (or use today) systems on top - please let us know ... Bye, Frank On Fri, Dec 10, 2021 at 3:25 PM John Chittum wrote: > I have a slight concern regarding CPC images. we currently produce ppcle64 > images and test in scalingstack. Since ppcel64 is a supported arch, if > those tests fail, no arches will be released. > > if scalingstack does not have access to P9 machines, then Jammy testing > will continuously fail. > > Before making this change, can we ensure we have test infra available for > use, in an automated fashion, that is supported by IS in an openstack > deployment? Or are plans right now only going to be in the MAAS powered > labs? If so, we'll have to remove ppcel64 testing entirely from our > blocking matrix, which makes it truly a "best effort" architecture > --- > Dr. John Chittum > Engineering Manager, Canonical, CPC team > > > On Fri, Dec 10, 2021 at 7:57 AM Frank Heimes > wrote: > >> Just to close the look (based on the MM chat): >> >> - Patricia released 'bobone' - thx Patricia >> - bobone is resource-wise more powerful that the existing P8 system for >> ISO testing, so it should be good >> - from there 10.25.200.31 can be (surprisingly) reached - so no need for >> an RT >> >> We'll put a new dedicated ISO testing system on the top of the list in >> case new P9 loaners arrive ... >> >> Thx, Frank >> >> On Thu, Dec 9, 2021 at 5:34 PM Frank Heimes >> wrote: >> >>> Ok, so like mentioned in MM, the interim solution is to provide you one >>> system from the PowerMAAS pool (with sufficient) resources. >>> And once we got more P9 loaners, one of these will be delegated to >>> you/Server-team for ISO testing. >>> >>> Next steps: >>> - I'll identify one system >>> - will check the network connectivity, if it's possible to >>> reach 10.25.200.31 (what is probably not the case) >>> - if it's not possible I'll open an RT and ask for routing adjustments >>> >>> I'll keep you in the loop ... (probably '-' ubuntu-devel then, to not >>> spam others too much ...) >>> >>> Frank >>> >>> >>> On Thu, Dec 9, 2021 at 3:40 PM Matthias Klose wrote: >>> >>>> On 12/9/21 15:24, Christian Ehrhardt wrote: >>>> > On Thu, Dec 9, 2021 at 2:25 PM Matthias Klose >>>> wrote: >>>> >> >>>> >> This weekend, we will bump the baseline for the ppc64el architecture >>>> to POWER9. >>>> >> A test compiler (gcc-11) for jammy can be found at >>>> >> >>>> >> https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/p9 >>>> >> >>>> >> We will not do an explicit test rebuild for that change, but do the >>>> first test >>>> >> rebuild during the Xmas/New Year breaks with this p9 default. If >>>> bugs are found >>>> >> with these defaults, >>>> >> >>>> >> - fix the bug if possible >>>> >> >>>> >> - file a bug report with the tag "power9" >>>> >> >>>> >> - if a fix is urgently needed, file the bug report as >>>> >>above, and then upload the package with a workaround >>>> >>defaulting to the previous baseline: >>>> >> >>>> >> -march=power8 -mtune=power9 >>>> > >>>> > Hi Doko, >>>> > to understand this right, the new will be -march=power9 then? >>>> > >>>> > If yes, that implies that any power8 test machine won't be usable for >>>> >=jammy. >>>> > I just wanted to spell this out so that the implication is clear since >>>> > I think while >>>> > P8 machines are old they are in common use as test system AFAIK. >>>> >>>> yes, that's correct. >>>> >>>> Matthias >>>> >>>> -- >>>> ubuntu-devel mailing list >>>> ubuntu-devel@lists.ubuntu.com >>>> Modify settings or unsubscribe at: >>>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel >>>> >>> -- >> ubuntu-devel mailing list >> ubuntu-devel@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel >> > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Bumping the baseline on ppc64el in jammy to POWER9
Just to close the look (based on the MM chat): - Patricia released 'bobone' - thx Patricia - bobone is resource-wise more powerful that the existing P8 system for ISO testing, so it should be good - from there 10.25.200.31 can be (surprisingly) reached - so no need for an RT We'll put a new dedicated ISO testing system on the top of the list in case new P9 loaners arrive ... Thx, Frank On Thu, Dec 9, 2021 at 5:34 PM Frank Heimes wrote: > Ok, so like mentioned in MM, the interim solution is to provide you one > system from the PowerMAAS pool (with sufficient) resources. > And once we got more P9 loaners, one of these will be delegated to > you/Server-team for ISO testing. > > Next steps: > - I'll identify one system > - will check the network connectivity, if it's possible to > reach 10.25.200.31 (what is probably not the case) > - if it's not possible I'll open an RT and ask for routing adjustments > > I'll keep you in the loop ... (probably '-' ubuntu-devel then, to not spam > others too much ...) > > Frank > > > On Thu, Dec 9, 2021 at 3:40 PM Matthias Klose wrote: > >> On 12/9/21 15:24, Christian Ehrhardt wrote: >> > On Thu, Dec 9, 2021 at 2:25 PM Matthias Klose wrote: >> >> >> >> This weekend, we will bump the baseline for the ppc64el architecture >> to POWER9. >> >> A test compiler (gcc-11) for jammy can be found at >> >> >> >> https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/p9 >> >> >> >> We will not do an explicit test rebuild for that change, but do the >> first test >> >> rebuild during the Xmas/New Year breaks with this p9 default. If bugs >> are found >> >> with these defaults, >> >> >> >> - fix the bug if possible >> >> >> >> - file a bug report with the tag "power9" >> >> >> >> - if a fix is urgently needed, file the bug report as >> >>above, and then upload the package with a workaround >> >>defaulting to the previous baseline: >> >> >> >> -march=power8 -mtune=power9 >> > >> > Hi Doko, >> > to understand this right, the new will be -march=power9 then? >> > >> > If yes, that implies that any power8 test machine won't be usable for >> >=jammy. >> > I just wanted to spell this out so that the implication is clear since >> > I think while >> > P8 machines are old they are in common use as test system AFAIK. >> >> yes, that's correct. >> >> Matthias >> >> -- >> ubuntu-devel mailing list >> ubuntu-devel@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel >> > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Bumping the baseline on ppc64el in jammy to POWER9
Ok, so like mentioned in MM, the interim solution is to provide you one system from the PowerMAAS pool (with sufficient) resources. And once we got more P9 loaners, one of these will be delegated to you/Server-team for ISO testing. Next steps: - I'll identify one system - will check the network connectivity, if it's possible to reach 10.25.200.31 (what is probably not the case) - if it's not possible I'll open an RT and ask for routing adjustments I'll keep you in the loop ... (probably '-' ubuntu-devel then, to not spam others too much ...) Frank On Thu, Dec 9, 2021 at 3:40 PM Matthias Klose wrote: > On 12/9/21 15:24, Christian Ehrhardt wrote: > > On Thu, Dec 9, 2021 at 2:25 PM Matthias Klose wrote: > >> > >> This weekend, we will bump the baseline for the ppc64el architecture to > POWER9. > >> A test compiler (gcc-11) for jammy can be found at > >> > >> https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/p9 > >> > >> We will not do an explicit test rebuild for that change, but do the > first test > >> rebuild during the Xmas/New Year breaks with this p9 default. If bugs > are found > >> with these defaults, > >> > >> - fix the bug if possible > >> > >> - file a bug report with the tag "power9" > >> > >> - if a fix is urgently needed, file the bug report as > >>above, and then upload the package with a workaround > >>defaulting to the previous baseline: > >> > >> -march=power8 -mtune=power9 > > > > Hi Doko, > > to understand this right, the new will be -march=power9 then? > > > > If yes, that implies that any power8 test machine won't be usable for > >=jammy. > > I just wanted to spell this out so that the implication is clear since > > I think while > > P8 machines are old they are in common use as test system AFAIK. > > yes, that's correct. > > Matthias > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Call for testing: mongodb 3.6
I just did a smoke test on s390x and it looks fine. Installation and basic use was flawless ... Thx for the update (and FFe)! Frank Heimes | Tech. Lead Ubuntu Server on Z | Canonical Ltd. mail: frank.hei...@canonical.com irc: jfh www.canonical.com | www.ubuntu.com | ubuntu-on-big-iron.blogspot.com <http://ubuntu-on-big-iron.blogspot.com/?view=sidebar> On Mon, Apr 16, 2018 at 11:04 AM, Robie Basak <robie.ba...@ubuntu.com> wrote: > I've updated mongodb and mongo-tools from 3.4 to 3.6 in Bionic (LP: > #1761807). They remain in universe. > > As this is very late in the cycle, I took quite some care in testing > things to detect any packaging regressions. I found none. > > If you use mongodb at all, please help us by testing so that we can fix > any issues before release if possible. > > You can find mongodb 3.6 release notes here: > > https://docs.mongodb.com/manual/release-notes/3.6/ > > and compatibility changes for 3.6 here: > > https://docs.mongodb.com/manual/release-notes/3.6-compatibility/ > > On upgrade from 3.4, mongod will remain in 3.4 compatibility mode by > default, so from a distribution perpsective I believe this will be safe. > Nevertheless, all testing is valuable and appreciated. > > Thanks, > > Robie > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/ubuntu-devel > > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: plans for golang packages in z
Hi Michael, I think this is a great idea - because I heard from IBM that Go 1.7 contains several s390x patches that make the z support sound, and that kubernetes will be re-based to golang 1.7 at some point in time, which would allow to build it for s390x without any further adjustment. Bye, Frank Frank Heimes | Tech. Lead z | Canonical Ltd. mail: frank.hei...@canonical.com irc: jfh P: +49 (0) 7031 415515 www.canonical.com | www.ubuntu.com | ubuntu-on-big-iron.blogspot.com <http://ubuntu-on-big-iron.blogspot.com/?view=sidebar> On Thu, Oct 13, 2016 at 11:03 PM, Michael Hudson-Doyle < michael.hud...@canonical.com> wrote: > Hi, > > It'd be nice to switch the default golang package to 1.7 during the > toolchain update part of the z development cycle. This is just a matter of > uploading a golang-defaults package with a version like 2:1.7+0ubuntu1. It > the stars align, the go team will release Go 1.7.2 before this happens but > I don't think waiting very long for that makes sense. > > I guess in practice this is just a pre-emptive request to the release team > to allow my golang-defaults upload through nice and early. > > Cheers, > mwh > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/ubuntu-devel > > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
