[08:32] <bizulk> Hello World !
[08:58] <bizulk> Question about gstreamer : when gst-inspect return that some plugins are blacklisted, it means that they won't be loaded with playbin, right ?
[08:59] <ogra_> xnox, there was a usb bug in the ac100 kernel, either try again once thats in, install from an SD card or go with the beta and upgrade
[09:01] <xnox> ogra_: hmm.... i am running quantal.
[09:01] <ogra_> yes, i was referring to quantal
[09:01] <xnox> ogra_: what was my question? I lost context....
[09:02] <ogra_> * xnox is playing with ac100 android install before reinstalling it with ubuntu
[09:02] <ogra_> * xnox ac100 no tarball found hm =/
[09:02] <ogra_> i was referring to the last one
[09:02] <xnox> ogra_: ah. I did manage to install with sdcard =)
[09:02] <ogra_> ah, great
[09:02] <ogra_> well, usb should work too now
[09:02] <xnox> ogra_: i was like, what the heck let's try the sdcard. Cause i was suspecting that my usb thumb drive was "tempremental"
[09:03] <ogra_> heh
[09:03] <xnox> ogra_: media keyboard buttons. Do they work?
[09:03] <ogra_> dont blame it ... the kernel was missing usb-storage
[09:03] <ogra_> no, they are F-keys
[09:03] <ogra_> you can re-assign some of them, i.e. i use the volume and mute keys remapped
[09:04] <xnox> =(
[09:04] <ogra_> the touchpad toggle key (F9) is sadly hardwired to touchpap power
[09:04] <xnox> ogra_:  what about bug 1061430 ?
[09:04] <ubot2> Launchpad bug 1061430 in libmtp "[ac100] libmtp-runtime is not pre-installed" [Medium,New] https://launchpad.net/bugs/1061430
[09:04] <ogra_> if your touchpad doesnt work once, first try with that key :)
[09:05] <ogra_> oh, yeah i noticed the noise on boot
[09:06] <ogra_> ac100 doesnt differ from other images (same seeds, no arch specific bits)
[09:06] <ogra_> so i really wonder why its not showing on other systems
[09:07] <ogra_> This package provides the udev rules file and the FreeDesktop.org Device
[09:07] <ogra_>  Information Files file (used by HAL).
[09:07] <ogra_> hal ... hmm
[09:08] <xnox> ogra_: I disagree with you.
[09:08] <xnox> ogra_: http://paste.ubuntu.com/1259609/
[09:09] <xnox> ogra_: notice how runtime is seeded everywhere where common is, but in the pre-installed case.
[09:09] <ogra_> heck, why is it seeded at such a high level ?
[09:09] <ogra_> thats like seeding alsa-libs in desktop
[09:09] <xnox> ogra_: i suspect it's not hal specific anymore. it's the thing that should tell what is an iPod / iPad / photo camera / video camera / mp3 player / etc.
[09:10] <ogra_> yeah
[09:10]  * xnox made lubuntu look ~ unity-like
[09:10] <ogra_> that should at least be in desktop-common
[09:12] <ogra_> ogra@anubis:~/Devel/seeds/ubuntu.quantal$ grep -r mtp *
[09:12] <ogra_> ogra@anubis:~/Devel/seeds/ubuntu.quantal$
[09:12]  * ogra_ scratches head
[09:13] <ogra_> not in platform either
[09:15] <xnox> ogra_: due to reverse-recommends from libmtp9 runtime is installed because of: amarok, rhythbox-plugins, banshee or audacious-plugins (all default music players?!)
[09:15] <ogra_> ah
[09:15] <ogra_> i dont see any of them in the binary rdepends
[09:15] <xnox> ogra_: so check the diff between lubuntu daily-live and daily-preinstalled manifests?
[09:16] <xnox> ogra_: reverse-depends libmtp-runtime -> libmtp9 (reverse-recommends) -> music players (reverse depends)
[09:16]  * ogra_ doesnt even know where the lubuntu seeds live :)
[09:17] <ogra_> ah. recommends
[09:17] <xnox> ogra_: well. diff the manifests on cdimage.u.c =)))) and it should be in the ubuntu-seeds project as  a branch?!
[09:17] <ogra_> lubuntu ships gmplayer or gnome-mplayer
[09:17] <ogra_> yeah, something like that
[09:18] <xnox> ogra_: then why did it get libmtp-common?
[09:19] <ogra_> ogra@anubis:~/Devel/seeds/platform.quantal$ apt-cache show libmtp-common|grep lubuntu|wc -l
[09:19] <ogra_> 2
[09:19] <ogra_> ogra@anubis:~/Devel/seeds/platform.quantal$ apt-cache show libmtp-runtime|grep lubuntu|wc -l
[09:19] <ogra_> 0
[09:19] <ogra_> ogra@anubis:~/Devel/seeds/platform.quantal$
[09:20] <ogra_> seems something explicitly seeds it
[09:24] <ogra_>   * Move all recommends to depends, to be consistent with the
[09:24] <ogra_>     no-follow-recommends feature of the seed.
[09:24] <ogra_> hmm, intresting changelog entry in lubuntu-meta
[09:25] <ogra_> i suspect that might explain it
[09:37] <ogra_> ok, got it
[09:37] <ogra_> lubuntu seeds audacious ... that depends on libmtp9 .... which doesnt depend on its own runtime buut only libmtp-common
[09:37] <ogra_> so its a dependency error in libmtp9
[10:53] <ogra_> xnox, fixed lubuntu-desktop uploaded :)
[10:54] <xnox> ogra_: cool.
[10:55] <xnox> ogra_: seeded-in-ubuntu transmission looks odd. why depend on a metapackage instead of selecting gtk frontend like the rest of seeds.....?
[13:20] <janimo`> hrw, hi, is there any catch in using ccache with the cross gcc for building kernels
[13:25] <janimo`> hrw, nevermind, found it :)
[13:26] <janimo`> marvin24, CROSS_COMPILE="ccache arm-linux-gnueabihf-" passed in the make or debuild line
[13:26] <janimo`> maybe the kernel build system ignores the PATH somehow
[13:27] <janimo`> since for a simple Makefile in another project arm gcc works via ccache if the symlinks are set
[13:42] <marvin24> janimo`: ok, thanks - will try out
[15:20] <bizulk> just in case my story does interest somebody : I did pass the configure step with --disable-modular-tests option
[15:57] <marvin24> janimo`: yup, that worked - easy enough
[15:57] <marvin24> thanks!
[15:59] <janimo`> marvin24, yes, quite faster here as well :)
[15:59] <janimo`> thanks for reminding me that ccache does not work, I somehow kept ignoring it and sufferint longer build times than needed
[16:01] <marvin24> janimo`: I guess that won't balance the time I stole you already ;-)
[16:09] <janimo`> marvin24, nah, the time it took was not longer than the delta between a regular and a ccached build so it is already gained back :)
[16:10] <janimo`> unless you mean ALL THE TIME YOU STOLE by starting the ac100 kernel and all it lead to ;)
[16:13] <marvin24> ^^^ yes, that's what I meant
[17:22] <hrw> guys: when #ubuntu-arm64? :D
[17:29] <infinity> hrw: Won't be a new channel, but I'm sure more arm64 talk will happen here soonish.
[17:30] <ogra_> hrw, as soon as we have #ubuntu-amd64
[17:31] <hrw> so far I crosscompiled only 634 packages
[17:31] <hrw> but with OE
[17:32] <infinity> hrw: Which libc are you using?  Our 2.15+libc-alpha patches, or master+alpha?
[17:33] <hrw> infinity: 2.16+svn+aarch64-public
[17:33] <hrw> its 2.16+svn20393 iirc in last build
[17:33] <infinity> So, vaguely master+libc-alpha.
[17:33] <hrw> yes
[17:34]  * infinity needs to spend some time in the next week or two to dump something vaguely workable into Debian/experimental and prep for R.
[17:35] <infinity> Not that R will be building arm64, due to lack of anything to use as a buildd, but I want R to be able to cross-build it without pain.
[17:35] <hrw> infinity: wookey works on it already too
[17:36] <infinity> wookey: We should talk. ;)
[17:37] <ogra_> why oh why that arch name
[17:37] <infinity> ogra_: Which one?  arm64 or aarch64?
[17:37] <ogra_> arm64 and amd64 are way to close for my taste
[17:38] <infinity> Heh.
[17:38] <infinity> Get less dyslexic. ;)
[17:38] <ogra_> aargh64 at least allows a funny typo :)
[17:38] <xnox> arrrr64 whould be awesome though
[17:38] <ogra_> pirates !
[17:38] <xnox> aka *our arch does not exist*
[17:58] <hrw> bye
[20:00] <wookey> ogra_: it's true that amd64 and arm64 are easy to confuse - I've been doing that quite a lot already
[20:00] <wookey> infinity: talk away
[20:01] <infinity> wookey: Oh just about glibc and how your cross-building adventures are going.  Perhaps I should have suffixed "we should talk" with "soon", or maybe even a date.
[20:01] <infinity> wookey: How's your tomorrow look?
[20:02] <wookey> tomorrow I foresee more fighting with eglibc2.16 and toolchain bootstrap :-)
[20:02] <wookey> so yes, anytime
[20:02] <wookey> tomorrow evg I'm out. But presumably you are thinking of my morning, your evg?
[20:03] <infinity> wookey: I was thinking my morning, your afternoon, but well before your evening.
[20:04] <wookey> no probs. I was miffed today to find tha the bug you get from trying to build eglibc2.15 with gcc4.7 gives zero google hits
[20:04] <wookey> So moving to 2.16 seems like likely path of least resistance (and matches aarch64 patches much better too)
[20:04] <infinity> wookey: Bring that up with me tomorrow too. ;)
[20:05] <infinity> wookey: Well, we're moving to 2.16 for Ubuntu-R and Debian/experimental, I just need to get to it.
[20:05] <infinity> wookey: If the current libc-alpha aarch64 patches apply cleanly to 2.16, I may not need much input from you, but I just want to pick your brain about your experiences so far.
[20:05] <wookey> OK. aurel told me the packaging was done, so I'm just assembling all the right parts to see if it builds
[20:06] <infinity> wookey: Yeah, aurel's done a lot of the heavy lifting already, I need to do a bit more though.
[20:06] <wookey> I'll have a patch for that within the hour I think
[20:06] <infinity> wookey: Oh, spiffy.  In that case, you can provide me with useful patches tomorrow. :)
[20:06] <wookey> no idea if it'll actually work...
[20:06] <infinity> wookey: And I'll get it all committed and we can work from there.
[20:07] <wookey> it's a bit wierd the way the debian packaging doesn;t match upstream layout
[20:07] <wookey> But I think I have groked what goes where
[20:07] <infinity> Hysterical raisins.
[20:07] <wookey> so I gathered
[20:08] <infinity> Going back to when it was three different upstream branches that had to be merged.
[20:08] <infinity> I'll mangle all of that when I move Debian to git.
[20:08] <infinity> But that won't happen until we're also ready to move Debian back to glibc.
[20:08] <wookey> I was confused for a while though...
[20:12] <infinity> Heh.
[20:12] <infinity> It's not ideal.
[20:12] <infinity> We'll fix it in the next 6-12mo, I hope.
[20:12] <infinity> As soon as we verify that glibc has all the eglibc patches we care about (or most of them), and switch back.
[20:13] <infinity> Some serious round tuits required for that audit.
[21:21] <[7]> hey
[21:21] <[7]> I've just tried to install quantal on my pandaboard (omap 4430)
[21:21] <[7]> sd card works well with oneiric/precise
[21:21] <[7]> however with the xloader from http://ports.ubuntu.com/ubuntu-ports/dists/quantal/main/installer-armhf/current/images/omap4/netboot/MLO it freaks out with this:
[21:21] <[7]> OMAP SD/MMC: 0\nmmc_send_cmd : timeout: No status update\nCard did not respond to voltage select!\nspl: mmc init failed: err - -17\n### ERROR ### Please RESET the board ###
[21:21] <[7]> so... is that a broken MLO, or a weird card that somehow happened to work right with an older one
[21:21] <[7]> if the former, where do I get a working MLO that works with quantal (12.10)?
[21:21] <[7]> if the latter, what kind of trouble is to be expected if I just use an older MLO, e.g. from oneiric or precise?
[21:35] <GrueMaster> Try one from Precise, just in case.  The MLO shouldn't have changed, afaik.
[21:36] <infinity> It's been rebuilt, even if the code didn't change.  That said, it works in our pre-built images.
[21:36] <infinity> (I'll admit I haven't built an SD by-hand with the one we publish, but it's identical to what's in the boot images sitting next to it)
[21:37] <[7]> GrueMaster: precise is 33K in size, quantal is 26K
[21:37] <[7]> swapping it results in this: http://pastie.org/4910961
[21:38] <[7]> infinity: those boot images fail to boot on my board/card
[21:38] <[7]> does this output mean that I might have to swap uboot as well? or did it actually fail to load uboot?
[21:39] <[7]> (that output loops over and over again)
[21:40] <infinity> [7]: Which "those images"?  boot.img-serial.gz?
[21:40] <[7]> yes, that one
[21:41] <infinity> Same voltage select error?
[21:41] <infinity> It could be the card, unsure.
[21:41] <[7]> haven't observed serial output of that, but it resulted in no LED activity as well
[21:41] <infinity> As for the error when you swap around MLO, it may well be that MLO and u-boot need to match.
[21:42] <GrueMaster> [7]: Just download either boot.img-fb or boot.img-serial and then "gunzip <boot.img.*|sudo dd of=/dev/mmcblk0 bs=4M"
[21:42] <[7]> infinity: so you say a precise uboot is likely to work with quantal?
[21:42] <GrueMaster> You don't need the other files unless you are manually creating a boot image.
[21:43] <infinity> [7]: Should do.
[21:45] <[7]> hm, now that card acts weird in my laptop as well: http://pastie.org/4910997
[21:47] <[7]> hm, replugged it, works again
[21:48] <infinity> This fits nicely with my "blame the card" mantra.
[21:48] <[7]> ok, swapping uboot as well seemed to help
[21:48] <[7]> booted a kernel at least
[22:00] <[7]> "ALERT!  /dev/disk/by-uuid/root does not exist.  Dropping to a shell!"
[22:00] <[7]> now why on earth does it look for a label in by-uuid?
[22:00] <infinity> Booting a non-standard kernel?
[22:00] <GrueMaster> what exactly are you trying to do?
[22:01] <[7]> or rather why does the installer set up a root=uuid=<label> bootarg if I specify a partition label during installation
[22:02] <GrueMaster> What does your boot.scr contain?
[22:03] <[7]> "root=uuid=root"
[22:03] <[7]> the interesting question is how that ended up in there
[22:04] <GrueMaster> Back to my earlier question, what are you trying to do?  Netboot installation?
[22:23] <[7]> GrueMaster: yes
[22:23] <[7]> and it worked for the most part, only problems were that MLO/uboot thing, and that wrong root device
[22:24] <GrueMaster> If you are doing a netboot install, just download the boot.img-fb or boot.img-serial and flash it to your SD card.  Don't worry about anything else.
[22:25]  * GrueMaster wishes he could log into the home network from work to verify the images are indeed ok.
[22:27] <[7]> GrueMaster: well, that didn't work with this card at least, which worked on oneiric just fine, for more than a year
[22:28] <[7]> hm, now it froze :/
[22:28] <[7]> no heartbeat anymore
[22:28] <[7]> no console output either
[22:47] <GrueMaster> Har!  Found a way into my home network.  Now testing the quatnal netboot install on my panda farm.
[22:48] <GrueMaster> Seems to be working for me just fine.  Panda4 rebooted and is running my preseed install (which is a symlink to my Precise preseed - i.e. unchanged).
[22:50] <GrueMaster> [7]: Just fyi:  I automated  SRU Kernel testing when I was doing Ubuntu ARM QA.  I am no longer doing that work, but my systems are still operational as is my local mirror.  Everyhting still appears to be working fine.
[22:50] <[7]> so we apparently have an incompatibility between this sd card and newer uboots?
[22:51] <GrueMaster> The automation process downloads the boot.img-serial.gz to the local panda and reflashes the SD.  It then reboots, and the preseed installes the designated release on a USB Sata drive.
[22:51] <GrueMaster> As to your SD, I don't know.  Try seroing it out and reimaging it.  I've had to do that on occasion when I was doing daily testing.
[22:51] <GrueMaster> *zeroing
[22:52] <[7]> hm, maybe I'm gonna try another card with that boot image to see if that works
[22:52] <[7]> but this card seems to be working just fine
[22:52] <[7]> (after swapping out xloader and uboot)
[22:53] <GrueMaster> Try reflashing the boot.img to the sd card.  You shouldn't have to do anything else.
[22:53] <GrueMaster> Are you on a Panda or PandaES?
[22:54] <[7]> the old (4430) one
[22:54] <GrueMaster> Ok.  That is what I am testing on.  (not sure if my ES is still plugged in)
[22:54] <[7]> and it did try that image on this card earlier, and it didn't work
[22:54] <[7]> now that I've installed everything I'm not sure I'll wipe it again
[22:55] <GrueMaster> heh
[22:55] <infinity> Are you positive you tried the .gz images, and not the -fat?
[22:55] <infinity> The latter is a red herring.  And we really need to stop publishing it.
[22:56] <[7]> no, i tried the gz
[22:56] <infinity> Kay.
[22:56] <[7]> both dd'ed directly to the sd card (superfloppy) or as a properly sized partition
[22:56] <infinity> Then I'm all for either blaming the card entirely, or doing a low-level zeroing of it before rewriting it.
[22:56] <infinity> Err, what?
[22:57] <GrueMaster> [7]: Did you gunzip before flashing it?
[22:57] <[7]> sure
[22:57] <infinity> The .gz contains a partition table, no superfloppiness about it.
[22:57] <[7]> hm? lemme check again
[22:57] <infinity> If what you have there doesn't have a partition table, it's not the right image.
[22:57] <[7]> hm, indeed it does
[22:57]  * [7] tries to remember what he did
[22:58] <GrueMaster> The proper way to flash (well, what I use anyway) is "gunzip <boot.img-serial.gz|sudo dd bs=4M of=/dev/mmcblk0"
[22:58] <infinity> I tend to just zcat as root, since the image is small enough that bumping the block size doesn't buy much.
[22:58] <GrueMaster> You could also use /dev/sdb (or whatever your PC designates as the SD drive).
[22:58] <infinity> But yeah, GrueMaster's command is best practice.
[22:59] <[7]> anyway, I'm sure I dd'ed that onto the sd card
[23:00] <GrueMaster> infinity: It isn't about size.  I discovered early on (Karmic timefram iirc) that using BS actually changes the write order a bit.
[23:00] <[7]> and only tried partitioning when that didn't work
[23:00] <GrueMaster> On some devices.
[23:00] <GrueMaster> [7]: Yea, no need to partition.  The img is a disk image that contains a small fat partition preloaded with good stuff.
[23:02] <[7]> hm, odd... anyway, I always checked that it was mountable
[23:03]  * GrueMaster wishes he had ipv6 access to the home instead tunneling around through putty.
[23:19] <GrueMaster> Hmm.  Fail.  infinity:  Did openjdk-6-jre-headless get removed this cycle?
[23:20] <GrueMaster>  same with python-software-properties apparently.
[23:49] <[7]> has someone seen aptitude crash like this before? Uncaught exception: ../../src/generic/problemresolver/choice.h:328: const version& generic_choice<PackageUniverse>::get_ver() const [with PackageUniverse = aptitude_universe; generic_choice<PackageUniverse>::version = aptitude_resolver_version]: Assertion "tp == install_version" failed.
[23:49] <[7]> seems to happen when it tries to resolve dependencies of broken packages
[23:57] <[7]> hm, apparently aptitude's pkgstates got corrupted during that crash


