| * mwhudson uploads glibc 2.35 to jammy | 01:00 | |
| * sergiodj braces for impact | 01:12 | |
| sergiodj | kidding aside, thanks mwhudson | 01:12 |
|---|---|---|
| * JackFrost watches as everything ftbfs. | 01:12 | |
| mwhudson | JackFrost: it shouldn't be too bad this time | 01:13 |
| JackFrost | \o/ | 01:13 |
| mwhudson | 2.34 was worse for sure | 01:13 |
| JackFrost | mwhudson: ...Do you still manage golang stuff? Mentally I still have you assigned as the Ubuntu go guy. :P | 01:13 |
| mwhudson | JackFrost: a bit but not so much these days | 01:14 |
| === genii is now known as genii-meeting | ||
| === JanC is now known as Guest7251 | ||
| === JanC_ is now known as JanC | ||
| === genii-meeting is now known as genii-core | ||
| === not_phunyguy is now known as phunyguy | ||
| sergiodj | llvm-toolchain-12 uploaded with the fix to unblock ocaml | 04:14 |
| === sem2peie- is now known as sem2peie | ||
| === sem2peie- is now known as sem2peie | ||
| seb128 | slyon, hey, the protobuf-c autopkgtest you added is going to test the binary from a new build, not the current package version no? | 13:22 |
| slyon | seb128: that's true. Though, it is build in the same way, using debhelper | 13:23 |
| seb128 | slyon, right, but if there is a change in a depends that makes the library be buggy until it's rebuilt then the autopkgtest isn't going to show the issue for example | 13:23 |
| slyon | seb128: yes. I will look into improving this! | 13:25 |
| seb128 | slyon, thanks! | 13:25 |
| seb128 | slyon, one standard test desktop libs usually is to build a small code example using the lib and try to start it | 13:26 |
| seb128 | at least you ensure the .pc/dev depends are right and that the lib is loading | 13:26 |
| seb128 | slyon, an example in case it's of any use to you, https://salsa.debian.org/gnome-team/libhandy-1/-/blob/debian/master/debian/tests/build-test | 13:27 |
| slyon | seb128: thanks that should be helpful! | 13:28 |
| ahasenack | how do I record in DEP3 the authorship of a patch to https://launchpad.net/~dzfranklin ? | 14:44 |
| ahasenack | there is just a name, no email | 14:44 |
| ahasenack | can I use the LP URL? | 14:44 |
| ahasenack | or Name <lpurl>? | 14:44 |
| kanashiro | ahasenack, I've seen people adding only the name but I think in this case "name <lpurl>" works better | 14:47 |
| ahasenack | +1 | 14:47 |
| * ahasenack waits for the bug number from debian's bts | 14:51 | |
| sergiodj | doko: llvm-toolchain-12 is FTBFS on i386 now, so I will revert the changes you made yesterday now that the autopkgtest has been fixed | 15:21 |
| doko | sergiodj, but the failure is about the missing libRemoteIndexProto.a which I didn't touch ... | 15:34 |
| sergiodj | doko: I did | 15:34 |
| sergiodj | see the latest upload | 15:34 |
| doko | I'm confused why you want to revert my changes not building ocaml ... | 15:35 |
| sergiodj | doko: in order to fix the autopkgtest issue, I uploaded a change (19ubuntu2) to actually install the libraries that were being previously removed. however, your upload (19ubuntu1) disabled GRPC on i386, which means we the libraries won't exist there, and that is causing the FTBFS (dh_install tries to install the two libraries which don't exist on i386) | 15:38 |
| sergiodj | ah, I see that protobuf-compiler-grpc isn't available in i386. now I understand why you made these changes | 15:39 |
| sergiodj | sigh... | 15:39 |
| doko | yes, exactly | 15:40 |
| sergiodj | I'll have to think about it. I'm in the middle of something else now | 15:40 |
| ahasenack | doko: do you also handle i386 issues? ndctl in jammy-proposed grew a dependency on iniparser which is not built for i386, so ndctl can't be built on i386. We either allow iniparser on i386, or stop building ndctl for i386 | 16:01 |
| ahasenack | https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1959892 | 16:02 |
| ubottu | Launchpad bug 1959892 in ndctl (Ubuntu) "FTBFS i386: missing libiniparser-dev on i386" [Undecided, New] | 16:02 |
| doko | ahasenack, I'll enable that | 16:03 |
| ahasenack | iniparser on i386? | 16:03 |
| ahasenack | or disable ndctl/i386? | 16:03 |
| doko | the former: https://launchpad.net/ubuntu/+source/iniparser/4.1-4ubuntu3 | 16:05 |
| kanashiro | fun, ruby-defaults is blocked by ocaml and ocaml seems to be blocked by python3-defaults :) | 16:08 |
| doko | well yes, it doesn't help that ruby-defaults sticks in -proposed for more than two months | 16:10 |
| kanashiro | doko, there was a EOY break and also a bunch of packages to be fixed | 16:11 |
| doko | understood, just saying that it sticks there for 50% of our development time in the cycle doesn't help | 16:13 |
| ahasenack | doko: thanks, I'll take care of ndctl after that | 16:15 |
| kanashiro | tbh we have more people fixing for instance python packages than ruby packages | 16:16 |
| kanashiro | coordinate fixes with debian and upstream takes time | 16:17 |
| vorlon | jbicha: is the gst-plugins-good1.0 build-dependency on libqt5waylandclient5-dev important on i386? Not sure how deep the stack of qt dependencies goes that we'd have to bring up on i386 for this | 16:28 |
| xnox | vorlon: i think cmake:i386 wants qt and lots of things need cmake to build (or something like that) | 16:57 |
| xnox | but it probably can be cut somehwere | 16:57 |
| vorlon | xnox: that has nothing to do with libqt5waylandclient5-dev? | 17:00 |
| jbicha | vorlon: it's not very important (we skipped the dependency for 21.10) but potentially one extra diff with Debian. On the other hand, we aren't able to sync -good anyway | 17:01 |
| vorlon | jbicha: ok. do you want to handle building without on i386 so that it can migrate? | 17:01 |
| jbicha | it was temporarily dropped for impish, I believe because it was late in the release cycle & that seemed to help the update migrate out of proposed faster | 17:01 |
| xnox | juliank: vorlon: we don't have archive copies of update_excuses.html do we? | 17:09 |
| xnox | i guess i will troll through the logs | 17:09 |
| laney | xnox: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses/jammy/ | 17:15 |
| laney | the .gz is kind of annoying :-) | 17:15 |
| ahasenack | how can I find out why this package was removed from debian? https://tracker.debian.org/pkg/libcxl | 17:27 |
| ahasenack | I don't see a bug | 17:27 |
| bdmurray | "Hint: Package not in unstable" | 17:28 |
| bdmurray | Oh, that's not uninstallable | 17:28 |
| xnox | laney: nice! thanks. | 17:28 |
| bdmurray | ahasenack: https://ftp-master.debian.org/removals.txt "obsolete source package" | 17:30 |
| ahasenack | and debian's ndctl is now building libcxl1 and libcxl-dev (see bottom left corner), with the exact same name as the binaries produced by the former libcxl, but for an entirely different purpose: https://tracker.debian.org/pkg/ndctl | 17:30 |
| ahasenack | can package names be reused like that? | 17:30 |
| ahasenack | and, should we remove src:libcxl from ubuntu too, now? | 17:31 |
| jbicha | ahasenack: I believe that's an RC bug in Debian for a package to do that without coordination | 17:48 |
| ahasenack | it's odd at the very least | 17:50 |
| ahasenack | I pinged the ndctl maintainer in #debian-devel | 17:50 |
| jbicha | yeah, my guess it was unintentional | 17:50 |
| jbicha | we could open a block-proposed bug in Ubuntu for it. But Debian will have to fix it for everyone anyway | 17:53 |
| jawn-smith | tjaalton: I heard you had some issues with booting on a zfs encrypted device? | 18:11 |
| jawn-smith | I just got hit by that as well. If you saw it too perhaps it will help figure out the root cause | 18:11 |
| tjaalton | jawn-smith: upgraded from impish? | 18:14 |
| tjaalton | I had to do a rollback to a snapshot before the dist-upgrade | 18:15 |
| tjaalton | just finished.. | 18:15 |
| jawn-smith | Yes, though the upgrade was done quite a while ago. I did an apt upgrade of a bunch of packages yesterday which I suspect caused the issue | 18:16 |
| tjaalton | ok | 18:16 |
| jawn-smith | the root of the issue was that my system.key had been moved to a new location | 18:16 |
| tjaalton | so you at least had a working zfsutils-linux installed so rollback to a snapshot works | 18:17 |
| jawn-smith | I was able to fix it by setting zfs properties from the initramfs shell | 18:17 |
| tjaalton | the sru sat in proposed for almost four months | 18:17 |
| tjaalton | unverified, should move next week | 18:18 |
| jawn-smith | which sru is this? | 18:19 |
| tjaalton | https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1946808 | 18:19 |
| ubottu | Launchpad bug 1946808 in zfs-linux (Ubuntu Impish) "zfs fails reverting to a previous snapshot on reboot when selected on grub" [Critical, Fix Committed] | 18:19 |
| tjaalton | what changed in the key path? | 18:22 |
| jawn-smith | okay so that likely would have helped fix the issue I saw, but doesn't explain what happened to my zpool in the first place. Do you know what caused your system to not boot? Were you also dropped to an initramfs shell after entering your password? | 18:28 |
| tjaalton | yes | 18:29 |
| jawn-smith | okay, so we likely saw the same issue then. I'll try to recreate on my laptop so I can gather more info | 18:30 |
| tjaalton | the bug above was about mounting snapshots | 18:30 |
| tjaalton | what did you change the keypath to? | 18:30 |
| jawn-smith | Originally I had the option set as file:///run/keystore/rpool/system.key | 18:32 |
| jawn-smith | but somehow system.key was moved to /run/keystore/system.key | 18:32 |
| jawn-smith | so `zfs set keylocation=file:///run/keystore/system.key rpool` | 18:32 |
| tjaalton | xnox: ^ | 18:33 |
| tjaalton | oh, it's caused by 'dirname' not found on the initramfs | 18:42 |
| tjaalton | pool="$(basename $(dirname ${ks}))" | 18:44 |
| tjaalton | that's why it asked 'Please unlock disk keystore-' instead of 'keystore-rpool' | 18:45 |
| tjaalton | and the path is wrong | 18:45 |
| jawn-smith | ah yeah I was seeing that | 18:48 |
| jawn-smith | oh so that's a foundations bug I guess | 18:54 |
| vorlon | sil2100: thanks for the ubiquity merge; fwiw d-i/source/README does state that the use of the per-project branches is optional, and we're not likely to ever merge these things from Debian again :) | 19:42 |
| === Unit193 is now known as JackFrost | ||
| ahasenack | jawn-smith: just found this, but there is no jammy build: https://launchpad.net/~ansible/+archive/ubuntu/ansible | 20:21 |
| jawn-smith | oh huh | 20:22 |
| jawn-smith | I'll try building against jammy/python3.10 | 20:23 |
| jawn-smith | I bet a build will work, though autopkgtests are a different story | 20:23 |
| jawn-smith | Targeting that 5.3.0-1 that exists in impish | 20:23 |
| ahasenack | the packaging layout might be super different than the one from debian, even debian/experimental | 20:25 |
| ahasenack | but maybe, if it installs, we get more info about that broken symlink | 20:25 |
| jawn-smith | yeah, there aren't even any tests in it haha | 20:36 |
| jawn-smith | by that I mean anything in d/tests/ for an autopkgtest to run | 20:37 |
| jawn-smith | it sbuilt fine though | 20:52 |
| ahasenack | with python 3.10? | 21:01 |
| ahasenack | jammy-proposed? | 21:01 |
| melodie | hi | 21:16 |
| melodie | I wonder what package or files are used in the live images for the first screens where one chooses the language to boot into? Dees someone have a hint on that? | 21:17 |
| sarnold | subiquity? | 21:18 |
| sarnold | err, probably ubiquity ; I think subiquity is the server version, sorry | 21:18 |
| melodie | is that so? I'll check right away | 21:18 |
| dbungert | melodie: server or desktop image? | 21:18 |
| melodie | dbungert, desktop image | 21:18 |
| dbungert | ubiquity is the one you want unless you're trying out the new "canary" desktop image | 21:19 |
| melodie | dbungert, what is the canary image? | 21:20 |
| melodie | I was making a master for a project, and I happened to have the language choice at boot not working right anymore | 21:20 |
| melodie | if I reinstall ubiquity it should solve it then? | 21:20 |
| melodie | when I say not working right, I mean : in the boot stanza some lines are translated and some are still in English | 21:21 |
| melodie | instead of being all in the same language | 21:21 |
| jbicha | I don't think that part comes from ubiquity | 21:26 |
| melodie | jbicha, perhaps it isn't. Do you know of any other leads I could test? I have tried reinstalling some packages that are in an original Ubuntu edition and were not on my master, but that has not helped and I don't know what else I could try before starting all over again | 21:31 |
| jbicha | it's not very likely that reinstalling will fix that. I think the translations are probably actually incomplete | 21:32 |
| jbicha | oh wait, you are using a custom Ubuntu build? that makes things a lot more complicated | 21:33 |
| jbicha | it's been a long time since I've dealt with the low level installer booting. There are multiple components: casper, isolinux, grub (probably others) | 21:35 |
| seb128 | if it's only on your remix and not on the ubuntu image then it's probably not a bug in ubuntu | 21:35 |
| melodie | I started months ago with a Xubuntu edition which I modified, using the Customizer script (available on github), and stripped it too much resulting in this issue. But recently I made it grow again and comparted all packages between the same Xubuntu version/edition and my spinoff, and installed anew whatever was missing in the system. I thought it would solve it but it didn't. | 21:37 |
| melodie | comparted/compared (sorry for the typo) | 21:37 |
| melodie | I used a diff file (diff -y) from both filesystem.manifest files | 21:38 |
| melodie | so I made sure all the languages files available in Xubuntu were there too, among else | 21:41 |
| === genii-core is now known as genii | ||
| seb128 | but do you have the issue on a stock xubuntu image? | 21:42 |
| jbicha | one of the strongest motivators for me to request official flavor status for Ubuntu GNOME was because it was a pain building my own ISOs 🙂 | 21:43 |
| melodie | seb128, not at all, only on the stripped master I made from it, which I am not trying to make a bigger version | 21:43 |
| melodie | jbicha, you did well! | 21:44 |
| melodie | aside from that, it works. Perhaps if I come back here during the week work hours someone will be able to give me the right pointers | 21:59 |
| melodie | here are two pics, https://linuxvillage.org/Downloads/VirtualBox_bento-lts-tests_04_02_2022_22_56_13.png https://linuxvillage.org/Downloads/VirtualBox_bento-lts-tests_04_02_2022_22_58_16.png | 22:03 |
| melodie | for a description, here would be the minimal version, very small : https://linuxvillage.org/en/blog/2022/01/13/bento-openbox-remix-20-04-core | 22:04 |
| melodie | when I first started in 2012 I used Ubuntu Mini Remix for a base, but a few years ago Fabrizio Balliani stopped producing them. | 22:09 |
| melodie | thanks, good night | 22:43 |
| jawn-smith | tjaalton: and any other developers. I have a fix for the issue of zfs encrypted installs no longer booting. I uploaded a patch to bug 1960083 | 22:57 |
| ubottu | Bug 1960083 in busybox (Ubuntu) "dirname applet missing from initramfs" [High, In Progress] https://launchpad.net/bugs/1960083 | 22:57 |
| jawn-smith | I'm confident that it works, but because busybox has security implications I'd like another set of eyes on it before I go ahead and dput this | 22:58 |
| === genii is now known as genii-core | ||
| jawn-smith | I'm going to hold off on uploading that for now, but a PSA to others running the development branch: | 23:16 |
| jawn-smith | if you're running a system with zfs encryption, avoid updating cryptsetup until busybox-initramfs has been updated. If you do end up in this situation however, run `zfs set keylocation=file:///run/keystore/system.key rpool` from the initramfs and reboot | 23:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
