| === ubott2 is now known as ubottu | ||
| LocutusOfBorg | Laney, how do we proceed with pitivi? | 06:56 |
|---|---|---|
| LocutusOfBorg | I might have a patch for it | 07:13 |
| Laney | LocutusOfBorg: I guess kicking it out and then syncing the new version "any day now" is easier than fixing the conflicts | 08:06 |
| LocutusOfBorg | can you do it? | 08:12 |
| LocutusOfBorg | in any case, I fixed the version, but requires a change in gst-plugins-bad | 08:12 |
| LocutusOfBorg | the conflict is too strict | 08:12 |
| Laney | yeah that's what I mean | 08:14 |
| Laney | I'll boot it out | 08:14 |
| LocutusOfBorg | I'm uploading it right now to groovy, and I'll update the conflict on gst-plugins-bad once it migrates | 08:15 |
| Laney | hmm then we might as well not kick it out | 08:15 |
| LocutusOfBorg | but requires a gst-base sourceful upload + autopkgtests | 08:16 |
| LocutusOfBorg | better let it migrate first? so I can test it for upgrade paths | 08:16 |
| Laney | I would prefer to just wait for the sync than add any new deltas | 08:16 |
| Laney | unless it really does take ages | 08:16 |
| LocutusOfBorg | "upstream is releasing it any day now" | 08:18 |
| LocutusOfBorg | not sure what it means, for llvm usually the planned release is delayed by 6 months :) | 08:18 |
| LocutusOfBorg | (there is a merge request and a discussion with the maintainer on the debian rc bug) | 08:18 |
| Laney | ya that is where I'm getting my info from | 08:19 |
| Laney | but I guess you have a backup plan to execute in a few days if necessary | 08:19 |
| LocutusOfBorg | the merge request is ready, so its a matter of editing changelog and uploading :) and I already asked gst-plugins-bad1.0 maintainers to lower that conflict requirement | 08:20 |
| LocutusOfBorg | so yes, we have two plans already | 08:20 |
| LocutusOfBorg | I don't care too much about pitivi, and looks like I already did lots of work on it in the last months | 08:20 |
| LocutusOfBorg | please let me know if you want something from my side, or you can do it by yourself | 08:21 |
| Laney | should go in hopefully | 08:30 |
| LocutusOfBorg | lovely! | 08:31 |
| LocutusOfBorg | is anybody eating the pending autopkgtests? | 08:32 |
| LocutusOfBorg | e.g. I kicked sqlobject test to let setuptools migrate, and got eaten on amd64 (but ran successfully everywhere else) | 08:33 |
| LocutusOfBorg | Laney, wrt https://autopkgtest.ubuntu.com/packages/b/boost1.71/groovy/amd64 | 08:44 |
| LocutusOfBorg | RESP BODY: {"forbidden": {"message": "Quota exceeded for ram: Requested 1536, but already used 50688 of 51200 ram", "code": 403}} | 08:44 |
| LocutusOfBorg | can you please move to big packages? | 08:44 |
| Laney | that's not what that means | 08:46 |
| Laney | it means we were using all of our quota in the cloud | 08:46 |
| Laney | ideally this would have not failed but been retried later instead | 08:46 |
| LocutusOfBorg | oh... ok! I was wishing about the feature in the log to easily know when a package needs to move to big packages :D | 08:47 |
| LocutusOfBorg | reading "1536" in the log confused me | 08:48 |
| Laney | so we could have one test running which uses 51200MB if we wanted :> | 08:48 |
| Laney | but then maybe the scheduler wouldn't be able to find a node with that amount of memory | 08:49 |
| LocutusOfBorg | it would be nice to check all the failed tests with a machine with more ram, and compare results with the current failures | 08:50 |
| LocutusOfBorg | e.g. we are pretty sure petsc4py on arm64 and ppc64el wouldn't fail with more ram | 08:50 |
| LocutusOfBorg | https://launchpad.net/ubuntu/+source/petsc4py/3.13.0-4ubuntu4 | 08:50 |
| LocutusOfBorg | but proving this is not trivial | 08:50 |
| nomad_fr | hi | 09:47 |
| nomad_fr | after an apt update; upgrade; autoremove; I can't boot anymore my Ubuntu zfs full install. | 09:48 |
| nomad_fr | I can live boot, then import the system | 09:48 |
| nomad_fr | but how to restaure the zsys grub things inside bpool | 09:48 |
| LocutusOfBorg | nomad_fr, ubuntu version? | 10:19 |
| LocutusOfBorg | apt dpkg log might help understanding what got removed | 10:20 |
| LocutusOfBorg | Laney, can you please help me parsing what is holding gst now? | 10:56 |
| LocutusOfBorg | * amd64: ges1.0-tools, gstreamer1.0-plugins-bad-apps, gstreamer1.0-rtsp, gstreamer1.0-wpe, libges-1.0-0, libgstrtspserver-1.0-0, python3-ges-1.0 | 10:56 |
| LocutusOfBorg | looks like some libdrm-common not installable... | 10:58 |
| Laney | LocutusOfBorg: try installing those things in your nearest amd64 chroot | 10:59 |
| LocutusOfBorg | E: Package 'libdrm-common' has no installation candidate | 11:00 |
| LocutusOfBorg | tjaalton, ^^ why should this package be uninstallable in chroot? | 11:00 |
| LocutusOfBorg | in sid chroot it works, and the arch:all libdrm-common has no dependencies | 11:00 |
| Laney | The following packages have unmet dependencies. libdrm2 : Depends: libdrm-common (>= 2.4.102-1ubuntu1) but it is not installable | 11:01 |
| Laney | it's something to do with that | 11:01 |
| Laney | got a call now, biab | 11:01 |
| LocutusOfBorg | yes but I can't understand why a package like that one can be uninstallable | 11:02 |
| LocutusOfBorg | also libqt5gui5 is not installable anymore | 11:03 |
| LocutusOfBorg | mmm | 11:03 |
| seb128 | LocutusOfBorg, https://launchpad.net/ubuntu/groovy/amd64/libdrm-common/2.4.102-1ubuntu1 shows it as superseeded for some reason... | 11:05 |
| LocutusOfBorg | of course if I take then libdrm-common binary it works | 11:05 |
| LocutusOfBorg | :/ | 11:05 |
| seb128 | LocutusOfBorg, take binary? | 11:05 |
| LocutusOfBorg | seb128, yes, I download the deb of 2.4.102-1ubuntu1 from https://launchpad.net/ubuntu/groovy/+package/libdrm-common | 11:06 |
| LocutusOfBorg | and install it manually | 11:06 |
| seb128 | the issue is that it's superseeded | 11:06 |
| LocutusOfBorg | and gst becomes nice | 11:06 |
| LocutusOfBorg | yes sure | 11:06 |
| seb128 | could be a question for #launchpad | 11:06 |
| LocutusOfBorg | no change rebuild might help? | 11:06 |
| seb128 | I don't understand why it got superseeded | 11:06 |
| seb128 | there is no newer version | 11:06 |
| LocutusOfBorg | sure, can you please move there? | 11:06 |
| seb128 | me? | 11:06 |
| seb128 | alright... | 11:06 |
| LocutusOfBorg | you got the problem, you are the best person to ask, but I can do it if you want | 11:07 |
| LocutusOfBorg | maybe something in the archive for a short while provided such binary? | 11:07 |
| tjaalton | LocutusOfBorg: libdrm-common | 2.4.102-1ubuntu1 | groovy | all | 11:39 |
| tjaalton | says rmadison | 11:39 |
| tjaalton | though before apt update apt-cache showed: | 11:41 |
| tjaalton | 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages | 11:41 |
| tjaalton | 500 http://archive.ubuntu.com/ubuntu groovy/main i386 Packages | 11:41 |
| tjaalton | and after: | 11:41 |
| tjaalton | 500 http://archive.ubuntu.com/ubuntu groovy/main i386 Packages | 11:41 |
| === acheronuk is now known as RikMills | ||
| cjwatson | I've copied libdrm-common back in. Seems to have been an obscure bug in domination, maybe to do with an override change. | 11:59 |
| tjaalton | ok, thanks | 12:00 |
| Laney | thanks for figuring it out! | 12:06 |
| rbasak | xnox: what's the status of bug 1877089? I see it in the SRU queue but its tasks are marked Won't Fix? | 12:22 |
| ubottu | Error: Could not gather data from Launchpad for bug #1877089 (https://launchpad.net/bugs/1877089). The error has been logged | 12:22 |
| nomad_fr | LocutusOfBorg:20.04 | 12:26 |
| xnox | rbasak: maybe there are bad bug reference numbers. | 12:26 |
| xnox | rbasak: which package are you looking at in the queue? | 12:26 |
| rbasak | xnox: zfcpdump-kernel | 12:27 |
| xnox | rbasak: please refresh the bug | 12:29 |
| xnox | rbasak: i have fixed title and impact. and changed status. | 12:29 |
| xnox | rbasak: we will fix wrong file-name & bumping to v5.4 kernel; but we will not sign it, as mainframe itself doesn't supported signing for zfcpdump. | 12:29 |
| * xnox hopes the bug is now clear. | 12:30 | |
| rbasak | xnox: sorry I don't really follow the bug at all | 12:44 |
| rbasak | Or why you've chosen to fix it like this, etc | 12:44 |
| LocutusOfBorg | seb128, half of gstreamer migrated, the other half should go in the next britney run | 12:45 |
| nomad_fr | I have an Ubuntu Full zfs (with encryption) that I break during an upgrade ... autoremove ... I can chroot inside it from a Live USB, I have my 2 pools bpool ans rpool ... how can I restaure my grub, my trouble is that my grub menu is empty | 12:50 |
| LocutusOfBorg | nomad_fr, look for removed packages | 12:52 |
| rbasak | seb128: o/ did you sponsor pulseaudio for Focal? | 12:53 |
| rbasak | 3.7 was never uploaded, so I think 3.8 should be squashed into 3.7. I would just accept, but it needs fixing up anyway as the changes file is missing the changes from 3.7 so that won't work for tracking on the pending-sru page. | 12:54 |
| nomad_fr | LocutusOfBorg: I can not just reinstall grub ? | 12:54 |
| nomad_fr | LocutusOfBorg: where can I llok for removed package ? | 12:54 |
| LocutusOfBorg | dpkg.log | 12:54 |
| rbasak | (and I have yet to review 3.7 as I didn't know that was there initially) | 12:54 |
| nomad_fr | LocutusOfBorg: inside my chroot I have this error (couldn't connect to zsys daemon) | 12:56 |
| LocutusOfBorg | nomad_fr, /var/log should be readable from live location | 12:59 |
| nomad_fr | LocutusOfBorg:I reinstall from chroot an older Kernel after mounting every thing needed inside my chroot and now it seems ok | 13:04 |
| xnox | rbasak: we had three issues. one issue was invalid. two issues remain. in a package which we upload about once every two years. | 13:07 |
| xnox | rbasak: thus upload is to focal SRU, which will be copied up to groovy, until 22.04 opens for development. | 13:08 |
| xnox | rbasak: because it's a kernel flavour which is infrequently updated. | 13:08 |
| xnox | rbasak: and many commments on the bug, are from reporter being confused about secureboot on s390x and that it is incompatible with zfcpdump. | 13:09 |
| rbasak | xnox: why aren't you uploading to Groovy first and doing the SRU later, as is normal? We benefit from testing in Groovy first as documented in SRU policy - and it also means that if the fix doesn't work, we can work it out without disrupting users multiple times. If you want an exception to this, you should explicitly request it in the bug plase. | 13:16 |
| rbasak | xnox: I also don't understand why such a major change is proposed to hit Focal. What about the risk of regression to existing users? If there are certain to be none (eg. the package is completely broken) then this also needs documenting in the bug please. | 13:17 |
| rbasak | xnox: eg. "Switch to 5.4 base from focal" --> why? | 13:19 |
| Odd_Bloke | Hey folks, we've received a cloud-init bug report because we're using `apt-key` to install GPG keys and the Debian image in question does not have gnupg{,1,2} installed so it fails; it looks like gnupg is in the server seed even in groovy so I assume we won't see this on Ubuntu (yet), but wanted to confirm that assumption: is gnupg expected to come out of any Ubuntu cloud images in the near future? (Or | 13:34 |
| Odd_Bloke | is it already out of images I haven't considered?) | 13:34 |
| Odd_Bloke | rbalint: FYI (and completely unrelated to the above), I started seeing this issue with the systemd upload that migrated overnight: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896772 | 13:36 |
| ubottu | Launchpad bug 1896772 in systemd (Ubuntu) "systemd-resolved configures no Current Scopes on start" [Undecided,New] | 13:36 |
| rbasak | Odd_Bloke: I think I'd favour having enough seeded to make "apt-key" work by default for users. But for cloud-init, shouldn't you Depend or Recommend it and therefore not have to care about the seed itself? | 13:38 |
| LocutusOfBorg | seb128, success! | 13:58 |
| xnox | rbasak: because v4.15 will go out of support during focal lifetime; and we forgot to update to v5.4 during focal development. | 14:07 |
| xnox | rbasak: current one is broken to the point of being not usable at all on neither focal or groovy. | 14:08 |
| xnox | rbasak: if any zfcp bugs arise, that will affect zfcpdump-kernel flavour, and one wouldn't want to patch it for v4.15 on focal. | 14:09 |
| Odd_Bloke | rbasak: I think we should move from using apt-key to dropping files directly in /etc/apt/trusted.gpg.d and solve the problem permanently; I guess the question was really whether this is something we need to address in time for groovy, and it sounds like the answer is no. | 14:09 |
| rbasak | Odd_Bloke: I think you're fine for now, though it might still be more correct to add apt-key as a recommend for now in Groovy. Then people will notice before dropping apt-key. | 14:12 |
| Odd_Bloke | rbasak: The problem is that apt-key is shipped by apt and only tells you at runtime that you haven't got the requisite packages installed. | 14:12 |
| Odd_Bloke | So cloud-init would have to add a Depends/Recommends on gnupg{,1,2} for apt-key to work. | 14:13 |
| Odd_Bloke | Though on inspection we do use gnupg directly for fetching keys, so we should probably add the dep regardless. | 14:13 |
| rbasak | Odd_Bloke: I think that's OK. Recommend what you need then assuming cloud-init doesn't need it by default. | 14:14 |
| rbasak | You might want to wait until Bionic is the oldest supported release prior to changing your implementation, FWIW, since apt-key(8) suggests apt >= 1.4 supports ASCII armored format which might be much cleaner to implement | 14:15 |
| Odd_Bloke | Right, so it sounds like a Recommends on gnupg in at least groovy and later, and then we can figure out how to phase out the apt-key usage at our leisure. | 14:22 |
| xnox | Odd_Bloke: "I think we should move from using apt-key to dropping files directly in /etc/apt/trusted.gpg.d and solve the problem permanently" yes please. | 14:23 |
| xnox | apt-key is dead | 14:23 |
| nomad_fr | LocutusOfBorg: here is what I've done : https://lab.neuronfarm.net/nomad/wiki-system/wiki/full-zfs-ecrypt-uefi-boot-trouble | 14:25 |
| seb128 | rbasak, hey, no, tseliot sponsors that pulseaudio and indeed it seems Daniel updated git for 3.7 but didn't get that sponsored, thanks for the ping | 15:19 |
| seb128 | tseliot, ^ see https://irclogs.ubuntu.com/2020/09/23/%23ubuntu-devel.html#t12:53 | 15:19 |
| rbasak | Thanks. | 15:22 |
| rbasak | I can't tell who sponsored unless I accept :) | 15:22 |
| xnox | rbasak: and those prior to 1.4 support binary key snippets. which can be used with any apt. | 16:03 |
| xnox | (including xenial) | 16:03 |
| rbasak | xnox: could you document that all in the bug please? And I'm not sure you answered my question as to why this can't be fixed in Groovy first? | 17:05 |
| seb128 | rbalint, 'I can't tell who sponsored unless I accept :)' ... that's not true, just click on the .changes from the queue, e.g https://launchpadlibrarian.net/498511673/pulseaudio_13.99.1-1ubuntu3.8_source.changes | 19:17 |
| seb128 | rbalint, Changed-By: Alberto Milone | 19:17 |
| === SuperKaramba is now known as BenderRodriguez | ||
| rbasak | seb128: I think that's just the person in the changelog, not the sponsor | 19:26 |
| seb128 | rbalint, I guess you are right | 19:28 |
| === BenderRodriguez is now known as help | ||
| === help is now known as BenderRodriguez | ||
| rbalint | seb128, i think rbasak is right, but thanks :-) | 19:42 |
| rbalint | Odd_Bloke, i have next systemd point release cooking in https://bileto.ubuntu.com/#/ticket/3801 in case you would like to give it a shot, but will check the problem, thanks for the bug | 19:44 |
| seb128 | rbalint, indeed, sorry, stupid IRC client completion mode | 19:46 |
| * seb128 needs to figure out how to tell hexchat to not complete on first match nick but to stop in case there are several matches | 19:47 | |
| tjaalton | it doesn't support going through all of them as irssi does? | 19:47 |
| === smoser1 is now known as smoser | ||
| seb128 | tjaalton, it does go through them if you notice you hit the wrong one :p | 19:48 |
| sarnold | :) | 19:49 |
| seb128 | it's more obvious the bash completion way | 19:49 |
| seb128 | stop and list all the options unless there is one match | 19:49 |
| seb128 | (I had xchat-gnome doing that, I bet it's possible to do in hexchat as well with some option...) | 19:50 |
| tjaalton | ok :) | 19:50 |
| seb128 | sil2100, hey, should we start doing langpack updates to G? also I don't know what we usually do for SRUs but the round of updates we did in focal for .1 wasn't done in the newest serie which means F is never than G for langpacks | 19:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!