[02:36] <chelz> any particularly good charities in the bay area or san francisco for old computer hardware?
[16:19] <pleia2> nhaines: nector is absolutely like post fruity cereal milk
[16:54] <philipballew> Reminder people: We have the San Diego hour today
[16:54] <philipballew> https://www.meetup.com/Ubuntu-California/events/238377125/
[16:54] <darthrobot> Title: [Ubuntu San Diego Meetup - Ubuntu California LoCo (Los Angeles, CA)| Meetup]
[16:54] <philipballew> Im going install Ubuntu Server live. Probably will take and enter any commands the attendees want
[16:55] <philipballew> Also probably will bring a growler. But if people come and dont act like an adult, that will be a regret I have.
[22:48] <nhaines> pleia2: Haha, someone said Apple Jacks, which I thought has merit.  Where'd you find one?  :D


[06:33] <cpaelzer> good morning
[08:41] <cult-> xnox: when it's going to be released just out of curiosity?
[09:00] <cpaelzer> hmm, when I upgrade from A to a newer A' which now has a recommends to B will be auto-installed on the upgrade
[09:01] <cpaelzer> I know it would on install
[09:01]  * cpaelzer heads raeading docs (but would be happy if one just knows)
[09:10] <LocutusOfBorg> yofel, please merge/sync libqapt and baloo? I have not enough knowledge for doing it by myself sorry
[10:26] <pitti> Laney: the two UPSTREAM_PULL_REQUEST=4670 ones in http://autopkgtest.ubuntu.com/running#pkg-systemd-upstream seem to loop; are there any errors in the logs?
[10:27] <pitti> Laney: yesterday they still ran and failed; then https://launchpad.net/ubuntu/+source/ifupdown/0.8.16ubuntu1 landed, maybe that changed/broke something
[10:28] <Laney> hey pitti
[10:28] <Laney> let me see
[10:28] <Laney> all arches?
[10:29] <pitti> Laney: both i386 and amd64, yes
[10:29] <pitti> (I didn't trigger s390x, no point)
[10:32] <Laney> pitti: don't those upstream ones run on xenial?
[10:32] <Laney> why would an ifupdown in zesty break that?
[10:32] <pitti> Laney: I  manually triggered test runs on zesty, as this is useful for that PR
[10:32] <Laney> oh right
[10:32] <pitti> Laney: that uses the new unified cgroup hierarchy on kernels that support enough of it, which isn't the case yet on xenial
[10:32] <Laney> ok, let me look for that then
[10:33] <pitti> so xenial is for "this doesn't break stuff on older kernels and continues to use cgroupsv1", and zesty is "this doesn't break on unified hierarchy"
[10:33] <Laney> there's one running, /me tail -fs that
[10:33] <pitti> Laney: I have a feeling that it already has ran several times since yesterday evening; they usually take 1:30 hours or so
[10:34] <pitti> Laney: so I was wondering if there's any nova console log (or similar) in the journal already
[10:35] <Laney> I just see the testbed failure
[10:35] <Laney> ah wait, there's an aborted worker
[10:36] <Laney> Feb 21 08:03:28 juju-prod-ues-proposed-migration-machine-3 sh[5696]: Selecting previously unselected package libio-html-perl.
[10:36] <Laney> it just ends on a package installation
[10:37] <Laney> Feb 21 06:57:03 juju-prod-ues-proposed-migration-machine-3 sh[5839]: Selecting previously unselected package autoconf.
[10:38] <Laney> Feb 21 06:21:49 juju-prod-ues-proposed-migration-machine-3 sh[5669]: Get:71 http://ftpmaster.internal/ubuntu zesty/main i386 libip4tc-dev i386 1.6.0-3ubuntu2 [6,534 B]
[10:53] <Laney> hmm
[10:54] <Laney> pitti: is this helpful?
[10:54] <Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: [    2.128242] Unable to open file: /etc/ima/ima-policy (-2)[    2.129043] IMA: policy update failed
[10:54] <Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: [    2.129613] audit: type=1802 audit(1487638604.548:2): pid=1 uid=0 auid=4294967295 ses=4294967295 op="policy_update" cause="fa
[10:54] <Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: [    2.141903] ip_tables: (C) 2000-2006 Netfilter Core Team
[10:54] <Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: [    2.146335] systemd[1]: Failed to create symlink /sys/fs/cgroup/net_cls: Operation not permitted
[10:54] <Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: [    2.147550] systemd[1]: Freezing execution.
[10:54] <Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: ---------------------------------------------------
[10:54] <Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: <VirtSubproc>: failure: Timed out on waiting for ssh connection
[10:54] <Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: autopkgtest [01:01:42]: ERROR: testbed failure: unexpected eof from the testbed
[11:12] <xnox> pitti, we landed 4.10 kernel too
[11:13]  * ogra_ hopes 4.10 passes quickly ... always makes me think "oh the warty kernel"
[11:16] <pitti> Laney: sorry, long phone call
[11:17] <pitti> Laney: it looks related, yes; /sys/fs/cgroup/net_cls wouldn't exist any more with the unified hierarchy, just not sure why this would cut the ssh connectino
[11:20] <pitti> xnox: oh right, only 10 hours ago, that could be relevant
[11:22] <Laney> pitti: Someone posted "Freezing execution" on the PR too
[11:23] <Laney> seems that was with 4.9 though
[11:25] <pitti> Laney: any chance you could put the /tmp/autopkgtest.*/binaries/*.deb somewhere? I'd like to see if I can reproduce this locally with today's cloud image
[11:25] <pitti> worked fine yesterday still
[11:25] <pitti> Laney: I could also rebuild it myself, but the binaries should already be there in the running tests, so convenience..
[11:26] <Laney> one second
[11:27] <Laney> got to pull this string
[11:27] <pitti> Laney: ah bummer, current retry is still at package building stage
[11:28] <Laney> no I've got binaries
[11:28] <pitti> oh, cool
[11:28] <Laney> no version in the filename
[11:28] <Laney> is that normal?
[11:34] <Laney> pitti: http://people.canonical.com/~laney/weird-things/systemd.tar.xz
[11:34] <pitti> Laney: yes, that's normal
[11:36] <pitti> Laney: many thanks!
[11:36] <Laney> pitti: just got them out in time ;-)
[11:36] <Laney> (died now)
[11:36] <Laney> I'll filter these out now if you don't mind
[11:37] <pitti> Laney: yes, please
[11:38] <pitti> [    2.080076] systemd[1]: Failed to create symlink /sys/fs/cgroup/net_cls: Operation not permitted
[11:38] <pitti> gotcha
[11:38] <pitti> trivial to repro locally
[11:38] <Laney> it killed the VM too?
[11:39] <Laney> I should throttle debmirror somehow, kills SSH latency when it's running
[11:40] <pitti> Laney: yep, same "freezing execution", I followed up to the PR
[11:40] <pitti> Laney: so presumably it's a regression from the followup pushes yesterday  evening
[11:41] <pitti> unfortuantely ridiculously hard to detect by heuristics
[11:41] <pitti> unless we add "Freezing execution" to the list of strings it watches out for; we now have strings for kernel crashes, don't we ?
[11:42] <pitti> similar to f9b3ee01e9
[11:43] <Laney> pitti: could do, if that always indicates a failure
[11:43] <Laney> bit of whack a mole, but what can you do?
[11:55] <doko> apw, infinity: what's the estimate for linux 4.10 and glibc 2.25 in z? asking for the test rebuild
[11:58] <pitti> doko: linux 4.10 landed yesterday (there's some fixes in -proposed, but hopefully shouldn't affect the headers much?)
[11:59] <doko> ahh, I see
[12:37] <mdeslaur> @pilot in
[13:43] <Laney> pitti: https://paste.ubuntu.com/24040277/ ?
[13:47] <pitti> Laney: nice! thanks
[13:52] <Laney> pitti: ok, deployed, could you trigger the test again to test it please?
[13:52] <Laney> just pick one arch
[13:53] <pitti> Laney: triggered amd64
[13:53] <Laney> merci
[13:53] <pitti> Laney: merci à toi ! I'll trigger i386 after amd64 failed "properly"
[13:54] <pitti> (although, that doesn't really tell us anything, nevermind)
[13:54] <Laney> You'll get a nice 'x' on the PR :P
[13:54] <pitti> I already get that with one failure
[14:14] <Bluefoxicy> I wish apt and update-manager had an integrated system to pull all process ids, identify all loaded binaries, and list everything using a binary which has been replaced
[14:14] <Bluefoxicy> that way when you update e.g. openssl, you can list everything running that's still using the previous version, and restart services or browsers
[14:16] <Snow-Man> uh
[14:16] <Snow-Man> check_libs
[14:16] <Snow-Man> Does basically exactly that...
[14:16] <Bluefoxicy> oh cool
[14:16] <Snow-Man> I agree that it'd be nice if apt would tell you too.
[14:16] <Bluefoxicy> command not found
[14:17] <Snow-Man> nagios-plugins-contrib: /usr/lib/nagios/plugins/check_libs
[14:17] <Snow-Man> heh
[14:17] <Bluefoxicy> oh lol
[14:17] <Snow-Man> lsof works too tho
[14:17] <Snow-Man> and is what check_libs runs
[14:20] <Saviq> wgrant, hey, looks like builders got a kernel upgrade again? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2457/+build/12039740
[14:56] <ilmaisin> hi
[14:56] <ilmaisin> how do i report a disruptive user in launchpad?
[14:57] <ilmaisin> blacksheep001 keeps spamming some internet connection questions to cups bug reports
[14:57] <ilmaisin> won't believe when i ask him to stop
[15:05] <seb128> ilmaisin, you can try asking on #launchpad but I think the recommended way is to use https://answers.launchpad.net/launchpad/+addquestion
[15:05] <ilmaisin> seb128: thanks
[15:05] <seb128> ilmaisin, yw!
[16:02] <tinoco> cpaelzer: are u also taking care of qemu for trusty ?
[16:02] <tinoco> qemu/libvirt
[16:02] <cpaelzer> tinoco: as much as possible :-)
[16:02] <tinoco> cpaelzer: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1317491
[16:02] <tinoco> i'll probably block the "block-commit" feature in libvirt for Trusty
[16:02] <tinoco> (just for active block devices)
[16:02] <tinoco> its broken anyway
[16:03] <tinoco> cpaelzer: could u review it for me so I can prepare the SRU ?
[16:03] <cpaelzer> tinoco: yes, but not today
[16:03] <tinoco> cpaelzer: cool, i'll prepare the debdiffs and wait for you
[16:03] <cpaelzer> tinoco: drop me a mail and I'll look at it then
[16:03] <tinoco> cpaelzer: ill attach them to the case and email you
[16:03] <tinoco> cpaelzer: tks buddy
[16:25] <smoser> xnox, around ?
[16:25] <xnox> smoser, sure! what's up?
[16:25] <smoser> i saw you re-ran some tests or open-iscsi once
[16:25] <smoser> i filed https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1666573
[16:25] <smoser> with some diagnosis comparing the pass and fail, and wanted to know if anything jumped out as you asa the reason for the transient results.
[16:26]  * xnox learns a new word "posterity"
[16:26] <smoser> the top 4 runs at http://autopkgtest.ubuntu.com/packages/o/open-iscsi/zesty/amd64 show pass and fail of identical runs
[16:27] <xnox> smoser, what updates the /etc/fstab? is it done in the initramfs before systemd is started?
[16:27]  * nacc has noticed for a few packages in excuses that the oldest success has no logs -- is that something that can be avoided (i'm assuming maybe it got pushed off the bottom of the list, but still shows up on the web UI, e.g.: http://autopkgtest.ubuntu.com/packages/p/puppet/zesty/amd64)
[16:27] <smoser> overlayrooto before intiramfs
[16:27] <smoser> er...
[16:27] <smoser> in initramfs
[16:27] <smoser> by overlayroot
[16:27] <xnox> smoser, there is possibly a race between fstab-generator and /etc/fstab being updated; if the update is not done in the initramfs.
[16:27] <xnox> ah, good.
[16:29] <smoser> the attached .tar.xz has "short" logs (just the tgt-boot-test output)
[16:29] <smoser> and they actually compare side by side reasonably well with vimdiff
[16:30] <smoser> cpaelzer, ^ i think that could be part of your issue with open-iscsi tests
[16:30]  * cpaelzer reads backlog
[16:31] <zul> doko: ping can you review os-faults wen you get a chance its a new dependency for rally
[16:33] <doko> zul: yes, will do it tomorrow morning
[16:34] <zul> doko: thank you
[16:35] <mdeslaur> @pilot out
[16:47] <nacc> is there a convenient way for me to test the exact environment the autopkgtests run in? That is, http/https proxies and all. I think the puppet failure is due to https_proxy being set, but I'm not 100%
[16:56] <jgrimm> nacc, i'm interested in that too
[16:56] <nacc> jgrimm: will keep you posted
[16:57] <jgrimm> tx
[16:57] <nacc> Laney: --^ you may know
[16:57] <Laney> afraid not
[16:59] <nacc> Laney: np, thanks!
[16:59] <nacc> Laney: you've just educated me on several other autopkgtest nuances :)
[17:02] <nacc> jgrimm: ah, i think i see the puppet failure a bit clearer now (and why my initial 'fix' does workaround it, but is incorrect). I think the tests assume a host-naming pattern of 'puppet'.
[17:02] <nacc> jgrimm: so when it attemps to use https://puppet... it will alias to localhost when Debian tests
[17:05] <jgrimm> nacc, aha.  tho, i was more interested in the part of your question that asked how to create the exact autopkgtest environment. :)
[17:06] <nacc> jgrimm: understood, just fyi :)
[17:07] <nacc> stgraber: `lxc --sudo --name puppet-1487554013 adt-sid-amd64` -- would that set the container's 'hostname' to puppet-1487554013 ?
[17:10] <nacc> stgraber: ah nm, that's an autopkgtest-virt-lxc option
[17:12] <Laney> nacc: yes, it's passed to lxc-start --name
[17:13] <nacc> Laney: yep, i see that now, thanks!
[17:14] <Laney> nacc: One way to do your thing might be to make the lxc/d runner apply a profile, and construct one of those which blocks network access other than to a proxy
[17:14] <Laney> Assuming you can make such profiles (I don't actually know that)
[17:15] <nacc> Laney: yeah, that's a thought. I think a much simpler one (looking at the test case ruby now), would be to just have puppet use the actual hostname at run-time, rather than assuming it's 'puppet' (and accessible at that hostname). There's nothing in the tests that asserts that's true.
[17:19] <Laney> nacc: That helps for this one problem, but not in general :P
[17:19] <nacc> Laney: yeah :)
[17:19] <Laney> Well done potentially finding the issue though
[17:19] <Laney> you can invoke autopkgtests against a PPA FYI
[17:19] <nacc> Laney: only because in this case, I don't think the proxy is actually the problem
[17:19] <Laney> so no need to upload to the archive to verify your fix if it's environment dependent
[17:20] <nacc> Laney: ah that would be great -- documentation for it?
[17:20] <Laney> ...
[17:20] <Laney> I knew you'd ask that
[17:20] <nacc> heh
[17:20] <jgrimm> nacc, or bileto!
[17:20] <nacc> LP: #1550280 implies it's not present
[17:21] <nacc> jgrimm: good point
[17:21] <Laney> private no, but public ones sure
[17:21] <nacc> Laney: err, right!
[17:23] <Laney> meh, got to get this from the source
[17:25] <Laney> nacc: ok, I think it's &ppa=user/ppa (https://autopkgtest.ubuntu.com/request.cgi?release=zesty&arch=amd64&package=puppet&ppa=nacc/myppa)
[17:26] <Laney> if that works, would appreciate a sentence on https://wiki.ubuntu.com/ProposedMigration :-)
[17:26] <nacc> Laney: ack, will test that!
[17:41] <nacc> Laney: https://autopkgtest.ubuntu.com/request.cgi?release=zesty&arch=amd64&package=puppet&ppa=nacc/lp1570472&trigger=puppet/4.8.2-3ubuntu2~ppa1, FYI
[17:41] <nacc> Laney: will update the docs
[17:41] <Laney> nacc: it got published already?
[17:41] <nacc> Laney: my upload to my PPA did yeah
[17:41] <Laney> wowzers
[17:41] <Laney> things are fast these days
[17:41] <nacc> Laney: yeah, faster than I expected :)
[17:42] <Laney> next challenge is finding the results :P
[17:42] <nacc> :) was just going to ask
[17:42] <Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-nacc-lp1570472/?format=plain
[17:43] <nacc> hrm, I get Unauthorized
[17:43] <Laney> the container is made when the first result is uploaded
[17:45] <Laney> oops, and I've just clicked on a huge text file which has killed firefox for the next X months
[17:52] <nacc> Laney: so... once it's done, should i be able to access the above log?
[17:52] <Saviq> wgrant, hey, did you see my message before about arm64 builders crashing in QML again? (bug #1630906)
[17:53] <Laney> nacc: yup
[17:53] <Laney> well, it'll be an index, and then you construct the path from that
[17:53] <Laney> you can see that the UX here has had a lot of thought :/
[17:54] <Laney> to be fair it was mostly designed to be driven by machines
[17:54] <Laney> but I'm sure we could make it more user friendly somehow
[17:54] <nacc> Laney: totally understood
[17:57] <smoser> xnox, i did manage to catch a failure that i have emergency console access to if you were looking at bug 1666573 and needed anything
[17:59] <nacc> Laney: and i'll update the wiki to indicate you can see it running on the main autopkgtest page
[17:59] <xnox> smoser, a dump of journal would be nice
[18:00] <Laney> nacc: Aye - you can see the formula for getting the index from that URL I gave
[18:00] <xnox> if you can save / extract / copy if somwhere
[18:00] <Laney> autopkgtest-release-username-ppaname
[18:01] <Laney> in fact that's documented at https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Container_Names
[18:01] <Laney> but that tells you more than you need to know
[18:01]  * Laney imagines a CLI tool for all this
[18:03] <Laney> ok, those rocks aren't going to climb themselves
[18:03] <Laney> o/
[18:04] <nacc> Laney: thanks and enjoy!
[18:05] <nacc> jgrimm: in case you didn't see it: "Testing against a PPA" at https://wiki.ubuntu.com/ProposedMigration
[18:06] <jgrimm> nacc, tx
[18:58] <nacc> Laney: just fyi, my autopkgtest seems wedged
[18:58] <nacc> if anyone else has access: http://autopkgtest.ubuntu.com/running#pkg-puppet ran that aginst my PPA
[18:59] <nacc> it looks like it's done and passed, but i've not seen any log change in a while now
[18:59] <nacc> and I can't access the underlying logs until the jobs is done, afaict
[19:34] <nacc> Laney (and anyone else): nevermind, it worked, it was just taking a while to extract the logs, i think
[19:44] <robru> anybody around that can help with an autopkgtest issue? sqlparse update is held back because failing autopkgtest with python-django-debug-toolbar 1.5, the issue is fixed by 1.6, which is in -proposed, but it's invalidated by sqlparse, which is invalidated by the autopkgtest run from 1.5. Not sure how to kick that autopkgtest with 1.6 which should work (I
[19:44] <robru> checked the source and the traceback is resolved in 1.6)
[19:45] <nacc> robru: have you tried rerunning the test?
[19:45] <nacc> robru: i think it should use the new version if it's in z-p now
[19:46] <robru> nacc: yeah, gives very strange output where it claims to be installing 1.6 deb but traceback references 1.5 source tree (and same traceback<EMAIL_ADDRESS>[19:48] <nacc> robru: ah it's using the z-p to satisfy the debends, but the test it is running is from the 1.5 src
[19:48] <nacc> *depends
[19:48] <robru> nacc: any thoughts how to fix that?
[19:49] <nacc> robru: thinking -- there is a proposed flag we can pass to the test to use proposed for everything, but i'm not sure if that's what we need here or not
[19:49] <robru> nacc: I have no idea. I mean the log already shows it's installing the correct version of the deb, so I'm not sure where it's even getting the 1.5 source tree from
[19:50] <nacc> robru: because that's the version the test is running (earlier you can see it downloads the 1.5 src)
[19:50] <nacc> robru: the way it works is that only sqlparse will come from z-p by default
[19:50] <nacc> robru: for this specific run
[19:50] <nacc> --apt-pocket=proposed=src:sqlparse
[19:51] <robru> nacc: oh well, can you rerun with --all-proposed then? should fix it
[19:51] <nacc> robru: let me try it
[19:51] <robru> thanks
[19:51] <nacc> robru: trying amd64 first, let's see if it passes
[19:52] <robru> nacc: I just double checked, v 1.6 absolutely fixes this traceback, no doubt.
[19:52] <robru> maybe some other problem will arise, not sure, but this specific traceback is for sure fixed by 1.6 ;-)
[19:52] <nacc> robru: ack
[19:57] <pitti> Laney: nice, that worked! proper failure with useful log now; thanks!
[20:02] <robru> nacc_: oooh I see the pass, thanks!
[20:03] <robru> nacc_: try the other arches please ;-)
[20:06] <jbicha> barry: hi, systemd-resolved hasn't been working smoothly here, bug 1666021
[20:07] <nacc> robru: ok, looks like it passed on amd64, will trigger the others
[20:07] <nacc> robru: will take excuses a bit to see the passes, ithink
[20:16] <barry> jbicha: interesting.  i haven't seen this, but then i don't suspend
[20:17] <jbicha> well the initial report wasn't about suspend, it was about first boot
[20:18] <jbicha> maybe there's multiple issues combined into one report but I didn't know where to split it
[20:20] <barry> jbicha: i have seen problems with resolving names right after first boot, but that predates the recent n-m or systemd uploads.  e.g. after first login, i have chromium set up as a start-up app, but after first login post-reboot, most of the tabs cannot load.  reloading always fixes it, so there is definitely something going on around boot
[20:24] <jbicha> ok, but with the symptoms I experienced and the workaround (just restart resolved), it's very convenient to blame resolved now
[20:29] <zul> doko: networking-bagpipe and networking-bgpvpn as well please
[20:30] <nacc> robru: yeah, amd64 just ticked over, at least, looks like it's passing elsewhere too
[20:31] <robru> nacc: thanks!
[21:01] <nacc> robru: and sqlparse is now a valid candidate
[21:01] <robru> nacc: yay, thanks!
[21:01] <nacc> robru: np!
[21:18] <scootergrisen> Can anyone help me get danish translation into the Ubuntu ISO live?
[21:18] <scootergrisen> So when i select danish language during boot its translated to danish without having to install danish language.
[21:25] <robru> nacc: http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#libseccomp all these regressions appear to me to be transient network issues, can you retry them?
[21:49] <nacc> robru: looking
[21:50] <nacc> robru: done
[21:50] <robru> nacc: thanks!
[22:38] <wgrant> Saviq: Not at 4am. Fixing.
[22:41] <Saviq> wgrant, duh, was sure you're closer than that on the timezone front... thanks :)
[23:11] <nacc> jgrimm: ping
[23:11] <jgrimm> nacc, pong
[23:12] <nacc> jgrimm: I *think* your openvpn upload may have inadvertently broken the Canonical VPN cxn with NM on upgrades :) related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848062 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848062
[23:12] <nacc> specifically, i get "Options error: Unrecognized option or missing or extra parameter(s) in [CMD-LINE]:1: tls-remote (2.4.0)"
[23:14] <sarnold> nacc: from #distro "You have to change VPN -> Advanced -> TLS Authentication -> "Server certificate check" to "Verify name exactly" and remove the /CN: or whatever it is"
[23:14] <jgrimm> nacc, fun times!
[23:14] <nacc> sarnold: yeah, we should put that somewhere, though -- release notes, or in a NEWS file?
[23:15] <jgrimm> yeah, release notes at very minimum
[23:16] <nacc> sarnold: but thank you for the pointer!
[23:18] <nacc> sarnold: as to the remove the '/CN: ...' it doesn't let that be empty (understandably, i think) -- so does that mean remove the value for /CN?
[23:19] <nacc> sarnold: nm, i undestand now
[23:19] <sarnold> nacc: I assumed it meant the non-data annotations..
[23:19] <nacc> jgrimm: so in that particular case, elide the '/CN:' string specifically
[23:19] <jgrimm> nacc, correct
[23:19] <nacc> jgrimm: will you follow up on that with the release notes? i have a feeling it will bite people
[23:20] <jgrimm> nacc, yeah i'll go add a blurb now
[23:21] <nacc> jgrimm: thanks
[23:48] <Laney> nacc: FYI you can add extra triggers instead of all-proposed
[23:49] <Laney> when retrying tests
[23:51] <Laney> they translate into src:proposed things basically


[07:37] <qwluhbear> Hi, anyone around to troubleshoot a password bootstrapping issue with VMWare?
[12:21] <doda> hi folks
[12:22] <doda> it seems like cloud-init deletes the ssh server keys of an instance, but if it can't find a metadata service or config drive it doesn't generate them
[23:37] <jgrimm> smoser, around?


[14:14] <ernstp> seems like something hangs when gdm starts to draw with latest xorg-edgers ppa on Lucid
[14:14] <ernstp> no error messages anywhere though
[17:48] <Kangarooo> hello Sarvatt . what ackage i need to report for this problem: changing resolution to lower/or 1024x786 makes tty no opening. with higher it opens. the higher the better resolution for tty.
[19:14] <Kangarooo> Sarvatt: u alive? :)
[19:56] <Kangarooo> Sarvatt: for the same bug ive mentioned here just now i want to know to waht package i need to report about if i have nvidia? xserver-xorg-video-nv or xserver-xorg-driver-nv
[19:57] <jcristau> neither
[19:57] <bjsnider> Kangarooo, go to the nvforums and report the bug to nvidia
[20:22] <Kangarooo> bjsnider: problem is for linux. when i set resolution in xorg to be larger then 1024x768 then TTY can be opened. the larger Xorg resolution the larger TTY. if smaller in Xorg then 1024 then tty cant be opened.
[20:23] <Kangarooo> i think TTY still opens but somehow that tty shows too small resolution that comp/monitor can show..
[20:23] <Kangarooo> *cant show..
[20:23] <bjsnider> so everybody on all platforms are also having that problem? otherwise it's an nvidia issue
[20:26] <Kangarooo> bjsnider: no only in linux. couse problem is for TTY(1-6) to show. and other os dont have TTY. so i thought problem maybe is for xorg or tty but in #ubuntu-bugs i was told to try also if its not kernel problem i tryd nomodeset and that didnt change anything for this problem.


[00:44] <wolfy1339> how do i create a local branch to later upload it to launchpad?
[00:46] <benonsoftware> wolfy1339: 'bzr init' will create a local branch.
[00:46] <wolfy1339> ok
[00:49] <wolfy1339> i get this error:  [Errno 38] Function not implemented: '/media/wolfy1339/SDXC/Programming/<projectname>/.bzr'
[00:53] <wgrant> wolfy1339: What's the traceback?
[00:53] <wgrant> Also, given the path I'm assuming that's on some weird filesystem like exFAT.
[00:54] <wolfy1339> traceback: http://pastebin.com/U9Syczxk
[00:54] <wolfy1339> and yes it's exfat
[00:55] <wgrant> I don't know how good the exFAT FUSE driver is nowadays...
[01:00] <wgrant> The driver doesn't implement chmod
[01:01] <wgrant> Other filesystems that don't support UNIX file modes usually EPERM, EACCES, or just do nothing
[01:01] <wgrant> bzr handles those cases, but it doesn't expect an ENOSYS.
[01:01] <wgrant> You can probably hack around it by adding ENOSYS to the list with EPERM and EACCESS in bzrlib/osutils.py's chmod_if_possible function
[01:08] <wgrant> wolfy1339: https://groups.google.com/forum/#!topic/exfat/vqPCwJnA_Fo suggests that the next release of exfat-fuse fixes this.
[01:14] <ekristen> why can’t I copy packages from here into a PPA? https://launchpad.net/ubuntu/+source/volatility/2.3.1-1
[01:22] <wgrant> ekristen: You can use the copy-package tool from lp:ubuntu-archive-tools to do that.
[01:22] <wgrant> But there's no web UI for it.
[01:23] <ekristen> wgrant: I’m ok with that
[01:23] <ekristen> any docs you can point me to?
[01:24] <wgrant> The --help is quite usable.
[01:24] <ekristen> trying to find and install it
[01:25] <wgrant> But something like 'copy-package -s trusty --to-ppa=wgrant --to-ppa-name=experimental -b --to-suite=saucy volatility'
[01:25] <ekristen> wgrant: I’ll definitely use the help as soon as I can figure out how to install the tool
[01:26] <wgrant> ekristen: I just have a checkout of lp:ubuntu-archive-tools and symlink relevant bits into ~/bin
[01:26] <ekristen> ah
[03:36] <olly> hi, i have a question about translation imports in launchpad
[03:37] <olly> the pot files gets imported automatically, but all the po files end up in the queue in "Needs Review" state - is that expected?
[03:37] <olly> there's only one possible template in the dropdown, so it seems it should be able to see where to import them to without having to be told
[03:38] <olly> I mean "pot file" (there's just one template)
[03:38] <olly> this is for "survex" BTW
[12:48] <Delfino1983> hello can you delete my key gpg my personal accoun
[12:50] <tsimpson> Delfino1983: you can deactivate it from https://launchpad.net/~/+editpgpkeys
[12:50] <Delfino1983> tsimpson ok thanks
[12:56] <Delfino1983> delete keys gpg!?
[12:57] <tsimpson> if you want them really deleted from launchpad, you're probably going to have to ask in https://answers.launchpad.net/launchpad
[13:44] <wgrant> Delfino1983: Why do you want to delete them?
[13:46] <Delfino1983> change S.O.Linux
[13:46] <wgrant> I don't quite understand what you mean.
[13:50] <Delfino1983> because I do not want more work cn ubuntu
[13:50] <wgrant> You can remove your Launchpad account at the bottom of https://launchpad.net/~/+edit.
[22:16] <pohutukawa> wgrant: thumper just told me to ping you on a package build problem on launchpad
[23:12] <wgrant> pohutukawa: Hi
[23:13] <pohutukawa> wgrant: Hi
[23:13] <pohutukawa> thumper has told me that you might be able to help
[23:14] <pohutukawa> a package build on launchpad fails
[23:14] <pohutukawa> https://launchpadlibrarian.net/162667429/buildlog_ubuntu-trusty-amd64.libsodium_0.4.5-0~trusty4_FAILEDTOBUILD.txt.gz
[23:14] <pohutukawa> somehow it seems like the pkg-config files do not get installed
[23:15] <pohutukawa> is that something where you could potentially help in finding out how to fix it?
[23:15] <pohutukawa> it builds fine on local machine
[23:15] <wgrant> pohutukawa: How were you building it locally?
[23:16] <pohutukawa> wait a sec ...
[23:17] <pohutukawa> wgrant: sudo dpkg-buildpackage -rfakeroot -b
[23:17] <pohutukawa> after apt-get source
[23:17] <wgrant> pohutukawa: Try with -B instead of -b
[23:17] <wgrant> -b builds both the architecture-dependent and architecture-independent binaries
[23:17] <wgrant> But Launchpad builds on multiple architectures, so it only builds the architecture-indepdendent binaries on one: i386.
[23:17] <wgrant> So the amd64 builds run with -B, not -b.
[23:18] <pohutukawa> let me try locally
[23:21] <pohutukawa> wgrant: well, it did build again fine on my own machine with -B
[23:21] <pohutukawa> the problem is that it won't run through on launchpad
[23:21] <pohutukawa> so there seems to be something different
[23:22] <wgrant> pohutukawa: Are you building in a clean chroot?
[23:22] <wgrant> Using pbuilder or sbuild
[23:22] <pohutukawa> no, just on the vanilla machine
[23:22] <wgrant> You're probably missing some build dependencies.
[23:22] <wgrant> Try using pbuilder or sbuild to get a clean environment.
[23:22] <wgrant> "checking for pkg-config... no"
[23:22] <pohutukawa> It's just that the package in the PPA didn't get built, and I've provided a patch that I thought should fix it
[23:22] <pohutukawa> but the maintainer can't get it to build himself
[23:23] <wgrant> pkg-config isn't being installed, because you're not Build-Depending on it.
[23:24] <pohutukawa> so do you reckon it could be "easily" fixed when just adding "pkg-config" to the dependencies of the package?
[23:24] <wgrant> Probably if you add it to the Build-Depends field, yeah
[23:24] <wgrant> But you should be test building locally
[23:24] <wgrant> In a clean environment.
[23:27] <pohutukawa> wgrant: thanks for the input
[23:27] <pohutukawa> I'll radio it on to the maintainer
[23:28] <pohutukawa> so I guess if it's in the Build-Depends field, then the launchpad builder will provide for it ...
[23:31] <wgrant> pohutukawa: The Build-Depends field tells the build infrastructure what to install before building the package.
[23:32] <pohutukawa> that's what I thought. thanks for confirming.


[03:46] <lamont> lets say I have juju 1.24.7-0ubuntu1~14.04.1, and I want to juju deploy local:xenial/foo... is there some obvious reason that the service winds up in this state:
[03:46] <lamont>     service-status:
[03:46] <lamont>       current: unknown
[03:46] <lamont>       message: Waiting for agent initialization to finish
[03:46] <lamont>       since: 19 Nov 2015 03:45:05Z
[03:46] <mgz> lamont: what status is the machine in?
[03:47] <lamont> nova?  doesn't exist at all
[03:47] <lamont> interestingly, local:wily/foo gets me machine-2
[03:47] <mgz> weeelll... that would be why the agent isn;t up
[03:47] <lamont>     service-status:
[03:47] <lamont>       current: maintenance
[03:47] <lamont>       message: installing charm software
[03:47] <lamont>       since: 19 Nov 2015 03:47:45Z
[03:48] <lamont> that's with local:wily/foo
[03:49] <lamont> mgz: is there some easy way to cause juju to spill what command it's using for "nova boot"?
[03:49] <mgz> lxc-ls --fancy gives you a view under the hood, as does $JUJU_HOME/$ENV/*
[03:50] <mgz> er, meph
[03:50] <lamont> no lxcs involved... this is openstack
[03:50] <mgz> I was imagining containers where none exist
[03:50] <lamont> can I have multiple series (trusty,wily,xenial) in one juju environment?
[03:50] <mgz> for the true story, you need the nova logs
[03:51] <lamont> as in nova host api logs on the api host?
[03:51] <mgz> but machine-0.log will tell you what the provisioner tried to do
[03:51] <lamont> ah!
[03:51] <mgz> it may be something as simple as nova not having a xenial image
[03:52] <lamont> nova image-list| grep xenial
[03:52] <lamont> | 00e59d4a-b4a5-4b27-8cf9-3fe2bcd0fb79 | ubuntu-xenial-daily-amd64-server-20151105-disk1.img  | ACTIVE |        |
[03:52] <lamont> ^^ that's why I thought I could do this
[03:53] <mgz> okay, but how does juju know about that image?
[03:53] <lamont> 2015-11-19 03:45:07 ERROR juju.provisioner provisioner_task.go:630 cannot find tools for machine "1": no matching tools available
[03:53] <mgz> did you also update local simplestreams
[03:53] <lamont> bingo!
[03:53] <lamont> apparently not
[03:53] <mgz> ...and also it couldn't find xenial tools
[03:53]  * lamont goes to poke his admins
[03:55] <mgz> okay, we haven't published xenial tools yet, because there are no xenial cloud-images yet, and our build chain expects that
[03:55] <lamont> oh!
[03:55] <lamont> well then
[03:55] <mgz> in practice, the tools would be identical to wily's
[03:55] <lamont> mgz: any eta?  (meanwhile, I'll do the wily + upgrade-in-place-while-crying
[03:56] <lamont> guessing step 1 is poke the cloud-images people?
[03:57] <mgz> yeah, they're trying to change the method they're making images, which is the hang up
[03:59] <lamont> ack
[07:57] <jamespage> adam_g, hey - you should hook up with gnuoy, coreycb and thedac as they are about to write three new openstack charms - all based on the new reactive framework which is our standard now
[10:36] <ionutbalutoiu> hi, jamespage. Update MP with the unit tests as you advised. Can you take a look whenever you can ? (https://code.launchpad.net/~ionutbalutoiu/charms/trusty/neutron-gateway/next/+merge/276833)
[10:37] <jamespage> ionutbalutoiu, on my list for today
[10:40] <ionutbalutoiu> jamespage, just as a note, amulet tests didn't run yet for this update (only lint_test and unit_test), but it's been two days. I think we have to wait for this as well. Just wanted to give you a ping. Is it common such a delay for amulet tests ?
[10:41] <jamespage> ionutbalutoiu, long queue in the lab right now as we keep enabling new tests for each charm
[10:41] <jamespage> its possible something is blocked up - I'll check
[10:41] <jamespage> ionutbalutoiu, if not I'll run them myself...
[10:41] <ionutbalutoiu> good, thank-you.
[10:42] <jamespage> ionutbalutoiu, tbh I'd be happy to land without those reporting in as they passed before, and you've made 0 code change that would impact that since then
[10:42] <jamespage> but lets see
[10:45] <lazypower> o/ mornin jamespage
[11:22] <jamespage> hey lazypower
[11:23] <lazypower> jamespage did you see the somewhat silent post yesterday about charming w/ layers interview feat. Adam Stokes?
[11:24] <jamespage> lazypower, I did - started to watch but then got children
[11:24] <jamespage> so had to stop
[11:24] <jamespage> will resume later today
[11:24] <lazypower> :D just wanted ot make sure it crossed your radar as i know your team is about to go head first in reactive/layer territory
[11:25] <lazypower> to anyone lurking that didn't catch the update - https://www.youtube.com/watch?v=lowRfWcxky0
[11:28] <jamespage> gnuoy, coreycb, thedac, ddellav, rockstar, beisner ^^
[11:29] <gnuoy> ta
[14:26] <tvansteenburgh> anyone know how to get the ID of the currently executing juju action from inside the action itself?
[14:27] <tvansteenburgh> i've seen other code using JUJU_ACTION_ID, but it's not set, and I don't see any mention of that env var in the docs
[14:43] <tvansteenburgh> ah, it's JUJU_ACTION_UUID
[15:06] <stub> Register the decorated function to run when not all desired_states are active.
[15:06] <stub> Which does not mean when all desired_states are not active.
[15:08] <stub> tvansteenburgh: I look in charmhelpers.core.hookenv() for those :)
[15:10] <stub> So we get an AND operation with @when and an OR with @when_not. But I think I might stick with a single state per decorator for now until I get the hang of this ;)
[17:58] <jcastro> rick_h_: we're 7 subscriptions short of the 100 we need to get the custom URL for the youtube channel, can you ask for one more push across the board?
[17:59] <rick_h_> jcastro: sure thing
[18:03] <rick_h_> jcastro: sent, included cloud@ as well this time so hopefully moves fast for you.
[18:04] <jcastro> <3
[18:06] <rick_h_> jcastro: <3 jane's reply
[18:28] <rick_h_> jcastro: and done! woot
[18:58] <natefinch> rick_h_: sort of sad that a 600 person company has trouble getting 100 subscriptions to their own youtube channel ;)
[19:02] <rick_h_> natefinch: naw, it got through pretty well. Folks just need reminders :)
[19:26] <adam_g> gnuoy, coreycb thedac  are there any examples out there of openstack charms using the reactive framework?
[19:27] <gnuoy> adam_g, there is one I think
[19:27]  * gnuoy is looking for the link
[19:28] <gnuoy> adam_g, https://code.launchpad.net/~openstack-charmers/charms/trusty/openvswitch-odl/next
[19:28] <adam_g> gnuoy, thanks.
[19:28] <gnuoy> adam_g, the directory layout is a little outdated though
[19:28] <gnuoy> reactive should be a top level dir I think
[19:31] <adam_g> also--i seem to remember at least one place in the openstack charms where a charm would go and create neutron networks and subnets in neutron using neutronclient as part of a hook. does that still exist?
[19:31] <adam_g> i need to do something similar but can't remember where that was done
[19:32] <gnuoy> adam_g, are you thinking of http://bazaar.launchpad.net/~ost-maintainers/openstack-charm-testing/trunk/view/head:/bin/quantum-ext-net
[19:32] <gnuoy> adam_g, oh, as aprt of a hook
[19:32] <adam_g> gnuoy, oh ya, that was it
[19:33] <gnuoy> adam_g, also http://bazaar.launchpad.net/~ost-maintainers/openstack-charm-testing/trunk/view/head:/bin/quantum-tenant-net
[19:33] <adam_g> gnuoy, okay, so those dont actuallyg et called as part of a hook
[19:33] <gnuoy> adam_g, nope, I can't think of a hook that does that
[19:34] <adam_g> as part of my services deployment, i need to go and create a network in neutron on behalf of the service tenant
[19:34] <coreycb> adam_g, btw we're in the midst of creating a base openstack layer and inteface layers for rmq, mysql, keystone, etc
[19:35] <adam_g> coreycb, cool. im kinda operating on a tight schedule so im not sure ill be able to adapt that just yet. :\ unless all that stuff is about done and ready to use now.
[19:35] <gnuoy> adam_g, that's going to be a pain I would think
[19:35] <gnuoy> I mean creating the network
[19:35] <adam_g> gnuoy, yeah, i was trying to find a good way to make that fit yesterday
[19:36] <adam_g> gnuoy, best i could come with is have neutron-api expose a setting in its relatoin that lets other services know that neutron at least has: keystone, db, rabbit relations
[19:36] <adam_g> then have the other end do what it needs once thats true
[19:37] <gnuoy> adam_g, fwiw we already have a concept of the charm being ready (all mandatory relations and config satisfied)
[19:37] <gnuoy> it;s spat out in the workload status
[19:38] <adam_g> gnuoy, right but isnt that just user facing? i cant block relatin A's hooks on the status of B+C+D ?
[19:38] <bdx_> charmers, core, dev: Hey whats up everyone? I am finally getting my feet wet and jumping into charming with reactive.... I'm trying to react to the changing of specific configs on config-changed hook, is there a best practice for checking for config change for specific configs? heres what I'm working with...https://github.com/jamesbeedy/puppet-agent/blob/master/reactive/puppet_agent.py
[19:39] <gnuoy> adam_g, yes, you're right. I just meant the charm already has a concept of what it needs to be ready
[19:39] <adam_g> gnuoy, yeah, AIUI that unfortunately doesnt help here
[19:40] <adam_g> i think all i need from neutron-api is a flag i can pass to other services that says 'the api is functional and you can create things'
[19:40] <adam_g> should be fine if that were  happen before the rest of neutron is wired (neutron-gateway and cooresponding compute agents)
[19:43] <gnuoy> adam_g, yep, it seems reasonable. I'd like to see what jamespage thinks too as he was pondering a similiar issue recently
[19:43] <adam_g> cool
[19:44] <adam_g> i might get something functional later this afternoon and push it somewhere
[19:56] <tvansteenburgh> bdx_: you can do `if config.changed(key)`
[19:57] <bdx_> tvansteenburgh: ha...I knew it was something simple....thanks!
[20:52] <bdx_> 2-vcpu_4-gb-ram_20-gb-hd


[11:44] <ogra> popey, http://people.canonical.com/~ogra/snappy/wmx.png ... using http://people.canonical.com/~ogra/snappy/wmx_8_amd64.snap (needs --devmode and the stable mir-kiosk ... and snap connect wmx:wayland-socket-dir mir-kiosk:wayland-socket-dir as well as snap connect wmx:x11-plug wmx:x11)
[11:44] <ogra> in case you are interested ;) ... thanks to devmode you can actually use snap run
[11:47] <ogra> (inside the xterm that is)
[12:02] <popey> Oh nice!
[23:05] <CustosLimen> hi
[23:05] <CustosLimen> spotify snap stopped working on fedora


[04:09] -ubottu:#ubuntu-news- ::planet:: Podcast Ubuntu Portugal: E275 Vende-Se NFT, Como Novo @ https://podcastubuntuportugal.org/e275/
[04:09] -ubottu:#ubuntu-news- ::planet:: Ubuntu Blog: Fast and reliable telco edge clouds with Intel FlexRAN and Real-time Ubuntu for 5G URLLC scenarios @ https://ubuntu.com//blog/intel-flexran-and-real-time-ubuntu-for-5g-urllc
[04:09] -ubottu:#ubuntu-news- ::planet:: Ubuntu Blog: MOTL: Minis Forum N33 NUC @ https://ubuntu.com//blog/motl-minis-forum-n33-nuc
[04:09] -ubottu:#ubuntu-news- ::planet:: Aaron Rainbolt: Making hyper-minimal Ubuntu virtual machines with debootstrap @ https://arraybolt3.substack.com/p/making-hyper-minimal-ubuntu-virtual
[08:26] -ubottu:#ubuntu-news- ::security:: Episode 214 @ https://ubuntusecuritypodcast.org/episode-214/
[11:06] -ubottu:#ubuntu-news- ::ubuntuonair:: Material Shell - An intuitive workflow that synergizes with your natural sense of direction @ https://www.youtube.com/watch?v=3OELEhRd4Wg
[11:06] -ubottu:#ubuntu-news- ::ubuntuonair:: Linux Gaming beyond Steam: Building native support for GOG, Epic, and more @ https://www.youtube.com/watch?v=QrLhqIASRbE
[11:06] -ubottu:#ubuntu-news- ::ubuntuonair:: How do Rust applications get into Debian ? @ https://www.youtube.com/watch?v=cbqOcnMasPs
[16:08] -ubottu:#ubuntu-news- ::omg!ubuntu:: Switch Workspaces in Ubuntu 22.04 Using Buttons with This Extension @ https://www.omgubuntu.co.uk/2023/12/workspace-switch-buttons-gnome-extension
[16:38] -ubottu:#ubuntu-news- ::omg!ubuntu:: Varia is a Brand New Download Manager for Linux @ https://www.omgubuntu.co.uk/2023/11/varia-new-download-manager-for-linux


[23:40] <Do``> crdlb: renamed autostart, exited the terminal, now logging in again and starting with that dbus-launch thingie
[23:40] <rconan> I thought there were other version for older cards in repo?
[23:40] <dan457> Bug with multiple monitors, but there is a workaround.
[23:40] <billybigrigger> ok, i see that the module forcedeth is shoing in lsmod, and my ethernet controller is listed in lspci, i just cant seem to get my wired ethernet working, someone want to lend a hand?
[23:40] <thewrath> acicula: yes sir
[23:40] <acicula> thewrath: ur using 4500 gma, same as me
[23:40] <rconan> dan457: I did still get that occasionally with repeat off
[23:40] <thewrath> acicula: is that a statement or question
[23:40] <rconan> dan457: while holding alt-NUM
[23:40] <dan457> rconan, I never get that now.
[23:41] <acicula> thewrath: statement, anyway, support for it is still crappy afaik
[23:41] <thewrath> so no compiz
[23:41] <thewrath> ?
[23:41] <dan457> rconan,  i'm going to try again next time they update X
[23:41]  * rconan hopes it's fixed soon
[23:41] <acicula> thewrath: there's a huge thread about the gpu on the ubuntuforums, have a look there
[23:41] <rconan> no key repeat is annoying
[23:41] <Do``> crdlb: now i saw a bit more stuff in the terminal, evolution alarms, tracker daemon messages, a tracker-extract crash, but still no gnome-panel
[23:41] <thewrath> please spell things out acicula i am still getting back into linux
[23:42] <thewrath> especiallyw ith jaunty
[23:42] <thewrath> GPU?
[23:42] <acicula> thewrath: from what i gathered the gpu does have better support, but during beta actual functioning of it is hit or miss
[23:42] <acicula> gpu is graphics card
[23:42] <thewrath> oh ok
[23:42] <thewrath> where on ubuntu forums is htis
[23:42] <acicula> somewhere in hardware/laptops probably search on gma 4500
[23:42] <thewrath> how did u know i was running 4500
[23:42] <crdlb> Do``: try running 'dbus-launch gnome-session &' instead, then you can try gnome-panel &
[23:44] <acicula> thewrath: magic 8 ball
[23:44] <thewrath> ha ha
[23:44] <rconan> thewrath: you can tell from lspci output
[23:44] <Ienorand> what is the package for the volume control app called?
[23:44] <acicula> ^^
[23:44] <thewrath> i am in there right now
[23:44] <acicula> what he said
[23:44] <thewrath> and i dont see anything that says 4500
[23:45] <Do``> crdlb: gnome-panel & says warning **: cannot register the panel shell: canno connect to the session bus
[23:45] <acicula> it's the express 4 series
[23:45] <thewrath> ok
[23:45]  * rconan is going to bed since he is not actually waiting for the beta...
[23:45] <crdlb> Do``: hmm, I was afraid of that; it just doesn't want to start outside of a proper session
[23:46] <crdlb> Do``: so try the real gnome session again
[23:46] <cwillu> "Your system could be in an unusable state" yay! \o/ :)
[23:47] <Do``> crdlb: same thing happened as with the failsafe terminal. stops after loading the wallpaper
[23:47] <crdlb> Do``: if that fails again, then rename ~/.gnome2/
[23:47] <thewrath> acicula: what do you think about this: http://ohioloco.ubuntuforums.org/showthread.php?p=6450032
[23:47] <Do``> and i renamed .gnome2 already :/
[23:47] <HolyScottie> the beta page is up
[23:47] <HolyScottie> can I post that link?
[23:47] <thewrath> HolyScottie: link us please
[23:47] <HolyScottie> http://cdimage.ubuntu.com/kubuntu/releases/9.04/beta/
[23:47]  * bruce89 yawns
[23:48]  * rconan points out that this still isn't final... there is a mailing list announcement :p
[23:48] <bruce89> nor does it really mean anything
[23:48] <HolyScottie> which they will make before or after all the servers are uploaded?
[23:48] <acicula> thewrath: i know better then to waste my time tinkering with graphics drivers. plus the 4500 3d performance is pityfull, if and when it works properly i shall bask in the awesomeness glow that is compiz, untill then it's really not worth the effort.
[23:48] <rconan> HolyScottie: after
[23:48] <thewrath> ok
[23:48] <rconan> but until then there can still be changes
[23:48] <thewrath> where is the beta page for ubuntu
[23:48] <thewrath> that was for kubuntu
[23:48] <acicula> thewrath: unless they actually implement HW decoding support, which is actually usefull
[23:48] <rconan> I fell into this trap last release
[23:49] <thewrath> acicula: all right. thank you sir for your help
[23:49] <HolyScottie> thanks for asking
[23:49] <HolyScottie> http://cdimage.ubuntu.com/releases/9.04/beta/
[23:49] <rconan> downloaded all 6 cd images then discovered 4 had changed or something
[23:49] <crdlb> Do``: ergh, have you tried creating a new user?
[23:49] <thewrath> its not up  yet
[23:49] <Do``> crdlb: no, actually i dont know how to do that without gnome :D
[23:50] <HolyScottie> ubunuted is being ULed right now
[23:50] <thewrath> ULed?
[23:50] <acicula> uploaded
[23:50] <bruce89> Do``: adduser
[23:50] <rconan> HolyScottie: you clearly have too much spare time :p
[23:50] <crdlb> Do``: sudo adduser <username>
[23:51] <HolyScottie> so I shouldnt say i've been looking since midnight last night.
[23:51] <thewrath> lol
[23:51] <thewrath> HolyScottie: how do you know its being uploaded?
[23:51] <HolyScottie> cause everytime I refresh they is something new added?
[23:51]  * bruce89 remembers all the excitement about Hardy's release
[23:51] <bruce89> people thought it was to be released at 00:00 exactly
[23:52] <bruce89> since the calendar on the fridge said so
[23:52] <rconan> I got excited about hardy
[23:52] <bsnider> Do``, you can create a new account from kde
[23:52] <rconan> I was expecting an awesome release
[23:52] <rconan> and was dissapointed
[23:53]  * bruce89 is not surprised
[23:53] <rconan> still... it gets better every time I think
[23:53] <Do``> bsnider: ye :)
[23:53] <rconan> time for bedcvertainly
[23:53] <rconan> 'night
[23:53] <bruce89> apart from Jaunty's notification system of course
[23:53] <Do``> crdlb: new account loaded gnome desktop.. :D
[23:54] <bsnider> i wouldn't have bet on that one
[23:54] <o0Chris0o> uncustomizable notifcation system
[23:54] <bsnider> you already blew away everything gnome really cares about
[23:54] <Do``> :D
[23:54] <rconan> HolyScottie: and just to really excite you: http://cdimage.ubuntu.com/releases/9.04/beta/
[23:54] <qixcom> amd64 of the beta is up now but not x86
[23:54] <bruce89> bsnider: GNOME?
[23:54] <Do``> crdlb:  now it's a matter of finding which of my settings is the problem
[23:55] <billybigrigger> the beta pages are there, no images though
[23:55] <thewrath> how do i bcakup my private keys and move themt o another machine?
[23:55] <bsnider> bruce89, huh?
[23:55] <thewrath> just wondering scine i am in jaunty atnm
[23:55] <bruce89> bsnider: this new notification system is not GNOME's fault
[23:55] <HolyScottie> so if I DL now before the rush, I can compare the hash file later to make sure I have the final?
[23:56] <bsnider> bruce89, i wasn't involved in your conversation. i was talking about something else
[23:56] <bruce89> HolyScottie: have you got Jaunty already?
[23:56] <billybigrigger> HolyScottie, if you were to download the alpha 6 image, and upgrade via apt, you will have the same version as the beta cd
[23:56] <qixcom> billybigrigger - the amd64bit images are there
[23:56] <bruce89> bsnider: oops, sirry
[23:56] <HolyScottie> will the apt-get updates be out today also?
[23:57] <Ienorand> Has brasero been removed now all of a sudden?
[23:57] <acicula> HolyScottie: they have been out for ever
[23:57] <HolyScottie> but I am in a different distro right now, so I want the iso to do a clean install
[23:57] <billybigrigger> qixcom, haha they weren't 1 min ago for me :P downloading now
[23:57] <bruce89> Ienorand: shouldn't have been
[23:57] <qixcom> looks like the x86 is up now too
[23:57]  * bruce89 still has the Intrepid beta CD, no need for me to download CDs any more
[23:57] <thewrath> ITS UP!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[23:57] <qixcom> downloading as we speak
[23:58] <thewrath> sorry for caps
[23:58] <bruce89> !caps
[23:58] <Ienorand> bruce89: Dunno but looks like the nautilus CD/DVD creator got installed and brasero removed in some update, presumably recent...
[23:58] <thewrath> oh only live cds
[23:58] <thewrath> right now
[23:58] <thewrath> i dont want a live cd i want the real thing
[23:58] <bruce89> Ienorand: well, that's not supposed to happen
[23:58] <thewrath> qixcom: u download hte live cd
[23:58] <Cycom> it's partially up.
[23:58] <HolyScottie> um, is there a cd release of ubuntu 9.04 or is it dvd only?
[23:59] <acicula> thewrath: livecd is the real deal.
[23:59] <thewrath> so i can isntall from taht
[23:59] <qixcom> downloading live dvd
[23:59] <acicula> thewrath: samething
[23:59] <thewrath> how would i upgrade then from the alpha to the beta
[23:59] <acicula> apt-get update && apt-get upgrade


[07:16] <didrocks> infinity: hey! I'm just starting to look at the upstart/upstart-bin/upstart-sysv separation. There is something I want to discuss with pitti before we go on on that topic
[07:16] <didrocks> infinity: the issue is about the "halt/poweroff/reboot…" bins
[07:17] <didrocks> as if you boot with another init, you expect to have the right binaries used of course
[07:17] <didrocks> and right now, they are in the upstart package and systemd-sysv
[07:17] <didrocks> not sure this worth having halt.upstart for instance
[07:18] <didrocks> so, it seems we need a wider discussion to see in which direction we should go
[07:21] <Ukikie> Might want to take into consideration users that do init=/sbin/upstart (as this is easy with grub2 now)
[07:24] <didrocks> Ukikie: that's exactly what we are talking about with this newer split
[07:25] <didrocks> (and that's the reason why we did that grub2 patch)
[07:25]  * Ukikie hides.
[07:25] <didrocks> ;)
[09:38] <oSoMoN> Good morning release team!
[09:38] <oSoMoN> could someone please review bug #1433141 and advise? It’s being validated by the QA team, will shortly be ready to land, but needs an ack from you
[17:33] <bdmurray> slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/phasing-link/+merge/253720
[19:15] <bdmurray> infinity: it looks like it'd be a good idea to get dpkg version 1.17.24 into Vivid. What needs to happen for that?
[19:20] <bdmurray> I'm referring to the "Disable dependency checks on trigger processing." change in it.
[19:43] <infinity> bdmurray: I'll be merging it soon.
[19:45] <bdmurray> infinity: okay, thanks!
[19:55] <bdmurray> infinity: Do you think I should won't fix the bugs created by trigger loops?
[19:56] <infinity> bdmurray: I think they're worth investigation.
[19:56] <infinity> bdmurray: Not in utopic, but in trust->vivid (and, eventually, 14.04->16.04) upgrades, we should care.
[19:57] <bdmurray> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776910 I was reading the last comment there
[19:58] <bdmurray> Paragraphs 2 and 4
[20:01] <infinity> bdmurray: Right, so what I mean by "we should care about trusty->vivid (and beyond)" is that we should only care about trigger cycle bugs found that are upgrading with dpkg 1.7.24 or higher.  Which, if guillem did this right, should be 0.
[20:01] <infinity> bdmurray: But the feature may creep back in before 16.04, and we need to pay attention to that.
[20:01] <infinity> bdmurray: I'll merge today, though, so we can see how this affects new bugs.
[20:02] <infinity> bdmurray: Old ones, we can probably drop on the floor, if no one has the energy to re-test those upgrades.
[20:02] <bdmurray> infinity: I don't think the dpkg version necessarily gets recorded in these apport reports so I'll fixes that.
[20:02] <infinity> bdmurray: If we're not recording dpkg and apt version in all upgrade reports, that's a massive bug.
[20:03] <infinity> bdmurray: And python-apt, if update-manager or ubuntu-release-upgrader was in play.
[20:03] <bdmurray> python-apt will get caught in that case because its a dependency
[20:16] <slangasek> bdmurray: this retrace failed with missing symbols for libsystemd0 and libflac8, which is pretty bad; are these known-missing ddebs? https://errors.ubuntu.com/oops/e3c5729c-cf0a-11e4-8e21-fa163e5bb1a2
[20:17] <slangasek> bdmurray: also, that retrace failed, but neither systemd nor flac libs are in the stack so that's also bad :)
[20:20] <bdmurray> slangasek: known to me yes
[20:28] <slangasek> bdmurray: ah; libsystemd0 is in the list you sent me earlier, I see, but not libflac8.  Anyway, how can we debug the retracing failure, given that it seems unrelated to the missing symbols?  The crash in question was from testing libc from vivid-proposed on a vivid system, would that account for the retracer not knowing where to find the symbols?  And can we extract a core file for manual retraci
[20:28] <slangasek> ng?
[20:29] <slangasek> though libc6 itself wasn't listed as having missing symbols hmm
[20:33] <slangasek> cjwatson: I've tried to enable arm64 builds for ubuntu-core, and it's failing with errors that look like a networking problem; would you know if there's anything particular to twombly that would prevent it from reaching ppas etc? https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/+build/23106
[20:33] <bdmurray> infinity: new apport uploaded
[20:34] <bdmurray> slangasek: I think we save cores for some failures to retrace let me double check
[20:34] <infinity> slangasek: It can obviously reach PPAs, it did so earlier in the build log.
[20:35] <slangasek> ah true enough
[20:35] <slangasek> but it's still failing with networking failures
[20:35] <infinity> Could have just been an intermittent hiccup.
[20:36] <slangasek> could be; retrying
[20:37] <slangasek> note fwiw that arm64 was the only arch that failed with this problem
[20:37] <infinity> slangasek: It's going to fail anyway, that linux-image package doesn't exist.
[20:37] <slangasek> well, that's ok
[20:37] <slangasek> those are bugs that clearly belong to the image :)
[20:39] <infinity> ... how does that work on any arch?
[20:39]  * infinity scratches his head.
[20:39] <infinity> Oh, wait.  linux-packages, not linux-flavours
[20:40] <infinity> Yeah, that should work.
[20:40] <infinity> I just can't read.
[20:42] <elfy> cyphermox: re the com32 bug you just added to - did you mean 13.04 or 14.04?
[20:43] <cyphermox> depends what you mean by what I mean?
[20:43]  * infinity laughs.
[20:44] <cyphermox> writing a live USB from vivid to 13.04 fails to properly start
[20:44] <cyphermox> ... the splash will not show, you'll get that com32 erro
[20:44] <elfy> is that because it's all completely EOL?
[20:45] <elfy> unless you start fiddling with oldubuntu repos
[20:45] <cyphermox> it's just an example of what versions to use, it's because they don't have the same structure for syslinux
[20:45] <cyphermox> you could use 12.04
[20:45] <elfy> ok :) just making sure ...
[20:46] <cyphermox> I mention 13.04 and 13.10 because IIRC that's where the difference was introduced
[20:46] <elfy> I did some tests so I could be sure that people could test jam Xubuntu recently - told them to install gnome-disks and use Disks ...
[20:46] <cyphermox> the exact versions don't matter as long as you use an older version of Ubuntu to write a very recent USB (ie. precise writing vivid), or the other way around
[20:48] <elfy> obviously all of those entailed a vivid image from trusty/utopic or vivid
[20:48] <cyphermox> elfy: since the SRU is for utopic only so far (I haven't tested trusty in a VM here yet, the changes were a bit more complicated), you'll want to use a precise iso for writing
[20:48] <elfy> and for Xubuntu you need to install one or the other ...
[20:49] <cyphermox> I'm not sure I follow
[20:50] <elfy> I'm rambling probably - we were after specific information - whatever you use to do USB stick has to be installed on Xubuntu - so I was looking for something that worked in all 3 scenario's
[20:51] <elfy> I'll wander off again and not confuse the issue further ;)
[20:51] <cyphermox> elfy: use dd if you're unsure
[20:52] <cyphermox> isn't usb-creator installed on xubuntu?
[20:52] <elfy> nope
[20:52] <elfy> oh - actually might be - never use it personally
[20:52] <elfy> cyphermox: didn't want to expose possible new people to getting dd wrong ...
[20:53] <cyphermox> ok
[20:53] <cyphermox> well yeah, getting it wrong is usually disastrous :)
[20:53] <elfy> :)
[20:54] <elfy> usb-creator's not on the manifest for us
[20:54] <cyphermox> no, doesn't look like it's included
[20:54] <cyphermox> might want to consider changing that :)
[20:54] <elfy> why?
[20:54] <elfy> I tell people to use Disks :)
[20:55] <cyphermox> fair enough
[20:55] <cyphermox> well you could still ask them to pull usb-creator-gtk when needed
[20:55] <cyphermox> but if Disks works..
[20:55] <cyphermox> does Disks do a full copy?
[20:56] <elfy> cyphermox: for me at least I got positives using that when doing vivid images from 14.04/14.10/15.04
[20:56] <elfy> restore image
[20:56] <cyphermox> ok, sounds like it's probably nearly the same thing as dd... or running dd in the background
[20:56] <elfy> doesn't make it very easy to deal with the stick afterwards - owned by root
[20:57] <elfy> yep - seems so
[20:57] <bdmurray> slangasek: so we don't save coredumps if RetraceOutdatedPackages is true and it is true if we are missing ddebs as apport mixes the two together
[20:58] <slangasek> infinity: failed again with the same error.  not transient. https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/+build/23110
[20:58] <slangasek> bdmurray: hmm ok
[20:59] <bdmurray> We could start saving them though
[21:00] <slangasek> davmor2: is your media-hub crash with https://errors.ubuntu.com/oops/e3c5729c-cf0a-11e4-8e21-fa163e5bb1a2 still available locally?
[21:00] <slangasek> davmor2: or is the problem reproducible?
[21:00] <slangasek> bdmurray: perhaps a good idea
[21:00] <infinity> slangasek: Curious.  Investigating.
[21:02] <slangasek> does also show the problem is not specific to a single arm64 builder
[21:03] <infinity> slangasek: Yeah, going to reproduce it manually quickly to see WTF it's doing.
[21:03] <slangasek> ok
[21:06] <infinity> Oh, that traceback has the required info.
[21:06] <infinity> I was just blind on the first reading.
[21:06] <infinity> Or the first log had a less useful trace.
[21:06] <infinity> softwareproperties.ppa.PPAException: 'Error reading https://launchpad.net/api/1.0/~snappy-dev/+archive/image: [Errno 110] Connection timed out'
[21:06] <infinity> It's making API calls.
[21:07] <infinity> On the one hand, "ew", on the other hand, can get IS to fix.
[21:07] <slangasek> infinity: so you'll chase it up?
[21:08] <infinity> slangasek: Already on it.
[21:08] <slangasek> ta
[22:10] <infinity> slangasek: So, there may or may not be a cowboy in place that may or may not work (feel free to test), but the larger issue now has a ticket, RT#79768
[22:16] <infinity> slangasek: FWIW, I can make an 'openssl s_client' connection from that network to {api.,}launchpad.net:443 now, so it should work.
[22:20] <infinity> slangasek: Hah, the api call worked and I bet it's now going to fail on contacting keyserver.ubuntu.com
[22:20] <infinity> slangasek: Also, who thought this was a sane thing to do in an image build?
[22:20] <wgrant> Ew
[22:20] <wgrant> ew
[22:21] <infinity> wgrant: Yes, ew.
[22:21] <infinity> wgrant: I said that very same thing 14 minutes ago.
[22:22] <infinity> Yup, there it goes failing on the keyserver.
[22:25] <infinity>     Rename it to the more domain-specific EXTRA_PPAS (which is now a
[22:25] <infinity>     space-separated sequence of <ppa-owner>/<ppa-name> pairs), and fetch
[22:25] <infinity>     signing keys for those from Launchpad using python3-software-properties.
[22:25] <infinity>  -- Colin Watson<EMAIL_ADDRESS>Mon, 19 May 2014 15:28:35 +0100
[22:25] <infinity> wgrant: Hey, don't you employ that guy now? :)
[22:26] <wgrant> Heh
[22:36] <infinity> wgrant: You know, on second thought, the datacentre is probably the only place in the world where add-apt-repository isn't a massive security hole, so maybe it's not that "ew". :P
[22:39] <infinity> wgrant: Speaking of, could we close that massive security hole by serving the actual public keys via https://api.lp.net instead of just fingerprints?
[22:40] <infinity> (Sure, it still means trusting the lp.net SSL cert, but that beats a plain HTTP connection to a keyserver)
[22:40] <wgrant> infinity: I thought the massive security hole was fixed years ago.
[22:41] <wgrant> It's meant to now download into a temporary keyring by fingerprint, then verify the fingerprint before importing into the main keyring.
[22:41] <infinity> wgrant: Verify it against what?
[22:41] <darkxst> infinity, hey, can you bump space on gnome3-staging ppa up a bit? sitting at 92% currently
[22:41] <wgrant> infinity: The fingerprint from the LP API.
[22:42] <infinity> wgrant: Still vulnerable to a fingerprint collision, since it's not the actual public key we're getting via a secure source.
[22:42] <wgrant> infinity: Fingerprint, not ID.
[22:42] <wgrant> If someone manages to collide fingerprints the entire world is broken and we should probably just move into caves.
[22:42] <infinity> wgrant: Oh, well, less bad then, certainly.
[22:43] <infinity> wgrant: Still seems like an odd runaround, since I assume LP has knowledge of the keys somewhere anyway.
[22:43] <wgrant> Colliding fingerprints requires a good SHA-1 preimage attack.
[22:43] <wgrant> infinity: LP just uses keyserver.internal.
[22:43] <wgrant> It doesn't store the keys themselves.
[22:43] <infinity> wgrant: Oh.
[22:44] <infinity> wgrant: Well, I guess ppamaster has them all, but yeah, just on disk.
[22:44] <wgrant> Well, sure, but they're well-defended given that they're private keys...
[22:44]  * infinity nods.
[22:44] <wgrant> The appservers cannot see them!
[22:44] <infinity> Right, if this has been sorted to use fingerprints, I care less.
[22:44] <wgrant> https://launchpad.net/bugs/1016643
[22:45] <infinity> I just saw "whee, downloading a key by ID from an insecure source" and didn't like what I saw. :P
[22:46] <wgrant> (really the bug is in gpg, which should allow secure retrieval)
[22:46] <wgrant> That is, it should verify the fingerprint matches what it requested.
[22:47] <infinity> We could also default to hkps instead of hkp.
[22:47] <infinity> If we're already trusting Canonical SSL certs in this scenario for the LP API, then a cert on the keyserver would be the same level.
[22:47] <wgrant> That provides no value except for preventing someone from watching what you're doing.
[22:47] <wgrant> OpenPGP keys are cryptographically verifiable in other ways, and we should do that without relying on a secure transport.
[22:48] <wgrant> If it requested by key ID from a secure keyserver, I could still upload a colliding key and it will trust it because HTTPS.
[22:48] <infinity> Sure.  I'm definitely no cryptographer.
[22:48] <infinity> But even a fingerprint is less good than the whole public key, one would assume.  Despite, as you say, it being hard to collide.
[22:48] <wgrant> We can verify the fingerprint, and that is secure unless someone has a secret SHA-1 preimage attack, so we should do that.
[22:49] <infinity> Oh, fair point on the ID collision.  keyserver.ubuntu.com is publically modifiable, I forget about that detail.
[22:50] <wgrant> OpenPGP should probably grow SHA-256 fingerprints, though for ECC keys it could also probably print them directly.
[22:51] <wgrant> But even MD5 isn't seriously broken for key fingerprinting purposes.
[22:51] <infinity> Really, fingerprints seem more for human consumption than computers, though.
[22:51] <wgrant> I wouldn't use it, but there are no huge known weaknesses so far.
[22:52] <wgrant> The fingerprint is just the SHA-1 of the public key.
[22:52] <wgrant> Just as we use the SHA-1 of Packages to verify it.
[22:52] <infinity> I'll take your word on the collision-being-hard thing, since you've clearly read more than I have, but it just seems like simple logic that if you could give a computer the public key, you should, cause why intentionally weaken it, even if only by a little bit?
[22:52] <wgrant> (except you don't usually compare Packages files, as they're OpenPGP-signed... by a key that your OS trusts or that you've verified the SHA-1 of!)
[22:53] <wgrant> s/Packages files/Packages files' SHA-1s/
[22:54] <wgrant> SHA-1 is becoming problematic for generic crytographic uses, but in this context it is a good many years away from being an issue.
[22:54] <infinity> And fear of Sha1 is why all the Packages/Sources files now have Sha256, I thought. :P
[22:54] <wgrant> Yes!
[22:54] <wgrant> But that's because a collision attack is plausible there.
[22:55] <wgrant> That's why modern keys use SHA-2 defaults for signatures that they generate.
[22:55] <wgrant> MD5 is very vulnerable to collision attacks, and SHA-1 looks like it will fall soon.
[22:55] <wgrant> But both are still fine against preimage and second-preimage attacks, and those aren't relevant for key fingerprints.
[22:56] <infinity> I imagine this all relates to math I forgot somewhere in my early 20s.
[22:56] <infinity> Intentionally.
[22:56] <wgrant> Collision == choose two inputs that hash to one output
[22:56] <infinity> Yes, I know. :P
[22:56] <wgrant> Preimage == choose one input that hashes to the same as a given input
[22:57] <wgrant> Second-preimage == choose one input that hashes to a given output
[22:57] <wgrant> The infamous PS3 MD5 collision was only possible because they were able to choose most of the data in both inputs, and were able to guess everything they couldn't choose.
[22:58] <infinity> Ahh, so the contention is that sha1 is vulnerable to accidental collisions just because the search space is small and the number of files in the world is large, but actually crafting an intentional and useful collision (like another PGP key) is still hard/impossible.
[22:59] <wgrant> infinity: Not accidental collisions.
[23:02] <wgrant> The contention is rather that collision attacks aren't relevant for public key fingerprints, since the attacker has no input into your public key (unless they compromise your RNG, in which case they probably have your private key anyway), so no collision attack is possible. Combine that with the very low risk of a practical SHA-1 (second-)preimage attack in the next couple of decades, and SHA-1 for
[23:02] <wgrant> fingerprints looks not particularly fatal.
[23:02] <wgrant> Certainly not something I'd pick today, but not a problem for a good long time.


[09:37] <lis> hi.  I was here a couple of days ago to report a fairly serious problem with the kernel image in jammy-proposed and told to pursue it upstream.  I've done that and there is ongoing discussion on LKML now about how to fix the problem.  I'd like to ask again that this update be pulled, because it's going to break stuff if it lands.
[09:38] <lis> relevant links: https://github.com/cockpit-project/bots/pull/5793  https://lkml.org/lkml/2024/1/15/147
[09:38] -ubottu:#ubuntu-kernel- Pull 5793 in cockpit-project/bots "Image refresh for ubuntu-2204" [Open]
[09:38] <lis> the bug has the attention of the block subsystem maintainers and it seems like a fix is on the way shortly (although the details are currently being hashed out)
[09:39] <lis> (i'd have reported this on launchpad but i'm currently locked out of my account and waiting for canonical's support team to reply to my ticket)
[11:48] <tjaalton> it's not getting pulled, but in case there is a respin for other issues, a fix might get in. still needs a bug on lp


[00:12] <teward> jbicha: did you intend to have ItzSwirlz request a sync *then* a debdiff on top of that within the same sync?
[00:12] <teward> s/same sync/same sync bug/ ?
[08:10] <fheimes> Hi, could someone please retrigger the autopkgtest for me:
[08:10] <fheimes> https://autopkgtest.ubuntu.com/request.cgi?release=mantic&arch=amd64&package=gcc-11&trigger=gmp/2%3A6.2.1%2Bdfsg1-1.1ubuntu2   (thx)
[09:45] <seb128> fheimes, retried
[09:46] <seb128> fheimes, in fact the url is not valid, it returned 'You submitted an invalid request: Malformed trigger'
[11:19] <sil2100> @pilot in
[11:26] <mirespace> Hi, could someone trigger some autopkgtest for me? Are for dpdk
[11:26] <mirespace> + amd64: https://autopkgtest.ubuntu.com/request.cgi?release=jammy&package=dpdk&arch=amd64&trigger=dpdk%2F21.11.4-0ubuntu<IP_ADDRESS>~ppa2&ppa=mirespace%2Fmre-dpdk-2026351
[11:26] <mirespace> + arm64: https://autopkgtest.ubuntu.com/request.cgi?release=jammy&package=dpdk&arch=arm64&trigger=dpdk%2F21.11.4-0ubuntu<IP_ADDRESS>~ppa2&ppa=mirespace%2Fmre-dpdk-2026351
[11:26] <mirespace> + ppc64el: https://autopkgtest.ubuntu.com/request.cgi?release=jammy&package=dpdk&arch=ppc64el&trigger=dpdk%2F21.11.4-0ubuntu<IP_ADDRESS>~ppa2&ppa=mirespace%2Fmre-dpdk-2026351
[11:26] <mirespace> (Thanks in advance)
[11:33] <cpaelzer> mirespace: done
[11:33] <mirespace> cpaelzer: thankyou :)
[11:39] <sil2100> I was too late!
[11:48] <mirespace> sil2100: hehehe
[11:53] <mirespace> cpaelzer: Doing the dpdk MRE for lunar (22.11.2), I realized the -1 in debian includes a new package (librte-net-mana23)
[11:56] <mirespace> cpaelzer: so I'm reading the MRE for dpdk, and I don't have context about if it could fit in some of the accepted "backporting features"
[12:21] <cpaelzer> mirespace: you'd want to revert the change so that is does not add the mana driver on the SRUs
[12:21] <cpaelzer> it was fine for mantic
[12:21] <cpaelzer> but won't be for the SRU
[12:21] <cpaelzer> at least IMHO
[12:36] <jbicha> teward: if I were the requester, I would have modified the bug title to say "merge" instead of sync, but I understood what was going on with bug 2027869
[12:36] -ubottu:#ubuntu-devel- Bug 2027869 in cinnamon (Ubuntu) "Sync cinnamon 5.8.4-1 (universe) from Debian experimental (main)" [Undecided, Fix Committed] https://launchpad.net/bugs/2027869
[12:37] <teward> jbicha: ack, came across sponsors as 'odd' hence the question
[13:43] <mirespace> cpaelzer: that was my doubt, thanks
[15:19] <bluca> slyon: will you by any chance have time to look at #1041310 in the next couple of days? If we need to fix something in systemd 254 I need to know pretty soon, otherwise it will be released as-is
[15:19] <bluca> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041310
[15:19] -ubottu:#ubuntu-devel- Debian bug 1041310 in src:netplan.io "netplan.io: autopkgtest fails with systemd v254-rc2" [Important, Open]
[15:20] <Odd_Bloke> o/ Still looking for sponsorship of my debootstrap backports BTW: https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/1990856 (cc sil2100 as patch pilot, perhaps?)
[15:20] -ubottu:#ubuntu-devel- Launchpad bug 1990856 in debootstrap (Ubuntu Jammy) "Does not consider all versions in Packages files" [Undecided, In Progress]
[15:21] <slyon> bluca: I looked into it today. Currently preparing a patch. I will send you the link in a bit.
[15:22] <slyon> bluca: essentially, networkd seems to be more picky about moving an interface from "configuring" to "configured". It waits for an IPv6 RA to be received. So we need to define "accept-ra: false" in Netplan tests to ignore that, or make our test environment (dnsmasq) to actually provide RAs. I've went with the latter.
[15:23] <slyon> bluca: still I see weird error messages from 'networkctl', which seems new, but they do not fail tests. E.g.:
[15:23] <slyon> Failed to query link bit rates: Invalid argument
[15:23] <slyon> Failed to query link DHCP leases: Invalid argument
[15:24] <slyon> I have the impression that these error messages are thrown while the interface is still in "configuring" state, i.e. while waiting for the RA to be processed. It vanishes when calling the same command after a few seconds.
[15:29] <slyon> bluca: https://github.com/canonical/netplan/pull/381
[15:29] -ubottu:#ubuntu-devel- Pull 381 in canonical/netplan "tests:integration: Adopt for systemd v254" [Open]
[15:31] <bluca> thanks!
[15:33] <bluca> is that the only thing needed to make tests happy?
[15:38] <slyon> I think so, yes. I will run a full Netplan vs systemd v254 autopkgtest locally over night and upload this patch into unstable tomorrow it that passed.
[15:39] <bluca> nice, thank you very much
[15:54] <slyon> Oh, I see systemd v254 is already in unstable, so I can rely on upstream CI and/or Salsa CI to do that test for me, which is much quicker than my local VM :) So we should have a resultin ~20 min (https://github.com/canonical/netplan/actions/runs/5589417419/jobs/10217662482?pr=381 & https://salsa.debian.org/debian/netplan.io/-/jobs/4445316)
[19:11] <bryceh> @pilot in
[21:45] <bryceh> @pilot out