[14:06] <xubuntu10i> does somebody know how to install minecraft in linux
[14:12] <amerigena> Longshot, but does anyone know of an IRC channel for Rhino Linux?
[14:13] <amerigena> Getting this error at install :
[14:13] <amerigena> Command <i>apt-get update</i> finished with exit code 100.
[14:13] <amerigena> Output:
[14:13] <amerigena> Get:1 http://archive.ubuntu.com/ubuntu ./devel InRelease [255 kB]
[14:13] <amerigena> Get:2 http://archive.ubuntu.com/ubuntu ./devel-updates InRelease [90.7 kB]
[14:13] <amerigena> Get:3 http://security.ubuntu.com/ubuntu ./devel-security InRelease [90.7 kB]
[14:13] <amerigena> Reading package lists...
[16:27] <rathouse> hi
[19:02] <pjotter1> I recently bought an HP Elitebook and installed Xubuntu 22.04 It has "Bang & Olufsen" speakers, but the volume is way too loud and sounds almost distorted. Just for comparison, I installed Windows 11 and the sound/volume was just fine. So, somehow (X)Ubuntu is not handling the sound correctly. Does anybody have an idea what the problem could be?
[19:08] <diogenes_Vx15> pjotter1, is your sound server pipewire or pulseaudio?
[19:08] <pjotter1> pulseaudio
[19:10] <pjotter1> On the internet, I found different topics about this problem, but all 'sollutions' are pretty vague.
[19:10] <diogenes_Vx15> pjotter1, so maybe try pipewire.
[19:13] <pjotter1> I might give it a try. See if it improves anything.
[19:14] <pjotter1> The overall sound is not too bad, but could be a lot better. It;s a bit high pitched, lacks bass and sometimes sounds too loud/distorted even when the volume is turned down.
[21:14] <pjotter1> diogenes_: Thanks for the tip! I install pipewire and I think it worked. Everything sounds much better now.


