[00:00] <infinity> :(
[00:03] <sidi> Currently splitting a pretty insane package into multiarch. I'm separating my existing pkg into a bin package, a common package and a lib-0 / lib-dev multiarch package. the source package has scripts under /usr/lib/foobar.sh, and the binaries of that package hardcode a path to that lib
[00:04] <sidi> yes I could spend the entire night writing new patches instead of sleeping, but if this is going to my -common package (it's scripts after all), how can I write my rules to ensure that only the Multi-Arch: same packages have a /
[00:04] <sidi> have a usr/lib/ARCH/... libdir, and that the common package (with Multi-Arch: any) uses the usual usr/lib/...
[00:05] <sidi> or in other words, is /$(DEB_HOST_MULTIARCH) defined when Multi-Arch: is set to any? in that case my current LIBDIR := usr/lib/$(DEB_HOST_MULTIARCH) line in rules should do what I need, right?
[00:05] <infinity> DEB_HOST_MULTIARCH is always set.
[00:06] <infinity> But installing foobar.sh to LIBDIR is wrong anyway, it should be LIBEXECDIR
[00:06] <infinity> Which may or may not be the same thing, depending on platform.
[00:07] <slangasek> ... if you are building with dpkg-buildpackage it is always set.  Since policy allows you to build by calling ./debian/rules build, you should be setting it in your makefile with DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH).
[00:07] <slangasek> where "your makefile" == "debian/rules"
[00:07] <infinity> It's always set for dh(1) targets, isn't it?
[00:07] <slangasek> infinity: yes, that also
[00:08] <slangasek> with the proper compat level etc etc
[00:09] <infinity> sidi: Anyhow, LIBDIR and LIBEXECDIR are different for a reason.  They may often be the same on, say, RedHat, but they differ on Debian, and differ wildly on BSD (where /usr/libexec is a thing), so yeah.  Callable programs don't live in LIBDIR.
[00:09] <infinity> sidi: That one might take an upstream patch to fix, but it's also The Right Thing To Do.
[00:11] <sidi> aw
[00:11] <sidi> infinity, the thing is this goes into a PPA and my main concern is that I need the fix pushed asap to my study participants so I can stop throwing money out of the window :-) and all of these packages get burnt to the ground the second I don't need them...
[00:12] <infinity> And yet, you're spending time trying to figure out how to multiarch it...
[00:12] <sidi> the original package is firejail. the upstream app doesnt respect any conventions for build chains, and the existing package doesnt have patches to use libexec instead of lib
[00:12] <slangasek> yes, ironically multiarching the world had the side effect of undoing the FHS's attempted merge of libdir and libexecdir
[00:12] <sidi> if i try to do the right thing i probably lose one or two weeks
[00:12] <sidi> infinity, yes because it makes other packages uninstallable
[00:13] <sidi> i have some existing multiarch libs in my PPA that now depend on this package's actual .so libraries (as part of my research). I need to split those from the rest
[00:13] <sidi> Also this is a Linux only package for the matter :-) It's based on Linux namespaces
[00:14] <sidi> knowing this, what would be the least resistance path for me? should i just move all those .sh files to /usr/share/ or something, patch the package's binaries' hard coded paths and go to bed?
[00:15] <infinity> sidi: Well, there's no rule that you have to keep the paths that "make install" gives you. :P
[00:15] <infinity> sidi: Just move things around a bit after dh_auto_install
[00:15] <sidi> if i change the paths i need to patch the original app :-) it somehow expects those .sh files in /usr/lib, sadly
[00:15] <infinity> Yes...
[00:16] <infinity> So, keep the .sh files there.  They belong there.
[00:16] <infinity> And put the libraries in the multiarch paths.
[00:16] <infinity> And you win.
[00:16] <infinity> You don't have to accept where the upstream makefile puts things as final.
[00:16] <sidi> infinity, right so I need to ensure the Makefile uses libdir only for actual .so libraries
[00:16] <sidi> and patch the makefile and voila?
[00:16] <infinity> No.
[00:17] <infinity> Just install with libdir=multiarch as you were, then mv multiarch/firefail/fshaper.sh to usr/lib
[00:18] <Unit193> Hah, nice typo.
[00:18] <infinity> Or do so with a .install file, which I assume you already have for your package split.
[00:18] <infinity> Unit193: Freudian.
[00:20] <sidi> Unit193, wait what? :p
[00:20] <sidi> infinity, alright, let me type this all up and check if it works. im writing the install files right now. well. i'm trying to guess what should be in there from other packages
[00:22] <infinity>         install -c -m 0755 src/ftee/ftee $(DESTDIR)/$(libdir)/firejail/.
[00:22] <infinity>         install -c -m 0755 src/fshaper/fshaper.sh $(DESTDIR)/$(libdir)/firejail/.
[00:22] <infinity> Looks like those are the two that need special treatment.
[00:24] <infinity> sidi: Note that the configure script does know what libexecdir means, so you could also fix it in the upstream Makefile.in with libexecdir=@libexecdir@ and twiddling those two lines.
[00:24] <infinity> YMMV, have fun, etc.
[00:25]  * infinity deletes the source before he's tempted to do the work.
[00:25] <sidi> infinity, thanks
[00:25] <sidi> infinity, you would be wasting your time anyway :-) my fork has an extra libraries on top of the existing mess :-)
[00:53] <smoser> hey, if anyone wants to look at bug 1575572 i'd appreciate it. basically init-system-helpers is broken for installation of a package before systemd is entirely booted.
[00:56] <infinity> smoser: How is that not a cloud-init bug?  Installing services and expecting them to start *while still booting* is a bit nutty.
[00:57] <smoser> it has worked since before lucid
[00:58] <infinity> Because pre-systemd, you probably ran in rc2
[00:58] <infinity> Or you ran in rcS, and then apache started when you reached rc2.
[01:00] <smoser> no. apache started when it was installed like it should have.
[01:00] <infinity> Then you were running your install in rc2.
[01:01] <smoser> possibly. you're probably right that 'runlevel' would provide some actual useful output rather than 'unknown'
[01:02] <smoser> it doesnt seem that odd for a service to insall other packages and do so as it runs in boot.
[01:03] <smoser> puppet or chef probably do this.
[01:03] <infinity> They most certainly don't.
[01:03] <smoser> really?
[01:03] <infinity> They run a daemon post-boot that checks for sanity and reconciles desired system state.
[01:03] <smoser> when is 'post-boot' ?
[01:04] <infinity> At least puppet actually has a delay built in.
[01:04] <infinity> But it's tripped from cron, so at least cron needs to be running.
[01:04] <smoser> ah.. sleep 12 should cover it.
[01:05] <smoser> this coudl be tripped really by anthing
[01:05] <smoser> boot system
[01:05] <smoser> ssh starts
[01:05] <smoser> user sshes in
[01:05] <smoser> apt-get install package
[01:05] <smoser> user expects package is installed
[01:05] <smoser> but systemd isn't "finished"
[01:06] <smoser> s/ssh/logs in at console/
[01:06] <infinity> In systemd parlance, though, it would be "systemctl is-system-running" that is interesting before going and doing apt/dpkg things, I'd say.
[01:09] <smoser> i think its a bug. this worked for at least 3 consecutive LTS releases, probaly worked in gutsy, but i dont really have the interest to check.
[01:09] <smoser> by your suggestion, installation of packages in rc.local would not be possible without some background and poll.
[01:10] <smoser> really seems broken.
[01:10] <infinity> Anyhow, if there's any bug there, it's that we're not starting apache after moving into rc2.  Starting a service in an unknown system state is exactly what an init system is meant to prevent.
[01:11] <smoser> that is not entirely unreasonable. not entirely.
[01:11] <smoser> but it wont start after moving to rc2 because systemd calculates its dependencies and such one time
[01:18] <infinity> Today's painful lesson: Never type 'telinit 2' on a systemd system.
[02:22] <xnox> infinity, hahahahahahaha
[02:22] <xnox> been there done that
[02:23] <xnox> infinity, smoser - i fell disturbance of the force due to lack of $ systemctl daemon-reload in apache2.postinst
[02:24] <xnox> *feel
[02:24] <xnox> pitti, should packages that ship init scripts only, call systemctl daemon reload?
[02:48] <infinity> xnox: The systemd trigger covers that.
[02:49] <infinity> xnox: (So, that's not the problem here)
[02:49] <sarnold> is there any long-term plan to .. clean up after the N init systems at some point?
[02:50] <sarnold> there's a certain lack of elegance in having /etc/init/foo.conf /etc/init.d/foo.sh and .. uhh wherever it is that foo.unit files are stored.
[02:50] <infinity> sarnold: Once we no longer have any upstart sessions anywhere in any of our products, we can completely kill upstart.
[02:50] <infinity> sarnold: Keeping sysvinit for all things in Debian is likely going to continue forever.
[02:50] <infinity> Or, at least, a long time.
[02:51] <sarnold> infinity: well, that's something I guess.
[02:59] <dmick> anyone else got cjwatson-level install-fu, or cjwatson: so I understand most of what finish-install's 90-console does, except 1) who writes /var/run/console-device (kernel?)and 2) where does $rawconsole come from.  (I think I got all the 500MB of pieces of debian-installer, but I can't find that string anywhere in it, where I'd expect it)
[03:00] <sarnold> zounds that was quick, I glanced over 90-console and had -zero- idea what it did :)
[03:00] <dmick> well, I am sort of in the middle of this problem :)
[03:00] <cyphermox> dmick: I can look it up
[03:01] <cyphermox> not nearly the semi-god install-fu of cjwatson, but installers are my thing ;)
[03:02] <dmick> I'm not even sure how it would be passed to this script; AIUI it's running as a postinstall during package installation, and it's surprising that something as specific as 'rawconsole' would be defined in its env, but I don't know how else it could get there
[03:02] <dmick> I suppose it's also possible it's just ab ug.
[03:03] <cyphermox> dmick: the best thing is probably for you to tell us exactly what is the problem you're trying to solve though
[03:03] <dmick> specifically, I started off trying to understand how /etc/init/ttySN.conf got written to enable getty on 'the console' SoL device
[03:03] <dmick> (which appears to match the console= given to the install kernel cmdline)
[03:04] <dmick> and really that's still the goal; the questions above are in service of that underlying question
[03:06] <dmick> (the reason is, we have provisioning code that was configuring this automatically that appears to no longer be necessary, but I'm unwilling to remove it without at least trying to understand why it's not necessary anymore)
[03:07] <infinity> dmick: It's not necessary because systemd doesn't statically configure gettys.
[03:08] <dmick> well yes but we're still provisioning  trusty systems
[03:08] <infinity> Oh, we magically fixed in there too? ;)
[03:08] <dmick> but yeah, I caught the bit about systemd doing this now
[03:08] <infinity> What is your console device?
[03:08] <dmick> /dev/ttySn where n is 0, 1, or 2 depending on the platform
[03:10] <infinity> fwiw, rawconsole just looks like a bug.
[03:10] <dmick> I was starting to think that
[03:10] <dmick> a harmless one, no doubt
[03:10] <infinity> Quite.
[03:10] <cyphermox> unless it comes from some d-i C code that runs finish.d
[03:10] <infinity> As for your provisioning, if you're setting console on the commandline, it should Just Work.
[03:11] <infinity> There shouldn't be need to do anything manual.
[03:11] <dmick> it seems like it does
[03:11] <dmick> like I say, the question was "how", and cjwatson pointed me to this script, which held most of the answer
[03:11] <dmick> so now I'm just filling out the whole picture.  any ideas about the origin of /var/run/console-device?
[03:12] <dmick> oh duh I hadn't grepped d-i yet
[03:13] <infinity> It's from rootskel.
[03:13] <dmick> yep
[03:13] <infinity> Which the finish-install changelog mentions.
[03:13] <cyphermox> there you go
[03:13] <dmick> reopen-console-linux, looks like
[03:13] <dmick> heh, and, amusingly, there's a "console_raw" in that script
[03:14] <dmick> wow.  grepping for a kernel message
[03:14] <dmick> and then eventually what probably happens: grepping /proc/cmdline
[03:14] <dmick> awesome.
[03:14] <dmick> that feels right
[03:16] <infinity> dmick: The sketchy ringbuffer grepping is only on ancient kernels.  We can probably tear all that out upstream now.
[03:16] <dmick> so this provisioning code originated as far back as oneiric, and I bet that either 1) at the time we weren't using the right console= options, or order, in the install boot, and/or 2) it was not quite as smart in those days.  so we just hadn't noticed it was automatic now.
[03:16] <infinity> src/sbin/get-real-console-linux.c is still correct, though.
[03:17] <dmick> ah.  nice info: /dev/console is magical
[03:20] <dmick> *awesome*.  that's much more than I paid for.  you guys are teh awesome
[03:21] <cyphermox> dmick: /dev/console is just whatever was last set as console=
[03:21] <cyphermox> (ie. if you set it multiple times on the cmdline, or it's some default based on the platform or something)
[03:21] <dmick> ...assuming all that other stuff in reopen-console-linux falls through, yes, looks like
[03:22] <dmick> oh sorry, you said /dev/console.  ok.
[03:22] <dmick> right.  and it's got its own maj/min, but the ioctl gets you the real one.  on my desktop running X, it's tty7; on this headless machine I was looking at, it's .. wait for it...  ttyS1, what a coincidence
[03:23] <dmick> that really nails home a lot of stuff I haven't fully understood for a long time; thanks
[03:30] <dmick> so it looks like the active branch of reopen-console-linux is likely the one that calls get-real-console-linux
[03:31] <lfaraone> Is the header for pages like http://releases.ubuntu.com/xenial/ maintained in some bzr branch somewhere I could submit a patch to?
[03:40] <dmick> cyphermox: infinity: really appreciate it.  thanks a mil.
[03:47] <infinity> lfaraone: lp:ubuntu-cdimage
[03:49] <sarnold> "The Breezy Colony 5 release was".. oy vey :)
[04:51] <cpaelzer> good morning
[06:01] <pitti> xnox: as Adam said
[06:41] <Bluefoxicy> hilarious
[06:41] <Bluefoxicy> I upgraded from 14.04 to 15.10, and now I'm upgrading to 16.04
[06:42] <Bluefoxicy> in the past several months, I never noticed that the upgrade kept the 3.16 kernel and never upgraded to 4.2.  No 4.2 kernels installed under Wily.
[07:09] <pitti> Bluefoxicy: missing linux-generic  metapackage?
[07:11] <Bluefoxicy> maybe
[07:11] <Bluefoxicy> it upgraded to 4.4 during do-release-update to 16.04 LTS
[08:18] <seb128> could somebody from the SRU team look at gnome-software in the xenial queue?
[08:20] <pitti> seb128: ok, I'll do a round of sru processing
[08:20] <seb128> pitti, thanks
[08:20] <seb128> pitti, hey btw, wie gehts? still under snow?
[08:20] <pitti> ugh, I got that queue empty yesterday, lots of uploads since then :)
[08:20] <pitti> seb128: non, il y a du soleil à nouveau \o/
[08:21] <pitti> seb128: mais il fait encore très froid, il n'y a qu'une degrée :/
[08:22] <seb128> pitti, c'est l'hiver...
[08:22] <pitti> en effet !
[08:22] <pitti> les premières deux semaines d'avril était très bon
[08:22] <pitti> seb128: but I'm sure that next ween in Austin will be really warm :)
[08:23] <seb128> pitti, what sprint is that?
[08:23] <pitti> seb128: cloud sprint
[08:23] <seb128> oh ok
[08:23] <seb128> have fun there!
[08:23] <pitti> merci !
[08:32] <pitti> seb128: btw, reviewing syncs for SRUs is a royal pain; any chance that these can become proper uploads?
[08:32] <pitti> (fine for this one, but for the future)
[08:32] <seb128> yes, I guess this one had no real reason to be a copy
[08:32] <seb128> sorry about that
[08:35] <pitti> seb128: also needs uploading to yakkety
[08:38] <seb128> pitti, ack
[08:39] <seb128> pitti, can't we just pocket copy? we used to do that early in the cycle
[08:39] <pitti> seb128: I'd rather not; we have a big compiler change, a libpng and other lib transitions already
[08:40] <seb128> k
[08:40] <pitti> and that's the kind of package that very well might link against libpng or libicu
[08:40] <seb128> we are working on rebasing on 2.20.2 we might just upload that one
[08:50] <pitti> armhf test queue < 1000, yay
[09:00] <ginggs> hi pitti, can you let json-c's tests run against u1db 13.10-6.1build1 in -proposed please?
[09:00] <pitti> ginggs: I'll do a mass-retry of regressions as soon as the current backlog settles down
[09:00] <pitti> ginggs: one "normal" round and one against --all-proposed
[09:01] <pitti> to shake out the implicit/forgotten versioned dependencies
[10:05] <rbasak> xnox: are you planning SRUs for bug 1572613?
[10:05] <rbasak> For MySQL, I'm expecting an SRU soon anyway.
[10:12] <xnox> rbasak, yes and no.
[10:12] <xnox> rbasak, so first there needs to be a gcc sru, and then rebuilds with fixed compiler.
[10:12] <xnox> rbasak, doko did say that he wants to sru gcc when 5.4 is out (or something like that)
[10:13] <xnox> and then i'll be looking into what needs fixing, and what "organically" fixes itself.
[10:13] <xnox> rbasak, it also matters where we upload the compiler to.... cause e.g. imho it should be in security pockt.
[10:14] <xnox> but i don't know what plan doko had for the gcc sru, and whether e.g. apw / arges will be annoyed if we do put the kernel into -security
[10:14] <xnox> (affects kernel builds for live patching)
[10:25] <apw> changing the compiler in a stable is always problematic, as i understand the world if we sru a compiler we
[10:25] <apw> have to consider it for the security pocket, so that kernels and dkms packages are built with the same compiler
[10:26] <apw> and we alwyas use the -security compiler for the main kernel
[10:26] <xnox> yeah, cause otherwise there lies madness
[10:26] <xnox> apw, with that compiler bug it is tricky, cause it was not trigger on the kernel sources.... so far...
[10:27] <xnox> but it could be =(
[10:27] <apw> xnox, i am not saying that we shouldn't update the ocmpiler, i am just saying i think it has to go
[10:27] <apw> to the security pocket if we do
[10:27] <xnox> quite for many reasons
[10:28] <xnox> apw, but i don't want to do security uploads =) i don't think i ever done one. So up to doko really =)
[10:38] <siretart> mvo: any chance you could upload the changes in your apt-btrfs-snapshot branch? Did you see my question to you in LP: #1454306? - can I help you with doing the upload for you?
[10:45] <ginggs> hi,  gdcm ftbfs on amd64 only since yakkety (xenial was fine) while linking against libpapyrus3-dev (a static-only lib) "lib/libPapyrus3.a(PapyError3.c.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC".  If I do a no-change rebuild of papyrus, then gdcm builds again on amd64. Does this make sense?  If so, what should I put in papyrus' changelog?
[10:45] <pitti> ginggs: yakkety's gcc now defaults to -fPIE
[10:46] <pitti> ginggs: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2016-April/001183.html
[10:46] <pitti> ginggs: not sure how to revert that, though; -fPIE can't work with static linking
[10:46] <pitti> so maybe it's a gcc bug that it uses PIE for .a too?
[10:47] <pitti> ginggs: also, static linking, *tsk* :0
[10:47] <mvo> siretart: uh, I have not seen that. and help with the upload is very welcome, thanks a bunch for the offer!
[10:47] <ginggs> pitti: this doesn't affect ppc64el though
[10:47]  * pitti thought most libraries stopped shipping .a
[10:47] <pitti> ginggs: right, it only was changed on amd64
[10:49] <ginggs> so isn't rebuilding papyrus with new flags a good thing to do?
[10:49] <pitti> ginggs: yes, it should be, if you disable the -fPIE thing; but I'm not sure whether this is a bug in gcc or in papyrus
[10:50] <pitti> doko: ^?
[10:50] <ginggs> but papyrus and gdcm both build fine without disabling -fPIE
[10:50] <pitti> I thought you just said it doesn't
[10:51] <pitti> oh, with rebuilding both
[10:51] <ginggs> yeah
[10:51] <pitti> ginggs: hm, that almost sounds like the rebuild would build the .a with PIE
[10:51] <pitti> which is wrong AFAIK
[10:57] <ginggs> i can't think of a difference between building the .a with PIE and bundling the paprus source into gdcm and building the whole lot with PIE
[10:57] <ginggs> hmm, and it is lunchtime
[10:59] <siretart> mvo: in order to build the package, I had to disable the pep8 and pyflakes unit test - both fail.
[10:59] <siretart> mvo: please confirm that you are OK with me uploading a package that disables both tests to rakety
[11:06] <siretart> mvo: hm, fixing both tests was easy, I'll upload with those changes
[11:10] <rbasak> xnox: OK, thanks. Well just FYI then, when you're ready it might be worth checking if an SRU has already landed or I still have one planned.
[11:10] <xnox> rbasak, will do will do
[11:16] <doko> ginggs, pitti: yes, rebuilding should be fine
[11:16] <doko> sbeattie, ^^^ still missing your list of static libs to rebuild :-/
[11:17] <pitti> doko: it's ok now to build static libs with -fPIE? (and apparently required now too)?
[11:18] <doko> pitti, if these are used to build binaries built with pie, yes
[11:18] <pitti> doko: ah ok, so that means in yakkety we'll rebuild all packages that ship an .a
[11:18] <ginggs> i think things will blow up if someone tries to link the .a into a .so
[11:19] <pitti> doko: thanks for the heads-up
[11:19] <doko> pitti, and no, we don't have infrastructure to build static libs fithout pie yet
[11:19] <pitti> ginggs: well, .so were always supposed to be PIC/PIE, no?
[11:20] <ginggs> pitti: i thought PIC yes, PIE no
[11:21] <ginggs> but i don't know for sure
[11:21] <pitti> ginggs: I keep confusing the two, I keep thinking of them as the same
[12:33] <pitti> xnox, seb128, slangasek: should we talk about un-upstartifying the desktop session next week at UDS?
[12:34] <xnox> pitti, that would be good
[12:34] <pitti> we haven't had an upstart maintainer for a long time any more, and we're already having trouble finding someone who keeps it buildable
[12:34] <pitti> seb128, xnox: also sounds like a nice topic for a mini-sprint
[12:34] <seb128> +1
[12:34] <seb128> is any distribution using systemd for user sessions nowadays?
[12:35] <pitti> seb128: unknown, but I figure most of them use good old gnome-session
[12:35] <seb128> right
[12:35] <pitti> and I'm sure we can at least replace some of them with dbus activation
[12:35] <Laney> desrt says not
[12:35] <Laney> i.e. someone should work on this :-)
[12:36] <xnox> seb128, as far as i know we are the only ones to have an init for a user session at all.
[12:36] <pitti> so for example, unity-settings-daemon both has an xdg autostart and an upstart session job
[12:36] <xnox> seb128, yolla kind of uses systemd, but it's single-user / system systemd, with many weird patches
[12:36] <pitti> xnox: no, the user systemd unit runs pretty much everywhere, just nobody uses it for distro things yet
[12:36] <xnox> pitti, yeah, i was keeping xdg autostart for systemd-xdg-autostart generator (not upstream)
[12:37] <xnox> pitti, so folks at intel have demostrated full user systemd session with like even "start xfce.target" after a "start gnome.target" with gnome tearing down, xfce coming up with applications staying in place
[12:38] <xnox> very scary but totally usable
[12:38] <xnox> but none of that shipped anywhere.
[12:38] <mapreri> in lp #1574745 can i have a xenial task instead of a milestone in the main task, so that yakkety can be fixed separately?
[12:38] <xnox> pitti, seb128 - but it would probably mean we need user dbus1, upgraded dbus1, and work out the kinks if we can use that.
[12:38] <xnox> as there is no support of multiple systemd user sessions per user, like we currently have in upstart
[12:39] <xnox> pitti, seb128 anyway, yes we should talk, and i should go to the airport soon.
[12:39] <seb128> is multiple-sessions-for-one-users something we support?
[12:39] <pitti> ok, let me create a blueprint/UDS discussion about that
[12:39] <pitti> xnox: oh, already?
[12:39]  * pitti leaves on Sunday
[12:39] <seb128> xnox, safe flight
[12:40] <xnox> pitti, i had a holiday from thrusday - monday, which i had to cut short, so i'm going to austin from budapest on sunday
[12:40] <xnox> and hence wasted money on a non-refundable flight from budapest to london, and one night of hotel.
[12:45] <pitti> https://blueprints.launchpad.net/ubuntu/+spec/desktop-y-replace-upstart
[12:46] <pitti> ah, I feel my lost TB powers already, I can't ack this for UOS any more nor for yakkety (only propose)
[12:47] <pitti> dholbach: do you see this ^ on https://blueprints.launchpad.net/sprints/uos-1605 ? I apparently can't see proposed topics any more
[12:49] <dholbach> pitti, accepted
[12:49] <pitti> dholbach: danke
[12:50] <pitti> dholbach: wow, this really is the first BP for UOS
[12:50] <dholbach> some folks filed "meetings" in summit directly
[13:14] <doko> yofel, please could you sync/merge digikam?
[13:15] <yofel> doko: sure... until when do you need it? (that's not a small thing)
[13:15] <doko> yofel, blocks the lensfun transition (it's a small one), so not immediately
[13:16] <yofel> ok, I'll take a look over the weekend then probably
[14:44] <ginggs> doko: thanks for aster and getdp rebuilds, for some reason i thought they would not be necessary
[14:45] <doko> ginggs, pcl still ftbfs
[14:46] <ginggs> doko: yeah, i saw :(
[14:47] <ginggs> doko: at this stage i have no ideas what do about pcl and yade, both look like issues with boost 1.60 to me
[15:01] <doko> ginggs, when in doubt, ask xnox
[15:05] <ginggs> xnox said "don't use boost" or something like that :)
[15:08] <ogra_> thats just a macro in his IRC client :P
[15:12] <shadeslayer> heh xD
[15:25] <cpaelzer> is there a way that one can send a link (e.g. in a mail) to a file in a deb?
[15:25] <cpaelzer> I can't get to the actual content from here https://launchpad.net/ubuntu/+source/dpdk/2.2.0-0ubuntu8 or http://packages.ubuntu.com/xenial/all/dpdk-doc/filelist
[15:25] <cjwatson> not afaik
[15:25] <cpaelzer> maybe they are just never "extracted" and so can't be reached, but if they are let me know
[15:26] <rbasak> Unfortunately not, AFAIK.
[15:26] <rbasak> The bzr importer used to do it, but doesn't for >= Xenial.
[15:26] <cpaelzer> rbasak: thanks, at least I can stop to search
[15:26] <rbasak> nacc's git importer may help when it's ready and running on dpdk.
[15:26] <cjwatson> even for the bzr importer that was only for source packages
[15:26] <cjwatson> while cpaelzer was asking about debs
[15:27] <rbasak> If the package is in Debian, then sources.debian.net can do it, but presumably that doesn't apply to dpdk right now.
[15:27] <cjwatson> (there is of course overlap)
[15:27] <cjwatson> I'd love to have sources.d.n for Ubuntu
[15:27] <rbasak> Oh.
[15:27] <rbasak> Sorry!
[15:27] <rbasak> Yeah, so most of what I said isn't relevant.
[15:27] <cjwatson> but am not volunteering!
[15:35] <slangasek> pitti: fwiw that UUID shown in that /etc/fstab on the bug is the GPT partition UUID (as the latest bug followup confirms), which no tool would ever have put in /etc/fstab automatically because it doesn't work; this is why the submitter's claim to have never edited /etc/fstab by hand is not credible
[15:37] <pitti> slangasek: urgh, yes, that doesn't belong there indeed
[15:37] <pitti> well, that still doesn't rule out that there's some shady package in ubuntu who does that
[15:37] <pitti> but we won't know really without a reproducer
[15:38] <slangasek> pitti: would have to be *very* shady, to simulate trial-and-error edits to /etc/fstab ;P
[15:38] <pitti> slangasek: well, I've had my share with ecryptfs-setup-swap breaking stuff :) (and it's still not done, got another case reported recently)
[15:38] <cyphermox> slangasek: could it be the result of some weird "fix grub" app?
[15:39] <pitti> but I'm reasonably sure it's not that one for this case
[15:39] <slangasek> cyphermox: maybe.  Do we have such a thing in the archive? If so, we should blast it with a cannon
[15:39] <cyphermox> looking.
[15:44] <doko> hmm, what really is the rationale for building static libs with pie?
[15:46] <slangasek> doko: besides "it's hard to exclude them", and "if your executables are going to be PIE the static libs linked into them need to be PIE"?
[15:47] <doko> slangasek, well, maybe for the former we should have patched libtool for most libs. Do we have any of these binaries for the latter? looks like collateral damage
[15:49] <doko> now rebuilding all rdeps for partclone
[15:50] <slangasek> doko: since we're building executables as PIE by default now, sure, any static lib in the archive that's being linked into an executable depends on this
[15:50] <slangasek> and there are going to be plenty of those around, because if libtool convenience libraries if nothing else
[15:50] <slangasek> (so changing this in libtool is also not going to DTRT)
[16:01] <cyphermox> slangasek: boot-repair looks like a possible culprit, that's *not* in the archive.
[16:01] <tjaalton> anyone who knows qt5 around? why does building owncloud-client against qt5 break it's notificator (doesn't show up)?
[16:04] <doko> tjaalton, is this related to png? there were some test failures in the last qt5 build, so I disabled these to the icu/libpng transition done. didn't hear yet back from Mirv
[16:04] <tjaalton> doko: this is on xenial, actually it's been broken since wily
[16:05] <tjaalton> bug 1511058
[16:07] <doko> tjaalton, ok, then it's not me =)
[16:07] <tjaalton> yeah :)
[16:17] <flexiondotorg> mdeslaur, Do you have a moment for a sort of security question?
[16:43] <doko> seb128, Laney: please could you merge gtk3 and friends?
[16:43] <_3by8> Hi, sorry to bother you guys but I was pretty sure that someone in here could tell me how to figure out if a package comes preinstalled or not. Specifically, open-vm-tools.
[16:44] <seb128> doko, not this week, team sprint, maybe next but SRUs for the LTS to do first and I didn't install y vms/chroots/etc yet
[16:44] <seb128> but feel free to do it if you want
[16:44] <seb128> need to go, team diner
[16:45] <_3by8> I'm having an issue with it and I don't think #ubuntu is going to be able to help. Just to give you some more background, it's preinstalled on a VMWare guest where I need to have the regular VMWare tools. Is it a preinstalled package for all systems? I know I can remove it but I was wondering if there's a switch or something during installation to suppress that from happening if that's the case.
[16:47] <dobey> _3by8: it's installed by default in the ubuntu-server image
[16:47] <dobey> but not ubuntu-desktop and derivatives
[16:47] <_3by8> dobey: can you exclude that package from being installed?
[16:48] <dobey> _3by8: if you install "ubuntu-dev-tools" you can run "seeded-in-ubuntu $package" to see what it's seeded in
[16:48] <_3by8> dobey: never mind, I'll use the network installer.
[16:48] <_3by8> dobey: thank you!
[16:58] <doko> slangasek, so partclone ends up with:
[16:58] <doko> make[3]: Entering directory '/«PKGBUILDDIR»/fail-mbr'
[16:58] <doko> sh compile-mbr.sh
[16:58] <doko> collect2: error: ld returned 1 exit status
[16:58] <doko>  /usr/bin/ld: attempted static link of dynamic object `fail-mbr.o'
[16:59] <doko> now we build up everything for dynamic linkage, and then I assume we pass -no-pie to this builds ... :-/
[17:17] <slangasek> doko: 'mbr' sounds like something that's meant to build freestanding?
[17:17] <doko> yes
[17:19] <slangasek> doko: are each of the objects built before that being passed compiler options that communicate 'freestanding'?  Could we infer no-pie from this?
[17:23] <doko> slangasek, in this case, no, just -nostdlib is passed. unsure if I can assume if this always should be built with -no-pie
[17:24] <slangasek> doko: maybe not "always" built with -no-pie, but maybe it would make sense to assume -no-pie by default?
[17:39] <hallyn> wgrant: i've asked this before, think the answer was no... ther eis no way for me to do a git fetch on launchpad itself into a lp tree (in particular from debian anonscm) right?
[17:50] <slangasek> nacc: hi, fyi I'm going to sync the new version of php-defaults from Debian; this drops our delta to the versioned Breaks:, which is ok because there are newer versions of all of these packages now in yakkety except for php-imagick and php-radius, which need a merge; so php-defaults will just hang out in yakkety-proposed until those merges are done, and then it will have a minor impact on upgrade
[17:50] <slangasek> ordering from xenial which isn't worth carrying a delta for
[17:55] <smoser> anyone able to tell me if this would work:
[17:55] <smoser>  https://code.launchpad.net/~smoser/ubuntu-seeds/ubuntu.yakkety.cloudimg-is-server/+merge/293308
[17:55] <smoser> namely, can one seed list a meta-package that is derived from another ? I suspect it will work, but wonder if its a good idea or if there'd be other fallout.
[18:03] <slangasek> smoser: should probably target the right branch fwiw; but you don't need to make the seed depend on ubuntu-server, you just declare in STRUCTURE that it inherits from ubuntu-server and the fact that these seeds are both metapackages means germinate + ubuntu-meta will DTRT
[18:04] <slangasek> ... if I'm not mistaken
[18:07] <slangasek> smoser: ok, so I may be mistaken.  You still want to do the STRUCTURE bit so that dependencies don't end up duplicated between the two metapackages, but you may indeed need that explicit ubuntu-server, judging by what I see of other packages in the archive
[18:08] <smoser> i re-set the merge target (you probably saw that)
[18:08] <smoser> cloud-image i dont think is a meta-package
[18:08] <smoser> it is a seed.
[18:10] <smoser> and bzr logging shows that once before i did make the change to show cloud-image: standard and then reverted it . my comment says that was per discussion with cjwatson
[18:12] <nacc> slangasek: ack, thanks!
[18:37] <slangasek> smoser: that was two years ago, and possibly based on different requirements at the time?  would like to know what cjwatson's specific objections were there; certainly, given the goal of minimizing and then eliminating the delta between cloud-image and server, I would prefer explicit inheritance there
[18:37] <slangasek> smoser: STRUCTURE is a different sort of inheritance vs. depending on the metapackage
[18:38] <slangasek> anyway, that change LGTM
[19:02] <slangasek> nacc: btw, are you pushing the stage1 patches up to Debian?  Do you have a list of these, should I drop them when merging packages that I'm TIL on and wait for them to come back in from upstream (or not)?
[19:05] <nacc> slangasek: yes, it's on my todo list for this week or next, I hope
[19:25] <mwhudson> docker seems to have been running in autopkgtests for like 12+ hours, but it says "Running for: 35 min 55 s"
[19:26] <mwhudson> does it keep failing and getting retried or something?
[19:26] <slangasek> mwhudson: where do you see "12+ hours"?
[19:27] <slangasek> it's probably a retry of a failed run, or a run that went missing
[19:27] <mwhudson> slangasek: it was running when i went to bed
[19:27] <slangasek> ok
[19:27] <mwhudson> which, sadly, i admit was not 12 hours ago
[19:27] <mwhudson> but definitely more than 35 mins
[19:27] <slangasek> mwhudson: did you definitely see in running, or just 'Test in progress'?
[19:28] <mwhudson> slangasek: it's on http://autopkgtest.ubuntu.com/running.shtml
[19:28] <slangasek> yes, it is now
[19:28] <slangasek> but 12 hours ago, was it? :)
[19:28] <mwhudson> and yes, it was there with output and stuff last night too
[19:28] <slangasek> ok fun
[19:28] <slangasek> then the results were lost, I didn't know that was a thing
[19:28] <mwhudson> i have learnt about the thing where "running" on excuses can actually mean "in the queue behind half of debian"
[19:30] <mwhudson> also excuses links to<EMAIL_ADDRESS>which is a failure on amd64
[19:30] <mwhudson> but i don't think it's linked from http://autopkgtest.ubuntu.com/packages/d/docker.io/yakkety/ppc64el/
[19:30] <mwhudson> er
[19:30] <mwhudson> *failure on ppc64el
[19:31] <slangasek> ... neat
[19:32] <slangasek> mwhudson: pitti should be apprised of these issues; can you file bugs on https://bugs.launchpad.net/auto-package-testing ?
[19:33] <mwhudson> slangasek: ok
[19:39] <mwhudson> huh it's no longer on running.shtml but it's not on http://autopkgtest.ubuntu.com/packages/d/docker.io/yakkety/amd64/ either
[19:40] <mwhudson> slangasek: is it britney that starts the autopkgtests running?
[19:40] <mwhudson> it sort of seems like the results are getting lost so something is just scheduling them to run again?
[19:41] <slangasek> mwhudson: britney triggers them, yes.  britney won't trigger a second time though, so the something else that retriggered is probably a release team member
[19:42] <slangasek> mwhudson: so that's likely pitti, but he may not know that the tests ran before and had results lost as he probably batch-retried
[19:44] <mwhudson> ah ok
[19:44] <mwhudson> these tests are cursed, it seems :-)
[20:29] <smoser> anyone know what urls 'snap install' hits ?
[21:00] <pitti> mwhudson: yes, I'm aware of the docker loop; somewhere in the middle it kills the sshd server-side process  which results in ssh returning with 255, which we currently treat as "temporary failure"
[21:00] <pitti> mwhudson: thus the test is just looping forever
[21:00] <pitti> mwhudson: I'm not quite sure yet what to do about that infra-wise, as in general we *do* want to retry on ssh failures
[21:01] <Unit193> bdmurray: You could likely consider 1573404 a request to add an option to jump early from an LTS to LTS without the first point release.  Currently silly blogs recommend you use '-d' and tell you to ignore the warnings, which can lead to fun if running this when there's an active development version.
[21:04] <pitti> mwhudson: yes, autopkgtest.u.c. browsing is a bit behind, that's on my TODO list
[21:04] <pitti> mwhudson: the direct log links from britney should be okay though
[21:14] <mwhudson> pitti: uggggh
[21:14] <pitti> mwhudson: I updated your bug report, I'll ponder this tomorrow
[21:15] <mwhudson> pitti: strange though, britney links to a log for ppc64el but not amd64
[21:16] <pitti> mwhudson: why strange? as I said, it only loops on ppc64el
[21:16] <pitti> mwhudson: err sorry, only on amd64
[21:16] <pitti> mwhudson: the armhf queue just didn't get to it yet (armhf is lagging quite a bit)
[21:16] <pitti> and the others have results
[21:16] <mwhudson> pitti: ah i think it *was* looping on ppc64el
[21:17] <pitti> mwhudson: note that "in progress (always failed)" does not block promotion
[21:17] <mwhudson> pitti: but then managed to fail more catastrophically and earlier, and got properly recorded as a failure
[21:17] <pitti> mwhudson: it's the armhf test that does
[21:17] <pitti> mwhudson: ah, could be :)
[21:17] <mwhudson> pitti: yeah i'm not so worried about migration, but it would be nice for these tests to work :-)
[21:18] <mwhudson> tianon: ^^
[21:20] <mwhudson> pitti: thanks for the updates
[21:20] <mwhudson> pitti: oh one thing, are the logs for the runs that end with ssh dying kept anywhere?
[21:20] <pitti> mwhudson: yes, I have them, but they aren't public right now
[21:20] <pitti> mwhudson: want one?
[21:21] <mwhudson> pitti: please
[21:22] <mwhudson> pitti: i filed https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1576419 too
[21:24] <pitti> mwhudson: followed up
[21:25] <pitti> mwhudson: I have the complete logs too, but they are a bit difficult to haul across, and also uninteresting (AFAICS)
[21:25] <mwhudson> pitti: thanks
[21:25] <mwhudson> fair enough
[21:25] <pitti> but if you need them, I can get them
[21:25] <mwhudson> pitti: i guess it *could* be OOM?
[21:25] <pitti> mwhudson: yes, that's possible of course
[21:25] <mwhudson> pitti: how much ram do the instances have?
[21:25] <pitti> mwhudson: 1.5 GB normally
[21:26] <mwhudson> ok
[21:26] <mwhudson> next step is to run the tests in verbose mode i guess
[21:26] <pitti> mwhudson: I can add docker.io to "big_tests" which would get them 8 GB
[21:26] <mwhudson> pitti: if that's easy and not too disruptive it might be worth a try?
[21:27] <pitti> but if I do that now before going to bed, I risk blocking the quota for five runners perpetually
[21:28] <pitti> mwhudson: *shrug* ok, done now
[21:28] <pitti> I can do another half hour
[21:28] <mwhudson> hm well
[21:28]  * pitti kills the currently running test
[21:29] <mwhudson> pitti: are you the only one who has access to the infrastructure?
[21:30] <pitti> mwhudson: no; Laney should know his way fairly well; infinity, slangasek and some others have too, but didn't get much hands-on training
[21:31] <mwhudson> pitti: well, i can watch the tests for an hour or two and if it looks bad get one of them to at least move it out of bit_tests?
[21:31] <mwhudson> *big_tests?
[21:31] <slangasek> yes, I have read the autopkgtest manual ;)
[21:32] <slangasek> but oh, we're talking about the infrastructure, I would have to hunt for that
[21:32] <pitti> https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure FTR
[21:33] <pitti> anyway, next runner will grab it
[21:33] <pitti> I added  it to big_tests locally (not committed to https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/worker-config-production yet)
[21:35] <mwhudson> next question!
[21:36] <mwhudson> i want to SRU golang 1.6.2 to xenial unchanged
[21:36] <pitti> mwhudson: http://autopkgtest.ubuntu.com/running.shtml#pkg-docker.io is now running in an m1.large instance
[21:36] <pitti> and promptly hit the quota ceiling (but it will retry until it gets enough)
[21:36] <mwhudson> is it considered best to just update the changelog of the yakkety version and upload that
[21:37] <pitti> mwhudson: -backports?
[21:37] <mwhudson> or put a new entry on top of the xenial version?
[21:37] <mwhudson> pitti: no, -updates
[21:37] <doko> pitti, any idea about the open-vm-tools failure?
[21:37] <pitti> well, unless you can make sure this is 100% backwards compatible -- we shouldn't introduce new FTBFS with an SRUed toolchain
[21:38] <slangasek> mwhudson: bear in mind that SRU requirements for 1.6.2 on top of 1.6.1, given that it would not be coinstallable, would be higher than for the previous golang-1.6 SRU -- ^^ what pitti says.  But in terms of changelogs... "Meh"
[21:38] <mwhudson> pitti: golang upstream is super conservative about point releases
[21:38] <pitti> doko: not from the logs, this needs some deeper investigation; not today any more though (from me)
[21:38] <pitti> it's almost midnight and I'm still swamped in pings and new bug reports :)
[21:39] <doko> hmm, open-vm-tools doesn't even have a debian/tests dir?
[21:39] <pitti> mwhudson: purely the changelog issue, I'd add a new record with " * backport yakkety release" and append a ~16.04.1
[21:39] <pitti> doko: no, it's the dkms autodep8 test
[21:39] <doko> ahh
[21:39] <pitti> mwhudson: aside from teh fact that yakkety has the same version than xenial
[21:40] <doko> so then it's kernel module breakage on amd64
[21:40] <doko> apw, ^^^
[21:40] <mwhudson> pitti: append a new record to which changelog? :)
[21:40] <pitti> mwhudson: well, golang's?
[21:40] <mwhudson> pitti: i meant xenial's or yakkety's?
[21:40] <mwhudson> oh and i should do trusty too
[21:41] <pitti> mwhudson: do a new upload to yakkety with normal versioning, then do the SRU with adding a new record with ~16.04.1 and a backport note; or just change the existing yakkety changelog record accordingly, I don't think it's that important really
[21:41] <mwhudson> pitti: ok
[21:41] <mwhudson> pitti: thanks
[21:41] <apw> doko. yep working on it ...
[21:41] <pitti> mwhudson: oh, err:
[21:41] <pitti>  golang | 2:1.6-1ubuntu4                 | yakkety                   | all
[21:42] <pitti>  golang-1.6 | 1.6.2-0ubuntu2     | yakkety                 | source, all
[21:42] <pitti> mwhudson: this is confusing
[21:42] <mwhudson> waait
[21:42] <mwhudson> golang should have been removed
[21:42] <mwhudson> oh no, binaries
[21:42] <mwhudson> i should have said golang-1.6 above sorry
[21:42] <mwhudson> https://launchpad.net/ubuntu/+source/golang-1.6
[21:42] <pitti> right, the other was golang-defaults, sorry
[21:51] <pitti> mwhudson: no, m1.large didn't help, reverting the big_tests
[21:51] <mwhudson> pitti: huh and :(
[21:52] <hallyn> ...   so i have two libvirt trees, the only difference is http://paste.ubuntu.com/16120216/ .  in one warnings are treated as errors, in the other not
[21:52] <mwhudson> i guess i should try to repro on ec2 or someting
[21:52] <pitti> mwhudson: would also be interesting to repro it locally with qemu, and ssh into teh instance while the test is running
[21:52] <mwhudson> yeah, or that
[21:53] <pitti> mwhudson: if it's your only adt-run with qemu, it'll be port 22000 on localhost (ubuntu:ubuntu)
[21:53] <mwhudson> oh yeah, i made an image when we were looking at juju
[21:53] <nacc> hallyn: something with DEB_BUILDHOST?
[21:54] <nacc> hallyn: don't see why that should matter, though
[21:55] <nacc> hallyn: and nm, i see where it's defined now
[21:55] <hallyn> nacc: yeah it's weird...
[21:56] <hallyn> well i need to get the animals fed before they tear each other apart - bbl
[21:56] <pitti> mwhudson: sorry, port 10022
[21:56] <pitti> 22000 is my "run this VM" script
[21:57] <pitti> mwhudson: running this now: adt-run --apt-pocket=proposed -U docker.io --- qemu /srv/vm/adt-yakkety-amd64-cloud.img
[21:58] <mwhudson> pitti: oh ok
[21:58] <mwhudson> i hadn't even gotten started really :)
[21:58] <pitti> mwhudson: well, and the VM doesn't boot after dist-upgrading to -proposed :/
[22:02]  * pitti re-runs without -U
[22:02] <pitti> mwhudson: wow, the docker.io tests install the entire build toolchain
[22:04] <mwhudson> they're pretty heavy, yeah
[22:11] <pitti> mwhudson: wohoo, what are these tests doing??
[22:11] <pitti> $ mount
[22:11] <pitti> mount: failed to read mtab: No such file or directory
[22:11] <pitti> there's no proper /proc any more, "mounts" is a dead symlink
[22:11] <mwhudson> there's definitely a reason they have all the scary control flags they do
[22:12] <pitti> mwhudson: I was going to check what's currently hanging locally with top, but that also just fails with "Error, do this: mount -t proc proc /proc" :)
[22:12] <mwhudson> pitti: haha ok, i didn't realize that they were /that/ destructive
[22:12] <pitti> Step 5 : RUN gcc -g -Wall -static userns.c -o /usr/bin/userns-test  && gcc -g -Wall -static ns.c -o /usr/bin/ns-test  && gcc -g -Wall -static acct.c -o /usr/bin/acct-test
[22:12] <pitti>  ---> Running in e064dc8c3809
[22:12] <pitti> Container command not found or does not exist.
[22:12] <pitti> ./hack/make.sh: line 258: local: can only be used in a function
[22:12] <pitti> it has hung here for several minutes now
[22:13] <mwhudson> oh right
[22:13] <pitti> nothing in dmesg
[22:13] <mwhudson> my experience is that once you get that "local: can only be used in a function" message, the tests are dead
[22:13] <pitti> anyway, if you can investigate this in local qemu, that'd be great -- really bedtime here, sorry
[22:13] <mwhudson> pitti: but it didn't kill ssh?
[22:13] <pitti> mwhudson: not yet, now
[22:13] <mwhudson> pitti: sleep well?
[22:13] <pitti> s/now/no/
[22:13] <mwhudson> pitti: sleep well!, rather
[22:13] <mwhudson> i'll try to poke with ssh
[22:14] <pitti> mwhudson: but it didn't even get to running the tests that I saw in the log when that happened
[22:14] <mwhudson> er qemu rather
[22:14] <mwhudson> can't type this morning
[22:14] <pitti> mwhudson: http://paste.ubuntu.com/16120559/
[22:14] <pitti> mwhudson: that's how far I got with the local run
[22:15] <pitti> I had two screenfuls more in the production log
[22:15] <doko> why does a package ftbfs with a syntax error on one arch when it succeeds on all others? https://launchpad.net/ubuntu/+source/cgal/4.8-3/+build/9639661
[22:16] <doko> and forgot to say, it builds locally ...
[22:16] <slangasek> doko: because it wants to assert not is fail, and it is fail
[22:17] <slangasek> doko: did you try a straight retry?
[22:17] <doko> two
[22:17] <slangasek> fun
[22:17] <doko> one more ...
[22:19] <pitti> doko: your local mirror might not have new enough -proposed packages in sbuild?
[22:20] <pitti> anyway, -EBEDTIME, really; /me waves
[22:20] <sarnold> see you ina few hours :)
[22:21] <doko> pitti, not using local mirrors for that reason
[22:21] <slangasek> doko: are you building -B or -b?
[22:22] <doko> slangasek, -b
[22:29] <doko> failed again
[22:32] <mwhudson> oops forgot to build check my golang upload :(
[22:45] <doko> giving up on cgal for now ...
[23:24] <wgrant> hallyn: I have git mirroring half done, but currently on hold due to some more important work.
[23:45] <sbeattie> doko: static libs that need rebuilding for -fPIE: antlr, autogen, bglibs, binpac, gadap, i2util, libctl, orbit2, publib, pvm, unicon, zlib. I rebuilt them successfully in a ppa with yakkety-proposed enabled.
[23:45] <sbeattie> doko: I'll have a few more, but I need to finish verifying that they build okay.


[00:49] <BUGabundo> nite folks! TGTiF
[02:58] <Tanks5> Upgraded to Kubuntu 11.04 from 10.10. Get past grub and then Kubuntu 11.04 in plain text appears. after that the screen goes blank and freezes forcing a reboot.
[02:59] <Tanks5> can not get past the blank screen -n00b needs help
[03:06] <hggdh> Tanks5: please use #ubuntu, we do not do support here
[03:06] <Tanks5> thanks
[08:06] <corno> good morning
[08:07] <corno> i would appreciate it if someone can give me some advice or point me in the right direction, my story as follows:
[08:08] <corno> i'm new to the LaunchPad system, joined a few days ago and would love to get involved with bug-fixing/development
[08:10] <corno> i've found a specific bug that i'm interested and its status is as follows:  a patch has been submitted to the bug item.
[08:11] <corno> the patch is made on top of usb-creator version 0.2.28
[08:11] <corno> when i checked out the latest TRUNK i see that other fixes/changes have been committed in the meantime
[08:12] <micahg> corno: you should ask about that in #ubuntu-devel, this channel is mainly for bug triage
[08:13] <corno> micahg - thanks, will do :)
[09:55] <MichealH> Hi all, I'm interested in heavily triaging bugs
[09:55] <MichealH> What was the wiki page again?
[10:02] <MichealH> chrisccoulson: Is there a wiki page to documnet how i can start bug triaging?
[10:04] <chrisccoulson> MichealH, i'm probably not the best person to ask (I hardly do any bug triaging), but https://wiki.ubuntu.com/Bugs/HowToTriage might be a good start
[10:04] <MichealH> Thanks :)
[10:06] <jbicha> chrisccoulson: Do you know why about:startpage in ubufox doesn't show the local homepage when there is no web connection?
[10:06] <jbicha> I have to manually hit File>Work Offline to see it
[10:09] <chrisccoulson> jbicha, my guess is you have the network manager integration turned off
[10:09] <jbicha> ?
[10:09] <chrisccoulson> works here ;)
[10:13] <jbicha> it doesn't work here with networking disabled in nm-applet on Natty with a clean profile
[10:20] <jbicha> I'll just open a bug for you then :-)
[10:21] <chrisccoulson> don't bother, i can already see why
[10:21] <chrisccoulson> in any case, it doesn't really matter, as the offline page doesn't work even when firefox detects you are offline
[10:22] <chrisccoulson> i'm just going to kill that whole thing entirely
[10:22] <jbicha> oh ok, it's easier not opening a bug
[10:23] <jbicha> I care because the theme for the local page is out-of-date (of course that theme doesn't work in Firefox) &
[10:24] <jbicha> it would be easier to kill the local page than retheme it
[10:25] <chrisccoulson> the theme doesn't work in firefox because it is blocked by it's security policy
[10:25] <chrisccoulson> about: URI's can be linked to from remote content, and are therefore blocked from loading local data from the filesystem
[10:26] <chrisccoulson> so the stylesheets are blocked
[10:58] <jibel> mvo, hey, any idea what could cause bug 772775
[10:58] <ubot4`> Launchpad bug 772775 in update-manager (Ubuntu) "Update to 11.04 failed (affects: 2) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/772775
[10:58] <jibel> mvo, this is the second report like this, look at the kde-plasmoid-cwd record in the status file
[10:59] <jibel> mvo, the other one is bug 773022
[11:00] <ubot4`> Launchpad bug 773022 in update-manager (Ubuntu) "Could not install the upgrades to 11.04 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/773022
[11:03] <mvo> jibel: looks like this package is causing the trouble, I don't think it was ever part of the official release, it looks like the new dpkg got stricter about the allowed values in the priority field in natty and therefore causing the crash
[11:07] <jibel> mvo, right, but if you look at the status file from apt-clone in 773022 the record is complete. So it looks like it gets corrupted during the upgrade ?
[11:08] <mvo> jibel: ohhhh
[11:09] <mvo> jibel: that gives it a different level importance
[11:09] <jibel> mvo, that's why I'm requesting your advice :-)
[11:12] <mvo> jibel: I need to go for lunch soon, but I will diagnose afterwards
[11:12] <jibel> mvo, np, bon appétit
[11:12] <mvo> thanks!
[11:13] <jibel> buxy, you might be interested in the above discussion as well. maybe it's a false positive.
[11:19] <buxy> jibel: kde-plasmoid-cwp is not an official package right? it looks like it has a bad Priority field and it should be dropped/fixed prior to the dpkg upgrade
[11:20] <buxy> (and maybe dpkg should refuse to upgrade as long as some packages with bad priorities are installed)
[11:25] <jibel> buxy, my concern was that, in 772775 the record is truncated but it was corrupted before the upgrade too.
[11:26] <jibel> buxy, I was wondering is it could be corrupted during the upgrade.
[11:26] <jibel> because the other report has a complete record.
[11:30] <MichealH> jibel: I had a thing when upgrading
[11:30] <jibel> MichealH, Cool, what thing ?
[11:30] <MichealH> I installed without formatting
[11:30] <MichealH> Then on return the NVidia drivers were playing up with unity
[11:31] <MichealH> Unity was flickerign on and off, rendering it unusable
[11:32] <jibel> MichealH, Do you have a bug numbeR ?
[11:32] <MichealH> In the end, I had to reinstall with formatting becuase Unity 2D bugged up when i started something £D
[11:32] <MichealH> Nope
[11:32] <MichealH> I thought someone else reported it xD
[11:32] <jibel> MichealH, It's better to have 2 reports than none.
[11:32] <MichealH> kk
[11:33]  * MichealH reports 2 bugs, I just found annother
[11:34] <jibel> MichealH, If you can reproduce it can you file a report please, this type of error can be very hardware specific, and affect different pieces of software, X, drivers, kernel, compiz or whatever.
[11:34] <MichealH> The new scrollbars are playing up
[11:34] <MichealH> I really do not want to retry, it took me hours to get everything running again :(
[11:37] <MichealH> Gah! How the ... Do you file a bug :/
[11:38] <MichealH> Its changed completley
[11:43] <jibel> MichealH, to file a bug you can use 'ubuntu-bug package_name' from the command line or the run dialog (alt+f2)
[11:44] <jibel> MichealH, for example to file abug against compiz, run: ubuntu-bug compiz
[13:41] <txomon> hello, I have registered a bug 773195, can someone check if correct?
[13:41] <ubot4`> Launchpad bug 773195 in gnome-power-manager (Ubuntu) "crashes in gnome3 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/773195
[14:06] <hggdh> txomon: unfortunately it does not help much... instead of opening manually, please always use 'ubuntu-bug' -- in your case, 'ubuntu-bug gnome-power-manager'
[14:08] <hggdh> txomon: right now you can try 'apport-collect 773195' to add the missing data
[14:09] <pedro_> a valgrind log would be useful too
[14:09] <pedro_> moi moi hggdh
[14:09] <hggdh> buen moi pedro_ :-)
[14:10] <penguin42> are we collecting Gnome 3 bugs?
[14:10] <hggdh> penguin42: good question... I am so tired I did not even see it was G3. But, if we publish, I guess we accept
[14:11] <hggdh> pedro_: do you know ^
[14:11] <hggdh> ?
[14:11] <penguin42> hggdh: But the only G3 is a ppa isn't it?
[14:11] <penguin42> (Don't get me wrong - I'd like to get G3 debugged)
[14:11] <yofel> iirc we accept them, but they need to be tagged gnome3
[14:11] <pedro_> there's a ppa with gnome3 so yeah, we can forward those later to the upstream folks
[14:12] <pedro_> i'm sure they are going to appreciate having more feedback (bugs) on that
[14:12] <hggdh> yes, now I remember, micahg even added a tag for it
[14:12] <yofel> although I don't find the PPA packages too useful for debugging. A) there's no apport hook B) many packages don't even have debug symbols so are useless for debugging
[14:13] <hggdh> pfui. That really does not thelp
[14:16] <ali1234> is there a metabug for all programs that look bad with a forced resize gripper?
[14:17] <yofel> ali1234: you mean that gtk grip in the bottom right corner ?
[14:18] <yofel> ali1234: bug 704105
[14:18] <ubot4`> Launchpad bug 704105 in gtk+2.0 (Ubuntu) "Resize grip always appears in bottom right of GTK+2.0 windows (affects: 17) (dups: 3) (heat: 142)" [Low,Confirmed] https://launchpad.net/bugs/704105
[14:18] <ali1234> yes
[14:18] <ali1234> lol, bad title
[14:18] <ali1234> it's not a bug, someone specifically went to the trouble of backporting it from gtk3
[14:19] <yofel> well, I DO count it as a bug, as it's totally useless in KDE
[14:19] <ali1234> but it doesn't affect kde applications
[14:19] <ali1234> i consider it a bug too
[14:19] <ali1234> vanilla gtk2+ does not have this patch
[14:20] <yofel> no, but it hides the slider in firefox for example using oxygen-gtk
[14:20] <yofel> which looks bad
[14:20] <ali1234> it's useless if you use any theme but light-themes
[14:20] <ali1234> because all the other themes have window borders
[14:20] <yofel> plus it makes the 'down' button of the slider unclickable
[14:22] <ali1234> the annoying thing is they are saying every app that doesn't want this has to be patched separately
[14:22] <charlie-tca> I like the way it shows up in things like launchpad bugs, when you are changing status/importance and commenting
[14:22] <ali1234> so what am i supposed to do?
[14:22] <ali1234> set this bug as "affecting" every package that has a resize gripper?
[14:22] <charlie-tca> You have to add each package to the bug
[14:22] <ali1234> i'm happy to do that
[14:22] <charlie-tca> not every package, no
[14:23] <ali1234> but there is probably several hundred
[14:23] <charlie-tca> only packages it does not belong in, or interferes with use
[14:23] <ali1234> like i said, several hundred
[14:23] <ali1234> the list of packages where it works properly is a shorter list
[14:24] <charlie-tca> Alternative would be a new bug for each one, then dup them to the master
[14:25] <ali1234> also since this whole problem is caused by an ubuntu specific there is zero chance of upstream ever "fixing" it
[14:25] <charlie-tca> It is not caused by ubuntu, it is caused by gtk
[14:25] <ali1234> it is caused by a patch to gtk which is only present in ubuntu
[14:26] <charlie-tca> but if they do not get in the way of use, they won't be fixed
[14:26] <yofel> but it does get in the way of use...
[14:26] <charlie-tca> sometimes, yes. Gedit has it, but it does not get in the way
[14:26] <seb128> the said patch is in gtk3
[14:27] <seb128> so it will be an issue for softwares when they switch to gtk3 this cycle
[14:27] <seb128> softwares should be fixed when they are buggy
[14:27] <yofel> seb128: then why does it show up in firefox?
[14:27] <ali1234> the patch which causes the problem is the one in gtk2
[14:27] <ali1234> the one that canonical backported
[14:27] <seb128> right, well better to fix applications
[14:27] <seb128> they will have that issue when they start using gtk3 which has the same patch than the one ubuntu backported to gtk2
[14:28] <seb128> the way forward is to fix buggy cases not to rollback the patch which is useful
[14:28] <ali1234> how can the applications be fixed when the call which is needed to disable the gripper doesn't even exist in vanilla gtk2?
[14:28] <seb128> yofel, it's a firefox bug I guess
[14:28] <yofel> seb128: well, it's caused by firefox not having the status bar at the bottom anymore
[14:28] <seb128> it does in the ubuntu gtk2 version and softwares are distribued in the ubuntu archive and can be patched
[14:28] <yofel> try to click that down arror here: http://people.ubuntu.com/~yofel/pics/slider.png
[14:29] <seb128> chrisccoulson, ^ can you confirm that's an issue?
[14:29] <yofel> s/arror/arrow/
[14:29] <seb128> yofel, I can't confirm that issue on natty
[14:29] <ali1234> i have exactly the same problem in firefox
[14:29] <yofel> seb128: this is kubuntu
[14:29] <seb128> well then there is a kubuntu interaction bug that needs to be fixed
[14:30] <seb128> in works fine on unity or classic GNOME
[14:30] <seb128> in -> it
[14:30] <ali1234> no it doesn't
[14:30] <ali1234> i am using unity on natty, identical problem
[14:30] <seb128> that's a very useful discussion
[14:30] <yofel> seb128: then why did this work fine in kubuntu before the patch was applied?
[14:30] <seb128> well "works here" and "nobody complain about it during the week of testing"
[14:31] <ali1234> i've been complaining about it since... oh 6 months ago?
[14:31] <ali1234> all i got was "it'll be better when it is released"
[14:31] <seb128> talk to chrisccoulson
[14:31] <yofel> seb128: I see several people complaining on the bug
[14:31] <seb128> he's maintaining firefox
[14:31] <seb128> is that a pure cosmetic thing?
[14:31] <seb128> or is that actually breaking anything?
[14:31] <ali1234> no, i cannot click on the scroll bar arrow it obscures
[14:32] <yofel> considering that I can't click the slider down button I don't count this as cosmetic
[14:32] <tdn> After installing Ubuntu 11.04 and enabling the restricted Broadcom STA wifi driver, the wifi network stops working after a while. How do I fix this?
[14:32] <yofel> sure, I can just use the slider, but it still breaks something
[14:32] <seb128> right, seems a small bug
[14:32] <seb128> in firefox
[14:33] <seb128> well I can still click the button but it's less easy to catch due to it
[14:33] <ali1234> well i'm going to set that bug as affecting firefox, pidgin, and anything else where the grip obscures the UI
[14:33] <yofel> hm, true, if I catch it I can click on that small visible corner
[14:33] <chrisccoulson> i already know about the firefox issue
[14:33] <chrisccoulson> and please do not assign a bug to multiple packages
[14:34] <chrisccoulson> i'll just remove the firefox task else. i get enough bug spam already
[14:34] <ali1234> ok, in that case i will open bugs for every single package instead :)
[14:34] <seb128> there is a bug for pidgin iirc but that one is purely cosmetic
[14:34] <ali1234> gimp?
[14:34] <seb128> check for open bugs, most are probably known
[14:34] <chrisccoulson> and there is already a bug for firefox
[14:35] <ali1234> it would be useful if there was a way to find them. are you tagging them "gripper" or something?
[14:35] <seb128> it's a small annoyance in some softwares but it's a real win compared to trying to get the 1 pixel corner which was an issue before adding those
[14:35] <penguin42> ali1234: I'm curious - where? The grip doesn't seem to be a problem for me on pidgin here
[14:35] <seb128> penguin42, you can see it a bit over the buddy image
[14:36] <ali1234> and also on the conversation windows
[14:36] <penguin42> seb128: Yeh but only when I hover to scroll
[14:36] <seb128> well in any case those handle have been added because they solved a real usability issue
[14:37] <seb128> so dropping it is not the way
[14:37] <penguin42> it seems the whole idea is to reduce the horizontal impact of the scrollbar most of the time by something that only appears when in use
[14:37] <ali1234> a usability that was introduced by another ubuntu customization
[14:37] <ali1234> +issue
[14:38] <yofel> I think what people are annoyed about is that the patch was added to fix an issue in one theme, and is force-applied to any gtk theme out there, even if there's absolutely no need for it
[14:40] <seb128> ali1234, the patch has been added upstream in gtk3
[14:40] <ali1234> but not gtk2
[14:40] <ali1234> and all the programs that have a problem use gtk2
[14:40] <seb128> it just got backported to ubuntu gtk2 because ubuntu didn't switch to gtk3 in natty
[14:41] <charlie-tca> ali1234: I did not intend to give you bad information. Apparently, a new bug is needed for each one.
[14:41] <charlie-tca> thanks, seb128
[14:41] <seb128> yw
[14:42] <seb128> well it's interesting to see that users do click on that small scrollbars arrow icon rather than using mouse scrolling or just scrolling on the scrollbar which does the same basically but is easier to catch
[14:42] <ali1234> i'm more annoyed about the cosmetic bugs
[14:42] <seb128> yofel, well, ubuntu focus on a solid experience for its default desktop rather than mixed experience for each desktop because comprises needs to be done
[14:43] <ali1234> light-themes was supposed to make it look better
[14:44] <ali1234> a few applications where it overlaps the UI: http://imagebin.org/150784
[14:45] <penguin42> ali1234: Oh - that square at the bottom - yeh I'd noticed that - what is that?
[14:45] <ali1234> um... it's the resize grip?
[14:45] <penguin42> ali1234: Apologies - before I thought you were referring to the scrollbar grips
[14:45] <seb128> well not sure why that's happening for you but it's not happening on a default installation
[14:46] <ali1234> this *is* a default installation
[14:46] <seb128> like the appearance dialog and pidgin conversation dialogs don't have ui cutting
[14:46] <seb128> well it's not happening to everybody
[14:46] <seb128> not sure what is different in yours
[14:46] <ali1234> all you have to do to reproduce that is switch to any theme that isn't light-themes
[14:46] <seb128> well then it's not the default installation ;-)
[14:46] <ali1234> and then switch back to light-themes
[14:47] <ali1234> i have no idea why i also have human window borders and light widgets
[14:47] <penguin42> ali1234: On pidgin for me it's much cleaner - it's just across the corner, it doesn't have a the square effect -it almost looks for you like it's not masking properly
[14:48] <seb128> right, I don't get the square either here
[14:48] <seb128> or in the appareance capplet it doesn't go over the button
[14:48] <ali1234> try changing theme to clearlooks and then back to ambiance
[14:48] <ali1234> (note that clearlooks is present in a default install)
[14:48] <seb128> it's just after changing theme for the current session?
[14:48] <seb128> or does it persist after restarts?
[14:49] <ali1234> no idea i haven't restarted since i installed unity a week ago
[14:49] <ali1234> it's been "fun"
[14:49] <seb128> seems like a bug, but if that's for one session that seems minor rather
[14:49] <seb128> well open a bug against gtk in launchpad
[14:49] <ali1234> if it was only drawing a triangle instead of a square it would not make much difference to me
[14:50] <ali1234> i will test if it persists after restart
[14:50] <ali1234> seems that it does not
[14:59] <ali1234> hmm so what's a package that uses gtk3 that i can test against?
[15:03] <ali1234> this seems to be the collection point for the grip bugs if anyone is interested: https://launchpad.net/hundredpapercuts/+milestone/nt9-grippy
[15:22] <txomon> hggdh, did it
[15:23] <somethinginteres> hi all, I noticed when installing 11.04 on my netbook (wubi) that the install screen was too big for the monitor and the progress bar was not visible. How do I report this problem?
[15:25] <penguin42> somethinginteres: From the installed system run ubuntu-bug ubiquity
[15:25] <penguin42> oh actually hang on
[15:25] <penguin42> I'm not sure what the installer package is for wubi?
[15:26] <somethinginteres> I don't think this is a Wubi specific problem the install proccess semmed identical to the normal one. Wubi just "launched" into that after doing its job as it were
[15:26] <jibel> somethinginteres, it's reported in bug 727905, you can add a comment there.
[15:26] <ubot4`> Launchpad bug 727905 in ubiquity (Ubuntu) "Installer windows are sometimes too tall for small wide-screen devices (netbooks) (affects: 4) (dups: 2) (heat: 92)" [Undecided,New] https://launchpad.net/bugs/727905
[15:27] <somethinginteres> ah, thank you both penguin42 and jibel
[15:28] <jibel> somethinginteres, some users are reporting that it is fixed for them, since you still have this problem add the necessary information that could make a difference, like your screen resolution and language used during the installation.
[15:30] <somethinginteres> jibel: yes, I will find that out. I wonder if those reporting it fixed used the final release ISO sans any updates?
[15:36] <jibel> somethinginteres, from the date of the comments I'd say no, the last comment is 1 month ago. You can also add a screenshot/picture of your screen, this helps to determine what takes too much space.
[15:38] <somethinginteres> jibel: hmm wouldn't that involve a reinstall?
[15:42] <jibel> somethinginteres, yes it would.
[15:42] <bdmurray> jibel: I reported bug 772913 after our discussion yesterday
[15:42] <ubot4`> Launchpad bug 772913 in update-manager (Ubuntu Natty) (and 1 other project) "apport not turned on for distribution upgrades (affects: 1) (heat: 12)" [High,In progress] https://launchpad.net/bugs/772913
[15:43] <jibel> bdmurray, yes, seen it. Thanks for investigating and finding out what is wrong.
[15:44] <mvo> bdmurray: I uploaded it now, its waiting in the unapproved queue
[15:44] <bdmurray> mvo: thanks
[15:45] <mvo> thanks YOU
[15:45] <bdmurray> jibel: I'd still like to improve the bug reporting situation before the dist upgrade starts running though
[15:50] <txomon> hggdh, Is now complete?
[15:57] <jibel> txomon, it's better but still incomplete. As pedro_ suggested could you please attach a valgrind log https://wiki.ubuntu.com/Valgrind
[15:59] <txomon> jibel, sry I didn't see that line
[15:59] <jibel> txomon, np
[16:04] <txomon> jibel, now, gnome-power-manager works (if using valgrind to launch it)
[16:20] <jibel> txomon, without this trace it will be hard to guess what's wrong
[16:55] <txomon> jibel, I attached the log file, but just wanted to point on that detail
[16:58] <jibel> txomon, Great! thanks.
[17:50] <penguin42> bug 728840 is making a running for the record on number of dupes
[17:50] <ubot4`> Launchpad bug 728840 in samba4 (Ubuntu) "upgradeprovision crashed with LdbError in connect(): (80, 'Failed to load modules from: /usr/lib/samba/ldb\n') (affects: 98) (dups: 130) (heat: 990)" [Medium,Confirmed] https://launchpad.net/bugs/728840
[17:52] <bdmurray> well it'd be helpful if a bug pattern were written for it then
[17:53] <penguin42> how do bug patterns work?
[17:54]  * penguin42 is no samba expert - but there seem to be a whole bunch of samba4 package install failures that match the description on that one coming in
[17:54] <bdmurray> you write an xml file with criteria regarding the bug (package, version?, traceback) and apport checks for those before filing the bug so the reporter gets redirected to that master bug number
[17:57] <penguin42> is it normal for someone knowledgeable about that package to do it?
[17:57] <bdmurray> its doesn't really need to be someone with specific knownledge about the package
[17:58] <penguin42> ok, is there some mechanism to test the rule - i.e. something you give it a bug number and the rule and it tells you if it would fire?
[17:58] <yofel> yes, in the patterns branch
[17:58] <bdmurray> yes you can test it with the bug number and actually search all bugs about the package for duplicates
[17:58] <bdmurray> I'm writing one now fwiw
[17:58] <yofel> lp:~ubuntu-bugcontrol/apport/ubuntu-bugpatterns
[17:59] <yofel> ah k
[17:59] <bdmurray> however I am sure there are more tagged bugpattern-needed
[18:01] <yofel> true, quite a few https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bugpattern-needed
[18:52] <penguin42> so my gnome3 bug was just closed with a 'the ppa versions are not officially supported'
[18:54] <yofel> micahg: we don't want those bugs anymore?
[18:54] <micahg> penguin42: bug #?
[18:54] <penguin42> bug 773464
[18:54] <ubot4`> Launchpad bug 773464 in gdm (Ubuntu) "Gnome3: GDM doesn't set any locale/lang variables (affects: 1) (heat: 6)" [Wishlist,Invalid] https://launchpad.net/bugs/773464
[18:55] <micahg> seb128: ^^ this seems like a system integration bug
[18:56]  * penguin42 isn't 100% sure where the problem is - I mean gdm seems to no longer have a chooser for the language, so I can see why it doesn't set it, but I would have thought that the language would be defined by the interface that a display manager should set
[18:57] <seb128> penguin42, GNOME3 is in a ppa an supported in no official way
[18:57] <seb128> micahg, GNOME decided to drop the keyboard and locale selectors from gdm in GNOME3
[18:58] <seb128> not sure what we intend to do next cycle but not likely get gdm3 the way it is
[18:58] <seb128> but in any case it's not an Ubuntu bug
[18:58] <penguin42> seb128: I'd assumed that, but the discussion at: 2:11pm (i.e. nearly 5 hours ago) was seeming we were accepting the bugs
[18:59] <seb128> didn't read that one and I closed IRC since
[18:59] <seb128> but we don't
[18:59] <seb128> whoever told you that mislead you
[18:59] <penguin42> ok, it would seem useful to collect them somewhere though
[19:00] <seb128> there is a mailing list for the gnome3-team on launchpad, send an email there
[19:00] <seb128> that's how they tracked the ppa issues
[19:00] <penguin42> ok
[19:00] <micahg> seb128: I was originally told that system integration issues could be tracked in LP
[19:00] <micahg> we created a tag for this purposee
[19:01] <seb128> that's not a system integration, it's a GNOME3 decision to drop the keyboard and locale selectors
[19:01] <micahg> seb128: ok, but in general, we're still collecting packaging, system integration issues in bugs?
[19:01] <seb128> yes, packaging issues are interesting
[19:02] <seb128> but we can't do a lot about features GNOME decided to drop in GNOME3
[19:02] <seb128> or at least having bugs about those is of no real use
[19:02] <micahg> seb128: ok, no problem, thanks
[19:03] <seb128> yw
[19:03] <penguin42> they do seem to have dropped some things that I miss
[19:06] <seb128> penguin42, there is a reason we didn't go for it this cycle ;-)
[19:06] <micahg> penguin42: maybe it would be proactive to discuss this issue with the kubuntu devs to see if there's anything they want to do
[19:06] <penguin42> micahg: Well except I assume it would break other sessions as well
[19:07] <micahg> penguin42: well, so everyone will have to adjust
[19:07] <penguin42> seb128: I might be the one person who prefers unity to gnome3 (although tbh I'd still have gnome 2 over either)
[19:08] <penguin42> micahg: It seems wrong to force everyone else to change because of one decision
[19:08] <seb128> penguin42, you are probably not the only one, I guess each desktop will have users liking it over the other ones
[19:08] <penguin42> seb128: It's the workspaces that I miss - I'm a long term user of a 3x3 workspace setup
[19:08] <seb128> penguin42, but we will review GNOME3 and such issues at UDS so maybe wait a bit
[19:08] <seb128> hum, go to go
[19:09] <seb128> bye
[19:09] <micahg> penguin42: there are other options besides gdm (kdm, xdm, lightdm)
[19:09] <penguin42> micahg: Yeh, but I'd expect that you should be able to use any dm with any session
[19:10] <charlie-tca> doesn't work as far as I know, though
[19:10] <micahg> penguin42: well, that's up to each piece of software to want to play nice with the others
[19:11] <penguin42> micahg: Well, I'd assume it was upto someone to define the interface between dm and session
[19:11] <micahg> penguin42: sounds like there should be a freedesktop.org standard :)
[19:12] <penguin42> micahg: Indeed
[19:16] <Bourne> what is the status for this bug https://bugs.launchpad.net/ubuntu/natty/+source/linux/+bug/730972/+activity
[19:16] <ubot4`> Launchpad bug 730972 in linux (Ubuntu Natty) (and 1 other project) "IdeaPad U160 Broadcom wifi not connecting (affects: 9) (heat: 48)" [Medium,Confirmed]
[19:56] <BUGabundo> deb mirror://mirrors.ubuntu.com/mirrors.txt oneiric main restricted universe multiverse
[19:56] <BUGabundo> there we go
[19:56] <BUGabundo> who is coming with me?
[19:56] <charlie-tca> heh
[19:57] <charlie-tca> a little too early for me. I can't do it until after UDS
[19:57] <BUGabundo> why charlie-tca?
[19:57] <penguin42> BUGabundo: But we haven't even got a +1 yet!
[19:57] <BUGabundo> now we can
[19:58] <charlie-tca> Things get too hectic for me
[19:58] <BUGabundo> now we have user(s) running +1 again :D
[19:58] <hggdh> BUGabundo: I am amazed by your courage ;-)
[19:58]  * yofel only created a oneiric pbuilder so far
[19:58] <BUGabundo> charlie-tca: lIES
[19:58] <BUGabundo> hggdh: why? I've been doing this since 5.x
[19:58] <yofel> I'll stick to natty for some kubuntu-ppa and SRU testing I think
[19:58]  * charlie-tca is just plain scared to do it ?
[19:58] <BUGabundo> *8c
[19:58]  * penguin42 waits for his ppa to wake up
[19:58] <BUGabundo> grrr
[19:58] <BUGabundo> **8.10
[19:59]  * yofel didn't see anything scary uploaded to oneiric so far though
[19:59] <BUGabundo> right now we have in oneiric just about the same as natty plus proposed
[19:59] <BUGabundo> if not even older
[19:59] <micahg> BUGabundo: new toolchain
[19:59] <BUGabundo> so?
[19:59] <penguin42> BUGabundo: Oh new toolchains add so many ways to break things :-)
[20:00]  * charlie-tca prefers to let BUGabundo lead the way
[20:00] <BUGabundo> :D
[20:00] <BUGabundo> we wait for you guys in +1
[20:01] <charlie-tca> I will see you there in a couple of weeks
[20:01] <BUGabundo> hope it opens soon D:
[20:01] <BUGabundo> now I need to test *every* PPA
[20:01] <BUGabundo> to see the ones still valid
[20:02]  * yofel goes back to trying natty with compressed btrfs
[20:02] <BUGabundo> $ grep ppa /etc/apt/sources.list | wc -l 27
[20:02] <BUGabundo> anyone with *very* slow systems why running APT?
[20:02] <BUGabundo> specially on SSD / BTRFS?
[20:03] <Pici> BUGabundo: archive.u.c and ppa.lp.net are both overloaded right now, related?
[20:03] <BUGabundo> Pici: naaaa, I'm using mirrors
[20:03] <BUGabundo> but I mean for the last month or so
[20:03] <arand> BUGabundo: I've heard about btrfs issues with apt..
[20:03] <yofel> overloaded is an understatement...
[20:03] <BUGabundo> E: Failed to fetch http://mirrors.fe.up.pt/pub/ubuntu/pool/main/t/telepathy-mission-control-5/telepathy-mission-control-5_5.7.9-1_amd64.deb: 404  Not Found
[20:03] <BUGabundo> oh well
[20:03] <BUGabundo> not synced yet
[20:04] <BUGabundo> The following actions will resolve these dependencies:
[20:04] <BUGabundo>       Remove the following packages:
[20:04] <BUGabundo> 1)      ubuntu-desktop
[20:04] <BUGabundo> 2)      xorg
[20:04] <BUGabundo> great broken left overs
[20:04] <BUGabundo> EEEWWWWWWWWWWWWWWWWWWWW
[20:04] <arand> BUGabundo: One workaround was using "eatmydata" to disable some safety feature ;)
[20:04] <BUGabundo> arand: barricades ?
[20:05] <BUGabundo> since 10.04 brough those, my system is SLOWWWW
[20:05] <BUGabundo> I should disable it
[20:05] <arand> BUGabundo: Or sync-something, I don't remember the name.
[20:05] <BUGabundo> but using btrfs and SSD the risk is to high
[20:06] <penguin42> yeh I think it's doing a sync or partial sync after each package to recover better with ext4
[20:06] <yofel> you can disable the sync() calls by adding force-unsafe-io to dpkg
[20:08] <wad> Is this where I would come to report a bug?
[20:08] <BUGabundo> wad: that would be launchpad
[20:09] <yofel> !bugs
[20:09] <ubot4`> If you find a bug in Ubuntu or any of its derivatives, please file a bug using the command « ubuntu-bug <package> » - See https://help.ubuntu.com/community/ReportingBugs for other ways to report bugs - Bugs in/wishes for the IRC bots (not Ubuntu) can be filed at http://bugs.launchpad.net/ubuntu-bots
[20:09] <wad> ah
[20:09] <wad> thanks!
[20:22] <wad> So I'm planning on reporting a bug around dual-monitor configuration where one monitor is positioned above another. What package does this pertain to?
[20:31] <BUGabundo> http://paste.ubuntu.com/600936/
[20:31] <BUGabundo> that's what my X looks like
[20:31] <BUGabundo> scary
[20:32] <yofel> hm... natty on compressed btrfs on an SDHC card on my eeePC is actually quite usable :)
[20:35] <jibel> BUGabundo, why do you need X, real man running oneiric doesn't need it ;-)
[20:35] <BUGabundo> :D
[20:46] <RedSingularity> jibel: Does the issue in this bug really belong to update-manager you think?  Or is there a better suited package to assign...?  bug 771032
[20:46] <ubot4`> Launchpad bug 771032 in update-manager (Ubuntu) "overlapped progress bar and column label in update manager dialog (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/771032
[20:49] <jibel> RedSingularity, it looks like a problem with the theme or the rendering engine.
[20:49] <RedSingularity> jibel: you think metacity?
[20:49] <jibel> no
[20:49]  * jibel looking
[20:51] <jibel> RedSingularity, gtk2-engines
[20:53] <RedSingularity> jibel: ah alright.  I have seen these types of bugs a few times but never knew exactly the culprit.  Thanks ;)
[20:53] <jibel> RedSingularity, yw
[21:36] <penguin42> hmph my PPA doesn't seem to be getting anywhere
[23:29] <BUGabundo> /dev/sda5              58G   51G  2.1G  97% /
[23:29] <BUGabundo> no wonder SSD is slow :\
[23:49] <arand> BUGabundo: You using natty on metal btw? I snapshotted and pulled the trigger on a kvm at least ;)
[23:49] <arand> *oneiric
[23:50] <BUGabundo> ohhh I forgot to make a snapshot
[23:50] <BUGabundo> DOH
[23:50] <BUGabundo> oh well
[23:50] <BUGabundo> risk it or leave it
[23:51] <BUGabundo> plus I just sdgear643y5n45u4 my entire X tree
[23:51] <BUGabundo> so if you don't see me in here tomorrow :P
[23:51] <arand> BUGabundo: What on earth are you on btrfs for! :þ
[23:53] <penguin42> arand: Masochism
[23:53] <yofel> hm, btrfs does work, I tried it today (and learned what people meant by saying that dpkg is slow on btrfs *shudder*)
[23:54] <arand> Well, I should already know that..
[23:57] <BUGabundo> yofel: :(((((((((((((((((((((((((((((((((((((((((
[23:57] <yofel> agreed