[01:05] <Trevinho> dmj_s76: that's something that is using the classic scaling mode, not the new one...
[01:07] <dmj_s76> Trevinho: hmm...there have been a lot changes in the mutter/settings center code recently, even for xorg
[01:07] <dmj_s76> if not directly from hidpi work then from the settings center changes.
[03:16] <tsimonq2> How would I go about using syncpackage with a package from wheezy-security?
[03:17] <tsimonq2> (oh, just as I got done typing that I see other uploads in {stretch,jessie}-security but it's still an interesting question nonetheless)
[03:24] <tsimonq2> (probably just needs --no-lp and the link to the dsc file)
[05:34] <cpaelzer> LocutusOfBorg: your last llvm didn't go in for a failed upload https://launchpadlibrarian.net/337703796/upload_13396831_log.txt
[05:41] <LocutusOfBorg> sure cpaelzer there is an ubuntu3
[05:41] <LocutusOfBorg> not sure why it was good amd64 on my ppa and not on ubuntu official builds
[05:42] <cpaelzer> well only s390x didn't copy
[05:42] <cpaelzer> but ok looking for ubuntu3 then
[05:42] <cpaelzer> ah no ubuntu3 is the one with amd64 issues
[05:42] <cpaelzer> ok I see
[05:44] <LocutusOfBorg> cpaelzer, didn't copy because of superseeded
[05:46] <cpaelzer> well whatever it is worth, the ubuntu2 that didn't copy works
[05:47] <cpaelzer> LocutusOfBorg: since you said the same ubuntu3 worked for you before what is the plan, rebuilding that?
[06:16] <LocutusOfBorg> cpaelzer, I'm trying a patch without that RELWITHDEBINFO
[06:16] <LocutusOfBorg> or relegated only for arm64
[06:23] <cpaelzer> LocutusOfBorg: ok, just let me know if I shall try anything new
[07:05] <doko> LocutusOfBorg, cpaelzer: what are you trying? we are back with two one gigabyte debug builds on ppc64el and s390x, and of course the failing amd64 build
[07:09] <LocutusOfBorg> doko, -g1 is breaking clamav
[07:09] <LocutusOfBorg> -g works
[07:09] <LocutusOfBorg> I'm doing a -g -NDEBUG to see what happens
[07:12] <cpaelzer> doko: bug 1717574
[07:14] <doko> cpaelzer: is this upstreamed to clamav, or are trying to change things which we don't understand? why is a change for the debug information responsible for that?
[07:14] <doko> s/are/are we/
[07:15] <cpaelzer> doko: I only rerun the test and found the link of the issue to llvm - there is no clamav change
[07:16] <cpaelzer> doko: so nothing to upstream there that we'd know yet
[07:16] <cpaelzer> doko: it is just that their bytecode worked before a certina llvm upload and fails since then
[07:16] <doko> cpaelzer: did you try to rebuild clamav with the same flags as llvm?
[07:17] <doko> cpaelzer: or did you try to rebuild clamav at all?
[07:17] <cpaelzer> we rebuilt clamav with old and new llvm, but not change flags
[07:17] <cpaelzer> none of the rebuilds had any effect
[07:17] <LocutusOfBorg> we also tried a new clamav just to be sure
[07:17] <LocutusOfBorg> but yeah, no changes in flags, except for llvm
[07:18] <doko> please can you report that upstream?
[07:20] <cpaelzer> so far things looked like "Ubuntu changed the llvm build and that broke clamav" at least I expected clamav to say "so what fix your llvm" - but I can report if you think that is worth
[07:25] <doko> cpaelzer: we can't accomodate these builds if they take too much disk space to build, and even if, each of these packages take 1 gb, that makes 4gb for every upload ...
[07:28] <cpaelzer> doko: I did never say "please make them big" I'm only naively debugged a clamav crash and found that it is broken since these llvm uploads
[07:28] <cpaelzer> I beg your pardon if that got to you differently
[07:29] <cpaelzer> I'm reporting to clamav and will link it up
[07:30] <cpaelzer> Also the case is easily reproducible, I msut admit I don't even understand why exactly it now fails
[07:30] <cpaelzer> doko: if you follow the bug I linked maybe you can see what the actual root cause might be the reason for that incompatibility
[07:31] <doko> cpaelzer: what is the change in compiler and linker flags?
[07:32] <LocutusOfBorg> cpaelzer, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+packages
[07:32] <LocutusOfBorg>  II uploaded a new llvm with -g1 (to make doko and infra happy) and with -DNDEBUG
[07:32] <LocutusOfBorg> what I discovered, is that ppassing RELWITHDEBINFO flags, overrides the cmake default ones
[07:32] <LocutusOfBorg> and that -DNDEBUG is stripped then
[07:32] <LocutusOfBorg> so the change has probably been a side-effect of that -g1, but not directly related
[07:34] <cpaelzer> I'll test that once it is built LocutusOfBorg
[07:34] <doko> cpaelzer: there's nothing about this -DNDEBUG in the bug report
[07:35] <doko> and then find out why clamav is relying on that ...
[07:35] <LocutusOfBorg> I discovered it some minutes ago, melding the failed amd64 and the succeeded one
[07:36] <LocutusOfBorg> because in my ppa it was good that build
[07:36] <doko> you should turn on creation of debug package in your ppa if you want to simulate the builders
[07:38] <LocutusOfBorg> both enabled, build and publish
[07:38] <LocutusOfBorg> thanks for the reminder, I admit I didn't recheck it
[07:47] <LocutusOfBorg> interesting, libclamav is using some NDEBUG stuff
[07:48] <cpaelzer> LocutusOfBorg: doko: I reported to clamav and linked it up in the bug
[07:49] <cpaelzer> LocutusOfBorg: let me know if/once there is a build I shall try for you
[07:49] <LocutusOfBorg> configure: CXXFLAGS from llvm-config: -I/usr/lib/llvm-3.9/include -std=c++0x -gsplit-dwarf -Wl,-fuse-ld=gold -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -Werror=date-time -std=c++11 -ffunction-sections -fdata-sections -O2 -g -DNDEBUG
[07:49] <LocutusOfBorg> -fno-exceptions -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
[07:49] <LocutusOfBorg> interestingly, clamav is getting the build flags from llvm, so a no change rebuild should change them too
[07:50] <LocutusOfBorg> and in fact this seems to happen
[07:50] <cpaelzer> but you rebuilt a new clamav
[07:50] <cpaelzer> also I did with a local build vs the new library and -dev packages
[07:52] <LocutusOfBorg> but clamav not picking up NDEBUG from llvm flags, means that the code ifdefs are not triggered
[07:52] <LocutusOfBorg> this means less asserts
[07:53] <cpaelzer> but the clamav currently in artful uploaded by mdeslaur still built by picking -DNDEBUG up as it was before the llvm changes
[07:53] <LocutusOfBorg> I think I'll directly upload to Ubuntu this one
[07:53] <cpaelzer> https://launchpadlibrarian.net/333379617/buildlog_ubuntu-artful-amd64.clamav_0.99.2+dfsg-6ubuntu2_BUILDING.txt.gz
[07:54] <cpaelzer> LocutusOfBorg: do you mean we have lost the -NDEBUG in llvm and those "extra" asserts might be the reason to break it now?
[07:54] <LocutusOfBorg> somewhat this is a possible reason
[07:54] <LocutusOfBorg> rebuilding makes it assert because the current llvm in artful proposed is built without
[07:54] <LocutusOfBorg> probably rebuilding it with -DNDEBUG makes it pass
[07:56] <cpaelzer> LocutusOfBorg: ok, so since clamav is already built with -DNDEBUG from the old llvm builds that would mean likely no re-upload there. Once your ppa is ready I would install from it and then retry + rebuild+retry - ok?
[07:57] <LocutusOfBorg> ok
[07:57] <cpaelzer> so waiting on https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+build/13399109 now
[07:57] <LocutusOfBorg> I could also upload directly to Ubuntu
[07:57] <cpaelzer> I personally prefer uploading to ubuntu what is known or at least expected to work
[07:57] <LocutusOfBorg> the current proposed one has debug symbols too huge
[07:57] <cpaelzer> ah, ok I see the reason
[07:58] <LocutusOfBorg> even if not working, it is worth an upload
[07:58]  * LocutusOfBorg meeting time
[07:58] <cpaelzer> well, are you sure the ubuntu5 at least builds and is as good/bad than the last one that had small symbols?
[07:58] <cpaelzer> I'll carry all this discussion into the bug for documentation
[08:04] <LocutusOfBorg> yes, it should build
[08:04] <LocutusOfBorg> now with debug logs melded I had a clear view of the build issue
[09:02] <zhongjun> coreycb: ping
[09:57] <LocutusOfBorg> cpaelzer, mostly built
[09:58] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/llvm-toolchain-3.9/1:3.9.1-16ubuntu4/+build/13399140
[10:51] <petersaints> Hi guys! I was looking at the latest Live CD/USB manifest (http://cdimage.ubuntu.com/daily-live/pending/artful-desktop-amd64.manifest), at the Ubuntu Package Search (https://packages.ubuntu.com/), and at Launchpad (https://launchpad.net/ubuntu), and I noticed that there are still lots of GNOME-related packages with 3.25.x versions (3.26 pre-releases). Will they be replaced with proper 3.26 versions? What about packages that
[10:51] <petersaints> are stuck at 3.24 (e.g., gnome-terminal or gnome-getting-started-docs, among others)? And perhaps there are even packages lingering from even older GNOME releases that I've missed! Any plans about this?
[11:17] <jbicha> petersaints: that's a lot of questions!
[11:18] <jbicha> the docs package might get updated today. Generally if we have a 3.25 version we can update it to 3.26. Terminal might stay at 3.24
[11:19] <jbicha> for 17.10
[11:28] <petersaints> Thats what I thought @jbicha. It wouldn't have made much sense to move packages to 3.25.x if they are not supposed to be replaced by the final 3.26 version.
[11:28] <petersaints> And thanks for the reply jbicha
[11:33] <cpaelzer> LocutusOfBorg: FYI 1:3.9.1-16ubuntu4 from the current build in a-p is not working
[11:33] <cpaelzer> 1:3.9.1-16ubuntu2 from the same place did work
[11:35] <cpaelzer> so while -DNDEBUG was a nice idea, that wasn't it
[11:35] <cpaelzer> no reply on the upstream report yet
[12:13] <doko> mwhudson: golang still at 1.8, and nobody complained?
[12:13] <LocutusOfBorg> so cpaelzer I have zero idea
[12:13] <LocutusOfBorg> if doko is not happy with debug symbols of 1gb, and no other flags changed...
[12:13] <LocutusOfBorg> I don't know
[12:13] <LocutusOfBorg> (I'm not happy with them too, btw)
[12:14] <LocutusOfBorg> cpaelzer, did you try a rebuild of it?
[12:14] <LocutusOfBorg> did you try to use -g1 in clamav too?
[12:28] <cpaelzer> configure: CXXFLAGS from llvm-config: -I/usr/lib/llvm-3.9/include -std=c++0x -Wl,-fuse-ld=gold -Wl,--no-keep-files-mapped -Wl,--no-map-whole-files -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -Werror=date-time -std=c++11 -ffunction-sections -fdata-sections -g1  -
[12:29] <cpaelzer> fno-exceptions -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
[12:29] <cpaelzer> LocutusOfBorg: I thought you brought -DNDEBUG back but in combination with -g1 in ubuntu4
[12:30] <cpaelzer> And failing still when rebuilt against the most recent - as expected
[12:42] <LocutusOfBorg> I'm really with no ideas
[12:42] <LocutusOfBorg> some parts in llvm build log are with -g instead of -g1
[12:42] <LocutusOfBorg> not sure why
[12:42] <LocutusOfBorg> btw manually adding -DNDEBUG does change something?
[12:53] <doko> ohh wonderful new gnome3 world ...
[12:57] <doko> Laney, seb128: python2 is back on the desktop. was this intended?
[12:58] <doko> ubuntu-artwork team using python2. great!
[12:59] <doko> ... and samba is installed by default again ...
[13:01] <seb128> doko, what is bringing it in
[13:01] <seb128> ?
[13:02] <doko> seb128: ^^^
[13:02] <seb128> doko, ubuntu-artwork team ... a team is using python?
[13:02] <seb128> for what  package?
[13:03] <doko> ahh, adium-theme-ubuntu
[13:07] <doko> seb128: or is this temporary and will be replaced?
[13:08] <abeato> sil2100, hi, I have tried to use '--image-size' option in ubuntu-core. The effect is that the size of the resulting volume is as I specified, but the rootfs partition has the same size as before, leaving empty space in the volume...
[13:09] <abeato> sil2100, is that a bug?
[13:09] <seb128> doko, that seems like a packaging error, let me look
[13:09] <abeato> s/ubuntu-core/ubuntu-image
[13:09] <doko> just asking because this theme has changes up to 2012, and one in 2016
[13:12] <seb128> doko, that theme is not very active indeed but can still be useful
[13:13] <doko> seb128: but it's installed by default
[13:13] <seb128> right
[13:13] <seb128> it's still useful
[13:14] <doko> ok, converting to py3
[13:14] <seb128> doko, you know python build systems better than me, why is that package even getting a depends on python?
[13:14] <seb128> doko, it uses     ${python:Depends},
[13:14] <seb128> but there is no python file included in the deb
[13:15] <seb128> doko, it has a setup.py that is just used to copy files to the right target as far as I can tell
[13:16] <doko> seb128: yes, I see that, but it provides an egg-info file too. why?
[13:16] <seb128> bug
[13:16] <seb128> ?
[13:16] <seb128> where is that coming from
[13:16] <seb128> it's not in the source?
[13:17] <doko> because it's *built* as a python module. see setup.py
[13:18] <seb128> is that easy to change?
[13:18] <seb128> I don't know that build system at all
[13:19] <seb128> doko, I guess I could just revert the packaging changes in http://launchpadlibrarian.net/255953920/adium-theme-ubuntu_0.3.4-0ubuntu1_0.3.4-0ubuntu2.diff.gz
[13:19] <seb128> before that it didn't have that depends
[13:20] <doko> seb128: sure, sounds fine
[13:20] <seb128> k
[13:20] <doko> seb128: and the status quo about samba was, that it was installed on demand, afaik
[13:21] <seb128> what is pulling it in now?
[13:22] <seb128> doko, samba itself isn't installed, only -common-bin?
[13:22] <seb128> and libs
[13:22] <doko> seb128: gnome-control-center -> gvfs-backends libsmbclient
[13:22] <doko> libsmbclient is linked against libpython2.7
[13:22] <seb128> ah
[13:23] <seb128> that's not a new issue
[13:23] <seb128> we never resolved that one afaik
[13:23] <doko> yes, but now it's pulled in unconditinally
[13:23] <seb128> it always was
[13:23] <doko> no?
[13:23] <seb128> libsmbclient is used by the gvfs samba backend
[13:23] <doko> we had python2 free desktop images in the past
[13:23] <seb128> are you sure? when?
[13:24] <seb128> I don't think we ever got there
[13:32] <cpaelzer> LocutusOfBorg: -g1 -NDEBUG on the clamav rebuild still not changing a thing
[13:32] <cpaelzer> it is llvm that has "changed"
[13:32] <cpaelzer> I'm lost
[13:33] <cpaelzer> hope that upstream respsonds at some point
[13:33] <seb128> doko, I've uploaded a fix for the theme
[13:33] <cpaelzer> completely disabling llvm support in clamav is the only option that I could toggle on clamav to unbreak it
[13:33] <LocutusOfBorg> I agree with doko on the fact that the change -g -g1 should have no effect, because symbols file are outside the package and stripped away
[13:33] <cpaelzer> but then I wonder if there is more out there that might react to thellvm change
[13:34] <cpaelzer> I totally agree, but I can only report what I see :-/
[13:35] <cpaelzer> LocutusOfBorg: do you know if the -g1 change was also done in Debian already?
[13:35] <cpaelzer> that might be a great chance to cross check there
[13:35] <LocutusOfBorg> yes, and it is not failing there
[13:35] <LocutusOfBorg> I already tried a no change rebuild
[13:36] <cpaelzer> ld/glibc then maybe?
[13:36] <LocutusOfBorg> the llvm in artful is in sync with the one in debian
[13:36] <LocutusOfBorg> (the one in artful proposed not really)
[13:36] <LocutusOfBorg> ld is in sync, because binutils is at the same version
[13:36] <LocutusOfBorg> glibc isn't
[13:36] <LocutusOfBorg> (this is why I put glibc on the table)
[13:37] <cpaelzer> fortunately libc6 is the simplest package to exchange for a test :-/
[13:37] <LocutusOfBorg> lol
[13:38] <cpaelzer> so zesty + new llvm + new clamav might be the closest low-hanging-fruit to try
[13:38] <LocutusOfBorg> you can ask infinity to upload new glibc on debian experimental
[13:38] <LocutusOfBorg> and test there
[13:39] <cpaelzer> good idea as well
[13:39] <doko> cpaelzer, LocutusOfBorg: did you compare the build flags from before and after these changes?
[13:40] <LocutusOfBorg> doko, melding the build flags is painful with 500k logs
[13:40] <doko> I now ...
[13:41] <LocutusOfBorg> for some reasons current llvm does -g somewhere and -g1 somewhere else
[13:41] <LocutusOfBorg> so, not even in sync with itself
[13:41] <cpaelzer> clamav picks up the CXX Flags from llvm-config - so the one in artful righ tnow still has -g, but rebuilding with the -g1 doesn't change anything
[13:41] <LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+build/13396394
[13:42] <cpaelzer> also tried the -NDEBUG, same (no) effect
[13:42] <LocutusOfBorg> this is the llvm that worked
[13:42] <LocutusOfBorg> cpaelzer, confirm please :)
[13:42] <cpaelzer> confirmed
[13:43] <cpaelzer> of the -16 series ubuntu1 = bad, ubuntu2 = good, ubuntu 3 doesn't exist) ubuntu4 = bad
[13:43] <cpaelzer> all -g1 are bad for the case at hand, but they obviously fix the huge debug symbols
[13:44] <cpaelzer> the NDEBUG was the other flag that LocutusOfBorg found, but that didn't resolve it either
[13:44] <cpaelzer> and we all agree that without debug symbols installed the effect of -g[1] should be non
[13:44] <cpaelzer> but this is "shoult (tm)" which never does as it should :-)
[13:45] <LocutusOfBorg> why the hell the NDEBUG is not there
[13:45] <LocutusOfBorg> hold on
[13:47] <LocutusOfBorg> :/
[13:48] <doko> seb128: incomplete, you need to use python3:Depends. otoh, you should just remove the egg-info file, shouldn't you?
[13:48] <LocutusOfBorg> cpaelzer, please try the llvm ubuntu5 I have just uploaded
[13:48] <LocutusOfBorg> :(
[13:48] <doko> or just remove the python:Depends
[13:48] <seb128> doko, I'm not familiar with python packaging, feel free to fix it (or to let it like that, it removed the depends which was not useful anyway)
[13:50] <doko> later, I have an idea how to remove the interpreter from the images ...
[13:53] <seb128> doko, oh, how? and did you figure out if python was really off the iso on some serie and when? (I'm happy to compare/look what regressed if that's the case)
[13:54] <cpaelzer> LocutusOfBorg: https://launchpad.net/ubuntu/+source/llvm-toolchain-3.9/1:3.9.1-16ubuntu5 ?
[13:54] <cpaelzer> will do so
[13:54] <LocutusOfBorg> did you spot the error?
[13:55] <cpaelzer> I didn't compare debdiffs or anything
[13:55] <cpaelzer> I just read you cahngelog and will try later
[13:55] <LocutusOfBorg> you can see it in the web interface
[13:55] <LocutusOfBorg> just click on the link at the bottom
[13:55] <LocutusOfBorg> :)
[13:55] <LocutusOfBorg> once it is generated
[13:55] <cpaelzer> sure, but I only click there if needed :-)
[13:55] <cpaelzer> it is there already
[13:56] <cpaelzer> oh I see, yeah +=/=
[13:56] <cpaelzer> so O2 and NDEBUG went away
[13:56] <cpaelzer> well worth a try for sure
[13:56] <cpaelzer> you don't have to upload to a-p all the time
[13:56] <cpaelzer> I'm fine with a ppa
[13:57] <cpaelzer> until we have settled on one working version
[14:08] <doko> seb128: https://launchpad.net/ubuntu/+source/talloc/2.1.9-2ubuntu1
[14:09] <seb128> doko, let's see how that goes :-)
[14:13] <LocutusOfBorg> cpaelzer, cross your fingers
[14:13] <LocutusOfBorg> :)
[14:34] <doko> seb128: done, shouldn't be there anymore on the image
[14:34] <seb128> great
[14:54] <smoser> didrocks, i have a question wrt your continued posts on desktop stuff.
[14:54] <smoser> mostly this is due to my novice like understanding of desktops
[14:54] <smoser>  https://didrocks.fr/2017/08/23/ubuntu-gnome-shell-in-artful-day-7/
[14:55] <smoser> i used rely on 2 indicators heavily
[14:55] <didrocks> smoser: you should have the indicators shown there
[14:55] <smoser>  * the 'mail' icon, which would go blue when xchat highlighted me
[14:55] <didrocks> but it's only appindicator
[14:55] <didrocks> not messaging indicator
[14:56] <smoser>  * the indicator multiload indicator
[14:56] <didrocks> (the mail icon was the messaging indicator)
[14:56] <didrocks> so you will only get the first one
[14:56] <smoser> (see, you just went way over my head with the distinction of 'appindicator' and 'messaging indicator' )
[14:56] <smoser> :)
[14:56] <didrocks> heh, I'm a little bit late and need to head out
[14:56] <didrocks> we can talk about it tomorrow or andyrock can help you ^
[14:56] <seb128> I can reply
[14:57] <smoser> ok. thanks.
[14:57] <didrocks> ah seb128 as well :)
[14:57] <didrocks> thanks seb128 :)
[14:57] <seb128> waiting to see where smoser is going
[14:57] <seb128> yw!
[14:57] <smoser> :)
[14:57] <smoser> so i just ran 'indicator-multiload' and it seems like it only gets a dozen pixels wide or so
[14:58] <smoser> and then i really want *some* indication that i got a xchat highlight.
[14:58] <smoser> are we expecting to get a 'messaging indicator' again ?
[14:59] <seb128> smoser, for the monitor you might want to try https://extensions.gnome.org/extension/120/system-monitor/ or look for similar extensions
[14:59] <seb128> smoser, not at the moment but we are trying to get back the "unread count" on the launcher, see bug #1713712
[14:59] <seb128> smoser, like https://user-images.githubusercontent.com/3677105/30074008-23a5de62-9270-11e7-91e1-19ebc7b7dade.png
[15:00] <seb128> smoser, that should give you hint about IRC pings and unread email
[15:00] <seb128> if you use apps that integrate, like hexchat and tb
[15:02] <smoser> seb128, thanks.
[15:03] <jibel> FWIW, I replaced indicator multiload by the extension seb128 mentioned when I switched to gnome-shell and never went back.
[15:16] <ricotz_> LocutusOfBorg, hi, is it expected that the installed libllvm3.9 grew by 44MB with -16ubuntu2?
[15:17] <ricotz_> I mean -16ubuntu4
[15:28] <LocutusOfBorg> ricotz, yes, I changed the -g flag
[15:30] <ricotz> LocutusOfBorg, ah, I see
[15:33] <LocutusOfBorg> ricotz, the latest ubuntu5 should be fine again
[15:33] <ricotz> ok
[15:34] <LocutusOfBorg> I missed a "+" so the NDEBUG and the -O2 got stripped
[16:34] <sboeuf_> apw: Hi, James Hunt told me you are a Ubuntu kernel maintainer and I have a question regarding the recent kernel supplied by Canonical in the Ubuntu 16.04.3 LTS image through Azure
[16:35] <sboeuf_> apw: I have noticed that the kernel bumped from 4.4.0-92-generic (yesterday) to 4.11.0-1011-azure (today)
[16:36] <sboeuf_> apw: the problem being that 4.11.0-1011-azure does not have CONFIG_KVM enabled
[16:36] <sboeuf_> apw: is that expected ?
[16:41] <smoser> seb128, sorry. you're prbably gone now, but i just looked at your screenshot. the only thing that i'd suggest is that any unread counts in hte launcher i'm generally not going to see because it auto-hides.l  the panel blue envelope i saw all the time.
[16:41] <apw> sboeuf_: in azure or elsewhere?
[16:41] <sboeuf_> in azure
[16:42] <sboeuf_> apw: ^
[16:42]  * ogra_ is curious how the -generic kernel ended up there in the first place
[16:43] <apw> ogra_: virtual reports as generic
[16:43] <ogra_> ah
[16:43] <sboeuf_> ogra_: well that's supposed to be a completely *clean* Ubuntu 16.04 image, meaning that it is supposed to be delivered with the generic kernel, right ?
[16:43] <ogra_> but wouldnt -azure have been used initially ?
[16:44] <apw> ogasawara: |`
[16:45] <sboeuf_> apw: ogra_ : I don't really know if the "generic" name matters here, but basically the latest kernel provided by Canonical for the Ubuntu 16.04 image does not enable KVM anymore
[16:46] <ogra_> no, the name doesnt matter for that particular issue ... i was just curious why the original image didnt use -azure in the first place
[16:46] <sboeuf_> apw: ogra_ : and that's an issue since I am using some Azure platforms allowing nested VM
[16:51] <apw> you should be able to switch by installing linux-hwe by eneric
[16:51] <apw> bloody autocorrupt
[16:52] <apw> linux-generic
[16:53] <ogasawara> sboeuf_: we are talking with Microsoft right now about this
[16:54] <ogasawara> sboeuf_: and relaying impact of it not being enabled
[16:59] <sboeuf_> ogasawara: oh okay, thank you
[17:00] <sboeuf_> ogasawara: do you know the timeline for a new release (if you/they agree on releasing a new Ubuntu 16.04 with a kernel supporting KVM) ?
[17:01] <ogasawara> sboeuf_: I suspect we could respin a kernel in a day once we reach agreement
[17:01] <sboeuf_> apw: what do you mean ? installing when logged into the distro ? or you suggest custom image ?
[17:01] <sboeuf_> ogasawara: oh that's pretty fast ;)
[17:01] <ogasawara> sboeuf_: apw was suggesting you could go back to the previous linux-virtual kernel
[17:02] <apw> when logged into the instance install linux-virtual and reboot selecting that kernel
[17:08] <sboeuf_> apw: that's a good idea but I need to see how it goes about interactions between my Jenkins CI and the automation of Azure VMs launching
[17:10]  * apw nods
[17:10] <LocutusOfBorg> apw :force-badtest virtualbox/5.1.26-dfsg-2
[17:11] <LocutusOfBorg> please update it! 5.1.28-dfsg-1
[17:11] <LocutusOfBorg> or make it versionless
[17:11] <LocutusOfBorg> thanks :)
[17:11] <Laney> it'd be good to fix dkms ...
[17:12] <LocutusOfBorg> now it is currently blocking libpng and python :)
[17:12] <LocutusOfBorg> dkms can wait I guess
[17:12] <LocutusOfBorg> maybe you can just lower a little bit the kernel version for the module
[17:12] <LocutusOfBorg> calling it 5.1.28~
[17:12] <LocutusOfBorg> so the virtualbox-dkms one has higher value and overrides it
[17:13] <apw> interesting thought, I like that
[17:14] <LocutusOfBorg> :)
[17:14] <LocutusOfBorg> or I can increase it
[17:14] <LocutusOfBorg> I appreciate having higher priority wrt your module
[17:15] <apw> we should reduce will look at it when I have power again
[17:27] <sboeuf_> apw: btw, how am I supposed to reboot to the new installed kernel (modifying grub I guess)
[17:45] <LocutusOfBorg> apw, in case you want to override the virtualbox one you can call it 5.1.28Ubuntu1
[17:45] <LocutusOfBorg> otherwise a ~Ubuntu1 might be the best versioning
[17:45]  * LocutusOfBorg didn't test that
[17:48] <apw> LocutusOfBorg: likely we want the dkms package to replace in case you want the live ones
[17:53] <LocutusOfBorg> why should somebody prefer them? maybe because they  might be signed?
[18:05] <ogasawara> sboeuf_: fyi bug 1718740
[18:08] <dmj_s76> ping Trevinho
[18:08] <Trevinho> dmj_s76: hey
[18:12] <dmj_s76> When you were making the hidpi changes, did any of the multimonitor (not fractional) work get incorporated in a way that xorg would use or was that purely left in the old way?
[18:12] <Trevinho> dmj_s76: no, there was a big refactoring of the configuration management which jonas did...
[18:16] <dmj_s76> Trevinho: so this is probably the configuration changes separate from the hidpi work, xorg should be using the same exact scaling mechanisms as before, and the new config settings tools just didn't get any testing for scaling on xorg.
[18:19] <Trevinho> dmj_s76: I suggest you to ping Jonas in #gnome-shell (he will be available later)
[18:19] <Trevinho> (jadahl is the nick)
[18:20] <dmj_s76> yeah, waiting on a response :)
[18:20] <dmj_s76> Thanks!
[18:49] <jtaylor> tjaalton: xorg in artful probably needs https://lists.freedesktop.org/archives/wayland-devel/2017-August/034895.html
[18:50] <jtaylor> part of the pointer confine fixes the package already has
[18:59] <tjaalton> jtaylor: I think that patch was dropped from artful already
[19:01] <jtaylor> tjaalton: dropped as in added and removed again?
[19:01] <seb128> jtaylor, https://launchpad.net/ubuntu/+source/xorg-server/2:1.19.3-1ubuntu6
[19:02] <seb128> jtaylor, which was the segfault your fix addresses
[19:03] <jtaylor> seb128: no its the xwayland-pointer-confine.diff
[19:03] <jtaylor> I have added the patch to ubuntu6 and it fixed my issue
[19:03] <seb128> jtaylor, what issue? did you report it to lp?
[19:04] <jtaylor> no, it requires prop. software to reproduce, though according the xwayland bug it can be reproduced with qemu too
[19:05] <jtaylor> ah you commented on the bug :) https://bugs.freedesktop.org/show_bug.cgi?id=102474
[19:05] <jtaylor> I think
[19:06] <tjaalton> well i can drop that one too :)
[19:07] <seb128> jtaylor, well for me (and I reported the upstream bug you mention) the upload withough xwayland-add-grab-protocol-support.diff fixes the issue
[19:08] <seb128> tjaalton, or just include the fix
[19:08] <tjaalton> sure
[19:09] <jtaylor> fwiw the program I hit the crash was the steam game xcom2 in windowed mode which is already buggy as all hell
[19:09] <jtaylor> but with that patch at elast it doesn't crash wayland :)
[19:14] <Odd_Bloke> slangasek: What's the alternative to dhclient hooks in the networkd world?  Do you know?
[19:18] <slangasek> Odd_Bloke: so, I think you can introspect /run/systemd/netif/leases after the fact; there is no explicit hook mechanism because networkd itself is designed to be asynchronous and non-blocking, so there would be some scaffolding to build up around querying + triggering
[19:18] <slangasek> I haven't checked if anyone is already working on this generically around networkd
[19:18] <slangasek> (haven't checked recently)
[19:18] <cyphermox> right
[19:19] <slangasek> Odd_Bloke: and you should spot-check that /run/systemd/netif/leases actually gives you all the info you require
[19:19] <cyphermox> leases will tell you some of what you want to know, otherwise you'd need to have a unit trigger based on a network interface being up, I guess?
[19:19] <slangasek> cyphermox: we need to get the actual value of the ntp server passed by the dhcp server
[19:20] <slangasek> and reconfigure the ntp client based on changes
[19:20] <cyphermox> right, that's why I say from leases (which should have some data from the dhcp server), and trigered from a job
[19:20] <cyphermox> or timedateddd or whatever it's called.
[19:20] <slangasek> right, you said "some of" what we want to know, we need to know that it tells us everything we want to know (except the timing)
[19:21] <cyphermox> I don't know right now, will be able to tell you in a few minutes
[19:21] <cyphermox> this desktop is using NM, I'm installing an artful VM with server :)
[19:22] <slangasek> I was just going to spin up an instance directly on GCE to check
[19:22] <cyphermox> yeah, or that
[19:24] <slangasek> # grep -i ntp /run/systemd/netif/leases/2
[19:24] <slangasek> NTP=<IP_ADDRESS>
[19:24] <slangasek> #
[19:24] <slangasek> lgtm
[19:25] <cyphermox> yup
[19:25] <cyphermox> 2 would be the ifindex of the interface, if you care
[19:25] <slangasek> yeah, that's the scaffolding bit that sucks to write
[19:26] <cyphermox> indeed :)
[19:26] <slangasek> well, possibly we don't need to map interfaces
[19:26] <slangasek> we just need to know whether the set of ntp servers has changed as a result of any interface going up or down
[19:26] <slangasek> (... or getting a new lease)
[19:26] <cyphermox> what if more than one iface comes up, with a different NTP server?
[19:26] <slangasek> so we don't need to know /which/ interface triggered, we just need to know there was an event, and re-examine /run/systemd/netif/leases/*
[19:27] <cyphermox> oh, I guess you just re-read everything then
[19:27] <slangasek> the sensible default behavior is to take the union of those values, unless we have configuration telling us to ignore ntp from one source but not another
[19:27] <cyphermox> yes
[19:27] <slangasek> (which AFAIK for ifupdown+dhclient we have never had previously)
[19:28] <slangasek> Odd_Bloke: sound good so far? :P
[19:29] <cyphermox> slangasek: that NTP value looks odd though, that's a zeroconf address. not that it means it's wrong, just surprising to see.
[19:30] <Odd_Bloke> cyphermox: That's the GCE metadata server IP address.
[19:30] <slangasek> cyphermox: indeed, and therefore I went to double-check if it's really there; and I discovered that a) yes the address pings, and b) it's also the DNS server and functions as one, and c) this GCE daily image has broken /etc/resolv.conf
[19:30] <Odd_Bloke> And the EC2 one, for that matter.
[19:30] <cyphermox> weee
[19:30] <cyphermox> yeah, I supposed it might be good in this context, for ease of use or something
[19:31] <slangasek> Odd_Bloke: are you aware of /etc/resolv.conf pointing to non-existent ../run/resolvconf/resolv.conf in the latest artful daily?
[19:31] <Odd_Bloke> slangasek: Nope.
[19:31] <Odd_Bloke> Well, I mean, I am now. :p
[19:31] <slangasek> :)
[19:31] <slangasek> daily-ubuntu-1710-artful-v20170920
[19:32] <Odd_Bloke> Ah, it's fine on the Alan-built image from today: daily-ubuntu-alan-1710-artful-v20170921
[19:32] <slangasek> ok
[19:33] <Odd_Bloke> cyphermox: It also won't accidentally route outside of the cloud, IIUC.
[19:33] <slangasek> (that's good, because I didn't find any code in livecd-rootfs that would've broken it)
[19:33] <cyphermox> Odd_Bloke: that too, yep
[19:34] <sarnold> what's a reasonable upper-limit on the number of interfaces that may exist? re-reading them all on a change may be painful on a host with a few thousand containers?
[19:35] <slangasek> sarnold: generally your containers are on a shared bridge as seen from the host, no?
[19:36] <slangasek> and you would only have lease files for interfaces where you have run a dhcp client
[19:36] <slangasek> (AIUI)
[19:37] <sarnold> slangasek: ah I thought there was a commonly-used mode with per-container interfaces on the host too
[19:37] <sarnold> ah good good
[19:40] <ginggs> kirkland: hi, do you know petname is FTBFS? https://launchpad.net/ubuntu/+source/petname/2.6-0ubuntu1
[19:40] <kirkland> ginggs: oh!  no, I hadn't noticed...  let me fix that :-)
[19:41] <kirkland> TEST [12/16]: Ensure all adverbs are common in the SCOWL database [usr/share/petname/medium/]...
[19:41] <kirkland> skillfully
[19:41] <kirkland> ⤷ Failure
[19:41] <kirkland> odd...
[20:07] <kirkland> ginggs: out of curiosity... did you notice that because you needed something from petname, or just because you were looking at FTBFS generally?
[20:26] <sboeuf_> ogasawara: that's great, thank you very much ! So basically, what does mean that the fix has been submitted ? Does that mean it is up to Azure now to publish the updated version ?
[20:28] <bjf> sboeuf_, we will build a new kernel today and get that out after some testing. then you would be able to upgrade the kernel for your instances
[20:28] <bjf> sboeuf_, it will take a little longer (a couple days I believe) for that new kernel to be the default in new images
[20:33] <sboeuf_> bjf: ok makes sense, thanks for the heads up
[20:33] <bjf> sboeuf_, np
[20:42] <Odd_Bloke> slangasek: Hmm, so I don't particularly want to take on building a generic solution (or even a specific one, if I can avoid it :p); any suggestions on next steps to resolve this?
[20:43] <slangasek> Odd_Bloke: scrape the above IRC backlog into a trello card? :)
[20:44] <Odd_Bloke> Will do.
[20:47] <TJ-> Odd_Bloke: could you tie into how systemd-timesyncd receives the NTP server addresses from networkd in some way?
[21:06] <ginggs> kirkland: just trawling FTBFSs
[21:06] <slangasek> kirkland: have you been receiving the britney nagmails regarding your package being delayed in -proposed?
[21:12] <kirkland> slangasek: don't think so...  can you give me a key phrase to search for?  maybe it's getting filtered...
[21:12] <kirkland> slangasek: I searched for "britney petname" and got nothing
[21:13] <cjwatson> try "proposed-migration"
[21:13] <slangasek> kirkland: Subject: [proposed-migration] petname $version stuck in artful-proposed for EIGHTY YEARS
[21:22] <kirkland> slangasek: negative;  not getting any of those
[21:22] <kirkland> slangasek: should this just be going to my upload address
[21:22] <slangasek> that's a good question
[21:22] <slangasek> since there was a bit of hacking around in the implementation to deal with the fact that snakefruit was still running on precise at the time
[21:22] <kirkland> slangasek: for better or worse, all of my mail eventually just collates down to a gmail address
[21:22] <slangasek> and therefore was not using launchpadlib
[21:25] <slangasek> kirkland: I can confirm emails have never been sent for petname :)
[21:25] <slangasek> now to see why
[21:26] <kirkland> slangasek: ah?  my fault?
[21:26] <slangasek> kirkland: not directly, no
[21:27] <slangasek> you're just exposing a bug somewhere in the britney policy
[21:27] <kirkland> slangasek: woot?
[22:04] <Odd_Bloke> TJ-: Unfortunately, it looks like timesyncd uses inotify in-process (via a systemd library) to be notified on new time servers from DHCP.
[22:04] <TJ-> Odd_Bloke: I was afraid of that :)
[22:05] <TJ-> Odd_Bloke: never easy is it!?
[22:05] <Odd_Bloke> Generally not, no. :p
[23:15] <slangasek> kirkland: ah, so it comes down to the fact that "missing package builds" is treated as a "temporary" failure in britney; even after 118 days.  So you should have received the emails informing you of the build failure initially, but don't get any other emails currently for the case of a build failure


[06:19] <icey> coreycb: vorlon: I'm going to work those python-pbr removals today
[06:27] <didrocks> RAOF: hey, can you resume phasing of gnome-shell on focal? The new reported crash has nothing to do with the area we patched (and the error rate was already low, so I guess it’s just a bump in the matrix :p)
[06:50] <LocutusOfBorg> hello, can anybody please review vbox* from SRU queue?
[06:51] <LocutusOfBorg> maybe tjaalton pleeeeeeeease? :D
[06:53] <enyc> =)
[06:55] <LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/virtualbox-ext-pack/+bug/1926937
[08:16] <RAOF> didrocks: Has someone else got to that? It doesn't look to me like it's halted phasing.
[08:16] <didrocks> RAOF: ah, I received an email telling me so, but I don’t know how to check and if somebody else unblocked (but I didn’t get any other answer than you)
[08:37] -queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (core)
[09:49] <RAOF> I'm just looking at https://people.canonical.com/~ubuntu-archive/phased-updates.html , which doesn't list any errors for gnome-shell/focal.
[10:26] <xnox> didrocks:  after initial release, the rate of crashes can be inflated if there is 1 crash 1 min after being phased, which dies down as time progresses. Once it does, and the crash rate drops below normal, phasing auto restarts by itself.
[10:26] <xnox> is roughly the explanation i got about this before. because math is actually hard for this stuff, given that we have unknown number of installs.
[10:27] <xnox> so if on https://people.canonical.com/~ubuntu-archive/phased-updates.html rate increase is empty, live is good, and phasing is comencing.
[10:45] <juliank> I'd appreciate someone to approve shim signed tarballs on xenial
[10:45] <juliank> :)
[10:50] -queuebot:#ubuntu-release- Unapproved: ii-esu (focal-proposed/universe) [1.0a.dfsg1-8build3 => 1.0a.dfsg1-8build4] (no packageset)
[10:51] -queuebot:#ubuntu-release- Unapproved: tatan (focal-proposed/universe) [1.0.dfsg1-8build3 => 1.0.dfsg1-8build4] (no packageset)
[10:51] -queuebot:#ubuntu-release- Unapproved: projectl (focal-proposed/universe) [1.001.dfsg1-9build3 => 1.001.dfsg1-9build4] (no packageset)
[10:57] -queuebot:#ubuntu-release- Unapproved: a7xpg (focal-proposed/universe) [0.11.dfsg1-10build3 => 0.11.dfsg1-10build3.1] (no packageset)
[10:57] -queuebot:#ubuntu-release- Unapproved: dustmite (focal-proposed/universe) [0~20170126.e95dff8-3build3 => 0~20170126.e95dff8-3build3.1] (no packageset)
[10:57] -queuebot:#ubuntu-release- Unapproved: ii-esu (focal-proposed/universe) [1.0a.dfsg1-8build3 => 1.0a.dfsg1-8build3.1] (no packageset)
[10:57] -queuebot:#ubuntu-release- Unapproved: parsec47 (focal-proposed/universe) [0.2.dfsg1-9build3 => 0.2.dfsg1-9build3.1] (no packageset)
[10:57] -queuebot:#ubuntu-release- Unapproved: tatan (focal-proposed/universe) [1.0.dfsg1-8build3 => 1.0.dfsg1-8build3.1] (no packageset)
[10:57] -queuebot:#ubuntu-release- Unapproved: torus-trooper (focal-proposed/universe) [0.22.dfsg1-12build3 => 0.22.dfsg1-12build3.1] (no packageset)
[10:57] -queuebot:#ubuntu-release- Unapproved: val-and-rick (focal-proposed/universe) [0.1a.dfsg1-6build3 => 0.1a.dfsg1-6build3.1] (no packageset)
[10:57] -queuebot:#ubuntu-release- Unapproved: dub (focal-proposed/universe) [1.19.0-1build2 => 1.19.0-1build2.1] (no packageset)
[10:57] -queuebot:#ubuntu-release- Unapproved: mu-cade (focal-proposed/universe) [0.11.dfsg1-12build4 => 0.11.dfsg1-12build4.1] (no packageset)
[10:57] -queuebot:#ubuntu-release- Unapproved: titanion (focal-proposed/universe) [0.3.dfsg1-7build3 => 0.3.dfsg1-7build3.1] (no packageset)
[10:57] -queuebot:#ubuntu-release- Unapproved: gunroar (focal-proposed/universe) [0.15.dfsg1-9build3 => 0.15.dfsg1-9build3.1] (no packageset)
[10:57] -queuebot:#ubuntu-release- Unapproved: tumiki-fighters (focal-proposed/universe) [0.2.dfsg1-9build3 => 0.2.dfsg1-9build3.1] (no packageset)
[10:57] -queuebot:#ubuntu-release- Unapproved: projectl (focal-proposed/universe) [1.001.dfsg1-9build3 => 1.001.dfsg1-9build3.1] (no packageset)
[10:57] -queuebot:#ubuntu-release- Unapproved: rejected ii-esu [source] (focal-proposed) [1.0a.dfsg1-8build4]
[10:57] -queuebot:#ubuntu-release- Unapproved: rejected tatan [source] (focal-proposed) [1.0.dfsg1-8build4]
[10:57] -queuebot:#ubuntu-release- Unapproved: rejected projectl [source] (focal-proposed) [1.001.dfsg1-9build4]
[11:23] <paride> laney, hi!
[11:24] <paride> laney, it seems that we're having issues with the image building process, see for example https://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/impish/daily-live-20210622.log
[11:25] <paride> which *may* be a hiccup, but the previous builds also failed, see for example https://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/impish/daily-live-20210621.log
[11:25] <paride> which has error lines like: ERROR WHILE BUILDING OFFICIAL IMAGES !!
[11:26] <paride> and indeed the 'pending' images on cdimage.ubuntu.com are outdated
[11:29] <paride> it seems that the latest round of correctly generated Impish ISO images are: Ubuntu-Server 21.10 "Impish Indri" - Alpha amd64 (20210614.1)
[11:29] <didrocks999> xnox: oh, interesting, I didn’t know there was that euristic, how can we know that phasing has restarted?
[11:29] <didrocks999> xnox: just checking phased-updates with empty rate?
[11:30] <paride> laney, is this something you can look into?
[11:30] <laney> paride: the latest one looks like a blip - there were some git.lp.n outages yesterday
[11:30] <laney> previous to that the images were broken because of a switch to zstd compression for the initramfs
[11:30] <laney> but sil2100 got IS to upgrade the necessary stuff for that
[11:30] <laney> let's see what happens with today's?
[11:31] <paride> laney, sure! thanks.
[11:38] <apw> laney, any idea who added libreoffice to the impish:i386-whitelist ?
[11:38] <laney> apw: nope not a clue. isn't that just managed by the script / germinate?
[11:39] <apw> laney, ahh i guess it could have gone again from germinate output of course.
[11:40] <laney> it seems odd that it would be dragged in there
[11:40] <laney> but kinda hard to see in retrospect
[11:40] <laney> does the script want to remove it now?
[11:42] <apw> yeah it would indeed
[11:43] <laney> sounds like a net win for society
[11:44] <apw> laney, https://code.launchpad.net/~apw/ubuntu-archive-tools/i386-whitelist--intuit-nvidia-versions/+merge/404567
[11:44] <apw> laney, seems i forgot to propose this for merge ...
[11:45] <laney> ah yes
[11:46] <laney> apw: that looks good!
[12:11] <doko> apw, laney: I did, to validate with ricotz that it builds on 32bit archs beside armhf
[12:13] <laney> doko: it would be helpful to do that by updating update-i386-whitelist, so others can find out what's going on
[12:13] -queuebot:#ubuntu-release- Packageset: Added nvidia-graphics-drivers-470 to i386-whitelist in impish
[12:43] -queuebot:#ubuntu-release- Packageset: Removed libreoffice from i386-whitelist in impish
[12:43] -queuebot:#ubuntu-release- Packageset: Removed php7.4 from i386-whitelist in impish
[12:43] -queuebot:#ubuntu-release- Packageset: Removed xmlrpc-epi from i386-whitelist in impish
[12:43] -queuebot:#ubuntu-release- Packageset: Added nvidia-graphics-drivers-340 to i386-whitelist in impish
[12:43] -queuebot:#ubuntu-release- Packageset: Added nvidia-graphics-drivers-418-server to i386-whitelist in impish
[12:43] -queuebot:#ubuntu-release- Packageset: Added nvidia-graphics-drivers-435 to i386-whitelist in impish
[12:43] -queuebot:#ubuntu-release- Packageset: Added nvidia-graphics-drivers-tesla-460 to i386-whitelist in impish
[12:49] <paride> laney, so now we have impish-live-server images, but they're all bad :( there's some kind of restart loop after the ISO image kernel loads
[12:49] <paride> My impression is that some piece of subiquity is missing
[12:50] <laney> bah
[12:50] <paride> :)
[12:50] <laney> I'll hand you over to xnox for that one though
[12:50] <laney> (assuming it's zstd fun times)
[12:50] <paride> that's because I mentioned 'kernel'? :)
[12:51] <paride> at least this is easy to reproduce: (1) grab the latest impish-live-server-amd64 image (2) try to install a VM
[13:08] <paride> the livefs build log seems sane
[13:44] <laney> paride: can you file a bug? anything on the console?
[13:45] <paride> laney, the console is in a loop showing the issue text (/etc/issue), with no login prompt
[13:53] <paride> laney, I'll file a bug against ubuntu-cdimage
[14:02] <mdeslaur> jamespage: I'm off for the next week and a half, please let sbeattie or leosilva know when the ceph packages are ready to be published. thanks!
[14:19] <xnox> didrocks:  that .html report is the source of info. The emails are one time thing when it goes from phasing to not-phasing (edge detection). I don't think there is email when it goes back from not-phasing to phasing.
[14:20] <xnox> paride:  i saw mwhudson was fixing starting subiquity on serial consoles......
[14:20] <xnox> laney:  i daubt it is zstd related.
[14:24] <xnox> laney:  i had bugs locally, cause my base snap was not refreshed as well. for good measure do `snap refresh core20` as well, in case that one has any fixes.
[14:24] <xnox> -EWRONGCHAN sigh
[14:31] <paride> laney, xnox, mwhudson https://bugs.launchpad.net/ubuntu-cdimage/+bug/1933352
[14:48] <bdmurray> juliank: I'll approve the shim signed tarballs for xenial
[14:48] <juliank> bdmurray: hooray; thanks
[15:40] -queuebot:#ubuntu-release- Unapproved: linux-base (hirsute-proposed/main) [4.5ubuntu5.2 => 4.5ubuntu5.3] (core, i386-whitelist)
[15:46] -queuebot:#ubuntu-release- Unapproved: linux-base (focal-proposed/main) [4.5ubuntu3.5 => 4.5ubuntu3.6] (core, i386-whitelist)
[16:27] -queuebot:#ubuntu-release- Unapproved: shim-signed (xenial-proposed/main) [1.33.1~16.04.8 => 1.33.1~16.04.9] (core)
[17:45] -queuebot:#ubuntu-release- Unapproved: reprepro (hirsute-proposed/universe) [5.3.0-1.2 => 5.3.0-1.3~ubuntu21.04] (no packageset)
[17:52] -queuebot:#ubuntu-release- Unapproved: reprepro (groovy-proposed/universe) [5.3.0-1.1 => 5.3.0-1.3~ubuntu20.10] (no packageset)
[20:21] -queuebot:#ubuntu-release- Unapproved: reprepro (focal-proposed/universe) [5.3.0-1.1 => 5.3.0-1.3~ubuntu20.04] (no packageset)
[21:11] <mwhudson> can't exec python3
[21:11] <mwhudson> ?
[21:11] <mwhudson> you wot
[21:11] <vorlon> ?
[21:12] <mwhudson> oh the live installer breakage
[21:12] <mwhudson> *server
[21:14] <mwhudson> uhh
[21:14] <mwhudson> so /snap/core18/2074 is empty
[21:15] <mwhudson> yeah core18 is in the seed.yaml but not in the seeds directory
[21:16] <mwhudson> i guess core18 is no longer in the filesystem layer because lxd is core20 now
[21:16] <mwhudson> and the seeding into the installer layer somehow isn't working
[21:16]  * mwhudson launches everything into the sun
[21:17] <mwhudson> yeah if i manually install core18 it starts successfully
[21:29] <laney> mwhudson: you're talking about paride's bug?
[21:39] <mwhudson> laney: yes
[21:40] <mwhudson> laney: should be an easy fix
[21:42] <laney> oh god you said it
[21:46] <vorlon> :)
[22:00] <mwhudson> laney: i'll try to avoid the fix including rewriting livecd-rootfs in rust
[22:38] <mwhudson> here's my proposed fix https://code.launchpad.net/~mwhudson/livecd-rootfs/+git/livecd-rootfs/+merge/404620
[22:38] <mwhudson> building here https://launchpad.net/~mwhudson/+livefs/ubuntu/impish/test/+build/283169
[22:45] <bdmurray> Could an AA reject language-pack-gnome-en from impish-proposed?
[22:45] <bdmurray> It has an lower version number than what's in the release pocket.
[22:47] <bdmurray> vorlon: ^
[22:48] <vorlon> bdmurray: done
[23:44] <mwhudson> ok my livecd-rootfs fix appears to work
[23:52] <mwhudson> merging & uploading


[23:49] <Darael> anon__: It is, yes.
[23:49] <pyrite> Alright... Here is the problem..  Using Ubuntu 10, and a USB Belkin Wireless N adapter.    the router will randomly turn off.. particularly if I am not actively transmitting anything. And when I am, the activity light will stop flashing for anywhere from 5 to 60 sec. sometimes longer.  during which time, I am obviously not transmiting or recieving.  It will typically recover.  But Not always.   any form of streaming media is constantly
[23:49] <pyrite> interupted.. Any ideas?
[23:49] <grkblood> Darael, its a very short file
[23:50] <iPittytheFoo> grkblood, it took me 2 seconds to find this........http://www.bitsoft.net/
[23:51] <grkblood> iPittytheFoo, im in a linux room, not a windows room
[23:51] <ben_q> hey, why is Kate overwriting the file-group on save?
[23:51] <iPittytheFoo> grkblood, excuses
[23:52] <vsilverlord> hi, im downloading software. i want to write a shellscript which shutdowns the pc when the software is ready. how to do?
[23:53] <chris_percol> try shutdown --help,
[23:53] <Darael> grkblood: Then you'll need to dump the individual frames and assemble them into a gif.  Convert won't do avi to gif because despite the blurred boundary it's from a video format to an imago one.
[23:53] <nikre> i bought a new hdd and now my fans are all at full speed. can anyone help?
[23:53] <grkblood> Darael, http://www.imagemagick.org/Usage/video/
[23:53] <grkblood> it says it will
[23:53] <vsilverlord> well how can i link the shutdown command with the software center?
[23:55] <anon__> My 10.10 ubuntu install will only boot correctly in low graphics mode, is this a problem with X? If so, how do I fix it?
[23:55] <Flare183> anon__: Graphics Drivers
[23:55] <anon__> Ah.
[23:55] <Goliath> is there any translation software like magenta for linux?
[23:56] <Goliath> i am interested in greek <=> english translation
[23:56] <chris_percol> vsilverlord: didn't realise you wanted to link them...why not write an apt-get install line in a script followed by shutdown command in same script?
[23:57] <detrate> is anyone familiar with sound issues that cause speakers to crackle? particularly when there in internet activity
[23:57] <detrate> I have verified my soundcard and speakers work on other computers
[23:57] <detrate> and it _used_ to work just fine
[23:57] <detrate> my onboard sound still works
[23:57] <detrate> I'm going to shoot myself in the ear if I continue to hear this crackling
[23:57] <pyrite> o.O
[23:58] <yaaar> hey guys. i'm looking to setup a webserver with some kind of chroot/jail functionality, and some research this morning turned up a whole bunch of different approaches...so now I'm a bit confused. what i'd really like is something similar to freebsd jails: all the user's processes are confined (in particular apache/ssh/ftp must all be properly sequestered), it has its own networking etc., and...
[23:58] <yaaar> ...can't be broken out of. can anybody recommend what i should be looking at? is mod_chroot good enough? vms? xen?
[23:58] <Darael> detrate: Please don't.  It won't stop the crackling and it'll hurt.
[23:58] <grkblood> Darael, ive extracted the avi to images, whats the best way to go about bringing them back together in gif format?
[23:59] <Darael> grkblood: I'm afraid I don't know.  I'm not really an image or video expert.
[23:59] <grkblood> Darael, ffmpeg -i ducking.avi ducking/image%d.jpg


[06:50] <ginggs> teward: i am now
[09:23] <seb128> is https://reports.qa.ubuntu.com/reports/sponsoring/index.html also not working for others? if those do you know who is maintaining the service/where to report?
[09:24] <seb128> bdmurray, ^ iirc you had at least access?
[09:30] <ginggs> seb128: i can confirm it's not working now.  it did work for me about 2 hours ago
[09:35] <seb128> ginggs, thanks
[10:10] <bluca> hi - any chance systemd/ppc64el could be added to https://git.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-package-configs/tree/big_packages ?
[10:10] <bluca> systemd/amd64 is already there, and the ppc64el test run does the exact same things, and often times out
[10:13] <ginggs> bluca: would you submit a MR please?  also -> #ubuntu-release
[10:18] <bluca> can do, what's the repo?
[10:27] <ginggs> bluca: as above?  https://git.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-package-configs/  or do I misunderstand?
[10:34] <bluca> no my bad, thought you meant on Salsa for some reason - https://code.launchpad.net/~bluca/autopkgtest-cloud/+git/autopkgtest-package-configs/+merge/424487
[10:40] <ginggs> bluca: thanks!
[10:43] <bluca> thanks for the review - who can do the merge?
[10:48] <ginggs> anyone in ~ubuntu-release -- i've pinged them
[10:50] <bluca> thanks!
[12:42] <ginggs> seb128: http://reqorts.qa.ubuntu.com/reports/sponsoring/ working again for me now
[12:44] <seb128> ginggs, thanks; it also works here now
[12:44] <enr0n> vorlon: "do we know why these tests are running more slowly on ppc64el than on other archs" > no, I did not investigate any further. I just noticed the tests were very inconsistently hitting timeouts due to the race conditions.
[14:15] <teward> ginggs: can you look at #1814302 and advise waveform on prepping kinetic and jammy patches and not have version collission?
[14:15] <teward> you sponsored it last according to LP
[14:15] <teward> while waveform TIL
[14:16] <teward> also i cant spell apparently. *goes to get coffee*
[14:16] <teward> (merge/sync for Jammy == regression introduction)
[14:18] <waveform> teward, the last rebuild that ginggs sponsored was to do with ... (checks notes) ... oh, the debhelper prerm fun. I think the actual sync from debian was before that but I've no idea what triggered that (given we had a delta for the lxd apparmor bits)
[14:19] <teward> waveform: based on affected releases I would say Jammy introduced the dropped delta which regressed the SRU
[14:20] <teward> but to apply in Kinetic and Jammy you need to avoid the version string collission (same version, two releases)
[14:20] <teward> at least until newer quassel is merged : P
[14:20] <teward> i am on a commute or i would JFDI for uploading :)
[14:20] <waveform> yeah, I figured it'd get sponsored into kinetic, then I could look at SRU'ing to jammy (with something like ~22.04.1 on the end)
[14:23] <waveform> but if it can go into both that's certainly easier
[14:24] <teward> use -Xubuntu<IP_ADDRESS>
[14:24] <teward> *points at sec team docs&
[14:24] <teward> waveform: if you create the jammy debdiff i'll upload both simultaneously
[14:25] <teward> at least... when i'm at my computer
[14:25] <teward> phone is not capable of debsign xD
[14:26] <teward> *adds a note to stab bryceh about nginx merge from Debian*
[15:03] <Eickmeyer> teward: I doubt you'll have to worry about a new quassel for a while, perhaps years. They're slower than turtles crawling through peanut butter at their releases.
[15:03] <teward> :P
[15:03] <teward> Eickmeyer: maybe, but i can expect a -3 in Debian at any time so :P
[15:04] <Eickmeyer> Fair.
[15:04] <Eickmeyer> Seeded in Studio, FWIW.
[15:05] <santa_> good afternnon
[15:06] <santa_> ddstreet: hello there, I'm having a problem which might be in systemd and I'm collecting info to try to report a bug, if you have some mins I would appreciate your advice, details below
[15:07] <santa_> - I have some servers to [re]build kubuntu packages
[15:07] <santa_> - in these servers I have LXD containers
[15:08] <santa_> - in the containers meant to build the package I also do an autopkgtest run
[15:08] <santa_> - I'm using autopkgtest with the LXD backend, therefore I'm using nested containers
[15:09] <santa_> - when autopkgtest starts it executes something like this to verify the container actually started:
[15:09] <santa_> lxc exec <container_name> runlevel
[15:10] <santa_> the thing is, since some time ago, "runlevel" no longer works in nested cointainers
[15:10] <santa_> so I have been researching the problem and I found out a couple of interesting systemd services:
[15:10] <teward> waveform: uploaded to Kinetic and jammy-proposed
[15:11] <santa_> systemd-update-utmp.service and systemd-update-utmp-runlevel.service
[15:11] <santa_> the first one works fine, the second doesn't
[15:12] <santa_> the second service is suposed to execute "/lib/systemd/systemd-update-utmp runlevel"
[15:13] <santa_> if I execute that manually in a nested container I get this line of output "Failed to get new runlevel, utmp update skipped."
[15:13] <waveform> teward, thanks
[15:14] <santa_> I have been looking into systemd's upstream git, but I couldn't find anything interesting so far
[15:14] <santa_> any advice to continue the research? I'm a bit stuck with this atm
[15:16] <santa_> oh I forgot to mention
[15:17] <santa_> executing "runlevel" in a nested container is always returning "unknown" (and thats what is making my autopkgtest executions fail)
[15:18] <ddstreet> santa_ in the top-level container, are you using 'security.nesting=true'? if not, it's worth giving that a try first
[15:19] <santa_> ddstreet: yes of course, also in case you are wondering this happens both with privileged and non-privileged containers
[15:20] <ddstreet> hmm, and is the 'runlevel' call failing for older releases too or just jammy/kinetic?
[15:21] <santa_> in my server I have 20.04
[15:21] <santa_> in the building containers I have 18.04
[15:21] <santa_> the nested containers have kinetic
[15:22] <santa_> however, I tried other versions
[15:22] <santa_> for example this happens with 20.04 top-level container + 20.04 nested container
[15:23] <santa_> also 20.04 top-level + kinetic nested container
[15:24] <santa_> ... and others (I don't remeber all combinations I tried but I couldn't get the runlevel thing working yet)
[15:24] <ddstreet> i think you'll likely need to enable systemd debug in the nested container to get more detail about why 'runlevel' is failing
[15:24] <ddstreet> maybe you can manually start the nested container and manually check 'runlevel'
[15:26] <santa_> yes, that's what I'm doing, it's always returning "unknown"
[15:27] <santa_> I mean in addition to the building infra I have I have been creating other containers manually to experiment
[15:27] <ddstreet> what does 'systemctl is-system-running' report?
[15:31] <santa_> ddstreet: "starting" on nested container
[15:31] <ddstreet> yeah that's the problem
[15:31] <santa_> I think it should say "running" at this point
[15:32] <ddstreet> the 'runlevel' program connects to pid1 over dbus, and asks for the state of specific units, namely 'graphical.target', 'multi-user.target', and 'rescue.target'
[15:32] <ddstreet> if any of those are 'active' (or 'reloading'), it uses that 'runlevel' (respectively, 5, 3, 1)
[15:33] <ddstreet> if none of those are active/reloading, it falls into the error you're seeing
[15:33] <ddstreet> and if the system is still 'starting' none of those will be active yet
[15:33] <ddstreet> and really, that makes sense, if the system is still starting it isn't in any 'runlevel'
[15:35] <ddstreet> is autopkgtest the code calling 'runlevel' in the container? if so, it should be waiting for the container to start, like with 'systemctl --wait is-system-running' or similar
[15:35] <santa_> ack
[15:35] <santa_> yes, let me find the code...
[15:36] <santa_> https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/virt/autopkgtest-virt-lxd#L101
[15:37] <santa_> perhaps it's about time that autopktest switches to 'systemctl --wait is-system-running'?
[15:38] <ddstreet> well they have a loop there, which is fine (i guess 'runlevel' is ok to use if you don't know if the container is running systemd...?)
[15:38] <ddstreet> i think they need to increase that timeout though, the default system timeout for units is 90 seconds
[15:39] <ddstreet> so any unit that delays the bootup will almost certainly go past that 60 second timeout
[15:39] <santa_> yeah, I have a customized autopkgttest increasing some timeouts
[15:39] <ddstreet> in the container you could check what service is delaying bootup, networking is a frequent offender (i.e. systemd-networkd-wait-online) but it could be something else
[15:40] <santa_> ah, I have 3 failed units, I could have a look into that
[15:41] <ddstreet> yep, probably one or more of those delaying boot
[15:41] <santa_> also, if you look at line 109 of the code I linked above, that seems to contain legacy code in case you are not using systemd
[15:42] <santa_> so I guess the idea of executing runlevel was to support old systems without systemd
[15:42] <ddstreet> yep, seems reasonable since Debian does allow not using systemd
[15:43] <ddstreet> main thing that probably needs changing there is to increase the timeout from 60 to 120 or so
[15:43] <ddstreet> unless the intention is to detect failed boot-time units, of course
[15:46] <santa_> ddstreet: funny coincidence I have 120 in mine + other fix: https://git.launchpad.net/~tritemio-maintainers/tritemio/+git/autopkgtest/commit/?id=976c322fca13a69a366c7dc60f1fe423702ff7ba
[15:47] <santa_> maybe I should send part of that patch to the autopkgtest guys
[15:53] <santa_> ok, so going back to systemd in nested containers, it seems there is a problem with apparmor
[15:54] <santa_> so I have 3 failed services:
[15:54] <santa_> - apparmor.service
[15:54] <santa_> - networkd-dispatcher.service
[15:54] <santa_> - snapd.apparmor.service
[16:16] <santa_> ok I have been playing around with a kinetic container nested in another kinetic container:
[16:16] <santa_> - I had the 3 services mentioned above failing
[16:17] <santa_> - I have removed the "apparmor" and "networkd-dispatcher", after that no more services failing
[16:18] <santa_> - however the nested cointainer is still in the same weird state
[16:20] <ddstreet> santa_ i started up a nested kinetic, and it looks like dbus isn't running, or is having major problems
[16:20] <santa_> weird state = runlevel reporting 'unknown', 'systemctl is-system-running' says 'starting'
[16:21] <santa_> ddstreet: ah, I remember some packages being updated and complaining about dbus or something
[16:21] <ddstreet> yeah while 'starting' runlevel will always return 'unknown'
[16:22] <santa_> also the multi-user, graphical or emergency targets were not reached apparently
[16:23] <ddstreet> yep, i am pretty sure the nested lxd containers is causing some issue(s)
[16:23] <ddstreet> i don't think it's necessarily systemd that's broken
[16:24] <santa_> yeah, I share that opinion
[16:24] <santa_> * I agrre
[16:24] <santa_> * I agree
[16:24] <santa_> also I have "Unexpected error response from GetNameOwner(): Connection terminated" from various systemd services
[16:24] <ddstreet> yep me too
[16:27] <ddstreet> slyon have you looked into problems with nested lxd containers with kinetic? ^
[17:18] <santa_> ok, I have found a workaround
[17:18] <santa_> https://bugs.launchpad.net/cloud-init/+bug/1905493
[17:19] <santa_> ddstreet: this thing you mention here: https://bugs.launchpad.net/cloud-init/+bug/1905493/comments/2 fixes 'runlevel' for me
[17:22] <santa_> + removing "apparmor" package
[17:52] <ddstreet> santa_ ah wow that bug still isnt fixed! wonder if server team might want to review it, cpaelzer_  ^
[17:53] <santa_> ddstreet: probably it was fixed, then at some point regressed
[17:53] <santa_> I mean I have been taking some time for personal reasons, but a few months ago my test rebuilds were working
[17:59] <enr0n> bdmurray: Any idea why this systemd-fsckd test would be marked FAIL in a PPA autopkgtest, despite returning 77 and having 'skippable' in the test restrictions<EMAIL_ADDRESS>[17:59] <enr0n> I ran it locally in qemu, and the test was skipped as expected
[18:00] <ddstreet> enr0n did it output anything to stderr and not have allow-stderr?
[18:01] <enr0n> ddstreet: AFAICT, no. It just makes a print() call stating "SKIP: root file system is being checked by initramfs already
[18:02] <enr0n> So that's stdout
[18:03] <bdmurray> enr0n: Out of curiuosity what does the systemd-fsckd test output look like when you run it locally?
[18:03] <bdmurray> enr0n: Also what version of autopkgtest are you using when you run it locally?
[18:04] <enr0n> bdmurray: Here is the local output: https://paste.ubuntu.com/p/nK88K8nxfQ/
[18:05] <enr0n> bdmurray: And I have autopkgtest 5.20 installed on jammy
[18:06] <ginggs> enr0n: that test ran with systemd 251-2ubuntu1~ppa3
[18:06] <ginggs> but your PPA now has 251.2-2ubuntu1~ppa1
[18:07] <bdmurray> It's also worth mentioning that the autopkgtest deb is not the same autopkgtest code being used in the infrastructure
[18:10] <enr0n> ginggs: ah, weird. Yeah it looks like the testbed for my 251.2-2ubuntu1~ppa1 test died on amd64. Thanks for catching that.
[18:12] <bdmurray> enr0n: Alright are you set then?
[18:13] <ddstreet> enr0n as ginggs mentioned that test was with ~ppa3 and pull-ppa-source for that version shows it doesn't include 'skippable'
[18:17] <enr0n> bdmurray: Yeah I think so. However, my PPA test for amd64 with trigger systemd/251.2-2ubuntu1~ppa1 shows a kernel panic, but is still listed on https://autopkgtest.ubuntu.com/running.
[18:18] <enr0n> I don't know how that page works exactly, but maybe that test needs to be killed manually or something?
[18:19] <enr0n> ddstreet: yeah, thank you. I see that now. I got confused by the timing of my test results. The tests I had triggered last week are still running I guess.
[18:24] <bdmurray> enr0n: I'll kill that test run
[18:24] <enr0n> bdmurray: thanks!
[19:00] <rbasak> !dmb-ping
[19:01] <teward> *spawns in, but requires rbasak to pay for the coffee this time*
[19:03]  * genii 's ears perk up for a moment at the mention of coffee
[19:04]  * arraybolt3[m] activates coffee teleporter and accidentally explodes cup everywhere
[19:45] <enr0n> bdmurray: I think something funky is happening with the rest of my PPA autopkgtests listed on https://autopkgtest.ubuntu.com/running#pkg-systemd. They have each been showing various "Running for" durations the last couple days (i.e. the durations don't appear to be strictly increasing).
[20:01] <bdmurray> enr0n: looking
[20:07] <bdmurray> enr0n: the arm64 one is still running, I killed the amd64 one again
[20:09] <bdmurray> enr0n: the s390x test is also running
[20:10] <bdmurray> enr0n: so is the ppc64el one.
[20:11] <bdmurray> enr0n: Or are you concerned that the tests should have finished by now but keep running for some reason?
[20:11] <enr0n> bdmurray: Yes, the latter. They have been "running" since at least Friday I believe.
[20:17] <bdmurray> enr0n: When you run it locally how long would it take for all the tests to finish?
[20:20] <enr0n> bdmurray: Hm, 30 minutes or so? If I do run it locally, I usually turn my attention to something else for a while.
[22:42] <bdmurray> enr0n: the amd64 test of systemd should stop running now
[23:18] <enr0n> bdmurray: thanks, I have the full logs for that now


[20:03] <mcphail> If I unpublish a click package in the store, will it remove it from users' devices? I want to end support without annoying people who already have it installed
[21:24] <popey> mcphail: no
[21:24] <popey> mcphail: we don't provide a faciliy to reach into people's devices and remove things


[00:09] <jimbaker`> seems to me that it would be nice if we had verbosity levels for --verbose, especially an easy way to screen out ZK logging which is seldom useful
[14:46] <lamalex> hi, im trying to figure out how to deploy wordpress, where are the docs for all of the initial set up? i see lots of stuff about ec2 but i dont have any ec instances i just want to hack locally on some stuff
[14:47] <drt24> lamalex: you might try http://blog.dustinkirkland.com/2011/08/formal-introduction-to-ubuntu-orchestra.html
[14:47] <drt24> which has been sitting in my to read pile for a couple of weeks now
[14:49] <lamalex> that doesn't really seem helpful at all actually haha. it's just an introduction to the idea of orchestra
[14:49] <lamalex> how how to use juju
[15:23] <lamalex> so i managed to deploy a wordpress and mysql charm
[15:23] <lamalex> and added a relation between them
[15:24] <lamalex> but nothing is starte
[15:24] <lamalex> mysql isn't running
[15:34] <lamalex> .... because it didnt install anything
[15:34] <lamalex> am i missing something? like a core point of what juju does?
[16:41] <niemeyer> lamalex: Hmm..
[16:42] <niemeyer> lamalex: I can try to help you.. it's been an hour, so have you evolved anyhow?
[16:42] <lamalex> niemeyer, i gave up, installed cherokee and just used their webstore, i dont really care anymore i just want to get my work done
[16:42] <niemeyer> lamalex: Sounds good, sorry it's been more painful than it should have been
[16:44] <niemeyer> lamalex: Hadn't heard of cherokee before.. it looks very neat
[16:45] <lamalex> yah it's also a great webserver
[23:34] <jcastro> SpamapS: around?
[23:36] <jcastro> EvilBill: ok we'll try here
[23:36] <EvilBill> yo.
[23:36] <jcastro> and if I totally fail you we can mail the mailing list
[23:36] <EvilBill> lol
[23:36] <EvilBill> Dude, I have a long time to figure this out
[23:36] <EvilBill> I'm just mucking around
[23:36] <jcastro> since I think you're the first victim outside of clint who is trying this
[23:36] <EvilBill> Juju makes a lot of sense to try at the new gig
[23:36] <EvilBill> cause they want a private cloud, and a public cloud
[23:37] <EvilBill> I'm looking for one set of tools to bind them all, y'know?
[23:39] <jcastro> yeah
[23:39] <jcastro> it's just you picked the time when we don't really have docs for OpenStack/Ubuntu/Juju
[23:39] <jcastro> though, it'll just force us to fix it
[23:39] <EvilBill> Picked the time, lol
[23:40] <EvilBill> I'm just trying to hit the ground running at the new gig
[23:40] <jcastro> "Well, I was just fine until you told me to use this, and you don't even have docs."
[23:40] <EvilBill> pretty much
[23:40] <jcastro> It's ok, we'll sort you eventually
[23:40] <EvilBill> but this isn't the first time I've been in this boat with something you've been all OMG THIS IS SO SHINY ABOUT
[23:40] <jcastro> what's the state of the instance now?
[23:41] <jcastro> hey man, early bird gets the worm
[23:41] <EvilBill> 2011-11-12 15:40:57,610 INFO Waiting for unit to come up.
[23:41] <jcastro> he just has to do all the digging on his own
[23:41] <EvilBill> it's seriously never going to come up.
[23:41] <EvilBill> unit mysql/0 says its deploying on machine 1
[23:41] <EvilBill> but there is no machine 1
[23:41] <EvilBill> there never will be machine 1
[23:41] <EvilBill> unless I drag another laptop out and provision it.
[23:41] <EvilBill> and I'm out of space on my desk lol
[23:44] <jcastro> put your notes on pastebin somewhere
[23:44] <jcastro> like, what you did
[23:44] <EvilBill> ugh.
[23:44] <EvilBill> ok
[23:44] <EvilBill> only reason I ugh, is I was constantly interrupted
[23:44] <EvilBill> so I may have missed a step of documenting, but we'll run with it.
[23:45] <jcastro> that's ok
[23:45] <jcastro> it's better than nothing
[23:47] <EvilBill> working on that now, cleaning up some nonsense
[23:48]  * jcastro nods
[23:58] <EvilBill> OK man
[23:58] <EvilBill> http://pastebin.ubuntu.com/736784/
[23:58] <EvilBill> sorry, had my son bug me in the middle of that.


