Re: git-ubuntu: call for testing: core24
On Sun, Oct 13, 2024 at 9:41 PM Robie Basak wrote:
>
> I've prepared an update to the git-ubuntu snap to move from a base of
> core20 to core24.
>
> Automated tests are passing as expected, including various snap
> integration tests. But the interactions between git-ubuntu and the host
> system are complex. I'd appreciate additional testing!
>
> You can update to a build of my core24 snap branch[1] using:
>
> sudo snap refresh git-ubuntu --channel=latest/edge/core24
>
> Please start by running:
>
> git-ubuntu.self-test
Thank you Robie
FYI (so you not only get negative cross test results) the Test ran
successfully for me (Noble):
458 passed, 3 xfailed, 2 warnings in 175.02s (0:02:55)
The two warnings seem to be deprecation warnings that probably happen
for every user:
gitubuntu/__main__.py:7
/snap/git-ubuntu/1613/usr/lib/python3/dist-packages/gitubuntu/__main__.py:7:
DeprecationWarning: pkg_resources is deprecated as an API. See
https://setuptools.pypa.io/en/latest/pkg_resources.html
import pkg_resources
pkg_resources/__init__.py:2871
/snap/git-ubuntu/1613/usr/lib/python3/dist-packages/pkg_resources/__init__.py:2871:
DeprecationWarning: Deprecated call to
`pkg_resources.declare_namespace('logilab')`.
Implementing implicit namespace packages (as specified in PEP 420)
is preferred to `pkg_resources.declare_namespace`. See
https://setuptools.pypa.io/en/latest/references/keywords.html#keyword-namespace-packages
declare_namespace(pkg)
> ...and check that it passes. Then use git-ubuntu like you normally do,
> and please report any regressions.
I ran a few basics (clone and checking the repo matches what I got
last time) which still worked as they did last week with the former
version.
export-orig and merge-start worked for me as well without behaving differently.
Tested on 1.1-55-gcab5296 (1613).
> If no issues are reported, I'll push this to latest/edge in the next few
> days.
>
> Architectures other than amd64 are also now available, but I haven't
> published a core24 branch for those. They will get the build with core24
> shortly after I push to latest/edge in a few days. Until then, builds
> continue to be available following the main branch, based on core20.
>
> Known issues:
>
> Python's keyring storage location has moved from $XDG_DATA_HOME to
> $XDG_CONFIG_HOME. This may result in the the following error:
>
> > RuntimeError: Keyring config exists only in the old location
> > $HOME/.local/share/python_keyring/keyringrc.cfg and should be moved to
> > $HOME/.config/python_keyring/keyringrc.cfg to work with this version
> > of keyring.
>
> This comes from the python3-keyring package in 24.04.
>
> It seems dangerous to migrate this automatically since other tools may
> also keyrings stored in the same places. It's probably best to leave
> this for users to resolve themselves. I think the worst case is that you
> will need to reauthenticate with Launchpad after renaming the old
> keyring away, but please let me know your experience.
>
> When running git-ubuntu.self-test, you will see:
One more thing you want to confirm and explain to lower the
suspicious-eye-brow count.
Whole running importer/tag_test.py the test will use the user's GPG
setup (like when running import locally), so it might pop up a GPG
prompt.
> > python-debianbts 4.0.2 requires pysimplesoap, which is not installed.
> > pip check failed but ignoring due to LP: #2084358
>
> This is caused by python3-debianbts in 24.04 causing pip in 24.04 to
> detect an anomaly. For this reason, the result of the "pip check" test
> in git-ubuntu.self-test is still printed, but the failure is ignored.
>
> Thank you for testing!
>
> Robie
>
> [1] Sources: https://git.launchpad.net/~racb/git-ubuntu/ branch "core24"
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
--
Christian Ehrhardt
Director of Engineering, 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
Re: SRUs and the importance of validating upstream release tarballs
On Wed, Oct 2, 2024 at 12:02 PM Robie Basak wrote: > > If we take a fresh upstream release directly into a stable release > update, then it seems to me that it's important to validate that the > orig tarball matches what upstream released, or is otherwise > reproducible against what upstream released (eg. if it was repacked for > the usual reasons). > > It's not currently a documented hard requirement for SRUs, but I think > that it should be, or at least be our default position. > > I've noticed some matter related to this concern a couple of days > running so I thought it was time to start a thread on this. > > When reviewing an SRU that does this, I usually take steps to verify > this. If it doesn't match (usually due to a repack I cannot reproduce) > then I query it. This is sometimes quite painful to do as I try to track > down an upstream source and some way to validate it. > > We have tooling to make this easy in the majority of cases, with uscan, > debian/watch and debian/upstream/signing-key.asc. I usually run `uscan > --download-current-version`, check that HTTPS or GPG was used, and that > the resulting tarball's hash matches the hash in the upload's changes > file. > > It might help to understand my position in the other thread by > considering that I have myself been doing this kind of verification for > years when I review SRUs that include orig tarballs. > > A few discussion points from this: > > 0) If you don't agree that this is important, then I guess this an > opportunity to make your point. > > 1) If you're preparing a relevant SRU, this is a request for you to > please ensure that uscan is set up appropriately with as much security > as upstream offer. Preferably this is done and maintained in the > development release, so by the time an SRU is required, there are no > changes needed to uscan configuration. Since this tooling is > well-established and this is best practice anyway, I trust that this > isn't a controversial request! Note that uscan can do some repacking via > mk-origtargz and Files-Excluded* in debian/copyright. > > 2) If uscan cannot be made to work, then it would be useful to document > how you arrived at the orig tarball you uploaded. > > 3) To what extent should this become a documented requirement for SRUs, > main inclusion, etc? Just like you on SRU, I've been loosely looking at that when I was looking at the NEW queue. I say loosely because it is me doing it "mostly" but not part of these rules and guidance we follow. But it could be and that is why I bring it up. Where it already is a requirement is the MIR process, a working d/watch is checked there before getting to main. This part of the rules is rather old, and back then not everyone was that aware about the importance of sig/csum checks. I'm +1 on your suggestion, but would - if agreed - extend it to also get added to: - NEW queue processing as recommended (we can debate if it shall be strictly required) - MIR processing to strictly require support for checksum/signature if the upstream that backs it provides such That would in the long run help to solve some of your "Preferably this is done and maintained in the development release, so by the time an SRU is required, there are no changes needed to uscan configuration" desire. > Robie > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Christian Ehrhardt Director of Engineering, 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
Re: Requesting help/no response to pings
On Fri, Aug 30, 2024 at 9:29 PM Utkarsh Gupta wrote: > > Hey, > > On Tue, Aug 27, 2024 at 12:29 PM Christian Ehrhardt > wrote: > > - Release team: I asked utkarsh2102 and his management chain, > > and they donated his time for Tue/Wed/Thu. > > Thanks to his team for spending his time - it is important to us! > > Just to summarize my involvement in the last couple of days - > > ### 24.10 - Oracular Feature Freeze > > - Assessed all the FFe in the backlog - over 20 of them. > - Most of them have been approved but I've asked for more information. > - If you're someone who filed an FFe, please take a look. > - If by chance your FFe slipped through, please reach out to me. > - Sponsored a few uploads for fellow contributors. > - Sync'd a package as requested. > - Added hints for lxqt qt6 transition for RikMills. > - Helped with some other transitions ongoing. > - Triggered rebuild for Edubuntu on Erich's request. > > ### 24.04.1 - Noble point release > > I assisted Lukasz for the Noble point release with the following: > > - Checking phased updates. Raising questions when things look "not good". :) > - Analyzing package diffs for each participating flavour. > - Assisting w/ riscv64 testing - thanks Christian and Lukas. > - Updating wiki. > - Pinged IS to clear content-cache for changelogs*. > - Moderating mail on ubuntu-announce@. > - Disabling the SRU freeze. > - Assisting flavours with their testing - thanks arraybolt3 for Ubuntu > Unity & MATE tests. > - And all the other small items here and there. > > ### 22.04.5 - Jammy point release > > Given how strenuous Noble point release was, I wanted to look for > blockers and resolve them ahead of Jammy point release, scheduled on > 12th September. > > - Updating wiki. > - Assisting Mate with cd-boot-images-* along w/ Christian, Andreas and Robie. > - And all the other small items here and there. > > ### Release/DMB > > I also assisted a few people blocked who were blocked for things ACL > wise by adding packages to packageset - > > - Added 3 packages to kubuntu packageset as requested by Scarlett. > - Added 15 packages to kernel-dkma packageset as requested by Timo. > - Added 4 packages to kernel packageset as requested by Timo. > > Let me know if I missed anything. Hope it helped & unblocked a bunch > of things. :) It did indeed help a lot Utkarsh! Thank you for the help and the summary and thanks to your team for donating a bigger share of your time for a while! Forgive me for not writing such a nice summary, but the TL;DR is similar in which I'm happy to have unblocked various cases mostly by processing removals and component mismatches. That ought to benefit all of us by avoiding all changes to unblock and land at the very last minute :-) To no surprise, now even more piled up on me. I'll continue to look after ubuntu-archive pings in #ubuntu-release, but won't be able to do regular queue duties [I'll try but I can't hard-commit for a few days]. > > - u -- Christian Ehrhardt Director of Engineering, 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
Re: Requesting help/no response to pings
> -- Forwarded message - > From: Erich Eickmeyer > Date: Tue, Aug 27, 2024 at 4:50 AM > Subject: Requesting help/no response to pings > To: > > > Hi release team and archive admins! > > For at least the past week, I and others have been pinging/highlighting > ubuntu-archive and ubuntu-release in #ubuntu-release on IRC trying to > get a response for help. Here are some examples: > > * I am unable to do an ISO rebuild request from the ISO tracker (this > has never occurred before), I suspect an issue with cdimage, but > this needs release team attention. > * Kubuntu and Ubuntu Studio are still in the process of transitioning > to Plasma 6 for Oracular, and are blocked by packages needing > removal [1]. > * Ubuntu Studio's oracular builds are failing due to a preinst script > error in the usbmuxd package and I cannot figure out why since they > are *not* failing in Kubuntu, so I have been requesting assistance. > * Ubuntu Studio has an ongoing SRU for users to be in the audio group > by default[2] with an adduser wrapper, targeted for 24.04.1 this > Thursday. While the SRU team is involved, this needs to be expedited > for the release. > * Many others have had requests for package removals, FFes, and other > requests have been done in #ubuntu-release and have gone completely > unanswered/unacknowledged, including an FFe by Rico Tzschichholz for > LibreOffice 24.8.x for oracular [3]. > > These are just examples that I know off the top of my head because they > affect my projects, but there have been plenty more. I understand you've > all been busy this cycle, and we've all heard radio silence on IRC for > more than a week. Hi Erich, thanks for reaching out! And also thanks for understanding everyone being busy, but in addition recently a few moves, PTOs and health issues have made the capacity-ice on this thin enough to crack - sorry for that! Steve was so kind to reach out to me (I'm just back from PTO and still weathering the inbox storm) and made me aware of the situation that you reported. On a first glance it really seems all kinds of special team tasks are needed, archive admins, release team, sru team - so we need a range of people and functions. This can't be just wishful thinking and the reality is clear - I'm unable to do it all myself :-/ Therefore I've checked what we can do and wanted to share the outcome so you know who to engage with (we will look at backlogs and team subscribed issues, but you know best some cases just need discussions). - Release team: I asked utkarsh2102 and his management chain, and they donated his time for Tue/Wed/Thu. Thanks to his team for spending his time - it is important to us! - SRU: I've checked and while it is probably already EOD for RAOF (Tue) the next two normal shifts are rbasak (Wed) and ahasenack (Thu) which are both available this week and will therefore do their full shifts. - Archive admins: for the coming three days I'll (cpaelzer) try to ignore the urgency in my back-from-PTO inbox and give the AA queues and pings a look. While I'm not trained in all AA-tasks yet, I'll get those resolved that I can, to allow others to only focus on where they are strictly needed. - At the same time sil2100 is so kind focussing on the point release tasks Let us hope we can make an impact on this. And to all the sick folks, get well! > However, since many of these are time-sensitive asks, > I wanted to ask, perhaps on behalf of the rest of the community, if > there's a better way to request assistance than IRC these days? We all > very much need answers and acknowledgements on these issues. > > Thanks in advance! > Erich P.S. extra thanks to Utkarsh, not only for helping but also for forwarding me the mail as only some ubuntu-devel mails seem to get through to me. Analyzing that is a task for another day though ... > [1] https://launchpad.net/bugs/2077506 > [2] https://launchpad.net/bugs/2063899 > [3] https://launchpad.net/bugs/2077516 > > -- > Erich Eickmeyer > Ubuntu MOTU > Project Leader - Ubuntu Studio > Technical Lead - Edubuntu > > > -- > Ubuntu-release mailing list > ubuntu-rele...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Christian Ehrhardt Director of Engineering, 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
Re: Requesting autopkgtests
On Mon, Jul 17, 2023 at 1:54 AM Brian Murray wrote: > > The set of people who can trigger autopkgtests at autopkgtest.ubuntu.com > has been recently expanded to include a new team[1] in Launchpad. The > Canonical Foundations team has been added to the autopkgtest-requestors > team and this has made their +1 maintenance shifts and proposed > migration work much easier. Thanks for addressing this issue, it is much appreciated! No more length lists of "could you restart that for me" links. > If you, or a team of which you are an > administrator, are interested in having the ability to retry > autopkgtests for packages which you do not have upload rights please get > in touch with myself or another member of the Ubuntu QA team. I'd ask for [1] to be added to [2]. That would cover the server team and a few closely related friends in CPC and actually QA as well :-) The set of People in that group are tightly controlled and I'd not be concerned about abuse of the test restart permission by any of the current or future members of it. [1]: https://launchpad.net/~canonical-server [2] https://launchpad.net/~autopkgtest-requestors > > Cheers, > -- > Brian Murray > > -- > 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 and acting Director, 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
Re: Autopkgtest Service
On Wed, Mar 22, 2023 at 10:56 PM Brian Murray wrote: > > The other week I created a discourse post[1] to document any known issues > about the autopkgtest service. The Ubuntu QA team will be updating it as > needed and if there is anything really terrible going on I'll still send > an email to this mailing list. Thank you, that will be quite useful to avoid many of us asking your or Paride about "what is currently going on". One question, do you expect Ubuntu developers to use the discussion on the page to report new things (and will you monitor them) or do you continue to want pings via mails or the chat protocol of your choice? Whichever way you decide, this already great page could benefit from a permanent footer "If you think you found something not listed here that is not working right, do/contact " statement reflecting that. > [1] https://discourse.ubuntu.com/t/autopkgtest-service/34490 > > Cheers, > -- > Brian Murray > > -- > 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
Re: PSA: autopkgtest web servers
On Wed, Dec 14, 2022 at 1:04 AM Brian Murray wrote:
>
> The Ubuntu QA team has recently replaced the two apache web servers
> which provide the autopkgtest web service with two machines with more
> capable hardware which should make the web site more responsive.
Thank you Brian and Paride for continuously working to sustain and
evolve the autopkgtest infrastructure.
I'm sure you'll mostly get "hey why isn't it working" messages -
especially after a cycle starts things often feel slow and stuck.
So I wanted to make sure you know that we all are really happy to have
the system in place which couldn't work without you two, nor without
your invisible helpers nor without those people that worked on it
before.
Thanks, not just for re-hosting, but for keeping the service healthy in general!
> Additionally, I've modified the servers to return a 403 status code if
> one is trying to request a test and not logged in. This becomes
> particularly useful if you pass the output of
> retry-autopkgtest-regressions to curl instead of wget[1] e.g.
>
> $ ./retry-autopkgtest-regressions --log-regex "ERROR: testbed failure:
> cannot send to testbed" | vipe | xargs -rn1 -P10 curl --cookie
> ~/.cache/autopkgtest.cookie -o /dev/null --silent --head --write-out
> '%{url_effective}: %{http_code}\n'
> https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=s390x&package=node-imagemagick&trigger=graphicsmagick%2F1.4%2Breally1.3.38%2Bhg16870-1:
> 403
> https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=arm64&package=node-imagemagick&trigger=graphicsmagick%2F1.4%2Breally1.3.38%2Bhg16870-1:
> 200
>
> Unfortunately, I'm getting a surprising number of 403s and that is being
> tracked in a bug[1]. However, while we still need to sort out that bug I
> wanted to pass along the information about using curl so that you can
> tell more easily whether or not your test request was actually queued.
>
> [1]
> https://code.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/+git/ubuntu-archive-tools/+merge/434458
> [2] http://launchpad.net/bugs/1999584
>
> Cheers,
> --
> Brian Murray
>
> --
> 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
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
Re: VT console font
On Mon, Jul 18, 2022 at 2:57 PM Heinrich Schuchardt wrote: > > Thanks Daniel for bringing up this topic. > > We should choose a font that is easily legible on a 28" 4K monitor. Honestly this feels like one of those "you help one and at the same time make it worse for others" cases. Could we instead of changing the default make this dynamic based on the HW properties detected on install or any such? IIRC the Desktop team has some data [1] on HW specs present on install which could help to make such a decision. [1]: https://www.omgubuntu.co.uk/2018/02/ubuntu-data-collection-opt-out > Best regards > > Heinrich > > On Mon, Jul 18, 2022 at 2:36 PM Daniel van Vugt > wrote: >> >> I find myself increasing the VT console font size on practically all modern >> machines: >> >>sudo dpkg-reconfigure console-setup >> >> Is it perhaps time that Kinetic defaulted to a larger console font? >> >> - Daniel >> >> -- >> 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 -- 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
Re: pv (a pipeline progress indicator) in main?
On Fri, Apr 22, 2022 at 11:01 PM Seth Arnold wrote: > > On Fri, Apr 22, 2022 at 09:58:14AM -0700, Bryce Harrington wrote: > > LP page: https://launchpad.net/ubuntu/+source/pv > > > Or other considerations that need made before deciding? > > pv is popular in the OpenZFS communities for use with zfs send | zfs recv > -- as is mbuffer, which exists more to provide much larger buffering than > the usual libc stdio buffers. mbuffer doesn't have progress bars, but does > show throughput: > > $ dd if=/dev/urandom | mbuffer > /dev/null > in @ 32.5 MiB/s, out @ 32.5 MiB/s, 166 MiB total, buffer 0% full^C > 341133+0 records in > 341133+0 records out > 174660096 bytes (175 MB, 167 MiB) copied, 5.13954 s, 34.0 MB/s > mbuffer: warning: error during output to : canceled > summary: 167 MiByte in 5.1sec - average of 32.4 MiB/s > > One feature of pv that slightly worries me is that you can change the > parameters of an already-running instance by running it again, with -R: > >-R PID, --remote PID > If PID is an instance of pv that is already running, > -R PID will cause that instance to act as though it > had been given this instance's command line instead. > For example, if pv -L 123K is running with process ID > 9876, then running pv -R 9876 -L 321K will cause it to > start using a rate limit of 321KiB instead of 123KiB. > Note that some options cannot be changed while > running, such as -c, -l, -f, -D, -E, and -S. > > It's probably fine. (Afterall, it's possible to disable the yama sysctl > kernel.yama.ptrace_scope and attach a debugger to the process to modify > whatever you want.) But it's also possible it's not fine. Hi Seth, thanks for raising this, but I'd like to understand where in between "just raising an eyebrow" and "total blocker" this really is. The option only allows you to change those which are sane to change. And it is part of user-access control, you can't IPC an instance you have no control of e.g. a normal user can't change other users pv process. user -> root: pv: 498786: Operation not permitted To some extent I consider this nothing more than an advanced version of DD having SIGUSR1 to report progress output - and that never was a problem. I wonder, is everything with an IPC msgqeue a problem or is there something here that I do not yet see that makes this more affected? Could you outline what level of concern you have here - see the starting quote of "just raising an eyebrow" and "total blocker" . And if it is important - would trying to create any of the following help a lot to overcome your concerns?: a) something like the apparmor profile Thomas suggested? b) an opt-out option like "--no-remote - do not create IPC msgqueue for later change of arguments" c) it was just a hint and would not be a blocker > Thanks > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Christian Ehrhardt 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
Re: pv (a pipeline progress indicator) in main?
On Fri, Apr 22, 2022 at 11:56 PM Thomas Ward wrote:
>
> Generally speaking, could we not ship an apparmor profile with it in
> Ubuntu specifically to prevent default usage of -R and ptracing for the
> application?
>
> If so, then a default apparmor profile to prevent usage of -R (depending
> on how they do it) might be prudent.
The following would do, but since apparmor is an allow-list for mandatory access
that could end up reading weird unless there is a nice trick to
allow-all-but ...
audit deny signal (receive, send) peer=/usr/bin/pv set=("exists"),
> I can see this being useful in Main, provided it passes security review.
>
>
> Thomas
>
> On 4/22/22 17:00, Seth Arnold wrote:
> > On Fri, Apr 22, 2022 at 09:58:14AM -0700, Bryce Harrington wrote:
> >> LP page: https://launchpad.net/ubuntu/+source/pv
> >> Or other considerations that need made before deciding?
> > pv is popular in the OpenZFS communities for use with zfs send | zfs recv
> > -- as is mbuffer, which exists more to provide much larger buffering than
> > the usual libc stdio buffers. mbuffer doesn't have progress bars, but does
> > show throughput:
> >
> > $ dd if=/dev/urandom | mbuffer > /dev/null
> > in @ 32.5 MiB/s, out @ 32.5 MiB/s, 166 MiB total, buffer 0% full^C
> > 341133+0 records in
> > 341133+0 records out
> > 174660096 bytes (175 MB, 167 MiB) copied, 5.13954 s, 34.0 MB/s
> > mbuffer: warning: error during output to : canceled
> > summary: 167 MiByte in 5.1sec - average of 32.4 MiB/s
> >
> > One feature of pv that slightly worries me is that you can change the
> > parameters of an already-running instance by running it again, with -R:
> >
> > -R PID, --remote PID
> >If PID is an instance of pv that is already running,
> >-R PID will cause that instance to act as though it
> >had been given this instance's command line instead.
> >For example, if pv -L 123K is running with process ID
> >9876, then running pv -R 9876 -L 321K will cause it to
> >start using a rate limit of 321KiB instead of 123KiB.
> >Note that some options cannot be changed while
> >running, such as -c, -l, -f, -D, -E, and -S.
> >
> > It's probably fine. (Afterall, it's possible to disable the yama sysctl
> > kernel.yama.ptrace_scope and attach a debugger to the process to modify
> > whatever you want.) But it's also possible it's not fine.
> >
> > Thanks
> >
>
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
--
Christian Ehrhardt
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
Re: Second Jammy Jellyfish test rebuild
On Fri, Mar 25, 2022 at 3:24 PM Graham Inggs wrote: > > The latest report, dated 2022-03-25 14:05:01 UTC, no longer has broken > links to build logs that do not exist. Instead, '!Log' is shown for > these. Hi Graham, we've resolved all of our issues by now. I do not know if you need to get your list trimmed down, after all that will need you to build things again and sometimes resources are scarce. So this is an FYI for you if you want/need to trim the list via rebuilds/refreshes/deletions-form-your-ppa. We initially had more and fixed a few, but the currently remaining list holds 5 entries left for the server team: - Dns-root-data is actually an issue in ldns fixed in jammy-proposed by ldns https://launchpad.net/ubuntu/+source/ldns/1.7.1-2ubuntu4 You could consider a rebuild against proposed to get this one green. - postgresql-14 was broken by llvm-14, a fix is uploaded to jammy and built fine (https://launchpad.net/bugs/1966319) You can rebuild the very same, or if you have a less-overhead way to do it just consider this one as done. - python-tempita was broken by python-3.10, not yet fixed but we know a way - Note it’s an openstack package - not server anymore, but we wanted to fix it anyway. - https://launchpad.net/bugs/1966323 - https://bugs.launchpad.net/ubuntu/+source/python-tempita/+bug/1966532 - https://code.launchpad.net/~ahasenack/ubuntu/+source/python-tempita/+git/python-tempita/+merge/417740 - samba shows to build fine in the latter 0ubuntu4 - https://launchpad.net/ubuntu/+source/samba/2:4.15.5~dfsg-0ubuntu4 - consider to remove or rebuild it yourself to pick it up - Mysql is one of the !log cases - we didn't want to trigger a rebuild on our side just to ask you to do one again (wasted time) - instead could you please just rebuild that in your ppa as it should actually be good already I know I said 5, but as a bonus: - Ruby-rexml is fixed for a few days already before the report was sent. Please consider rebuilding all orange ruby* packages (reference LP: #1966201). -- Christian Ehrhardt 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
Re: Call for votes: Developer Membership Board restaffing
On Wed, Mar 23, 2022 at 12:06 PM Robie Basak wrote: > > The Developer Membership Board (DMB) has started a restaffing vote for > three vacant seats. The DMB is responsible for reviewing and approving > new Ubuntu developers. It evaluates prospective Ubuntu developers and > decides when to entrust them with developer privileges. There are five > candidates: > > William 'jawn-smith' Wilson (https://wiki.ubuntu.com/jawn-smith/RunningForDMB) > Brian Murray > Sebastien Bacher > Lucas Kanashiro > Utkarsh Gupta > > The vote closes on 2022-03-30 at approximately 18:00 UTC. > > As usual, the election is being run using the Condorcet Internet Voting > Service. All members of the ~ubuntu-dev team in Launchpad are eligible > to vote. However, recent changes to CIVS require you to *opt-in* to > using your email address to vote. You cannot receive a ballot until you > have opted in. Please opt in here: > > https://civs1.civs.us/cgi-bin/opt_in.pl > > You must use the same email address as the one I have collected for you > for your ballot. This is generally @ubuntu.com if that is an > alias that you have published in Launchpad publicly. More complicated > matching rules apply otherwise. If you are a member of ~ubuntu-dev and > are struggling to acquire your ballot, please contact me privately. I > may need to identify the email alias I am using for you directly. Thank you so much Robie for outlining all this in detail. Since I just activated mine, but needed to try a few addresses I wanted to describe how it looks. I hope it will help that everybody knows what to expect. If you happen to activate the "wrong" email you'll just see: ``` Email address successfully activated. ``` But if you activate the right one (just as Robie said, usually the @ubuntu.com one) you'd in the Web UI of CIVS right after clicking "Complete activation" see this: ``` Email address successfully activated. Pending poll invitations: Ubuntu Developer Membership Board restaffing ``` The latter line is a link leading you to your vote. > This announcement is being sent to a moderated announcement mailing > list. For discussion, Ubuntu developers should use > ubuntu-devel@lists.ubuntu.com. > > On behalf of the DMB, > > Robie > -- > ubuntu-devel-announce mailing list > ubuntu-devel-annou...@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce -- Christian Ehrhardt 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
Re: MIR question: upstream code in main pulled in code we have in universe
On Sat, Feb 12, 2022 at 1:42 AM Steve Langasek wrote: > > On Fri, Feb 11, 2022 at 01:43:31PM -0300, Andreas Hasenack wrote: > > On Fri, Feb 11, 2022 at 1:33 PM Steve Langasek > > wrote: > > > > On Fri, Feb 11, 2022 at 11:35:07AM -0300, Andreas Hasenack wrote: > > > > Hi, I have a question for the MIR (Main Inclusion Request) team members, > > > > > New version of nfs-utils upstream (src:nfs-utils in main) pulled[1] in > > > > code (regex.c file) from another upstream project[2], for which we > > > > have a package in universe: src:libnfsidmap-regex > > > > > Would this require another MIR review? I mean, in general, once a > > > > package is in main, we don't apply the MIR guidelines to it anymore, > > > > and they can usually change the code as the project sees fit. > > > > It just so happens this time we have this exact scenario where the > > > > code that was pulled already exists and is the sole purpose of > > > > another, universe, package. > > > > > My options are basically: > > > > a) have src:nfs-utils build bin:libnfsidmap-regex and remove > > > > src:libnfsidmap-regex from the archive > > > > b) build src:nfs-utils without producing bin:libnfsidmap-regex, and > > > > keep building src:libnfsidmap-regex from universe as usual > > > > > Option (b) will incurr in delta with debian. I believe[3] Debian will > > > > eventually remove/obsolete src:libnfsidmap-regex > > > > > 1. > > > > http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=940caffdfb9953a2ccfecec81664e4a179753461 > > > > 2. https://github.com/isginf/libnfsidmap-regex > > > > 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925022#20 > > > > I think you should submit it for an additional MIR review if and only if > > > there is reason to consider the new library security-sensitive. (If it's > > > a > > > library that will be used by one of the NFS daemons, that's a good reason > > > to > > > think it's security-sensitive.) > > > Yeah, it's an libnfsidmap plugin that applies regular expressions to > > NFSv4 usernames and group names that come over the wire in the form > > user@DOMAIN and group@DOMAIN. > > > What if I keep bin:libnfsidmap-regex, built from the new > > src:nfs-utils, in universe? With a remark in d/control that it should > > not be promoted to main without a specific new MIR? > > I think that's also acceptable. Indeed, if you have no dependency pulling it into main the binary can live in universe as it did before, just now built from another source. > -- > 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 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
Re: glibc 2.35 is coming to jammy
On Fri, Feb 4, 2022 at 2:04 AM Michael Hudson-Doyle wrote: > > Hello again, > > On Fri, 28 Jan 2022 at 10:47, Michael Hudson-Doyle > wrote: >> >> glibc 2.35 is due to be released next week and the plan is to get it into >> Ubuntu pretty soon after that. As usual, this will run a very large number >> of autopkgtests and so be a bit disruptive, but I'm not expecting enormous >> fallout from this update based on the testing we have done so far. Assuming >> things line up, I'll try to upload on my Friday so that the infrastructure >> can grind away over the weekend. > > > I've just uploaded the release to jamy. Hopefully all the tests will be done > by next week! Thanks Michael! Just in case anyone ran into a similar FTBFS due to 2.35 - it seems that something in poll has changed and combining "-O2 +LTO +libc 2.35" which now are all default in jammy-proposed can lead to breakage complaining like: error: ‘__poll_chk’ specified size between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=] For my case I've added a mitigation and reported it upstream, see [1]. But since FTFBS due to the new libc6 often follows a pattern and breaks many packages the same way I wanted to bring it up here for awareness. Maybe there is a better global fix for it or at least some people can save some time on debugging this issue. [1]: https://bugs.launchpad.net/open-vm-tools/+bug/1960224 > Cheers, > mwh > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Christian Ehrhardt 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
Re: Revisiting default initramfs compression
On Wed, Jan 26, 2022 at 4:18 PM Robie Basak wrote: > > It was noted in ubuntu-devel-discuss@ that changing the compression > method impacts Xen's use of pygrub. I thought that was worth mentioning > in this thread as something worth considering when making any decision. Agreed > > https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2022-January/019165.html Which for people who love bugs more than mailing list entries is [1]. [1]: https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1956166 > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Christian Ehrhardt 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
Re: First Jammy Jellyfish test rebuild
On Thu, Jan 13, 2022 at 12:58 PM Graham Inggs wrote: > > The first test rebuild of Jammy Jellyfish was started on December 17 > 2021 for all architectures, all components. The rebuild is finished > for all architectures for the main component and still running for > universe and multiverse on arm64, armhf and riscv64. > > Thanks to everybody keeping the buildds going during the end-of-year break. > > Results (please also look at the superseded builds) can be found at > https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20211217-jammy-jammy.html > > Additional build failures for packages in jammy-proposed (not yet in > jammy) can be found at http://qa.ubuntuwire.com/ftbfs/ > > Please help with fixing the build failures. > > Another test rebuild using a glibc snapshot from December 2021 can be found at > https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20211217-jammy-glibc-jammy.html > Still running for universe and multiverse on arm64, armhf and riscv64. > The glibc snapshot can be found in > https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/glibc > > Yet another test rebuild using GCC 12 can be found at > https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20211217-jammy-gcc12-jammy.html > Still running for universe and multiverse on arm64, armhf and riscv64. > This is in preparation for GCC 12 for the 22.10 release. GCC test > packages can be found in > https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test Hi Graham, thanks for that work! I've found two details I wanted to ask about ... 1. cross toolchains seem to have failed due to the dependencies in that test environment Example: https://launchpadlibrarian.net/579467210/buildlog_ubuntu-jammy-amd64.qemu_1%3A6.0+dfsg-2expubuntu4_BUILDING.txt.gz That is nothing we need to be concerend right, only if we see actual e.g. compiler issues right? 2. Some logs have broken hrefs, in the code it is like 'Log' and browsers render that as a link back to itself. Example: php8.0 risc64 with gcc12 $ wget -q https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20211217-jammy-gcc12-jammy.html -O - | grep -c 'Log' 92 $ wget -q https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20211217-jammy-glibc-jammy.html -O - | grep -c 'Log' 77 $ wget -q https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20211217-jammy-jammy.html -O - | grep -c 'Log' 49 The links to the builds are ok, and it seems they generated no log at all, example https://launchpad.net/ubuntu/+archive/test-rebuild-20211217-jammy-gcc12/+build/22817139 Maybe a fix to the script regenerating that might help to avoid confusion? > Happy New Year and bug fixing! > Graham > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Christian Ehrhardt 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
Re: Bumping the baseline on ppc64el in jammy to POWER9
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. > Matthias > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Christian Ehrhardt 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
How to make git-build-recipe find orig tarballs?
Hi,
I'm looking for experience or a hint on git-build-recipe.
I've worked on a recipe that uses git-ubuntu branches as the base like
# git-build-recipe format 0.4 deb-version {debversion}~{time}
https://git.launchpad.net/ubuntu/+source/postgresql-12 ubuntu/focal-devel
This might be extended with other branches for adaptations or backports,
but this isn't needed for the question I have here.
The problem is that a build without --allow-fallback-to-native will fail.
That is due to git-ubuntu having two pristine-tar branches (since they might
differ between Debian/Ubuntu).
Also git-build-recipe isn't just using the orig tarball from the archive
and ends up like:
$ git-build-recipe --no-build --distribution focal
recipes/postgresql-12-focal.recipe /tmp/testbuild/
...
pristine-tar: There's no local pristine-tar branch. Several remote
pristine-tar branches exist.
Run "git branch --track pristine-tar " to create a local
pristine-tar branch
ed778a9b05e89dc12aff034836655ab40d10da42
refs/remotes/source/importer/debian/pristine-tar
274809cadf2802b26b8a4dd2425d266447e4f5d6
refs/remotes/source/importer/ubuntu/pristine-tar
usage: git-build-recipe [-h] [--manifest PATH] [--if-changed-from
PATH] [--package PACKAGE] [--distribution DISTRIBUTION] [--no-build]
[--append-version APPEND_VERSION] [--safe]
[--allow-fallback-to-native]
LOCATION [WORKING-BASEDIR]
git-build-recipe: error: Unable to find the upstream source. Import
it as tag upstream/12.9 or build with --allow-fallback-to-native.
Note: I tried pushing a tag as the error message suggests, but it
didn't work for me.
So far (in all other recipes I had) this wasn't a problem, but I had to realize
that the way this --allow-fallback-to-native works will bump the time of all
files to the time that git-build-recipe ran.
And in postgresql case that became obvious as it started to rebuild things only
meant to be re-built when upstream creates a new tarball, but since the stamp
files were no more newer it now did and led to an FTBFS.
My question would be if anyone knows how to do either of:
a) Get it to use the tarball from the Ubuntu Archive
b) How to correctly push ie.g. tag (and where) so that git-build-recipe properly
recognizes and uses that as the upstream content
c) Specify the pristine-tar branch I want it to use
I have a (way too ugly) workaround for now and would appreciate any
hints on this topic.
--
Christian Ehrhardt
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
+1 Maintenance report
Hello, last week I was on +1 Duty, well I was supposed to :-/ Sadly many things tried to keep me away from it. After checking with Mclemenceau for that to be "ok", I still tried to get as much done as I could fit in between. This might only be worth maybe ~1.25day overall, but at least I was able to tackle a few things. ## Segyio [1] Vorlon left this bug from last weeks +1, but while starting to look at it I found Ginggs already had tackled that. I helped to ensure upstream is aware (for bonus confusion it is an embedded source in sigyio from catch2) and the bug status [1] is up to date to reflect all that. ## parlatype [2] FTBFS due to whitespace damage, reported to Debian [3] and filed as LP update-excuse bug [2]. Uploaded a fix to get it resolved for now and expecting it will become a sync later on. This fix migrated in Ubuntu with the fix and got merged into Debian. On the weekend the fix was uploaded to Debian including that and I synced the package again. ## nbd [4] I realized too late how young the age of the last upload was and had created and submitted two fixes already. This is pretty much WIP in Debian and uploaded to unstable every time. We can wait until it resolves there, and LP but tracking and explaining that was filed. As expected over the next few days it was resolved. Never look at too young uploads I guess. ## ldc [5] This was an FTBFS for almost two weeks and the reason is that the LDC project did not yet convert from the ORCv1 to the ORCv2 API for the jit compiler. Thereby it can't build with llvm >=12 which is our default. Build this against llvm-11 until upstream has resolved that (known issue for them). For Ubuntu I uploaded a fix to build with llvm-11 for not, but to really resolve this mid term I filed a bug with Debian outlining the backgrounds (considered experimental and to be dropped by upstream) and proposed a PR there to do so. Builds look good now, but it still hangs in the new queue of jammy. ## emscripten I looked into the TFBFS of this but it seemed flaky and failing for different reasons every time. Sometimes taking 10h to do so made it hard to debug and then I found that Debian still uploads more versions to fix similar (but not the same) test issues on their side. I think we need to let Debian settle this and once concluded there but still failing for us have another look. ## glew [7] I've found that glew is listed as blocking dependency 45 times. As usual the chain is long, there are: - vtk7 also wait on gdal, but that is only listed as it was recnetly build and waits to be published - vtk7 which has a test issue on armhf - rss-glx which FTBFS I've found rss-glx to be fixed in Debian [6] filed a LP tracker about it [7] rebased and uploaded a merge of that new version to resolve this issue. This worked fine and is at least one less to block glew. ## pg/post* [8] I have found that some universe packages around the wider postgres context have issues and thought I might be able to help those to get out of the way of other transitions which implicitly depend on them e.g. proj, pdal, pgrouting and indirectly even openssl. I did some debugging on a ppc64 host, but no matter which combination the issue was not reproducible there. So I eventually filed [8] to document the summary so far and brought it to the attention of the postgresql packagers if they recognize anything. [1]: https://bugs.launchpad.net/ubuntu/+source/segyio/+bug/1951658 [2]: https://bugs.launchpad.net/debian/+source/parlatype/+bug/1951833 [3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000388 [4]: https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/1951839 [5]: https://bugs.launchpad.net/ubuntu/+source/ldc/+bug/1951845 [6]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984322 [7]: https://bugs.launchpad.net/debian/+source/rss-glx/+bug/1951968 [8]: https://bugs.launchpad.net/ubuntu/+source/postgis/+bug/1952604 P.S. as usual I'm not listing the many small cases of retriggering with or without changed package sets. -- Christian Ehrhardt 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
Main inclusion requirement process - updated templates
Hello everyone, the MIR team has made the MIR process [1] easier and more consistent by updating the templates and rules. On one hand over the past initial MIR bugs were often inconsistent, with a wide variety of quality and content provided. On the other hand the MIR team used a newer template based approach for reviews over a year now and it standardized and improved our review quality. We were lucky to add a few new team members over the last years and introducing them pointed us to ambiguities and duplications. Combining these insights made us rework the sections for reporters and rules in the same way it was already successful for our review. While rewriting we removed those duplications, but also clarified many cases to outline what prep-work and content we expect. Furthermore in some cases we prepared common answers/best-practises to select from. To be clear, the actual requirements didn't really change, but the content we expect in a report is much more standardized now. All that will help consistency and avoid later delay due to back and forth caused by missing details. You will find all you need to request a MIR bug in [2] (same link as it always was) and if unsure a little guide how to use it in [3]. As TL;DR you reduce the template until all TODOs are resolved and the result is the content of the initial bug. [1]: https://wiki.ubuntu.com/MainInclusionProcess [2]: https://wiki.ubuntu.com/MainInclusionProcess?action=show&redirect=MIRTeam#Main_Inclusion_requirements [3]: https://wiki.ubuntu.com/MainInclusionProcess?action=show&redirect=MIRTeam#Templates_and_Rules -- Christian Ehrhardt 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
Re: eBPF support in HWE kernels + userland changes needed
On Wed, Nov 3, 2021 at 12:23 PM Rafael David Tinoco wrote: > > Hello list, > > I have been trying to address this issue for sometime now, without success. > Hopefully this can gain some traction with this e-mail. I know many of you > address most of your efforts into the current development version, but I'd > like to call attention for something I judge is important for the LTS > versions in the cloud world (regarding eBPF only). > > eBPF CO-RE technology [1][2] is becoming the base for cloud native > introspection / networking / performance tools, and many projects are > starting to use it. Examples I can remember off the top of my head are: > > - cilium > - inspektor gadget > - sysdig > - datadog agent > - tracee (the one I currently work with) > - sysmon tool for linux (does not need BTF but might in near future) > > But, because of LP #1926330, HWE kernels aren't enabling > CONFIG_DEBUG_INFO_BTF. > > After libbpf started supporting external BTF files (converted from DWARF), I > have created the following project: > > - https://github.com/aquasecurity/btfhub/ > > containing BTF files for all existing Ubuntu HWE kernels (and from other > distros) I could get. But now, -generic 5.11 HWE kernels don't have their > debug packages published (another bug I was told kernel team was already > aware). > > It's becoming very hard to help Ubuntu LTS to be eBPF CO-RE capable. All > other distros already are (as you can see at the btfhub README.md page). > > -- Problems: > > - #1 = Ubuntu HWE kernels aren't being compiled with BTF support, something > that is critical for eBPF CO-RE, turning an eBPF object portable among > different kernel versions. > > https://github.com/aquasecurity/btfhub/issues/9 > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1926330 > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1949286 Hi Rafael, glad to "see" you. It seems pahole is only a build time dependency to enable the kernel to be able to build this dwarf info. If it is indeed build-time only then it does not need to pass the MIR process. As long as the kernel team is happy with using it at build time to generate this extra data you should be fine. > My proposal to this problem is the "MIR" bug I created with a package called > "pahole-btf". It is a backport of Impish's dwarves "pahole" binary (only) to > Bionic and Focal. If this package is added to [main], then it will allow HWE > kernels to use a recent "pahole-btf" binary in vmlinux-link script and > generate correct BTF debug information for those kernels, allowing eBPF CO-RE > technology to work. > > Would that be acceptable ? If not, what is the alternative ? > > - #2 = Ubuntu HWE kernels should always have dbg packages published in ddebs. > What happened to 5.11 kernels ? Why can't we have access to the debug > packages ? > > Could I get some help/feedback in addressing those issues ? Thank you! > > > [1] https://nakryiko.com/posts/bpf-portability-and-co-re/ > [2] https://github.com/aquasecurity/btfhub/tree/main/tools > > rafaeldtinoco > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Christian Ehrhardt 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
Re: git-ubuntu rich history beta
On Wed, Oct 13, 2021 at 6:52 PM Robie Basak wrote: > Eventually I expect a high level CLI such as `git ubuntu submit` to do > all the work for you, but I want to get the low level stuff right first. Thanks for bringing this up, I personally really like the current prepare-upload as it neatly integrates with my common habits. But for wider acceptance such a higher level wrapper will feel more natural. > # Details of what the subcommands do > > There are two subcommands being added here: `git ubuntu prepare-upload > args` and `git ubuntu prepare-upload mangle`. Both will push the current > branch to a personal remote (defaulting to your personal Launchpad > namespace that `git ubuntu clone` sets up named after your Launchpad > username; details overridable with `--remote` and `--branch`). After > that, `args` will output the required additional changes file headers in > a form suitable for `dpkg-buildpackage`. `mangle` will instead replace > an existing changes file to add the headers, stripping the signature if > it was signed (as the alteration requires re-signing). > > # Details of the changes file headers > > * Vcs-Git: points to the git repository where the rich history can be >found. > > * Vcs-Git-Ref: the ref which when fetched contains the rich history. > > * Vcs-Git-Commit: the commit hash of your rich history. This must match >your upload. I did a few uploads with that, so far they all got detected well. But I only used args, not mangle. Out of that I have filed a few bugs, they will improve things but are no total show stoppers I'd like to have these being looked at: - fails more visible https://bugs.launchpad.net/usd-importer/+bug/1942865 - help users more if args/mangle was forgotten https://bugs.launchpad.net/usd-importer/+bug/1947138 - have less problems if non https:~/git https://bugs.launchpad.net/usd-importer/+bug/1942985 > When git-ubuntu imports your upload, it will look in the location -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On Sat, Oct 2, 2021 at 6:34 PM Steve Langasek wrote: > > +1 Maintenance, Sep 27-Oct 1 > ... > > xrdp: > a warning about unknown archs has been promoted to an error, causing build > failures on ppc64el and s390x. Without further analysis for correctness, > I've added ppc64el and s390x to the list of architectures not requiring > structure alignment, because this is how the package was built before, so > there is no regression. Patch forwarded to Debian for further evaluation. Hi, the further analysis of this has already happened in [1]. Real support was added in a later version and will be fully fixed by >=0.9.16. I had hoped that >0.9.16 would appear in Debian before FF, but 0.9.17 was the next upload and it was too late. But that means we can sync it next cycle and drop the delta that you added to mitigate it now. [1]: https://bugs.launchpad.net/ubuntu/+source/xrdp/+bug/1931225 ... -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
+1 Maintenance Report
This week Steve was also on +1 duty, which made me think the massive AA-needing tasks most likely will happen on his side anyway. Therefore I focused more on build/test fails. Unfortunately I must admit that I clearly wasn't able to find as much time for +1 as usually :-/ # openvswitch This was an armhf test fail [1] and while I wanted to look if it is reproducible I got a ping from schopin hinting at the right combined trigger as it was a known systemd issue. I Issues that and it TODO # libgphobos rebuild making cheesecutter & dub FTBFS I've seen rebuilds of those failing for essentially compiler errors (different issues for both packages, but the same across architectures). It pretty much looked the same way as it does when we build a new toolchain and since libgphobos is from gcc-* that might very much be what happens. I tried a local rebuild of those two and they reproduced the issue. It seems that really are just new toolchain issues. I quickly found fixes and rebuild to see if there are other issues. Then I checked if upstreams had new releases/patches in that regard. For dub that existed upstream [4], but also there is another issue in the package [5] which would block an upload and soon cause it to be removed [6]. Since the fix is applied in an already released version by upstream I think this does not need much more attention but time to sync the new builds - it isn't critical to impish to get the latest version. On the other hand it will be useful to document this in the open update-excuse bug so that others do not have to re-investigate this, so I added some info there. cheesecutter was rather similar, I found that this is a known and expected change as it is part of a set of deprecations scheduled for removal in 2018 [3]. The page holds hints how to replace this, but actually upstream has already a commit that fixes the problem [7]. I filed an update-excuse bug [8] and linked it to the related debian bug [9] as well as sending an FYI about the fix to the Debian bug. Given that this isn't blocking gcc we could just wait until Debian uploads a new git-snapshot with the fix included. Also the forwarded upstream issue needed a bump to realize bug and fix belong together. # umockdev 0.16.3 breaking bolt autopkgtest I analyzed this and eventually filed [10] for it. The TL;DR is that a test wants to created a mocked $tmp/sys/bus but the new umockdev auto-creates this on init, so the test fails as the dir already exists. Martin is the upstream and Debian maintainer and has to choose if this shall be fixed by partially reverting the offending commit or by adapting the test as I'm unaware of the context that triggered adding the change. The update-excuse bug will help to avoid re-analysis of the same case, but there is no urgency to fix this in Impish, we can wait until it resolves in Debian and sync it then. OTOH If a minimal fix is available early syncing it to impish would be nice, a lot will depend on the reply on those bugs. # mdbtools FTFBS on ppc64 This seemed to hang around so I fetched a ppc64 machine from maas and found it to be reproducible. I found a fix and upstreamed it via [12] as it was just a new gcc warning. LP bug [11] marked update-excuse as long as it wasn't complete and an upload of the upstream fix eventually resolved it. # Firewalld autopkgtest fail This looked interesting, but I failed to find time for it. Nevertheless there was already decent context due to the answers I got on my ping for potential prior activity on this. I Filed [13] to give anyone who will have a deeper look at this a head start. # Help Gladly this week Paride was so kind to help me and pick a few more +1 tasks. That way some more than what I managed to resolve got done. I assume he will reply to this thread with his own content he worked on this week. Thanks @paride! [1]: https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/armhf/n/netplan.io/20210927_104834_e5e17@/log.gz [2]: https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20210805-impish-impish.html [3]: https://dlang.org/changelog/2.075.0.html#pattern-deprecate [4]: https://github.com/dlang/dub/commit/aec94916cd856c662386bdea9038f19da27e457b [5]: https://bugs.launchpad.net/ubuntu/+source/dub/+bug/1915312 [6]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981229 [7]: https://github.com/theyamo/CheeseCutter/commit/68d6518f0e6249a2a5d122fc80201578337c1277 [8]: https://bugs.launchpad.net/debian/+source/cheesecutter/+bug/1945212 [9]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984009 [10]: https://bugs.launchpad.net/ubuntu/+source/umockdev/+bug/1945321 [11]: https://bugs.launchpad.net/ubuntu/+source/mdbtools/+bug/1945478 [12]: https://github.com/mdbtools/mdbtools/issues/352 [13]: https://bugs.launchpad.net/ubuntu/+source/firewalld/+bug/1945596 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd -- ubuntu-devel mailing list ubuntu-devel@l
+1 Maintenance report
. This was already brought up in April in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986488 but not handled since then. Note: This package is uncommon as it always runs the testsuite code and tests against the same other packages but NOT against a packaged pyspread. This happens because pyspread is not installed as dependency, only via the test that extracts it. Therefore it is not necessarily always testing what you think. For example you can not run the 1.99.6 test against the 1.99.5 binaries or vice versa. I found, debugged and fixed the broken testcase. I reported it and a fix upstream https://gitlab.com/pyspread/pyspread/-/issues/92 https://gitlab.com/pyspread/pyspread/-/merge_requests/36 I also bumped the Debian bug as FYI and filed a launchpad bug for other plus-one people to be aware of. Thanks to various people in #ubuntu-desktop for my journey through font-land. I uploaded the fix to Impish to resolve it but did not migrate for another issue this time on s390x due to big endian https://bugs.launchpad.net/ubuntu/+source/pyspread/+bug/1937162 I fixed that new test as well - it is not a new regression, only a new test coverage that was missed before. I also reported it upstream in case there is a deeper underlying issue that needs to be fixed. https://gitlab.com/pyspread/pyspread/-/issues/93 With both applied it migrated. # breezy / lintian-brush / breezy-debian I have actually looked at those last plus-one-duty that I was on. In the meantime https://bugs.launchpad.net/ubuntu/+source/lintian-brush/+bug/1931369 were fixed through https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989634 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988909 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989633 But that wasn't all it seems, the breezy-debian bug https://bugs.launchpad.net/ubuntu/+source/breezy-debian/+bug/1933034 now also affects lintian-brush at least in Ubuntu. It turns out that there are staged issues. First one would need to resolve the breezy 3.2.1 FTBFS https://bugs.launchpad.net/ubuntu/+source/breezy/+bug/1937173 Once that FTBFS is solved breezy-debian and lintian-brush can be rebuilt and will work. Then finally the tests of silver-platter, breezy-debian, breezy and lintian-brush all need to be re-triggered with combined triggers to each of them. The latter will then resolve bug 1933034. But as I said first of all the breezy FTBFS in bug 1937173 needs to be solved. I've done quite some debugging and documented it in the launchpad bug. My current working theory is that the newer python that is in Impish is not loading the test modules more than once. The tests are designed to load modules that have "raise exception..." and expect that to be processed. That works once, but not ever again - as if python would keep it in some cache and decide to "no I no more load that crap". I've tried to clear loaded python modules sys.modules.items / sys.modules.pop and also to make the module non-identical (in case they are hashed) but neither approach has worked. It is easily reproducible in e.g. a local sbuild but needs another pair of pythonic eyes that want to dive deeper into the behavior of __import__. This would be a great spot for next weeks +1 maintenance to continue on. -- Christian Ehrhardt 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
Re: Switching from fuse2 to fuse3 in main
On Wed, Jul 14, 2021 at 11:26 AM Graham Inggs wrote: > > Fuse3 is a requirement for qemu 6 [1]. To be fair, qemu needs it for a new nice-but-not-too-important feature, but it got the ball rolling and made us realize that also plenty of others like Gnome / KDE would like to see the transition to fuse3 happen. Also fuse upstream strongly encourages a change since 2019. So it is not just "because of qemu" as that could be debated-away by the feature being not too important. But overall it is an important enough change. BTW - thanks a lot Graham for driving this! > Since we don't want to support > two versions of fuse in main, we'd like reverse-dependencies of fuse > to switch to fuse3. > > A test rebuild of packages in main with a build-dependency on > libfuse-dev was done, switching the build-dependency to libfuse3-dev. > > The following packages do not require changes at this time: > > * ceph is compatible with fuse2 and fuse3 > * gvfs is compatible with fuse3, and carries a patch reverting to fuse2 > > * e2fsprogs builds fuse2fs, which is in universe > * libvirt builds libvirt-daemon-driver-lxc, which is universe > * ntfs-3g builds with an internal libfuse-lite > > Bugs have been filed for the following packages that need to be > adapted to build with fuse3: > > * grub2 / grub2-unsigned [2] > * open-vm-tools [3] > * s390-tools [4] > * snapd [5] > * xdg-desktop-portal [6] > > Please talk to upstreams and investigate what changes are required to > these packages, but please don't upload until all of the other > affected packages are ready. > Some references: fuse 3.0.0 changelog [7], changes made to ceph [8], > gvfs [9] and grub2 in OpenMandriva [10]. > > > [1] https://bugs.launchpad.net/ubuntu/+source/fuse3/+bug/1934510 > [2] https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1935659 > [3] https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1935665 > [4] https://bugs.launchpad.net/ubuntu/+source/s390-tools/+bug/1935666 > [5] https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1935667 > [6] https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal/+bug/1935668 > [7] > https://github.com/libfuse/libfuse/blob/master/ChangeLog.rst#libfuse-300-2016-12-08 > [8] > https://github.com/ceph/ceph/commit/cb0a600acfca76c5b4653e4c6f34c1712a2da9de > [9] > https://gitlab.gnome.org/GNOME/gvfs/-/commit/7a0a06186b6fef07b8fce2360c04fd075fc84ed1 > [10] > https://github.com/OpenMandrivaAssociation/grub2/blob/master/grub-2.02-fuse3.patch > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Christian Ehrhardt 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
+1 Maintenance report
]: https://github.com/neutrinolabs/xrdp/commit/3b81df3f9e894dd164f86d8cf87c3a171ced6d08 [12]: https://bugs.launchpad.net/ubuntu/+source/konclude/+bug/1931229 [13]: https://code.launchpad.net/~paelzer/britney/+git/hints-ubuntu/+merge/403885 [14]: https://bugs.launchpad.net/ubuntu/+source/cif2cell/+bug/1931260 [15]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989634 [16]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988909 [17]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989633 [18]: https://bugs.launchpad.net/ubuntu/+source/lintian-brush/+bug/1931369 [19]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989638 [20]: https://bugs.launchpad.net/debian/+source/qemu-web-desktop/+bug/1931375 [21]: https://code.launchpad.net/~paelzer/gdebi/gdebi-fix-glib-2.68/+merge/403954 [22]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989647 [23]: https://bugs.launchpad.net/debian/+source/gdebi/+bug/1931394 [24]: https://bugs.launchpad.net/ubuntu/+source/xindy/+bug/1931531 [25]: https://sourceforge.net/p/clisp/mailman/clisp-devel/thread/CAATJJ0KdgVUA6kb_QQVBVgFcKuyeCF_9Z4NcmVokfydhhYx3%2BQ%40mail.gmail.com/#msg37300059 -- Christian Ehrhardt 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
Re: +1 maintenance report
ready:
> https://foss.heptapod.net/pypy/pypy/-/commits/branch/rpython3/
>
> The pypy maintainer @tumbleweed is pretty active and suggested using the
> pycparser bundled with pypy, to avoid that dependency. Also, a python2.7
> source could be bundled with pypy to avoid that dependency as well, if
> need be
> (i.e. after src:python2.7 is removed).
>
> It builds fine without the python-pycparser build-dependency (for non
> 'stage1'
> build profiles, i.e. building with pypy with pypy itself). @tumbleweed
> wants to
> look into fixing the '--profile=stage1' bootstrapping build using the
> bundled
> pycparser.
>
>
> ### hyphy ###
>
> hyphy / 2.5.28+dfsg-3 autopkgtest failure on amd64
>
> The tests for this package crash with "Illegal instruction (core dumped)"
> ("Using /usr/lib/hyphy/bin/hyphy-avx"). I was not able to reproduce the
> issue
> locally in qemu, so this seems to be an infrastructure issue. The test
> first
> failed for the new "curl" upload, but I did a baseline test against
> "hello",
> which shows that this package regressed in -release, independently of
> "curl".
> The tests still pass on hirsute-release, tho. I'm not really sure how to
> continue here...
> Did something change wrt. the AVX instruction set on our amd64 test
> runners?
>
>
> ### nss (dogtag-pki) ###
>
> nss / 2:3.63-1ubuntu1 (vs dogtag-pki) autopkgtest failure on s390x
>
> This problem is unrelated to the s390x autopkgtest failures we had some
> while
> ago. The 389-ds-base patch (https://github.com/389ds/389-ds-base/pull/4573)
> is
> included in the 389-ds-base package. The dogtag-pki test passes if tested
> against "389-ds-base"; it passes if tested against "hello" (using old
> "nss");
> it fails when tested using the new "nss" (2:3.63-1ubuntu1).
> Looking into DebianCI, the new "nss" passes testing with "dogtag-pki" on
> s390x, tho. So this seems to be a real regression in nss 2:3.63-1ubuntu1,
> most
> probably inside the ubuntu delta itself.
> It's kind of hard to debug this right now, as Canonistack is still flaky,
> there
> is no proper access to s390x machines... Also, I'm running out of time, so
> this
> is something to pick up next time.
>
>
> ### TODO ###
>
> - Check back with @tumbleweed about the pypy/stage1 build
> - Figure out what changed wrt. AVX instruction set on the test runners
>
Hi Lukas,
There is no single "AVX instruction set", it actually consists of various
things introduced in different chip generations.
And what can be passed to the guest also depends on kernel and
qemu versions.
For a feeling of it look at `$ qemu-system-x86_64 -cpu ? | grep avx`
It is quite likely that your local test didn't have avx enabled at all.
My local autopkgtest for example specifies by default:
-cpu kvm64,+vmx,+lahf_lm
This default has no avx capabilities at all.
In a local autopkgtest you can pass qemu cpu options via:
-- qemu --qemu-options=
Unless you need to do things much more fine grained you could try
--qemu-options="-cpu host"
If still not locally reproducible, you might need to find a server with the
same chips as being used in the test infrastructure.
And you'd want to find the cpu spec that autopkgtest CPUs are run with
(this is an openstack, so there are
libvirt XMLs representing the guests and logs of the qemu commandling in
/var/log/libvirt/qemu/.log
Look for "-cpu ..." in there
- Verify the Ubuntu delta of nss 2:3.63-1ubuntu1 regressed on s390x
> (dogtag-pki)
>
>
> Cheers,
> Lukas
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
--
Christian Ehrhardt
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
Hirsute +1 Duty Report
new iperf. # 10 psmisc Being such a core package I was wondering that this hung in excuses for 28 days already. I found that it had a test at armhf "lost". It wasn't failed or passed, just non existing and from britney's POV it was waiting for the test result. I guess we'd want that new (minor) upstream release in Hirsute so I had a look. After re-issuing the test is succeeded and this became ready to migrate. #11 ddd This had build errors, but actually is an important rebuild from the hiccup that had created wrong permissions in built packages. Gladly this was a toolchain issue back then and now is resolved. => https://launchpad.net/ubuntu/+source/ddd/1:3.3.12-5.3build1 It might be worth to note that there are a few others left of that rebuild-burst that are still stuck in one or the other way: FTFBS: - https://launchpad.net/ubuntu/+source/clisp/1:2.49.20180218+really2.49.92-3build5 - https://launchpad.net/ubuntu/+source/nng/1.4.0-1build1 Test fails: - https://launchpad.net/ubuntu/+source/gnome-activity-journal/1.0.0-3build1 - https://launchpad.net/ubuntu/+source/php-apcu/5.1.19+4.0.11-3build1 - https://launchpad.net/ubuntu/+source/ruby-httpclient/2.8.3-2build1 I was out of time, but I'd guess that one also should look after those? -- Christian Ehrhardt 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
Re: glib2.0 causing some build errors in Hirsute
On Tue, Feb 23, 2021 at 3:38 PM Christian Ehrhardt
wrote:
>
> Hi,
> this is an FYI in case other packages FTBFS as well (in my case qemu)
> in Hirsute-proposed.
> There is a change in libglib2.0-dev 2.66.4-1 to 2.67.4-1 which makes
> it break build if it is included in an "extern C" context.
>
> That is discussed upstream https://gitlab.gnome.org/GNOME/glib/-/issues/233
Works even better if I'd have copy-pasta'd the full link which is:
https://gitlab.gnome.org/GNOME/glib/-/issues/2331
> The TL;DR is no mitigation will be applied, but in turn that means we
> need to fix all problematic packages in Hirsute to avoid becoming an
> FTBFS.
>
> Remember this case if you see build issues like:
>
> ../../disas/arm-a64.cc
> In file included from /usr/include/glib-2.0/glib/gmacros.h:241,
> from
> /usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h:9,
> from /usr/include/glib-2.0/glib/gtypes.h:32,
> from /usr/include/glib-2.0/glib/galloca.h:32,
> from /usr/include/glib-2.0/glib.h:30,
> from /<>/qemu-5.2+dfsg/include/glib-compat.h:32,
> from /<>/qemu-5.2+dfsg/include/qemu/osdep.h:126,
> from ../../disas/arm-a64.cc:21:
> /usr/include/c++/10/type_traits:56:3: error: template with C linkage
>56 | template
> | ^~~~
> ../../disas/arm-a64.cc:20:1: note: ‘extern "C"’ linkage started here
> 20 | extern "C" {
> | ^~
>
> Thanks Doko for debugging with me and Laney to point to the upstream issue.
>
> --
> Christian Ehrhardt
> Staff Engineer, Ubuntu Server
> Canonical Ltd
--
Christian Ehrhardt
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
glib2.0 causing some build errors in Hirsute
Hi,
this is an FYI in case other packages FTBFS as well (in my case qemu)
in Hirsute-proposed.
There is a change in libglib2.0-dev 2.66.4-1 to 2.67.4-1 which makes
it break build if it is included in an "extern C" context.
That is discussed upstream https://gitlab.gnome.org/GNOME/glib/-/issues/233
The TL;DR is no mitigation will be applied, but in turn that means we
need to fix all problematic packages in Hirsute to avoid becoming an
FTBFS.
Remember this case if you see build issues like:
../../disas/arm-a64.cc
In file included from /usr/include/glib-2.0/glib/gmacros.h:241,
from /usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h:9,
from /usr/include/glib-2.0/glib/gtypes.h:32,
from /usr/include/glib-2.0/glib/galloca.h:32,
from /usr/include/glib-2.0/glib.h:30,
from /<>/qemu-5.2+dfsg/include/glib-compat.h:32,
from /<>/qemu-5.2+dfsg/include/qemu/osdep.h:126,
from ../../disas/arm-a64.cc:21:
/usr/include/c++/10/type_traits:56:3: error: template with C linkage
56 | template
| ^~~~
../../disas/arm-a64.cc:20:1: note: ‘extern "C"’ linkage started here
20 | extern "C" {
| ^~
Thanks Doko for debugging with me and Laney to point to the upstream issue.
--
Christian Ehrhardt
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
Re: General mechanism to supply "rich history" to git-ubuntu
On Tue, Feb 2, 2021 at 4:56 PM Robie Basak wrote: > > On Tue, Feb 02, 2021 at 10:48:07AM -0500, Scott Moser wrote: > > I think this is great. I think it is a game-changer for ubuntu development. > > Thank you. > > Thanks! I have discussed this with you before and also like it very much - thanks for all your work on this! > > In your example above, the 'refs/heads/test' has to exist (and to have the > > referenced commit) in order for the importer to find it. > > > > So the uploader would then have to not delete or force-push that reference > > until some point in the future, right? > > > > My only concern here is that I already have way too many branches > > that I've pushed. This will just leave more manual maintenance for me > > to not clean up these branches until the upload that references > > them is landed. > > > > Did I undestand that correctly? > > Correct. At the time the importer runs, it needs to be able to fetch a > ref from somewhere. If you push to a personal branch and use that ref, > then it'll need to exist until git-ubuntu has caught up with your > upload. Right now the time varies, is commonly an hour or two, but > sometimes has been a week. Over time, I hope for us to get more reliable > with it (this requires infrastructure, monitoring, etc). > > I'm not really sure how to avoid this requirement. > > Another approach you could take is to maintain a team repository and > branch somewhere. Then all your uploads could be "from" a single main > branch, which would then persist by its nature. The following just came to my mind, I haven't thought it through for hours, so I'm sharing it with some disclaimer attached :-) I think there is a chance if someone has a "next" or "for-upload" branch that it might be recycled and no longer match on import. But IMHO we could synthesize a branch name in the wrapper and push to that one. Example: 1. user works on his branch called "cool-new-feature" (that would change) 2. user decides to upload, and calls the wrapper 3. the wrapper synthesizes a new branch name like --<$date/time> => git-ubuntu-upload-cool-new-feature-03012021085107 and push this one. 4. the synthesized name is referenced in the tags and used by the importer It is unlikely (unless intentional) that this branch is force pushed before the import happens. But it has the downside of a potential proliferation of pushed branches, but TBH providing a "remove all merged branches" command should not be too hard. If we spin this forward (And ACS for it work out) we could push it to a special namespace in the actual per package git ubuntu repositories. And maybe add some UUID to the synthesized branch name (for multi-user de-collision). The ACS would need to allow that no "normal" user can force push, but nearly everyone (with a LP user) can push their branches. In that repository, the importer could do auto-remove-after-import and proliferation would not happen in the users repository anymore. > I guess you could sort of do that with a personal repository, too, if > you wanted. Maintain a "for-upload" branch, always push there, and then > forget about it until you reuse it next time. > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Christian Ehrhardt 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
+1 Duty Report
ests belong to src:octave-parallel It was already triggered by several people with custom triggers around other octave-* things like: octave/6.1.1~hg.2020.12.27-3 octave-parallel/4.0.0-2build1 octave-struct/1.0.16-8 Unfortunately if you just install things in hirsute or debian-sid the test works fine. So much for debugging. But OTOH on autopkgtest.ubuntu.com it keeps failing even with all-proposed. Upgrading from manual tests to autopkgtest but in local VMs works for hirsite as-is as well as hirsute-proposed and a selection of just octave,octave-parallel,octave-struct. Worth to note, on armhf this worked just fine on autopkgtest.u.c The debugging of this went on and on - so I created a bug to track what I've found to share it with other debuggers and be visible due to the update-excuse tag. => https://bugs.launchpad.net/ubuntu/+source/octave-parallel/+bug/1911400 I had some fun debugging this and after some TIL and a long strange trip it turned out to be rather easy. This is a lib for parallelization and in the new version it fails on 1 vcpu - so it needs to be marked as big_package. Nevertheless - since it is a regression from our POV - I also filed an upstream bug about it. => https://savannah.gnu.org/bugs/index.php?59869 The MP to mark it as huge is here: => https://code.launchpad.net/~paelzer/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/396300 After that was merged I did some custom triggers to get the set of packages tested together as needed. And I checked the test log if they used the new instance - they did and results finally went good unblocking many other things that were indirectly linked. Just when I thought things were happy I got told that a new dependency came in. Thanks for shattering my hopes Rick :-P. This was an installability issue on riscv64 between nheko/fmtlib which was taken care of by vorlon/Rik/Gianfranco while it was nighttime for me. But this story seems to continue. After that was resolved a new plasma-workspace joined the entanglement party. But finally at the end of this week all of those bits moved in the next run of britney. \o/ # dune-* FTFBS A bunch of dune-* packages were blocked on one of them failing to build. The reason was an unclear segfault that seemed to be flaky. I found that Locutus has already uploaded a delta to "Reduce parallelism to 3 in arm64" only to now have it fail on armhf and ppc64. I didn't reach him, so I gave things a try in a PPA if that change would help all architectures. But it still failed with that change (flaky, not 100%). Rebuilds as-is fail (2/2) and lowering the parallel on all arch does not fix armhf (which formerly built fine). This really seems to be a huge flaky-fest or a situation that got worse with recent toolchains. To crank it up a bit I was doing various other test builds but all of them were flaky. In a discussion on #ubuntu-release the last theory was that (other than retrying forever) using gcc-9 might help as it did in other cases. ... it feels like not that much as usual, but still progress being made at least. See you next week. -- Christian Ehrhardt 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
Re: +1 maintenance report
On Mon, Jan 11, 2021 at 4:53 PM Steve Langasek wrote: > > +1 maintenance shift Thursday and Friday, 7-8 Jan 2021. > > I took a look at the libjsoncpp transition. > > - opendht failed to build, but builds fine in sid and also built fine in a >hirsute chroot, so I've given the build back on all archs and it's >built/building successfully now. > - scanning update_excuses for other packages linked to libjsoncpp, I >spotted that waybar depends on both libjsoncpp and on spdlog, which was >not a candidate because it was dep-wait on i386. I fixed up the i386 >whitelist to include liblist-more-utils-xs-perl, which has now built, so >in theory this will unblock soon. > - also linked to digikam via opencv; digikam has a new build-dependency on >qtwebengine5-dev, which is only available on x86 / arm, so I removed the >ppc64el/s390x/riscv64 binaries from the release pocket to let this >migrate. > - and to gst-plugins-bad1.0 via opencv, which seems to have a build failure >on ppc64el and s390x due to a segfault in gst-plugin-scanner and in >gst-codec-info-1.0; reproducible on s390x in a built tree with >`/usr/lib/s390x-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-codec-info-1.0 > > debian/gstreamer1.0-plugins-bad/usr/lib/s390x-linux-gnu/gstreamer-1.0/libgstlv2.so` >but haven't had time yet to diagnose and resolve. A backtrace is: Hi Steve, I started to look into that as well today and got as far as you did (identifying libgstlv2.so). I also pinged ubuntu-desktop and it didn't ring any bell being a known issue there. The failing bits of gst-plugins-bad1.0 are the same that worked a few weeks before, so I started trying to identify the component that brought the change - with suspects like libgstreamer1.0-0 1.18.2-1build1 -> libgstreamer1.0-0 1.18.0-3. I'm still on +1, so I'll continue on that tomorrow. > Program received signal SIGSEGV, Segmentation fault. > 0x4ee6 in ?? () > (gdb) bt > #0 0x4ee6 in ?? () > #1 0x03fffdf8527e in plugin_cleanup (plugin=) > at ../ext/lv2/gstlv2.c:381 > (gdb) Might I ask how you've got to plugin_cleanup - in my case it looks like the following stack. (Which seems to indicate memory is clobbered as the main function fully completes and then on return hell breaks loose) (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49 #1 0x03fffd9aaa88 in __GI_abort () at abort.c:79 #2 0x03fffd9c1896 in __assert_fail_base (fmt=, assertion=assertion@entry=0x3fffd00a382 "frame->node", file=file@entry=0x3fffd00a1c8 "../src/zix/btree.c", line=line@entry=716, function=function@entry=0x3fffd00a7f0 "zix_btree_get") at assert.c:92 #3 0x03fffd9c190e in __GI___assert_fail (assertion=0x3fffd00a382 "frame->node", file=0x3fffd00a1c8 "../src/zix/btree.c", line=, function=0x3fffd00a7f0 "zix_btree_get") at assert.c:101 #4 0x03fffd005148 in sord_free () at /lib/s390x-linux-gnu/libsord-0.so.0 #5 0x03fffd292168 in lilv_world_free () at /lib/s390x-linux-gnu/liblilv-0.so.0 #6 0x03fffdf9363e in () at /lib/ld64.so.1 #7 0x03fffd9ce256 in __run_exit_handlers (status=, listp=0x3fffdb4d540 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108 #8 0x03fffd9ce3f0 in __GI_exit (status=) at exit.c:139 #9 0x03fffd9aadd4 in __libc_start_main (main= 0x2aa1d20 , argc=, argv=0x3fff328, init=, fini=, rtld_fini=0x3fffdf93410, stack_end=0x3fff270) at libc-start.c:348 #10 0x02aa2aa4 in _start () > -- > 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 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
Re: Workaround for broken qemu-system-gui upgrade in Hirsute until 5.1+dfsg-4ubuntu3 lands
On Mon, Nov 30, 2020 at 4:31 PM Christian Ehrhardt wrote: > > Hi, > if you are upgrading packages in hirsute as of today you might see a > fail for the package qemu-system-gui. If you are not, be happy and > feel free to close this mail :-) > > But if you are affected I first need to say sorry. Furthermore I > wanted to let you know that it is some unfortunate fallout of the > merge of qemu 5.1 which first triggered [2] for qemu-block-extra > (already fixed) and now [3] qemu-system-gui (similar but different). > > Of course you can just wait for [1] to land in hirsute and upgrades > will work again without you having to do any else. But if you just > want to unblock your upgrades asap you should know that this issue is > only on the upgrade path when running the .prerm of the currently > installed version. > Therefore here a few manual workarounds that you could consider: > > Workaround #1 - uninstall and install > $ apt remove qemu-system-gui > # the remove will complain the same way as the upgrade, but an install > # of the new version over this state "rH" works. > # You most likely had this installed through qemu-system-x86 > # so remember to re-install dependency removed packages as well: > $ apt install qemu-system-x86 qemu-system-gui > > Workaround #2 - use repackaged 5.1+dfsg-4ubuntu1 (If you can't remove > qemu* packages for some reason) > # replace original 5.1+dfsg-4ubuntu1 with one that does not have the prerm > issue > $ wget > https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1906245/+attachment/5439620/+files/qemu-system-gui_5.1+dfsg-4ubuntu1_amd64.repackaged.lp1906245.deb > $ dpkg -i qemu-system-gui_5.1+dfsg-4ubuntu1_amd64.repackaged.lp1906245.deb > # upgrade to 5.1+dfsg-4ubuntu2 (now working) > $ apt install qemu-system-gui > > Workaround #3 - use the PPA version > $ sudo add-apt-repository ppa:ci-train-ppa-service/4356 > $ apt install qemu-system-gui > # or > $ apt install upgrade > # This will need libgdk-pixbuf-2.0-0 from proposed thou And if 3 isn't a charm for you, you can as well remove the bad lines from the old prerm and then upgrade: Workaround #4 $ sed -i -e '/Debian 1:5.1+dfsg-4ubuntu1/d' /var/lib/dpkg/info/qemu-system-gui*.prerm $ apt install qemu-system-gui > [1]: https://launchpad.net/ubuntu/+source/qemu/1:5.1+dfsg-4ubuntu3 > [2]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1905377 > [3]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1906245 > > -- > Christian Ehrhardt > Staff Engineer, Ubuntu Server > Canonical Ltd -- Christian Ehrhardt 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
Workaround for broken qemu-system-gui upgrade in Hirsute until 5.1+dfsg-4ubuntu3 lands
Hi, if you are upgrading packages in hirsute as of today you might see a fail for the package qemu-system-gui. If you are not, be happy and feel free to close this mail :-) But if you are affected I first need to say sorry. Furthermore I wanted to let you know that it is some unfortunate fallout of the merge of qemu 5.1 which first triggered [2] for qemu-block-extra (already fixed) and now [3] qemu-system-gui (similar but different). Of course you can just wait for [1] to land in hirsute and upgrades will work again without you having to do any else. But if you just want to unblock your upgrades asap you should know that this issue is only on the upgrade path when running the .prerm of the currently installed version. Therefore here a few manual workarounds that you could consider: Workaround #1 - uninstall and install $ apt remove qemu-system-gui # the remove will complain the same way as the upgrade, but an install # of the new version over this state "rH" works. # You most likely had this installed through qemu-system-x86 # so remember to re-install dependency removed packages as well: $ apt install qemu-system-x86 qemu-system-gui Workaround #2 - use repackaged 5.1+dfsg-4ubuntu1 (If you can't remove qemu* packages for some reason) # replace original 5.1+dfsg-4ubuntu1 with one that does not have the prerm issue $ wget https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1906245/+attachment/5439620/+files/qemu-system-gui_5.1+dfsg-4ubuntu1_amd64.repackaged.lp1906245.deb $ dpkg -i qemu-system-gui_5.1+dfsg-4ubuntu1_amd64.repackaged.lp1906245.deb # upgrade to 5.1+dfsg-4ubuntu2 (now working) $ apt install qemu-system-gui Workaround #3 - use the PPA version $ sudo add-apt-repository ppa:ci-train-ppa-service/4356 $ apt install qemu-system-gui # or $ apt install upgrade # This will need libgdk-pixbuf-2.0-0 from proposed thou [1]: https://launchpad.net/ubuntu/+source/qemu/1:5.1+dfsg-4ubuntu3 [2]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1905377 [3]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1906245 -- Christian Ehrhardt 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
+1 maintenance report
esql-13 eventually. Also in Debian after checking with the maintainer the preferred option seems to be a removal from -testing [32]. I'm concerned about removing too much of hirsute if we remove postgresql-12 now. Therefore I'll go ahead of Debian an upload the stable release of v12 today which will fix the issue for v12 for now (still to be later in the cycle removed).. So in addition to waiting for 13.1 to show up via auto-sync I prepared all other stable updates as well which also cover a bunch of CVEs for the supported releases [35] and the build/test fail filed by rbalint [36]. 13.1-1 as synced from Debian built fine as expected, so did 12.5 in a PPA which I then uploaded. Together with security I'm preparing the same stable updates for all active releases but that will be next week (not part of the +1 duty). Finally plenty of postgresql related tests failed in the past as they need to be triggered together to work. I have done that over the weekend (once the new builds were in) to get this closer to migrate. # 15 ebtables breaking tests While trying to look at libvirt for perl (see above) I have early on identified an issue with iptables/ebtables that turned out to be broken not only in hirsute but also in groovy. An initial quick check confirmed that it was not my new libvirt version nor the hirsute release at all. So this was worth an investigation if we might have general issue. A discussion with security showed that the issue could match the merge of 1.8.5 and/or the whole iptables/ebtables/nftables move. I was tracking down which component causes this and then filed a bug [39]. Although I have to admint it feels like my ebtables-foo might just be too weak, but then it will be TIL moment once explained :-) While I found the issue on +1 duty after the initial analysis it became clear that the task isn't qualifying for +1 so I'll continue on it next week (in the context of libvirt which we want to have for perl anyway). [1]: https://lists.debian.org/debian-devel-announce/2020/11/msg1.html [2]: https://people.canonical.com/~ubuntu-archive/germinate-output/i386.hirsute/i386+build-depends [3]: https://wiki.ubuntu.com/i386 [4]: https://launchpadlibrarian.net/504480967/buildlog_ubuntu-hirsute-amd64.trilinos_12.14.1-5_BUILDING.txt.gz [5]: https://launchpadlibrarian.net/504427600/buildlog_ubuntu-hirsute-arm64.trilinos_12.14.1-5_BUILDING.txt.gz [6]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973825 [7]: https://launchpad.net/ubuntu/+source/dolfin/2019.2.0~git20200629.946dbd3-4 [8]: https://autopkgtest.ubuntu.com/packages/libf/libftdi1/groovy/i386 [9]: https://ci.debian.net/packages/libf/libftdi1/testing/i386/ [10]: https://code.launchpad.net/~paelzer/britney/+git/hints-ubuntu/+merge/393500 [11]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946577 [12]: https://paste.ubuntu.com/p/6VDFJmSTf6/ [13]: https://code.launchpad.net/~paelzer/britney/+git/hints-ubuntu/+merge/393501 [14]: https://bugs.launchpad.net/ubuntu/+source/gkrellm2-cpufreq/+bug/1891336 [15]: https://bugs.launchpad.net/ubuntu/+source/cpufreqd/+bug/1215411o [16]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974136 [17]: https://bugs.launchpad.net/debian/+source/netgen/+bug/1903719 [18]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974137 [19]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966014 [20]: https://code.launchpad.net/~paelzer/britney/+git/hints-ubuntu/+merge/393558 [21]: https://buildd.debian.org/status/fetch.php?pkg=clustalo&arch=s390x&ver=1.2.4-6&stamp=1589135789&raw=0 [22]: https://launchpadlibrarian.net/498532550/buildlog_ubuntu-groovy-s390x.clustalo_1.2.4-6_BUILDING.txt.gz [23]: https://salsa.debian.org/med-team/clustalo/-/merge_requests/1 [24]: https://bugs.launchpad.net/ubuntu/+source/clustalo/+bug/1903817 [25]: https://github.com/axboe/fio/issues/1065 [26]: https://github.com/axboe/fio/commit/fd56c235caa42870e6dc33d661514375ea95ffc5 [27]: https://github.com/axboe/fio/issues/1123 [28]: https://salsa.debian.org/debian/fio/-/merge_requests/6 [29]: https://bugs.launchpad.net/ubuntu/+source/fio/+bug/1903963 [30]: https://bugs.launchpad.net/ubuntu/+source/fio/+bug/1903962 [31]: https://code.launchpad.net/~paelzer/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/393641 [32]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974061 [33]: https://buildd.debian.org/status/fetch.php?pkg=postgresql-13&arch=amd64&ver=13.1-1&stamp=1605173772&raw=0 [34]: https://launchpad.net/ubuntu/+source/postgresql-13/13.1-1 [35]: https://bugs.launchpad.net/ubuntu/focal/+source/postgresql-12/+bug/1903978 [36]: https://bugs.launchpad.net/ubuntu/+source/postgresql-12/+bug/1903573 [37]: https://salsa.debian.org/debian/tgt/-/merge_requests/1 [38]: https://salsa.debian.org/linux-blocks-team/multipath-tools/-/merge_requests/1 [39]: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1904192 -- Christian Ehrhardt 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
Re: Hirsute opening status?
On Mon, Oct 26, 2020 at 11:20 PM Sebastien Bacher wrote: > Hey there, > > Before the focal cycle we had an archive opening summary email [1], I > personally found it useful to have an idea what are the next steps, > could we try to make that maybe a regular thing and part of the new > cycle opening? > > Currently the Hirsute serie seems ready but yet uploads aren't accepted, > is there particular things that need to be sorted out? Hi Sebastien, I'm in no way denying the usefulness of such a mail, but as a hint for self-checking the state I can recommend to look at the release pages like [1] and avoid uploading before the status "Pre-release Freeze" is gone there. [1]: https://launchpad.net/ubuntu/hirsute > How long do we > expect that to take and is help needed? > > Thanks, > Sebastien Bacher > > [1] > https://lists.ubuntu.com/archives/ubuntu-devel/2019-October/040817.html > > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- Christian Ehrhardt 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
Re: Second Groovy Gorilla test rebuild
On Tue, Sep 29, 2020 at 11:07 AM Christian Ehrhardt wrote: > > On Mon, Sep 28, 2020 at 9:39 PM Sebastien Bacher wrote: > > > > Hey Matthias, > > > > Le 28/09/2020 à 18:07, Matthias Klose a écrit : > > > Some build failures on ppc64el and s390x are caused by a buildd issue, > > > and will > > > be retried soonish. Please ignore these where you see a ftbfs just on > > > those > > > architectures, but successes on the other architectures. > > > > There seems to be some flakyness on arm as well, are those going to be > > retried or should that be requested by e.g pinging you? > > > > Some examples > > > > https://launchpadlibrarian.net/499016257/buildlog_ubuntu-groovy-armhf.colord-gtk_0.2.0-0ubuntu1_BUILDING.txt.gz > > https://launchpadlibrarian.net/499209776/buildlog_ubuntu-groovy-arm64.gpm_1.20.7-6_BUILDING.txt.gz > > https://launchpadlibrarian.net/499174464/buildlog_ubuntu-groovy-arm64.remmina_1.4.8+dfsg-1ubuntu1_BUILDING.txt.gz > > Adding the same armhf dependency issue on these: > htop: > https://launchpadlibrarian.net/499078378/buildlog_ubuntu-groovy-arm64.htop_3.0.2-1_BUILDING.txt.gz > openvpn: > https://launchpadlibrarian.net/499161991/buildlog_ubuntu-groovy-armhf.openvpn_2.4.9-3ubuntu1_BUILDING.txt.gz > I see that Laney already filed a bug about that with IS. > > Furthermore some armhf issues are due to > https://bugs.launchpad.net/ubuntu/+source/gcc-10/+bug/1890435 > php7.4: > https://launchpadlibrarian.net/499168409/buildlog_ubuntu-groovy-armhf.php7.4_7.4.9-1ubuntu1_BUILDING.txt.gz > > When doing an initial triage of some errors I found three sets of > recurring issues: > 1. rpc includes like "rpc/rpc.h: No such file" > 2. better null checking like " -Werror=nonnull" or "directive argument is > null" > 3. linker shows "multiple definitions of" Just as FYI to save you some debugging, common issue #3 is due to gcc now defaulting to -fno-common Most of the time that is due to missing "extern" declarations and the fix is to add them. This even is the first entry on [1] Porting to GCC 10 page. But there is one more case which is less clear than missing "extern", Defines that are meant to be linked together like the following also trigger it: #define __shared __asm__ ( "_shared_bss" ) __aligned The fix here is to add back -fcommon for such. [1]: https://gcc.gnu.org/gcc-10/porting_to.html > #2 likely comes down to fixing code or disabling the warning for now. > But for #1 and #3 I think there is a general change and every affected > package likely will need the similar fix. > So if someone already debugged those it would be great to let the others know. > > > > Cheers, > > Sebastien Bacher > > > > > > > > -- > > ubuntu-devel mailing list > > ubuntu-devel@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > > > -- > Christian Ehrhardt > Staff Engineer, Ubuntu Server > Canonical Ltd -- Christian Ehrhardt 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
Re: systemd PathExists triggers
On Wed, Sep 30, 2020 at 7:43 PM Brian Murray wrote: > > Recently there was a systemd change regarding PathExists for > systemd.path units that made systemd behave the way it was documented to > work. The effect being that if the PathExists or PathExistsGlob > condition is met the service is continually started which may not be the > behavior some packages expect as it didn't used to work that way. > > As an example apport's autoreport service uses PathExistsGlob to check > for a .crash file and then calls whoopsie-upload-all which used to run > once when the .crash file appeared. As of Groovy whoopsie-upload-all was > called continuously thereby causing systemd to use 100% of your CPU[1]. > > While this is resolved for apport's case, the Foundation's team thought > it was worth mentioning as other package's services may also be > impacted. Thanks Brian for your warning! I see in your list some .path files e.g. the aforementioned apport-autoreport.path that I understand if using a PathExist* will have changed. Of those the list [2] contains 9 to look at. I beg your pardon, but the list is vast due to including any "Type=oneshot" as well. And from the summary you gave I don't see why those are included as well. Looking at the first in the list that probably everyone has installed I see: a) /lib/systemd/system/alsa-restore.service there are no associated .path files, only ConditionPathExists in the unit itself - are those also affected? b) Looking slightly further /lib/systemd/system/apt-daily.service even has no associated .path nor any *Exist* statement. My question would now be - are those files of type (a) or (b) all also affected in some way or is the "critical list" actually much shorter? I was wondering if you could help to clarify before everyone that feels responsible for a package with a file in that list is diving into and re-understanding the case. Thanks in advance, Christian > An archive search[2] (thanks Seth!) was done of services which are > Type=oneshot or utilize a PathExists or PathExistsGlob. Briefly scanning > the list the following packages should probably be looked at: > > mandos-client > ostree > python-diskimage-builder > ubuntu-report > > [1] http://launchpad.net/bugs/1891657 > [2] https://paste.ubuntu.com/p/k5Gj7rQ9FX/ > > Cheers, > -- > Brian Murray > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Christian Ehrhardt 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
Re: Second Groovy Gorilla test rebuild
On Tue, Sep 29, 2020 at 11:07 AM Christian Ehrhardt wrote: > > On Mon, Sep 28, 2020 at 9:39 PM Sebastien Bacher wrote: > > > > Hey Matthias, > > > > Le 28/09/2020 à 18:07, Matthias Klose a écrit : > > > Some build failures on ppc64el and s390x are caused by a buildd issue, > > > and will > > > be retried soonish. Please ignore these where you see a ftbfs just on > > > those > > > architectures, but successes on the other architectures. > > > > There seems to be some flakyness on arm as well, are those going to be > > retried or should that be requested by e.g pinging you? > > > > Some examples > > > > https://launchpadlibrarian.net/499016257/buildlog_ubuntu-groovy-armhf.colord-gtk_0.2.0-0ubuntu1_BUILDING.txt.gz > > https://launchpadlibrarian.net/499209776/buildlog_ubuntu-groovy-arm64.gpm_1.20.7-6_BUILDING.txt.gz > > https://launchpadlibrarian.net/499174464/buildlog_ubuntu-groovy-arm64.remmina_1.4.8+dfsg-1ubuntu1_BUILDING.txt.gz > > Adding the same armhf dependency issue on these: > htop: > https://launchpadlibrarian.net/499078378/buildlog_ubuntu-groovy-arm64.htop_3.0.2-1_BUILDING.txt.gz > openvpn: > https://launchpadlibrarian.net/499161991/buildlog_ubuntu-groovy-armhf.openvpn_2.4.9-3ubuntu1_BUILDING.txt.gz > I see that Laney already filed a bug about that with IS. > > Furthermore some armhf issues are due to > https://bugs.launchpad.net/ubuntu/+source/gcc-10/+bug/1890435 > php7.4: > https://launchpadlibrarian.net/499168409/buildlog_ubuntu-groovy-armhf.php7.4_7.4.9-1ubuntu1_BUILDING.txt.gz > > When doing an initial triage of some errors I found three sets of > recurring issues: > 1. rpc includes like "rpc/rpc.h: No such file" FYI These are broken by libc6-dev dropping rpc.h being taken over by libtirpc-dev Paths changed: Before: # dpkg -S rpc/types.h rpc/rpc.h libc6-dev:amd64: /usr/include/rpc/types.h libc6-dev:amd64: /usr/include/rpc/rpc.h After: # dpkg -S rpc/types.h rpc/rpc.h libtirpc-dev:amd64: /usr/include/tirpc/rpc/types.h libtirpc-dev:amd64: /usr/include/tirpc/rpc/rpc.h Ubuntu/Debian build of glibc for a long time had --enable-obsolete-rpc but that was now removed upstream and this is the fallout. Include paths might need to add -I/usr/include/tirpc to resolve correctly. This already exists in some places: https://sources.debian.org/src/zsh/5.8-5/configure/?hl=11274#L11274 https://sources.debian.org/src/libquota-perl/1.8.1+dfsg-1/Makef Not (yet) a problem in Debian because there we are still on 2.31 # dpkg -S rpc/types.h rpc/rpc.h libc6-dev:amd64: /usr/include/rpc/types.h libc6-dev:amd64: /usr/include/rpc/rpc.h And we are by pushing glibc2.32 late in groovy we are forcing everything that is left to resolve the same now. I'm not sure should glibc provide a compat path - I assume this was made so that every project has to make a concious switch? Note, in most cases this include path should be covered by libtirpc pkg-config. # pkg-config --cflags libtirpc -I/usr/include/tirpc But e.g. in the case of open-vm-tools that seems not to be propagated to all toolchain calls :-/ > 2. better null checking like " -Werror=nonnull" or "directive argument is > null" > 3. linker shows "multiple definitions of" > > #2 likely comes down to fixing code or disabling the warning for now. > But for #1 and #3 I think there is a general change and every affected > package likely will need the similar fix. > So if someone already debugged those it would be great to let the others know. > > > > Cheers, > > Sebastien Bacher > > > > > > > > -- > > ubuntu-devel mailing list > > ubuntu-devel@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > > > -- > Christian Ehrhardt > Staff Engineer, Ubuntu Server > Canonical Ltd -- Christian Ehrhardt 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
Re: Second Groovy Gorilla test rebuild
On Mon, Sep 28, 2020 at 9:39 PM Sebastien Bacher wrote: > > Hey Matthias, > > Le 28/09/2020 à 18:07, Matthias Klose a écrit : > > Some build failures on ppc64el and s390x are caused by a buildd issue, and > > will > > be retried soonish. Please ignore these where you see a ftbfs just on those > > architectures, but successes on the other architectures. > > There seems to be some flakyness on arm as well, are those going to be > retried or should that be requested by e.g pinging you? > > Some examples > > https://launchpadlibrarian.net/499016257/buildlog_ubuntu-groovy-armhf.colord-gtk_0.2.0-0ubuntu1_BUILDING.txt.gz > https://launchpadlibrarian.net/499209776/buildlog_ubuntu-groovy-arm64.gpm_1.20.7-6_BUILDING.txt.gz > https://launchpadlibrarian.net/499174464/buildlog_ubuntu-groovy-arm64.remmina_1.4.8+dfsg-1ubuntu1_BUILDING.txt.gz Adding the same armhf dependency issue on these: htop: https://launchpadlibrarian.net/499078378/buildlog_ubuntu-groovy-arm64.htop_3.0.2-1_BUILDING.txt.gz openvpn: https://launchpadlibrarian.net/499161991/buildlog_ubuntu-groovy-armhf.openvpn_2.4.9-3ubuntu1_BUILDING.txt.gz I see that Laney already filed a bug about that with IS. Furthermore some armhf issues are due to https://bugs.launchpad.net/ubuntu/+source/gcc-10/+bug/1890435 php7.4: https://launchpadlibrarian.net/499168409/buildlog_ubuntu-groovy-armhf.php7.4_7.4.9-1ubuntu1_BUILDING.txt.gz When doing an initial triage of some errors I found three sets of recurring issues: 1. rpc includes like "rpc/rpc.h: No such file" 2. better null checking like " -Werror=nonnull" or "directive argument is null" 3. linker shows "multiple definitions of" #2 likely comes down to fixing code or disabling the warning for now. But for #1 and #3 I think there is a general change and every affected package likely will need the similar fix. So if someone already debugged those it would be great to let the others know. > Cheers, > Sebastien Bacher > > > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Christian Ehrhardt 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
Re: +1 Maintenance report
On Fri, Aug 14, 2020 at 10:18 PM Sergio Durigan Junior < sergio.duri...@canonical.com> wrote: > On Friday, August 14 2020, Christian Ehrhardt wrote: > > > 2. groovy rsync was one of the many packages waiting for > >armhf test backlog to resolve - it just needed some help with test > > triggers > >and then migrated. > > Hm, I still see rsync blocked (or maybe you were referring to a previous > version of rsync in your email...): > Hi Sergio, Yes I was on the last steps of the migration of 3.2.2 at the beginning of last week. 3.2.3 came mid last week and currently looks as you describe it. > > https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#rsync > > It's being blocked by dgit (failing on all arches), diaspora-installer > (failing on armhf; but it seems to have passed now), and livecd-rootfs > (failing on arm64; I think it's worth a retry just to make sure it's not > an intermitted failure). > livecd looks like a flaky test and I have restarted it. dgit seems to be a legitimate issue with the new rsync As you can see the fails all report this: dgit-mirror-ssh-wrap: unexpected command (rsync upgraded?): rsync --server -lHtre.iLsfxCIvu --timeout=900 --delete --safe-links . /tmp/autopkgtest.CZJdKU/autopkgtest_tmp/git-mirror/example.git rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(228) [sender=3.2.3] + rc=127 I have restarted them for the sake of having one more data point on reproducibility once you get online today. But my assumption is that this issue will stay. You might want to look into that, I did not see the same when moving to 3.2.2 btw. Thanks, > > -- > Sergio > GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14 > -- Christian Ehrhardt 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
+1 Maintenance report
buntu-clean-groovy-proposed2/+merge/389239 [33]: https://code.launchpad.net/~seb128/britney/ignore-libreoffice-armhf/+merge/389227 [34]: https://bugs.launchpad.net/ubuntu/+source/fatrace/+bug/1885188 [35]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963714 -- Christian Ehrhardt 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
Re: +1 maintenance report
On Tue, Aug 11, 2020 at 6:55 PM Bryce Harrington < bryce.harring...@canonical.com> wrote: > On Tue, Aug 04, 2020 at 09:53:26PM +1200, Michael Hudson-Doyle wrote: > > Hi all, > > > > I noticed golang-gopkg-square-go-jose.v2 times out on armhf, filed > > https://github.com/square/go-jose/issues/326. > > > > Then I looked at the icu transition. > > > > 0ad fails to build due to gcc-10, I found the fix for this upstream and > > backported it. > > > > I retried some ucto builds which appeared to have run before a build > > dependency had been built (maybe fallout from the build farm outage). And > > retried "frog" builds when these completed. > > > doxygen autopkgtests are failing because the json-c in proposed has moved > > its Doxyfile. > > > > doxygen's tests fail with the json-c in proposed: it builds the > > documentation for json-c in an autopkgtest but json-c has moved it's > > Doxyfile into a different directory. Easy to fix once json-c has > migrated. > > > > Cheers, > > mwh > > Could someone give a status update on the icu and json-c transitions? > I see they've been progressing daily, but curious since server team has > a few packages blocked from migrating. > Steve already answered the ICU question in a new thread and I've seen you participated there. To answer both, json-c seems complete except a chain of implicit dependencies json-c -> kamailio -> mongo-c-driver -> icu So json-c seems ready, but entangled with ICU right now. > Thanks, > Bryce > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- Christian Ehrhardt 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
Re: +1 maintenance June 2nd-5th
On Fri, Jun 5, 2020 at 8:29 PM Bryce Harrington <
bryce.harring...@canonical.com> wrote:
> On Fri, Jun 05, 2020 at 08:11:40AM +0200, Christian Ehrhardt wrote:
> > php-horde
> >
> > Next was a look at php-horde-* which is not only split into many packages
> > but also has plenty of autopkgtests due to that.
> > 10/10 tests that I checked were blocked at the same issue: "E: Package
> > 'php-horde-test' has no installation candidate"
> > If there is another issue, then I need this to resolve to be able to see
> it
> > :-)
> >
> > It turned out to be rather easy: php-horde-test isn't in groovy-release -
> > not even an older version.
> > Due to that the tests fail to find anything.
> >
> > 104 source packages and counting :-). The reason for all that was that
> the
> > status was a mixed feeling before [6] and removed from focal.
> > It was removed from Debian as well [7] and the current flurry of
> > builds&tests is caused by re-uploads to bring it back.
> > Some bits are still hanging in Debian's new queue like the core
> "php-horde
> > 5.2.21+debian1-1" itself.
> >
> > We should give it a chance now, but if it looks as bad with proper test
> > triggers it likely should be removed until this has resolved to a proper
> > state in Debian (gladly the package was adopted, so this will become
> better
> > over time).
> >
> > For now we can't go on, this will need to wait until php-horde passes the
> > new queue and is in groovy-proposed.
> > Then we want to run something like the following to properly restart the
> > tests.
> >
> > $ wget
> >
> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
> > $ for p in $(grep -Hrn '>php-horde-.* (- to php-horde-/php-horde-/' | sed -e
> > 's/<\/a>.*//' ); do retry-autopkgtest-regressions --series groovy
> --blocks
> > "${p}"; done | sed -e
> >
> 's/$/&trigger=php-horde-test%2F2.6.3%2Bdebian0-5&trigger=php-horde%2F5.2.21%2Bdebian1-1/'
> >
> > ---
> >
> > php-horde
> >
> > Still waiting in Debian new queue, due to that still nothing to do.
>
> php-horde was dropped in focal, and should be for groovy as well, and
> blacklisted:
>
> https://bugs.launchpad.net/ubuntu/+source/php-horde/+bug/1880776
>
> php-horde-* wraps a vast number of other system packages, so whenever
> there are any changes in plumbing, invariably some chunk of php-horde
> ends up broken. We don't see a high enough usage of php-horde to
> warrant the effort maintaining it has been taking.
>
Hi Bryce,
thanks for the background.
I remember and even read the old removal bug when looking at the case this
week.
I thought we could give it a chance if it is better now, but I'm fine to
remove it if that is still the right thing to do.
So you are saying we should re-remove and more actively block further
syncing then?
I can do so next week, just please confirm to me that this is the path to
go on this.
> Bryce
>
--
Christian Ehrhardt
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
+1 maintenance June 2nd-5th
l
- timeouts and URL issues of some sorts, test history suggests at least
some of them might just be flaky
lintian,mysql-8.0,rspamd
But for some extended joy with all of this we now got [15] which means all
these tests will be restarted for the new version anyway.
Due to that I have -not- restarted the old ones I have analyzed above.
To help the test queue one with the ability to do so could cancel the
remaining 7329 tests for the older version please.
The regexp that matches on an unescaped [16] would be:
'\\n{"triggers": \["perl/5.30.3-1"\]'
I've pinged Laney asking for the reject of those from the test queue.
---
## Misc
And along all that I did retrigger plenty of known-flaky tests seen to show
up in excuses just to get things moving.
Those are not worth to be mentioned individually.s
---
[1]: https://launchpad.net/ubuntu/+source/spice/0.14.3-1ubuntu1
[2]:
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4078/+packages
[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962012
[4]: https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Status
[5]: https://bugs.launchpad.net/ubuntu/+source/plinth/+bug/1881860
[6]: https://bugs.launchpad.net/ubuntu/+source/php-horde/+bug/1868281
[7]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942282
[8]: https://bugs.launchpad.net/ubuntu/+source/probert/+bug/1830347
[9]: https://lists.debian.org/debian-haskell/2020/06/msg3.html
[10]: https://launchpad.net/ubuntu/+source/six/1.15.0-1
[11]: https://paste.ubuntu.com/p/mfRXfQPwJp/
[12]:
https://code.launchpad.net/~paelzer/ubuntu/+source/nfs-ganesha/+git/nfs-ganesha/+merge/385106
[13]: https://salsa.debian.org/debian/nfs-ganesha/-/merge_requests/1
[14]: https://bugs.launchpad.net/ubuntu/+source/jinja2/+bug/1882095
[15]: https://launchpad.net/ubuntu/+source/perl/5.30.3-2
[16]: http://autopkgtest.ubuntu.com/queues.json
[17]: https://wiki.ubuntu.com/PlusOneMaintenanceTeam
--
Christian Ehrhardt
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
Re: Help understanding the package set we need to maintain for partial i386
On Mon, May 25, 2020 at 11:44 PM Steve Langasek wrote: > > On Mon, May 25, 2020 at 01:48:28PM +0200, Christian Ehrhardt wrote: > > Hi Steve (and all of Ubuntu-dev), > > so far things almost worked as expected :-) > > > The change for openmp [1] worked and migrated to groovy-release. > > The new dependency worked as well and germinate [2] now reports to no > > more pull in rdma-core on i386. > > But on the subsequent sync of rdma-core [3] I see i386 is still trying > > to be built. > > So I face the obvious "missing build on i386: ibacm, ..." [4] in > > update-excuses. > > > I wonder what to do now, is this another case not yet documented in [5]? > > Do I need to call for an archive admin to update the "effective > > whitelist" accordingly? > > Yes, that's exactly what needs to happen. The whitelist is not > automatically updated, it requires an archive admin to review any > autogenerated changes and commit them. > > I've rerun the script now, and rdma-core has dropped out of the whitelist. Thanks, I have uploaded a no-change rebuild and can confirm it picked this up now. > We will then also have to remove the rdma-core binaries on i386 in the > release pocket. Yes I've filed a removal bug for that. => https://bugs.launchpad.net/ubuntu/+source/rdma-core/+bug/1880651 P.S. As for the former parts of this discussion I have put (my) new insight into the i386 wiki page to help everyone else as well > > Thanks in advance, > > Christian > > > > [1]: https://launchpad.net/ubuntu/+source/openmpi/4.0.3-6ubuntu2 > > [2]: > > https://people.canonical.com/~ubuntu-archive/germinate-output/i386.groovy/i386+build-depends > > [3]: https://launchpad.net/ubuntu/+source/rdma-core/29.0-1 > > [4]: > > https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html > > [5]: https://wiki.ubuntu.com/i386 > > > > > > > But then I have realized that while there are not more runtime > > > > > dependencies, build dependencies in i386 seem to be quite a lot still > > > > > (reverse-depends --release=groovy --arch=i386 --build-dep > > > > > src:rdma-core shows 41). > > > > > > > > As far as I know these are all false-positives; I don't know that > > > > reverse-depends --build-dep --arch=foo ever does anything useful. > > > > Spot-checking the output, I see that most of these packages only have > > > > arch: > > > > all packages published on i386. > > > > > > > > > With this mail I'd look for: > > > > > a) general guidance on `is the effective i386 build = whitelist + > > > > > build-deps` > > > > > b) feedback on the suggestion to remove the rdma-core build dep on > > > > > openmpi; or would all 41 build-deps have to go away? > > > > > c) other alternatives > > > > > > > > > The answers to (a) we could add to the wiki [4]. > > > > > The answers to (b)+(c) will hopefully help me to go on with this, it > > > > > might eventually come down to keeping the current Delta (trivial) in > > > > > rdma-core, but along the way understanding the inner workings better > > > > > would be great. > > > > > > > > > > [1]: https://launchpad.net/ubuntu/+source/rdma-core/28.0-1ubuntu1 > > > > > [2]: > > > > > https://github.com/linux-rdma/rdma-core/pull/756#issuecomment-630138899 > > > > > [3]: > > > > > https://discourse.ubuntu.com/t/community-process-for-32-bit-compatibility/12598 > > > > > [4]: https://wiki.ubuntu.com/i386 > > > > > [5]: > > > > > https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/i386/tree/i386 > > > > > [6]: > > > > > https://people.canonical.com/~ubuntu-archive/germinate-output/i386.focal/i386+build-depends.sources > > > > > > > > -- > > > > 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 > > > > > > > > > > > > -- > > > Christian Ehrhardt > > > Staff Engineer, Ubuntu Server > > > Canonical Ltd > > > > > > > > -- > > Christian Ehrhardt > > 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 > > -- > 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 -- Christian Ehrhardt 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
Re: Help understanding the package set we need to maintain for partial i386
On Tue, May 19, 2020 at 5:43 PM Christian Ehrhardt wrote: > > On Mon, May 18, 2020 at 9:25 PM Steve Langasek > wrote: > > > > Hi Christian, > > > > On Mon, May 18, 2020 at 03:57:39PM +0200, Christian Ehrhardt wrote: > > > Hi, > > > I was revisiting one of the packages the server team usually looks > > > after: `rdma-core`. > > > Late in the focal release cycle I was asked to mark the `pandoc` > > > build-dependency with !i386 as it doesn't exist there and was causing > > > problems [1]. I was revisiting this now to resolve it in a better way > > > to be able to make the package a sync again. > > > > > I had a discussion with Debian and started to wonder why this is a > > > problem for Ubuntu at all. That made me identify a weak spot in my > > > understanding of partial i386 [3][4]. > > > The odd thing to me is that `rdma-core` isn't part of the i386 > > > whitelist [5], so why would it be a problem that the d/control lists > > > pandoc as build-dep - I'd have expected it to not build at all. > > > Then I realized that germinate still pulls it in [6], but failed to > > > see why. Is it that we actually have i386 builds on the whitelist and > > > in addition all-of-its-build-deps ? > > > > The relevant germinate output is > > https://people.canonical.com/~ubuntu-archive/germinate-output/i386.groovy/i386+build-depends > > > > This shows the source packages that are in the set, as well as why they're > > pulled in. > > > > rdma-core is there as a dependency of openmpi, which is a dependency of > > mpi-defaults, which is a build-dependency of boost. > > Thank you for this link on top of the ones I have checked. > > > There are a lot more packages that need to be built on i386 than those that > > are directly in the whitelist, because we need a closure over > > build-dependencies in order to be able to build the packages that are in the > > whitelist. > > I was seeing that it was more, thanks for confirming that it is due to > the dependencies. > I have added this to the wiki page [4] so that fewer people have to > ask again :-) > > > > Furthermore that might explain why the only dependency left is openmpi > > > which also isn't part of the whitelist [5] but shown in germinate [6]. > > > > > $ reverse-depends --release=groovy --arch=i386 src:rdma-core > > > Reverse-Depends > > > * libopenmpi-dev(for libibverbs-dev) > > > > > I now wonder if a much easier fix might be to remove the build > > > dependency to rdma-core on src:openmpi (for i386 only) which would > > > finally make rdma-core really not building on i386. Is that a better > > > solution? Openmpi in turn has a much longer list of things depending > > > on it, doing the cut at openmpi->rdma-core seems to be the cleanest. > > > > I have no preference on whether we do the cut above or below rdma. If you > > find that having openmpi not depend on rdma-core on i386, and keeping > > rdma-core in sync, is easier for maintenance, then that's fine. > > Looking at openmpi more in detail it seems someone called "Steve" > already gave this a shot :-) > The current Delta we have there is: >* Also disable the direct build-dependency on libibverbs-dev (from > rdma-core) on i386. >* Disable libfabric support on i386 to avoid pulling in rdma-core. > > So since we already have delta on openmpi due to i386 let us try to > reduce it to just openmpi. > It seems the build deps are correct, but there is a hard dependency > statement in d/control: > libibverbs-dev (>= 1.1.7) [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386] > > That just needs the same !i386 treatment as the build-deps you have > already done. > Hopefully rdma-core will no more be pulled then. > > I'll do the openmpi change and re-check the i386 germinate a day later > if rdma-core really was let go on i386. Hi Steve (and all of Ubuntu-dev), so far things almost worked as expected :-) The change for openmp [1] worked and migrated to groovy-release. The new dependency worked as well and germinate [2] now reports to no more pull in rdma-core on i386. But on the subsequent sync of rdma-core [3] I see i386 is still trying to be built. So I face the obvious "missing build on i386: ibacm, ..." [4] in update-excuses. I wonder what to do now, is this another case not yet documented in [5]? Do I need to call for an archive admin to update the "effective whitelist" accordingly? Thanks in advance, Christian [1]: https://launchpad.net/ubuntu/+sourc
Re: Help understanding the package set we need to maintain for partial i386
On Mon, May 18, 2020 at 9:25 PM Steve Langasek wrote: > > Hi Christian, > > On Mon, May 18, 2020 at 03:57:39PM +0200, Christian Ehrhardt wrote: > > Hi, > > I was revisiting one of the packages the server team usually looks > > after: `rdma-core`. > > Late in the focal release cycle I was asked to mark the `pandoc` > > build-dependency with !i386 as it doesn't exist there and was causing > > problems [1]. I was revisiting this now to resolve it in a better way > > to be able to make the package a sync again. > > > I had a discussion with Debian and started to wonder why this is a > > problem for Ubuntu at all. That made me identify a weak spot in my > > understanding of partial i386 [3][4]. > > The odd thing to me is that `rdma-core` isn't part of the i386 > > whitelist [5], so why would it be a problem that the d/control lists > > pandoc as build-dep - I'd have expected it to not build at all. > > Then I realized that germinate still pulls it in [6], but failed to > > see why. Is it that we actually have i386 builds on the whitelist and > > in addition all-of-its-build-deps ? > > The relevant germinate output is > https://people.canonical.com/~ubuntu-archive/germinate-output/i386.groovy/i386+build-depends > > This shows the source packages that are in the set, as well as why they're > pulled in. > > rdma-core is there as a dependency of openmpi, which is a dependency of > mpi-defaults, which is a build-dependency of boost. Thank you for this link on top of the ones I have checked. > There are a lot more packages that need to be built on i386 than those that > are directly in the whitelist, because we need a closure over > build-dependencies in order to be able to build the packages that are in the > whitelist. I was seeing that it was more, thanks for confirming that it is due to the dependencies. I have added this to the wiki page [4] so that fewer people have to ask again :-) > > Furthermore that might explain why the only dependency left is openmpi > > which also isn't part of the whitelist [5] but shown in germinate [6]. > > > $ reverse-depends --release=groovy --arch=i386 src:rdma-core > > Reverse-Depends > > * libopenmpi-dev(for libibverbs-dev) > > > I now wonder if a much easier fix might be to remove the build > > dependency to rdma-core on src:openmpi (for i386 only) which would > > finally make rdma-core really not building on i386. Is that a better > > solution? Openmpi in turn has a much longer list of things depending > > on it, doing the cut at openmpi->rdma-core seems to be the cleanest. > > I have no preference on whether we do the cut above or below rdma. If you > find that having openmpi not depend on rdma-core on i386, and keeping > rdma-core in sync, is easier for maintenance, then that's fine. Looking at openmpi more in detail it seems someone called "Steve" already gave this a shot :-) The current Delta we have there is: * Also disable the direct build-dependency on libibverbs-dev (from rdma-core) on i386. * Disable libfabric support on i386 to avoid pulling in rdma-core. So since we already have delta on openmpi due to i386 let us try to reduce it to just openmpi. It seems the build deps are correct, but there is a hard dependency statement in d/control: libibverbs-dev (>= 1.1.7) [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386] That just needs the same !i386 treatment as the build-deps you have already done. Hopefully rdma-core will no more be pulled then. I'll do the openmpi change and re-check the i386 germinate a day later if rdma-core really was let go on i386. > > But then I have realized that while there are not more runtime > > dependencies, build dependencies in i386 seem to be quite a lot still > > (reverse-depends --release=groovy --arch=i386 --build-dep > > src:rdma-core shows 41). > > As far as I know these are all false-positives; I don't know that > reverse-depends --build-dep --arch=foo ever does anything useful. > Spot-checking the output, I see that most of these packages only have arch: > all packages published on i386. > > > With this mail I'd look for: > > a) general guidance on `is the effective i386 build = whitelist + > > build-deps` > > b) feedback on the suggestion to remove the rdma-core build dep on > > openmpi; or would all 41 build-deps have to go away? > > c) other alternatives > > > The answers to (a) we could add to the wiki [4]. > > The answers to (b)+(c) will hopefully help me to go on with this, it > > might eventually come down to keeping the current Delta (trivial) in > > rdma-core, but along the way understanding the inne
Help understanding the package set we need to maintain for partial i386
Hi, I was revisiting one of the packages the server team usually looks after: `rdma-core`. Late in the focal release cycle I was asked to mark the `pandoc` build-dependency with !i386 as it doesn't exist there and was causing problems [1]. I was revisiting this now to resolve it in a better way to be able to make the package a sync again. I had a discussion with Debian and started to wonder why this is a problem for Ubuntu at all. That made me identify a weak spot in my understanding of partial i386 [3][4]. The odd thing to me is that `rdma-core` isn't part of the i386 whitelist [5], so why would it be a problem that the d/control lists pandoc as build-dep - I'd have expected it to not build at all. Then I realized that germinate still pulls it in [6], but failed to see why. Is it that we actually have i386 builds on the whitelist and in addition all-of-its-build-deps ? Furthermore that might explain why the only dependency left is openmpi which also isn't part of the whitelist [5] but shown in germinate [6]. $ reverse-depends --release=groovy --arch=i386 src:rdma-core Reverse-Depends * libopenmpi-dev(for libibverbs-dev) I now wonder if a much easier fix might be to remove the build dependency to rdma-core on src:openmpi (for i386 only) which would finally make rdma-core really not building on i386. Is that a better solution? Openmpi in turn has a much longer list of things depending on it, doing the cut at openmpi->rdma-core seems to be the cleanest. But then I have realized that while there are not more runtime dependencies, build dependencies in i386 seem to be quite a lot still (reverse-depends --release=groovy --arch=i386 --build-dep src:rdma-core shows 41). With this mail I'd look for: a) general guidance on `is the effective i386 build = whitelist + build-deps` b) feedback on the suggestion to remove the rdma-core build dep on openmpi; or would all 41 build-deps have to go away? c) other alternatives The answers to (a) we could add to the wiki [4]. The answers to (b)+(c) will hopefully help me to go on with this, it might eventually come down to keeping the current Delta (trivial) in rdma-core, but along the way understanding the inner workings better would be great. [1]: https://launchpad.net/ubuntu/+source/rdma-core/28.0-1ubuntu1 [2]: https://github.com/linux-rdma/rdma-core/pull/756#issuecomment-630138899 [3]: https://discourse.ubuntu.com/t/community-process-for-32-bit-compatibility/12598 [4]: https://wiki.ubuntu.com/i386 [5]: https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/i386/tree/i386 [6]: https://people.canonical.com/~ubuntu-archive/germinate-output/i386.focal/i386+build-depends.sources -- Christian Ehrhardt 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
Re: RFC: Ubuntu HA resource-agents supportability
ocf:pacemaker:ping - records in CIB number of nodes host can connect to > portblock - temporarily block/unblock access to tcp/udp ports > > # openstack > > openstack-cinder-volume - attach cinder vol to an instance (os-info <->) > openstack-floating-ip - move a floating IP from an instance to another > > # registration (CIB) > > lxd-info- nr of lxd containers running in CIB > machine-info- records various node attributes in CIB > NodeUtilization - cpu, host mem, hypervisor mem etc... into CIB > openstack-info - records attributes of a node into CIB > SysInfo - records various node attributes into CIB > SystemHealth- monitors health of system using IPMI > attribute - sets node attr one way when started and vice-versa > > # > ## COMMUNITY SUPPORT (bugs opened here will be forwarded to upstream > directly) > # > > # services > > SphinxSearchDaemon - sphix search daemon > Xinetd - start/stop services managed by xinetd > zabbixserver- zabbix server instance > > # storage > > o2cb- oracle cluster filesystem userspace daemon > (oracle) > sfex- excl access to shared storage using SF-EX > > # virtualization > > aliyun-vpc-move-ip - move ip within a vpc of the aliyum ecs (alibaba) > awseip - manages aws elastic IP address (aws) > awsvip - manages aws secondary private ip addresses (aws) > aws-vpc-move-ip - move ip within a vpc of the aws ec2 (aws) > aws-vpc-route53 - update route53 vpc record for aws ec2 (aws) > azure-events- monitor for scheduled events for azure vm (azure) > azure-lb- answers azure load balancer health probe req > (azure) > gcp-vpc-move-ip - floating ip address within a GCP VPC (google) > ManageVE- openVZ virtual environment (virtuozzo) > minio - minio server instance > podman - creates/launches podman containers > rkt - creates/launches container based on supplied image > > # > ## UNSUPPORTED (Ubuntu does not support it) > # > > db2 - manages IBM DB2 LUW databases (IBM) > eDir88 - Novell eDirectory directory server instance > (novell) > ICP - ICP vortex clustered host drive (intel) > ids - IBM informix dynamic server (IDS) (IBM) > SAPDatabase - SAP database (of any type) instance agent (SAP) > SAPInstance - SAP application server instances agent (SAP) > ServeRAID - enables/disables shared serveRAID merge groups > (IBM) > ManageRAID - raid devices (/etc/conf.d/HB-ManageRAID) > oraasm - oracle asm agent, uses ohasd for asm disk grp > (oracle) > oracle - oracle database instance (oracle) > oralsnr - oracle TNS listener (oracle) > sybaseASE - sybase ASE failover instance (Sybase) > vdo-vol - https://bugs.launchpad.net/ubuntu/+bug/1869825 > WAS - websphere application server instance (IBM) > WAS6- websphere application server instance (IBM) > Xen - xen unprivileged domains Xen is on community support level, so you likely want to move this one category up. > # > ## DEPRECATED (do not use) > # > > Evmsd - clustered evms vol mgmt (evms is not maintained) > EvmsSCC - clustered evms vol mgmt (evms is not maintained) > LinuxSCSI - enables/disables scsi devs through kernel scsi > hotplug > scsi2reservation- SCSI-2 reservation agent (depends on > "scsi_reserve") > ocf:heartbeat:pingd - monitors connectivity to specific hosts > ocf:pacemaker:pingd - replaced by pacemaker:ping (this is broken) > vmware - control vmware server 2.0 virtual machines (2009) > > -- Christian Ehrhardt 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
Re: apport permission error
On Tue, Feb 25, 2020 at 6:10 PM Steve Langasek wrote: > On Tue, Feb 25, 2020 at 02:04:51PM +1030, Alex Murray wrote: > > > On Fri, Feb 21, 2020 at 02:04:37PM -0800, Kees Cook wrote: > > >> On Thu, Feb 20, 2020 at 03:45:39AM +, Seth Arnold wrote: > > >> > I'm worried that turning this flag on for the first time in an LTS > release > > >> > may be breaking too many expectations. > > > >> > Adapting applications may be too much effort; because I don't know > what > > >> > exactly apport is doing here it is hard to estimate how much effort > it > > >> > will take to adapt it. Possibly the user-launched apport instances > need > > >> > to create their own directory on launch. Possibly apport needs a > > >> > more invasive redesign. > > >> > [...] > > >> > Source code searching is not practical. The combination of working > > >> > with files in a world-writable sticky directory and not already > using > > >> > O_EXCL with O_CREAT is not feasible to search for. > > > >> FWIW, I think that the scope of the change is small enough (only in > > >> world-writable stick directories) and dramatic enough (usually total > > >> failure), that the risk is worth the benefit. Excepting the very few > > >> special directories (like /var/crash, where the software using them > > >> is likely enumerable), I would also argue that breaking stuff in > > >> "standard" temp directories (like /tmp) that isn't using O_EXCL is > > >> actually _desirable_, given that it is expressly risky to operate in > > >> that condition. > > > >> And, I would suggest that doing this in an LTS is the right thing to > do, > > >> otherwise you wait 2 years before gaining this defense that would be > > >> actively _disabled_ compared to all other distros with a modern > version > > >> of systemd. And if this is the first noticed problem, that seems to > be a > > >> reasonably good indication of how rare the case is of it creating > "real" > > >> problems. > > > > As an additional wrinkle, procps in focal-proposed is now setting > > > fs.protected_regular=2 by default, overriding the systemd setting. > This > > > hasn't made it out of proposed yet because the additional restriction > broke > > > the postgresql-common autopkgtest (fix for this is in progress): > > > https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1864423 > > > > Kees, it sounds like you were advocating for setting the level to > > > fs.protected_regular=1, but NOT raising it to 2. Should we back out > this > > > procps change for 20.04? > > > (I'll let Kees respond for himself but figured this was a good point to > > reply) > > > From the Ubuntu Security team's view, it is not clear how much breakage > > will result from setting this to 2 - setting protected_regular=1 is > > already a good win and so far has seen little fallout that I know of > > (Apport has already worked around this), but given how close we are to > > FF I am a bit hesitant to mandate for this to be =2 (given we > > already have one known failure as a result). From a security point of > > view, =2 is a better default but this is not the only view that > > matters. > > > So my preference would be to keep this at =2 for now but be confident > > that we can back it out to =1 in the event that we suddenly discover a > > bunch more issues in the near term. > > Thanks, it's easy enough to back out later (as long as someone actually > raises a flag when things break!), so I'm ok with that. > > Since postgresql-common's tests have now been fixed for compatibility with > =2, the procps with this new behavior will be unblocked and should reach > the > focal release today or tomorrow. > I think it won't migrate as-is. Since this was out-of order compared to Debian there are a few no-change-rebuilds needed. Update_output suggests we are stuck on the rev-deps to the old lib version: $ reverse-depends -r focal libprocps7 Reverse-Depends === * apitrace [amd64 arm64 armhf ppc64el s390x] * cpu-x [amd64] * deepin-screen-recorder [amd64 arm64 armhf ppc64el s390x] * intel-gpu-tools [amd64 i386] * libprocps-dev * procps * veyon-plugins [amd64 arm64 armhf ppc64el s390x] -- > 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 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
How to handle tmpfiles.d in non-systemd environments
Hi, There is a bug [1] showcasing an issue failing in a docker container as tmpfiles.d there does nothing. On 6th of December I already wrote to ubuntu-server as part of my daily bug duties and subscribed people to the bug. Not much happened since then, a few small IRC exchanges and the Debian init system GR was resolved, but other than that I didn't hear anything else on the topic. This class of issues we should IMHO solve/ignore/handle in a general and not package specific fashion. I was wondering if anyone on the core-system or systemd side of things has already thought/decided on that class of issues and could chime in on the bug. To everyone - have you seen similar bugs that we should Dup' together in regard to this? [1]: https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1855140 -- Christian Ehrhardt 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
Re: Call for nominations: Developer Membership Board
On Fri, Feb 7, 2020 at 2:24 AM Eric Desrochers < eric.desroch...@canonical.com> wrote: > Since we have not yet enough nominations and it was the same situation at > last election 2 years ago, I started to think about what can be changed in > our approach. > > One thing that comes to my mind is what if the nomination were public ? > Right now it is private and only visible to the DMB team. It is only > public once the condorcet vote officially start. > > Would it helps having more folks nominating themselves (ripple effect) if > they see someone they know give it a try ? > IMHO yes, more like "oh he's in there I might be able to do that as well I guess", but still I think it would help. > Would it make the nomination less intimidating for some individuals ? > Yes to that. Furthermore I expect it would eliminate some cases were people skip the mail thinking "there will be enough anyway". P.S. Just an opinion and entirely up to you, the alternating meeting time is hard to plan for everyone. If there would be a way to get rid of that it might help as well. I do realize why it is the way it is (give applicants from anywhere a better chance to attend), but I'm just saying this detail might make your search for members harder. Regards, > Eric > > On Tue, Feb 4, 2020 at 4:06 PM Robie Basak wrote: > >> On Wed, Jan 29, 2020 at 01:32:35PM +, Robie Basak wrote: >> > The membership terms for two members (Jeremy Bicha and Mathieu >> > Trudel-Lapierre) have expired, and the terms of the remaining members >> > (Eric Desrochers, Micah Gersten, Robie Basak, Simon Quigley and Łukasz >> > Zemczak) expire in May. Subsequently, this email is a call for >> > nominations to fill their positions. >> >> We don't yet have enough nominations to fill the seats that are up for >> election. In recent years the DMB has routinely been short-staffed, >> blocking us from being able to appoint more Ubuntu developers. >> >> If you are a core dev or MOTU, please consider spending one hour every >> other Monday to help others join us by nominating yourself for a seat on >> the DMB[1]. >> >> Thanks, >> >> Robie >> >> [1] >> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2020-January/001270.html >> -- >> 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 > -- Christian Ehrhardt 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
Run Focal i386 autopkgtests locally
Hi, The i386 removal works great and after the dust settled it comes mostly down to adding a few more hints in recent weeks. But sometimes there are i386 tests that are valid to run, but fail and need debugging. If you happen to face such a case the old common pattern won't work anymore: $ sudo autopkgtest-buildvm-ubuntu-cloud -a i386 -r bionic -s 15G $ sudo ~/work/autopkgtest/autopkgtest/runner/autopkgtest .dsc \ -- qemu ~/work/autopkgtest-focal-amd64.img The above was fine in the past, but with Focal you that won't work due to: $ sudo autopkgtest-buildvm-ubuntu-cloud -a i386 -r focal -s 15G Downloading https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-i386.img. .. No image exists for this release/architecture Steve was so kind to help me with the case I was facing and after a bit I learned how to locally run my i386 tests in a VM and wanted to share that with you. First of all, you probably need a more recent autopkgtest to get the features you need. So you need to clone git and run it from there. $ git clone git+ssh:// pael...@git.launchpad.net/~ubuntu-release/autopkgtest/+git/development [for me that is in ~/work/autopkgtest/autopkgtest] And then - since you only have amd64 images - to run it you have to add # to select the architecture for the test -a i386 # to get the arch available in the test env before the testing starts --setup-commands="dpkg --add-architecture i386; apt-get update" Overall for me it then worked like: $ sudo ~/work/autopkgtest/autopkgtest/runner/autopkgtest .dsc \ --setup-commands="dpkg --add-architecture i386; apt-get update" -a i386 \ -- qemu ~/work/autopkgtest-focal-amd64.img I hope this helps some other people as well. And if anyone knows more tweaks to get this local i386 test to run even better please reply and let us all know. P.S. of course my commandline never is that simple, the above is just for illustration. In reality it was more like: $ sudo ~/work/autopkgtest/autopkgtest/runner/autopkgtest --no-built-binaries --apt-upgrade --apt-pocket=proposed=src:re2c --setup-commands="dpkg --add-architecture i386; apt-get update" --shell-fail -a i386 re2c_1.3-1.dsc -- qemu --qemu-options='-cpu host' --ram-size=2048 --cpus 2 ~/work/autopkgtest-focal-amd64.img -- Christian Ehrhardt 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
Re: How to further handle Openssl 1.1.1 in Bionic?
On Thu, Oct 10, 2019 at 12:03 PM Dimitri John Ledkov wrote: > > On Wed, 9 Oct 2019 at 17:41, Christian Ehrhardt > wrote: > > > > Hi, > > in recent weeks since [1][2] there were quite some bugs related to > > rebuilds or feature requests. > > Those kind of issues seemed to be partially expected quoting the bugs SRU > > text: > > > > "OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some software > > is sensitive to the negotiation handshake and may either need > > patches/improvements or clamp-down to maximum v1.2." > > > > Along the SRU some packages were initially identified needing patches > > to either fully support (if doable in an SRU scope) or clamp-down to > > TLSv1.2 and got such changes. > > > > But since then there is a set of bugs [3] coming up for either > > a) "could you also enable TLSv1.3 in package ..." > > b) "Openssl 1.1.1 broke package ..." > > > > There is no generic guidance we can give on what to do with these, as > they need to be on a case by case basis. > > I have submitted a few rebuilds were clearly the code is sensitive to > openssl used at built time and picks up libssl1.1 >= 1.1.1 shared > library dependency based on symbols used, and those got rejected by > the SRU team. > > In general, the point of openssl 1.1.1 SRU was to make openssl > supportable (maintainable, certifiable) over the Bionic timeframe. It > was not to enable TLSv1.3 across the board. I remember we talked about the reasoning before, thanks for the detailed response and filling in the gaps that I had and those that I might have forgotten :-) > We did call the risk of connectivity issues. And those need to be > handled on a case by case basis. SNI was explicitly called out for, > and yes we had to fix about a dozen packages to do that. Arguably > things should have been using SNI for years now, and it is a security > improvement to verify, enforce, and use SNI properly. Thus when issue > is w.r.t. SNI patching to support SNI is the correct course of action > and usually simple to do. > > So far connectivity issues have been minor compared with when we > enabled TLSv1.2, then had to disable it by default (but keep > compiled), then enable it back in. And these days, we are luckly > enough to have openssl.cnf system-wide way to set MaxProtocol=TLSv1.2 > to prevent TLSv1.3 based connectivity issues locally. > > > > > And while some of those seem to be "just work" e.g. a rebuild or small > > patch to enable/disable TLSv1.3 others run into interesting issues as > > openssl has changed more than jsut adding TLSv1.3. > > > > A good example is a bug that was expected to just be a rebuild [4]. We > > have realized there can be subtle effects causing regressions. In the > > particular example it seems that a rebuild not only enabled TLSv1.3, > > but also bumped the minimum dh key size to 2k [5] which in turn breaks > > some older clients and therefore is a no-no from an SRU perspective. > > That's not quite correct assessment of things. We will break people > and will trade connectivity for better security. That's why we have > disabled SSLv3, mitigated poodle attacks, etc. We will continue to > require entropy, and higher key sizes, and better key-exchange > algorithms as we go along. And sometimes that includes security > updates, which SRUs build on top of. The change-effect you describe is > due to a security update of openssl, which trumps SRUs. OpenSSL 1.1.0 > & 1.1.1 have raised a set of minimum key size requirements, mostly > breaking all the test-suites with pre-generated tiny keys, but some > real users too. > > As a local configuration, I believe one can lower OpenSSL security > requirements by setting CipherString = DEFAULT@SECLEVEL=0 which will > bring down requirements down to like pre 1.0.2, but that should only > done as a local site configuration, and clients haunted down and > upgraded/fixed. Great suggestion, I'll give this a try somewhen later. > For the HAPROXY, it would be nice to check if CipherString = > DEFAULT@SECLEVEL=0 "helps" to bring down dh sizes to less secure ones, > and if smaller dh sizes are pre-computed/available still. I would only > call this is a regression, if there really is no way to use smaller dh > sizes and if they are stopped being available at all. > > IMHO the haproxy SRU should not have been accepted, should now be > tagged proposed-regression and removed from bionic-proposed. Which is > a normal SRU process, and retry later. Or like discover some CVE and > ask security team to deal with the rebuild =) > > > The bug [4] currently
How to further handle Openssl 1.1.1 in Bionic?
Hi, in recent weeks since [1][2] there were quite some bugs related to rebuilds or feature requests. Those kind of issues seemed to be partially expected quoting the bugs SRU text: "OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some software is sensitive to the negotiation handshake and may either need patches/improvements or clamp-down to maximum v1.2." Along the SRU some packages were initially identified needing patches to either fully support (if doable in an SRU scope) or clamp-down to TLSv1.2 and got such changes. But since then there is a set of bugs [3] coming up for either a) "could you also enable TLSv1.3 in package ..." b) "Openssl 1.1.1 broke package ..." And while some of those seem to be "just work" e.g. a rebuild or small patch to enable/disable TLSv1.3 others run into interesting issues as openssl has changed more than jsut adding TLSv1.3. A good example is a bug that was expected to just be a rebuild [4]. We have realized there can be subtle effects causing regressions. In the particular example it seems that a rebuild not only enabled TLSv1.3, but also bumped the minimum dh key size to 2k [5] which in turn breaks some older clients and therefore is a no-no from an SRU perspective. The bug [4] currently is assigned to ubuntu-security team for guidance on this - do we want/need this and accept the regression it causes or do we want/need to "clamp-down" the dh key size as well? But this is a generic question - not only in the context of haproxy for [4]. If formerly only "clamping down for TLSv1.2" was considered, do we need to revisit all packages for DH key size as well? ... Even if we don't do anything today, a security update tomorrow might force us to rebuild and trigger this kind of issues for 'potentially' all dependencies of openssl. We already have seen quite some of them being actual regressions in our LTS which is concerning for the potential estimated number of unreported cases. And this is what this mail is about, as more than just bug-triagers and the security-team might have a say and an opinion about it that should be heard. Questions are: - Are other packages known to likely could be affected by that? - How was that planned from the POV of the openssl upload? What are we expected to do in the case of [4] or any similar issue that we find later on? - Do we need to analyze all packages rebuilt since openssl 1.1.1 for such effects? ... If you are involved or have context expertise please help to clarify the questions above for the current issue [4] but also in general. If not I'd still ask everyone to speak up if you know or have seen related issues. Triagers can use the tag "bionic-openssl-1.1" to help tracking those bugs. [1]: https://launchpad.net/ubuntu/+source/openssl/1.1.1-1ubuntu2.1~18.04.1 [2]: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386 [3]: https://bugs.launchpad.net/bugs/+bugs?field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.tag=bionic-openssl-1.1&orderby=status&start=0 [4]: https://bugs.launchpad.net/ubuntu/bionic/+source/haproxy/+bug/1841936 [5]: https://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-4000.html -- Christian Ehrhardt Software 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
Re: Delegating hinting for autopkg failures to core developers and MOTU
On Wed, Apr 10, 2019 at 7:21 AM Matthias Klose wrote: > > Please can we delegate the hinting for autopkg test failures to core > developers > and MOTU? Hi Matthias, I like the idea, but to be specific I assume you only refer to the hinting done in the current dev release. Changes to hinting for released versions should stay with the SRU Team only right? > When ignoring an autopkg test failure, you usually have a reason to do so. > As a > core developer you already can work around autopkg test failures with > uploading > a work-around in a new package version, both for main and universe packages. > The disadvantage is a longer turn-around, re-triggered autopkg tests, > introducing a delta which has to be maintained. MOTU could be limited to only > hint failures for universe packages. > > The current limitation of autopkg related hints being done by the release team > seems to be a technical limitation, because other hints are done by the > release > team only. Of course there should be informal restrictions for hinting during > archive freezes, release freezes. /me has removed a lot of suggestions how to implement things I tried to write as answer at first. I think we need to focus on discussing what we'd want before we go into how to achieve that. Therefore lets see what the discussion brings, as all of this is a bit mix-and-match depending on preferences. Personally I'd appreciate something staged like: A/B depending on how much we want to trust each other :-) A) - overrides to main stay with the release team - overrides to universe can be committed by core-devs (keep some formal checking) B) - overrides to main can be committed by core-devs - overrides to universe can be committed by MOTUs -- Christian Ehrhardt Software 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
Looking for example Package solving sysV+.service+.socket
TL;DR: known example of a package correctly solving sysV+.service+.socket and having only .socket running on install? - Detail - Hello everybody, I want to know if there is any best practise / example on the following case: A package that delivers: - sysV init (for old style compat/backport or just happens to be there) - .service supposed to replace the sysV - the .service should be installed and enabled, but not started in postinst - .socket installed and started on install supposed to be starting the service when needed I've hit a few cases like that now, and in most of them I see - dh_installinit for sysV trumps dh_installsystemd/dh_systemd_* - invoke.rc start is mapped to systemd service start - service ends up started which it shoudl not I have tried different combinations of --no-start and dh_*_override's, but never succeeded to something great so far. Different compat levels have great impact on this as well, unfortunately none resolved it for me. The few cases I know ended up dropping the sysV init to get out of the situation :-/ This is why I wanted to reach out if anybody knows better "prior art" to resolve this. -- Christian Ehrhardt Software 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
Re: call for testing -- qemu / libvirt sandboxing on 18.04 LTS
On Thu, Sep 6, 2018 at 8:20 PM Seth Arnold wrote: > Hello, > > Jann Horn has discovered that qemu's seccomp blacklist is not properly > applied to all threads. This means the security hardening is nearly > useless. > > We'd like to fix this issue so the users who opt-in to the seccomp > filtering will get the benefits they expect. However, this change feels > like it brings more than the usual amount of regression risk, so we'd like > to call for tests from the wider community. > > If you're in a position to try an updated qemu package on 18.04 LTS, > we'd like to hear your results. > Hi Seth, after none of us sent the mail it seems now we both did :-) So let me add some references here FYI. I had already sent the same at [1][2] We had one reply [3] so far with a TL;DR of: - yes sandbox feature is used - proposed change works [1]: https://lists.ubuntu.com/archives/ubuntu-server/2018-September/007740.html [2]: https://lists.ubuntu.com/archives/ubuntu-devel/2018-September/040483.html [3]: https://lists.ubuntu.com/archives/ubuntu-server/2018-September/007741.html > The bug report to coordinate the effort: > https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1789551 > The package repository: > https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3395 > > You may need to set seccomp_sandbox = 1 in your /etc/libvirt/qemu.conf > and restart the libvirt service and any running VMs. > > Some errors may be difficult to spot. Some kernels will report seccomp > denials to dmesg or auditd and some kernels will not report anything. > > Thanks > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- Christian Ehrhardt Software 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
Call for testing to qemu -sandbox users
Hi, TL;DR: If you enabled -sandbox in your Bionic qemu, please test the PPA [2] Details: There is a CVE [1] which we fixed in Cosmic [3], but are unsure to backport to Bionic. Reasons for that are: - there is some regression risk associated which we want to minimize - the sandbox feature it fixes is not enabled by default on Bionic (it is in Cosmic) Per discussion between me and the security Team there are two things gating the backport of this to Bionic. 1. We'd want to know if anybody actually enables -sandbox explicitly in Bionic? 2. if so, it would be great if one of those with a real case could do a verification based on the ppa [2] In case there is no feedback here (this poll might work, but no reply doesn't mean too much) we likely will wait until Cosmic is released for quite a while. That will implicitly test the -sandbox feature including the fix. [1]: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15746 [2]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3395 [3]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1789551 P.S.: sorry for the cross post, but this is trying to maximize the chance to actually find somebody with the conditions in a real setup -- Christian Ehrhardt Software 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
Re: Globally refreshing new group membership - would be needed after some package installations
On Fri, Aug 3, 2018 at 3:28 PM Robie Basak wrote: > On Fri, Aug 03, 2018 at 12:13:15PM +0100, Robie Basak wrote: > > Yeah, so for example starting virt-manager from the desktop shell will > > continue to be a problem until the next login session. > > Actually, now that I think about it, we could adjust the desktop file to > use a wrapper there also. > We will have a discussion on the sprint, but in some experiments I found why I think this is no (good) solution. The reason is that the fix is not bound to the place of the issue. Take the libvirt example which would make some users member of group libvirt on install. - The trigger is in installing libvirt package - But the fix would be in virt-manager, uvtool, ... how many more? - People might wonder why one works but not the other The lack of a better solution might make us use it in some places (Those that matter to users most) still, but I wanted to put words to my concerns :-) -- Christian Ehrhardt Software 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
Re: Globally refreshing new group membership - would be needed after some package installations
On Fri, Aug 3, 2018 at 1:13 PM Robie Basak wrote: > On Fri, Aug 03, 2018 at 12:13:30PM +0200, Christian Ehrhardt wrote: > [...] > > - And the UI itself when click-starting things will not have changed > > Yeah, so for example starting virt-manager from the desktop shell will > continue to be a problem until the next login session. Do you have any > solution in mind for this? No better idea, which was why I was asking for the Mass-Intelligence of 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: Globally refreshing new group membership - would be needed after some package installations
On Thu, Aug 2, 2018 at 1:32 PM Robie Basak wrote: > On Thu, Aug 02, 2018 at 01:16:04PM +0200, Christian Ehrhardt wrote: > > I was wondering if there is a common pattern to resolve this that might > > just be unknown to me yet and that I could use in packaging. > > I have in mind to write a wrapper that checks if "newgrp" or "sg" would > succeed and exec itself via that if so. I'm not aware of this being an > existing pattern though. > > If we wanted to make it a standard thing, we could provide such a > wrapper in a package and then packages that wanted to use it could > register with (and symlink to) the wrapper. > If working this could maybe fixup the terminal it is running in but not more than that. - New terminals started from UI might still have old group membership (if not a new login) - And the UI itself when click-starting things will not have changed I'm a console guy myself, but that would only only fix part of the problem :-/ Especially as the console-addicted folks are those who would mostly have known "that they have to" and "how to" refresh their groups. -- Christian Ehrhardt Software 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
Globally refreshing new group membership - would be needed after some package installations
Hi, In certain cases package installations will have to set up new groups, mostly for access management. Examples are: - libvirt to access /var/run/libvirt/libvirt-sock - lxd to access /var/lib/lxd/unix.socket - ... also sometimes accessing files, but you get the pattern Since logins stay as-is in regard to groups, users have to re-login to pick up those permissions and be able to use the tools. That is often mitigated by: - package being preinstalled, so no one realizes the issue - people deploy a system + set up a recipe automatically and only then log in But then there are certain cases which just "feel" bad - a.k.a: "why can't it just work after being installed". Yes a user can easily open a new terminal or kick su/newgrp/... manually !IF! they know what to do. The next thing that comes to mind is echoing something on install, but who reads those messages - not worth the effort IMHO. Finally none of these commonly discussed options [1][2][3] will be appropriate to be run from a maintainer-script IMHO. Nor would they fixup the Graphical UI that represents a login as well. Please get me right, I have every now and then seen issues of "this kind" and they are often not a big deal - so triage all of those ->wishlist and ignore them, not really. But I find it annoying since we spent so much to make Ubuntu easy to consume and having such rough edges left. I was wondering if there is a common pattern to resolve this that might just be unknown to me yet and that I could use in packaging. OTOH I can already feel the security concerns and bad side effects of "global group membership refreshes" And if there would be a common pattern that really works well - we should probably think of a single dh_group_refresh or something like it instead of per package fixes. I'm afraid there is no such mechanism, but wanted at least to ask instead of giving up prematurely. [1]: https://superuser.com/questions/272061/reload-a-linux-users-group-assignments-without-logging-out [2]: https://serverfault.com/questions/74934/refresh-supplementary-group-memberships-without-logging-in-again [3]: https://unix.stackexchange.com/questions/18796/how-to-apply-changes-of-newly-added-user-groups-without-needing-to-reboot -- Christian Ehrhardt Software 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
Re: Inconsistencies in package versions for stable releases
he existing document by the Security Team[1] lacking any important > > considerations? > > The Security Team has had really good success with the documented > versioning scheme. There are some minor corner cases where -security > uploads have had to deviate slightly. I want to say that mostly had to > do with "security fake syncs" where a Debian package is manually synced > to -security. Maybe a current security team member has more recent > memories than I do and can comment. OTOH, I'd say the scheme works %95 > of the time and the scheme can always be updated once the other 5% is > identified. > > > Can we adopt it as the uniform standard for updates in a > > stable release, or is there a good reason to continue with inconsistency > > here? > > +1 from me for adopting it. I don't enjoy the inconsistency when I'm > sponsoring uploads because I feel like I'm nitpicking about something > that's not widely used/adopted. > > Tyler > > > > > Thanks. > > > > [1] > > > https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging > > > > > > > > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- Christian Ehrhardt Software 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
Deprecation notice for mail-stack-delivery (dovecot) - planned to be dropped in 18.10
Hello, since Ubuntu 18.04 has reached feature freeze we started to think about 18.10. One of the changes ahead is the dropping of the mail-stack-delivery package (part of dovecot). This package was created a long time ago with the intend to simplify several steps of a mail server setup, for example to get a safe ssl secured default installation. It is essentially almost only a postinst to set up some better defaults. But the bit that I can derive from bug reports and such indicates that it is almost unused these days and has become an unused maintenance debt (it started to show it's age - no more matching e.g. recommended ciphers). Furthermore the world has moved on: - For encryption ssl is now default in dovecot-core - In general the hosting your own mail service has become less attractive - If users want to set up a mail server still they often look more for e.g. for Mail-in-a-box [1] For all of these reasons we intend to drop the mail-stack-delivery package in 18.10 If there is a big love/consumption of the package we might have missed please speak up. In that case we likely want to drop it from dovecot still, but community could take over maintenance in a separate package that lives in universe. [1]: https://mailinabox.email/ -- Christian Ehrhardt Software 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
Re: Road to new openssl
On Mon, Jan 29, 2018 at 5:26 PM, Andreas Hasenack wrote: > > > On Mon, Jan 29, 2018 at 9:48 AM, Dimitri John Ledkov > wrote: >> >> >> > > net-snmp >> > >> > Patch available in Debian BTS, was deferred for stretch: >> > https://bugs.debian.org/828449 >> > >> >> Fixed. >> > > It's stuck in excuses due to a hilarious chain of dep8 failures: net-snmp -> > 389-ds-base -> python-ldap -> freipa 389-ds-base I hit as well, FYI: See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888745 And: https://code.launchpad.net/~paelzer/britney/hints-ubuntu-mask-389-ds-base/+merge/336779 > > freeipa (the last upload) is stuck becauase needs bind9 9.11, for which I > have an MP up[1] and am trying to clarify the lwresd drop that Debian did. > > 1. > https://code.launchpad.net/~ahasenack/ubuntu/+source/bind9/+git/bind9/+merge/336719 > > > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- Christian Ehrhardt Software 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
Server team meeting minutes: 2017-09-19
== Meeting information ==
* #ubuntu-meeting: ubuntu-server-team, 19 Sep at 16:01; 16:23 UTC
* Full logs at
[[http://ubottu.com/meetingology/logs/ubuntu-meeting/2017/ubuntu-meeting.2017-09-19-16.01.log.html]]
== Meeting summary ==
=== Review ACTION points from previous meeting ===
The discussion about "Review ACTION points from previous meeting"
started at 16:01.
* ''ACTION:'' nacc to write a release notes entry on ipv6 netboot
(carried over)
* ''ACTION:'' nacc to write a server guide entry on ipv6 netboot
(carried over)
* ''ACTION:'' rbasak to add maintainership info to mysql triage page
(carried over)
=== Artful Development ===
The discussion about "Artful Development" started at 16:03.
* ''LINK:'' https://wiki.ubuntu.com/ArtfulAardvark/ReleaseSchedule
* '''Current Work''' (16:03)
* ''LINK:'' https://trello.com/b/U9HhWyT0/daily-ubuntu-server
* '''Release Bugs''' (16:03)
* ''LINK:''
http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-aa-tracking-bug-tasks.html#ubuntu-server
* ''LINK:'' https://bugs.launchpad.net/~ubuntu-server/+bugs
* ''LINK:'' https://wiki.ubuntu.com/ZestyZapus/ReleaseNotes#Ubuntu_Server
* ''ACTION:'' nacc to consider http2 info in artful release notes
* ''ACTION:'' cpaelzer to add a virt-stack release notes entry
* ''ACTION:'' ahasenack add a release note entry on the bind9 key
signing key change
* ''LINK:'' https://wiki.ubuntu.com/ArtfulAardvark/ReleaseNotes
* ''LINK:'' https://wiki.ubuntu.com/ArtfulAardvark/ReleaseNotes
* ''ACTION:'' smoser to add a cloud init (and if there is something
curtin) release notes entry for artful
Worth to mention are the bugs around the netplan-transition:
* bug 1718227: replacement of ifupdown with netplan needs integration for
/etc/network/if{up,down}.d scripts
* bug 1713803: replacement of resolvconf with systemd needs integration
* bug 1717983: replacement of isc-dhcp-client with with systemd-networkd for
dhclient needs integration
=== Server & Cloud Bugs & SRU/Pending Uploads (slashd, ddstreet) ===
The discussion about "Server & Cloud Bugs & SRU/Pending Uploads
(slashd, ddstreet)" started at 16:10.
* ''LINK:''
http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-z-tracking-bug-tasks.html#ubuntu-server
* ''LINK:''
http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-x-tracking-bug-tasks.html#ubuntu-server
* ''LINK:''
http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-t-tracking-bug-tasks.html#ubuntu-server
* Ryan Beisner is going to review the percona changes that were discussed
=== Weekly Updates & Questions for the QA Team (powersj) ===
The discussion about "Weekly Updates & Questions for the QA Team
(powersj)" started at 16:13.
* ''LINK:'' https://jenkins.ubuntu.com/server/
A KVM is now landed as cloud-init integration test backend, next will be an
actual cloud-provider
=== Weekly Updates & Questions for the Kernel Team (smb, sforshee) ===
The discussion about "Weekly Updates & Questions for the Kernel Team
(smb, sforshee)" started at 16:15.
* ''LINK:'' https://launchpad.net/ubuntu/+source/linux/4.13.0-11.12
Still waiting on 4.13, available in proposed (see the link above)
=== Upcoming Call For Papers ===
The discussion about "Upcoming Call For Papers" started at 16:18.
* ''LINK:'' https://lwn.net/Calendar/Monthly/cfp/
* ''LINK:''
https://mail.openvswitch.org/pipermail/ovs-announce/2017-September/000241.html
* The Open vSwitch project, a Linux Foundation Collaborative
Project, will host its fourth annual conference focused on Open
vSwitch and OVN on November 16 and 17, 2017, at Club Auto Sport in San
Jose, California.
* Please submit proposals to to the following URL by September 29:
https://goo.gl/forms/erjZIQICXVjfUh863
=== Ubuntu Server Team Events ===
The discussion about "Ubuntu Server Team Events" started at 16:19.
=== Open Discussion ===
The discussion about "Open Discussion" started at 16:20.
=== Announce next meeting date, time and chair ===
The discussion about "Announce next meeting date, time and chair"
started at 16:22.
* Next meeting Tuesday, 2017-09-26 at 1600 UTC, chair will be
rharper_sprinting
--
Christian Ehrhardt
Software 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
Potential indirect fallout due to toolchain updates
Hi, all of this is just FYI in case you run into something similar. Recently nut became an FTBFS package, triggered by a combo of: 1. nut's build system having an error 2. nut has default hardening=+all 3. net-snmp configure options disabled -pie 4. changes to our toolchain around PIE TL;DR: - due to PIE now being default chaning hardening= now behaves differently (former "-fPIE" became "", and former "" became "-specs=/usr/share/dpkg/no-pie-compile.specs") - if set on cflags in general LDflags need the matching no-pie-link.specs to work - if you had cases where cflags and ldflags didn't match properly there are chances they break while before tolerating the issue Details on my particular case https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1711092 -- Christian Ehrhardt Software 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
Re: Polling for opinions on removing vm-builder, sandbox-upgrader and auto-upgrade-tester
On Tue, Jul 18, 2017 at 8:25 AM, Christian Ehrhardt < christian.ehrha...@canonical.com> wrote: > On Tue, Jul 18, 2017 at 8:10 AM, Chris Puttick wrote: > [...] > >> So if you want to define us as "upstream" we'd be proud to be making a >> contribution (but in the end we're just scratching our collective itch >> and have found nothing that does it better in the context we work in >> (small-medium size deployments on multiple sites)). >> > > If it solves things for you it might be a solution for more people. > We might remove the unused dependent test packages thou depending how the > feedback looks like. > There was no further call on these (other than stating to be no more used) so I intend to get them removed by an AA. > We'll review the open bugs on Launchpad and any we are up to >> addressing, as sys admins rather than devs ;) , we'll open an issue >> report on our fork (and report back to Launchpad once fixed?). Sound >> like a way forward? >> > > [...] > If you need assistance on the Launchpad bug processing let me (and > probably Serge) know. > Likely initially it is all about commenting on the bugs that you pick (or > reject) and linking the github issues that you open. > I saw that Emilian already updated one of the bugs that it is fixed. Also there is a lot recent activity on [1] which I appreciate - given what I read there maybe even more bugs could be updated to be fixed (or nacked for a reason). I updated the bug [2] with the concluding actions. Thank you everybody for your participation. [1]: https://github.com/newroco/vmbuilder/commits/master [2]: https://bugs.launchpad.net/ubuntu/+source/vm-builder/+bug/1260062 P.S. All of this might still be a bit bumpy for Artful given that the Feature Freeze is just a week out but I look forward to see vmbuild getting usable again from now on. -- Christian Ehrhardt Software 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
Re: "git ubuntu clone": what tags do you expect to see locally?
On Fri, Aug 11, 2017 at 3:24 AM, Michael Hudson-Doyle <
michael.hud...@canonical.com> wrote:
> On 11 August 2017 at 07:19, Robie Basak wrote:
>
>> "git ubuntu clone " is like "git clone", but also knows the URL
>> and some sensible default refspecs.
>>
>> If you then run "git tag", which tags do you expect to have
>> automatically been fetched for you?
>>
>
> I think I would expect to get all tags
>
^^ that - I as well would expect all tags as well.
Having a stampede of tags happens now and then in all kind of repo's and
people are used to deal with it.
Missing them for no reason that appears trivial ("normal" clone fetches
them as you outlined) hurts much more.
And finally since the tags are nicely name-spaced and follow rules they can
easily be filtered out.
--
Christian Ehrhardt
Software 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
Re: Polling for opinions on removing vm-builder, sandbox-upgrader and auto-upgrade-tester
On Tue, Jul 18, 2017 at 8:10 AM, Chris Puttick wrote: [...] > So if you want to define us as "upstream" we'd be proud to be making a > contribution (but in the end we're just scratching our collective itch > and have found nothing that does it better in the context we work in > (small-medium size deployments on multiple sites)). > If it solves things for you it might be a solution for more people. We might remove the unused dependent test packages thou depending how the feedback looks like. > We'll review the open bugs on Launchpad and any we are up to > addressing, as sys admins rather than devs ;) , we'll open an issue > report on our fork (and report back to Launchpad once fixed?). Sound > like a way forward? > Sounds great - lets give you a bit of time, lets say 3.5 weeks and sync again on 14th of August. That hopefully "enough" time for you to go over the issues and get an idea if/how they could be solved. Also it is still before feature freeze to upload a hopefully much better version there. If you need assistance on the Launchpad bug processing let me (and probably Serge) know. Likely initially it is all about commenting on the bugs that you pick (or reject) and linking the github issues that you open. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Polling for opinions on removing vm-builder, sandbox-upgrader and auto-upgrade-tester
On Fri, Jul 14, 2017 at 10:52 AM, Christian Ehrhardt < christian.ehrha...@canonical.com> wrote: Therefore this is a final poll for objections, before pushing harder on the > removal of the whole set of: > - vmbuilder > - sandbox-upgrader > - auto-upgrade-tester > > On this thread there were no reports on any active users of the tools so far. Still looking for any feedback on that part - also a nack to confirm no more (or never) using it will help the decision. In addition it turns out that due to issues in vm-builder a removal was considered in zesty as well [1] Yet OTOH there was some feedback on a number of forks. - by Vacheslav Anzhiganov [2] [3] [4] - and Chris Puttick [5] [6] I appreciate that you two picked up the work on that, you might even combine your efforts. The latter seems slightly more active looking at the changes. Also Serge offered to help SRUing fixes if someone else ensures that the latest upstream works, thanks Serge! But since we need to make a decision I wanted to ask you two directly, if you are willing to continue to maintain it as "the upstream" of the project, handle bug reports and so on. - If you do so it would be great if you could pass through [7] and try to address some of them, coordinate with Serge and me to upload a new one to Artful after this and we can consider SRUs from there - If not - fine as well - we will remove it from the archive and it can continue to live outside of the archive (you could consider [8] as packaging alternative if you'd prefer a more direct way to deliver your code). [1]: https://bugs.launchpad.net/ubuntu/+source/vm-builder/+bug/1618899 [2]: https://launchpad.net/~vanzhiganov [3]: https://github.com/vmbuilder/vmbuilder [4]: https://pypi.python.org/pypi/VMBuilder [5]: https://launchpad.net/~cputtick [6]: https://github.com/newroco/vmbuilder [7]: https://bugs.launchpad.net/ubuntu/+source/vm-builder [8]: https://snapcraft.io/ -- Christian Ehrhardt Software 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
Polling for opinions on removing vm-builder, sandbox-upgrader and auto-upgrade-tester
Hi, due to a few recent bugs in ubuntu-vm-builder I got reminded that whenever vmbuilder comes up, people feel bad and have to excuse a lot as it is essentially un-maintained. All use-cases people seemed to care about are replaced by uvtool [1] which is far more widely used. I happened to realize that it was already tried to be removed for the same reasons [2] in late 2013. It was un-maintained then and hasn't changed. There was a short flicker of an upstream community [3], but not enough to consider it maintained at the moment. If this really comes to life we can add it in later releases. The reasons preventing the removal last time were reverse dependencies from "sandbox-upgrader" and "auto-upgrade-tester". These are Ubuntu only as well and have no reverse dependencies on their own. Furthermore it seems their former (assumed) users are no more utilizing them [4] Therefore this is a final poll for objections, before pushing harder on the removal of the whole set of: - vmbuilder - sandbox-upgrader - auto-upgrade-tester [1]: https://launchpad.net/uvtool [2]: https://bugs.launchpad.net/ubuntu/+source/vm-builder/+bug/1260062 [3]: https://github.com/newroco/vmbuilder [4]: https://irclogs.ubuntu.com/2017/07/13/%23ubuntu-devel.html#t20:43 P.S. this is not just looking for an easy reply-to-all:"yes please keep it". As Serge phrased it so well 3 years ago the alternative is "someone who has the time and technical ability to maintain the package (in past and current releases)" -- Christian Ehrhardt Software 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
Server team meeting minutes: 2017-07-11
Hi, here a summary of the weekly IRC Server team meeting held today. == Meeting information == * #ubuntu-meeting: ubuntu-server-team, 11 Jul at 16:01 — 16:31 UTC * Full logs at [[ http://ubottu.com/meetingology/logs/ubuntu-meeting/2017/ubuntu-meeting.2017-07-11-16.01.log.html ]] == Meeting summary == === Review ACTION points from previous meeting === * ''ACTION:'' nacc to write a release notes entry on ipv6 netboot (carried over) * ''ACTION:'' nacc to write a server guide entry on ipv6 netboot (carried over) * ''ACTION:'' rbasak to add maintainership info to mysql triage page (carried over) * ''ACTION:'' rharper to write a server guide entry on v2 yaml support in cloud-init (carried over) * ''ACTION:'' rharper to write a release notes entry on v2 yaml support in cloud-init (carried over) * Done: dpb look into why this is stalled https://github.com/lxc/pylxd/issues/232 === Artful Development === * ''LINK:'' https://wiki.ubuntu.com/ArtfulAardvark/ReleaseSchedule * ''LINK:'' https://trello.com/b/U9HhWyT0/daily-ubuntu-server * ''LINK:'' http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-aa-tracking-bug-tasks.html#ubuntu-server * No current high profile bugs mentioned === Server & Cloud Bugs & SRU/Pending Uploads (slashd, ddstreet) === * ''LINK:'' http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-z-tracking-bug-tasks.html#ubuntu-server * ''LINK:'' http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-x-tracking-bug-tasks.html#ubuntu-server * SRU pending for : percona-xtradb-cluster-5.5 percona-xtradb-cluster-5.6, cups, sssd, open-iscsi, rsyslog, ksh, neutron * ''LINK:'' https://lists.ubuntu.com/archives/ubuntu-server/2017-July/007559.html === Weekly Updates & Questions for the QA Team (powersj) === * ''LINK:'' https://jenkins.ubuntu.com/server/ * See the status report in the full log === Weekly Updates & Questions for the Kernel Team (smb, sforshee) === * 4.11 to arrive soon in Artful * 4.12 (or more) will eventually be the target kernel * discussion about netplan triggered errors in Artful === Upcoming Call For Papers === * ''LINK:'' https://lwn.net/Calendar/Monthly/cfp/ * ''LINK:'' http://www.open-zfs.org/wiki/OpenZFS_Developer_Summit * ''LINK:'' https://discuss.linuxcontainers.org/t/containers-micro-conference-at-linux-plumbers-2017/262 === Open Discussion === * Daily builds on libvirt and qemu master available * ''LINK:'' https://launchpad.net/~ubuntu-virt/+archive/ubuntu/virt-daily-upstream * Discussion on improving the weekly summary by adding SRUs appearing in unapproved -- Christian Ehrhardt Software 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
Re: Hanging builds on s390x
On Thu, Jun 22, 2017 at 10:44 AM, Christian Ehrhardt < christian.ehrha...@canonical.com> wrote: > You certainly know the actual tests and code better - maybe this already > helps you to debug further. > If you need more please get in touch with me on #ubuntu-devel - Nick: > cpaelzer > FYI - you can stop thinking about it in terms of the LP or s390x build environment. >From [1] to [2] we found [3] being a fix. Yet why this doesn't hit other architectures than s390 nor Debian-s390x is still a riddle to solve. In case you are interested, details are in the IRC log. Good luck Mitya57 to track the rest down! [1]: https://irclogs.ubuntu.com/2017/06/22/%23ubuntu-devel.html#t08:48 [2]: https://irclogs.ubuntu.com/2017/06/22/%23ubuntu-devel.html#t11:57 [3]: http://paste.ubuntu.com/24924317/ -- Christian Ehrhardt Software 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
Re: Hanging builds on s390x
Hi Dmitry, I tried to recreate and think I can. I hopped onto a s390x LPAR got the deb-src of your ppa and ran the following: # prep LP like sbuild environment sudo sbuild-launchpad-chroot create -n artful-LP-s390x -a s390x -s artful cp /usr/share/doc/sbuild/examples/example.sbuildrc /home/ubuntu/.sbuildrc sudo sbuild-update -udcar artful-LP-s390x # build with ppa enabled for dependencies DEB_BUILD_OPTIONS="parallel=4" sbuild -Adartful-LP-s390x --arch=s390x --extra-repository="deb [trusted=yes] http://ppa.launchpad.net/ci-train-ppa-service/2819/ubuntu artful main" qtquickcontrols-opensource-src_5.9.0-1.dsc Then I left it alone but it already hangs at the following for about an hour now - so I think it is the same hang you see: PASS : qtquickcontrols::Tests_Calendar::test_hovered() PASS : qtquickcontrols::Tests_Calendar::test_keyNavigation() SKIP : qtquickcontrols::Tests_Calendar::test_minMaxJsDateRange() QTBUG-36846 Loc: [/<>/tests/auto/controls/data/tst_calendar.qml(180)] PASS : qtquickcontrols::Tests_Calendar::test_minMaxUndefined() QWARN : qtquickcontrols::UnknownTestFunc() file:///usr/lib/s390x-linux-gnu/qt5/qml/QtTest/TestCase.qml:1761: TypeError: Cannot call method 'indexOf' of undefined A quick check on the environment on hanging processes or anything like that showed the following process tree [1]. This tree does not change and hangs forever, so the question is what is the following polling for? ./tst_controls -import /build/qtquickcontrols-opensource-src-rUatts/qtquickcontrols-opensource-src-5.9.0/tests/auto/controls/../testplugin The simple minded solution of killing that hanging process helped to unlock everything - so nothing else seems to infinitely block. This even got me a working build - here the buildlog which pretty much matches your LP builds [2]. The fact that the build completes successful after killing it feels like it is not really waiting on something important but instead should have exited on its own. You certainly know the actual tests and code better - maybe this already helps you to debug further. If you need more please get in touch with me on #ubuntu-devel - Nick: cpaelzer [1]: http://paste.ubuntu.com/24923475/ [2]: http://paste.ubuntu.com/24923511/ On Wed, Jun 21, 2017 at 7:03 PM, Dmitry Shachnev wrote: > Hi all, > > Simon Quigley and I are currently working on Qt 5.9 transition in a PPA > [1]. > > We noticed that some of the Qt packages hang when their tests are run on > s390x. This does not happen on other architectures, and this does not > happen > on Debian s390x buildds (and I cannot reproduce it on zelenka.debian.org). > > Examples of hanging builds: > > - https://launchpad.net/~ci-train-ppa-service/+archive/ > ubuntu/2819/+build/12754612 > - https://launchpad.net/~ci-train-ppa-service/+archive/ > ubuntu/2819/+build/12758700 > - https://launchpad.net/~ci-train-ppa-service/+archive/ > ubuntu/2819/+build/12754642 > - https://launchpad.net/~ci-train-ppa-service/+archive/ > ubuntu/2819/+build/12784776 > > The last one is still running, however the build log indicates that it > hanged > *after* the tests have finished, so it should not be a bug in Qt code. > > Has anybody else seen such issues? If no, maybe some buildd admin can > investigate what happens there? > > [1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2819 > > -- > Dmitry Shachnev > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/ubuntu-devel > > -- Christian Ehrhardt Software 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
Re: Is there a log of Proposed-Migration overrides?
On Wed, Jun 21, 2017 at 1:01 PM, Robie Basak wrote: > On Wed, Jun 21, 2017 at 03:32:00AM -0700, Christian Ehrhardt wrote: > > I wondered about a package being in -updates and thought "was anything > > forced when this migrated"? > > Individual migration run output is logged in > http://people.canonical.com/~ubuntu-archive/proposed-migration/log/. > From a quick look, as verbose as it is, I think details of hints seen at > the time are in there. > Yeah very verbose and many individual logs, but I found the hints being spelled out in there. While I could not find my particular example case in any of the logs of that day so far I might just need to give the parsing more time. > It might be more practical to examine > https://code.launchpad.net/~ubuntu-release/britney/hints-ubuntu for > hints that the release time have added and removed over time. > Thanks I remember hearing of that, the link certainly helps to check them. Thanks a lot! > HTH, > > Robie -- Christian Ehrhardt Software 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
Is there a log of Proposed-Migration overrides?
Hi, Sometimes part of that complexity maintaining a Distribution can be the need of "forcing" proposed-migrations [1]. But I recently faced this from a different point of view. I wondered about a package being in -updates and thought "was anything forced when this migrated"? As far as I asked around nobody knew any place this could be checked. A log like this would allow three things: - clarification if something was forced if ever in doubt - tracking counts in that list would allow to identify issues that really should be fixed to avoid forcing them "regularly" - it could be an extra source of info for Archive Admins that need to solve complex cases Therefore - is there already any log or tracking of those overrides? If not, would that be a reasonable addition and where/how should it be implemented? It some sense it seems to me like an extension to [2] which would add the reasoning if forced. In this particular case I know e.g. that 9.5.7-0ubuntu0.16.10 was forced. [1]: https://wiki.ubuntu.com/ProposedMigration#Are_there_any_exceptions.3F__I.27m_sure_acmefoo_has_just_made_it_into_the_release_pocket_despite_not_satisfying_all_of_the_requirements . [2]: https://launchpad.net/ubuntu/+source/postgresql-9.5/+publishinghistory -- Christian Ehrhardt Software 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 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Is there a log of Proposed-Migration overrides?
Hi, Sometimes part of that complexity maintaining a Distribution can be the need of "forcing" proposed-migrations [1]. But I recently faced this from a different point of view. I wondered about a package being in -updates and thought "was anything forced when this migrated"? As far as I asked around nobody knew any place this could be checked. A log like this would allow three things: - clarification if something was forced if ever in doubt - tracking counts in that list would allow to identify issues that really should be fixed to avoid forcing them "regularly" - it could be an extra source of info for Archive Admins that need to solve complex cases Therefore - is there already any log or tracking of those overrides? If not, would that be a reasonable addition and where/how should it be implemented? It some sense it seems to me like an extension to [2] which would add the reasoning if forced. In this particular case I know e.g. that 9.5.7-0ubuntu0.16.10 was forced. [1]: https://wiki.ubuntu.com/ProposedMigration#Are_there_any_exceptions.3F__I.27m_sure_acmefoo_has_just_made_it_into_the_release_pocket_despite_not_satisfying_all_of_the_requirements . [2]: https://launchpad.net/ubuntu/+source/postgresql-9.5/+publishinghistory -- Christian Ehrhardt Software 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
Re: The transition to add support for Python 3.6 is beginning
Hi Michael, thanks for all the work on this. I checked packages in your list that I often touch and found openvswitch: It fails with: Copying ovs.egg-info to /<>/debian/python3-openvswitch/usr/lib/python3/dist-packages/ovs-2.7.0.egg-info Skipping SOURCES.txt running install_scripts /bin/sh: 2: cd: can't cd to python debian/rules:84: recipe for target 'override_dh_install' failed That is [1] that I fixed in [2]. In general I wonder, other than your work of fixing these issues one-by-one, will you just re-upload new versions of the remaining failed packages iteratively every now and then to see things if like that resolved? Or do you need us other devs to notify you in any known case? [1]: https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/1691658 [2]: https://launchpad.net/ubuntu/+source/openvswitch/2.7.0-0ubuntu2 On Wed, Jun 21, 2017 at 5:13 AM, Michael Hudson-Doyle < michael.hud...@canonical.com> wrote: > Hi all, > > An update on the transition to Python 3.6: Python 3.6 is now a supported > version in artful release, and almost all packages that build C extensions > have been rebuilt (pandas is still a problem). > > We have created a PPA where python3.6 is the default and rebuilt all > python packages: https://launchpad.net/~canonical-foundations/+ > archive/ubuntu/python3.6-as-default/+packages and the next step is to fix > all the failures this reveals. The initial failing source packages are > listed in http://paste.ubuntu.com/24903638/ although some of those have > been fixed now. > > Once the failures are accounted for, we can flip the switch to make python > 3.6 the default in the archive. > > Cheers, > mwh > > On 12 May 2017 at 11:29, Michael Hudson-Doyle < > michael.hud...@canonical.com> wrote: > >> Hi everyone, >> >> The process of adding Python 3.6 as a supported version has begun. >> >> The transition tracker is here: >> >> https://people.canonical.com/~ubuntu-archive/transitions/htm >> l/python3.5-6.html >> >> and I'm currently working my way down the list. >> >> I did a test rebuild of all/most dependent packages in a ppa: >> >> https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+packages >> >> And compiled some terse notes on the failures here: >> >> http://paste.ubuntu.com/24557408/ >> >> And help resolving the failures would be appreciated (especially pandas!) >> >> Cheers, >> mwh >> > > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/ubuntu-devel > > -- Christian Ehrhardt Software 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
Re: Kimchi & Ginger in Ubuntu outdated and broken - update or remove them
On Wed, May 31, 2017 at 4:37 PM, Aline Fatima Manera wrote: > Otherwise, I agree it is better to remove the package than have them > broken there. Thank you Aline, Frederic and Ernst for all your feedback, all we heard so far went went the same direction - so it is more an agreeing than a discussion. Therefore I changed the bug to officially request the packages to be removed in artful. Furthermore as fallback for users who come by the bug missing the package I referred to the ppa and the upstream download page. Frederic did so in this thread already, yet OTOH all your posts seem to wait for moderation I guess so let me summarize here as well. The following is a copy&paste of my last update to the bug so that people can find things in the mail archive as well: @~ubuntu-archive per comments #8 #16 #25 and #29 I think we reached consensus and should remove the following packages from the archive in Artful: - kimchi - ginger Reasoning: - broken - outdated - not maintained - no further dependencies on them that would block Looking for an archive admin that is willing to consider removing them. Unassigning from Frederic and subscribing ~ubuntu-archive so one can pick. FYI - For users who come here "missing" these packages (well likely missing a working version). The projects strategy itself seems to be self provided deb's - while I don't like that you can get it at [1]. Furthermore there is a ppa maintained by IBM which you could use at [2]. But also please read the referred comments and links if you really want that. [1]: https://kimchi-project.github.io/kimchi/downloads/ [2]: https://launchpad.net/~ibmpackages/+archive/ubuntu/kimchi-project/ -- Christian Ehrhardt Software 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
Kimchi & Ginger in Ubuntu outdated and broken - update or remove them
Hi Aline and Frederic, I came along this issue to drop the libvirt-bin dependency [1], but I had to realize that kimchi and ginger hang outdated in the archive since a way too long time. TL;DR: - initial upload in wily - no fix/update since then - upstream development continued - in newer releases broken lacking the upstream fixes - upstream provides out of tree .debs to install I hereby try to reach out to the maintainers that drove the initial uploads into Ubuntu and the recent .deb packages hosted by the kimchi-project. If you are willing and able to update kimchi/ginger to a working state in the Ubuntu Archive please confirm and do that. Otherwise - if e.g. the out-of-archive .deb is the current strategy we should consider removing it from the archive in artful. [1]: pad.lv/1694159 -- Christian Ehrhardt Software 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
Server team meeting minutes: 2017-05-09
Minutes and action items from today's server team meeting are now posted and available here: *https://ubottu.com/meetingology/logs/ubuntu-meeting/2017/ubuntu-meeting.2017-05-09-16.03.html <https://ubottu.com/meetingology/logs/ubuntu-meeting/2017/ubuntu-meeting.2017-05-09-16.03.html>* Next week's agenda is available here: https://wiki.ubuntu.com/ServerTeam/Meeting Thanks! -- Christian Ehrhardt Software 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
Server team meeting minutes: 2017-03-07
Minutes and action times from today's server team meeting are now posted available here: https://ubottu.com/meetingology/logs/ubuntu-meeting/2017/ubuntu-meeting.2017-03-07-16.01.html Next week's agenda is available here: https://wiki.ubuntu.com/ServerTeam/Meeting Thanks! -- Christian Ehrhardt Software 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
Pilot report
pad.lv/1668093 - some debugging, and setting up a bisect run to spot the offending patch helping the reporter to get to upstream with better data. pad.lv/1668557 - helped with performance analysis on IRC ending up identifying the fix in linux-stable and the tuning to get it fixed. Since proper triaging is one of the patch pilots tasks as well I was looking at forgotten server bugs and eventually were triaging 100 (no fake, It really sums up to exactly hundred 3+3+1+10+5+19+22+6+5+16+10 from our triage queue) bugs that were still in "new" or had no update for quite a while. Not so much pilot-sponsoring on these, but a lot of cases users could be helped directly by explaining their logs or guiding them to report to Debian/Upstream instead where it made more sense. -- Christian Ehrhardt Software 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
Re: liblockfile cross compilation guidance
FYI - resolved. Doko replied on IRC [1] and we could sort it out to be a valid sync these days. They build fine - the old issue was that cross build "worked" but created binaries of the wrong architecture. But I verified that the new package is fine in that regard, doing a few more tests now. [1]: https://irclogs.ubuntu.com/2017/02/08/%23ubuntu-devel.html#t09:47 P.S. I just see that Steve replied with about the same content - thanks as well. On Wed, Feb 8, 2017 at 10:40 AM, Christian Ehrhardt < christian.ehrha...@canonical.com> wrote: > Hi, > re-post - this time also reaching out to the full ubuntu-devel list so > that this could be decided before the impending FF next week. > > *TL;DR:* is just dh/dh_auto_configure cross build safe enough these days > to allow liblockfile becoming a syncpackage in zesty? > > *Options:* > >- Yes a sync should be safe for zesty >- No, we still need the delta (adapted to new d/rules) >- No, we want to wait until it stabilized again in Debian and only >consider it in zesty+1 (I have never touched any of the reverse-depends to >this so it is hard for me to decide) > > > *Details:* > >- about the changes in liblockfile: https://github. >com/miquels/liblockfile/blob/master/Changelog ><https://github.com/miquels/liblockfile/blob/master/Changelog> >- about the Ubuntu delta, see my older mail forwarded below > > > -- Forwarded message -- > From: Christian Ehrhardt > Date: Wed, Jan 25, 2017 at 4:17 PM > Subject: liblockfile cross compilation guidance > To: Adam Conrad > Cc: Matthias Klose , Jon Grimm < > jon.gr...@canonical.com> > > > Hi, > I asked on IRC before [1] but it might have been lost. > TL;DR: is just dh/dh_auto_configure cross build safe enough these days? > > I need your advise and experience on general packaging and cross > compilation on that. > The old change is from you Adam, so I wanted to ask you. > Similar (to me) changes I've seen often are from Doko, so I set him on CC > for an extra pack of experience. > > Background: > The package liblockfile was all-the-same for quite a while. > Recently there seems to be an influx of upstream and Debian packaging > activity. > > Our only Delta is "Explicitly set CC with DEB_HOST_GNU_TYPE if we're > cross-compiling." > DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) > +DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) > +DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) > + > +ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) > + export CC = $(DEB_HOST_GNU_TYPE)-gcc > + INSTALL += --strip-program=$(DEB_HOST_GNU_TYPE)-strip > +endif > > > > But the new d/rules dropped almost all and uses almost only dh defaults in > the more recent packaging: > %: > dh $@ > > override_dh_auto_configure: > dh_auto_configure -- --enable-shared --with-mailgroup > > The older Delta is 5 years old since the package didn't change at all. > But the question that I can't answer alone is, if just > dh/dh_auto_configure would be cross build safe enough these days? > And if so if this shall just become a sync then, because that was the only > delta that is left > > [1]: https://irclogs.ubuntu.com/2017/01/24/%23ubuntu-devel.html#t16:16 > > -- > Christian Ehrhardt > Software Engineer, Ubuntu Server > Canonical Ltd > -- Christian Ehrhardt Software 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
Fwd: liblockfile cross compilation guidance
Hi, re-post - this time also reaching out to the full ubuntu-devel list so that this could be decided before the impending FF next week. *TL;DR:* is just dh/dh_auto_configure cross build safe enough these days to allow liblockfile becoming a syncpackage in zesty? *Options:* - Yes a sync should be safe for zesty - No, we still need the delta (adapted to new d/rules) - No, we want to wait until it stabilized again in Debian and only consider it in zesty+1 (I have never touched any of the reverse-depends to this so it is hard for me to decide) *Details:* - about the changes in liblockfile: https://github.com/miquels/liblockfile/blob/master/Changelog - about the Ubuntu delta, see my older mail forwarded below -- Forwarded message -- From: Christian Ehrhardt Date: Wed, Jan 25, 2017 at 4:17 PM Subject: liblockfile cross compilation guidance To: Adam Conrad Cc: Matthias Klose , Jon Grimm < jon.gr...@canonical.com> Hi, I asked on IRC before [1] but it might have been lost. TL;DR: is just dh/dh_auto_configure cross build safe enough these days? I need your advise and experience on general packaging and cross compilation on that. The old change is from you Adam, so I wanted to ask you. Similar (to me) changes I've seen often are from Doko, so I set him on CC for an extra pack of experience. Background: The package liblockfile was all-the-same for quite a while. Recently there seems to be an influx of upstream and Debian packaging activity. Our only Delta is "Explicitly set CC with DEB_HOST_GNU_TYPE if we're cross-compiling." DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) +DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) +DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) + +ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) + export CC = $(DEB_HOST_GNU_TYPE)-gcc + INSTALL += --strip-program=$(DEB_HOST_GNU_TYPE)-strip +endif But the new d/rules dropped almost all and uses almost only dh defaults in the more recent packaging: %: dh $@ override_dh_auto_configure: dh_auto_configure -- --enable-shared --with-mailgroup The older Delta is 5 years old since the package didn't change at all. But the question that I can't answer alone is, if just dh/dh_auto_configure would be cross build safe enough these days? And if so if this shall just become a sync then, because that was the only delta that is left [1]: https://irclogs.ubuntu.com/2017/01/24/%23ubuntu-devel.html#t16:16 -- Christian Ehrhardt Software 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
Re: Ask for guidance on packaging sources with multiple libraries
On Mon, Feb 6, 2017 at 9:40 AM, Christian Ehrhardt < christian.ehrha...@canonical.com> wrote: > *TL;DR:* > How to correctly package a source creating libraries with individual ABI's > bumped separately but that depend on each other and due to that ending up > in mixed versions in the executable after ld.so mapped in dependencies? > I'm reaching out to you as this is a case I have no experience with. > I've thought and discussed on several solutions but I'm sure on none of > them yet. > >- Compat packages with symlinks to the new .so version as it has ABI >backward compat symbols >- Hard inserting the major version (currently 16.11) into every >library version e.g. making the new a librte_eal.so.16.11.3 >- Some magic combination of breaks/conflicts/replaces that prevents >the error window (lib updated, but not consumers) to occur >- Others according to your guidance > > I analyzing the compat package approach of above (see the original mail about some details on the DPDK ABI compat model). That seemed to be the approach being the lowest hanging fruit (a.k.a not revamping big chunks of upstream code). To get more ideas how to package that I was checking the archive for other packages with similar cases. I found several like libcurl, libhwloc and libOSMesa to have symlinks from older sonames. Of those libhwloc appeared to be most similar to our case: libhwloc.so.0 -> libhwloc.so.5 libhwloc.so.1 -> libhwloc.so.5 libhwloc.so.2 -> libhwloc.so.5 libhwloc.so.4 -> libhwloc.so.5 I was studying the packaging of all those and found that in their cases the dependencies where non versioned. Therefore those packages implemented this compat with symlinks to the new soname and as "provides" field for the old named package. But according to [1] "... If a relationship field has a version number attached, only real packages will be considered to see whether the relationship is satisfied ... " Thereby for our case this will likely not work - I confirmed that in an experimental build. >From there the next step was to create explicit (and versioned) packages to hold the symlink to the ABI compatible new version. I implemented that and it works great for all combinations of old/new library and library-consumers, see [2] (this thread also holds more on why just provides fields fail). The change itself is out for review [3] and discussion on deb_dpdk. So I have a solution that works, but wanted to hereby post it to ubuntu-devel before I upload to get an early nack if it has an hidden fault. [1] - https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual [2] - https://lists.alioth.debian.org/pipermail/pkg-dpdk-devel/Week-of-Mon-20170206/11.html [3] - https://gerrit.fd.io/r/#/c/5060/ -- Christian Ehrhardt Software 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
Ask for guidance on packaging sources with multiple libraries
ib/x86_64-linux-gnu/backup-libethdev.so.4 $ ln -s /usr/lib/x86_64-linux-gnu/librte_ethdev.so.5 /usr/lib/x86_64-linux-gnu/libethdev.so.4 With that in place it started correctly Yet DPDK releases all three months, so sometimes we skip versions in the Distribution. That means there could be cases where even this mechanism fails - so if this solution is good for now I'd be happy. But I'd still want to clarify what we would need to do if it is not an option at some point into the future. *## Potential Solutions?: ##* See the TL;DR at the top, but I'm not sure what to go for at the moment, so I hope for your guidance :-/ *## Appendix ##* (FYI Full Dependencies) Prior upgrade: http://paste.ubuntu.com/23939692/ After DPDK Upgraded: http://paste.ubuntu.com/23939693/ -- Christian Ehrhardt Software 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
Server team meeting minutes: 2016-11-22
Full report, more details and log available at: https://wiki.ubuntu.com/MeetingLogs/Server/20161122 SummaryReview ACTION points from previous meeting - *ACTION:* jgrimm: send jamespage email about iscsitarget - Done - no response yet, but started the thread Server & Cloud Bugs & SRU/Pending Uploads (caribou) - caribou: SRUs in play: dhclient, netcfg, qemu, libvirt - others: libvirt, tgt, dovecot, qemu Zesty Development - In general we see merges coming in at a good pace compared to former cycles. Weekly Updates & Questions for the QA Team (powersj) - Work on hardening the cloud-init tests, some of them due to being different when ran in LXD - KVM migration test now all green except one which we are working on. Now we have to check the longer term stability of the tests along the next weeks. Weekly Updates & Questions for the Kernel Team (smb, sforshee) - experiments ongoing with kernel 4.9 for the Zesty alpha Upcoming Call For Papers - no conferences that are relevant at the moment Ubuntu Server Team Events - There is a team internal sprint in two weeks from now. Open Discussion - n/a Announce next meeting date, time and chair - Next chair up will be nacc -- Christian Ehrhardt Software 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
Re: partman, recipes, sizing, swap, and all the things
On Thu, Nov 3, 2016 at 12:52 AM, Dimitri John Ledkov wrote: > As far as I understand, swap performance is better on swap formatted > lvm volume, than a swapfile on a filesystem on an lvm volume. > That is only true for the initial search for swap slots, that is when memory is tight the first time. After the pages have a backing store assigned it should be the same code&speed for both. Overall I'd say the speed argument shouldn't be important here. E.g. 1GB swapfile, but no more than 5% of disk space is simple enough. no? > Since it can be overwritten anyway I personally like that one a lot. I'd expect that almost all setups that will be "not happy" with this simple approach like the "temporary ballooning of memory requirements" you mentioned e.g. in a virtualization environment need a way more complex setup anyway to do it right (spread I/O on multiple disks, tune page-cluster and bulks to your disk I/O HW and so on). The remaining share of people suffering might be those that want to enable Hibernate (non default anyway as you mentioned). Just give them a reasonable and easy path if they want to do so. But I think the overwrite swapsize option will do. But I guess we have to realize that this discussion perfectly qualifies to expect to never make everybody happy anyway. -- Christian Ehrhardt Software 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
Handling qemu machine types for migration
source/libvirt/+bug/1291321 [2] https://wiki.ubuntu.com/QemuPTMigration [3] http://developers.redhat.com/blog/2015/03/24/live-migrating-qemu-kvm-virtual-machines/ [4] https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1294823 [5] https://bugzilla.redhat.com/show_bug.cgi?id=895959 [6] http://lists.nongnu.org/archive/html/qemu-devel/2014-06/msg05376.html [7] https://launchpad.net/ubuntu/+source/qemu/2.0.0+dfsg-2ubuntu1.26 [8] https://access.redhat.com/articles/1444903 [9] https://goo.gl/0VBgGY Old bugs on the topic: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1291321 https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1291321 https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1374612 https://bugs.launchpad.net/ubuntu/+source/ipxe-precise/+bug/1374617 Current bugs on the topic: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1621042 https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1536487 https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1536331 -- Christian Ehrhardt Software 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
Re: Annoucing netplan -- Consolidated YAML network configuration across Ubuntu
Thanks for the feedback, I'll file whishlist bugs as suggested to keep track and hope to find a day I can hide from everything else trying to create some experimental contribution to start things. Minor remaining comments inline below: On Mon, Aug 1, 2016 at 10:02 AM, Martin Pitt wrote: > Hello Christian, > > Christian Ehrhardt [2016-08-01 8:18 +0200]: > > I read through the current yaml and recognized a lot from curtin/Maas > that I > > knew. There is one point I wanted to ... well not discuss, but mention at > > least. > > Please do discuss these. This is meant to be demand driven -- i. e. if > we need a feature for one of our installers, we add it. > > > So in that s390x world and reading this announcement as written with a > > scope of: "unify and clean up networking configuration" I'd miss: > > - a way configure my Network card options (layer2, hwchksum, ..) > > These settings are not currently exposed in NetworkManager or > networkd. You can configure a few layer 2 settings like wake-on-lan, > duplex, or MTU, but not the full range that you can set with e. g. > ethtool. However, netplan could certainly generate udev rules which > apply those settings via e. g. ethtool. udev rule generation already > happens for other purposes (mostly to blacklist a device from NM if it > is configured via networkd), so this isn't too hard in principle. > The hard part might be to avoid conflicts with the tools later on - in that case lszdev/chzdev. Providing an ephemeral rule would be nice to be able to control things, but I'm afraid (and don't want to) of re-implementing chzdevs code. How would it "take over" an ephemeral rule later on if the user changes configuration via chzdev - I have to think about that more. > Needless to say, contributions appreciated :-) (Just keep the test > coverage at 100%). > > > - a way to identify my card by subchannel > > I'm afraid I don't know what that means, this might be a z series > specific concept? This isn't exposed by networkd or NM directly, but > it might be possible that the subchannel is part of the ifnames > generated name so that you can use a name glob? Think of it as a virtual pci-id (some people might want to hurt me now for this comparison) :-) So yet it is currently rendered as part of the ifname subchannel c000 becomes encc000 and is usuable via that. Just that people would likely want to say "c000" please get this config without caring in any way about device naming. But I really think that is way down the priority list since encc000 is rather close. > > So it is a matter of our intended "target": > > - If we think of it as one place to configure all I need for my > networking > > config, but just above a certain level - I think it is ok. > > - If we think of it as one place to configure all I need for my > networking > > config - it is missing something. > > I think the intention is the latter -- with emphasis on what we > actually need to configure in cloud-init, MaaS, subiquity, Ubiquity > etc. > > > To be clear that is not a feature request in any way, I just want to > > ensure that this "separating line" between Network-Hardware and > > Network-Logical configuration is a conscious and intentional > > decision instead of happening accidentally. > > It is not a conscious decision at all. I suggest filing wishlist bugs > against the nplan package or the netplan project to keep track of > these. > > Thanks for your suggestions! > > Martin > -- > Martin Pitt| http://www.piware.de > Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Annoucing netplan -- Consolidated YAML network configuration across Ubuntu
Hi, I read through the current yaml and recognized a lot from curtin/Maas that I knew. There is one point I wanted to ... well not discuss, but mention at least. As a habit I still think in "system z" terms once in a while and in that case this is good as it is "different". And different is good to identify rough edges of spec like this. So in that s390x world and reading this announcement as written with a scope of: "unify and clean up networking configuration" I'd miss: - a way configure my Network card options (layer2, hwchksum, ..) - a way to identify my card by subchannel Both are currently handled by chzdev of [1] (networkd picks up later by card name) and therefore don't apply to configuring networkd/NetworkManager. But they are clearly networking related configurations. So it is a matter of our intended "target": - If we think of it as one place to configure all I need for my networking config, but just above a certain level - I think it is ok. - If we think of it as one place to configure all I need for my networking config - it is missing something. To be clear that is not a feature request in any way, I just want to ensure that this "separating line" between Network-Hardware and Network-Logical configuration is a conscious and intentional decision instead of happening accidentally. More so I think this should be a chance to everyone else to bring up examples that might cross this line even more and should be considered into the netplan yaml. Kind Regards, Christian [1]: https://launchpad.net/ubuntu/+source/s390-tools Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd On Fri, Jul 29, 2016 at 11:14 AM, Martin Pitt wrote: > Hello all, > > The purpose of the new "netplan" project is to unify and clean up > networking configuration in Ubuntu. Currently, Desktop/Server > installers generate ifupdown /etc/network/interfaces, > MaaS/curtin/cloud-init use a YAML based format that gets translated to > /e/n/i, and there is currently no simple way to pre-configure > NetworkManager, and no support for networkd. > > With netplan there are central /etc/netplan/*.yaml network config > files for *all* Ubuntu -- Snappy, Server, Client, MaaS, cloud-init. > All installers only generate such a file, no /etc/network/interfaces > any more. This then gives us the flexibility to dynamically select or > switch between different backends -- for example, there is demand for > moving away from ifupdown towards networkd, and some environments > might prefer NetworkManager for everything. netplan translates the > YAML config to the backend specific configuration formats on boot, but > all these are only written to /run -- i. e. they are ephemeral and not > considered primary configuration files in /etc. > > This is now available in yakkety as "nplan" package. "netplan" already > exists but is something else entirely -- but as we intend to install > it by default everywhere very soon, the package name does not really > matter. > > It currently supports configuring ethernets, wifi (infrastructure, > adhoc, AP), and bridges, which should be the most common device types. > Version 0.4 (just uploaded to yakkety) now also provides documentation > of the configuration as HTML and manpage; the rendered HTML page can > also be seen at [1] for the time being. > > Of course a lot of features are still missing (bonds, routes, > nameservers, veth), there is no upgrade handling from /e/n/i yet, and > it does not start networkd automatically (i. e. if you use it you > currently need to "systemctl enable systemd-networkd"). All these are > being tracked as work items in the blueprint[2] and in bug reports [3]. > > If you are interested in network configuration, or are a > cloud-init/installer/snappy developer etc. who wants to use it, I > appreciate feedback about the YAML format, features, bug reports, etc. > -- for now I reserve the right to break the current YAML format in > incompatible ways, for example if there is a strong desire to change > the structure or rename some properties. This already has been > discussed between Ryan, Scott, Loïc and me for hours though, so > hopefully it won't change dramatically any more ☺ > > Project page: https://launchpad.net/netplan > Code: git clone https://git.launchpad.net/netplan > > Thanks, > > Martin > > [1] http://people.canonical.com/~pitti/tmp/netplan.html > [2] > https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-network-yaml > [3] https://bugs.launchpad.net/ubuntu/+source/nplan > > -- > Martin Pitt| http://www.piware.de > Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) > > -- > 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
Server team meeting minutes: 2016-07-05
Minutes Review ACTION points from previous meeting The discussion about "Review ACTION points from previous meeting" started at 16:03. Yakkety Development The discussion about "Yakkety Development" started at 16:03. - *LINK:* https://wiki.ubuntu.com/YakketyYak/ReleaseSchedule - *LINK:* http://cdimage.ubuntu.com/ubuntu-server/daily/current/ - *Release Bugs* (16:05) - *LINK:* http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-y-tracking-bug-tasks.html#ubuntu-server - *LINK:* http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-x-tracking-bug-tasks.html#ubuntu-server A small discussion about the open bugs, but all were considered covered.Also rharper pointed out that we had the first alpha builds. Server & Cloud Bugs (caribou) The discussion about "Server & Cloud Bugs (caribou)" started at 16:08. caribou was not able attend this week. Weekly Updates & Questions FROM the QA Team The discussion about "Weekly Updates & Questions FROM the QA Team" started at 16:10. We welcomed powersj, but obviously no updates on his first day. Weekly Updates & Questions for the Kernel Team (smb, sforshee, arges) The discussion about "Weekly Updates & Questions for the Kernel Team (smb, sforshee, arges)" started at 16:12. Nothing to report. Upcoming Call For Papers The discussion about "Upcoming Call For Papers" started at 16:14. Packaging of DPDK hopefully to go to a DPDK conference in October. Ubuntu Server Team Events The discussion about "Ubuntu Server Team Events" started at 16:15. Nothing raised. Open Discussion The discussion about "Open Discussion" started at 16:15. A bit of a discussion where to find information and where in IRC to ask for powersj, but surely worth for all. Announce next meeting 12th of July, same time chaired by nacc then The discussion about "Announce next meeting 12th of July, same time chaired by nacc then" started at 16:18. nacc will be next chair, for real [image: Smile :-)] Assigned merges/bugwork (rbasak) The discussion about "Assigned merges/bugwork (rbasak)" started at 16:19. Rbasak was busy in remote participating at debconf. Therefore he will ping and collect status one by one on #ubuntu-server over the week. See logs for details. See the full log at: https://wiki.ubuntu.com/MeetingLogs/Server/20160705 Christian Ehrhardt Software 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
Server team meeting minutes: 2016-05-31
== Meeting information == * #ubuntu-meeting: ubuntu-server-team, 31 May at 16:00 — 16:24 UTC * Full logs at [[ http://ubottu.com/meetingology/logs/ubuntu-meeting/2016/ubuntu-meeting.2016-05-31-16.00.log.html ]] == Meeting summary == Skipping all empty sections === Review ACTION points from previous meeting === No old actions to review. As a bit of a delayed action from two weeks ago nacc was telling us that there will be a v2 of the importer tool this week. === Yakkety Development === The discussion about "Yakkety Development" started at 16:03. * ''LINK:'' https://wiki.ubuntu.com/YakketyYak/ReleaseSchedule * ''LINK:'' http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-y-tracking-bug-tasks.html#ubuntu-server === Server & Cloud Bugs (caribou) === The discussion about "Server & Cloud Bugs (caribou)" started at 16:07. - nothing to discuss === Weekly Updates & Questions for the QA Team === The discussion about "Weekly Updates & Questions for the QA Team" started at 16:09. - nothing to discuss === Weekly Updates & Questions for the Kernel Team (smb, sforshee, arges) === The discussion about "Weekly Updates & Questions for the Kernel Team (smb, sforshee, arges)" started at 16:10. - smb shared that there are indications but no confirmations for a 4.8 kernel in Yakkety. === Upcoming Call For Papers === The discussion about "Upcoming Call For Papers" started at 16:12. No interesting CFPs === Ubuntu Server Team Events === The discussion about "Ubuntu Server Team Events" started at 16:12. None. === Open Discussion === The discussion about "Open Discussion" started at 16:13. - nothing to discuss === next meeting will be in a week date 7th of june, same time - gnuoy will be chairing (I jumped in today) === The discussion about "next meeting will be in a week date 7th of june, same time - gnuoy will be chairing (I jumped in today)" started at 16:15. === Bug Progress === The discussion about "Bug Progress" started at 16:16. - We now regularly track progress on community important bugs here. See the full log for details. Christian Ehrhardt Software 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
