=== plars_ is now known as plars | ||
=== ebarretto_ is now known as ebarretto | ||
xnox | doko: you re-added python-minieigen can i drop it again? otherwise it ftbfs against the new boost | 02:25 |
---|---|---|
=== pieq_ is now known as pieq | ||
=== SuperKaramba is now known as BenderRodriguez | ||
=== sparr_ is now known as sparr | ||
=== addyess_ is now known as addyess | ||
cpaelzer | I was finding https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html update slowly the last few days | 07:30 |
cpaelzer | last 24 hours it didn't update at all | 07:30 |
cpaelzer | is anyone aware of details what might be going on ? | 07:30 |
cpaelzer | (I have pinged the last two days but I'm not sure who owns/manages this) | 07:30 |
JackFrost | Urgh, ruby-zip still hasn't migrated.. | 07:31 |
cpaelzer | kanashiro: ^^ FYI | 07:36 |
JackFrost | I hit retest on yet another failing test, hopefully it'll work this time. | 07:36 |
JackFrost | Another == it didn't want to re-test with the "new" ruby-roo, so I had to manually kick them all off. | 07:37 |
Aliekezhi | hi, I'm trying to edit gnome css files but it doesn't seem to have any effect. modifying all of .css files /usr/share/gnome-shell/theme$ | 08:31 |
Aliekezhi | is there another file used by default on ubuntu ? | 08:32 |
jamespage | xnox: I'm having trouble with boost-context on s390x - https://launchpadlibrarian.net/463652248/buildlog_ubuntu-focal-s390x.ceph_15.1.0-0ubuntu1~ubuntu20.04.1~ppa202002051350_BUILDING.txt.gz | 09:33 |
jamespage | for the time being I'm going to disable use on s390x to allow your boost transition to proceed | 09:33 |
ogra | waveform, sil2100 the new flash-kernel breaks all my lxd containers on my pi's ... could we add a runtime test if the environment is a container ? | 09:53 |
doko | tkamppeter: th ghostscript sync without the completed MIR makes a lot of packages now ftbfs | 09:53 |
kanashiro | JackFrost, re ruby-zip: did you do any investigation on s390 autopkgtest failure? | 10:12 |
jamespage | hmm is there something up with the launchpad builders? I swear I just saw a load of active builds for a PPA disappear and restart? | 10:20 |
seb128 | jamespage, probably more a question for #launchpad, but I saw some weird thing happening to one of my ppa builds as well | 10:22 |
sahid | jamespage, coreycb, cinder is ready https://code.launchpad.net/~sahid-ferdjaoui/ubuntu/+source/cinder/+git/cinder | 10:47 |
ogra | waveform, sil2100 seems FLASH_KERNEL_SKIP also became a no-op now ? (at least exporting it doesnt stop f-k from running here) | 10:48 |
waveform | ogra, which version? | 10:51 |
ogra | waveform, https://paste.ubuntu.com/p/xcG6gQkFnc/ | 10:53 |
ogra | thats a freshly pulled bionic container simply running apt update/upgrade | 10:54 |
ogra | (this run with FLASH_KERNEL_SKIP set ... but it doesnt seem to make any difference) | 10:55 |
waveform | ogra, that looks like it can't determine the kernel version (judging by the search paths); FLASH_KERNEL_SKIP *should* still work ... let me check the postinst in the bionic branch | 10:56 |
waveform | ogra, FLASH_KERNEL_SKIP looks like it should still work: https://git.launchpad.net/ubuntu/+source/flash-kernel/tree/debian/flash-kernel.postinst?h=ubuntu/bionic-devel&id=b2fbda45824cfdd2950349979b1cfda52fa86d9d#n48 | 11:04 |
ogra | yeah, that seems to be an issue with the way i execute apt in a non-interactive shell ... | 11:05 |
ogra | yet it would still be cool if it simply detected that it runs inside a contrainer ... that will likely also break armhf docker images on upgrade | 11:06 |
xnox | jamespage: ack and thank you. I will escalate this back to IBM they had students port boost context for ceph specifically, as nothing else important uses it pretty much =) | 11:08 |
tkamppeter | doko, how? Are they using libgs? | 11:17 |
xnox | jamespage: i wonder if i missbuilt it | 11:18 |
waveform | ogra, wouldn't it be better not to have flash-kernel installed at all? I've just tried firing up a bionic container on a pi to see what "linux-version list" returns (nothing, which explains why flash-kernel's getting confused about its search paths), and I note u-boot isn't installed, /lib/firmware doesn't exist, etc. so it seems a bit odd that flash-kernel is there at all? | 11:21 |
ogra | waveform, well, some seed or taks pulls it in for whatever reason ... i agree it should probably not be there | 11:22 |
ogra | *task | 11:22 |
waveform | ogra, that would seem the preferable course of action here - rather than adding logic for detecting various containers to flash-kernel - especially when we've apparently managed to exclude stuff like u-boot and the linux firmware from the image | 11:24 |
ogra | well, it would protect people that accidentially get it pulled in through a dependency | 11:25 |
ogra | (or explicitly install it but then they should perhaps know about FLASH_KERNEL_SKIP) | 11:25 |
ogra | ... though it might make F_K_S unnecessary completely | 11:26 |
waveform | F_K_S seems to be used by the packaging system too (judging from the comments) so I suspect it has some other uses which would keep it around; I'm sure I recall *some* detection code somewhere already but I can't remember where I saw it | 11:27 |
waveform | still, for now I'm definitely leaning toward ensuring our images simply don't include f-k - it's a cleaner solution | 11:27 |
waveform | oh, the initramfs hooks it installs ... that's where the detection is | 11:28 |
jamespage | xnox: its odd because the unit that fails lists boost_context in the list of things to link with | 11:30 |
jamespage | and I only see this on s390x - other archs that have previously built with boost-context continue todo so | 11:31 |
jamespage | sahid: sorry missed your ping - looking now | 11:31 |
xnox | jamespage: i do wonder if some included copies of code leaked into the build. cause there is a copy of boost in ceph, and a system one, which are out of sync on s390x now. | 11:32 |
xnox | (only on s390x they are out of sync) | 11:33 |
jamespage | hmm | 11:33 |
xnox | minor for now, will play with it when everything else is more in shape | 11:34 |
jamespage | yah | 11:36 |
tkamppeter | doko, the openjpeg2 MIR finished finally after 9 years, otherwise I had not done the sync, the urw-fonts MIR should go quickly, as it has no executable code, only data. | 11:41 |
tkamppeter | bug 1862048 | 11:42 |
ubottu | bug 1862048 in fonts-urw-base35 (Ubuntu) "[MIR] fonts-urw-base35" [Undecided,New] https://launchpad.net/bugs/1862048 | 11:42 |
=== mpt_ is now known as mpt | ||
mdeslaur | tjaalton: how do I install the hwe stack on bionic? I tried the instructions here: https://wiki.ubuntu.com/Kernel/LTSEnablementStack but it didn't pull in xorg-server-hwe-18.04... | 12:28 |
mdeslaur | tjaalton: ah, never mind, I fat-fingered it | 12:30 |
tjaalton | :) | 12:30 |
mdeslaur | -ENEEDCOFFEE | 12:30 |
ahasenack | cpaelzer: +1ed https://code.launchpad.net/~paelzer/ubuntu-seeds/+git/platform/+merge/378436 | 12:36 |
ahasenack | rafaeldtinoco: hi, could you perhaps pick this one up? It's related to the i386 work you did in samba: | 12:50 |
ahasenack | LP: #1861316 - (New) [samba] - ubuntu 20.04: libnss-winbind:386 should remain | 12:50 |
ubottu | Launchpad bug 1861316 in samba (Ubuntu) "ubuntu 20.04: libnss-winbind:386 should remain" [High,Triaged] https://launchpad.net/bugs/1861316 | 12:50 |
rafaeldtinoco | ahasenack: I'll get it | 12:57 |
rafaeldtinoco | if its just adding them back it will be easy | 12:57 |
rafaeldtinoco | based on what steve has replied | 12:57 |
ahasenack | yep | 12:58 |
ahasenack | thanks | 12:58 |
=== ricab is now known as ricab|lunch | ||
RikMills | marcustomlinson: smoketest, test-extension & odk-build-examples fail with badpgk as they depend on the nogui packages, which don't seem to exist on armhf | 13:31 |
marcustomlinson | RikMills: interesting, thanks I'll have a look | 13:37 |
cpaelzer | ahasenack: thanks pushing ndctl change | 13:44 |
cpaelzer | cjwatson: also did fix up the report generation \o/ | 13:44 |
cpaelzer | ahasenack: so in a bit we can try to grab an AA and get things moved | 13:45 |
ahasenack | ok | 13:45 |
=== ricab|lunch is now known as ricab | ||
JackFrost | kanashiro: ZipFileExtractTest#test_extract_incorrect_size was the test failure, wanted to see if it'd fix on re-try. | 15:15 |
tkamppeter | doko, could you help on a gcc problem with ppc64: bug 1862053? | 16:03 |
ubottu | bug 1862053 in gcc (Ubuntu) "Compiler gets stuck (or extremely slow) on ppc64el" [High,New] https://launchpad.net/bugs/1862053 | 16:03 |
juliank | tjaalton: OK, got a soft hang with -13 now, while running hangout meet | 16:08 |
juliank | but I mean, hangouts is crazy | 16:09 |
juliank | without iris now, default mesa i915 driver again | 16:10 |
juliank | this is likely a different issue | 16:10 |
tjaalton | check dmesg | 16:11 |
juliank | dmesg just says | 16:12 |
juliank | [10161.268097] i915 0000:00:02.0: GPU HANG: ecode 9:1:0x00000000, hang on rcs0 | 16:12 |
juliank | and then two reset messages | 16:12 |
tjaalton | ok | 16:12 |
tjaalton | file a new bug upstream I guess, saying that the fix from the other one is already included | 16:13 |
juliank | yup | 16:13 |
tjaalton | grab /sys/class/drm/card0/error | 16:15 |
juliank | tjaalton: Yes, sure, I did. I'd love to reboot with drm debug, but I don't want to spam my journal with huge kernel logs :/ | 16:23 |
juliank | Then I can keep a window with netflix running while working and if it hangs we get a lot of nice debug | 16:24 |
juliank | or a hangout meet, but needs lot of people | 16:24 |
tjaalton | you don't need drm debug, it should always save the error state there | 16:25 |
tjaalton | drm debug only shows what the driver is doing, mostly helpful with modesetting issues | 16:25 |
juliank | intel wants that, though, they say | 16:26 |
tjaalton | for hangs? | 16:30 |
tjaalton | it does say things about the hw though | 16:30 |
juliank | tjaalton: forwarded to https://gitlab.freedesktop.org/drm/intel/issues/1150 | 16:31 |
juliank | tjaalton: It's just in their generic bug reporting guidelines | 16:32 |
juliank | aka https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs | 16:32 |
juliank | ah it says and/or a crash dump | 16:32 |
juliank | missed the and/or :D | 16:33 |
tjaalton | ok | 16:33 |
tjaalton | juliank: are you able to modify the mimetype of the attachments of your bug? the error state shows as octet-stream and not text/plain | 17:08 |
juliank | hmm | 17:09 |
tjaalton | oh, I have the same laptop :P | 17:09 |
tjaalton | time to upgrade to focal | 17:10 |
juliank | tjaalton: I re-uploaded it as error.txt, but that did not seem to help | 17:10 |
juliank | in any case it downloads | 17:11 |
juliank | other people simply embed ``` the dump, but that's too much text for me to be comfortable embedding | 17:11 |
juliank | but it should respond text/plain now | 17:12 |
tjaalton | probably just a feature of gitlab, I prefer to open them on the browser | 17:12 |
tjaalton | and a regression compared to bugzilla | 17:12 |
juliank | they're stored in storage.googleapis.com | 17:13 |
juliank | But it redirects with response-content-disposition=attachment | 17:13 |
juliank | it could probably redirect with response-content-disposition=inline or something set | 17:13 |
juliank | you can grab it like this: | 17:14 |
juliank | https://storage.googleapis.com/fdo-gitlab-uploads/%40hashed/f3/6e/f36e412aea00d7c622f3d331c5ceec42eaf18bda2d0374971a09fc79d7d9f293/8dfdebf043239f6d2e192c7826638e99/error.txt?response-content-disposition=inline%3B%20filename%3D%22error.txt%22%3B%20filename%2A%3DUTF-8%27%27error.txt&response-content-type=text%2Fplain&GoogleAccessId=GOOGOEXJKVLVDILPMJ5V2WSY&Signature=kuzMpvRKv0nLaTY7 | 17:14 |
juliank | Cb8b%2F%2BzYsKc%3D&Expires=1581009795 | 17:14 |
juliank | Or you could write a browser extension that rewrites the urls for you | 17:14 |
tjaalton | well, error.txt is at least being opened in an editor, instead of just saving to disk | 17:15 |
juliank | that's good | 17:15 |
tjaalton | but it is what it is :) | 17:15 |
juliank | hmm there's a weird bug in nautilus | 17:17 |
juliank | when you have a video in a directory it has padding at the top of the item grid | 17:17 |
juliank | it's not normally there | 17:18 |
juliank | If you do it with a picture it's at the left | 17:18 |
didrocks | doko: it seems that grub2 is blocked as build-dep on python, should it only bump the build-dep to mention "python2"? | 17:30 |
cjwatson | didrocks: I fixed that to use python3 in Debian some time back | 17:34 |
cjwatson | Like August | 17:34 |
cjwatson | Somebody should merge it | 17:35 |
didrocks | cjwatson: ack, thanks! | 17:35 |
cjwatson | https://salsa.debian.org/grub-team/grub/commit/615a8893413f85c58e59a99948f97ceb9ab5dc16 | 17:36 |
didrocks | cjwatson: I was just looking. I think I’ll cherry-pick to unblock the package. Thanks :) | 17:37 |
mitya57 | xnox, Trevinho: hi, do you know whether we still need the window-mocker package? It is the last package that depends on python-qt4, which I want to remove. | 17:44 |
mitya57 | Its reverse dependencies are python3-autopilot-tests and unity-autopilot and you touched these packages last, that's why I'm asking you. | 17:44 |
Trevinho | mitya57: not that I know | 17:44 |
Trevinho | I suppose we can also get rid of the unity-autopilot one | 17:45 |
mitya57 | If you could do a MP that would be nice. | 17:46 |
mitya57 | Hmm, I think python3-autopilot-tests should depend on python3-windowmocker instead of python-windowmocker. Its other dependencies are already python3-*. | 17:54 |
mitya57 | xnox: ^^^ | 17:55 |
mitya57 | This way we will be able to drop at least the Python 2 version of window-mocker (and python-qt4). | 17:55 |
ahasenack | hi, the package src:vmem was not being synced from debian because it had binaries conflicting with pmdk <= 1.7. I now updated pmdk in focal, it migrated, and was wondering if I need to sync vmem manually, or if a cron job somehwere will take another shot at it | 19:49 |
ahasenack | OK (Y/n)? y | 19:50 |
ahasenack | * Trying to add vmem ... | 19:50 |
ahasenack | vmem_1.8-1 is trying to override modified binary libvmem1_1.7-1ubuntu1. OK (y/N)? n | 19:50 |
ahasenack | let me see when that ran | 19:50 |
ahasenack | hm, looks like 3 times a day | 19:51 |
ahasenack | I'll check again tomorrow | 19:51 |
=== hggdh is now known as hggdh-msft | ||
ahasenack | Skuggen: hi, around? Sorry, I don't know your tz | 20:53 |
xnox | mitya57: ideally i want to drop all of autopilot but i fear it is still used in places - like ubiquity ui tests | 21:56 |
xnox | seb128: Laney: jibel: do we still run the autopilot ubiquity tests? any others? | 21:57 |
xnox | mitya57: and what is python3-windowmocker written in? Imho we should only really need gtk3 python3 portions of autopilot, but i am not sure how to untangle it all | 21:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!