=== ubott2 is now known as ubottu
LocutusOfBorgLaney, how do we proceed with pitivi?06:56
LocutusOfBorgI might have a patch for it07:13
LaneyLocutusOfBorg: I guess kicking it out and then syncing the new version "any day now" is easier than fixing the conflicts08:06
LocutusOfBorgcan you do it?08:12
LocutusOfBorgin any case, I fixed the version, but requires a change in gst-plugins-bad08:12
LocutusOfBorgthe conflict is too strict08:12
Laneyyeah that's what I mean08:14
LaneyI'll boot it out08:14
LocutusOfBorgI'm uploading it right now to groovy, and I'll update the conflict on gst-plugins-bad once it migrates08:15
Laneyhmm then we might as well not kick it out08:15
LocutusOfBorgbut requires a gst-base sourceful upload + autopkgtests08:16
LocutusOfBorgbetter let it migrate first? so I can test it for upgrade paths08:16
LaneyI would prefer to just wait for the sync than add any new deltas08:16
Laneyunless it really does take ages08:16
LocutusOfBorg"upstream is releasing it any day now"08:18
LocutusOfBorgnot 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
Laneyya that is where I'm getting my info from08:19
Laneybut I guess you have a backup plan to execute in a few days if necessary08:19
LocutusOfBorgthe 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 requirement08:20
LocutusOfBorgso yes, we have two plans already08:20
LocutusOfBorgI don't care too much about pitivi, and looks like I already did lots of work on it in the last months08:20
LocutusOfBorgplease let me know if you want something from my side, or you can do it by yourself08:21
Laneyshould go in hopefully08:30
LocutusOfBorgis anybody eating the pending autopkgtests?08:32
LocutusOfBorge.g. I kicked sqlobject test to let setuptools migrate, and got eaten on amd64 (but ran successfully everywhere else)08:33
LocutusOfBorgLaney, wrt https://autopkgtest.ubuntu.com/packages/b/boost1.71/groovy/amd6408:44
LocutusOfBorgRESP BODY: {"forbidden": {"message": "Quota exceeded for ram: Requested 1536, but already used 50688 of 51200 ram", "code": 403}}08:44
LocutusOfBorgcan you please move to big packages?08:44
Laneythat's not what that means08:46
Laneyit means we were using all of our quota in the cloud08:46
Laneyideally this would have not failed but been retried later instead08:46
LocutusOfBorgoh... ok! I was wishing about the feature in the log to easily know when a package needs to move to big packages :D08:47
LocutusOfBorgreading "1536" in the log confused me08:48
Laneyso we could have one test running which uses 51200MB if we wanted :>08:48
Laneybut then maybe the scheduler wouldn't be able to find a node with that amount of memory08:49
LocutusOfBorgit would be nice to check all the failed tests with a machine with more ram, and compare results with the current failures08:50
LocutusOfBorge.g. we are pretty sure petsc4py on arm64 and ppc64el wouldn't fail with more ram08:50
LocutusOfBorgbut proving this is not trivial08:50
nomad_frafter an apt update; upgrade; autoremove; I can't boot anymore my Ubuntu zfs full install.09:48
nomad_frI can live boot, then import the system09:48
nomad_frbut how to restaure the zsys grub things inside bpool09:48
LocutusOfBorgnomad_fr, ubuntu version?10:19
LocutusOfBorgapt dpkg log might help understanding what got removed10:20
LocutusOfBorgLaney, 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.010:56
LocutusOfBorglooks like some libdrm-common not installable...10:58
LaneyLocutusOfBorg: try installing those things in your nearest amd64 chroot10:59
LocutusOfBorgE: Package 'libdrm-common' has no installation candidate11:00
LocutusOfBorgtjaalton, ^^ why should this package be uninstallable in chroot?11:00
LocutusOfBorgin sid chroot it works, and the arch:all libdrm-common has no dependencies11:00
LaneyThe following packages have unmet dependencies. libdrm2 : Depends: libdrm-common (>= 2.4.102-1ubuntu1) but it is not installable11:01
Laneyit's something to do with that11:01
Laneygot a call now, biab11:01
LocutusOfBorgyes but I can't understand why a package like that one can be uninstallable11:02
LocutusOfBorgalso libqt5gui5 is not installable anymore11:03
seb128LocutusOfBorg, https://launchpad.net/ubuntu/groovy/amd64/libdrm-common/2.4.102-1ubuntu1 shows it as superseeded for some reason...11:05
LocutusOfBorgof course if I take then libdrm-common binary it works11:05
seb128LocutusOfBorg, take binary?11:05
LocutusOfBorgseb128, yes, I download the deb of 2.4.102-1ubuntu1 from https://launchpad.net/ubuntu/groovy/+package/libdrm-common11:06
LocutusOfBorgand install it manually11:06
seb128the issue is that it's superseeded11:06
LocutusOfBorgand gst becomes nice11:06
LocutusOfBorgyes sure11:06
seb128could be a question for #launchpad11:06
LocutusOfBorgno change rebuild might help?11:06
seb128I don't understand why it got superseeded11:06
seb128there is no newer version11:06
LocutusOfBorgsure, can you please move there?11:06
LocutusOfBorgyou got the problem, you are the best person to ask, but I can do it if you want11:07
LocutusOfBorgmaybe something in the archive for a short while provided such binary?11:07
tjaaltonLocutusOfBorg:  libdrm-common | 2.4.102-1ubuntu1        | groovy          | all11:39
tjaaltonsays rmadison11:39
tjaaltonthough before apt update apt-cache showed:11:41
tjaalton        500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages11:41
tjaalton        500 http://archive.ubuntu.com/ubuntu groovy/main i386 Packages11:41
tjaaltonand after:11:41
tjaalton        500 http://archive.ubuntu.com/ubuntu groovy/main i386 Packages11:41
=== acheronuk is now known as RikMills
cjwatsonI've copied libdrm-common back in.  Seems to have been an obscure bug in domination, maybe to do with an override change.11:59
tjaaltonok, thanks12:00
Laneythanks for figuring it out!12:06
rbasakxnox: what's the status of bug 1877089? I see it in the SRU queue but its tasks are marked Won't Fix?12:22
ubottuError: Could not gather data from Launchpad for bug #1877089 (https://launchpad.net/bugs/1877089). The error has been logged12:22
xnoxrbasak:  maybe there are bad bug reference numbers.12:26
xnoxrbasak:  which package are you looking at in the queue?12:26
rbasakxnox: zfcpdump-kernel12:27
xnoxrbasak:  please refresh the bug12:29
xnoxrbasak:  i have fixed title and impact. and changed status.12:29
xnoxrbasak:  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
rbasakxnox: sorry I don't really follow the bug at all12:44
rbasakOr why you've chosen to fix it like this, etc12:44
LocutusOfBorgseb128, half of gstreamer migrated, the other half should go in the next britney run12:45
nomad_frI 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 empty12:50
LocutusOfBorgnomad_fr, look for removed packages12:52
rbasakseb128: o/ did you sponsor pulseaudio for Focal?12:53
rbasak3.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_frLocutusOfBorg: I can not just reinstall grub ?12:54
nomad_frLocutusOfBorg: where can I llok for removed package ?12:54
rbasak(and I have yet to review 3.7 as I didn't know that was there initially)12:54
nomad_frLocutusOfBorg: inside my chroot I have this error (couldn't connect to zsys daemon)12:56
LocutusOfBorgnomad_fr, /var/log should be readable from live location12:59
nomad_frLocutusOfBorg:I reinstall from chroot an older Kernel after mounting every thing needed inside my chroot and now it seems ok13:04
xnoxrbasak:  we had three issues. one issue was invalid. two issues remain. in a package which we upload about once every two years.13:07
xnoxrbasak:  thus upload is to focal SRU, which will be copied up to groovy, until 22.04 opens for development.13:08
xnoxrbasak:  because it's a kernel flavour which is infrequently updated.13:08
xnoxrbasak:  and many commments on the bug, are from reporter being confused about secureboot on s390x and that it is incompatible with zfcpdump.13:09
rbasakxnox: 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
rbasakxnox: 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
rbasakxnox: eg. "Switch to 5.4 base from focal" --> why?13:19
Odd_BlokeHey 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?  (Or13:34
Odd_Blokeis it already out of images I haven't considered?)13:34
Odd_Blokerbalint: 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/189677213:36
ubottuLaunchpad bug 1896772 in systemd (Ubuntu) "systemd-resolved configures no Current Scopes on start" [Undecided,New]13:36
rbasakOdd_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
LocutusOfBorgseb128, success!13:58
xnoxrbasak:  because v4.15 will go out of support during focal lifetime; and we forgot to update to v5.4 during focal development.14:07
xnoxrbasak:  current one is broken to the point of being not usable at all on neither focal or groovy.14:08
xnoxrbasak:  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_Blokerbasak: 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
rbasakOdd_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_Blokerbasak: 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_BlokeSo cloud-init would have to add a Depends/Recommends on gnupg{,1,2} for apt-key to work.14:13
Odd_BlokeThough on inspection we do use gnupg directly for fetching keys, so we should probably add the dep regardless.14:13
rbasakOdd_Bloke: I think that's OK. Recommend what you need then assuming cloud-init doesn't need it by default.14:14
rbasakYou 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 implement14:15
Odd_BlokeRight, 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
xnoxOdd_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
xnoxapt-key is dead14:23
nomad_frLocutusOfBorg: here is what I've done : https://lab.neuronfarm.net/nomad/wiki-system/wiki/full-zfs-ecrypt-uefi-boot-trouble14:25
seb128rbasak, 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 ping15:19
seb128tseliot, ^ see https://irclogs.ubuntu.com/2020/09/23/%23ubuntu-devel.html#t12:5315:19
rbasakI can't tell who sponsored unless I accept :)15:22
xnoxrbasak:  and those prior to 1.4 support binary key snippets. which can be used with any apt.16:03
xnox(including xenial)16:03
rbasakxnox: 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
seb128rbalint, '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.changes19:17
seb128rbalint, Changed-By: Alberto Milone19:17
=== SuperKaramba is now known as BenderRodriguez
rbasakseb128: I think that's just the person in the changelog, not the sponsor19:26
seb128rbalint, I guess you are right19:28
=== BenderRodriguez is now known as help
=== help is now known as BenderRodriguez
rbalintseb128, i think rbasak is right, but thanks :-)19:42
rbalintOdd_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 bug19:44
seb128rbalint, indeed, sorry, stupid IRC client completion mode19: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 matches19:47
tjaaltonit doesn't support going through all of them as irssi does?19:47
=== smoser1 is now known as smoser
seb128tjaalton, it does go through them if you notice you hit the wrong one :p19:48
seb128it's more obvious the bash completion way19:49
seb128stop and list all the options unless there is one match19:49
seb128(I had xchat-gnome doing that, I bet it's possible to do in hexchat as well with some option...)19:50
tjaaltonok :)19:50
seb128sil2100, 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 langpacks19:51

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!