[03:22] <Omnifrog> OMGWTFBBQ?
[03:22] <Omnifrog> https://consumerist.com/2016/08/12/dancing-baby-youtube-lawsuit-may-go-before-supreme-court/
[03:23] <Omnifrog> SRSLY???
[03:23] <Omnifrog> how is that case still alive?
[19:41] <netritious> Howdy everyone have a good weekend?
[19:44] <wrst> hey netritious doing well how are you?
[19:44] <wrst> oh and netritious, what do you think gives with this? http://susquehannamobile.org/cares-program-store/3-month-bundle
[19:45] <netritious> Pretty good wrst! Finally on at the same time lol
[19:46] <wrst> yes sir the stars and the planets have aligned :)
[19:48] <netritious> That looks pretty neat wrst. Sounds almost to good to be true. Is it?
[19:49] <wrst> I'm 150 bucks into it and seeing :)
[19:49] <wrst> I called them I'm sure they have a grant of some sort and they are a not for profit deal
[19:49] <wrst> if it works my quest is going to be the best way to get that to a "real" router
[19:49] <wrst> thinking of just using dd-wrt as a repeater and running all my networking through it
[19:50] <wrst> 10 devices won't cut it in my house, but sprints LTE is a lot better than my DSL
[19:50] <netritious> That would be a sweet setup. Let me know how that goes.
[19:51] <wrst> will do, you can use USB for tethering, I have a mikrotik router with usb but not for sure if that function will work or not I don't see it as supported
[19:52] <wrst> 3-5 days and I should have some idea
[19:53] <netritious> Still the tinkerer I see.
[19:53] <wrst> ha ha of course, I mean really if that works for that type of pricing I will do away with DSL eventually
[19:54] <wrst> bought the 3 month plan
[19:54] <wrst> I get around 25-30 down and 5-8 up with sprint at my house
[19:54] <wrst> I'm paying 110 bucks for 16/1
[19:54] <wrst> total bill with taxes and the phone I don't want
[19:55] <netritious> Eek
[19:56] <netritious> DSL is slowly dying. Reminds me of AOL..
[19:56] <wrst> I'm ready to put a bullet in it
[19:56] <wrst> they are however running fiber and I could get fiber to the home right now
[19:57] <wrst> oh and may try to track one of these down for the ethernet port: https://www.netgear.com/service-providers/products/mobile/mobile-hotspots/78XS-cradle.aspx?cid=wmt_netgear_organic
[19:58] <netritious> WHY AREN'T YOU GETTING FIBER?
[19:58] <wrst> http://twlakes.net/content/index/id/57/title/Rates+and+Speeds
[19:58] <netritious> Whoops, sorry...not yelling
[19:58] <wrst> plus about another 40 bucks to all of that for phones
[19:58] <wrst> and no I would understand yelling about it :D
[19:59] <netritious> :D
[20:00] <netritious> Hey someone bought my handle+.or trying to sell dieting software.
[20:01] <netritious> +.org I meant
[20:03] <netritious> That's hilarious because I probably need that software in my life heh
[20:04] <netritious> wrst: I am really getting into lxd/lxc on xenial.
[20:10] <wrst> ha ha
[20:10] <wrst> netritious: I'm using a mac right now... I do have a xenial server running at home
[20:10] <wrst> shhh don't tell cyberanger
[20:12] <netritious> Lol. cyberanger secretly loves ubuntu, everyone knows it.
[20:15] <netritious> Checking out ansible too. I've been avoiding it, but I think it's time to try to learn python again.
[20:17] <netritious> The last time I tried, it took me hours just to write a simple http client to fetch a page. Iirc it just felt awkward.
[20:18] <netritious> But it seems like python is every darn place now.
[20:34] <wrst> netritious: i didn't want him to know i was using  OS X :)
[20:35] <netritious> Oh, lol.
[20:36] <wrst> have been for a few months, works well for me, because i really don't use a comuter at home that much
[20:37] <netritious> If you were to hand cyberanger a mac with osx or a pc with windows 10 I bet he picks the mac with osx.
[20:37] <netritious> Or just walks away...that's more likely maybe.
[20:40] <wrst> ha ha probably
[20:41] <wrst> OS X has all the UNIXYness I need I can easily do whatever i want to do especially with the help of macports
[20:41] <wrst> plus can run MS Office and been getting into Abelton Live on the music side of things
[20:42] <wrst> but of course all my important stuff still resides and runs on linux
[20:42] <netritious> Like freed ports?  If only Tux was a pokemon...
[20:44] <netritious> *were
[20:45] <wrst> my wife who is a badge wearing member of the grammar police would appreciate that correction :)
[20:46] <netritious> Ha ha. My wife has Masters in English. I'm not allowed to get away with much :)
[20:47] <wrst> ha ha I would imagine not :)
[20:47] <netritious> Well time to get ready for daughter's open house at school.
[20:48] <netritious> Good chatting with you wrst! Promise I'll bbl!
[20:48]  * wrst has heard that one before !
[20:48] <wrst> later netritious :)
[23:02] <cyberanger> wrst: ouch a mac
[23:04] <cyberanger> netritious didn't give me the hardware specs on my choices, but I know the mac should have the VMX flag on the processor, and does have EFI. odds are it'd also have the higher specs (presuming a entry model for both)
[23:05] <cyberanger> I'd grab the Mac and a USB key or two and run linux.
[23:08] <cyberanger> If that's considered cheating, I still have macports, debootstrap and chroot on a mac, or KVM virtualization.


[02:36] <azend> Anyone have a fix for ubuntu laptops that run hot
[02:37] <azend> every single ubuntu laptop I've had has run extremely hot
[05:49] <DarwinSurvivor> azend: make sure you have the video card driver installed, otherwize the CPU dose 50 times as much work as the GPU would have been doing
[05:50] <DarwinSurvivor> azend: laptop-mode-tools is also very helpful
[05:51] <DarwinSurvivor> azend: also look at CPU scaling
[05:51] <DarwinSurvivor> azend: out of curiosity, what machines are you using that are heating up?
[05:52] <DarwinSurvivor> azend: OH, and make sure the fan is actually spinning! You have no idea how often laptop fans die!
[17:06] <azend> DarwinSurvivor: couple of dells, thinkpad t60, eeepc 1005ha
[17:07] <azend> I thought laptop-mode-tools was installed by default in ubuntu on laptops?
[17:07] <genii-around> Hm
[17:08] <azend> My fans seem to be spinning well but they could still probably use a shot of compressed air
[17:09] <genii-around> azend: You have an overheating issue?
[17:13] <azend> genii-around: yeah
[17:13] <azend> all of my ubuntu machines run really hot in comparison to windows


