[00:05] <maxb> hallyn: http://package-import.ubuntu.com/ can show you packages the importer is currently errorring on, libvirt being one of them
[00:06] <maxb> In this case it looks like some sort of bug in bzr-builddeb's code
[00:40] <infinity> lifeless: Nah, it's just on my list of things to informally chat with mvo about, no big deal.
[05:19] <didrocks> good morning
[08:19] <bambee> hi, http://paste.ubuntu.com/658502/ <-- an idea ?
[08:31] <hrw> hi
[08:32] <hrw> can someone maintaining networkmanager look at bug 819700 and tell me how to help?
[08:35] <debfx> bambee: could you try reinstalling virtualbox-dkms
[08:36] <geser> hrw: cyphermox takes care of network-manager
[08:36] <hrw> geser: thx, will wait for him to wake up
[09:23] <bambee> debfx: trying
[09:26] <bambee> debfx: good point, it's fixed, thanks
[11:13] <tkamppeter> I am packaging CUPS 1.5.0 and the saemon segfaults. If I start it from the command line ("sudo cups -F") it does not dump core, even after "ulimit -c 9999999". How do I get a core file?
[11:13] <tkamppeter> s/saemon/daemon/
[11:14] <geser> tkamppeter: IIRC you had so set a value in /proc else the core dump gets routed to apport
[11:16] <tkamppeter> geser, thanks, found a solution: Run the command in a root shell.
[11:17] <tkamppeter> geser, did not core, what do I have to set in /proc exactly
[11:21] <geser> tkamppeter: echo core > /proc/sys/kernel/core_pattern
[11:21] <geser> currently it should contain a pipe to apport
[11:25] <tkamppeter> geser, yes
[11:26] <tkamppeter> geser, I tried your command and could not find the core, then I tried to set /tmp/core and did not ghet a core in /tmp ...
[11:26] <geser> hmm
[11:28] <tkamppeter> geser, switched AppArmor to complain and also does not help.
[11:37] <geser> and the root shell you run "cups -F" from doesn't have a core limit set? (just to be sure)
[11:41] <tkamppeter> geser, I had set "ulimit -c 9999999" there, too.
[11:45] <geser> why not set it to "unlimited" in your root shell? but I guess that's not the reason why you don't get a core file
[11:46] <tkamppeter> geser, thanks. Tried it now and did not work, too. Seems to be a kernel bug generally preventing to generate core files.
[11:50] <geser> might one of our security features prevent it too?
[11:52] <tkamppeter> geser, seems that I have to switch back to apport and create a bug report on code which was never uploaded, only to extract a core ...
[11:52] <geser> urgs
[11:53] <tkamppeter> geser, or is there a possibility to extract the core from /var/crash/_usr_sbin_cupsd.0.crash without sending it to Launchpad?
[11:55] <geser> "apport-unpack: Unpack a report into single files (one per attribute). This is most useful for extracting the core dump." (from https://wiki.ubuntu.com/Apport)
[11:58] <tkamppeter> geser, that's it. Got access to a core by that. Thank you very much.
[12:00] <geser> np
[13:31] <ahasenack> Spads: ping
[13:31] <ahasenack> Spads: nm, wrong nick
[13:31] <ahasenack> SpamapS: ping
[13:32] <ahasenack> SpamapS: can you give me an update on the landscape-client lucid sru? I think it has been in proposed for a week now
[13:35] <cyphermox> hrw: am here now.
[14:04] <hrw> cyphermox: can we talk in 0.5h? meeting in progress
[14:08] <cyphermox> sure, just ping me
[14:10] <hrw> ok
[14:16] <apw> cjwatson, what defines which modules are packaged up for the live initramfs used by casper ?
[14:29] <kees> tkamppeter, geser: I didn't read full backscroll, but you can't get a core dump out of a proces that has changed uid. you can bypass this by setting /proc/sys/fs/suid_dumpable to "1", though, but it will leave a system rather exposed to local attacks.
[14:32] <tkamppeter> kees, so better to use the apport-unpack method.
[14:34] <kees> tkamppeter: well, apport won't see a core dump at all for processes that have made uid transitions, iirc
[14:35] <kees> tkamppeter: but if you have a reproducible crash, you can temporarily set the flag, crash the service, let apport catch it, then restore the flag
[14:40] <tkamppeter> kees, no chance, I do not get a core.
[14:42] <kees> tkamppeter: hm, dunno
[14:47] <infinity> apw: It's just a default initramfs-tools config, unless something's changed, so it will be "modules=most" in initramfs.conf.
[14:48] <apw> infinity, ahh thanks, obvious
[14:49] <infinity> apw: Following that codepath in update-initramfs is fairly self-evident, I assume :)
[14:49] <infinity> apw: Are we missing anything specific, or was the question purely educational?
[14:51] <apw> infinity, yeah we may be missing a new module, will go and look at it, thanks
[15:15] <mdeslaur> so, because of the accidental sync, swig2.0 in universe now has a swig package that supersedes the swig1.3 swig package in main, causing some main packages to FTBFS
[15:15]  * mdeslaur isn't sure how to fix it
[15:17] <Laney> 1.3 was removed from Debian. Follow suit?
[15:17] <mdeslaur> Laney: there are 115 reverse build depends on swig
[15:18] <mdeslaur> I don't know if they need to be fixed or not
[15:19] <Laney> there is a gotcha here https://bugs.launchpad.net/ubuntu/+source/swig1.3/+bug/682613/comments/5
[15:22] <SpamapS> ahasenack: yes! I will go ahead and release it today
[15:22] <mdeslaur> Laney: ouch :(
[15:22] <Laney> mdeslaur: indeed, but Debian apparently made the switch anyway …
[15:23] <mdeslaur> Laney: I guess switching is the less painful solution
[15:23] <Laney> you could revert
[15:23] <apw> when something builds for i386, that includes the any packages as well right?  or more specifically, we always do the equivalent of dpkg-buildpackage -b on i386 and -B on everything else ... right ?
[15:23] <mdeslaur> Laney: how? bump swig1.3's version to 2.0.really.1.3 or something?
[15:24] <Laney> mdeslaur: it's 2.0 that's the problem, right?
[15:24] <mdeslaur> Laney: yeah
[15:24] <Laney> oh, hm, but the swig binary will have to increase in version
[15:26] <SpamapS> ahasenack: landscape-client should show up in -updates soon
[15:26] <Laney> mdeslaur: maybe do test rebuilds and decide from there
[15:26] <SpamapS> I maintain one of those packages that is broken regarding swigh 1.3 vs 2.0 autoconf check..
[15:27] <SpamapS> swig even
[15:27] <Laney> how did Debian go ahead if it's that badly broken?
[15:27] <SpamapS> Its not swig that is badly broken, but the old autoconf rules
[15:27] <SpamapS> and because they have about 1.5 years left till release. :)
[15:27] <Laney> exposed by changing the version though?
[15:27] <Laney> the release team usually still cares about such things :-)
[15:27] <maco> 2.0~really1.3 is how im used to seeing it be done
[15:27] <SpamapS> Its a transition really..
[15:28] <Laney> +really.., but you can't do that here
[15:28] <maco> oops
[15:28] <Laney> swig1.3 needs to reclaim the swig binary package, and versions can't go backwards
[15:28] <SpamapS> The fix is fairly small.. I did it for gearman-interface already..
[15:28]  * maco is not thinking about sort rules today
[15:28] <maco> oh the number is in the name?
[15:29] <Laney> both versions were coexisting for some time, with 'swig' providing the default
[15:29] <Laney> that got switched in this accidental sync and broke stuff
[15:29] <Laney> SpamapS: you think the transition is doable?
[15:29] <SpamapS> I don't know the scope of it
[15:29] <SpamapS> For my one package, it was a small patch
[15:30] <mdeslaur> Laney: so, we remove the swig package from swig2.0, and rename swig1.3-1.3.40 to swig1.3-2.0+really1.3.40
[15:30] <mdeslaur> well, 2.0.4+really1.3.40
[15:30] <SpamapS> -  AC_PROG_SWIG(1.3.31)
[15:30] <SpamapS> +  AX_PKG_SWIG(1.3.31)
[15:30] <Laney> mdeslaur: right, revert swig2.0 to what it was before and bump swig1.3 to something >> the current version of swig2.0
[15:30] <SpamapS> And build-depend on autoconf-archive
[15:31] <SpamapS> or drop the new ax_pkg_swig.m4 in m4
[15:31] <Laney> it sounds like this would break most of the swig-using packages; I don't think we can do this unless someone volunteers to lead it
[15:32] <mdeslaur> Laney: you mean the transition? if we don't revert?
[15:32] <SpamapS> Its tough to even find them because they don't end up Depending on swig .. its a build-dep only.
[15:32] <Laney> yeah
[15:32] <Laney> SpamapS: we can determine that easily enough
[15:32] <mdeslaur> SpamapS: the "reverse-build-depends" script figures that out nicely
[15:34] <SpamapS> I knew it existed, but never went looking for it. :)
[15:34] <mdeslaur> SpamapS: it's in ubuntu-dev-tools now
[15:34] <SpamapS> OUCH.. 107
[15:35] <Laney> but like I said, I don't know how many of those are actually busted
[15:35] <SpamapS> Could we possibly do a mass rebuild *now* ... note the ones that fail, then do the reverting?
[15:35] <Laney> that would be ideal
[15:36] <mdeslaur> heck, maybe we'll get lucky and they've all been fixed already in debian :P
[15:37] <SpamapS> I know mine isn't, because I've been waiting for a sponsor. ;)
[15:37] <SpamapS> an lazy
[15:37] <SpamapS> and
[15:38] <Laney> do you have one lined up?
[15:40] <ahasenack> SpamapS: thanks! (re: landscape-client)
[15:40] <apw> u
[15:40] <czajkowski> hey just sent a message to -devel if it could be moderated I'd appreciate it, thanks.
[15:41] <apw> infinity, you'll likley know this, does i386 build -B instead of -b when there are no Arch: all packages ?
[15:41] <mdeslaur> Laney, SpamapS: so, who can do the test builds, and the fix, etc.?
[15:41] <Laney> not me I'm afraid
[15:41] <Laney> (building machine is down temporarily)
[16:15] <micahg> mdeslaur, Laney, SpamapS I would suggest dropping the swig package from 2.0 and doing the version bump on 1.3, that way packages can transition if they're ready, but might want to ask the release team as suggested to be sure
[16:15] <Laney> I'd just like the data
[16:15] <Laney> but in the absence of that to revert
[16:18] <mdeslaur> ok, I'll do it on monday if nobody gets around to it before then
[16:19] <mdeslaur> slangasek: ^ any thoughts/objections?
[16:22] <slangasek> mdeslaur: lacking context :)  -vv?
[16:23] <slangasek> ah, fake upstream version bump on swig 1.3 to restore compatibility?
[16:23] <mdeslaur> slangasek: because of the unfortunate merge, swig2.0 in universe now owns the swig package, instead of swig1.3
[16:23] <slangasek> and we don't want to just carry on and fix up the regressions this introduced?
[16:24] <mdeslaur> slangasek: well, that's the question...there are 115 reverse build deps...more info in bug 862613
[16:24] <mdeslaur> bug 682613
[16:24]  * slangasek nods
[16:24] <infinity> apw: The buildds have no way of knowing in advance if there will or won't be arch:all packages, i386 always builds with -b, and other arches always with -B
[16:25] <micahg> infinity: don't you mean the reverse?
[16:25] <infinity> mdeslaur: The transition would (in theory) be preferrable, but yeah, only if we think it's something we can commit to doing in time.
[16:25] <slangasek> mdeslaur: do we necessarily need to get swig1.3 out of the archive at the same time as fixing up the things that depend on swig?
[16:25] <slangasek> or can this be a soft transition across releases?
[16:26] <infinity> micahg: No.
[16:26] <micahg> infinity: sorry, you're right :)
[16:26] <mdeslaur> well, I don't really want to ship oneiric with 60 packages that FTBFS because of swig
[16:26] <mdeslaur> I'm the security guy, remember ;)
[16:26] <Laney> slangasek: it's because the 'swig' binary package (which provides the default) moved from 1.3 to 2.0
[16:26] <Laney> this is what most packages BD on
[16:26] <slangasek> mdeslaur: right, I was suggesting we fix up those with coordination w/ Debian; but if it's that many, yeah, probably better to revert
[16:27] <Laney> so you can't really soft transition it
[16:27] <slangasek> mdeslaur: also, swig2.0 is not migrating to testing in Debian because of two new RC bugs - so it's not considered releasable there
[16:27] <mdeslaur> either someone takes it, and does test rebuilds and fixes them, or I revert it
[16:27] <slangasek> so +1 for the mock-up version
[16:28] <mdeslaur> ok, cool. thanks slangasek, Laney, infinity, micahg
[16:28] <Laney> one of the rcbugs is this configure problem
[16:29] <Laney> (I think)
[16:30] <ryanakca> Is there an equivalent to http://snapshot.debian.org/ for Ubuntu? I'm looking for easy access to at least all binary package names of all Ubuntu releases across time, and preferably the contents of said packages across time.
[16:31] <Laney> no, but that would be cool
[16:31] <slangasek> ryanakca: not really; we let the launchpad librarian keep track of all that for us, but while there's a per-package history index, there's nothing that gives you a time-based index AFAIK
[16:32] <infinity> Yeah, even using lplib, you'd be stuck walking source package publishing histories, I imagine.
[16:34] <ryanakca> Laney: Well, I'm willing to dump the database I'll have somewhere if you'd like it.
[16:34] <ryanakca> slangasek, infinity: Thanks.
[16:35] <ryanakca> On a side note, should I ask in #launchpad before fetching all of this data?
[16:36] <infinity> If you can DoS one of our appservers with a single lplib client, we'd be curious to know about it, I imagine.
[16:37] <ryanakca> infinity: Alright ;)
[16:45] <bdmurray> stgraber: is bug 819624 fixed now?
[16:56] <Daviey> skaet: just to confirm, I am happy with the current server and cloud images for A3.
[16:56] <skaet> Daviey,  thanks!
[16:56] <stgraber> bdmurray: I think this particular one is. xubuntu still won't have working autologin but that's another lightdm bug (lightdm hardcodes "ubuntu" as the session, so won't start xfce)
[17:33] <bdmurray> slangasek: does bug 816117 seem sru'able to lucid to you?
[17:35] <slangasek> bdmurray: yes, though I think the SRU itself will clobber any local changes the user has made in lucid, so it probably should only be SRUed if there's some other change needed to the package in lucid
[17:36] <slangasek> bdmurray: I'm also surprised that he needed to edit this particular script to get his ppp working; would be best if he could file another bug report explaining why
[19:06] <Keybuk> jhunt_: I'm starting the countdown
[19:07] <jhunt_> Keybuk: ?
[19:08] <Keybuk> you've posted the notes to upstart-devel
[19:08] <Keybuk> Lennart reads upstart-devel
[19:08] <jhunt_> :)
[19:08] <Keybuk> so I'm going to time how long it takes him to reply
[19:08] <Keybuk> in his usual style, of course
[19:09] <davmor2> Keybuk: and 3.......2.........1............RANT!
[19:10] <davmor2> Keybuk: you sure it's not an auto-reply?
[19:15] <juliank> Keybuk: Everyone knows that systemd is better, so why are still working on it, just switch over, damnit! ?:)
[19:17] <Keybuk> juliank: I imagine he'll throw something like "oh, now you're going to use cgroups; why not just use systemd?" certainly
[19:17] <Keybuk> I'm not sure he'll be able to find anything in jhunt_'s mail that constitutes "a personal attack", but I'd still put money on him making that accusation in his reply
[19:18] <Keybuk> perhaps instead saying things like "after all the personal attacks from the Upstart community"
[19:18] <Keybuk> and I look forward to finding out what new obscure English word he's learned this week that he'll use repeatedly in his reply ;-)
[19:18] <juliank> "after all the personal attacks from the Upstart community, they are now copying MY ideas,"
[19:21] <Keybuk> that's not really Lennart's style
[19:33]  * jhunt_ goes to polish and oil his panoply...
[19:34] <tkamppeter> Can someone help me with building a package? I have problems on the linking step.
[19:34] <tkamppeter> It is argyll from this PPA: https://launchpad.net/~pmjdebruijn/+archive/ppa
[19:34] <tkamppeter> It builds on Natty but not on Oneiric.
[19:34] <tkamppeter> I need it to build on Oneiric to include it as part of the new Color Management support.
[19:36] <tkamppeter> Problem is probably the new Gold linker. all needed libraries are specified with "-l..." on the command line but the linking fails.\
[20:31] <ryanakca> Is there a list of source packages that have been removed from the archive?
[21:01] <ahasenack> hi guys, when does one use "+" in the version/release of a package? I'm trying to understand that
[21:01] <ahasenack> I kind of understand that something called 1.1~1234 could mean "revision 1234, working towards releasing version 1.1"
[21:01] <ahasenack> so that when 1.1 is finally released, it will upgrade any 1.1~revno
[21:01] <ahasenack> is there a similar use case for "+"?
[21:02] <ahasenack> something like "1.1+1234" which could mean "revision 1234 of the 1.1 stable branch"?
[21:02] <ahasenack> since 1.1+1234 is higher than 1.1?
[21:03] <slangasek> ahasenack: yes, 1.1+1234 sorts higher than 1.1 and lower than 1.1.1, so is generally suitable
[21:03] <micahg> ahasenack: yeah, generally, pre-release vs post-release snapshots
[21:03] <ahasenack> hmmmmm
[21:03] <ahasenack> micahg: good terminology
[21:03] <slangasek> (however, 1.1+1234 sorts higher than 1.1a, so care must be taken to not trip over upstream versioning conventions)
[21:04] <ahasenack> I was looking at how a packaging branch revision could be added to a debian version/release in a package
[21:04] <ahasenack> the recipes have this example: deb-version 1.0+{revno}-0ubuntu0+{revno:packaging}
[21:05] <ahasenack> I just hit a problem because I was only using the code revision, not the packaging revision, and the packaging branch changed and the upload failed then
[21:05] <slangasek> 0ubuntu0+{revno:packaging} would not be typical IME, but I don't see anything against it offhand
[21:05] <ahasenack> slangasek: would you have another suggestion about how to use both revision numbers in the versioning?
[21:06] <ahasenack> slangasek: considering I have one branch for the code and another branch for the debian/* parts
[21:06] <slangasek> if this isn't the authoritative branch for packaging for this work, using 0+{revno:packaging} could be ambiguous and confusing
[21:06] <slangasek> but other conventions give only incremental improvement in that regard
[21:07] <ahasenack> ok, I would need to put my stamp in there somewhere, like ~ppa is used for ppa builds
[21:07] <ScottK> Even if it is the authoritative branch, bzr revision numbers can change.
[21:07] <slangasek> right, ~ppa<serial> is more typical
[21:07] <ahasenack> or ~landscape in my case, I have seen some use that convention too
[21:07]  * slangasek nods
[21:08] <ahasenack> but in the recipe example, the packaging revision is added to the package release number, not version
[21:08] <ahasenack> is there any preference regarding that?
[21:08] <ahasenack> or, what about just concatenating both in the version? Like 1.0+{revno}+{revno:packaging}-0ubuntu0?
[21:09] <slangasek> that implies a new upstream tarball for every packaging change
[21:09] <ahasenack> ah, good point
[21:09] <ahasenack> I knew there was a reason :)
[21:09] <slangasek> 1.0+{revno}-0ubuntu0+<something> would be preferred
[21:09] <slangasek> or 1.0+{revno}-0ubuntu1~<something>
[21:09]  * Daviey write a ppa-version-o-matic in go. </jest>
[21:10] <ahasenack> so, hmm
[21:12] <ahasenack> 1.0+{revno}-0ubuntu0+{revno:packaging}~landscape1, so I have both revnos in there (and daily builds work), and the ~landscape identifier/stamp
[21:12] <ahasenack> and the recipe will still add ~<ubuntu-release>1 to all that
[21:16] <slangasek> ahasenack: it does strike me as odd to encode the bzr revno of the packaging branch in the version number, especially considering debian/changelog is conventionally maintained in the VCS so there's a bit of a circular dependency there - are you autogenerating debian/changelog?
[21:16] <ahasenack> slangasek: no, the idea is to have daily builds and when we cook up a release, then populate debian/changelog with real data
[21:17] <slangasek> ok
[21:18] <slangasek> IMHO an auto-incrementing serial is more practical for this than encoding the packaging revno
[21:19] <ahasenack> slangasek: a timestamp, then. Recipes don't have autoincrement serials
[21:20] <slangasek> oh, so these recipes are for how to construct a version that doesn't itself get committed to debian/changelog on the packaging branch
[21:20] <slangasek> so in that sense you are autogenerating :)
[21:20] <slangasek> that's perfectly ok then
[21:20] <ahasenack> slangasek: hmm, true
[21:20] <ahasenack> slangasek: I mean launchpad recipes, if that wasn't clear
[21:21] <slangasek> I'm afraid I know nothing about how launchpad recipes work
[21:22] <ahasenack> slangasek: np, it's the versioning that always confuses me, there are several policies about that. It's one thing to read the dpkg version comparison rules, but another to see how they are being used in real life
[21:23] <ahasenack> or should I say, best practices, not policies
[21:23] <slangasek> yeah :)
[21:23] <ahasenack> is there a doc about these best practices? Or just the policy manual? For example, the ~ppa suffix
[21:24] <slangasek> I don't know of any documentation anywhere about ~ppa versioning conventions
[21:24] <ahasenack> ok
[21:24] <slangasek> it might exist, but I haven't read it
[21:24] <ahasenack> I'll keep going, thanks a lot for your help
[21:24] <slangasek> sure thing :)
[21:28] <maxb> It seems to me that the ~ppa versioning convention is usually used incorrectly
[21:29] <maxb> The problem seems to be that people who don't really understand dpkg versions have seized on it as the only possible way, even to the extent of using ~ as a default separator. Which it really isn't
[21:30] <ahasenack> the idea was to make sure the ppa version was lower than the released one, thinking that the PPA can only be used for backports
[21:30] <maxb> Ah, good
[21:30] <ahasenack> is that what you mean?
[21:30] <maxb> Someone has apparently redrafted https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage to remove the ~ppa sillyness
[21:31] <ahasenack> ah, cool!
[21:31] <ahasenack> it mentions "+" :)
[21:31] <ahasenack> I will give it my full attention
[21:31] <ahasenack> maxb: thanks for that
[21:32]  * ahasenack -> away
[21:32] <maxb> Ultimately, though, there's no substitute for just thinking about the actual version comparisons yourself, rather than following recipes
[22:08] <hallyn> a package in main cam suggest a package not in main?
[22:08] <micahg> hallyn: yes
[22:09] <hallyn> thanks
[22:12] <TheMuso> oio/c
[22:30] <TheMuso> @pilot in
[22:34] <TheMuso> The joys of creating an account on a bugzilla instance for a project where I need to forward 1 bug to usptream.
[22:36] <micahg> TheMuso: if you get a chance, could you please look at bug 820773
[22:36] <TheMuso> micahg: Will make it the next thing on my list.
[22:36] <micahg> TheMuso: great, thanks
[22:37] <TheMuso> Actually, I'll do it now. I need to wait for an email for the above referred to bugzilla account.
[22:38] <micahg> k, I just was hoping it could be done before the weekend to unblock libglew transitions and FTBFS (depwait)
[22:38] <TheMuso> micahg: Sure.
[22:45] <TheMuso> micahg: Uploaded.
[23:01] <micahg> TheMuso: thanks, hopefully this time something won't break :)
[23:03] <SpamapS> hrm.. looks like something has changed to make collectd FTBFS.. last time it built was Mar 31
[23:03] <SpamapS> it can't seem to link to libperl
[23:03] <micahg> SpamapS: new version of perl?
[23:05] <SpamapS> probably
[23:08] <micahg> SpamapS: it was missed in the perl5.12 transition: http://people.canonical.com/~ubuntu-archive/transitions/perl.html
[23:10] <SpamapS> hmm
[23:12] <SpamapS> micahg: it actually doesn't end up depending on libperl.. which is .. confusing
[23:13]  * SpamapS wonders if it statically links perl
[23:14] <SpamapS> 	libperl.so.5.10 => not found
[23:14] <SpamapS> Interesting..
[23:14] <SpamapS> the "perl" plugin does in fact link to libperl
[23:15] <RAOF> SpamapS: We obviously do something special with translation-pack SRUs.  What is it?  I'd rather like to get the natty-proposed unapproved queue down below 800 :)
[23:15]  * TheMuso prods mercurial to work faster... I should have asked for more verbose output when cloning...
[23:15] <SpamapS> RAOF: no idea, I've never seen that either.. been meaning to ask pitti
[23:16] <RAOF> A perfectly timed holiday for pitti!
[23:17] <SpamapS> RAOF: I did rummage through them and find a few that weren't langpacks. :)
[23:17] <micahg> SpamapS: it deps on libperl5.10
[23:18] <RAOF> Yeah. :)
[23:21] <SpamapS> micahg: collectd-core does not
[23:22] <SpamapS> micahg: which is where the .so that depends on libperl lives
[23:22] <micahg> right, but collectd does and should've shown up on the transition page
[23:36] <SpamapS> FTBFS on Debian too
[23:36] <SpamapS> hrm
[23:36] <Keybuk> wow
[23:37] <Keybuk> since when you can strace -p 1 ?
[23:41] <broder> you...can?
[23:41] <broder> whoa
[23:41] <infinity> Not that it's usually very exciting to watch.
[23:42] <lifeless> Keybuk: meep!
[23:48] <Keybuk> it means you can go gdb -p 1 too


[07:26] <lordievader> Good morning
[10:41] <kolia> hi
[10:42] <IrcsomeBot3> <Azam Fadil-lillah> Hi
[10:42] <kolia> I've been away from Kubuntu quite a few years, and now back on the same laptop
[10:42] <kolia> however the nvidia card is not handled correctly and I have glitches
[10:42] <IrcsomeBot3> <Azam Fadil-lillah> 😅😅
[10:42] <kolia> what's the good practice nowadays to fix nividia cards?
[10:44] <kolia> it was working well few tears ago but I don't remember what I did at this time. Neither if I was using a Kubuntu 64bits already.
[10:45] <diogenes_> kolia, try to set up your rendering backend to xrender instead of opengl
[10:45] <kolia> diogenes_: thanks, googling this now
[10:46] <diogenes_> kolia, settings > hardware > display and something in ther
[10:46] <diogenes_> i forgot
[10:48] <IrcsomeBot3> <Azam Fadil-lillah> Oh.. … God … I so sorry .. … I don't know.. more
[10:48] <kolia> yep settings > monitor and display > compositor
[10:48] <diogenes_> right!
[10:49] <kolia> well, I won't shout victory yet, but glitch disappeared it seems..
[10:49] <diogenes_> log out and back and see if you get any improvements
[10:50] <kolia> i already see improvements, the weird black triangles don't appear anymore when I switch windows
[10:50] <diogenes_> then it should be fine
[10:50] <kolia> thank you very much
[10:50] <diogenes_> you're welcome
[10:50] <kolia> i thought i'd have to install some nvidia drivers
[10:51] <diogenes_> that might be a good idea too
[10:51] <kolia> that was my first try actually, found a driver on nvidia website, for linux 64 bits, for my card, but it wouldn't install correctly unfortunately
[10:52] <kolia> and I'm a bit rusty :)
[10:52] <kolia> will do for now
[10:52] <diogenes_> ok :)
[11:58] <BluesKaj> Hi folks
[13:05] <captain__> Hi all and any. Im having HP printer problems after 18.04 to 18.10 upgrade. Can some one remind me which generic print driver i can try for a Laserjet P1102W . The HP_plugin program will not load the neccisary plugin.
[13:21] <BluesKaj> captain__, have you rerun the hardware printer app in system settings, i have to ask the obvious ;-)
[13:27] <captain__> do you mean  in "Configure your Printer"   ?
[13:28] <captain__> i have deleted and re added a bunch of times in there . it sees the printer and lables it correctly
[13:28] <captain__> i just cant find a driver that will work and the HP one wont load
[13:32] <BluesKaj> captain__, try sudo modpprobe nameofdriver
[13:33] <captain__> $ sudo modprobe nameofdriver
[13:33] <captain__> modprobe: FATAL: Module nameofdriver not found in directory /lib/modules/4.18.0-13-generic
[13:38] <BluesKaj> the actual name of the driver is required
[13:40] <captain__> ive been going in to the  configure tab and selecting costom driver
[13:40] <captain__> then picking random things in Generic
[13:40] <captain__> trying to get anything to come out of the printer
[13:41] <captain__> if i chose the actual model number from the HP list
[13:41] <captain__> it tries to install its plug in and fails
[14:10] <BluesKaj> captain__, have you tried driver manager ?
[14:10] <captain__> no
[14:12] <captain__> it says "your computer requires no proprietary drivers"
[14:17] <captain__> HP-lip = unhappy user. i wish there was a laser printer i could just go buy and it would work across all my installs and OS's . im ready to make this laseprinter into a boat anchor
[14:19] <BluesKaj> caphave you tried the HP printer site for linux drivers ?
[14:20] <BluesKaj> captain__,^
[14:21] <captain__> i have
[14:22] <captain__> i removed all the old hp stuff and installed the latest hplip-3.18.12
[14:22] <captain__> in the end when i plug in the printer via usb it asks me to fire up hp-plugin
[14:23] <captain__> which downloads the driver prompts me for root and fails
[14:24] <captain__> gatherning the error it send up now
[14:26] <captain__> these are the versions im running https://www.outsideonline.com/2380751/sunscreen-sun-exposure-skin-cancer-science
[14:27] <captain__> nope not that
[14:27] <captain__> HP Linux Imaging and Printing System (ver. 3.18.12)
[14:27] <captain__> Plugin Download and Install Utility ver. 2.1
[14:29] <captain__> this time it actually verified its sig file which it rarely does
[14:29] <captain__> Verifying archive integrity... All good.
[14:30] <captain__> heres how it fails
[14:30] <captain__> QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: Permission denied
[14:30] <captain__> QFileSystemWatcher: failed to add paths: /home/captain/.config/ibus/bus
[14:30] <captain__> Bus::open: Can not get ibus-daemon's address.
[14:31] <captain__> IBusInputContext::createInputContext: no connection to ibus-daemon
[14:31] <captain__> Plugin installation failed
[14:31] <captain__> error: Python gobject/dbus may be not installed
[14:31] <captain__> error: Plug-in install failed.
[14:31] <captain__> Done.
[14:39] <BluesKaj> does this show the printer IP ? , lpstat -pPRINTER -l
[14:41] <BluesKaj> captain__,^
[14:48] <captain__> its connected via USB
[14:48] <captain__> lpstat: Invalid destination name in list "PRINTER".
[14:53] <BluesKaj> yeah, my HP inkjet works , but that command gives the same error here ...btw I can't find that ,config/bus/bus path eithe, so seems like it's looking in the wrong path
[14:53] <BluesKaj> either
[14:54] <captain__> could the path issue be  a kobuntu vs ubuntu issue?
[14:54] <BluesKaj> maybe the plugin you referred to is at fault here
[14:55] <BluesKaj> kubuntu vs ubuntu is possible
[14:56] <BluesKaj> dunno for sure since i haven't run gnome or unity DE in yrs
[14:59] <captain__> i see an /.config/ibus directory but i cant cd into it
[14:59] <captain__> ls
[15:02] <BluesKaj> I don't have /.config/ibus
[15:03] <BluesKaj> are you on ubuntu or kubuntu?
[15:04] <captain__> kubuntu
[15:05] <BluesKaj> odd
[15:07] <BluesKaj> did you install kubuntu or did you install ubuntu then remove gnome and install kde ?
[15:09] <captain__> ive never had gnome
[15:09] <captain__> its always been plasma
[15:10] <BluesKaj> ok
[15:11] <BluesKaj> well, I'm at a loss as to what to do atm...have to leave for bit , bbl
[15:12] <captain__> thanks for your help
[15:14] <IrcsomeBot3> aloneoriole was added by: aloneoriole
[15:41] <BluesKaj> oops, vpn disconnected
[15:54] <[Relic]> 18.04 (not sure if it works different in 18.10) is there some reason fstrim never shows up as working (shows disk sleep not cpu %) in ksysguard, but you can find it in top; cause frankly it is annoying to see % cpu working but not being able to see what is using it and wondering if something is locked completely slowing your computer and looking like needing a reboot
[16:15] <BluesKaj> [Relic], sudo fstrim -a ?
[16:17] <BluesKaj> or sudo fstrim / or/ home ?
[16:20] <[Relic]> not sure, it auto activates
[16:20] <[Relic]> figured it was on a weekly or # days set up but not sure where to look
[16:23] <BluesKaj> i just run it once in a while , the new ssds supposedly don't need it anymore or it's auto
[16:24] <BluesKaj> anyway, stuff to do...bbl
 C'est l'anniversaire de maman aujourd'hui ?
[16:56] <BluesKaj> q'est que c'est maman?
[16:57] <BluesKaj> UncleMez^
 ```baloo_file_extr[1557]: segfault at error 4 in libc-2.27.so``` â€¦ i have deleted libc for next reinstall, but now i only have: â€¦ ```$ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin  LC_CTYPE="en_US.UTF-8" sudo apt-get update && sudo apt-get full-upgrade && sudo apt-get dist-upgrade â€¦ [sudo] password for linecommander:  â€¦ Hit:1 http://ua.archive.ubuntu.com/ubuntu bionic InRelease                   â
[17:43] <IrcsomeBot3> http://ua.archive.ubuntu.com/ubuntu bionic-updates InRelease           … Get:3 http://security.ubuntu.com/ubuntu bionic-security InRelease [83.2 kB] … Hit:4 http://ua.archive.ubuntu.com/ubuntu bionic-backports InRelease              … Fetched 83.2 kB in 1s (87.9 kB/s)                                                 … Reading package lists... Done … Reading package lists... Done … Building dependency tree        … Reading state in
[17:43] <IrcsomeBot3> Done … Calculating upgrade... Done … The following NEW packages will be installed: …   libc-bin … 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. … Need to get 0 B/641 kB of archives. … After this operation, 3718 kB of additional disk space will be used. … Do you want to continue? [Y/n] y … perl: warning: Setting locale failed. … perl: warning: Please check that your locale settings: …         LANGUAGE = "en_
[17:43] <IrcsomeBot3> LC_ALL = "en_US.UTF-8", …         LC_TIME = "uk_UA.UTF-8", …         LC_MONETARY = "uk_UA.UTF-8", …         LC_CTYPE = "en_US.UTF-8", …         LC_ADDRESS = "uk_UA.UTF-8", …         LC_TELEPHONE = "uk_UA.UTF-8", …         LC_NAME = "uk_UA.UTF-8", …         LC_MEASUREMENT = "uk_UA.UTF-8", …         LC_IDENTIFICATION = "uk_UA.UTF-8", …         LC_NUMERIC = "uk_UA.UTF-8", …         LC_PAPER = "uk_UA.UTF-8", …         LANG =
[17:43] <IrcsomeBot3> are supported and installed on your system. … perl: warning: Falling back to the standard locale ("C"). … Can't exec "locale": No such file or directory at /usr/share/perl5/Debconf/Encoding.pm line 16. … Use of uninitialized value $Debconf::Encoding::charmap in scalar chomp at /usr/share/perl5/Debconf/Encoding.pm line 17. … dpkg: warning: 'ldconfig' not found in PATH or not executable … dpkg: error: 1 expected program not found in PA
[17:43] <IrcsomeBot3> executable … Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin … E: Sub-process /usr/bin/dpkg returned an error code (2)```
[17:55] <Roey{-> BluesKaj: hello
[17:56] <Roey{-> BluesKaj: for some reason, I can no longer see my intel sound device in KDE
[17:56] <Roey{-> or even with mp
[17:56] <Roey{-> it just falls back to the speaker in my monitor
[18:05] <BluesKaj> Roey,which audio chio?
[18:07] <BluesKaj> oh intel, ok try sudo modprobe snd-hda-intel
[18:08] <BluesKaj> you may need to reboot, if the the driver loads properly there won't be any output from that command
[18:09] <BluesKaj> it's an intel bug that's been around for years,  and I don't know why it hasn't been fixed
[23:03] <jcgsykes> hi, does anyone know how to get bluetooth headphones working? they connect fine but don't show up as an audio device, so I'm assuming no audio will come out of them
[23:05] <jcgsykes> can see that various bluetooth modules are loaded in pulseaudio but can't get any further than that. have loaded and unloaded them but doesn't do anything


[15:56] <lynxman> o/
[16:00] <hallyn> \o
[16:00] <smb> \o
[16:00] <utlemming> \o
[16:00] <jamespage> o/
[16:00] <jamespage> I'm in the chair today
[16:00] <Daviey> o/
[16:00] <Daviey> (Note, i will be largely absent this time - is someone else happy to drive the dev review?)
[16:01] <jamespage> #startmeeting
[16:01] <meetingology> Meeting started Tue Jan 31 16:01:30 2012 UTC.  The chair is jamespage. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:01] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[16:01] <jamespage> #topic Review ACTION points from previous meeting
[16:02] <Daviey> None.
[16:02] <jamespage> \o/
[16:02] <jamespage> #topic Precise Development
[16:02]  * jamespage passes the baton to Daviey
[16:03] <jamespage> (who hopefully is prepared)
[16:03] <Daviey> 16:00 < Daviey> (Note, i will be largely absent this time - is someone else happy to drive the dev  review?)
[16:04] <jamespage> lol
[16:04] <hallyn> Daviey: why don't you hand jamespae the url with the concerning bugs
[16:04] <hallyn> then i'm sure jamespage will be happy to drive
[16:04] <Daviey> http://status.qa.ubuntu.com/reports/ubuntu-server/release-bugs.html :)
[16:04] <jamespage> http://reports.qa.ubuntu.com/reports/ubuntu-server/release-bugs.html
[16:04] <Daviey> good thinking that man!
[16:04] <jamespage> So whilst we review this we need to consider that Alpha 2 is due on the 2nd Feb and Beta 1 on the 16th
[16:05] <jamespage> ticktockticktock
[16:06] <jamespage> do we really just run through these?
[16:06] <jamespage> OK so bug 883988
[16:06] <zul> its on the upstream radar
[16:06] <jamespage> zul: when is a fix expected?
[16:07] <zul> jamespage: ill bug jaypipes
[16:07] <jamespage> nice one
[16:07] <jamespage> bug 893926
[16:08] <jamespage> Guess that is still in progress
[16:08] <jamespage> bug 911812
[16:09] <jamespage> not sure if roaksoax is here...
[16:09] <adam_g> jamespage: i spoke to andres about that friday. i think that is fixed released in a number of recent releases, and should propose to lucid.
[16:09] <adam_g> not sure what he's found out, though
[16:09] <jamespage> smoser, bug 913009
[16:09] <jamespage> progress?
[16:10] <smoser> hm..
[16:10] <smoser> no, no progress.
[16:10] <jamespage> adam_g: I see bug 916992 is fixed - nice one!
[16:11] <jamespage> SpamapS, bug 914392
[16:11] <jamespage> any eta from the juju team on when that will be resolved?
[16:12] <smoser> branch is in merge queue i beleve
[16:12] <jamespage> great
[16:12] <SpamapS> jamespage: thats got a fix upstream in a branch, ready for testing
[16:12] <jamespage> adam_g: bug 922232 - I see that there is a fixed proposed upstream
[16:13] <Ursinha> what's the importance of this bug?
[16:13] <adam_g> jamespage: yeah, didnt realize a QA bot had tagged it failing a unit test, pushed a second rev. last night.
[16:13] <adam_g> Ursinha: the tgt bug? high, i'd say
[16:13] <Ursinha> adam_g, may I set it?
[16:14] <adam_g> Ursinha: sure.
[16:14] <Ursinha> oh, I can't :)
[16:14] <adam_g> i thought i did for the ubuntu task
[16:14] <jamespage> adam_g: you did - thats fine
[16:14] <jamespage> we can't set the upstream task importance which is fair enough
[16:15] <Ursinha> that's fine
[16:15] <Ursinha> so the downstream is in progress
[16:15] <jamespage> Ok; bug 923681
[16:16] <jamespage> interesting that the automated testing has not picked that up because it uses tasksel (albeit through preseeds).
[16:17] <jamespage> bug 875262;
[16:18] <jamespage> currently assigned to koolhead17
[16:18] <jamespage> ..
[16:18] <SpamapS> he's been working on it
[16:18] <SpamapS> I've been helping him when I can
[16:19] <jamespage> SpamapS, think that will make alpha-2?
[16:20] <Daviey> SpamapS: Can you clarify what is holding it up?
[16:21] <jamespage> OK; lets come back to that if/when
[16:21] <jamespage> bug 890362
[16:22] <jamespage> adam_g, zul: any thoughts on this one? It would nice to land something for alpha-2
[16:22] <zul> james: yeah its on my todo list
[16:22] <jamespage> great
[16:23] <SpamapS> Sorry I had something here distracting me
[16:23] <jamespage> np
[16:23] <jamespage> any feedback?
[16:23] <SpamapS> Whats holding it up is that koolhead17 is new to packaging, and needs guidance, and is in a very incompatible time zone with me.
[16:23] <arosales> zul, do you think 890362 will make alpha 2?
[16:24] <SpamapS> We also need to merge PHP 5.3.9 .. but thats not going to make alpha-2
[16:24] <jamespage> SpamapS, ack - I think Daviey and I are more compatible timewise...
[16:24] <zul> arosales: probably i was going to do some work on it this afternoon
[16:24] <jamespage> so feel free to point him in our direction
[16:24] <arosales> zul: ok, thanks.
[16:25] <jamespage> roaksoax has been working on bug 898840
[16:26] <SpamapS> jamespage: he's in India
[16:26] <SpamapS> jamespage: but I think he can work on this stuff only after working hours, which should fall into your TZ
[16:26] <jamespage> great
[16:26] <jamespage> I thought you mean't roaksoax for a minute then
[16:27] <jamespage> I guess bug 898840 won't make alpha-2
[16:27] <jamespage> I believe bug 904681 is now fixed
[16:28] <jamespage> test when green today in jenkins
[16:28] <jamespage> https://jenkins.qa.ubuntu.com/view/Precise%20ISO%20Testing%20Dashboard/view/Daily/job/precise-server-amd64_minimal-virtual/79/
[16:28] <hallyn> that'd be grrreat
[16:28] <jamespage> wonders what we actually did to fix it....
[16:29] <jamespage> bug 906654 is not currently milestone targetted
[16:29] <adam_g> jamespage: i think that will eventually be marked invalid, the openstackx library is to be deprecated and removed from openstack entirely this cycle
[16:29] <jamespage> adam_g, zul - any thoughts on this and when/if it might happen
[16:30] <jamespage> adam_g: good
[16:30] <jamespage> pls can you comment to that effect.
[16:30] <zul> jamespage: i think openstackx i sbeing dropped so i need to doubleechk
[16:30] <adam_g> jamespage: happening soon if not already
[16:30] <jamespage> adam_g, zul: same with bug 907197
[16:31] <zul> jamespage: still havent reproduced it
[16:31] <jamespage> zul: ack
[16:31] <jamespage> rbasak, around? care to update on bug 879666
[16:32] <rbasak> I will update the patch for oneiric-updates
[16:32] <rbasak> but the patch isn't present in precise atm
[16:32] <rbasak> so can't complete the SRU justification
[16:32] <rbasak> Was speaking to Daviey about this earlier
[16:32] <rbasak> I think he wants the patch taken into precise too
[16:32] <jamespage> OK
[16:33] <Daviey> zul: Please re-introduce that patch to precise.
[16:33] <zul> ack
[16:33] <jamespage> lynxman was working on bug 916489
[16:33] <jamespage> which needs a new upstream release of ipxe
[16:33] <jamespage> but I know he's short on time for this now
[16:34] <lynxman> jamespage: unfortunately my management requires my attention elsewhere, new release is almost ready
[16:34] <jamespage> Daviey: still key that makes alpha-2?
[16:34] <lynxman> jamespage: I reckon tops weekend will be here
[16:35] <Daviey> jamespage: no, it can wait
[16:35] <Daviey> I thought we were just waiting on the version string resolution?
[16:36] <jamespage> bug 833499
[16:36] <jamespage> looks like we have a workaround for the moment
[16:37] <jamespage> zul, smoser: is that getting any upstream focus in esses?
[16:37] <smoser> probably not.
[16:37] <zul> still on my neverending todo list
[16:38] <jamespage> zul: is bug 901881 there as well?
[16:39] <zul> jamespage: keystone is in transition right now so that is in limbo kind of
[16:39] <jamespage> right - I understand
[16:39] <jamespage> so not in the short term then
[16:39] <zul> no...
[16:39] <jamespage> rbasak, hows OpenMPI looking (bug 889644)
[16:39] <rbasak> it's built in a ppa now
[16:40] <rbasak> next step is to try building its dependencies against it
[16:40] <rbasak> debian armel ftbfs, but ubuntu is ok
[16:40] <Daviey> neat
[16:40] <jamespage> rbasak, likely to land for beta-1?
[16:41] <Daviey> rbasak: Depends on the testing of rdepends, rebuild right?
[16:41] <rbasak> yep
[16:42] <rbasak> if it works then we can get it in the archive straight away
[16:42] <rbasak> Holdups will depend on any bugs
[16:42] <jamespage> OK bug 907206
[16:42] <jamespage> nearly there how
[16:42] <zul> will be uploaded friday
[16:42] <jamespage> zul: sweet
[16:43] <jamespage> bug 887186 and bug 891977 for roaksoax; hopefully he's on those
[16:43] <Daviey> I merged that a few days ago
[16:43] <jamespage> adam_g: bug 923817
[16:44] <adam_g> jamespage: fix proposed, waiting on a +1 our openstack packaging
[16:44] <jamespage> readhy for review I see - friday zul?
[16:44] <zul> yeah
[16:44] <jamespage> nice
[16:45] <jamespage> So I won;t go through the other teams list; but we probably what to add the MIR's for juju to the list for tracking in precise
[16:45] <jamespage> #action jamespage to get juju MIR's added to server precise release tracking
[16:45] <meetingology> ACTION: jamespage to get juju MIR's added to server precise release tracking
[16:45] <jamespage> #topic Ubuntu Server Team Events
[16:46] <jamespage> rbasak, Daviey and I at FOSDEM this weekend
[16:46] <Daviey> Right!
[16:46] <jamespage> \o/
[16:46] <jamespage> any other events?
[16:46] <jamespage> nope
[16:46] <jamespage> #topic Weekly Updates & Questions for the QA Team (hggdh)
[16:46] <jamespage> hggdh: around?
[16:46] <hggdh> yep
[16:47] <SpamapS> WAIT
[16:47] <SpamapS> events
[16:47]  * jamespage rewinds the tape
[16:47] <SpamapS> https://juju.ubuntu.com/Events
[16:47] <jamespage> #link https://juju.ubuntu.com/Events
[16:47] <SpamapS> Tomorrow, Mark Mims and David Medberry will be at MongoDB Boulder to talk about juju
[16:48] <SpamapS> And at the end of the month, juju will be at Strata
[16:48] <SpamapS> that is all
[16:48] <jamespage> ta
[16:48] <jamespage> hggdh?
[16:48] <hggdh> Alpha is in, folks. As much test as possible will be appreciated. We are looking good, though, so far :-)
[16:48] <hggdh> and this is it, right now
[16:48] <hggdh> ..
[16:48] <jamespage> I noted that the ISO testing dashboard was looking sweet for server :-)
[16:48] <jamespage> #topic Weekly Updates & Questions for the Kernel Team (smb)
[16:48] <smb> Random list of things I was involved at least as part of the problem, not
[16:48] <smb> necessarily, yet, part of the solution:
[16:48] <smb> * bug 923685
[16:48] <smb> * bug 922754
[16:48] <hggdh> yes... isn't life good?
[16:48] <smb> * bug 824089 and bug 913760
[16:48] <smb> * bug 922137
[16:48] <smb> * bug 922486
[16:48] <smb> * bug 921816
[16:49] <smb> Over to smoser for more... ;)
[16:49] <Daviey> jamespage: (MIR bugs added.)
[16:49] <jamespage> Daviey: ta
[16:49] <smb> ..
[16:49] <smoser> i dont have anything specific for smb at the moment.
[16:49] <Daviey> bug 922754 is one for jodh i think
[16:50] <smb> Daviey, He is on it
[16:50] <jamespage> I'm sure he will love that :-)
[16:50] <jamespage> #topic Weekly Updates & Questions regarding Ubuntu ARM Server (rbasak)
[16:50] <jamespage> how is arm server looking rbasak
[16:50] <Daviey> I thought it was fixed now TBH
[16:50] <roaksoax> smb where u abl
[16:50] <rbasak> The kernel is fixed now
[16:50] <jamespage> \o/
[16:50] <rbasak> juju is working in a local environment too!
[16:50] <jamespage> (I can re-install again!)
[16:50] <SpamapS> /o/
[16:50] <rbasak> I'm not sure that the installer is carrying the latest kernel
[16:50] <smb> roaksoax, abl 2 do what? :)
[16:51] <rbasak> But you can use the latest kernel image and the installer will work
[16:51] <Daviey> rocking!
[16:51] <jamespage> any questions for robbiew?
[16:51] <robbiew> hey
[16:51] <jamespage> sorry that should be rbasak
[16:51] <jamespage> doh!
[16:51] <robbiew> lol
[16:52] <roaksoax> smb where able to resolvr yhe orchestra/squid issue u were having?
[16:52] <jamespage> nope - great
[16:52] <jamespage> #topic Open Discussion and Community
[16:53] <SpamapS> Wait, "and Community" ?
[16:53] <jamespage> Anyone got anything they would like to discuss?
[16:53] <SpamapS> did we miss the point of removing the "Community" section?
[16:53] <robbiew> FeatureFreeze is Feb16th :)
[16:53] <SpamapS> *the entire meeting is about the community*
[16:53] <robbiew> justsayn
[16:53] <smb> roaksoax, currently running mostly without proxy enabled. as I try to use apt-cacher-ng as proxy which seems to be flakey with precise. but the complete strange fails seem to have disappeared
[16:53] <robbiew> SpamapS: I expect we'll need an FFS for juju stuff
[16:53] <robbiew> ...and maas <- Daviey
[16:54] <Daviey> robbiew: I have lots of FFF's
[16:54] <jamespage> SpamapS, you are quite correct
[16:54] <Daviey> FFS*
[16:54] <robbiew> \o/
[16:54] <roaksoax> smb ok ;) then it was cache issue or even archive
[16:54] <jamespage> #topic Open Discussion
[16:54] <SpamapS> jamespage: ty.. lets fix the agenda for the next meeting too
[16:54] <jamespage> SpamapS, agreed - will do that when I write the minutes
[16:55]  * jamespage pokes Daviey
[16:55] <Daviey> right!
[16:55] <SpamapS> I promise I'll do an extra 2 or 3 turns as moderator once daylight savings time returns
[16:55] <jamespage> lol
[16:56] <jamespage> so if thats all folks...
[16:56] <jamespage> #Announce next meeting date and time
[16:56] <jamespage> 1600UTC on 7th Feb
[16:56] <jamespage> until next week
[16:56] <jamespage> #endmeeting
[16:56] <meetingology> Meeting ended Tue Jan 31 16:56:52 2012 UTC.
[16:56] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-01-31-16.01.moin.txt
[16:56] <SpamapS> jamespage: thanks!
[16:56] <Ursinha> thanks jamespage
[16:57] <arosales> thanks jamespage
[16:59] <jsalisbury> Roll Call for Ubuntu Kernel Weekly Status Meeting
[16:59] <apw> o/
[16:59] <sforshee> o/
[16:59] <cking> o/
[16:59] <tgardner> o/
[16:59] <bjf> o/
[16:59] <herton> o/
[16:59] <arges> o/
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> ##
[17:00] <meetingology> Meeting started Tue Jan 31 17:00:13 2012 UTC.  The chair is jsalisbury. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[17:00] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[17:00] <jsalisbury> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Precise
[17:00] <smb> \o
[17:00] <ppisati> o/
[17:00] <jsalisbury> [TOPIC] ARM Status (ppisati)
[17:00] <ppisati> P/omap4: a new kernel version (1405.7) was released, with improved PM support and fixes for the usb subsystem (CMA revert).
[17:00] <ppisati> P/master: problems with mmc were due to twl4030's GPIO lines being inactive at boot time since support was factored out in a kernel module; recompiling it in the main kernel made omap3 boards boot off the mmc again (12.20).
[17:01] <ppisati> SRU: new kernels were released for every supported arch/release.
[17:01] <ppisati> ..
[17:01] <jsalisbury> [TOPIC] Release Metrics and Incoming Bugs (jsalisbury)
[17:01] <jsalisbury> Release metrics and incoming bug data can be reviewed at the following link:
[17:01] <jsalisbury> [LINK] http://people.canonical.com/~kernel/reports/kt-meeting.txt
[17:01] <jsalisbury> ..
[17:01] <jsalisbury> [TOPIC] Milestone Targeted Work Items (ogasawara)
[17:02] <ogasawara> [LINK] http://status.ubuntu.com/ubuntu-precise/canonical-kernel-distro-team-precise-alpha-2.html
[17:02] <ogasawara> I've pushed out any open work items from Alpha-2 to Beta-1.
[17:02] <ogasawara> Additionally, some work items have come to my attention but I'm unaware
[17:02] <ogasawara> of anyone from our team actually working on them:
[17:02] <ogasawara> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-ceph
[17:02] <ogasawara> [canonical-kernel-team] investigate large xattr support patch from Ted T'so in ext4: TODO
[17:02] <ogasawara> [canonical-kernel-team] potentially help push large xattr support to ext4: TODO
[17:02] <ogasawara> Did anyone attend that session at UDS and commit us to those work items?
[17:02] <ogasawara> I suspect these may just get postponed.
[17:02] <apw> those were for the cluster filesystem thing
[17:03] <apw> for use in openstack iirc
[17:03] <apw> ..
[17:03] <ogasawara> k, i'll follow up and see if I can find out more.
[17:03] <ogasawara> Also, https://blueprints.launchpad.net/ubuntu/+spec/ubuntu-arm-p-optional-initrd
[17:03] <ogasawara> [canonical-kernel-team] provide a kernel with uuid support in the internal initrd for measuring
[17:03] <ogasawara> I vaguely recall there were discussions regarding this work item at the
[17:03] <ogasawara> rally, but I'm unaware of what the outcome was?
[17:05] <tgardner> oagdunno where that one is. I think ogra was gonna do some testing
[17:05] <tgardner> ogasawara, ^
[17:05] <ogasawara> ack
[17:05] <ogasawara> ..
[17:05] <tgardner> punted...
[17:05] <ogra_> tgardner, well, the foundations WIs were all postponed/blocked yesterday
[17:06] <ogasawara> ogra_: blocked on the above work item?
[17:06] <ogra_> i can indeed do a test of with/without initrd, but that wont tell anything about with/with minimal initrd in kernel
[17:06] <ogra_> ogasawara, yes
[17:06] <ogra_> but i cant speak for slangasek :)
[17:06] <tgardner> ogra_, but don't we have an option to generate a minimal initrd now ?
[17:07] <ogra_> he set his items to blocked
[17:07] <ogra_> wrt my item i can easily provide you with data tomorrow if that helps anyone
[17:07] <tgardner> ogra_, I think those would be interesting numbers.
[17:08] <ogra_> tgardner, i dont think so ... when i said minimal i meant the in-kernel initrd just containing teh blkid command as we had discussed
[17:08] <ogra_> though i think slangasek would even like to see that done in-kernel with a patch (which i think you already said is to intrusive)
[17:09] <apw> ogra_, probabally we should discuss a plan for this feature offline, we are clearly confused on who is doing what when in which order
[17:09] <ogra_> apw, k
[17:09] <slangasek> tgardner: FSVO "minimal" that always includes udev and sundry other utilities
[17:09] <ogra_> slangasek, not necessarily, thats why we have devtmpfs, no ?
[17:09] <tgardner> slangasek, I guess I was referring to the "tailored" initrd so taht we could see if there was _any_ time differences
[17:10] <slangasek> there is no support for generating any genuinely minimal initramfs out of initramfs-tools
[17:10] <ogra_> right, it will always be bloated and at least contain both libc's
[17:12] <tgardner> ..
[17:12] <apw> we'll discuss it offline ..
[17:12] <jsalisbury> Everyone OK with moving on?
[17:12] <ogra_> ..
[17:12] <jsalisbury> [TOPIC] Blueprint: hardware-p-kernel-power-management (cking)
[17:12] <cking> nothing to report this week
[17:12] <cking> ..
[17:12] <jsalisbury> [TOPIC] Status: Precise Development Kernel (ogasawara)
[17:12] <ogasawara> Last week we rebased to v3.2.2 and uploaded.  There is a potential
[17:12] <ogasawara> regression in v3.2.2 that I'm concerned about, bug 923512.  jsalisbury
[17:12] <ogasawara> is working with the bug reporters and has a test kernel with the
[17:12] <ogasawara> offending patch reverted.  If anyone else has hw which uses the ath9k
[17:12] <ogasawara> driver, it would be nice if you could test.  I'd consider this would
[17:12] <ogasawara> warrent an upload to fix before the milestone which is in 2 days, Thurs
[17:12] <ogasawara> Feb 2.  This means we'd likely have to upload by end of day today.
[17:12] <ogasawara> ..
[17:13] <jsalisbury> [TOPIC] Status: CVE's (apw)
[17:14] <apw>
[17:14] <apw> [LINK] http://people.canonical.com/~kernel/cve/pkg/CVE-linux.txt
[17:14] <apw>
[17:14] <apw> Currently open CVEs for each supported branch:
[17:14] <apw>
[17:14] <apw> || Package                                  || Open      || Defd ||
[17:14] <apw> ||                                          ||           ||      ||
[17:14] <apw> || linux Hardy                              ||   20 (+3) ||    8 ||
[17:14] <apw> || linux Lucid                              ||   14 (+2) ||    5 ||
[17:14] <apw> || linux Maverick                           ||   14 (+3) ||    5 ||
[17:14] <apw> || linux Natty                              ||   13 (+3) ||    5 ||
[17:14] <apw> || linux Oneiric                            ||   10 (+1) ||    5 ||
[17:14] <apw> || linux Precise                            ||    7      ||    5 ||
[17:14] <apw> || linux-ec2 Lucid                          ||   14 (+2) ||    5 ||
[17:14] <apw> || linux-fsl-imx51 Lucid                    ||   14 (+3) ||    4 ||
[17:14] <apw> || linux-mvl-dove Lucid                     ||    0 (-9) ||    0 ||
[17:14] <apw> || linux-mvl-dove Maverick                  ||   10 (+1) ||    4 ||
[17:14] <apw> || linux-ti-omap4 Maverick                  ||   15 (+3) ||    4 ||
[17:14] <apw> || linux-ti-omap4 Natty                     ||   12 (+5) ||    4 ||
[17:14] <apw> || linux-ti-omap4 Oneiric                   ||    7 (+1) ||    4 ||
[17:14] <apw> || linux-ti-omap4 Precise                   ||    5      ||    4 ||
[17:14] <apw> || linux-lts-backport-maverick Lucid        ||   14 (+3) ||    5 ||
[17:14] <apw> || linux-lts-backport-natty Lucid           ||   13 (+3) ||    5 ||
[17:14] <apw> || linux-lts-backport-oneiric Lucid         ||   10 (+1) ||    5 ||
[17:14] <apw>
[17:14] <apw> Note that the table has a new column this week, the "Defd" column
[17:14] <apw> represents the number of CVEs which have been referred back to security for
[17:14] <apw> resoution, either for lack of a fix or if the fix is not clearly complete.
[17:14] <apw>
[17:14] <apw> Nine new CVEs were added this week, of which about 6 have been resolved.
[17:14] <apw> We have also finally dropped lucid/mvl-dove from the table above.
[17:14] <apw>
[17:14] <apw> ..
[17:14] <jsalisbury> [TOPIC] Status: Stable, Security, and Bugfix Kernel Updates - Oneiric/Natty/Maverick/Lucid/Hardy (bjf/herton)
[17:15] <bjf> Here is the status for the main kernels, until today (Jan. 24):
[17:15] <bjf>
[17:15] <bjf>  * Hardy - 2.6.24-30.98
[17:15] <bjf>   * Nothing new this cycle.
[17:15] <bjf>
[17:15] <bjf>  * Lucid - 2.6.32-38.85
[17:15] <bjf>   * Proposed is frozen due to 10.04.4 prep.
[17:15] <bjf>
[17:15] <bjf>  * Maverick - 2.6.35-32.65
[17:15] <bjf>   * Verification testing.
[17:15] <bjf>
[17:15] <bjf>  * Natty - 2.6.38-13.55
[17:15] <bjf>   * Verification testing.
[17:15] <bjf>
[17:15] <bjf>  * Oneiric - 3.0.0-16.27
[17:15] <bjf>   * Verification testing.
[17:15] <bjf>
[17:15] <bjf> Current opened tracking bugs details:
[17:15] <bjf>  * http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html
[17:15] <bjf>
[17:15] <bjf> For SRUs, SRU report is a good source of information:
[17:15] <bjf>  * http://people.canonical.com/~kernel/reports/sru-report.html
[17:15] <bjf>
[17:15] <bjf> Future stable cadence cycles:
[17:15] <bjf>  * https://wiki.ubuntu.com/PrecisePangolin/ReleaseInterlock
[17:15] <bjf> ..
[17:15] <jsalisbury> [TOPIC] Open Discussion or Questions? Raise your hand to be recognized (o/)
[17:16] <jsalisbury> OK, Thanks everyone
[17:16] <apw> jsalisbury, thanks
[17:16] <jsalisbury> #endmeeting
[17:16] <meetingology> Meeting ended Tue Jan 31 17:16:26 2012 UTC.
[17:16] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-01-31-17.00.moin.txt


 But will it keep PulseAudio for fallback purposes? Or deprecate it straight away?
 well pipewire is based on pulse (re @VitalKanev: But will it keep PulseAudio for fallback purposes? Or deprecate it straight away?)
 really, thought pipewire was something new built from scratch
 https://archlinux.org/packages/extra/x86_64/pipewire-pulse/ (re @philipz: really, thought pipewire was something new built from scratch)
 Install pipewire-pulse. It will replace pulseaudio and pulseaudio-bluetooth. https://wiki.archlinux.org/title/PipeWire#PulseAudio_clients
 ah alright
 Server Name: PulseAudio (on PipeWire 0.3.16)
 that confuses me tough
 think its still fully compatible with pulseaudio and alsa things
 would have to be if it intends to be the new base system for all A/V, as most apps won't be ported to its framework.
 ah true
[17:50] <teward> *prods the bot*
 good its still working
 sorry i restarted it :)
 does it often need to be restarted?
[17:52] <teward> nope, it got restarted 'cause i changed the nick to match the cloak
[17:52] <teward> ubuntuTGbot -> ubuntubridgebot  (with an ubuntu/bot/ cloak on the IRC side)


 Is that correct? And if so, how?
[10:31] <mpt> e.g. opening a document from the file manager, or a music player from the sound menu
[10:32] <tvoss> mpt, right, although we haven't implemented user feedback, yet. But in theory, it would solve the issue
[10:36] <mpt> tvoss, is the feedback design specified somewhere?
[10:37] <tvoss> mpt, I don't think so, surely not for the desktop use-case
[10:38] <mpt> tvoss, a job for katie then perhaps?
[10:38] <tvoss> mpt, yup, I would think that you will be involved, too :)
[12:13] <dednick> Cimi: ping
[12:16] <dednick> Cimi: looks like that test issue with ubuntu-settings-components is a qt bug. I've filed a bug with them, skipped the test for now and added a TODO for when it is fixed.
[12:44] <dandrader> Mirv, I'm at a loss on how to proceed with https://bugs.launchpad.net/bugs/1258057
[12:44] <dandrader> Mirv, any suggestions?
[12:50] <Mirv> dandrader: so qt5-beta2 PPA + git snapshot of qt declarative (and only qt declarative) works? then maybe the snapshot would be worth considering indeed. it just adds to the uncertainty, but if we already know there's a component that's broken in a sense (qt declarative), then I guess it wouldn't do more harm.
[12:50] <Mirv> and yes it's a stable branch, but sometimes indeed the minor stable releases aren't that minor either
[12:51] <dandrader> Mirv, yes (assuming qt5-beta2 PPA is essentially git tag v5.2.0)
[12:52] <dandrader> Mirv, problem is: 1 - there isn't a single commit to cherry-pick that fixes it. we need to bring in a number of commits
[12:52] <dandrader> Mirv, 2 - it fixes the testLauncher crash but causes testApplication to fail
[12:54] <dandrader> Mirv, so, taking in the latest qtdeclarative stable branch improves our situation (moving from a crash to a failure) but doesn't completely solve it
[12:55] <dandrader> Mirv, to a course of action could be taking qtdeclarative stable branch an filing a qtbug on that failure, which looks like a regression regarding qobject enums not visible on the qml side
[12:56] <dandrader> s/to a/so a
[12:56] <dandrader> but then, we don't know what other problems or regressions might come along that newer qtdeclarative, as you said...
[12:59] <Mirv> dandrader: yeah or it's still ~rc since I'm rebuilding all final releases in qt5-daily at the moment. but yes I'd consider failure better than a crasher, so it's at least worth considering, but I'll concentrate on rebuilding all of final releases now first (and rebuilding everything against them, then)
[12:59] <Mirv> there's of course a chance that unity-api would behave slightly differently also with the final release vs. the release candidate in rc2, so worth checking first
[13:00] <greyback> hi ho
[14:31] <tsdgeos> dednick|lunch: standup?
[14:31] <tsdgeos> mzanetti: ↑↑
[14:32] <tvoss> Saviq, ping
[14:32] <mzanetti> tedg: sorry... trashed my PC
[14:32] <mzanetti> will try to join asap
[14:33] <mzanetti> tsdgeos: ^^
[14:33] <tsdgeos> ok
[14:33] <tsdgeos> tvoss: he's out today
[14:33] <tvoss> tsdgeos, ack and thx
[14:36] <tsdgeos> mzanetti: we're done i guess you can fill in your notes and just shout here if it's something that you need us to act on
[14:37] <dednick|lunch> doh. missed it
[14:38] <tsdgeos> dednick: same applies to you :-)
[14:38] <dednick> tsdgeos: yep. wil do
[14:40] <mzanetti> tsdgeos: yeah... nothing really. I've just been working on the right edge with unfortunately very little progress so far today.
[14:40] <tsdgeos> ok :-)
[14:40] <mzanetti> have been following the wrong approach and had to go back one step
[14:44] <dednick> Is Cimi not in today?
[16:45] <jn> anybody?
[16:45] <jn> how to reinstall unity after installing gnome.
[16:45] <jn> ?
[16:46] <dandrader> tsdgeos, so VerticalJournal.horizontalSpacing is indeed different than Grid.columnSpacing?
[16:46] <tsdgeos> is the horizontal spacing
[16:47] <tsdgeos> both between columns and between the borders of the item
[16:47] <tsdgeos> being a minimum bound at the right side of course
[16:47] <dandrader> tsdgeos, that must be documented
[16:48] <tsdgeos> what other thing can it be?
[16:48] <dandrader> tsdgeos, I would expect it to be like Grid.columnSpacing
[16:48] <tsdgeos> well, but it's not called columnSpacing :D
[16:49] <dandrader> tsdgeos, so your horizontalSpacing is like a margin
[16:49] <tsdgeos> dandrader: so you'd prefer stuff to start x=0 instead of x=horizontalSpacing
[16:49] <tsdgeos> i understand?
[16:50] <dandrader> tsdgeos, I prefer to have the meaning of that property documented to avoid ambiguities and misunderstandings
[16:50] <tsdgeos> that's not the answer i want :D
[16:50] <tsdgeos> i am asking API wise
[16:51] <tsdgeos> do you think it makes more sense for it to be what i say or not
[16:51] <tsdgeos> we're trying to make this good
[16:51] <tsdgeos> so i'm asking what you think makes more sense
[16:51] <dandrader> tsdgeos, I would prefer s/horizontalSpacing/columnSpacing
[16:51] <dandrader> tsdgeos, that margin can be done via other means
[16:52] <dandrader> tsdgeos, yield more flexibility to the layout
[16:52] <dandrader> tsdgeos, you use Item's native margin properties to achieve that spacing between the edge columns and the item borders
[16:54] <dandrader> tsdgeos, and also mimicking an existing API (Qt's Grid) has the added benefit of having the overall API more uniform and fit better together
[16:54] <dandrader> tsdgeos, A developer used to work with Grid will have a much lower learning curve if his existing API expectations can be directly transfered when working with VerticalJournal
[16:58] <tsdgeos> dandrader: ok, can you please add that comment to the review?
[16:58] <tsdgeos> will need to change it for vSpacing too
[16:59] <dandrader> tsdgeos, ok
[17:05] <tsdgeos> thanks :-)
[17:08] <tsdgeos> dandrader: as for the tryFoo
[17:08] <tsdgeos> we dont' support what you envision :D
[17:09] <tsdgeos> you can't remove items from the middle
[17:09] <tsdgeos> this only works with static models
[17:09] <tsdgeos> you can make it grow
[17:09] <tsdgeos> because that's kind of static
[17:09] <tsdgeos> but that's all
[17:10] <tsdgeos> or shrink from the end
[17:13] <tsdgeos> dandrader: that ok?
[17:15] <dandrader> tsdgeos, didn't get the "static model" explanation but, anyway, you can still push and pop (like in a stack), right?
[17:16] <dandrader> tsdgeos, if so, the tryVerticalJournal still makes sense
[17:16] <tsdgeos> dandrader: basically we don't support removing from the model
[17:16] <tsdgeos> errr
[17:16] <tsdgeos> model/middle
[17:16] <tsdgeos> you can add stuff at the end and remove from the end
[17:17] <tsdgeos> and that's it
[17:17] <tsdgeos> but sure i am not saying it does not make sense
[17:17] <tsdgeos> i'm just setting your expectations
[17:17] <tsdgeos> that said
[17:17] <tsdgeos> EOD-time
[17:17] <tsdgeos> tty tomorro
[17:17] <tsdgeos> w
[20:49] <tedg> greyback, Hey, so doing more timing tests.
[20:49] <tedg> greyback, It seems that the observer for the starting signal is taking 63ms inside the unity codebase (dbus overhead stripped)
[20:50] <tedg> greyback, Is that expected?  Seems like a while.
[21:01] <kgunn> veebers: hey, hope you're well...just wanted to point out...this one is makin' the news
[21:01] <kgunn> https://bugs.launchpad.net/unity8/+bug/1260860
[21:02] <kgunn> causing random failures on maguro...can you treat with priority ?
[21:05] <veebers> Hi kgunn, I'm currently on vacation so time in front of my laptop is spotty. I should be able to look at this morning if it's priority though. Should be easy enough to fix for any dev though
[21:05] <kgunn> veebers: ack, are you off for christmas ?
[21:06] <veebers> kgunn: aye, off until Jan 6th


[00:00] <skaet> GrueMaster,  can you please open a bug, so we can reference it?
[00:01] <skaet> :)
[00:01] <GrueMaster> Will do (once I figure out a few other more pressing issues).
[00:01] <stgraber> GrueMaster, skaet: one already exists
[00:02] <stgraber> https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/892394
[00:02] <ubot4> Launchpad bug 892394 in unity-greeter (Ubuntu) "Greeter logo needs to be updated for 12.04 (affects: 2) (dups: 1) (heat: 16)" [Medium,Triaged]
[00:02] <GrueMaster> thanks stgraber.
[00:02] <skaet> stgraber,  just heard about it from robert-ansell as well.  you're faster this time.  :)
[00:02] <stgraber> hehe
[00:03]  * skaet --> heading for dinner, back later
[00:03]  * GrueMaster adds the but to the armel images on the shiny new iso tracker.
[00:03] <GrueMaster> bug
[00:05] <GrueMaster> This bug is old.  Surprised it wasn't updated before A1.
[00:06] <stgraber> yeah, really weird as it's an easy one (just a .png to update, took me a good 2 minutes for Edubuntu) and Robert commented on the bug (though only recently)
[00:06] <GrueMaster> I could have fixed it, and I am not artistic by nature.
[02:02]  * skaet not seeing any blockers so far on the iso tracker,  calling it an evening.
[02:36] <ScottL> stgraber, are you the person i would talk to about which test cases are being shown for ubuntu studio on the qa tracker?
[02:37] <ScottL> also, do you know who i would talk to about editing the instructions for the test cases?
[02:39] <ScottL> the first sentence is referencing the 'entire disc with encryption'
[02:40] <ScottL> the second sentence references the link from http://<IP_ADDRESS>/qatracker/milestones/205/builds/7263/testcases goes to http://testcases.qa.ubuntu.com/Install/AlternateResize, which doesn't mention jackd 'real time previliges'
[02:44] <stgraber> ScottL: I can do changes on the tracker (rename/change testcases and make them point somewhere else), though it's probably best to talk to jibel about it as he's coordinating the testing and knows more about the right way of doing things :)
[02:45] <stgraber> and jibel has the same rights as I do
[02:50] <stgraber> oh, fun, looks like we just got a new empathy (new major version)...
[02:54] <micahg> stgraber: I think we have to go back to grilling people about freezes in DMB meetings :)
[02:55] <stgraber> micahg: yeah, that sounds like a useful thing to do ;)
[02:55] <micahg> fortunately, it can't build since it requires clutter-gst
[02:55]  * stgraber waits for someone to upload a new clutter-gst still during the freeze
[02:56] <micahg> stgraber: not seeded, doesn't matter
[02:57] <stgraber> ah, it build-deps on something new that needs to be promoted?
[02:57] <micahg> stgraber: worse, build deps on something we said we wouldn't promote :)
[02:57] <stgraber> hmm, ok :)
[02:58] <stgraber> Maybe we should send a friendly reminder for people to subscribe and READ ubuntu-devel-announce?
[02:59] <stgraber> it's not really high traffic and should be a must subscribe for anyone with upload rights
[02:59] <micahg> really, I think ubuntu-devel should be required reading for devs with upload rights, but certainly ubuntu-devel-announce at a minimum
[03:01] <stgraber> ubuntu-devel can be high traffic at times, you should at least know what threads are going on and ignore these you aren't interested in, but -announce should definitely be a must read
[03:03] <stgraber> I guess I'll add that to be before-voting list of questions :) "are you subscribed and do you read ubuntu-devel and ubuntu-devel-discuss every day? (that's at least every day where you contribute to ubuntu)"
[03:08] <micahg> speaking of...
[03:27] <infinity> micahg: I might need educating on freezes, yes. ;)
[03:28] <micahg> infinity: not you :)
[03:28] <infinity> micahg: I dunno, my accidental mono upload made me feel special. :P
[03:28] <micahg> infinity: you at least caught it and apologized before I got the -changes E-Mail :), people make mistakes
[03:32]  * stgraber just got his first armhf build failure!
[03:35] <micahg> ooh, mono-devel is part of the DVD seed
[03:44] <micahg> infinity: I would think getting armhf bootstrapped and building in the archive would make you feel special
[03:55] <broder> wait, i'm supposed to be reading ubuntu-devel-discuss? :(
[03:55] <stgraber> argh, s/discuss/announce/g :)
[03:56] <stgraber> though I do read -discuss every day too but it's not nearly as useful as -announce :)
[03:56] <broder> ah, good :)
[03:57] <micahg> ooh, didn't catch that
[06:29] <pitti> Good mornintg
[06:30] <pitti> skaet: btw, the complete rebuild only takes 4 hours because of powerpc
[06:31] <pitti> skaet: i386/amd64 desktop images now take 8 minutes, but have to wait for powerpc which takes some 35
[06:31] <pitti> skaet: there's an RT for switching those to a faster machine
[06:32] <pitti> infinity: I'm not worried at all about packages not  being up to date on the a1 images; that will basically never be true anyway
[06:32] <pitti> infinity: as long as arch skew on mono doesn't cause uninstallability, that should not matter
[06:34] <pitti> skaet: so, can't see any blockers right now, except for this infamous bug 894768; anything I need to watch out for during my day?
[06:34] <ubot4> Launchpad bug 894768 in linux (Ubuntu Precise) (and 1 other project) "Installation randomly fails with: File "/usr/lib/ubiquity/ubiquity/install_misc.py", line 621, in copy_file targetfh.write(buf) IOError: [Errno 22] Invalid argument (affects: 6) (dups: 6) (heat: 58)" [High,Triaged] https://launchpad.net/bugs/894768
[06:43] <pitti> infinity: hm, seems arch desync does cause trouble.. http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
[06:43] <pitti> let's hope that it finishes building soon
[06:44] <pitti> armhf already finished, seems these builders are faster?
[07:58] <pitti> cjwatson, skaet: FYI, I updated publish-image-set.py for the new tracker
[07:58] <pitti> still had to use screenscraping, the XMLRPC API is missing some bits for this still (in particular, retrieving builds)
[09:36] <pitti> skaet: FYI, added "general" and filled out the "Ubuntu" part of https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview
[10:54] <infinity> pitti: Yeah, armhf has all the pandas right now.
[10:55] <infinity> pitti: And sorry about the skew.  Was a complete oops on my part.
[10:57] <pitti> infinity: np, it's all good now
[11:04]  * ogra_ wonders if hf actually gains us compiler speed too
[11:04] <ogra_> does that use the floating point engine massively in any way 8i would have thought not)
[11:35] <pitti> skaet: also added some known bugs to TechOver now
[11:36] <pitti> jibel: so aside from the dreaded EINVAL thing, I don't see any showstoppers so far; did you?
[11:39] <jibel> pitti, I'm currently facing a problem with i386 installed on a server. jamespage says it could be due to powernap, I'm testing a workaround now
[11:40] <jibel> problem = the server hangs and tells me bad things like http://paste.ubuntu.com/754743/
[11:40] <jamespage> jibel: I'm pretty sure thats what its is - same symptoms as I saw in the openstack lab
[11:40] <pitti> ah, offlining CPUs
[12:13] <jibel> pitti, jamespage bug 898127
[12:13] <ubot4> Launchpad bug 898127 in linux (Ubuntu) "system hangs and errors at /build/buildd/linux-3.2.0/arch/x86/kernel/apic/ipi.c:113 default_send_IPI_mask_logical+0xdc/0xf0() (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/898127
[12:30] <jibel> jamespage, no hangs with your workaround, could you update the bug report, and I'll add a release notes task.
[13:57] <pitti> jibel, jamespage: do we want to upload a powernap workaround for this, or just release-note it?
[13:58] <jamespage> Daviey: any opinion on ^^
[13:59]  * Daviey looks
[14:00] <Daviey> jamespage: Only impacts a subset of machines?
[14:00] <Daviey> we've only seen it on Dell?
[14:00] <jamespage> Daviey: in this instance it was machines with the ubuntu-orchestra-client installed which still recommends powernap
[14:00] <jamespage> jibel: do you know what type of machine that issue happened on?
[14:01] <Daviey> ubuntu-orchestra-client is still universe.. we don't install powernap by default, but shipped server-ship
[14:01] <jibel> jamespage, PE R210
[14:01] <jamespage> so a dell then
[14:01] <Daviey> I really don't think this warrants a rebuild.
[14:01] <jibel> right
[14:01] <jamespage> Daviey: I don't think so either - is powernap even on the ISO?
[14:02]  * jamespage goes to lookl
[14:02] <Daviey> server-ship
[14:04] <jamespage> so I see
[14:04]  * jamespage should read things better
[14:06] <Daviey> I don't think it even needs release notes providing there is a fix in the archive at release.
[14:17] <lamont> putting several of the armhf builders on manual to minimize my pain from some maintenence to happen shortly
[15:17] <bdmurray> How do the meta-release files at changelogs.ubuntu.com?  I fixed one of them yesterday and hit hasn't been updated.
[15:17] <skaet> pitti,   good morning.   Thanks for the updates to TechnicalOverview.  :)
[15:18] <stgraber> oh, technicaloverview alsmost forgot that one :) will need to update (not that there's much to say at this point)
[15:18] <skaet> stgraber,  thanks!
[15:19]  * skaet crosses one of the teams to remind off her list ;)
[15:20] <bdmurray> mvo: ^?
[15:29] <mvo> bdmurray: what did you fix, sorry I missed the context
[15:29] <mvo> bdmurray: oh, indeed
[15:30] <mvo> bdmurray: its a manual process currently, anyone in the changelogs group can update it
[15:30] <mvo> I did that now
[15:30] <bdmurray> mvo: okay, thanks
[15:52] <skaet> jibel, mvo - has anyone started off the https://wiki.ubuntu.com/UpgradeTestingProcess?
[16:03] <mvo> skaet: I haven't but I think that jibel has
[16:08] <jibel> skaet, I did excepted cdrom upgrade
[16:13] <skaet> thanks jibel, mvo
[16:51] <jibel> skaet, wubi.exe is not on the desktop images and not listed in http://cdimage.ubuntu.com/daily-live/current/precise-desktop-amd64.list
[16:52] <jibel> skaet, did I miss something or is it really missing ?
[16:52] <skaet> pitti, ^
[16:52]  * pitti looks
[16:53] <skaet> jibel,  should be there,  will look into it too with pitti
[16:53] <pitti> right, it's missing indeed
[16:54]  * jibel adds a task to test the content of the images
[16:56] <pitti> jibel: how can I find out what failed here? https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/PROFILE=main-all,label=upgrade-test/
[16:57] <jibel> pitti, go to the last failed or select job 58
[16:57] <jibel> pitti, the logs are attached as artefacts
[16:57] <pitti> jibel: ah, found it; thanks!
[16:57] <jibel> in that case main.log says that 2011-11-30 06:54:46,720 ERROR Dist-upgrade failed: 'E:Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.'
[16:57] <jibel> so you'll need to look at apt.log
[16:58] <jibel> and you'll see there some dependency issue with tdsodbc
[16:58] <jibel> Broken tdsodbc:i386 Breaks on libiodbc2 [ i386 ] < 3.52.7-2 > ( libs )
[16:58] <jibel>   Considering libiodbc2:i386 3 as a solution to tdsodbc:i386 0
[16:58] <jibel>   Holding Back tdsodbc:i386 rather than change libiodbc2:i386
[16:58] <pitti> jibel: ok, will do that tomorrow; but sounds just like arch desync
[16:59] <jibel> pitti, I'll look at it tomorrow morning with mvo because we also need to fix the base image for amd64
[17:00] <pitti> I need to run for today, Taekwondo time
[17:00] <jibel> good night pitti
[17:00] <pitti> skaet: no idea about missing wubi.exe right now, I don't know how this works; need to RTFS tomorrow; perhaps ev knows
[17:01] <skaet> RTFS?
[17:01] <pitti> read the fine source
[17:01] <pitti> cdimage scripts and so on
[17:02] <skaet> :)  gotcha.
[17:04] <mdeslaur> Is there an expert here or resources on packaging license dependencies?
[17:04] <mdeslaur> I'm not sure where to ask about this
[17:05]  * pitti waves goodnight, need to runu
[17:05] <GrueMaster> Is no one testing kubuntu?
[17:06] <skaet> mdeslaur,  I've got some background,  what's up?
[17:06] <GrueMaster> I'm pulling the armel images now so I can whip through them.
[17:06] <seb128> mdeslaur, don't ask to ask just ask I guess, worth case you get ignored :p
[17:06] <skaet> GrueMaster,  I've posted in kubuntu-devel channel asking for some help, but no one's stepped forward.
[17:07] <mdeslaur> seb128: pffff :P
[17:07] <mdeslaur> skaet: I'm looking at bug 891192
[17:07] <ubot4> Launchpad bug 891192 in ubuntu "Please sponsor the proposed qt4reactor packaging branch (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/891192
[17:07] <skaet> RIddell is out due to car accident,  and not back on line yet.
[17:07] <skaet> mdeslaur, looking
[17:07] <mdeslaur> skaet: about sponsoring qt4reactor, but the reason it's not bundled with twisted in the first place is because twisted is MIT and pyqt is GPL
[17:08] <ev> oh
[17:08] <ev> pitti, skaet: entirely my fault
[17:08] <ev> fixing now
[17:08] <ev> (directory structure is missing in my public_html)
[17:08] <skaet> thanks ev
[17:09] <skaet> mdeslaur,  do they need to link together in some way (dynamic or static) to work?
[17:10] <nessita> skaet: qt4reactor imports pyqt on a try-except block
[17:10] <mdeslaur> skaet: it's python, which is why it's complicated :P
[17:10] <nessita> skaet: if pyqt is not available (ImportError), it will try to use pyside
[17:11] <mdeslaur> pyside is LGPL
[17:11] <skaet> mdeslaur, heh,  yeah, see the issue, LGPL is better license for this sort of thing.
[17:13] <skaet> mdeslaur,   let me ping around on this then.  imports aren't quite dynamic linking, but ... yeah, good question.
[17:13] <ev> skaet: fixed
[17:14] <skaet> jibel, ^
[17:14] <mdeslaur> skaet: thanks.
[17:15] <jibel> skaet, ev thanks.
[17:15] <jibel> skaet, you'll rebuild the desktop images but not the squashfs ?
[17:19] <skaet> jibel,  can do,  am also ok with release noting this, since some things have crept into the repository during soft-freeze that might have side effects.    What's the re-testing bandwidth like?
[17:21] <jibel> skaet, not much.
[17:21] <jibel> skaet, +1 for release noting for me.
[17:22] <skaet> jibel,  anything else showing up from that testing that might provoke a respin?
[17:22] <skaet> s/provoke/necessitate/
[17:23] <jibel> skaet, nothing
[17:24] <skaet> jibel,  ok,  lets plan on release noting it.
[17:40] <skaet> jibel,  just talked to superm1 - they won't be releasing mythbuntu images with A1.  I've removed them from the tracker.
[17:40] <jibel> skaet, k
[17:41] <jibel> skaet, netboot images are not on the tracker but are good.
[17:42] <skaet> jibel,  thanks for checking them
[17:54] <skaet> stgraber, ^ I'm seeing netboot images as active,  any idea why they might not be showing up?   something need to be twiddled on nusakan?
[17:58] <jibel> about netboot, precise is not listed at http://cdimage.ubuntu.com/netboot/
[18:01] <skaet> jibel,  yup that would do it.
[18:01] <davmor2> jibel: http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/ and installer-i386 I imagine
[18:02] <davmor2> jibel: as a temporary fix
[18:02] <davmor2> jibel: if memory serves cjwatson does some hocus pocus and it appears in http://cdimage.ubuntu.com/netboot/ but that is the original link
[18:03] <jibel> davidm, thanks, I know where to find it, just mentioning that it is not linked from cdimage.u.c
[18:04] <davmor2> jibel: wrong david but I figured you might but always worth checking :)
[18:04] <jibel> :)
[18:05] <davmor2> jibel: assumption the mother of all *choose your expletive* ups ;)
[18:12] <skaet> jibel,  I've gone in and added precise pangolin to the page,  but will need to wait for it to publish, and we'll see if it picks up the right pieces.   If not will get cjwatson to look at it tomorrow morning.  (he'll be back from vacation then).   Since the images are known to test out ok, that's the main thing.
[18:14] <stgraber> skaet: netboot is an interesting one, as we don't build them daily but only when building a new d-i, they'll never show up automatically on the tracker, unless cjwatson does some magic to get them update when a new d-i is uploaded
[18:15] <skaet> stgraber,  interesting,  lets find out how he wants to handle it then when he's back tomorrow.
[19:15] <GrueMaster> I test omap4 netinstaller daily, and it works fine here.  After I run through the kubuntu armel images, I'll test the omap netinstaller.
[19:17] <stgraber> skaet, jibel: LTSP failed on alternate, apparently something changed in ssh ... looking into that now
[19:18] <skaet> stgraber,  ack.   thanks
[19:19] <stgraber> skaet: I'll likely have a fix in the next 30 minutes (as in, I have a fix, it takes me 30 minutes to validate). Not sure if it's worth rebuilding though, your call.
[19:21]  * skaet pondering
[19:50] <stgraber> skaet: looks like the fix works (at least it didn't fail at the same place as before)
[19:50] <stgraber> skaet: I should be able to check that a thin client can actually boot from that server in the next 10min or so
[19:51] <skaet> stgraber, ok.
[19:55] <stgraber> skaet: confirmed to work after reboot
[19:55] <stgraber> skaet: should I upload a new LTSP with the fix?
[19:55] <skaet> stgraber,  yes go ahead and upload.
[19:56] <stgraber> (btw, the problem is Precise's ssh being picky about the permissions of /var/run/sshd)
[19:58] <skaet> stgraber,  I think we can live with it being release noted, but want to get jibel's input.
[19:59] <stgraber> skaet: right, only thing to be aware of is that I can't provide a workaround. Install will just fail, so workaround is to use a more recent daily.
[20:00] <skaet> stgraber,   fair enough.
[20:01] <stgraber> skaet: I don't feel like explaining how to modify the postinst script by hand at run time in the release notes ;)
[20:02]  * skaet interprets that stgraber recommends a respin.
[20:03] <stgraber> skaet: if we want/care about LTSP for alpha-1, then we need a respin
[20:03] <stgraber> as usual it depends on how quickly we can get it re-tested
[20:03] <skaet> stgraber,  yes, retesting is the concern at this point.
[20:03] <skaet> jibel, ^^
[20:04] <stgraber> at least it's limited to Ubuntu Alternate (i386 and amd64), Edubuntu's LTSP isn't affected
[20:04] <skaet> thanks for confirming Edubuntu's LTSP isn't affected.
[20:05]  * skaet goes and kicks off the Ubuntu Alternate respins
[20:08] <stgraber> at least the current ones are fully tested, so we can always go with that
[20:10]  * skaet nods
[20:15]  * GrueMaster hears "respin", gets as nervous as a strung out long-tailed cat in a room full of mouse traps.
[20:17]  * skaet reassures GrueMaster with phrase "Ubuntu Alternate" at this pont.
[20:18] <GrueMaster> Yea, saw that.
[20:18] <skaet> :)
[20:22] <stgraber> jibel: I'm sure you'll also be interested by http://<IP_ADDRESS>/qatracker/milestones/205/history (there's no link to /history in the UI at the moment as it's still fairly new)
[20:23] <stgraber> skaet: I guess that between that page and jibel's report you should have a pretty good overview of what happened for a given milestone
[20:24] <skaet> stgraber,  yes,  this is great!!!   Thank you very much!
[20:25] <stgraber> skaet: that's for Oneiric Final: http://<IP_ADDRESS>/qatracker/milestones/202/history
[20:28]  * skaet *hugs* stgraber.
[20:28] <skaet> sweet!!
[20:39]  * skaet waiting for LTSP to actually publish before trying again.
[20:51] <smoser> skaet, where should release notes be going ?
[20:54] <skaet> smoser, https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview
[20:54] <smoser> yeah, jst found thank you.
[20:56] <skaet> :)
[21:52] <skaet> LTSP published now.
[21:52] <skaet> started respin of ubuntu alternate.
[21:53] <skaet> pitti,  jibel - xubuntu won't have time to retest,  so leaving their images alone..  Haven't heard backfrom kubuntu or lubuntu yet on whether they want a respin.
[21:55] <skaet> lubuntu just responded,  they'll stay with their current images.
[22:12] <skaet> kubuntu responsed they'll stay with their current images in #kubuntu-devel channel.
[22:12] <skaet> new ubuntu alternate images with LTSP posted.
[23:21] <jibel> latest alternate looks good.
[23:22] <jibel> I'll test wubi tomorrow morning when it's published somewhere.
[23:22] <jibel> good night
[23:29] <GrueMaster> skaet: Kubuntu armel images tested ok.
[23:29] <skaet> Thanks Gruemaster
[23:31] <skaet> jibel, thanks for confirming alternates look good.
[23:32] <skaet> jibel,  unless pitti feels otherwise,  i recommend release noting the WUBI issue.