[00:36] <ausimage> I have a question regarding use of logos from the various main distributions...
[00:37] <ausimage> I have created a pamphlet... http://www.ausimage.us/pamp1.pdf
[00:38] <ausimage> I thought since you deal with the logos in your marketing you would know the most about where I stand with using them in the pamphlet...
[00:52] <ausimage> oh well give me ping if you can help me out TIA
[07:26] <elky> ausimage, i think you're supposed to talk to<EMAIL_ADDRESS>[16:21] <berduchwal> Hi people
[16:22] <berduchwal> please take a look at http://www.berduchwal.pl/Ja/ubuntu_cufflinks.html and let me know what you think
[17:16] <juliux> hi beuno
[18:14] <beuno> juliux, hey
[18:24] <Icebuntu> hey hi


[00:00] <elmo> how do I link a bug to an upstream one?
[00:01] <wgrant> elmo: "Also affects project"
[00:01] <wgrant> Find the project, and paste the bug URL into the appropriate box.
[00:01] <wgrant> And hope it works.
[00:02] <wgrant> Which it does in a lot of cases now, particularly since it started automatically creating bugtrackers.
[00:02] <elmo> I don't need this upstream link molarkey for the distro source package?
[00:02] <wgrant> You don't need it, but it helps.
[00:02] <wgrant> It sets the default for when you click "Also affects project"
[00:03] <wgrant> Compare https://bugs.edge.launchpad.net/ubuntu/+source/soundconverter/+bug/260853/+choose-affected-product and https://bugs.edge.launchpad.net/ubuntu/+source/convertall/+bug/224049/+choose-affected-product
[00:04] <wgrant> Hmm, a product reference in the UI.
[00:05] <elmo> "<structured-string 'Invalid series given.'>"
[00:05] <elmo> \o/
[00:06] <elmo> what a sweet pop up
[00:06] <wgrant> Hah.
[00:06] <wgrant> I keep away from those pages in general.
[00:06] <wgrant> As they're rather unmaintained.
[00:10] <wgrant> Would one file bugs against -foundations or soyuz for those pages?
[00:12] <elmo> not soyuz, I don't think
[00:26] <_Zeus_> am i the only one annoyed by that long thing at the right on launchpad?
[00:26] <_Zeus_> the thing that makes the page so much longer
[00:28] <wgrant> On which page?
[00:28] <wgrant> The only horrifyingly long one is the Ubuntu tag list.
[00:30] <wgrant> (that I know of, that is)
[00:31] <wgrant> And I know most parts of LP pretty well.
[00:36] <_Zeus_> yeah, that one
[00:46]  * NCommander wonders whats in the PPA admin menu
[00:49] <wgrant> NCommander: Hm?
[00:49] <NCommander> wgrant, https://edge.launchpad.net/~xubuntu-dev/+archive/+admin
[00:49] <NCommander> Or equivelent PPA admin URL
[00:50] <wgrant> Making it private, probably.
[00:50] <NCommander> I wonder if there is any other magic in that menu :-P
[00:50] <NCommander> Like a switch to enable it to use real vs. virtual builders
[00:51] <NCommander> wgrant, do any projects have private PPAs AFAIK?
[00:51] <wgrant> IIRC that's implicit in being a P3A.
[00:51] <NCommander> P3A?
[00:52] <wgrant> PPPA. Private PPA.
[00:53] <NCommander> Suspose the next question is how do you get a PPPA :-)
[00:53]  * NCommander runs
[00:55]  * NCommander also wonders how wgrant knows so much about launchpad's internals
[00:55] <wgrant> As do I.
[00:56] <NCommander> PPPA or your knowledge of the internals of LP?
[00:56] <wgrant> The latter.
[00:56] <NCommander> I think your really kiko, and the wgrant aspect is just a split personality
[00:56]  * NCommander runs
[00:56] <elmo> Private PPAs are still in development, but they're going to be used for security
[00:56] <elmo> as one example
[00:56] <NCommander> Very handy
[00:57]  * NCommander figured the security usage
[00:57] <wgrant> Would it be wrong to file two duplicates of bug #2088 in order to bring the list on https://edge.launchpad.net/launchpad-foundations/+filebug into order?
[00:57] <wgrant> Er, hm.
[00:58] <wgrant> It seems indecisive.
[00:59] <NCommander> wgrant, er, what?
[01:00] <wgrant> Ah, wrong tab.
[01:00] <wgrant> Just noting that the list on one of the Launchpadish projectish was slightly out of order.
[01:00] <wgrant> But not that one.
[01:00] <wgrant> I have too many tabs open.
[01:02] <NCommander> elmo, is it possible to have a PPA work on normal builders vs. the virtual ones? (I ask only because for some PPAs like xubuntu-dev, it would be nice to see powerpc binaries for those of us who use that architecture ;-))
[01:02] <wgrant> NCommander: Port Xen to PowerPC!
[01:03] <NCommander> wgrant, http://wiki.xensource.com/xenwiki/XenPPC/Build
[01:03] <NCommander> already don e
[01:04] <wgrant> Damn. m68k, then.
[01:04] <NCommander> So first you want me to port Ubuntu to m68k?
[01:04] <NCommander> k
[01:05] <elmo> NCommander: not being funny, but didn't we have this discussion already?
[01:05] <NCommander> No, that discussion was using qemu
[01:05] <elmo> NCommander: because PPAs can install their own packages as build dependencies, it's a firm requirement that they use a strong virtual sandboxed enviroment
[01:06] <NCommander> Right, I know that, for general usage
[01:07] <NCommander> I was just noting that I actually use Xubuntu (server install, then xubuntu-desktop) on my PPC, and its kinda anonying I can't use the beta packages right out of the box on it
[01:09] <elmo> (btw, Xen/PowerPC has hardware requirements that we don't meet)
[01:09] <NCommander> ah
[01:09] <NCommander> THat explains that and ends that discussion ;-)
[01:10] <NCommander> Man, I'd thought that PPC was totally dead, but there are 2962 active Ubuntu PPC machines
[01:10] <elmo> NCommander: sure, I appreciate it's unideal, and I'd love to be able to support !x86 arches for PPA someday, but honestly, I don't know when anyone's going to get the time to explore alternatives
[01:10] <NCommander> elmo, I'll probably look into it once LP is open
[01:11]  * NCommander finds it amusing he has or has access to every Ubuntu port
[01:16]  * wgrant cries.
[01:16]  * _Zeus_ backs off...
[01:16] <wgrant> I'm trying to file bugs on the DSSP<->Product linkage pages.
[01:16] <wgrant> But I keep finding more.
[01:16] <wgrant> Not more bugs, more pages.
[01:18] <wgrant> I think all 6 that I've found so far can have a bug reported on pretty much every element.
[01:21] <wgrant> So far I've found <DSSP>/+edit-packaging, <DSSP>/+packaging, <Product>/+packages, <Product>/+distributions, <ProductSeries>/+ubuntupkg, <ProductSeries>/+addpackage
[01:21] <wgrant> So there are three instances of each of the two types of pages.
[01:22] <wgrant> A couple of the pages expose information about the links that isn't visible on any of the other five, nor the SP page.
[01:26] <NCommander> DSSP?
[01:26] <wgrant> DistroSeriesSourcePackage
[01:28] <NCommander> are you sure on addpackage
[01:28] <NCommander> I don't get a Permission Denied on that one
[01:29] <wgrant> Right, the permissions differ for ubuntupkg and addpackage.
[01:29] <wgrant> For no good reason that I can see.
[01:29] <NCommander> What's ubuntupkg?
[01:29] <NCommander> (no, I get Lost Something page, not permission denied)
[01:29] <wgrant> ProductSeries/+addpackage, not Product.
[01:30] <NCommander> still getting lost something
[01:30] <NCommander> https://edge.launchpad.net/ubuntu/hardy/+addpackage
[01:31] <NCommander> how badly do I fail ;-)
[01:31] <wgrant> That's a distroseries.
[01:32] <NCommander> oh
[01:32] <NCommander> so then whats a ProductSeries vs. a DistroSeries
[01:33] <wgrant> Product is the old name for project. Still used internally and in places they've forgotten it in the UI.
[01:34] <wgrant> So a project series.
[01:34] <NCommander> Oh I see
[01:34] <NCommander> BTW, wgrant, they fixed having Releases for distributions
[01:34] <NCommander> https://edge.launchpad.net/nexenta/hardy - i.e.
[01:35]  * NCommander wishes it was possible to run a publisher instance for Nexenta, but meh :-P
[01:37] <wgrant> Yep, I noticed that.
[01:40] <NCommander> I do hope LP gets the ability to seperate publisher from Soyuz so it would be possible for us to use LP's archive tools without having to run a seperate LP instance
[01:40] <NCommander> (once LP is open)
[01:40] <wgrant> Publisher is part of Soyuz...
[01:42] <NCommander> right
[01:42] <NCommander> Essentially, what I'm saying is having all archive functions controlled via launchpad.net, but hosting our own infrastructure
[01:42] <NCommander> I'm told to do that, publisher would require work to seperate it from Soyuz, or Storm would require modification to work across the internet
[01:43] <NCommander> ^securely
[02:54] <NCommander> barry, hola
[02:54] <NCommander> (and beuno-afk ping)
[05:40] <markh> I've pushed a branch to launchpad under my username (ie, lp:~mhammond/...) when I really want it under one of the groups - can I move it?
[05:41] <wgrant> markh: Sure, click on the edit button next to the branch's title.
[05:44] <markh> wgrant: ahh, I see now - thanks
[05:51] <nijaba> hello. I'm getting a trying to get to http://bazaar.launchpad.net/~ubuntu-virt/vmbuilder/trunk/revision/198 and get a "please try again error", normal?
[05:55] <markh> nijaba: me too on a different branch
[05:55] <nijaba> markh: ok, I feel better now . I know that I am not alone ;)
[05:56] <RAOF> Works for me, now.
[05:57] <markh> still not for me
[06:07] <jml> are there any OOPS codes?
[06:09] <wgrant> Loggerhead doesn't OOPS, does it?
[06:10] <markh> working now!
[06:10] <wgrant> jml: Can you please explain why I got the error that caused me to file bug #272304?
[06:12] <jml> wgrant: nope, sorry, there's not enough info there. what were you doing? with which branch? time would also be good in case we have to check the logs.
[06:13] <wgrant> jml: It's still there now: https://code.edge.launchpad.net/~wgrant/ubuntu-cve-tracker/mainold
[06:18] <jml> wgrant: ok. that means that the branch timed out when being mirrored to the public area.
[06:18] <wgrant> jml: Ahh. Thanks.
[06:18] <jml> wgrant: why it timed out is another interesting question.
[06:18] <wgrant> It is an old knit branch.
[06:18] <wgrant> With an awful lot of files.
[06:19] <jml> well, the size per se doesn't matter
[06:19] <jml> it's more a question of how granular bzr's progress reporting is.
[06:19] <wgrant> Ah.
[06:19] <wgrant> I find it awful for knits.
[06:20] <jml> then, that's quite possibly the problem.
[06:20]  * wgrant might try his luck recreating that as a stacked branch.
[06:20] <jml> you can trigger a re-mirror using launchpadlib (but I don't have the right incantation handy), or by doing a trivial write to the branch.
[06:21] <wgrant> I need to upgrade it, and an upgrade will take forever. I'll just recreate it.
[06:21] <wgrant> (particularly as I think it's all merged)
[06:21] <jml> well, upgrading your local copy and pushing won't be so bad
[06:21] <jml> oh, if it's merged... :)
[06:21]  * jml -> risotto
[06:21] <wgrant> Mmm, risotto.
[06:22] <wgrant> It's an ongoing branch, but I think it's all in master now.
[06:22] <wgrant> Thanks for the help.
[06:24] <wgrant> Hrmph.
[06:24] <wgrant> It dereferenced my lp: URL. Not very nice of it.
[06:24] <wgrant> Created new stacked branch referring to<EMAIL_ADDRESS>[06:39] <wgrant> And a pretty AssertionError because of that. Yay.
[06:44] <jml> wgrant: is the assertion error on Launchpad or Bazaar?
[06:45] <wgrant> jml: LP. Complaining that my hosted branch references a non-hosted branch. It dereferenced lp:ubuntu-cve-tracker, which I passed as --stacked-on.
[06:46] <wgrant> I'm using the real HTTP URL for now, so it should be happier.
[06:47] <jml> same branch as before?
[06:47] <wgrant> lp:~wgrant/ubuntu-cve-tracker/main
[06:48] <wgrant> (the one I pointed you to earlier had been main, but I renamed it because it was sooooo slooooow and needed to die)
[06:48] <jml> *nod*
[06:48] <wgrant> Is it a bug that it dereferences the lp: URL?
[06:48] <jml> no.
[06:48] <jml> well...
[06:49] <jml> no.
[06:50] <wgrant> How is one meant to do it, then?
[06:51] <jml> you'd have to stack on the http url. It's possible that bzr makes it harder than it could be.
[06:52] <wgrant> But I don't know that the HTTP URL exists.  Bulletproof, I guess.
[07:02] <mwhudson> b = bzrlib.branch.Branch.open('bzr+ssh://bazaar.launchpad.net/~wgrant/ubuntu-cve-tracker/main')
[07:02] <mwhudson> b.set_stacked_on_url('/~ubuntu-security/ubuntu-cve-tracker/master')
[07:03] <mwhudson> might work
[07:04] <jml> o/` or just another country o/`
[07:05] <wgrant> mwhudson: Thanks. I'll try that.
[07:05]  * wgrant looks confused at jml.
[07:05] <mwhudson> (this is what the automagic stacking thing will do for you)
[07:06] <wgrant> Does that not work yet?
[07:08] <mwhudson> wgrant: a phased rollout seemed sensible, in case of horrific bugs
[07:09] <wgrant> mwhudson: Indeed, but having something that can't be used isn't an excellent method of testing.
[07:09] <mwhudson> wgrant: _we_ can use it
[07:09] <wgrant> It seems to be complaining less now, but I might not have waited long enough...
[07:09] <wgrant> mwhudson: Ah, right.
[07:09] <wgrant> Yay, it worked. Thanks mwhudson, jml.
[07:09] <mwhudson> np
[08:17] <Hew> Hi. I'm trying to update the bug status/milestone/comment of a bug, but I get this error: "Application error.  Unauthenticated user POSTing to page that requires authentication.". I've tried pressing back and trying again, but it refuses to let me comment. I'm using edge.
[08:19] <wgrant> Hew: Try logging in. You may have been logged out by viewing a Launchpad feed.
[08:21] <Hew> wgrant: Thanks, I had indeed been logged out for some reason.
[08:22] <wgrant> Viewing feeds seems to destroy your session at the moment; I believe it's being worked on.
[08:25] <Hew> wgrant: No worries, these things have to be expected when on launchpad-beta. What is a "feed" though?
[08:25] <wgrant> Hew: An RSS or Atom (I forget which) feed. Does that make more sense?
[08:27] <Hew> wgrant: Yes, even though I don't view feeds (unless firefox is pulling it down in the background or something).
[08:30] <mwhudson> the fix for this has landed, btw
[08:30] <mwhudson> so it should be fixed on edge pretty soon
[08:31] <Hew> mwhudson: Sounds good :-)
[08:32] <mwhudson> hm, should be fixed on edge already, actually
[12:50] <attila_lendvai> hi! so, launchpad is for opensource software... but what if i wanted to buy it as a service for a company? is there a chance i could get a cheap rent for a low-traffic service?
[13:10] <Hobbsee> attila_lendvai: ask mrevell about that, during a european workday.
[13:12] <attila_lendvai> Hobbsee: thanks!
[13:12] <Hobbsee> attila_lendvai: you're welcome!
[17:40] <yarko> are there any known issues currently w/ Launchpad source view?
[17:41] <yarko> (I'm getting repeated "Problem connecting to the Launchpad server.... )
[17:41] <yarko> ...this is for better than the last 1/2 hour.
[17:43] <yarko> I just checked and am getting this on more than one project...
[17:44] <yarko> I believe there's a problem w/ the source server...
[17:51] <yarko> Is anyone else experiencing server problems w/ Launchpad?
[17:51] <_steven_> I get an error when browsing source online
[17:51] <yarko> I just merged from one tree, and wound up with NO FILES (everything deleted)
[17:51] <yarko> I tried browsing, and got an error also
[17:52] <yarko> I tried browsing in another project - same thing, an online error
[18:36] <insomninja> I seem to have problems to connect to the lp server and was told to drop a notification here
[18:57] <tgm4883_laptop> How long is it before bugs that were marked for expiration actually expire?
[19:10] <persia> tgm4883_laptop: At least for Ubuntu, they don't actually expire.  This was turned off as it annoyed too many people.
[19:10] <tgm4883_laptop> ah
[19:11] <tgm4883_laptop> which is interesting, since we have a lot of incomplete bugs that aren't expiring, which is annoying me ;)
[19:11] <tgm4883_laptop> is there another way to get rid of them?
[19:24] <laga> hello. i accidentally dput something to regular ubuntu instead of to my PPA. of course, the upload was rejected. now i can't upload to the PPA because it claims the source is already in ubuntu/intrepid. but it's not, it was rejected.
[19:32] <NCommander> barry, ping
[20:12] <NCommander> Are there any dogfood administrators online?
[20:55] <ketilwaa> I can not connect to Bazaar on LP via browser at the moment. Known problem?
[21:23] <rsc_> hey guys. is it possible to get the HEAD revision of my project's trunk downloadable as a .tar.gz?
[21:23] <rsc_> or, how do i put something in my new project's "downlaods" section?
[21:57] <spm> ketilwaa: should be working now
[22:02] <ketilwaa> spm: Thanks, I just noticed.
[22:05] <exarkun> https://answers.launchpad.net/launchpad/+faq/49 says to choose "Delete branch" in the actions menu
[22:05] <exarkun> I can't recognize anything that might be an actions menu on https://code.launchpad.net/~exarkun/pyopenssl/thread-safety
[22:06] <exarkun> How can I delete that branch?
[22:19] <tgm4883_laptop> exarkun, to the right of ~exarkun/pyopenssl/thread-safety, isn't there a pink dot with a - on it?
[22:21] <exarkun> tgm4883_laptop: Indeed there is.
[22:21] <exarkun> And hovering it, I see the title is "Delete branch", so I suppose that's it :)
[22:21] <tgm4883_laptop> that should be the delete button
[22:21] <tgm4883_laptop> yep, I had trouble finding it when lp changed looks too
[22:22] <exarkun> I'm sure this isn't the ideal forum for usability feedback, but man, that's obscure :)
[22:22] <tgm4883_laptop> yea could be
[22:22]  * tgm4883_laptop is just a lp user
[22:29] <mterry> I have a project that uses translations in LP.  Is there an easy way to get update po files than the 'request a download' button?  Like, is there an rsync line I can run?


[05:52] <froud> African greetings
[06:04] <froud> trickie,
[06:04] <froud> ?
[06:04] <froud> you in Melbourne?
[06:05] <trickie> yes i am
[06:05] <trickie> u?
[06:05] <froud> the same nick loeve from the ASTC?
[06:05] <trickie> ASTC?
[06:05] <froud> South Africa
[06:05] <froud> You a tech writer?
[06:06] <trickie> but yes i reckon i am the only nick loeve in melbourne :)
[06:06] <trickie> yeah... sometimes.... ha ha ha
[06:06] <trickie> whats ASTC
[06:06] <trickie> ?
[06:06] <froud> Australian Society for Technical Comunications (VIC Chapter)
[06:07] <froud> I met a NIck Loeve while I was in AU about a year ago
[06:07] <trickie> Wow... never heard of it... but i think i am the only nick loeve in australia... never met another with my last name
[06:07] <froud> Also on Bigpond net (Cable Broadband)
[06:08] <trickie> i am on bigpond here at work
[06:08] <froud> perhaps he was nick love
[06:08] <trickie> but i have another provider at home
[06:08] <froud> nah then its not the same person
[06:08] <trickie> ok
[06:08] <froud> welcome anyway
[06:08] <trickie> thanks
[06:08] <trickie> :)
[06:09] <froud> well must go drop a freind at the airport, b c'ing ya
[06:09] <trickie> cool
[01:48] <abelli> ciao
[01:55] <Kinnison> ciao abelli, come va?
[01:57] <abelli> bene grazie
[03:39] <sid77> hi