[01:26] <veebers> thumper oh lol, sorry to blank you - I'm not actually online atm (EOY leave :-D) How's things?
[01:51] <hpidcock> tlm: can you review this plz https://github.com/juju/juju/pull/11044
[01:52] <thumper> veebers: I thought it could have just been a bouncer reconnect
[01:52] <thumper> veebers: I'm good, you?
[01:52] <thumper> veebers: we should catch up for a coffee sometime
[01:53] <veebers> thumper can't complain - busy with the boy. Aye I would be keen!
[01:55] <thumper> veebers: he must be getting a lot bigger now
[01:56] <veebers> thumper grows faster than a weed! On a fine day we could go play a round of disc golf if you wanted something more energetic than coffee :-D In the week after xmas  I could bring Link too
[01:56] <tlm> hpidcock: sure
[01:57] <thumper> veebers: not sure how energetic I'll feel :)
[01:57] <thumper> babbageclunk: I think I need you again
[01:57] <veebers> :-D
[01:58] <wallyworld> hpidcock: and here it is https://github.com/juju/juju/pull/11045
[01:59] <wallyworld> babbageclunk: you ready for me to look at your test issue?
[01:59] <hpidcock> just a casual 222 files changed
[01:59] <wallyworld> mostly imports :-)
[02:25] <thumper> hpidcock, babbageclunk: https://github.com/juju/juju/pull/11046 for 2.7 merge
[02:25] <thumper> can I get you two to cast your eyes over it to make sure I didn't fubar it
[02:28] <hpidcock> thumper: yep, the files I was concerned about look how they should
[02:29] <thumper> hpidcock: coolio
[02:34] <hpidcock> wallyworld: I'm halfway and the green lines are starting to merge with the red lines haha I'm going to take a break from this PR for a bit
[02:34] <wallyworld> sure, np
[02:47] <babbageclunk> thumper: looking
[02:49] <wallyworld> babbageclunk: so in https://github.com/juju/juju/pull/11013, what test is it that is failing?
[02:50] <babbageclunk> wallyworld: hang on, getting you a link...
[02:50] <wallyworld> and PR has latest code pushed?
[02:50] <babbageclunk> it's in api/crossmodelrelations
[02:50] <babbageclunk> yup
[02:51] <babbageclunk> wallyworld: https://github.com/juju/juju/pull/11013/files#diff-d93493a140cf12285d568802cca83761R363
[02:52] <wallyworld> righto
[02:53] <babbageclunk> fails with: https://paste.ubuntu.com/p/wwgkyScvFY/
[02:53] <babbageclunk> Instead of coming in as something that I can assign a value to, result comes in as just interface{}
[02:54] <babbageclunk> Presumably it's because of the dance that happens with the commonWatcher inside the client-side watchers (constructing a new result type and passing it around as interface{})?
[03:00] <wallyworld> not sure yet, will look
[03:01] <wallyworld> just finishing a fight with go dep. go dep sucks
[03:26] <babbageclunk> it's just dep
[03:27] <babbageclunk> thanks - no rush, still wrestling with the remoterelations worker tests
[03:37] <hpidcock> thumper: you still handling that forward port?
[03:41] <thumper> hpidcock: yeah, got an expected error
[03:41] <thumper> in babbageclunk's stuff
[03:41] <thumper> babbageclunk: may need your assistance again
[03:42] <babbageclunk> ok
[03:48] <thumper> that was easier than I thought it was going to be
[03:48] <thumper> ... which is good
[03:56] <babbageclunk> thumper: normally it goes the other way
[03:57] <thumper> babbageclunk: true that
[04:09] <wallyworld> babbageclunk: i'm not sure either at this point how to deference that ptr. Goland knows how to so it clearly can be done
[04:16] <wallyworld> babbageclunk: actually, this works, but need to figure out how to do the assert
[04:16] <wallyworld> 				res := reflect.ValueOf(result).Elem()
[04:16] <wallyworld> 				res.Set(reflect.ValueOf(&params.RelationUnitsWatchResult{}))
[04:16] <wallyworld> 				//c.Assert(res, gc.FitsTypeOf, &params.RelationUnitsWatchResult{})
[04:16] <wallyworld> 				*(res.Interface().(*params.RelationUnitsWatchResult)) = params.RelationUnitsWatchResult{
[04:16] <wallyworld> 					Error: &params.Error{Message: "STOPPED"},
[04:16] <wallyworld> 				}
[04:17] <hpidcock> you should be able to dereference a interface ptr https://play.golang.org/p/mlyAZHqvWPJ
[04:19] <wallyworld> yeah, that works need to see if it works with the assert stuff
[04:31] <wallyworld> hmmm, we still need all the reflect machinery to wrie stuff up. but can add a check to start with and avoid the checker
[04:31] <wallyworld> 				_, ok := result.(interface{}).(*params.RelationUnitsWatchResult)
[04:31] <wallyworld> 				if !ok {
[04:31] <wallyworld> 					c.Fail()
[04:31] <wallyworld> 				}
[04:31] <wallyworld> 				res := reflect.ValueOf(result).Elem()
[04:31] <wallyworld> 				res.Set(reflect.ValueOf(&params.RelationUnitsWatchResult{}))
[04:31] <wallyworld> 				*(res.Interface().(*params.RelationUnitsWatchResult)) = params.RelationUnitsWatchResult{
[04:31] <wallyworld> 					Error: &params.Error{Message: "STOPPED"},
[04:31] <wallyworld> 				}
[04:32] <wallyworld> babbageclunk: the above will unblock for now at least
[04:38] <thumper> https://github.com/juju/juju/pull/11047 for someone...
[04:38] <thumper> provides exposing the underlying replicaset status in juju_metrics and juju_engine_report
[04:53] <wallyworld> thumper: done
[04:53] <thumper> wallyworld: ta
[04:53] <wallyworld> tlm: you going ok on the pylibjuju bug?
[04:54] <tlm> bug yes
[04:54] <tlm> python venv no
[04:54] <wallyworld> joy
[04:54] <wallyworld> hpidcock can probs help
[04:54] <wallyworld> don't forget to add a trello card
[04:54] <tlm> it will work soon, hpidcock has been. Having an issue installing requirements. Might be a version mismatch
[04:54] <tlm> yep will do now
[04:54] <wallyworld> ty
[04:56] <hpidcock> wallyworld: I won't let him drown
[04:57] <wallyworld> hpidcock: did the pr explain ok how bakery.v2-unstable in places still?
[04:59] <hpidcock> wallyworld: haha yep makes sense sorry. I must have read it. Went in this ear and out the other
[04:59] <wallyworld> no worries, sorry about the snark :-)
[05:00] <hpidcock> I appreciated the snarky comment
[05:02] <tlm> rage quit, problem is because python remove a function from an interface between 3.7 3.8. So much for backwards compatibility
[05:03] <hpidcock> go 1.0 promise keeps me loving go
[05:06] <hpidcock> wallyworld: I'm happy with the PR now. Hopefully it lands without 🔥
[05:07] <wallyworld> hpidcock: awesome, and many thanks, those sorts of prs are horrible to review (and even worse to write, took me ages to get stuff sorted).
[05:07] <hpidcock> they are fine, one day I'll return the favour with a 1000 file PR :P
[05:08] <wallyworld> huh, only 1000, i eat then for breakfast
[05:13]  * thumper EODs
[05:13] <thumper> see y'all tomorrow
[06:06] <hpidcock> wallyworld: can a subordinate unit be a subordinate to multiple parents?
[06:06] <hpidcock> hmm I dunno if that makes sense
[06:06] <wallyworld> no, you need to install the charm a second time and alias the app name
[06:06] <hpidcock> ok
[06:07] <hpidcock> weird how the "subordinate-to" field is an array
[06:07] <wallyworld> hmmm, maybe i'm wrong then
[06:07] <wallyworld> i would have been 99.9% sure i was right
[06:17] <hpidcock> yeah I'm getting more and more confused as I read the code
[06:19] <hpidcock> processApplicationRelations in apiserver/facades/client/client/status.go
[06:19] <hpidcock> makes me think it "could"
[10:11] <stickupkid> I find it interesting that on first use of juju, we break --format directives :|
[14:08] <gnuoy> stickupkid, do you know when the next release to pypi might be for libjuju ?
[14:09] <stickupkid> gnuoy, might be worth pinging rick_h
[14:09] <gnuoy> stickupkid, ack, thanks
[14:19] <rick_h> gnuoy:  sorry, it'll be after the break I think. There's some WIP that's going into the next release for some missing items that we're doing on roadmap
[14:20] <gnuoy> rick_h, sure, np, thanks
[14:20] <rick_h> gnuoy:  the other half of Juju is doing them so I don't have really solid insight into what % of the way they are but it feels a bit like there's another weekish of work there
[16:35] <achilleasa> hml: I am looking at the code in runner/debug/server.go:43. Can you tell how it figures out what script to run?
[16:36] <hml> achilleasa:  looking
[16:37] <hml> achilleasa:  I think i know - HO?
[16:37] <achilleasa> give me 5'
[16:38] <hml> achilleasa:  sure - it’s related to juju debug-hooks
[16:49] <hml> achilleasa:  a hook is not actually run, just does setup to the debug-hooks tmux session to let the user know what hook would have been run.  so the user can run it themselves and debug the results, try again etc.
[16:50] <hml> we do need a way to “hook” into that for process-hook.
[16:54] <achilleasa> hml: can you join daily?
[16:54] <hml> achilleasa:  omw
[22:01] <babbageclunk> wallyworld: ah, so it seems the problem is that it's an interface{} wrapping another interface{} wrapping the real type, and the checker machinery is only going down one level?
[22:02] <wallyworld> babbageclunk: yeah, i think that's the case
[22:02] <babbageclunk> awesome - thanks for picking that apart! Think I've got all of the other tests fixed, just incorporating that now.
[22:03] <wallyworld> awesome
[22:29] <babbageclunk> wallyworld: hmm, I don't think that does it - that code always succeeds, even if the result type is wrong
[22:31] <babbageclunk> ie, I've changed the newResult func to use the wrong type, and I can't get the test to fail
[22:32] <wallyworld> hmmm, well that sucks
[22:33] <wallyworld> babbageclunk: this line is meant to cater f rot that
[22:33] <wallyworld> _, ok := result.(interface{}).(*params.RelationUnitsWatchResult)
[22:33] <wallyworld> ok should be false if the type is wrong surely?
[23:09] <babbageclunk> doesn't seem to fail...
[23:09] <babbageclunk> wallyworld: oh yeah - that fails, but it also fails if the type is right.
[23:18] <hpidcock> small forward port from 2.7 - develop https://github.com/juju/juju/pull/11048
[23:22] <babbageclunk> hpidcock: did you have any conflicts?
[23:22] <hpidcock> 0 conflicto
[23:22] <babbageclunk> sweet
[23:23] <babbageclunk> I'm going to get so many when I merge the remaining cmr/appdata stuff
[23:23] <babbageclunk> really looking forward to it
[23:23] <hpidcock> pffft, you'll only have 5000
[23:26] <babbageclunk> hpidcock: approved anyway
[23:27] <hpidcock> thanks :)
[23:34] <wallyworld> babbageclunk: i ran the unit test with the code i pasted and it worked as expected when the type was correct
[23:34] <wallyworld> i didn't test when the type was wrong, but i can't see how it wouldn't fail
[23:35] <babbageclunk> :(
[23:35] <babbageclunk> might try in the debugger
[23:37] <wallyworld> so it passes for you? but dosn't fail?
[23:39] <babbageclunk> no, that check always fails
[23:39] <babbageclunk> if I take it out, the res.Set always succeeds
[23:39] <wallyworld> whaaaat
[23:40] <babbageclunk> ikr
[23:40] <wallyworld> maybe get someone else to pull the code and try it
[23:40] <babbageclunk> Looking at the watcher code I can see that I'm missing a case where the watch result has an error - I'm going to handle that and then tweak the test some more
[23:40] <babbageclunk> wallyworld: you don't believe me! It's true though
[23:41] <hpidcock> I'm happy to help, let me know
[23:44] <babbageclunk> thanks hpidcock - just trying something else, will v likely hit you up after that
[23:52] <babbageclunk> ugh, trying to read the json unmarshalling code to see how it manages to store info into the result in this circumstance
[23:54] <babbageclunk> yeah, that's too Lovecraftian for my taste


[02:24] <emgent> hello there, in #ubuntu-hardened is avaiable a bot (nick ubuSecurity) that paste in realtime CVE advisory, bugtraq advisory and milw0rm POC. if someone is interested please join. :)
[05:36] <Hobbsee> youch.  broken gnome.
[05:37] <TheMuso> Hobbsee: Its not so bad if you have the latest updates.
[05:38] <TheMuso> Not so bad, as in, working properly.
[05:38] <TheMuso> However, I don't know what you are meaning by broken.
[05:38]  * Hobbsee is updating again, in the hope that it goes away
[05:39] <ScottK2> Gnome would go away if you'd switch back to Kubuntu ...
[05:39] <Hobbsee> heh.  there is that
[05:40] <ScottK2> Sorry.  Couldn't resist.
[05:42] <Chipzz> Hobbsee: update gnome-session and logout
[05:43] <Chipzz> Hobbsee: alternatively, unset G_DEBUG in a terminal and run the crashing application from there
[05:43] <Hobbsee> gnome-session said it fell over
[05:44] <Hobbsee> Fetched 60.3MB in 7min47s (129kB/s)
[05:44] <Hobbsee> sob.
[05:44]  * Hobbsee prefers fetching at 3006kB/s
[05:44] <Chipzz> Hobbsee: seb128 forgot to patch out what makes fatal warnings crash applications; it's fixed in the last upload
[05:45] <Chipzz> but since it's an environment variable set by gnome-session you need to log out
[05:45] <Hobbsee> that's fine.  i have bip :)
[05:45] <Chipzz> bip?
[05:45] <Hobbsee> bip irc proxy
[05:45] <Chipzz> ah
[05:45]  * Chipzz just uses screen/irssi :P
[05:46] <Hobbsee> terminal lover :P
[05:46] <Chipzz> you betcha :)
[05:47]  * Chipzz also uses mutt ;P
[05:49]  * realist wonders if Chipzz also uses lynx
[05:56] <Chipzz> realist: are you crazy? :P
[05:56] <Chipzz> at the very least, links :P
[05:56] <Chipzz> and even then preferable elinks :P
[05:57] <Chipzz> but no, I do not, or allmost not :)
[05:57] <Chipzz> except when I need to download something on a remote server (like from sf)
[05:57] <realist> wget/curl :-)
[05:58] <Chipzz> which does not work for sf
[05:58] <Chipzz> just gives you some nice html :P
[05:58] <realist> html2text
[05:58] <Chipzz> I'm really sure tar will grok that :P
[05:58] <realist> I'd forgotten sf did that
[05:59] <Chipzz> well I guess you *can* download directly from sf
[05:59] <Chipzz> except most links are links to the download.php pages and not direct links
[05:59] <Chipzz> which still leaves you nowhere
[06:00] <Chipzz> realist: also, wget lacks a feature to save some downloads under the correct filename
[06:00] <TheMuso> If you want text mode browsing, elinks is the only one worth considering.
[06:01] <Chipzz> ie if you have a php page which adds information about the file name (forgot what the exact http header is), wget will not use that and save your download as bla.php
[06:01] <realist> TheMuso: reason being?
[06:01] <Chipzz> realist: support for https for starters
[06:02] <realist> lynx has that doesn't it?
[06:02] <Chipzz> compared to plain links, that is
[06:02] <Chipzz> but lynx doesn't do tables. at all.
[06:02] <Chipzz> which... sucks. big time
[06:05] <FrankQ> you mean you don't use the Stallman method??
[06:05] <FrankQ> http://lwn.net/Articles/262570/
[06:05] <realist> FrankQ: we were joking about that at LCA yesterday
[06:07] <FrankQ> I would get so agitated with a method like that
[06:07] <Chipzz> realist: but really, mutt *does* have some extremely handy features which I have not found in any other mailer yet
[06:07] <realist> Chipzz: such as?
[06:08] <Chipzz> realist: do you know about link-threads and break-thread in vim?
[06:08] <Chipzz> very convenient for people with broken mailers you'ld like to give a kick on the butt :P
[06:08] <realist> in vim?
[06:08] <Chipzz> errr
[06:08] <Chipzz> in mutt
[06:08]  * realist nods
[06:09] <Chipzz> you can join threads which get broken by people with broken mailers which fail to add references headers
[06:09] <realist> I like the pattern tagging, and tag commands too
[06:10] <Chipzz> and you can break threads for those bloody morons who have to hit reply on a random message in a thread instead of just copy/pasting the to: and starting a new one
[06:10] <realist> It does gpg out of the box too, these days
[06:10] <Chipzz> don't really care about pgp atm though
[06:11] <Chipzz> maybe at some point in the future
[06:11] <Chipzz> but you don't happen to know another mailer that has these features?
[06:11] <TheMuso> realist: Customizable keyboard commands, tables, javascript thanks to libmozjs0d/xulrunner, https, bookmarks, cookies, and a lot more that I haven't thought of. :p
[06:12] <realist> TheMuso: nice, I'll have to try it out.
[06:12] <Chipzz> TheMuso: but regular links also has a lot of those features
[06:12] <realist> Chipzz: no, I use mutt.
[06:12] <Chipzz> TheMuso: cookies, bookmarks, tables...
[06:12] <realist> Chipzz: lynx doesn't :-)
[06:12] <TheMuso> Chipzz: WHich links? links2, links, or lynx?
[06:13] <TheMuso> Chipzz: But no javascript
[06:13] <TheMuso> ChipzzOh thats right, elinks also allows you to use $EDITOR for editing multi-line form fields.
[06:14] <Chipzz> TheMuso: I don't use elinks *that* much ;)
[06:15] <TheMuso> Chipzz: Well I do, so thats why I love what it can do compared to the rest of the text mode browsers.
[06:17] <Chipzz> TheMuso: anyway: 06:56 < Chipzz> and even then preferable elinks :P
[06:17] <TheMuso> heh
[06:27] <pitti> Good morning
[06:34] <Hobbsee> morning pitti!
[06:35] <pitti> Good morning Hobbsee!
[07:05] <superm1> is update-manager-core going to be entering dapper-proposed for testing dapper-hardy server upgrades, or is there a different plan?
[07:11] <superm1> well i guess i see bug 186694
[07:11] <ubotu> Launchpad bug 186694 in update-manager-core "update-manager-core dapper backport" [Undecided,New] https://launchpad.net/bugs/186694
[07:11] <warp10> Good morning
[07:11] <superm1> i dont suppose it's been released into dapper-proposed yet then
[07:14] <emgent> warp10, morning
[07:15] <warp10> hi emgent ;-)
[07:17] <superm1> yeah its sitting in the NEW queue yet. https://launchpad.net/ubuntu/dapper/+queue?start=20
[08:03] <dholbach> good morning
[08:05] <goobsoft> Does anyone know why I'm getting a 404 error on my PPA on launchpad?
[08:05] <goobsoft> http://ppa.launchpad.net/goobsoft/ubuntu
[08:07] <goobsoft> I just set it up... is there a delay?
[08:20] <pitti> soren: hm, did you ever try virt-manager with compiz? they don't seem to like each other very well :/
[08:22] <stgraber> moin
[08:23] <soren> pitti: Yeah, there's a bit of focus-oddness going on there.
[08:23] <soren> pitti: I assume that's what you're talking about?
[08:23] <pitti> soren: by default the window title bar of a VM is invisible, then I have *two* mouse cursors, and fullscreen doesn't work
[08:24] <soren> pitti: I'm not sure how much of that is compiz-specific?
[08:24] <pitti> hm, and now the kernel just panicked again, darn
[08:24] <soren> Guest, I assume?
[08:24] <pitti> no, the host
[08:24] <soren> Erk.
[08:24] <pitti> soren: might also be bugs in the vnc viewer, not sure
[08:25] <pitti> should try with metacity
[08:25] <pitti> soren: (don't worry, that kernel panic happens to 2.6.24 about twice a week on my laptop, nothing kvm specific as it seems)
[08:26] <soren> phew..
[08:27]  * soren wipes the sweat off his brow
[08:48] <pitti> soren: FYI, xen-3.2 NEWed
[08:52] <soren> pitti: Thanks.
[08:59] <borschty> pitti: hello, i have a short question about the esd-multiuser-patch you wrote some years ago (http://people.ubuntu.com/patches/esound.multiuser.diff)
[09:00] <pitti> borschty: hello
[09:00] <borschty> https://bugs.launchpad.net/ubuntu/+source/esound/+bug/177072 i have described it in the last post
[09:00] <ubotu> Launchpad bug 177072 in esound "AUDIODEV should be exported when using pulseaudio" [Wishlist,Invalid]
[09:01] <pitti> borschty: that bug is still on my TOOD list, haven't found time to look at it yet
[09:01] <borschty> well the bug itself is closed now, but i think the patch might contain a small leak
[09:03] <borschty> not really important stuff, if you have to smash some real bugs, this can wait
[09:03] <TheMuso> pitti: What is involved to get that AUDIODEV environment variable exported? Does that have to be done within pulse itself?
[09:03] <seb128> TheMuso: why do you need that? looks like that was a workaround when libesd what broken but it's fixed now
[09:04] <TheMuso> seb128: pitti said its somethign that still needs doing, or so I thought...
[09:04] <borschty> yes, it was a workaround, i guess i should have changed the description, but i did not want to spam the subscribers
[09:05] <borschty> the actual bug is fixed, but i suspect the patch to introduce a small memory leak
[09:06] <pitti> ok, if the AUDIODEV one was fixed with the re-applying of the libesd patch, great
[09:06] <pitti> borschty: ok, thanks for pointing out; I'll have a look and fix the memleak
[09:11] <xivulon> evand did you see my msg yesterday night?
[09:20] <seb128> soren: is kvm known to not install correctly?
[09:20] <seb128> soren:  * Module kvm_intel failed to load
[09:20] <seb128> soren: Operation not supported
[09:21] <carlos> seb128: is it known that latest evolution in Hardy crashes after sending an email? (I'm not sure it would be related, but I use SMTP + SSL). The email is not sent and it's lost
[09:22] <seb128> carlos: upgrade gnome-session and restart GNOME or unset G_DEBUG
[09:22] <seb128> carlos: that has been fixed yesterday, we had the warnings crashers code enable by mistake for a day
[09:23] <carlos> hmm, I think I had that fix already installed... but let me restart it, just in case...
[09:23]  * carlos restarts
[09:25] <soren> seb128: Does your machine support kvm?
[09:25] <soren> seb128: (grep vmx /proc/cpuinfo)
[09:25] <seb128> soren: I supposed so, that's a D630
[09:26] <seb128> I didn't enable the bios option most likely though
[09:26] <seb128> but the package install should not fail anyway
[09:26] <soren> seb128: dmesg will tell you if that's the case.
[09:26] <seb128> what should I look for there?
[09:26] <soren> kvm: Disabled in BIOS
[09:26] <soren> or something like that.
[09:26] <seb128> $ dmesg | grep kvm
[09:26] <seb128> [ 1516.217209] kvm: disabled by bios
[09:27] <soren> There you go.
[09:27] <seb128> soren: that was expected, still the package should install?
[09:27] <soren> Should it?
[09:27] <seb128> soren: well, I see no valid reason to break installations
[09:28] <carlos> seb128: seems like that's it. At least that also fixed pidgin :-P
[09:28] <soren> Well, if you don't have the hardware, it can't be configured.
[09:28] <seb128> soren: if I install the intel video driver on a box using nvidia it doesn't fail ;-)
[09:28] <pitti> the package should always succeed to install
[09:28] <mvo> ++
[09:28] <seb128> soren: you should display a warning but not break the install
[09:28] <pitti> and if it doesn't work, the init script would ideally point out why
[09:28] <carlos> also, for some reason, all emails I sent appear in the outbox folder so I didn't lose data
[09:28] <carlos> seb128: thanks for your help
[09:28] <seb128> carlos: you are welcome
[09:28] <soren> I'm certain there was a discussion about this at some point where the opposite conclusion was reached.
[09:28] <seb128> weird
[09:29] <pitti> soren: I guess at some point you want to ship the package by default on the server image?
[09:29] <mvo> on a list or in a channel?
[09:29] <mvo> I have very strong opinions about failing maintainer scripts
[09:29] <soren> mvo: Yes :)
[09:29] <seb128> is there anybody here who argued for breaking installation?
[09:29] <soren> seb128: Come on..
[09:29] <seb128> me too, package installation should never break
[09:29]  * mvo looks around to see if he can find his stick-of-doom
[09:29] <seb128> just add a || true in the postinst
[09:29] <seb128> and display a warning
[09:29]  * Hobbsee offers mvo the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! ™
[09:29] <pitti> whoever proposed that should be sentenced to one week of triaging apport package inst failure bugs
[09:30] <soren> "So, guys, what do you think? I think we should break isntallation of stuff."
[09:30] <soren> seb128: I'm perfectly aware of the mechanics involved.
[09:30] <mvo> and update-manager bug triage too
[09:30] <seb128> soren: I'm surprised you seem to argue that's not a bug
[09:31] <soren> seb128: I'm surprised to see you argue the way you do. Can we please focus on the problem rather than resort to stuff like "is there anybody here who argued for breaking installation?"
[09:31] <soren> Ok, the argument, as I remember it, went:
[09:32] <soren> If the package will be unable to function after installation, it's wrong to have dpkg claim that it's configured, since.. well... it's not.
[09:32] <davmor2> Guys just to say that the nautilus-cd-burner patch has fixed only being able to burn one cd :)
[09:33] <pitti> but configuring a package just means that it's properly installed, not necessarily working
[09:33] <pitti> otherwise we could not install any printer or X.org graphics driver by default either
[09:33] <seb128> soren: well, as said you can install the intel video driver on a nvidia machine, it'll not work but that's alright
[09:33] <pitti> the init script should fail, sure
[09:34] <davmor2> What causes two windows to open when ever you insert a cd or pen drive though.  Is there anything I can do to track it down or is it already being worked on?
[09:34] <seb128> davmor2: that's a feature, nothing to track down, go to nautilus preferences, media tab and uncheck the option if you don't want it
[09:35] <soren> It's not something I feel very strongly about.
[09:35] <seb128> davmor2: ah, the duplicate window, that's known
[09:35] <pitti> seb128: two windows for one driver?
[09:35] <pitti> drive
[09:35] <seb128> pitti: I read too quickly
[09:35] <pitti> ah, ok
[09:35] <davmor2> seb128: okay cool :)
[09:35] <pitti> 118 sync bugs? ugh
[09:35] <seb128> basically gvfs mount drivers on first access now
[09:35] <soren> Where is the dpkg status semantics documented? I can't seem to find it.
[09:35] <mvo> soren: I see your point, but I think with the tools we currently have we can not follow that for practical reasons. we have no good recovery mechanism for package failures, we can not do rollbacks and a package failure during a complex upgrade causes cascadigng errors or stop of the upgrade
[09:36] <seb128> pitti: I didn't do syncs because of the freeze ...
[09:36] <pitti> soren: ... that, and it would forbid us to install that package by default
[09:36] <mvo> I think even if we wanted to follow that definition we would first have to fix the tools
[09:36] <pitti> seb128: np; you've been busy enough
[09:36] <seb128> but we have too many sync requests I agree
[09:37] <seb128> we should really consider this automatic sync new revisions for universe packages
[09:37] <davmor2> I'm just happy I can burn all the iso's again without resorting to rebooting the machine :)
[09:37] <seb128> davmor2: you can use brasero now if n-c-b is broken
[09:37] <seb128> you should not need to reboot
[09:38] <soren> IIRC, it was iwj that was making the point I'm trying to make now, so it's not entirely inconceivable that it was more of a "this is how things are supposed to be" rather than "this is how we should actually do it" :)
[09:39] <seb128> soren: right
[09:39] <seb128> soren: the current situation is not nice because it'll let apt in a broken state you can't resolve with graphical tools easily
[09:39] <soren> seb128: True.
[09:39] <seb128> and will prevent you to install anything else
[09:40] <seb128> which will lead to pretty bad users comments
[09:40] <seb128> anyway, rebooting to set the bios option now ;-)
[09:41] <soren> \o/
[09:41]  * soren has amd hardware now for testing kvm.
[09:41] <mvo> well, it let you install stuff, but you always get the error and stuff. I think that the package level is the wrong layer for this kind of tests
[09:41] <davmor2> seb128: brasero didn't work for the same reason as n-c-b as far as I could figure.  It would burn one cd perfectly but the next cd you put in would fail.  Not sure if it was the n-c-b fix or gvfs but it is working now which is the good news :)
[09:42] <pitti> soren: yay new toys!
[09:42] <soren> mvo: I think the argument could be made both ways. However, as the tools are now, I can see why making the install succeed makes sense.
[09:42] <stgraber> I'm going through the bugs reported on the tracker, we have bug 187898 and bug 186711 looking quite similar, can some confirm that I can set bug 187898 as dupe of bug 186711 ?
[09:42] <ubotu> Launchpad bug 187898 in ubiquity "Stuck on "Removing conflicting operating system files"" [Undecided,New] https://launchpad.net/bugs/187898
[09:42] <soren> pitti: Yeah, and it's on a decent pipe, too :)
[09:42] <soren> 09:26:05 (9.67 MB/s) - `hardy-desktop-amd64.iso' saved [721704960/721704960]
[09:42] <ubotu> Launchpad bug 186711 in partman-target "The installer needs to remove operating system files from the install target, but was unable to do so. The install cannot continue" [Undecided,Fix released] https://launchpad.net/bugs/186711
[09:44] <pitti> soren: WANNAHAVETOO
[09:45] <mvo> soren: woah!
[09:46] <soren> It's not that expensive, really. €59/month.
[09:46] <soren> Deductible, even :)
[09:47] <seb128> re
[09:47] <seb128> soren: better now ;-)
[09:47] <mvo> I get a bit agitated about failing maintainer scripts, they just come up way too often in failed upgrades where it could have been avoided
[09:47] <soren> I hear you, I hear you. It's changed in the next upload.
[09:48]  * mvo hugs soren
[09:52] <soren> O_O
[09:52]  * soren eyes netcat-openbsd in Debian
[09:52] <soren> \o/
[09:55] <seb128> soren: waouh, kvm is very easy to use once installed, good work ;-)
[09:56] <seb128> current hardy image booted correctly
[09:56] <pitti> seb128: you used virt-manager?
[09:56] <seb128> pitti: I did what is written on the wiki page
[09:57] <seb128> yes
[09:57] <seb128> it's on my D630 and work like charm, out of usplash which is not displayed
[09:58] <seb128> but it took less than one minute to boot and I've the standard desktop usuable now
[10:00] <seb128> hum
[10:00] <seb128> the virtual network thing might not be what I want, I've not internet access from the image
[10:01] <stgraber> We have very little results on the tracker, so when you guys are doing testing please think of reporting your results : http://iso.qa.ubuntu.com/qatracker/build/all/all
[10:06] <pitti> seb128: argh, syncbugbot gets this "AssertionError: Wrong XPath-Expr in InfoTable.parse()" exception
[10:06] <pitti> seb128: was it that one which you recently fixed in the retracers?
[10:06] <seb128> pitti: somebody should upload a new python-launchpad-bugs
[10:06] <seb128> pitti: yes, that's fixed in bzr for some time now
[10:06] <pitti> dholbach, thekorn: any plans for uploading a new p-lp-bugs?
[10:06] <seb128> that's a one line change
[10:07] <pitti> seb128: ok, I'll dig into the bzr
[10:07] <pitti> I need to manually roll it out to drescher anyway
[10:07] <seb128> pitti: http://launchpadlibrarian.net/11477436/184594.diff
[10:07] <dholbach> pitti: I asked bdmurray he said "today or tomorrow"
[10:07] <soren> seb128: usplash will work when the new kernel lands, by the way.
[10:07] <pitti> dholbach: thanks
[10:07] <pitti> seb128: merci!
[10:07] <seb128> soren: good
[10:08] <seb128> pitti: you are welcome
[10:08] <soren> seb128: What type of networking did you choose?
[10:08] <soren> seb128: Virtual (the default)?
[10:08] <seb128> soren: the one you recommend, virtual, it's not on the right network though and the preferences dialog doesn't let me edit that
[10:08] <seb128> I need to change the .122
[10:09] <soren> seb128: I don't quite follow..
[10:10] <pitti> seb128: hm, that didn't help
[10:11] <seb128> soren: the virtual network use <IP_ADDRESS>, shouldn't it be on the same network than my router if I want to go on internet?
[10:11] <seb128> pitti: weird, that did the trick for the retracers
[10:11] <soren> seb128: No, it's separate. It sets up nat by default, though.
[10:11] <seb128> pitti: maybe you have a pyc?
[10:11]  * pitti pokes it harder
[10:12] <soren> seb128: If you install dnsmasq, dhcp will be enabled in the virtual network.
[10:12] <soren> (install dnsmasq and restart libvirtd, that is)
[10:12] <seb128> soren: doing that
[10:12] <soren> (I'm adding dnsmasq as a dependency of libvirt-bin real soon, by the way)
[10:13] <soren> Whose archive day is it?
[10:13] <seb128> pitti's
[10:14] <seb128> hum
[10:14] <seb128> soren: I get a non bootable device error in the vm now
[10:15] <soren> pitti: Will you be able to look at bug 187983 and bug 187986 today? And do the subsequent binary new for netcat and source+binary new for netcat-openbsd?
[10:15] <ubotu> Launchpad bug 187983 in netcat "Please sync netcat (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/187983
[10:15] <ubotu> Launchpad bug 187986 in ubuntu "Please sync netcat-openbsd (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/187986
[10:15] <pitti> soren: yes, I'm currently processing sync bugs
[10:15] <soren> seb128: Right. The CD is only attached when you run it the first time, and it will only boot from CD the first time as well.
[10:15] <pitti> soren: and as soon as I fix that python-launchpad-bugs thingy, I'll be able to commit the syncs
[10:15] <seb128> soren: so I need to recreate the machine every time?
[10:15] <soren> pitti: Cool. It's the final piece of the puzzle to enable remote libvirt management.
[10:16] <soren> seb128: You can tweak the xml by hand.
[10:16] <soren> seb128: Otherwise, yes. There's a bug open about it upstream.
[10:16] <soren> seb128: If they don't get around to it soon, I'll be looking into it myself.
[10:16] <seb128> ok, thanks
[10:17] <pitti> thekorn: hm; on p-lp-bugs main head I still get "Wrong XPath-Expr in InfoTable.parse()" for bug 186856
[10:17] <ubotu> Launchpad bug 186856 in apache2 "Please sync apache2 2.2.8-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/186856
[10:17] <seb128> soren: can you point me to what to change exactly?
[10:17] <soren> seb128: I'm writing it for you already. Hang on :)
[10:17] <seb128> good ;-)
[10:17] <seb128> thanks!
[10:19] <soren> seb128: http://paste.ubuntu-nl.org/54315/
[10:19] <davmor2> what's jockey-gtk?
[10:21] <seb128> davmor2: restricted manager renamed
[10:21] <seb128> soren: where is the xml? .virt-manager only has a .log
[10:23] <davmor2> seb128: ah okay so the fix released will be effective after the release of alpha4 then?
[10:23] <soren> seb128: /etc/libvirt/qemu
[10:23] <seb128> davmor2: what fix released?
[10:25] <davmor2> seb128:  bug 187139
[10:25] <ubotu> Launchpad bug 187139 in jockey "jockey-gtk crashed with AssertionError in __init__()" [Undecided,Fix released] https://launchpad.net/bugs/187139
[10:26] <thekorn> pitti: ok, can reproduce this, will have a closer look at this in about an hour
[10:30] <pitti> thekorn: thank you muchly!
[10:31] <seb128> virt-manager doesn't play nicely with compiz
[10:31] <pitti> heh, just what I said above :0
[10:32] <soren> If any of you have any clever hints about that, please don't hesitate to enlighten me.
[10:32] <seb128> soren: bug mvo until he fixes compiz? ;-)
[10:33] <soren> seb128: Sounds like a plan :)
[10:34] <pitti> seb128: ok, I prepared the current syncs as syncbugbot list in ~pitti/s; not committing, since (a) we are still in freeze, and (b) we need a fixed p-lp-bugs
[10:34] <seb128> pitti: ok
[10:38] <pitti> Riddell: why did you remove the ((qApp) && (qApp->type() == QApplication::Tty)))
[10:38] <pitti> Riddell: in the gtk-qt-engine SRU?
[10:39] <Riddell> pitti: which distro release?
[10:39] <pitti> Riddell: gutsy
[10:39] <pitti> http://launchpadlibrarian.net/11630805/gtk-qt-engine_0.8~svn-rev36-2ubuntu2.1.debdiff
[10:40] <Riddell> pitti: looks like an error, please reject and I'll upload a fixed one when my machine is done with this test install
[10:40] <pitti> Riddell: ok
[10:41] <pitti> Riddell: also, it would be helpful to describe the "why" of that patch in the changelog
[10:41] <pitti> Riddell: stl. like 'nspluginviewer crashes when using the gtk-qt engine' or whatever the reason is
[10:41] <Riddell> pitti: ok
[10:41] <Riddell> (it stops it freezing)
[10:42] <pitti> Riddell: rejected
[10:50] <pitti> Riddell: gutsy's kdelibs update has a vast debdiff, mostly just +X-Ubuntu-Gettext-Domain and a changed files list; that's confirmed to not hurt, or break the .desktop/other files?
[10:51] <pitti> Riddell: I don't think that the X-Ubuntu-Gettext-Domain tags make sense in most of the .desktop files
[10:52] <Riddell> pitti: hmm, sorry, they should all get cleaned out, reject it and I'll take a look in a minute
[10:52] <pitti> Riddell: the patch itself looks reasonable
[10:52] <pitti> Riddell: will do, thanks
[10:55] <pitti> wow -- kdebase b-deps on libglib2.0-dev now?
[10:56] <pitti> seb128: I wasn't aware that gnome world dominance was that close already :-P
[10:56] <ogra> evolution ... the app that has a new exciting bug for you every day ....
[10:56] <Riddell> pitti: mm, well it's a workaround for flash requiring it
[10:56] <pitti> Riddell: (just kidding)
[10:57]  * ogra sighs ... and installs the evolution-dbg package to provide something useful to seb128
[10:57] <seb128> pitti: joke aside glib has no gnome depends and is nice, KDE could be using it for other things ;-)
[10:57] <seb128> ogra: what happens now?
[10:57] <ogra> seb128, chrashes while sending
[10:58] <seb128> ogra: that's so yesterday's, did you update gnome-session and restart GNOME?
[10:58] <ogra> it bumps up to 100% CPU usage for a while and then crashes
[10:58] <seb128> ogra: is G_DEBUG set?
[10:58] <ogra> hmm, i had to update 25 packages this morning, let me restart the session (even though i think i did that yesterday evening)#
[10:59] <seb128> ogra: look if G_DEBUG is set
[11:00] <ogra> doesnt seem like
[11:00] <pitti> Riddell: ugh, heavy patch; there's no way I can eyeball this for correctness; I think we just need to test it very thoroughly
[11:00] <seb128> ogra: env | grep G_DEBUG?
[11:01] <ogra> nope
[11:01] <seb128> k, weird
[11:01] <seb128> so maybe you have an another bug
[11:01] <seb128> get me the backtrace ;-)
[11:01] <seb128> a non debug one will do for a quick glance
[11:01] <ogra> meh, apport didnt have it :/
[11:02]  * ogra sends another mail to reproduce
[11:02] <ogra> hmm
[11:03] <ogra> send/recieve worked this time ... it crashed before
[11:03] <pitti> Riddell: flashplugin-nonfree isn't updated yet in hardy, right?
[11:03] <seb128> ogra: did you restart your session between?
[11:03] <ogra> yup
[11:03] <seb128> ogra: so that was the G_DEBUG issue
[11:03] <ogra> the mail that made it crash was sent but also still sitting in oubox
[11:04] <Riddell> pitti: yes it is
[11:04] <seb128> ogra: unstable gnome-session set G_DEBUG to turn critical warnings to crashers, we usually disable that but the patch was not in the series
[11:04] <ogra> ah
[11:04] <pitti> Riddell: nothing obvious in the changelog
[11:04] <ogra> well, seems to work now
[11:04] <seb128> ogra: I fixed that yesterday, that took only effect after you restarted the session though
[11:04] <seb128> ogra: yeah, likely that was due to it
[11:04] <ogra> yeah
[11:04] <ogra> thanks
[11:04] <seb128> you are welcome
[11:04] <asac> bryce: are there still known dpi issues in X (if so, what would be the right X bug for bug 178558)?
[11:04] <ubotu> Launchpad bug 178558 in firefox-3.0 "Firefox 3.0 makes everything annoyingly huge" [Undecided,Confirmed] https://launchpad.net/bugs/178558
[11:05] <Riddell> pitti: it's version 9.0.115
[11:05] <pitti> Riddell: ah, thanks; marking as fixed then
[11:08] <pitti> Riddell: gtk-qt-engine> dapper looks fine, edgy and feisty have the same problem; I'll keep track of it in the bug
[11:13] <ogra> hmm, why did nautilus stop to display the gartoon icons :/
[11:14] <seb128> ogra: where?
[11:14] <ogra> on my recently upgraded laptop
[11:14] <seb128> I meant what icons?
[11:14] <seb128> are the menus using correct icons?
[11:14] <ogra> (the one that just had the evo issue)
[11:14] <ogra> yes
[11:15] <ogra> places shows the gartoon folders
[11:15] <ogra> panel icons are fine as well
[11:15] <ogra> in a nautilus window everything above the location bar is correct
[11:15] <ogra> below it shows the fallback icons
[11:17] <ogra> hman theme seems to work ... i bet gartoon is missing a change
[11:17] <ogra> *human
[11:21] <tjaalton> asac: dpi issues don't increase the size of the images afaik :)
[11:22] <asac> tjaalton: hmm ... reading the bug it appears that setting the dpi value explicitly in firefox fixes this
[11:23] <tjaalton> asac: ok, maybe it's because 3.0 uses cairo for everything?
[11:23] <asac> tjaalton: maybe it was true in the past that dpi issues didn't affect firefox, but now they zoom images as well.
[11:24] <asac> s/firefox/firefox images/
[11:24] <thekorn> pitti: py-lp-bugs is broken, parsing of bugreports in edge.launchpad.net is impossible,
[11:24] <pitti> ugh
[11:24] <thekorn> due to a change in edge.lp.net (bug 137448)
[11:25] <asac> tjaalton: maybe; but i think they calculate a scaling factor in firefox itself. most likely cairo just does what they tell it to do
[11:25] <ubotu> Launchpad bug 137448 in malone "New UI is confusing and counter inuitive for changing affected package" [High,Fix committed] https://launchpad.net/bugs/137448
[11:26] <tjaalton> asac: sure. if other apps look normal then I'd say it's indeed an issue with xulrunner
[11:26] <pitti> thekorn: you mean Bjorn's recent fix changed the HTML?
[11:26] <tjaalton> reading the upstream report
[11:27] <asac> thekorn: do you know the page of maybe duplicates you get when reporting a bug. i couldn't get a similar search result using the standard search form, so i wonder whether that search facility is already supported in py-lp-b
[11:27] <thekorn> pitti: yes
[11:28] <thekorn> asac: no such a search is not implemented in py-lp-bugs
[11:32] <xivulon> OT microsoft tries to buy yahoo
[11:33] <Riddell> pitti: gtk-qt-engine and kdelibs re-uploaded
[11:33] <xivulon> now on bloomberg
[11:33] <pitti> Riddell: hm, I just accepted kdelibs/feisty, that looked goo
[11:34] <pitti> d
[11:34] <Riddell> pitti: kdelibs for gutsy only
[11:34] <pitti> ah, good
[11:34] <pitti> Riddell: bug tasks states are up to date ATM
[11:43] <pitti> Riddell: argh, queue tool fooled me; can you please reupload gtk-qt-engine for edgy with bumping the version number?
[11:44] <pitti> sorry
[11:52] <pitti> Riddell: ok, now we have everything except gtk-qt-engine for edgy (the fixed one, see above) and kdebase for edgy and feisty
[11:56] <Riddell> pitti: what's wrong with kdebase for edgy and feisty?
[11:56] <pitti> Riddell: feisty: https://bugs.edge.launchpad.net/ubuntu/dapper/+source/kdebase/+bug/184149/comments/22
[11:56] <ubotu> Launchpad bug 184149 in kdelibs "[hardy]xembed and flash support patches doesn't work for konqueror" [Undecided,Fix committed]
[11:56] <pitti> Riddell: and for edgy it is not in the queue
[12:34] <emgent> !info wordpress
[12:34] <ubotu> wordpress (source: wordpress): an award winning weblog manager. In component universe, is optional. Version 2.2.2-1ubuntu1.2 (gutsy), package size 783 kB, installed size 4196 kB
[12:35] <thekorn> pitti: I added a fix to Bug 188018
[12:35] <ubotu> Launchpad bug 188018 in python-launchpad-bugs "Latest changes in edges.launchpad.net breaks py-lp-bugs" [High,Fix committed] https://launchpad.net/bugs/188018
[12:35] <pitti> thekorn: \o/
[12:43] <pitti> thekorn: I get a bit further now:
[12:43] <pitti>   File "/home/lp_archive/python/launchpadbugs/lptime.py", line 59, in __new__
[12:43] <pitti>     raise ValueError, "Unknown date format (%s)" %time_str
[12:43] <pitti> ValueError: Unknown date format (2008-01-29 00:39:09 CET)
[12:44] <soren> Muhahahah..
[12:44]  * soren has a cunning plan..
[12:45] <dholbach> MOTU Q&A session in 15 minutes in #ubuntu-classroom
[12:45] <thekorn> pitti: oha :(
[12:45] <thekorn> hi dholbach
[12:46] <dholbach> hey thekorn
[12:46]  * pitti hugs thekorn
[12:55] <pitti> Riddell: can you please re-upload edgy gtk-qt-engine with bumping the version number?
[12:55] <Riddell> pitti: done
[12:55] <pitti> Riddell: thanks
[12:55] <Riddell> pitti: working on kdebase, sorry for the delay, it would help if ubiquity would stop deleteing my hard disk
[12:55] <pitti> ugh
[12:57] <Hobbsee> Riddell: well, it would help if you stopped running windows, i'm sure..
[12:58] <Riddell> Hobbsee: hmm?
[12:59] <Hobbsee> Riddell: you were talking a while ago abotu a feature of ubuntu deleting your windows for you, during the install
[12:59] <Hobbsee> the last time that some people's data got wiped out, iirc
[13:01] <_MMA_> seb128: Did TheMuso contact you re: GDM sound issue? He figured out why the little drum noise wasn't playing on new installs.
[13:02] <seb128> _MMA_: no he didn't
[13:03] <_MMA_>  /usr/lib/gdmplay was not executable.
[13:03] <_MMA_> After a "sudo chmod 755 /usr/lib/gdmplay" things worked fine on a Ubuntu and Studio install.
[13:05] <seb128> _MMA_: ok, good, thanks, i'll fix that with the next upload
[13:08] <_MMA_> seb128: Cool. And he found that Studio's login/out, caching error is specific to us. But we're not sure why we get the error on this one file. Maybe there's a play length or file size limit now. I don't know. Worked in Gutsy. :-/
[13:10] <cheguevara> bryce, hi, are you around?
[13:10] <thekorn_> pitti: I'm looking at your last date/time error, can't reproduce this for the given date,
[13:11] <thekorn_> can you give me a bugnumber of a bug where this error occurs
[13:11] <pitti> ok, hang on
[13:12] <cheguevara> or tjaalton
[13:12] <pitti> thekorn_: it's indeed bug 186856
[13:12] <ubotu> Launchpad bug 186856 in apache2 "Please sync apache2 2.2.8-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/186856
[13:13] <pitti> hah
[13:13] <pitti> thekorn_: it seems to fail on    print b.reporter
[13:13] <pitti> thekorn_: where b is a Connector.ConnectBug().Bug() instance
[13:14] <pitti> thekorn_: the actual tasks seem to be ok
[13:14] <thekorn_> pitti: let me check...
[13:36] <davmor2> Xubuntu alternative installs are failing :( bug 188030
[13:36] <ubotu> Launchpad bug 188030 in pkgsel "xubuntu hardy alternative alpha 4 cd fails to install" [Undecided,New] https://launchpad.net/bugs/188030
[13:46] <stgraber> broken deps for libxine1-ffmpeg
[14:02] <pitti> thekorn_: ok, I updated bug 188031; I think I'll just hack around it on drescher; sorry for the noise
[14:02] <ubotu> Launchpad bug 188031 in python-launchpad-bugs "crashes with "ValueError: Unknown date format" on .reporter property" [Undecided,Invalid] https://launchpad.net/bugs/188031
[14:09] <pitti> oh noes, another p-lp-bugs exception
[14:10] <mvo> APIs ftw
[14:17] <ScottK> pitti: If you have a few minutes today, I'd appreciate a chance to discuss the amavisd-new MIR.  There's some tasksel integration work that's blocking on it and with FF two weeks away... https://wiki.ubuntu.com/MainInclusionReportAmavisd-new
[14:18] <pitti> thekorn_: another one for you, sorry: bug 188044
[14:18] <ubotu> Launchpad bug 188044 in python-launchpad-bugs "AttributeError: 'change_obj' object has no attribute 'change_obj__action'" [Undecided,New] https://launchpad.net/bugs/188044
[14:20] <pitti> ScottK: alright; please give me some minutes for this sync wreckage, then I'll do some MIR
[14:20] <ScottK> pitti: No rush.  It's still early morning here.  Thanks.
[14:25] <pitti> thekorn_: ok, another workaround later I could now circumvent above bug and syncs are finally running \o/
[14:28]  * thekorn hugs pitti
[14:28]  * pitti hugs thekorn, master of LP
[14:29] <thekorn> pitti: If I would be the master of LP, then ... ;)
[14:36] <pitti> argh, more of the above; there's another place that uses change_obj__action
[14:38] <pitti> thekorn: you don't happen to have a quickfix for that? I guess it's something trivial, but I can't figure it out without reading the entire code
[14:38] <thekorn> pitti: I'm sorry, this is code from the very beginning of my python experience, let me check the code
[14:39] <tokok> are you accept mono based d-bus?
[14:50] <pitti> thekorn: if I change "change_obj__action" to __action, I get "AttributeError: 'change_obj' object has no attribute '_Attachments__action'"; hmm
[14:55] <thekorn> pitti: give me a second, testing a fix
[14:58] <pitti> StevenK: libosso reviewed, bug updated
[14:59] <pitti> Riddell: so, only kdebase for feisty-proposed is missing now, rest is in -proposed
[14:59] <pitti> Riddell: what an update, that must have cost you ages to prepare *hug*
[15:06] <thekorn> pitti: added patch to Bug 188044
[15:06] <ubotu> Launchpad bug 188044 in python-launchpad-bugs "AttributeError: 'change_obj' object has no attribute 'change_obj__action'" [Undecided,New] https://launchpad.net/bugs/188044
[15:07] <thekorn> pitti: I have to leave now, I will have a closer look at the bugs over the weekend
[15:07] <pitti> thekorn: you rock
[15:07] <pitti> thekorn: thank you! and enjoy the weekend
[15:07] <thekorn> you too
[15:29] <zul> pitti: ping
[15:29] <pitti> zul: pong
[15:29] <zul> for ibmasm there was no source for it so it is sitting in new
[15:30] <pitti> zul: ah, I see; let me take a look at it then
[15:30] <zul> pitti: thanks
[15:30] <zul> ill file a MIR after you have a look
[15:33] <Riddell> pitti: kdebase for feisty-proposed uploaded now
[15:36] <pitti> zul: NEWed
[15:36] <zul> pitti: thank you
[15:36] <zul> ill do the mir report right now
[15:40] <geser> pitti: Hi, please give-back aspectwerkz2. It failed to upload. Thanks
[15:42] <pitti> geser: done
[16:00] <davmor2> guys I've just tried an encrypted lvm install of Ubuntu it's been 2 hours and it's still erasing the drive
[16:01] <pitti> davmor2: don't you have a cancel button there?
[16:01] <pitti> you should be able to skip this
[16:02] <stgraber> pitti: why has this setting been changed ? wasn't it set not to entirely erase the disk on Gutsy ?
[16:05] <davmor2> pitti: The gutsy version takes no longer than a normal install.
[16:06] <pitti> stgraber: it was; but since it's still useful for paranoia reaons, adding a 'skip' button seemed better
[16:06] <pitti> davmor2: right; my Q is, do you actually have a cancel/skip button there and does it work?
[16:07] <davmor2> pitti:  I've hit cancel now yes.  Maybe change cancel to skip might be better.  I didn't want to cancel the install
[16:07] <pitti> davmor2: that's a good point; can you please file a bug about this?
[16:07] <davmor2> pitti no probs
[16:08] <pitti> davmor2: thanks a lot for testing
[16:09] <davmor2> well can't code, the bug reports are getting too technical it's about the only way left for a dyslexic to help out :)
[16:09] <davmor2> pitti: what do you want the bug filing against d-i
[16:10] <pitti> davmor2: hm, not sure; evand? partman-something?
[16:10] <pitti> davmor2: d-i is fine as a default target
[16:10] <davmor2> np
[16:11] <pitti> davmor2: thorough testing and bug reporting are a great contribution, so no need to be shy about it :)
[16:11] <pitti> davmor2: (my wife can't code either, and I still love her :-P)
[16:13] <evand> partman-lvm?
[16:13] <evand> d-i is fine though, it'll get moved where it needs to be
[16:16] <davmor2> evand: pitti: bug 188085
[16:16] <ubotu> Launchpad bug 188085 in debian-installer "debian-installers encrypted erase disc cancel button should read Skip" [Undecided,New] https://launchpad.net/bugs/188085
[16:16] <davmor2> is that okay?
[16:18] <evand> davmor2: looks good
[16:18] <davmor2> okay cool leave it with you then :)
[16:32] <davmor2> Is it safe to start testing the Live cd's or is ubiquity being updated?
[16:32] <slangasek> ubiquity is being updated
[16:33] <davmor2> okay thanks I'll check back latter then :)
[16:53] <pitti> ah, seems I fixed the i386 retracer to properly process duplicate checks for python bugs again
[16:54] <pitti> (I applied a p-lp-bugs which made them throw exceptions)
[16:54] <pitti> ...patch...
[17:03] <jwendell> Hi, seb128. Vino installs its executable in /usr/libexec. Why does ubuntu package install it in /usr/lib/vino/ ?
[17:03] <slangasek> because libexec is not part of the FHS
[17:03] <seb128> jwendell: because on debian and ubuntu libexec=/usr/lib/binary
[17:04] <slangasek> it's subsumed into /usr/lib according to the standard
[17:04] <seb128> binary being the name of your software
[17:04] <jwendell> ok
[17:05] <slangasek> (I wish we /did/ have a separate libexec, but it's a little late to change our minds now :)
[17:05] <seb128> jwendell: is that an issue?
[17:07] <jwendell> seb128, no, I was just trying to debug vino and noticed that I was looking at wrong directory
[17:07] <seb128> ah ok
[17:13] <tjaalton> cheguevara: yes?
[17:26] <cheguevara> tjaalton, sorry was away wanted to talk to you about the intel driver
[17:28] <LaserJock> pitti: do you have an ETA on the next lang pack update?
[17:28] <soren> pitti: Please let me know if there's any problem with the netcat-openbsd package.
[17:28] <pitti> carlos: ^ for gutsy you told me it would be better to do a full export, right? can you trigger this over the weekend?
[17:29] <carlos> pitti: yes, I told you that
[17:29] <pitti> LaserJock: next Monday would be the next regular update
[17:29] <pitti> soren: it's in the sync buffer, I just need to flush; flushing needs to happen after alpha-4 release, though
[17:29] <carlos> pitti: you are able to do it, although I cannot force Gutsy export, it will happen in its next scheduled time (I think it's tonight)
[17:29] <LaserJock> pitti: will they go up on the PPA before?
[17:29] <pitti> LaserJock: they are already
[17:29] <pitti> carlos: ah, right; I'll flip that checkbox
[17:29] <LaserJock> oh, ok
[17:30] <LaserJock> I checked a day or two ago
[17:30] <carlos> pitti: do you remember the page to do it?
[17:30] <soren> pitti: Oh, ok. I just noticed the netcat package getting synced, so I thought you had specifically skipped the -openbsd one.
[17:30] <pitti> carlos: yes, already done
[17:30] <pitti> carlos: I just keep forgetting that I'm now able to do that myself :)
[17:30] <carlos> pitti: ;-)
[17:31] <pitti> soren: hm, indeed
[17:31] <tjaalton> cheguevara: ok, what about?
[17:32] <pitti> soren: right, I didn't process new package syncs yet (need to flush first)
[17:32] <pitti> soren: if it's very urgent, I could cowboy it, but otherwise I'd just do it on Monday
[17:33] <soren> pitti: No, it's not *that* urgent :)
[17:33] <soren> pitti: Monday it is.
[17:33] <soren> Thanks.
[17:33] <pitti> ok, great
[17:34] <carlos> pitti: confirmed, full export will happen tonight
[17:37] <pitti> \o/
[17:40] <mvo> does anyone has a idea what https://bugs.edge.launchpad.net/ubuntu/+source/update-manager/+bug/187889 is about (is that polish?)
[17:41] <ubotu> Launchpad bug 187889 in update-manager "Nové návrhy na překlady v balíku upgrade-manager" [Undecided,New]
[17:41] <geser> mvo: not polish, from the look and the timezone of the submitter I'd say it's czech
[17:42] <tjaalton> yep
[17:45] <slangasek> yes, it's czech.  "New suggestions for the translation of the upgrade-manager package"
[17:47] <slangasek> ... and then a link to a page that mentions no Czech translations being available, so, er
[17:48] <slangasek> oh, apparently you have to click to see all the translations, n/m :)
[17:51] <geser> slangasek: which language do you don't understand? :)
[17:52] <slangasek> geser: Xhosa
[18:17] <cheguevara> tjaalton, abot exa and xaa thing
[18:18] <cheguevara> i really think switching to xaa is a bad idea
[18:18] <cheguevara> the drm modules are getting merged in .25 they can be backported
[18:21] <superm1> pitti, are you still going to go through the new queue again today?  we (mythbuntu team) were hoping to roll new live disks at some point this weekend (preferably with those builds)
[18:34] <slangasek> stgraber: I've failed at getting builds disabled in a timely manner when we knew we'd be rerolling, but FYI I'm pushing a full set of new images because of the partman "eat my old OS" bug identified yesterday
[18:36] <stgraber> k
[18:39]  * mathiaz just finished testing 18 test installation of the isos. Now he can start over.
[18:42] <tjaalton> cheguevara: well, it's a tough decision..
[18:43] <cheguevara> tjaalton, yeah i understand, what does the kernel team say?
[18:46] <tjaalton> cheguevara: it was discussed at UDS and turned down, I'm not sure anything has changed since
[18:48] <cheguevara> tjaalton, i see, is there any possibility of it happening though? xaa is deprecated, has video problems and doesn't support compiz on 965 (i am sure you know all that though)
[18:48] <cheguevara> compiling mm sources right now to see the diffference
[18:48] <Amaranth> but isn't EXA still slower than XAA even with ttm?
[18:48] <tjaalton> cheguevara: I watched the presentation by cworth at lca, and while they have been able to get the performance better, rendering text is still maybe 40% slower
[18:49] <tjaalton> Amaranth: ^^
[18:49] <tjaalton> :)
[18:49] <MacSlow> Amaranth, depends
[18:49] <Amaranth> The only thing EXA is really better at is large fills or whatever
[18:49] <MacSlow> Amaranth, following Carl Worth's blog regarding his work with EXA and related bits of the i965 driver is always very interesting
[18:50] <cheguevara> tjaalton, when was that?
[18:51] <tjaalton> cheguevara: a sec
[18:51] <tjaalton> cheguevara: http://mirror.linux.org.au/pub/linux.conf.au/2008/Wed/mel8-167.ogg
[18:51] <tjaalton> slides from http://linux.conf.au/programme/wednesday
[18:53] <tjaalton> we have linux-backports-modules package now.. maybe the new versions could be shipped there?
[18:53] <tjaalton> um, new drm modules
[18:54] <cheguevara> yeah that would be better then nothing
[18:54] <cheguevara> and may be specifiy somewhere that if you wanna try experimental drm modules install this package for increased performance etc
[18:55] <tjaalton> but compiz would still be disabled by default
[18:55] <tjaalton> for i965
[18:55] <tjaalton> (i have one)
[18:55] <MacSlow> gee... intels GPU docs were released to the public
[18:56] <cheguevara> tjaalton, new_exa is the batchbuffer git branch right?
[18:57] <MacSlow> LCA seems to be growing and growing... some major conference... not that it was small before.
[18:58] <tjaalton> cheguevara: yep. I tried that two weeks ago, but something went wrong and the driver failed to load. Now that anholt has pushed more stuff to master things should be easier..
[18:58] <tjaalton> hm, maybe I'll pull all the trees now
[19:01] <cheguevara> there seems to be some minor screen corruption with the current hardy driver as well
[19:01] <tjaalton> with exa?
[19:01] <cheguevara> no xaa
[19:02] <tjaalton> mine works fine..
[19:02] <tjaalton> dinner, bbl ->
[19:02] <cheguevara> i had to put xaa in my xorg.conf, 'cause exa is just that crap atm lol
[20:02] <oojah> I'm filling out a MainInclusionReport and I don't know what to put for "Packaging system (debhelper/cdbs/dbs) ?  Patch system ?  Any packaging oddities ?". Any suggestions where I can find information about that?
[20:03] <jpatrick> oojah: in the source package
[20:03] <jpatrick> oojah: apt-get source packageName and take a look in the debian/ dir
[20:05] <oojah> jpatrick: I'm not on ubuntu ;)
[20:05] <oojah> But that's fine, I know where to look now. Thanks.
[20:06] <slangasek> er, you're requesting a package's inclusion in main but aren't running Ubuntu?  That's seems a bit strange to me
[20:07] <StevenK> And if you're unsure about how to fill out a MIR, you shouldn't be, IMO
[20:08] <oojah> Well that's a fair point, but you've got to start somewhere, right?
[20:08] <davmor2> bug 173130 still affecting alpha 4
[20:08] <ubotu> Launchpad bug 173130 in xserver-xorg-video-nv "edubuntu hardy 64bit live cd issues" [Medium,Triaged] https://launchpad.net/bugs/173130
[20:08] <jpatrick> oojah: what exactly is the MIR for?
[20:08] <StevenK> oojah: Sure, but don't start with MIRs
[20:09] <oojah> jpatrick: libggz, a build dep of gnome-games.
[20:09] <slangasek> oojah: libggz is already in main
[20:09] <oojah> Well that certainly shows me up...
[20:10] <oojah> Does everything that goes into main remain in universe?
[20:10] <slangasek> no, each package is in one or the other for each given release
[20:13] <oojah> Fair enough. I checked universe on archive.ubuntu.org and as it was there assumed it wasn't in main.
[20:14] <sistpoty> btw.: motu-meeting in #ubuntu-meeting now... for anyone interested
[20:14] <slangasek> oojah: right, it'll still be in universe for past releases
[20:14] <oojah> Sure
[20:18] <oojah> Well that certainly makes life easier. I was asked to look at the gnome-games ggz deps last week when they weren't in main and now they all are as of a few days ago.
[20:42] <stgraber> slangasek: Are all the ISOs on the tracker ready for testing (I finally managed to have my test computer back so I'll be able to do some tests now) ?
[20:47] <slangasek> stgraber: desktop images are not rerolled yet, just disabled those; alternate images are ready for testing
[20:48] <stgraber> ok
[21:54] <Chipzz> 11:12 < soren> (I'm adding dnsmasq as a dependency of libvirt-bin real soon, by the way) >> sounds wrong to me?
[22:23] <soopurman> stgraber, which tracker were you referring to? when slangasek mentioned that the alternate images are ready for testing
[22:24] <stgraber> soopurman: http://iso.qa.ubuntu.com
[22:24] <slangasek> desktop images are also back up by this point, for all but xubuntu
[22:27] <soopurman> so the contents of 20080201.1 are candidates for the alpha4 release ?
[22:27] <stgraber> yes
[23:03] <soopurman> alright! i'm about to perform the install (manual partitioning) of the 20080201.1 image of hardy-alternate-amd64.iso... i'll report my results on the tracker in about half an hour
[23:03] <soopurman> see you then :-)
[23:07] <slangasek> oh how nice, 3 new updates.
[23:08] <slangasek> presented to me after booting into my newly-installed hardy, which was rolled mere hours earlier. while still in a freeze.
[23:11] <LaserJock> slangasek: "soft" ;-)
[23:13] <slangasek> right... maybe I should try different language for the next one, maybe call it a "retaliatory freeze". :)
[23:14] <StevenK> Haha
[23:14] <StevenK> "If you upload, I'll retaliate."
[23:46] <stgraber> slangasek: first result from Ubuntu desktop i386 : Jockey crashing at session opening (why is it starting on the livecd ?), rofs and cdrom shown on the desktop, ubiquity missing its icon, update-manager showing an update available icon when no updates are available + hovering it shows a "A package maanger is working" label
[23:46] <superm1> slangasek, would you be able to release mythtv binaries from NEW at some point before the end of day?  we were looking to roll our alpha this weekend with them and do some testing over the weekend
[23:47] <slangasek> stgraber: yes, similar to my own experience.  But I don't think any of those are blockers, so I guess it'll just be a little rough around the edges
[23:48] <stgraber> slangasek: I'm installing now, those are not blockers though really annoying bugs (especially when the first thing you see is an apport report :))
[23:49] <slangasek> oh, I didn't see any apport reports here :/
[23:49] <slangasek> well, so be it though
[23:49] <stgraber> I have a nvidia graphic card in my test computer
[23:49] <slangasek> yeah, I'm testing in a VM, no hardware to manage ;)
[23:49] <stgraber> hehe, solves a lot of problem :)
[23:56] <slangasek> stgraber: 188221 for the generic install icon issue
[23:58] <slangasek> I'm fairly certain the rofs icon is a gvfs issue; I haven't checked for open bugs
[23:58] <stgraber> does it disappear when you start ubiquity ?
[23:58] <slangasek> er, I didn't pay attention
[23:59] <stgraber> it did here and I didn't really understand why
[23:59] <slangasek> the update-manager bug has also been reported as #188201


[21:11] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/4905 Abandoning ticket
[21:11] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/4883 Abandoning ticket
[21:12] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/4875 Abandoning ticket
[21:13] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/4980 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[22:00] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/4980 Preparing packages
[23:51] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/4980 Generating diffs
[23:51] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/4980 Successfully built