[00:42] <psusi> xnox, doko, since you guys have touched it recently, I thought I would ask you... libboost seems to have a file, /usr/bin/quickbook... it moved from liboost-tools-dev to libboost-dev between liboost 1.53 and 1.54, which makes libboost1.54-dev have an undeclared conflicts with libboost1.53-tools-dev... why did this file move between binary packages?
[00:45] <nvrpunk> quick question, is tahr fairly usable?
[01:02] <xnox> psusi: due to multiarch.
[01:02] <xnox> psusi: in trusty, we have boost 54 (default) and 55 (available in universe) and they should be all fine.
[01:02] <xnox> psusi: ditto conflicts / replaces. Where are you spotting 1.53 / 1.54 conflict?
[01:02] <xnox> psusi: also boost-dev packages are not co-installable per se....
[01:04] <sarnold> if boost-dev packages aren't co-installable, why offer both 54 and 55?
[01:04] <psusi> xnox, yea...  I see they are set to conflict with each other but due to the change of package, 1.54 needs a Conflicts: libboost1.53-tools-dev... I saw someone asking about it on askubuntu, and there are a few upgrade failure bugs in launchpad
[01:04] <psusi> sarnold, in case you need the old one to build something.. it's there... you just have to remove the new one
[01:07] <jrwren> i've no idea why you would need an older version though. AFAIK boost is great at backward source compat
[01:24] <ScottK> It is better than it used to be.
[01:50] <nvrpunk> so my gnome-terminal's transparency is not working, what should I check?
[01:56] <semiosis> nvrpunk: use kde
[01:56]  * semiosis ducks
[01:56] <Unit193> Use #ubuntu ?
[01:57] <semiosis> nvrpunk: but seriously, as much as i love kde, this is probably teh wrong channel for that kind of question.
[01:57] <semiosis> as Unit193 points out :)
[01:57] <sarnold> it might be alright if it is busted in trusty...
[01:57] <semiosis> truth
[01:59] <Unit193> *Generally*, trusty would be in #ubuntu+1 though.
[01:59] <sarnold> heh never seen that one before..
[02:00] <nvrpunk> im using Ubuntu Gnome Trusty Tahr
[02:01] <nvrpunk> so how is this the wrong channel?
[02:01] <xnox> sarnold: why offer both -> because that's easier then black-listing from debian.
[02:01] <xnox> sarnold: and actualy libboost runtime library packages are co-installable.
[02:02] <sarnold> xnox: that's a good answer :) hehe
[02:02] <sarnold> I haven't looked enough at boost but I'm surprised there's much 'runtime library'
[02:04] <xnox> sarnold: a good chunk of boost are templates, but a whole-load of it are shared libraries that one links against.
[02:13] <TheMuso> @pilot in
[02:25] <TheMuso> Unit193: Where can I find a tarball for https://code.launchpad.net/~unit193/xfce4-panel/snapshot/+merge/206173?
[02:27] <Unit193> TheMuso: Right, sorry about that.  https://launchpad.net/~unit193/+archive/staging/+sourcepub/3912036/+listing-archive-extra
[02:27] <TheMuso> Unit193: Thanks, please put a pointer to the tarball if its a snapshot in the merge proposal in future.
[02:28] <Unit193> Sure, not used to bzr merges so wasn't really sure what to do there.
[02:28] <TheMuso> Understandable.
[02:28] <Unit193> (FWIW, xfce4-indicator-plugin is there too.)
[02:29] <TheMuso> Unit193: Yeah, I saw it, I'm doing them together.
[02:30] <Unit193> TheMuso: Just to be clear, that's preferred over dsc files?
[02:31] <TheMuso> Unit193: Yeah, thanks.
[02:57] <Devastator> can I ping a maintainer or is it considered disrespect?
[02:58] <Devastator> I would like to discuss an idea on IRC before going any further, so I thought discussing here would be better than e-mails etc as it is all informal for now
[03:17] <RAOF> Devastator: Pinging is generally fine.
[03:19] <Devastator> RAOF do you know which approach Stéphane Graber likes?
[03:20] <RAOF> If he's here I'm sure he'd be fine with a ping. stgraber?
[03:21] <Devastator> his idle says almost 4:30 hours, so probably not :)
[03:23] <Unit193> Devastator: Already been a couple pings, may as well ask now (in a highlight, and he may well see it.
[03:24] <Devastator> Unit193 alright, thanks, I'm assuming pasting links which may be from debian is ok also?!
[03:24] <sarnold> yes
[03:24] <Devastator> thanks!
[03:31] <Devastator> stgraber hi, I've seen that you are ubuntu's ifupdown maintainer and I want to add something that can be perhaps useful. Currently ifupdown exports IF_ environment variables to be used in if-pre-up.d, if-up.d, if-down.d and if-post-down.d, but it doesn't distinguish each parameter per interface, example: everytime one interface goes up it exports IF_ADDRESS, IF_NETMASK and others, what
[03:31] <Devastator> I'm proposing is adding interface logical name to it, like IF_eth0_ADDRESS, IF_eth1_ADDRESS, IF_eth0_NETMASK, IF_eth1_NETMASK and so on as this could be useful for using in shellscripts for advanced configurations. I must say I'm not currently using ubuntu but I'm willing to try it if you think this can be added
[03:32] <sarnold> Devastator: you were cut off at "others, what" in your first message
[03:33] <Devastator> thanks
[03:33] <Devastator> stgraber what I'm proposing is adding interface logical name to it, like IF_eth0_ADDRESS, IF_eth1_ADDRESS, IF_eth0_NETMASK, IF_eth1_NETMASK and so on as this could be useful for using in shellscripts for advanced configurations. I must say I'm not currently using ubuntu but I'm willing to try it if you think this can be added
[03:35] <Devastator> stgraber I give you a pastebin of what ifupdown exports currently: http://codepad.org/pksia5AW and here is the wishlist bug I posted in debian's BTS which contains the piece of code I tried to edit and failed miserably: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737749
[03:36] <psusi> Devastator, that would make it _less_ usable... if you want to know what iface you are being run for that is what the IFACE variable is for
[03:38] <Devastator> psusi yes, but how to check if IF_ADDRESS=<IP_ADDRESS> is from IFACE=eth0 for example?
[03:38] <Unit193> TheMuso: Thanks muchly!
[03:41] <TheMuso> Unit193: You're welcome, please keep in mind the pointers I made both on IRC, and in the comments for the indicator plugin.
[03:41] <Unit193> Indeed.
[03:42] <Devastator> also, if you guys don't mind me asking, are there plans to replace ifupdown altogether?
[03:48] <Devastator> psusi also, could you please explain why you think it would make less usable?
[03:59] <psusi> Devastator, with an if statement of course
[03:59] <psusi> Devastator, it would make it less usable because you couldn't write a script without knowing the name of the iface
[04:00] <Devastator> psusi I'm not trying to replace IFACE with IF_<iface name>_ADDRESS etc, I want to keep IFACE
[04:01] <Devastator> psusi did you take a look at the pastebin also?
[04:01] <Devastator> psusi also, I'm not saying you are wrong, just trying to understand
[04:03] <Devastator> if you possible, give me an example of the if
[04:07] <psusi> Devastator, if [ $IFACE = eth0]
[04:09] <Devastator> psusi does it matter if $IFACE is exported after $IF_ADDRESS?
[04:09] <psusi> no
[04:10] <Devastator> will do some tests
[04:15] <psusi> Devastator, generally speaking, the script shouldn't *care* what interface it is being used with
[04:17] <Devastator> psusi I'm trying to come up with a multiwan failover solution without having to hardcode things, the if works, now I have to make some kind of array to store $IFACE from each interface, then get each $IF_ADDRESS, but I think it will work
[04:20] <psusi> Devastator, I think you're going about it all the wrong way.. I'm pretty sure those scripts aren't called when an interface fails... only when you manually ifdown
[04:24] <Devastator> psusi I don't think I follow you, are you saying it's not a good idea to use if-up.d scripts?
[04:40] <Devastator> psusi I really have to get some rest, can we continue this talk at perhaps.. 11:00 UTC?! my TZ is UTC-2 by the way
[04:46] <psusi> Devastator, yes, that is not a use case for if-up.d scripts
[06:04] <TheMuso> @pilot out
[06:43] <pitti> Good morning
[06:45] <pitti> mlankhorst: they auto-ran; yay, they all succeed now! https://jenkins.qa.ubuntu.com/view/Upgrade/?
[06:45] <pitti> mlankhorst: that is, ubuntu-precise-trusty-*-lts-*
[07:14] <dholbach> good morning
[07:16] <YokoZar> pitti: Not to poo-poo you for fixing wine1.4, but I'd rather you just delete it
[07:16] <pitti> YokoZar: ah, I wanted to ask you yesterday, but you weren't online
[07:16] <YokoZar> https://bugs.launchpad.net/ubuntu/+source/wine1.4/+bug/1218645
[07:17] <pitti> YokoZar: I actually already uploaded it yesterday, but the upload somehow wasn't accepted
[07:17] <pitti> YokoZar: right, Debian has 1.6, I wondered whether we want to upgrade
[07:17] <YokoZar> We have 1.6 too
[07:17] <YokoZar> now
[07:17] <YokoZar> I wanted to upgrade 2 releases ago
[07:17] <pitti> YokoZar: I just got the FTBFS when I did the libgphoto transition, and then felt obliged to spend the two hours to fixing the build and finishing the transition
[07:18] <YokoZar> It never got into saucy due to being uploaded like 2 minutes after feature freeze
[07:18] <pitti> hm, I cant' see wine 1.6 in trusty
[07:18] <YokoZar> wait, what
[07:19] <pitti> not in https://launchpad.net/ubuntu/trusty/+queue?queue_state=0 either
[07:19] <pitti> wine1.6 | 1:1.6.1-0ubuntu4 | trusty-proposed/universe | source, amd64, i386
[07:19] <pitti> ooh
[07:19] <pitti> they just didn't propagate yet
[07:19] <pitti> wine1.6/amd64 unsatisfiable Depends: wine1.6-i386 (= 1:1.6.1-0ubuntu4)
[07:20] <pitti> yeah, that looks wrong
[07:20] <YokoZar> oh right
[07:21] <pitti> I thought in the times of multi-arch we wouldn't need those -i386/-amd64 packages at all any more
[07:21] <YokoZar> didn't we have to do something manual for wine1.4
[07:21] <pitti> you can just apt-get install wine and would get wine:i386
[07:21] <YokoZar> The issue is that wine on amd64 needs BOTH the i386 and amd64 guys
[07:21] <YokoZar> and there's no way to do arch-specific depends
[07:22] <YokoZar> so instead you have to make a package that's only satisfiable as a foreign depends
[07:22] <pitti> ah, so wine: is arch: all, depends: wine-bin
[07:22] <pitti> and wine-bin is M-A: foreign?
[07:22] <YokoZar> Yeah
[07:25] <YokoZar> To be more specific, wine is a metapackage depending on wine1.6, which in turn depends on wine1.6-i386 or (both wine1.6-i386 and wine1.6-amd64)
[07:26] <YokoZar> and wine1.6 isn't arch-all but is defined for specific arches (cause the dependencies change based on the arch)
[07:28] <YokoZar> I seem to remember there being some sort of "ignore wine's unsatisfiable cross-arch depends" thing in the proposed migration for wine1.4.  Or maybe it was just manually approved each time.
[07:28] <pitti> YokoZar: ah, indeed skype is similar; skype is amd64, depending on skype-bin which is i386 only and M-A: foreign
[07:29] <pitti> IIRC slangasek set that up, so I take that as "official reference to do it right" :)
[07:29] <YokoZar> Yup.  I'm somewhat proud of it being so coherent (and Wine using just about every edge case of apt there is)
[07:31] <pitti> YokoZar: oh, and now the wine1.4 builds got rejected because they are older than the transitional ones in -proposed
[07:32] <pitti> so I guess that was in vain
[07:32] <YokoZar> hah, so I suppose you would have discovered wine1.6 that way :p
[07:33] <pitti> so, TBH I don't know why britney complains about it
[07:33] <pitti> infinity: do you have an idea about "wine1.6/amd64 unsatisfiable Depends: wine1.6-i386 (= 1:1.6.1-0ubuntu4)" in britney?
[07:34] <pitti> wine1.6-i386 is already M-A: foreign
[07:34] <infinity> pitti: Yeah, we need a fauxpkg setup for it.  britney doesn't do cross-arch deps.
[07:34] <infinity> pitti: I'll sort it in the morning when I'm more awake.  Or ask cjwatson, he knows what's up.
[07:34]  * pitti tries to make an halfway intelligent face about "fauxpkg"
[07:35] <infinity> pitti: See fauxpkg/FauxPackages in britney1 source.
[07:36] <infinity> YokoZar: Bug me about it in the morning if no one's fixed it before.  I'm sleeping in about 3 minutes.
[07:37] <pitti> infinity: I just got a bug report against langpack-locales; do we actually build locales from eglibc now? eglibc has it in it's Binary: list, but our locales still comes from langpack-locales
[07:37] <pitti> infinity: (feel free to answer after you wake up again, not urgent at all)
[07:40] <YokoZar> pitti: infinity: thank you both
[08:07] <OdyX> tkamppeter_: yay, thanks.
[09:35] <mlankhorst> pitti: not yet, xrandr needs a tes ttoo
[09:35] <mlankhorst> test that ls /usr/bin/xrandr* == /usr/bin/xrandr
[09:37] <mlankhorst> I forgot about that diversion
[09:39] <pitti> mlankhorst: would you mind describing that in https://bugs.launchpad.net/auto-upgrade-testing/+filebug ?
[09:39] <pitti> (hunting down two other failures ATM, brain stack is full)
[10:09] <mlankhorst> pitti: upload https://mblankhorst.nl/etc/xorg-lts-transitional_5.tar.gz and then https://bugs.launchpad.net/ubuntu/+source/x11-xserver-utils/+bug/1280155 should be fixed for the packages in ubuntu
[10:11] <pitti> mlankhorst: uploaded, thanks!
[10:19] <zyga> hey, daily update left my system with this:
[10:19] <zyga> apt-get: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory
[10:20] <zyga> I didn't reboot but I cannot launch most things
[10:20] <zyga> doko: ^^
[10:20] <zyga> help please :-)
[10:21] <zyga> ara: what a day ;)
[10:21] <ara> zyga, what happened?
[10:22] <pitti> urhg, indeed
[10:22] <doko> zyga, I see
[10:22] <zyga> ara: libgcc_s.so.1: cannot open shared object file
[10:22] <pitti> this just caused a gazillion autopkgtset failures, too
[10:22] <zyga> ara: don't upgrade for a moment
[10:22] <doko> arghh, and it did migrate already ...
[10:22] <pitti> jibel: hm, given that this broke pretty much every autopkgtest, any idea why this wasn't held back?
[10:22] <zyga> ara: (earlier I had lots of kernel fc*ups, wired networking didn't work and other funny things)
[10:22] <seb128> an we delete the binaries before they get downloaded?
[10:23] <seb128> can*
[10:23] <pitti> oh, I guess they only started failing after the promotion of whatever caused that
[10:23] <doko> zyga, quick fix: install the old libgcc1
[10:23] <doko> if you have it in the cache
[10:24] <seb128> doko, can you get #is to block the download of the buggy binaries?
[10:24] <zyga> I only have libgcc1_1%3a4.9-20140213-0ubuntu1_amd64.deb
[10:24] <pitti> hmm, gcc-4.8 was uploaded two days ago already
[10:24] <doko> trying ...
[10:24]  * zyga checks if apt-cacher-ng has it
[10:25] <pitti> zyga: you can get older ones from https://launchpad.net/ubuntu/+source/gcc-4.8/<version>
[10:25] <Laney> why did that only just happen?
[10:25] <pitti> is that really libgcc1?
[10:26] <pitti> it must have been something which just propagated an hour or so ago
[10:26] <zyga> pitti: I may have it in apt-cacher-ng
[10:26] <Laney> yeah
[10:26] <doko> pitti: now built from gccgo-4.9
[10:26] <pitti> ah
[10:26] <doko> but empty package. messed up the testing
[10:26] <pitti> and gccgo-4.9 doesn't trigger any autopkgtests, so it wasn't caught by those until after it promoted
[10:27] <pitti> ok, that at least explains the mysteries
[10:27] <pitti> doko: i. e. is it meant to build from gccgo-4.9, or was that an oversight? In the latter case, we'd need a version downgrade, i. e. update gcc-4.8 to 4.9+really4.8.. or so?
[10:28] <doko> pitti, it is meant to
[10:28] <pitti> doko: ok, that at least simplifies the versioning problem
[10:28] <doko> but the quick fix is to download the previous version and just dpkg -i it
[10:29] <pitti> wget http://archive.ubuntu.com/ubuntu/pool/main/g/gcc-4.8/libgcc1_4.8.2-15ubuntu3_amd64.deb
[10:29] <pitti> sudo dpkg -i libgcc1_4.8.2-15ubuntu3_amd64.deb
[10:29] <pitti> zyga:  ^
[10:29] <zyga> ok, thank god I had apt-cacher-ng with the older copy :)
[10:29] <zyga> already fixed, I also installed the i386 version for parity
[10:30] <Laney> hmmmmmmm
[10:30] <pitti> the teutonic mirror is behind by half a day or so, seems that rescued me
[10:30] <Laney> I ended up with /var/lib/spamassassin being root:root rather than debian-spamd:debian-spamd
[10:30] <cjwatson> And of course this means all trusty builds are failing too
[10:30] <Laney> which broke my upgrade due to the new sa-compile thingy
[10:31] <Laney> does anybody else have it with these permissions?
[10:31] <cjwatson> /usr/bin/apt-cache exit status 32512
[10:32] <pitti> i. e. including the upcoming gccgo4.9 fix, yay
[10:32] <cjwatson> We can probably work around that with the bootstrap archive somehow
[10:32] <pitti> cjwatson: could we temporarily disable the dist-upgrade of the build chroots for that?
[10:33] <pitti> I take it the chroots are usually a few days or even weeks old
[10:33] <seb128> can we get the binaries blocked from download on the server?
[10:33] <seb128> save users and the chroots :p
[10:33] <seb128> oh, cjwatson just pinged #is a bit more, thanks
[10:34] <cjwatson> pitti: it's easier to prod it in the bootstrap archive; fiddling with the build chroots will require infinity to wake up
[10:34] <pitti> ack
[10:35] <tvoss> doko, around?
[10:35] <pitti> tvoss: not now, please : )
[10:35] <pitti> tvoss: trusty is on fire, nobody disturb doko for a while
[10:35] <tvoss> pitti, ack
[10:35] <zyga> was I the first person affected that came here/
[10:36] <cjwatson> I don't understand why autopkgtest didn't save us from this
[10:36] <cjwatson> I: [Fri Feb 14 09:42:55 2014] - Requested autopkgtest for apt_<IP_ADDRESS>ubuntu1 (NEW gccgo-4.9 1:4.9-20140213-0ubuntu1)
[10:36] <cjwatson> [lots of more things along the same lines]
[10:36] <cjwatson> final: gccgo-4.9,ubuntu-keyboard
[10:36] <pitti> cjwatson: yeah, we got a bazillion failures
[10:36] <zyga> cjwatson: this is like backup, the first time we know the backup failed, the second time we check if backups can also restore
[10:36] <cjwatson> zyga: please can I not have the smart commentary just now? :)
[10:36] <zyga> cjwatson: sorry
[10:36]  * zyga goes away
[10:37] <pitti> cjwatson: gccgo4.9 doesn't have direct rdepends that have autopkgtests apparently, but it should have caught the libgcc1 binary for sure
[10:37] <cjwatson> jibel: could you have a look at why adt-britney apparently said everything was just fine when we'd just triggered a load of autopkgtests for gccgo-4.9 and they hadn't come back yet?
[10:37] <cjwatson> pitti: the above log entry shows that it definitely felt it necessary to trigger them
[10:37] <pitti> cjwatson: ok
[10:38] <pitti> yeah, I noticed that several times, britney waving through uploads before tests finished
[10:38] <jibel> cjwatson, looking
[10:41] <cjwatson> I'm going to disable the publisher while I figure this out; don't tell anyone but I think I might be able to manage to wind this back as an emergency measure
[10:46] <cjwatson> 10:45 <cjwatson> doko: so, I'm going to remove gccgo-4.9 from trusty, copy gcc-4.8 back over it (which should be permitted, and should restore libgcc1), rerun the publisher, then hopefully we can build the new gccgo-4.9
[10:46] <cjwatson> oops, echan, but never mind
[10:51] <cjwatson> Downloads should be disabled where possible
[12:22] <cjwatson> pitti: I think you can retry those autopkgtest failures now
[12:30] <pitti> cjwatson: thanks; our internal mirror (tachash) still gives the bad deb, I asked in #ci a while ago about purging it
[12:30] <cjwatson> it should be sufficient to just sync it now
[12:30] <cjwatson> current indices have libgcc 4.8.mumble instead
[12:30] <pitti> I'll just try
[12:33] <pitti> yay, works now
[12:33]  * pitti gives our machines something to chew on then
[12:34] <pitti> doko, cjwatson: many thanks for your swift handling of this!
[12:34] <cjwatson> I'm going to do an automated search for affected failed builds
[12:34] <cjwatson> (once I write it)
[12:38] <jibel> pitti, autopkgtest in the lab use ftpmaster and should have the right deb
[12:40] <cjwatson> OK, walking through all recent builder history now searching for "/usr/bin/apt-cache exit status", will take a while
[12:41] <cjwatson> of course chances of getting answers quickly out of wildcherry right now ...
[12:41] <cjwatson> wgrant: I guess the POST rule applies with the API too?  so my first retry() -> everything after on wildcherry
[12:41] <wgrant> cjwatson: All API requests go straight to the master
[12:42] <cjwatson> ah ok
[12:42] <wgrant> But the API is mostly performing OK at the moment.
[12:43] <zbenjamin> cjwatson: i was reading in the ML and the link you gave me. But where can i find details on where i put the different binaries for the different archs? like the armhf binaries, the x86 binaries and so on
[12:47] <cjwatson> zbenjamin: that's not up to click
[12:48] <cjwatson> zbenjamin: it's for the SDK and tools such as upstart-app-launch to define how packages are laid out internally
[12:48] <cjwatson> zbenjamin: tedg might be able to advise on current standards
[12:48] <zbenjamin> cjwatson: thx i'll ask him
[12:50] <jibel> cjwatson, what I found so far, gccgo triggered an autopkgtest for 54 packages, status has been set to running for these packages and collected by britney but gccgo has not been removed from upgrade_me, it passed the upgrade test and has been copied. What is unclear yet is why gccgo has not been removed while tests of dependant packages were running.
[12:58] <cjwatson> jibel: hopefully that much will clear out soonish, a fixed gccgo-4.9 is building
[12:58] <cjwatson> oh, but you mean for why it didn't block initially
[12:59] <jibel> cjwatson, yes, for why it didn't block initially, I'm in britney.py
[13:03] <pitti> jibel: beer o'clock!
[13:03] <pitti> http://d-jenkins.ubuntu-ci:8080/view/Upgrade/
[13:03] <pitti> ugh, at least the wrestling this week was useful :)
[13:05] <jibel> pitti, 38 profiles, all green \o/ time to add more tests
[13:05] <seb128> pitti, hum, are you sure you want to hand beer to jibel while he's working on britney.py? ;-)
[13:06] <pitti> seb128: I'll buy him one next week
[13:06] <pitti> I pestered him all week with questions about how stuff works
[13:06] <seb128> oh, you guys have a team gathering coming
[13:06] <seb128> enjoy it!
[13:06] <pitti> yeah, Oakland, will fly out tomorrow
[13:06] <pitti> seb128: merci !
[13:07] <pitti> jibel: more tests> for sure, but nice to have a stable base line now
[13:09] <Laney> more Oakland, lucky pitti ;-)
[13:16] <cjwatson> jibel: hopefully you're about to get it again; accepted the fixed gccgo-4.9
[13:17] <cjwatson> though armhf is still building so maybe it'll block anyway
[13:37] <cjwatson> All libgcc-affected failed builds retried, I believe
[14:25] <spineau> doko: hello, to build checkbox-gui for ubuntu we're a bit blocked by two dependencies waiting to be promoted to the main archive: bug 1277408 and bug 1278822, could you please help us?
[14:26] <doko> spineau, not yet seen in http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[14:27] <spineau> doko: I think it's because we're still in -proposed
[14:27] <spineau> roadmr: ^
[14:27] <doko> http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[14:30] <roadmr> spineau, doko: I see, I fixed the stuff that was keeping checkbox in proposed (dep-wait) so it should make it out, will it appear in component-mismatches once this happens?
[14:30] <doko> roadmr, yes, it should
[14:31] <roadmr> spineau, doko: OK then, upload coming up in a second
[14:31] <spineau> roadmr: doko: perfect, thanks
[15:03] <shadeslayer> ev: ping
[15:34] <shadeslayer> pitti: can Kubuntu also utilize https://jenkins.qa.ubuntu.com/view/Upgrade/ ?
[15:39] <pitti> shadeslayer: yes, I don't see why not
[15:41] <shadeslayer> yay :)
[15:41] <shadeslayer> pitti: I'll have a look at how to write a test case and send MR's
[15:42] <pitti> shadeslayer: it's primarily about defining a new scenario
[15:43] <pitti> shadeslayer: i. e. something like s/ubuntu-desktop/kubuntu-desktop/ and enabling universe
[15:43] <shadeslayer> I see
[15:43] <jpds> stgraber: Have you seen this? https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1280050
[15:43] <pitti> shadeslayer: the scenarios in lp:auto-upgrade-testing are outdated, we are actually using a branch from jibel, hang on
[15:43] <shadeslayer> pitti: I think there are 2 upgrade paths we want to check : regular 13.10 to 14.04 and 13.10 + LTS Stack + Kubuntu backports to 14.04
[15:45] <stgraber> jpds: nope, I haven't. Though to be faire, I'm not maintaining samba, I only patched the few bits I needed to get my use case covered (AD domain controller) :)
[15:45] <jpds> Ah, right.
[15:45] <stgraber> jpds: I believe the server team are the ones actually maintaining our delta, anything else should probably go straight to Debian
[15:46] <rbasak> infinity: do you think it appropriate/could you sync cyrus-sasl2, please? Looks like a host of bugs have been fixed recently there. It's not in testing yet though.
[15:46] <rbasak> (and it's a new upstream release, too, which looks minor, but the changelog suggests that it isn't)
[15:47] <jibel> shadeslayer, I think I've already a profile for Kubuntu 13.10->14.04.
[15:47] <jibel> shadeslayer, What is 13.10 + LTS stack?
[15:47] <pitti> shadeslayer: this one: https://code.launchpad.net/~jibel/+junk/auto-upgrade-testing_profiles
[15:48] <pitti> shadeslayer: I think the 12.04+LTS stack scenarios are already well-handled; is there anything Kubuntu specific in them?
[15:48] <shadeslayer> jibel: whoops, I meant 12.04 + HWE
[15:48] <pitti> oh yes, http://bazaar.launchpad.net/~jibel/+junk/auto-upgrade-testing_profiles/files/head:/kubuntu/
[15:48] <Devastatr> stgraber good afternoon (or probably evening), did you happen to see the message I leave here?
[15:48] <shadeslayer> pitti: well, we backport KDE releases to our PPA, and alot of users add that ppa
[15:48] <shadeslayer> so I think it's useful to have that tested
[15:51] <pitti> ah, yes
[15:52] <jibel> shadeslayer, ah okay as pitti said LTS+HWE is already covered, we could do 12.04 + Kubuntu backport
[15:52] <shadeslayer> sure, fine with me
[15:53] <zbenjamin> tedg: ping
[15:54] <tedg> zbenjamin, Howdy
[15:54] <zbenjamin> hey
[15:54] <zbenjamin> tedg: i got pointed to you by jdstrand i think, because i was asking about how a fat click package should look like internally and how it will work with the desktop files EXEC property
[15:55] <zbenjamin> i'm working on the qtcreator ubuntu plugin and we would like to integrate fat packaging :)
[15:55] <tedg> zbenjamin, Yup, so what we're doing is adding an arch dependent directory to the path.  So that way you can put an executable name in the Exec line and it'll find the arch dependent one.
[15:56] <zbenjamin> tedg: ok but do i need a own desktop file per architecture in the package then?
[15:57] <tedg> zbenjamin, Nope, so the desktop file can have "Exec=foo-bar" and the package would have a $(dir)/lib/$(arch)/bin/foo-bar for each arch.
[15:57] <stgraber> Devastatr: I did. I'm not necessarily against extending the script environment though I'm not going to diverge from Debian either, so if Andrew (the Debian maintainer) does those changes, I'll include them in Ubuntu but I don't want Ubuntu to suddenly become incompatible with Debian for those scripts.
[15:57] <zbenjamin> tedg: ok and the path will be set correctly so it will be found
[15:58] <tedg> zbenjamin, Yup, for some examples there are the exec-test* file in the tests directory here: http://bazaar.launchpad.net/~indicator-applet-developers/upstart-app-launch/trunk.14.04/files/head:/tests/
[15:59] <zbenjamin> tedg: and for things like : Exec=qmlscene $@ -I ./lib/arm-linux-gnueabihf/qt5/qml   share/qml/cmake1/cmake1.qml
[16:00] <Devastatr> stgraber I understand that and I agree, when you have some time, can you ping me? I want to discuss if I wanted to design something to replace ifupdown, together with you and Andrew, where to start
[16:00] <tedg> zbenjamin, We're also setting the QML2_IMPORT_PATH to be $(dir)/lib/$(arch)
[16:02] <zbenjamin> tedg: do you have any docs on which directories have to be where?
[16:02] <tedg> zbenjamin, Uhm, not really.  Not really sure where that belongs.
[16:03] <zbenjamin> tedg: ok so lets recap, i put a arch into the manifest , lets say armhf, then click wants to have executables in APP_DIR/bin/armhf  and libs in APP_DIR/lib/armhf
[16:04] <zbenjamin> or is it arm-linux-gnueabihf
[16:04] <tedg> zbenjamin, It's the triplet, and not /bin, but /lib/$arch/bin
[16:05] <zbenjamin> tedg: or maybe you could point me to the code that sets up the env
[16:08] <tedg> zbenjamin, Sure, I'm not sure that's as helpful as the tests are though.  http://bazaar.launchpad.net/~indicator-applet-developers/upstart-app-launch/trunk.14.04/view/head:/exec-line-exec.c#L62
[16:10] <zbenjamin> tedg: thanks , if i have more questions i'll come back to you :)
[16:14] <tedg> zbenjamin, No problem, good to see this getting into the plugin!
[16:16] <zbenjamin> tedg: yeah, we have a _lot_ of things to get in there ;)
[16:18] <tedg> zbenjamin, BTW, are you guys also adding support for custom URLs (or is that on the TODO list)?
[16:18] <zbenjamin> custom urls? that i don't know about, bzoltan is my mentor so he should know more
[16:22] <hallyn> bdmurray: hi, so regarding bug 1228977.  I was waiting for sdague to post a test case so I could do the SRU justification
[16:23] <hallyn> bdmurray: however, the candidate package I pushed is broader, taking the whole upstream "-stable" series for that libvirt version.  I wasn't sure if that should be handled specially
[16:24] <hallyn> (it took some time to reconsile the upstream patchset with the individually-applied CVE patches in our tree)
[16:24] <hallyn> normally, I would say that if the bug submitter can't be bothered to give a test reproduction s cript, let's just drop the patch and close the bug, but
[16:25] <hallyn> since this is a whole -stable patchset I'd prefer to test for new regressions and call it good
[16:32] <bdmurray> hallyn: I hadn't actually looked at the diff yesterday, just the bug.
[16:38] <hallyn> bdmurray: if my reasoning about the -stable patchset is legitimate i can put that in teh bug comment.  otherwise, i'll ping the bug submitter oen more time for a test case, and we can drop teh set and close the bug next week if we dont' get it
[16:39] <bdmurray> using the -stable patchset seems more like a micro release to me than a standard SRU
[16:46] <hallyn> bdmurray: if saucy was going to be around longer i'd pursue that.  unfortunately there is an upstream libvirt -stable tree for saucy, but not (other than the one i maintain :) for precise
[17:03] <ev> shadeslayer: pong
[17:04] <shadeslayer> ev: Kubuntu has started reporting crashes to errors.ubuntu.com but our backtraces usually end in KCrash ( the KDE Crash handling framework ) , would daisy interpret the crashes as crashes in KCrash or will it be able to parse the stack correctly? ( see ref : https://trello.com/c/u9KpFFxF )
[17:08] <ev> shadeslayer: what do you mean by "our backtraces usually end in KCrash"?
[17:09] <ev> oh
[17:09] <shadeslayer> ev: KDE Software :)
[17:09] <ev> shadeslayer: that's pretty easy to test. Just kill -SEGV a KDE process and see what's in the executablepath and package fields
[17:09] <ev> in the resulting crash report
[17:10] <shadeslayer> ev: but my question is whether daisy will interpret all crashes as crashes in KCrash?
[17:10] <ev> shadeslayer: right, and I'm saying the way to find out is by looking at the resulting crash report after killing a process with sigsegv
[17:12] <shadeslayer> ev: and what am I looking for?
[17:12] <ev> shadeslayer: the Package field and the ExecutablePath field
[17:14] <shadeslayer> ev: grep doesn't say anything
[17:14] <shadeslayer> Bunch of jumbled text
[17:14] <ev> shadeslayer: can you pastebin the resulting .crash file?
[17:14] <shadeslayer> sure
[17:15] <shadeslayer> ev: http://paste.ubuntu.com/6932266/
[17:16] <shadeslayer> ev: really really large file :P
[17:17] <ev> shadeslayer: looks right to me: ExecutablePath: /usr/bin/kate
[17:17] <Laney> shadeslayer: you do have Package and ExecutablePath in there
[17:17] <ev> you wont get Package until you actually run apport-kde over it
[17:17] <ev> err so you do :)
[17:17] <shadeslayer> ev: Laney yeah it's weird, grep didn't return anything
[17:19]  * Laney suspects PEBCAK :P
[17:19] <shadeslayer> http://paste.ubuntu.com/6932302/
[17:20] <shadeslayer> ev: anyway, so it'll be fine even though backtrace has KCrash in it?
[17:22] <ev> shadeslayer: ja
[17:22] <shadeslayer> cool :)
[19:58] <u-foka> Hy, I've tryed to install trusty using the latest daily-live image dd-d over an usb key but it refuses to boot :(
[20:10] <u-foka> is anyone here?
[20:11] <sarnold> a few hundred :) normally IRC works best if you've got something concrete.. an error message or something similar
[20:12] <u-foka> sorry I have only the fact that my bios immediatelly returns to the device selection mennu when I select the pendriver and hit enter :/
[20:12] <u-foka> I've tried to dd the iso on the dirst (active) partition and also on the entire device without success
[20:13] <u-foka> also I can't found the unity alpha2 iso image, there are the images for every other flavor but not for ubuntu-desktop
[20:14] <dobey> main ubuntu doesn't do actual alpha releases any more
[20:14] <dobey> the daily image should be what you use
[20:15] <u-foka> so I should try it with an older daily image?
[20:15] <dobey> maybe, i don't know
[20:15] <dobey> "refuses to boot" doesn't really say anything about what's wrong
[20:15] <dobey> you do have to dd to the main device, not a partition
[20:16] <dobey> "dd if=foo.iso of=/dev/sdg bs=4096" for example
[20:16] <u-foka> tried that way also, but got only a blank screen
[20:16] <u-foka> my bios has uefi support and it can't be disabled
[20:17] <dobey> i can't really help beyond that info though. sorry
[20:17] <u-foka> okay, thanks anyway
[20:18] <dobey> fwiw though, #ubuntu is the help channel, so you might have better luck asking in there
[20:18] <u-foka> I'll try with the 11th image maybe it will work
[20:19] <dobey> kenvandine, mardy: are there docs about what mechanisms/options can be used with the generic_oauth plug-in, when creating a provider file?
[20:19] <u-foka> well I thought this is the right channel for asking about an alpha release :) then I'l try asking there also if it won't boot with the other image
[20:24] <kenvandine> dobey, not that i've seen
[20:24] <geoff-> Hi, where can I find a kernel that will work with this: cdimage.ubuntu.com/ubuntu-core/daily/current/trusty-core-arm64.tar.gz?
[20:24] <dobey> kenvandine: do you know if PLAINTEXT is a valid mechanism?
[20:25] <geoff-> I looked around in ports.ubuntu.com, but could'nt find anything for arm64
[20:29] <dobey> ah, i guess it is
[20:32] <kenvandine> dobey, sorry, don't know
[20:34] <dobey> ok
[20:37] <Noskcaj> Is there anything i can do to speed up bug 1272123
[20:42] <u-foka> well, definitely something's wrong with the uefi boot ot the daily images.. it boots into a black screen when selecting the pendrive from the boot menu, but it boots properly when selecting the pendrive as the first boot device from the bios setup
[20:43] <u-foka> anyway it's installing now
[20:48] <dobey>  kenvandine do you know if there is some way to debug the HTTPS requests there?
[20:48] <dobey> u-foka: that sounds very much like it could be a problem with the BIOS itself
[20:49] <u-foka> yeah it was my first impression also but somehow the 13.10 insaller boots without any problems in uefi mode
[20:57] <kenvandine> dobey, i don't, but maybe cwayne might
[20:57] <kenvandine> he's done quite a bit of hacking on that stuff lately
[20:58] <dobey> oh
[20:58] <dobey> and not in here, whee
[21:24] <Unit193> mvo_: Well howdy.  Just a small poke again. :)
[22:22] <chiluk> what tool outputs this kind of information ip-21638 [020] .... 37415.094434: lg_local_unlock <-mntput_no_expire
[22:22] <chiluk> ip-21638 [020] .... 37415.094436: lg_global_lock <-do_umount
[22:22] <chiluk> ip-21638 [020] .N.. 37431.042253: lg_global_unlock <-do_umount
[22:22] <chiluk> ip-21638 [020] .N.. 37431.042265: lg_global_lock <-release_mounts
[22:30] <roadmr> chiluk: seems to come straight from the kernel: http://lxr.free-electrons.com/ident?i=lg_global_lock
[22:31] <chiluk> roadmr some tool is tracing the kernel..
[22:31] <roadmr> ohh weird then
[22:31] <chiluk> roadmr, I'm curious what the tool is that is producing the output.
[22:31] <chiluk> maybe I'll move to ubuntu-kernel
[22:31] <stgraber> chiluk: looks fairly close to ftrace
[22:32] <TJ-> chiluk: local-global spinlocks
[22:38] <chiluk> thanks stgraber
[23:19] <Logan_> Noskcaj: hi
[23:20] <Logan_> ok


[03:47] <pitti> Good morning
[07:34] <jibel> pitti, http://paste.ubuntu.com/7593101/ additional quoting for safety and doc updates
[08:01] <jibel> plars-away, I confirm that the desktop ISO looks a bit broken. No nice boot screen, no ubiquity-dm and ubiquity hangs on start. I'll search useful information and report a bug
[08:02] <pitti> jibel: thanks! running tests with that
[08:20] <pitti> jibel: pushed
[08:33] <jibel> pitti, thanks. I'll continue the work on the ssh driver after I debugged desktop images
[13:37] <brendand> balloons, hey
[14:34] <balloons> brendand, hey, I answered the track question last night but you missed it again I think. propose it wherever you think is best
[14:34] <brendand> balloons, no i got your answer
[14:51] <cgoldberg> balloons, hey..  how long is each session in UOS?
[14:52] <balloons> cgoldberg, an hour.. but you can have it be shorter
[14:52] <balloons> just not longer :-)
[14:52] <balloons> brendand, ahh ok.. so something else then or ?
[14:52] <brendand> balloons, i was going to ask if there's a template for presentations. but i guess we don't really need one
[14:53] <balloons> brendand, not really. You'll be in a hangout and can go wild :-)
[14:54] <brendand> balloons, i will!
[14:54] <cgoldberg> balloons, i think I'd like to do one .. are there still slots open?
[14:56] <cgoldberg> balloons, not sure on topic.. though I can tackle one of the ideas from your email.  got any other suggestions or really hot python-ish topics I should consider?
[14:56] <balloons> cgoldberg, yes slots are still open for sure
[14:56] <balloons> cgoldberg, you can tackle any subject you wish.. outside of QA as well..
[14:57] <balloons> my list of ideas was just that. On python, there's plenty of things you could talk about..
[14:57] <balloons> hmm
[14:57] <cgoldberg> balloons, perhaps an overview of testtools and subunit?   ... since we make heavy use of them all over QA (inside Autopilot for example)
[14:57] <balloons> the UITK helper, or autopilot helpers in general
[14:57] <balloons> delayed assertions, testtools, subunit.. all good stuff
[14:59] <balloons> cgoldberg, http://uds.ubuntu.com/getinvolved/propose-a-session/
[15:00] <balloons> cgoldberg, for you it would be a discussion session
[15:01] <balloons> brendand, you are approved. cgoldberg or brendand if you want a specific date/time slot speak up and I'll put the session there for you
[15:01] <elfy> good job I deferred ... no way I could talk for 60 minutes about manual testcases lol
[15:01] <cgoldberg> balloons, ok cool.  i need a day to figure out topic, and see if I can put together some materials.. i can propose a topic tomorrow
[15:01] <balloons> elfy, as long as it's not over an hour is all
[15:01] <balloons> lol
[15:02] <balloons> cgoldberg, wonderful thanks!
[15:02] <cgoldberg> elfy, i hear ya.. i'm usually good for a lightning talk, and that's about it :)
[15:02] <elfy> :)
[15:03] <elfy> I could probably do 52 minutes worth of umming and aahing
[15:03]  * balloons wonders if a lightening talk 'session' would be useful for people
[15:03] <balloons> I could make a session and host it.. and everyone would get 5 mins as usual, without having to do anything
[15:04] <elfy> balloons: next time around I'll be happy to do something about manual tests - might be useful to do a session with a bit of each thing in it - say 15/20 minutes
[15:04] <elfy> and a wrap up
[15:04] <elfy> just an idea
[15:07] <balloons> elfy, a bit of each thing?
[15:07] <elfy> autopilot/manual testcases/package tracker/etc
[15:08] <elfy> though it depends how much detail people want to get into
[15:08] <elfy> sounds like cgoldberg and I could be all done in 10 minutes :p
[15:10] <balloons> elfy, lol
[15:10] <balloons> time for questions too!
[15:10] <cgoldberg> balloons, i like lightning talks idea.  could even do several short topics summarizing python test libraries
[15:12] <elfy>  a whole session in manual testcases would be a waste of a session
[15:13] <elfy> anyway - that'll be next time - if the format is the same then
[15:13] <balloons> cgoldberg, you could propose a session that way by yourself.. do 3 or 4 lightening talks
[15:14] <balloons> or ask another person to collab with you on it
[15:16] <cgoldberg> balloons, good idea.. i'll see what i can put together, or if I can drag someone in for a duet
[15:19] <balloons> cgoldberg, perfect.. drag another person in for the fun ;-)
[15:26] <elfy> I'm not draggable this time round - too late in the day for me
[15:26] <elfy> rhetorically speaking - most of the sessions are physically too early in the day for me :)
[15:46] <cgoldberg> doanac, fginther..  hi.   have  you worked much with subunit?   i'm currently starting a project working with subunit result streams, and could use someone to ask a few questions to
[15:46] <fginther> cgoldberg, I only have experience with extracting the data stream. vila might have some better insight
[15:47] <doanac> cgoldberg: not a whole lot. just mostly converting it to junit. thomi and vila are the best people
[15:49] <cgoldberg> doanac, fginther ... i'll ask vila since thomi is out until monday  (he's my usual goto)  .. thanks!
[15:51] <cgoldberg> fginther, actually, what i'm working on is extracting the stream  .. so I want to add arbitrary attachments as test details, and extract them from the subunit stream (saved as files) ... I've got it working, but it seems like it was overly complex.  have you done something similar?
[15:53] <fginther> cgoldberg, I think doanac created something a while back that did exactly that. I'll see if I can dig it up
[15:54] <doanac> fginther: i was lucky and wound up just having to convert subunit to junit using an existing filter
[15:56] <cgoldberg> fginther, doanac ... this is what I came up with for a first attempt:  https://gist.github.com/cgoldberg/a5d6ff19dc192217d317#file-subunit_save_details-py  .. it works so far
[16:04] <fginther> cgoldberg, I don't have any good advice here. It doesn't look that complex, but perhaps there is a bettery way to do it. sorry I can't help more
[16:17] <cgoldberg> fginther, no prob.. im talking to vila.  thanks


[01:45] <flip> hey, my audio was showing as dummy driver and i uninstalled alsa and reinstalled then restarted alsa and nothing.  THis is the second time it has happened.  any idea what to do? please?
[01:48] <wxl> flip: it happens sometimes bnut not other times/
[01:49] <flip> how do you fix it?
[01:49] <wxl> i await your answer to my question to help figure that out
[01:50] <flip> if that was  question then not usually.  I reinstalled the OS to get the sound to work and it did but now its not working again
[01:50] <wxl> so it works sometimes, but not other timese
[01:50] <flip> i thought that was an answer at first
[01:50] <wxl> and there's no pattern to when it works and doesn't
[01:50] <wxl> right?
[01:50] <flip> pretty much but it hasnt worked consistently since it didnt work
[01:50] <wxl> well consistently is the key
[01:51] <wxl> random problems usually ahve random causes
[01:51] <flip> i followed some fourm advice and uninstalled alsa and pulse audio then reinstalled them and forced a restart of alsa
[01:51] <wxl> my guess is that either your sound card is failing or it's not properly connected to the motherboard
[01:51] <wxl> if `lspci` doesn't see the card, it doesn't matter what software you have, it won't work
[01:52] <flip> now the audio icon is gone from the top right...or the bar where wifi, battery...that stuff is
[01:52] <wxl> you need to look lower level
[01:52] <wxl> first confirm the kernel sees the hardware with `lspci`
[01:53] <flip> 00:1b.0 Audio device: Intel Corporation NM10/ICH7 Family High Definition Audio Controller (rev 02)
[01:53] <wxl> so it does see it which is good
[01:53] <wxl> try `lspci -nnk | grep " Audio " | grep driver`
[01:54] <flip> include the `?
[01:54] <wxl> no, that indicates the start and end of the command
[01:55] <flip> nothing ahppens, it just goes to the next line
[01:55] <wxl> oh well that's remarkable
[01:55] <wxl> oh derp
[01:55] <wxl> i did this wrong
[01:55] <wxl> try `lspci -nnk | grep -A2 " Audio " | grep driver`
[01:56] <flip> lspci -nnk | grep " Audio " | grep driver
[01:56] <flip> Kernel driver in use: snd_hda_intel
[01:56] <wxl> ok, so you have a driver
[01:56] <wxl> so that's all good
[01:57] <flip> so far so good
[01:57] <wxl> you have a wav file handy?
[01:58] <flip> maybe, i just reinstalled ubuntu 14.04
[01:58] <flip> then added apps and whatnot...but ill see would youtube wrok or specifically a wav?
[01:58] <wxl> preferably a wav
[02:00] <wxl> you can grab this http://www.nch.com.au/acm/11k16bitpcm.wav
[02:00] <flip> hu
[02:00] <flip> its working
[02:00] <flip> it asked me to click something to activate vlc
[02:01] <flip> i did that and it worked...
[02:01] <wxl> so i was going to have you test alsa, but it seems you've moved a bit upstream :)
[02:01] <wxl> which is fine
[02:01] <wxl> so what is NOT working?
[02:01] <flip> well now the video for class is working with sound so i assume everything works
[02:02] <wxl> okie dokie
[02:02] <flip> the identifier icon is not on the right though
[02:02] <wxl> also keep in mind if you're having problems with video that might be a totally different issue unrelated to sound itself
[02:02] <wxl> i always start at the lowest level:
[02:02] <flip> it was only the sound from the video, the video was working otherwise
[02:02] <wxl> 1. make sure the hardware is detectged
[02:02] <wxl> 2. make sure the kernel driver is in use
[02:03] <wxl> 3. make sure alsa is behaving (i use `aplay`)
[02:03] <wxl> 4. make sure pulse is working (i don't use it so figure that one out yourself)
[02:03] <wxl> 5. make sure something basic like an mp3 and/or a video plays with vlc
[02:04] <wxl> 6. then move to the browser
[02:04] <wxl> the browser could be a whole array of problems
[02:04] <wxl> usually the simplest solution is to use a different browser
[02:04] <wxl> of course it could be a browser plug int
[02:04] <wxl> etc
[02:04] <wxl> good luck :)
[02:04] <flip> thanks
[02:06] <flip> i think my audio was attributed to something incorrectly...im not sure but i figure it asked me to use VLC so can i set it to only use VLC?


[15:19] <hrw> looks like this channel died or something
[15:21] <ogra_> 97 zombies around though :)
[15:21] <ogra_> but yeah, #ubuntu-touch is way way more active nowadays if it comes to arm stuff
[15:22] <hrw> one ubuntu channel is enough ;D
[15:23] <ogra_> well arm got way to mainstream in ubuntu nowadays ... most of the arm stuff is just discussed in the normal channels
[15:24] <ogra_> there is only the occasional board develeoper question "how do i install ubuntu on my $sunsupported board"
[15:24] <ogra_> *unsupported
[15:25] <hrw> yep
[15:49] <ndec> hi ogra_ , in case it matters to you... https://git.linaro.org/landing-teams/working/qualcomm/pkg/alsa-lib.git/commit/511c627e826478b0b32838a659381308886f900c, that should give you UCM profile for HDMI audio on Nexus 4. it's tested on IFC6410 board
[15:49] <ogra_> heh, thanks .... we dont do anything with the N4 on HDMI though
[15:50] <ogra_> (and i think until we start using any HDMI out on phones the N4 will be long obsolete(
[15:50] <ndec> ok..


[22:50] <rlameiro> ScottL: are you there?
[22:51] <rlameiro> I am afraid that networking isnt as good as it could
[22:51] <rlameiro> the network is indeed there, we can configure etc
[22:51] <rlameiro> but for my end I couldnt connect to my house network
[22:51] <rlameiro> I even changed my router from WPA2 to WPA
[22:52] <rlameiro> I didnt tried with WEP yet, maybe it will work
[22:52] <rlameiro> about the wired, i didnt tested it yet, my igep board has the ethernet cable on it now, updating
[22:58] <ronj> rlameiro, I just sent a mail to the devel mailinglist about network testing, you should report your tests here
[22:59] <ronj> on my side I could connect to my WEP AP
[23:00] <rlameiro> well, i am not sure if it is beacuse its WAP and needs a suplicant, or not
[23:00] <rlameiro> maybe its beacus eof the encription
[23:00] <rlameiro> i will need to test with wep
[23:08] <ronj> rlameiro, does the dropdown menu listing ESSIDs work on your machine?
[23:19] <rlameiro> no
[23:19] <rlameiro> is there a drop down?
[23:20] <rlameiro> the network-admin doesnt have it
[23:20] <rlameiro> AFAIK
[23:20] <rlameiro> it is possible that my driver is not instaled, its a broadcom
[23:20] <rlameiro> but since broadcom released its drivers opensource, maybe they have it already
[23:20] <rlameiro> I will need to check that latter
[23:25] <ronj> rlameiro, broadcom released source for new cards only, the old ones we have probably will never have open drivers
[23:26] <rlameiro> well, i dont know if my card is from the olds or the newers
[23:26] <rlameiro> I will need to check


[15:22] <minimal> general question, when raising a MR which fixes multiple Launchpad issues should multiple "LP: #NNNNN" lines be put in the PR description or a single line with comma separated numbers?
[16:07] <blackboxsw> minimal:     LP: #1858928, #1858929, #1858931, #1858932
[16:07] -ubottu:#cloud-init- Launchpad bug 1858932 in cloud-init "schema: add jsonschema definition to cc_yum_add_repo" [Low, Fix Released] https://launchpad.net/bugs/1858932
[16:07] -ubottu:#cloud-init- Launchpad bug 1858929 in cloud-init "schema: add jsonschema definition to cc_update_hostname" [Low, Fix Released] https://launchpad.net/bugs/1858929
[16:07] -ubottu:#cloud-init- Launchpad bug 1858931 in cloud-init "schema: add jsonschema definition to cc_write_files" [Low, Fix Released] https://launchpad.net/bugs/1858931
[16:07] -ubottu:#cloud-init- Launchpad bug 1858928 in cloud-init "schema: add jsonschema definition to cc_update_etc_hosts" [Low, Fix Released] https://launchpad.net/bugs/1858928
[16:07] <blackboxsw> oops sorry all
[16:07] <falcojr> blame the bot ;)
[16:07] <blackboxsw> ubottu: why be so noisy :)
[16:08] <minimal> blackboxsw: thanks
[18:36] <ananke> I don't suppose cloud-initramfs-growroot is part of cloud-init?
[18:44] <ananke> I'm tracking a bug in the latest Kali AMI, which involves missing flock. The issue in theory was solved, but somehow it resurfaces for me, when I apply all of the updates and make a new image. trying to figure out if it's something in our process that may be causing it, or Kali broke something
[18:48] <waldi> no, this is outside of cloud-init. and i think i know when it broke
[18:49] <ananke> I found a mention of it here<EMAIL_ADDRESS>, now trying to see if the bug fix is present or not
[18:59] <ananke> the hooks script present in cloud-initramfs-growroot is already the newest version (0.18.debian11).
[18:59] <ananke> oops, wrong paste
[18:59] <ananke> the hooks script present in cloud-initramfs-growroot 0.18.debian11 does not seem to contain the same stuff as https://git.launchpad.net/cloud-initramfs-tools/tree/growroot/hooks/growroot#n12
[19:01] <minimal> ananke: wouldn't it be a case of adding a "dracut_install flock" to the growroot/dracut/modules.d/50growpart/install file?
[19:04] <ananke> minimal: possibly, I may ultimately do that to get us going. I'm trying to determine who's at fault first :) (me/us, kali, debian)
[19:05] <ananke> in case of kali/debian, there is no dracut though
[19:05] <minimal> ananke: well the other change you mentioned just checks if flock is present and gives and error if not, the change I'm suggesting (from a cursory glance) is to add flock to the initramfs, so avoid the error that it's not present ;-)
[19:05] <minimal> ok, well whatever manages the initramfs
[19:05] <minimal> initramfs-tools
[19:06] <ananke> minimal: are you referring to the bug url I posted? this seems to actually copy flock, rather than check for its presence
[19:06] <ananke> and sure enough, my initramfs lacks flock. I should check if their vanilla AMI has flock in initramfs
[19:09] <ananke> it doesn't have flock either, but resizes just fine. fun
[19:58] <minimal> ananke: I've never seen growpart run in an initramfs before
[20:05] <ananke> minimal: not sure if it's a new behavior or not, running out of initramfs that is
[20:06] <ananke> but it's certainly there, and has been for some time
[20:11] <ananke> still baffles me that their AMI works just fine on first boot, without that flock in initramfs. the problem likely happens with the update to cloud-initramfs-tools, their AMI comes with 0.18.debian8, but update sets it to 0.18.debian11
[20:12] <ananke> and looks like there may be another issue, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027050
[20:12] -ubottu:#cloud-init- Debian bug 1027050 in cloud-initramfs-growroot "growing image fails to boot: /scripts/local-bottom/growroot: line 97: wait-for-root: not found" [Important, Open]
[21:11] <ananke> this whole thing is a hot mess. latest debian package also no longer includes hooks for sed/grep/rm, so growpart throws even more errors
[21:46] <ananke> smoser: I'd love your take on this issue, if you happen to be available sometime this week :)


[03:17] <bddebian> Heya
[06:23] <Hobbsee> hi all
[06:23] <robotgeek> hey Hobbsee
[06:23] <Hobbsee> robotgeek: :)
[06:24] <imbrandon> heya Hobbsee
[06:25] <Hobbsee> hi imbrandon, how's the machine?
[06:25] <imbrandon> being lazy lol, lemme add you an account, give me a few minutes
[06:25] <Hobbsee> imbrandon: heh
[06:25] <imbrandon> i'm vnc'd into my brothers machine atm helping him
[06:25] <imbrandon> for a moment
[06:25] <Hobbsee> ah
[06:25] <Hobbsee> fair enough
[06:26] <imbrandon> he is converting from windows to kubuntu ;)
[06:26] <Hobbsee> imbrandon: nice!  :)
[06:29] <robotgeek> nice!
[06:29] <robotgeek> i used OS X for 3 weeks. now i am back on kubuntu
[06:30] <imbrandon> heh i'm torn between osx and kubuntu
[06:31] <lnxkde> talking about osx
[06:31] <robotgeek> i really like kmail. and amarok :)
[06:32] <lnxkde> someone here using kxdocker or engage with compiz and xgl on kubuntu?
[06:32] <lnxkde> :P
[06:32] <Hobbsee> sounds scary.
[06:32] <Hobbsee> robotgeek: you manage to stop kmail crashing?  wow.
[06:32] <lnxkde> http://img225.imageshack.us/img225/9413/snapshot1ge3.png <-- curent kubuntu system
[06:32] <robotgeek> Hobbsee: i'm still on dapper?
[06:33] <Hobbsee> robotgeek: that's when i was trying kmail.
[06:34] <robotgeek> hmm, to come to think of it, kmail died on me when i shoved 250mb of mail at it
[06:36] <Hobbsee> hehe
[06:38] <robotgeek> i now like to keep kmail's mail directory separate on another partition, where it is readable by mutt also :)
[06:38] <Hobbsee> hehe
[06:39] <imbrandon> revolution os, heh i havent seen that movie in a while
[06:39] <imbrandon> good call
[06:39] <robotgeek> i have great difficulty using thunderbird after i've gotten used to kmail
[06:40] <Hobbsee> good point
[06:40] <robotgeek> the killer feature is the attachment thing, which reminds you if you have forgotten to attach files
[06:40] <imbrandon> i like thunderbird becouse i can use it on osx / windows and linux
[06:40] <robotgeek> you can get that in thunderbird via an extension
[06:41] <Hobbsee> ahh...i've learned to attach files first, then write the message afterwards - so i cant forget
[06:41] <Hobbsee> seeing as i use webmail every once in a while too
[06:42] <robotgeek> i usually dont use webmail, so not an issue for me.
[06:42] <Hobbsee> lucky...i dotn take my laptop everywhere
[06:43] <imbrandon> heh , i take mine EVERYWHERE
[06:43] <imbrandon> thats the point of having it for me
[06:43] <imbrandon> otherwise i use desktopsa
[06:43] <imbrandon> s/a//
[06:43] <robotgeek> gmail is blocked at work, and i dont bring work email home
[06:44] <Hobbsee> ahhh...
[06:45] <imbrandon> Hobbsee: yea showoff kde at the uni ;)
[06:45] <Hobbsee> imbrandon: heh, could do that.
[06:45] <imbrandon> and koffice ;)
[06:45] <imbrandon> and knotes etc ;)
[06:59] <Hobbsee> how do you pin a package?
[06:59] <Hobbsee> !pin
[06:59] <ubotu> I know nothing about pin - try searching http://bots.ubuntulinux.nl/factoids.cgi?db=ubuntu
[06:59] <Hobbsee> !pinning
[06:59] <ubotu> pinning is an advanced feature that APT can use to prefer particular packages over others.  In repository main, is optional. Version 2:1.0.0-0ubuntu9 (dapper), package size 693 kB, installed size 3368 kB
[08:41] <imbrandon> !info libx11-6 edgy
[08:42] <ubotu> libx11-6: X11 client-side library. In repository main, is optional. Version 2:1.0.3-0ubuntu1 (edgy), package size 553 kB, installed size 1176 kB
[09:01] <Hobbsee> imbrandon: yeah.
[09:01] <imbrandon> kk
[09:01] <Hobbsee> imbrandon: why do you have a k7 kernel installed on what is showing as an i686 machine?
[09:01] <imbrandon> its not 686 , cat /proc/cpuinfo
[09:02] <Hobbsee> imbrandon: ahhh...according to uname -a it is
[09:02] <imbrandon> amd64 3400+
[09:02] <imbrandon> ;)
[09:02] <Hobbsee> hmmm okay
[09:02] <imbrandon> hehe
[09:02] <imbrandon> its actualy a k8 proc but
[09:02] <imbrandon> i dident want 64bit
[09:03] <imbrandon> hehe cool
[09:03] <imbrandon> i'm loading dapper on my lappy
[09:03] <imbrandon> so i have atleaste __one_stable machine to check my mail etc heh
[09:05] <imbrandon> and watch sg-1 epsodes on ( since season 10 just started ) heh
[09:06] <imbrandon> Hobbsee: is there a "craigslist" for sydney ? reason i ask is i found some great deals on apple lappys on there
[09:06] <Hobbsee> imbrandon: a what?  no idea...
[09:06] <imbrandon> you might check that ;)
[09:06] <imbrandon> ahh its like a garage sale on the internet
[09:07] <imbrandon> one for all major cities
[09:07] <Hobbsee> ahh...
[09:07] <imbrandon> leaste in the US, i'll check if they have a sydney one
[09:08] <imbrandon> haha matter of fact they do, thats cool
[09:08] <Hobbsee> where at?
[09:08] <Hobbsee> ahh
[09:08] <imbrandon> Hobbsee: http://sydney.craigslist.org/ <-- main url ....... check http://sydney.craigslist.org/sys
[09:08] <imbrandon> for computer stuff
[09:09] <imbrandon> pretty good place to get stuff, becouse you can physicaly check it out before you buy it
[09:09] <imbrandon> becouse its local 99% of the time
[09:10] <Hobbsee> oh nice :)
[09:10] <imbrandon> heh yea i find most of my computers that way
[09:10] <imbrandon> lots cheaper
[09:10] <Hobbsee> the salesperson asked if i did a subject at the uni, whcih i had - he recognised me
[09:10] <imbrandon> heheh
[09:12] <Hobbsee> i'm like "yeah, i got a distinction in it"  "oh wow!"
[09:12] <imbrandon> heh, distinction == good ?
[09:13] <Hobbsee> imbrandon: it goes, from top to bottom:  high distinction, distinction, credit, pass, conceded pass, fail
[09:13] <imbrandon> ahh ok , cool
[09:13] <imbrandon> ohh cruft your still on intrepid heh
[09:13] <Hobbsee> yeah.
[09:13] <imbrandon> i forgot to add you to voyager
[09:13] <imbrandon> lol
[09:13] <Hobbsee> meany :(
[09:13] <imbrandon> one sec
[09:13] <imbrandon> hehe give me a sec
[09:17] <danimo> moin!
[09:18] <Hobbsee> hi danimo!
[09:18] <imbrandon> ok Hobbsee grab anything you need off intrepid and logout for the last time, lemme know when your off
[09:19] <danimo> heya Hobbsee!
[09:19] <imbrandon> heya danimo
[09:19] <danimo> hi imbrandon
[09:19] <Hobbsee> imbrandon: just the simflight*.deb in /var/cache/pbuilder/edgy/result
[09:20] <imbrandon> heh copy it to /media/server/hobbsee
[09:20] <imbrandon> you will be able to grab it from there off voyager
[09:20] <imbrandon> i have /media/server mapped on all the comuters
[09:21] <imbrandon> anyhow when you have everything copied you want lemme know i'll shutdown intrepid and transfer the ssh ports to voyager
[09:21] <Tm_T> hmmmh
[09:22] <Tm_T> Hobbsee: like to test something simple?
[09:22] <Tm_T> or anyone with KDE 3.5.4
[09:22] <imbrandon> Sysinfo for 'voyager': Linux 2.6.17-5-686 running KDE 3.5.4, CPU: Intel(R)Celeron(R)CPU2.93GHz at 2933 MHz (5874 bogomips), , RAM: 627/1003MB, 103 proc's, 6.40h up
[09:23] <imbrandon> i'm on 354 wasup ?
[09:23] <Tm_T> just try to use custom titlebar button settings
[09:23] <imbrandon> i do
[09:23] <imbrandon> thats one of the first things i set
[09:23] <Tm_T> that's one of main problems here, over half of windeco settings doesn't apply
[09:24] <imbrandon> hrm i use the akdc kwin windeco
[09:24] <imbrandon> that might be part of it
[09:24] <Tm_T> I tried many
[09:24] <imbrandon> hrm strange
[09:24] <Tm_T> indeed
[09:25] <imbrandon> and see
[09:25] <Tm_T> almost like som parts of kwinrc is skipped while reading
[09:25] <imbrandon> seems to work for me here, let me fiddle with another engine
[09:25] <Hobbsee> imbrandon: havent transferred stuff yet
[09:25] <imbrandon> and see
[09:25] <Tm_T> imbrandon: thanks
[09:25] <imbrandon> Hobbsee: thats fine, just lemme know when
[09:25] <Hobbsee> imbrandon: did you have my last lot of backup?
[09:26] <imbrandon> what ever is in /media/server/hobbsee is what i have backed up for you from your /home
[09:26] <imbrandon> its not recient
[09:26] <imbrandon> the pbuilder etc i have all setup already on voyager
[09:26] <imbrandon> just not your /home stuff
[09:26] <Hobbsee> right, so i'll need the profile
[09:27] <Hobbsee> sigh.  can i kill off bluefoxicy please?
[09:27] <imbrandon> yea honestly i would rm -rf /media/server/hobbsee/* and just copy what you want like your .gnupg and .bash*
[09:27] <imbrandon> and any deb's you just built
[09:27] <Hobbsee> imbrandon: having trouble connecting in again
[09:28] <Hobbsee> imbrandon: i can tell you where the stuff is, if you want
[09:28] <imbrandon> kk one sec lemme login to it
[09:28] <imbrandon> k i'm in
[09:28] <imbrandon> what ya need ?
[09:29] <Hobbsee> imbrandon: okay, .bash_profile and .bashrc
[09:29] <Hobbsee> ~/.gnupg
[09:30] <Hobbsee> and /var/cache/pbuilder/edgy/result/simgear*.deb
[09:30] <imbrandon> k
[09:30] <imbrandon> gimme just a sec
[09:30] <imbrandon> meanwhile think of a good name for my lappy hehe
[09:31] <Hobbsee> heh
[09:32] <imbrandon> http://pastebin.ca/106294  <-- anything else ?
[09:33] <Hobbsee> imbrandon: scritps in /usr/local/bin?
[09:33] <imbrandon> ahh yea one sec
[09:33] <Hobbsee> hehe
[09:34] <Hobbsee> dont make me write them again :P
[09:34] <imbrandon> heh i have them all already cept {dapper,revu,edgy}build
[09:35] <Hobbsee> imbrandon: i'd just get them, and overwrite them or something.
[09:35] <Hobbsee> it doesnt really matter
[09:36] <imbrandon> well i modified the pbuilder-* to use the US mirrors and not the gb/jp/au ones it had
[09:36] <imbrandon> heh
[09:36] <Hobbsee> ah right
[09:36] <imbrandon> so i'll keep those and just get the *build ones
[09:36] <Hobbsee> yep
[09:37] <imbrandon> brandon@intrepid:/usr/local/bin$ sudo cp -Rv {dapper,revu,edgy}build /media/server/hobbsee/
[09:37] <imbrandon> `dapperbuild' -> `/media/server/hobbsee/dapperbuild'
[09:37] <imbrandon> `revubuild' -> `/media/server/hobbsee/revubuild'
[09:37] <imbrandon> `edgybuild' -> `/media/server/hobbsee/edgybuild'
[09:37] <imbrandon> kk done
[09:37] <imbrandon> think thats it
[09:37] <Hobbsee> imbrandon: cool
[09:38] <imbrandon> your gonna have to clean out your ~/.ssh/known_hosts file again or it will complain
[09:38] <imbrandon> ( localy )
[09:38] <imbrandon> seaLne: kerry is mono isnt it ?
[09:38] <imbrandon> heh
[09:38] <seaLne> is it?
[09:39] <imbrandon> i think so
[09:39] <Hobbsee> imbrandon: yep, cool, okay
[09:43] <imbrandon> ok Hobbsee login
[09:43] <imbrandon> should be all ready
[09:47] <seaLne> its a pity basket 0.6 probably won't be ready for edgy as it looks so much nicer
[09:47] <seaLne> (than tomboy)
[09:48] <Hobbsee> seaLne: when will it be ready?
[09:48] <imbrandon> Hobbsee: once your in just grab the files from /media/server/hobbsee
[09:48] <seaLne> http://basket.kde.org/development.php no idea
[09:48] <Hobbsee> imbrandon: they seem to be there...
[09:48] <Hobbsee> oh.
[09:48] <Hobbsee> oops.
[09:48] <imbrandon> heh just the defaults are there
[09:49] <imbrandon> i dident copy them to your new /home yet
[09:49] <imbrandon> hehehe
[09:50] <imbrandon> since i fixed the mirrors and for pbuilder and the fact voyager has more ram it should build faster
[09:51] <Hobbsee> oh yay.
[09:52] <seaLne> Riddell: is there going to be a meeting tommorow?
[09:53] <Hobbsee> seaLne: hopefully not.
[09:53] <Hobbsee> seaLne: and it's still a bit early for Riddell
[09:53] <Hobbsee> oh, wait, we were having trouble with times.
[09:53] <imbrandon> Hobbsee: you might want to pbuilder-edgy update too i havent done it since yesterday
[09:56] <imbrandon> new version ?
[09:57] <Hobbsee> that i had locally
[09:59] <Hobbsee> ooh, colour prompt!
[09:59] <imbrandon> heh
[10:06] <Hobbsee> imbrandon: thanks :)
[10:07] <imbrandon> hehe np
[10:07] <imbrandon> this is my day to day machine though try not to botch it up with dist-upgrades ;)
[10:07] <imbrandon> hehe
[10:07] <Hobbsee> yay for screen.
[10:10] <Hobbsee> bye all
[10:16] <seaLne> hmm "09:07 < Hobbsee> yay for screen." and "09:10 < Hobbsee> bye all" don't make sense :)
[10:17] <imbrandon> seaLne: heh why ?
[10:18] <seaLne> i was expecting her to have started ircing from within screen :)
[10:19] <seaLne> my first coffee of the day is now ready so i may make more sense shortly
[10:20] <imbrandon> ahh no she is building on voyager with screen
[10:20] <imbrandon> for the yay , then i guess hse had to run ;)
[10:37] <seaLne> when is universe freeze, i can't find the page on the wiki with dates
[10:40] <seaLne> ah found it
[11:08] <Tm_T> MMMOOOOH
[11:09] <Tm_T> ok, now every "tip of the day" or "first run wizard" are active
[11:10] <Tm_T> some weird kdelibs issue
[11:16] <Tm_T> AERGH! just noticed, all my input actions are gone
[11:18] <imbrandon> he
[11:18] <imbrandon> heh
[12:08] <toma> mo
[12:14] <Tm_T> moin
[12:17] <toma> mo Hobbsee
[12:17] <Hobbsee> hi toma
[12:20] <danimo> wb Hobbsee
[12:20] <Hobbsee> hi danimo
[12:20] <Hobbsee> yay, it built.
[12:20] <danimo> Hobbsee: did the wpa key hint help?
[12:20] <Hobbsee> danimo: havent tried it - didnt feel like fighting it last night when i was very tired
[12:20] <Hobbsee> i'm thinking kde sessions is mucking this card up, actually.  we'll see.
[12:37] <danimo> Hobbsee: which card?
[12:58] <toma> Hobbsee: could you review a new package for me? Whenever I succeed debianising it?
[01:13] <toma> The pbuilder howto tells me to "sudo pbuilder build my-package_1.0.dsc", but how do i get a .dsc?
[01:15] <Hobbsee> ahhh....yes...that's why i dont like using pbuilder as such, but use pdebuild.
[01:16] <Hobbsee> danimo: ah, a netgear wg511 v2 made in china, and a dlink dwl-660
[01:16] <Hobbsee> Sime: yay!
[01:16] <Hobbsee> Sime: when do we see it?
[01:16] <Sime> Hobbsee: there is a spec for it...
[01:16] <danimo> Hobbsee: dlink, netgear, the pure evil :)
[01:16] <Sime> Hobbsee: https://wiki.kubuntu.org/KubuntuSystemSettingsUsability
[01:16] <Hobbsee> danimo: dlink isnt so bad....
[01:16] <Hobbsee> danimo: netgear, with a marvell driver though...
[01:17] <Hobbsee> danimo: the real problem is that it doesnt like my network - it was workign fine in this machine while i was out, but not at home
[01:17] <danimo> Hobbsee: I had my very special expririence, with a dlink router though
[01:19] <Hobbsee> Sime: looks good
[01:19] <Sime> Hobbsee: the implementation is now pretty close to the mock up. :)
[01:19] <Hobbsee> Sime: yay :
[01:19] <Hobbsee> )
[01:23] <Hobbsee> Sime: at least the theme support needs some love - you probably already know that
[01:24] <Sime> Hobbsee: you mean the theme manager?
[01:24] <Hobbsee> Sime: sorry, yeah.
[01:24] <Hobbsee> Sime: people get confused a lot in dapper, saying "how can i install a theme"
[01:24] <Hobbsee> Sime: that should probably be rectified somehow - whether there's a help text on the side, or a help button, or what.
[01:24] <Sime> Hobbsee: yeah, I don't think it is in dapper. not sure if it is planned for edgy
[01:25] <Hobbsee> Sime: oh it's in dapper, no question - it's just that the differnet parts of the theme are treated separately
[01:26] <Hobbsee> Sime: so you can install a theme of colours, a theme of icons, a theme of windecos...but no way to install "a theme" of all the bits together, and it's obviously not terribly obvious that you're to download and install each bit separately.
[01:26] <Hobbsee> Sime: i mean, i figured that out, but a lot of our users in #kubuntu havent - and that's probably worth fixing.
[01:26] <Hobbsee> is anyone else's kmenu buggered - ie, not updating?
[01:27] <Sime> yeah, mines rooted. :-)
[01:27] <Hobbsee> right....thought it might be
[01:27] <Hobbsee> hi apachelogger
[01:28] <apachelogger> ahoy Hobbsee
[01:28] <Sime> Hobbsee: sorry, I had to laugh. There is only one country that uses the word "buggered" like that. ;-)
[01:29] <Hobbsee> gah.  and i was going to use "screwed" instead, but thought better of it.
[01:30] <Hobbsee> anyway, s/buggered/broken.
[01:30] <Hobbsee> :P
[01:30] <apachelogger> Hobbsee: could you please change ...including xmms, noatun, kscd, juk, kaffeine and amarok.   --->  including Amarok, XMMS, Noatun, KsCD, JuK and Kaffeine.
[01:30] <Sime> I've come to like the "bitched". i.e my menu is complete bitched.
[01:30] <Sime> the word ^
[01:31] <Sime> anyway, about the theme manager. I don't know if it is on Riddell's TODO list for edgy.
[01:31] <apachelogger> Hobbsee: kopete control file that is ^^
[01:32] <Hobbsee> Sime: not that we really need a theme manager in itself - the current one is good - but it's not obvious in how to use it.
[01:32] <Hobbsee> apachelogger: it's in main now - grab source, change whatever you like, put it on revu :)
[01:32] <apachelogger> oh-kay :D
[01:33] <Hobbsee> apachelogger: did what i say go totally over your head?
[01:33] <Hobbsee> Sime: open it up one day.  it's under appearances - see the buttons marked "import" or something similar
[01:34] <apachelogger> Hobbsee: well, I coded yesterday 8 hours in ruby ;-)
[01:34] <Hobbsee> apachelogger: nice!
[01:34] <Hobbsee> that would go over my head, no questoin.
[01:34] <Sime> Hobbsee: :-> not any more it ain't. The theme manager isn't in Ellen's new sys-settings menu structure...
[01:35] <Hobbsee> Sime: ah.  right.
[01:35] <apachelogger> Hobbsee: hehe, at least that damn plugin for insanity @ #amarok is now kind of working :)
[01:35] <Hobbsee> apachelogger: hehe, nice.  which plugin was that?
[01:35] <apachelogger> Hobbsee: advanced bar plugin
[01:35] <Hobbsee> !flash
[01:35] <ubotu> For multimedia issues, this page has useful information: https://help.ubuntu.com/community/RestrictedFormats  -  See also http://help.ubuntu.com/ubuntu/desktopguide/C/common-tasks-chap.html  -  But please use free formats if you can: https://help.ubuntu.com/community/FreeFormats
[01:36] <Hobbsee> ah right
[01:36] <apachelogger> so one can order stuff
[01:36] <Hobbsee> yep
[01:36] <apachelogger> though it ends one day :P
[01:36] <toma> okay, that worked
[01:39] <imbrandon>   *cough* and include kdm theme manager from kde-look.org *cough*
[01:39] <Hobbsee> imbrandon: didnt we include that?
[01:39] <imbrandon> yea themes in kde need a little love though, i have had to fuge them alot with the royale and osx theme
[01:39] <Hobbsee> oh, maybe not.
[01:39] <imbrandon> Hobbsee: not in dapper, havent looked in edgy
[01:40] <Hobbsee> imbrandon: can you shoot me an email about that please?
[01:40] <imbrandon> sure
[01:41] <Hobbsee> imbrandon: thanks.
[01:41] <Hobbsee> imbrandon: know if the latest version is 1.1?
[01:42] <imbrandon> something close to that yea
[01:45] <Riddell> seaLne: no meeting planned
[01:45] <Hobbsee> argh, how do you find if anything doesnt have any build-deps outside of main, apart from building a chroot and testing it that way?
[01:45] <Hobbsee> hi Riddell!
[01:45] <Riddell> morning
[01:46] <imbrandon> moins Riddell
[01:46] <imbrandon> bbiab yall switching to lappy
[01:46] <Riddell> Sime: theme manager is probably just a case of removing the buttons to launch the other kcontrol modules, then it can be added in
[01:47] <Hobbsee> Riddell: could we get kcontrol-kdmtheme installed by default?
[01:47] <Riddell> Hobbsee: hmm, yet another kcontrol module
[01:47] <Riddell> would be ok if it was part of the default kdm module
[01:48] <Hobbsee> Riddell: add it to the appearance stuff.
[01:48] <Hobbsee> Riddell: or in that.  do we have a working kdm default module?
[01:49] <Riddell> it was working last I used it
[01:49] <Riddell> which wasn't recently, but I've not heard any problems with it
[01:49] <Hobbsee> it's been a while since i have, so okay.
[01:49] <Hobbsee> Riddell: how do we fix a borked arts?
[01:49] <Hobbsee> Riddell: it doesnt generate any sort of useful backtrace.
[01:51] <seaLne> Riddell: k
[01:51] <Riddell> Hobbsee: revert back to 1.5.2 I guess
[01:52] <Sime> speaking of arts... does anyone have mp3s working in arts or notuan? (not amorak, it uses the xine backend for mp3)
[01:53] <Riddell> you'll need libakode2-mpeg and/or libarts1-mpeglib
[01:53] <Hobbsee> Sime: er...how do you get mp3's working in arts, per se?  as far as i know, arts is not a music plaer
[01:53] <Hobbsee> *player
[01:53] <Hobbsee> Riddell: hmmm...okay...did you want the backtrace?  it really is borked and useless.
[01:54] <Hobbsee> it even says so itself :P
[01:54] <Riddell> I get the crash too
[01:54] <Hobbsee> Riddell: right, okay.
[01:54] <Sime> Hobbsee: I'm with apps that use arts as a backend.
[01:54] <Hobbsee> Sime: yep, right.
[01:55] <Sime> Hobbsee: from what I understand, mp3 decode normally happens inside arts itself (in an arts plugin)
[01:55] <Hobbsee> Sime: true.  i think.  i really dont know though
[02:03] <Lathiat> yeh it is
[02:03] <Hobbsee> !show libdvdread3 edgy
[02:03] <ubotu> I know nothing about show libdvdread3 edgy - try searching http://bots.ubuntulinux.nl/factoids.cgi?db=ubuntu
[02:03] <Hobbsee> !info libdvdread3 edgy
[02:03] <ubotu> libdvdread3: library for reading DVDs. In repository main, is optional. Version 0.9.6-1 (edgy), package size 53 kB, installed size 196 kB
[02:04] <danimo> suse even patched it out of kde
[02:04] <danimo> (3)
[02:04] <Hobbsee> yay.  i'll need an uploader for that, i suspect.
[02:04] <insanekane> danimo: what does suse kde use instead ?
[02:04] <danimo> insanekane: an early version of phonon, back then developed for kde 3
[02:04] <insanekane> danimo: aha ok
[02:05] <danimo> insanekane: causes a lot less trouble with other sound applications it seems
[02:05] <insanekane> danimo: havent they given the patches back to kde so that they can be applied in kubuntu as well ?
[02:05] <Hobbsee> woo!  i can fix two bugs at once for this, i think.
[02:05] <danimo> insanekane: but it's fairly intrusive of course
[02:05] <danimo> insanekane: well, the patches are public
[02:05] <danimo> insanekane: they did come from kde in first place
[02:05] <insanekane> danimo: aha ok
[02:06] <insanekane> danimo: so why wasnt it applied ?
[02:06] <danimo> insanekane: but I think it would be easiset to pull the latest version from the suse rpms
[02:06] <danimo> insanekane: because Riddell thinks it's too intrusive
[02:06] <insanekane> intrusive in the sense ? apps stop working ?
[02:06] <danimo> insanekane: well, if anyone's heart is on noatun... ;)
[02:07] <danimo> Riddell: what was your reason?
[02:09] <Riddell> danimo: for what?
[02:10] <Riddell> hmm, phonon in kde 3, hmm
[02:10] <danimo> Riddell: it used to be called different
[02:10] <danimo> Riddell: but it uses xine as a playerbackend afaik
[02:10] <Riddell> using an unreleased version of an API/library makes me nervous
[02:11] <danimo> Riddell: well, it's not a public api anyway
[02:11] <danimo> not meant to be a..
[02:11] <danimo> Riddell: it is a workaround for sure
[02:11] <danimo> but one would have to try and see if it's worth it
[02:12] <Hobbsee> after all, it is edgy, and we've just discovered at arts is fubar'd at current version
[02:13] <danimo> Hobbsee: that took you quite a while... ;)
[02:13] <Hobbsee> danimo: hmmm?
[02:13] <Hobbsee> danimo: i was examining libdvdread.
[02:13] <danimo> Hobbsee: oh, inside the kde project, arts is considered dead for a long time
[02:13] <Hobbsee> danimo: yeah, exactly
[02:13] <danimo> Hobbsee: we just can't help releasing it to maintain b/c
[02:14] <Hobbsee> b/c?
[02:14] <danimo> Hobbsee: that's why I was joking about it taking you until edgy to realize
[02:14] <danimo> Hobbsee: oh, binary compatible
[02:14] <Hobbsee> oh
[02:14] <Hobbsee> ahh...
[02:14] <danimo> and source (read: API) compatible
[02:14] <danimo> we cannot just take away an API in KDE
[02:14] <danimo> if a distributor does it, that's fine
[02:14] <danimo> as long as he and his users can live with it
[02:14] <Hobbsee> are they not releasing their sources or something?
[02:15] <danimo> Hobbsee: who?
[02:16] <Hobbsee> danimo: whoever is the one who is in charge of the binaries
[02:16] <danimo> Hobbsee: no, I think you misunderstood
[02:16] <danimo> Hobbsee: the KDE project committed to maintain binary compatiblity across minor releases
[02:17] <danimo> Hobbsee: to exactly avoid the need of say, recompiling all apps only because someone upgraded the kdelibs
[02:17] <danimo> Hobbsee: so recompiling is not an option
[02:17] <Hobbsee> danimo: ahhh...right.
[02:17] <Hobbsee> danimo: yes, i did then
[02:19] <danimo> Hobbsee: all KDE needs arts for is noatun and the kde system sounds
[02:19] <Hobbsee> yeah, right.  those system sounds.  grumble.
[02:20] <danimo> Hobbsee: noatun is not shipped by default at least, and the kde system sounds work just fine with the drop-in replacement
[02:20] <danimo> Hobbsee: which uses xine
[02:20] <danimo> Hobbsee: and libxine is in main, no?
[02:20] <Hobbsee> true
[02:20] <Hobbsee> nice
[02:20] <Hobbsee> ah, yeah, it is
[02:21] <danimo> Hobbsee: less problems, at the price of switching an onofficially unsupported piece of software to an officially unsupported one :)
[02:21] <danimo> from an unofficially...
[02:21] <Hobbsee> danimo: Riddell's the one you need to convince :P
[02:22] <danimo> Hobbsee: I need to take over the rest of the channel first ;)
[02:22] <Hobbsee> danimo: heh
[02:22] <danimo> seriously, though: Riddell: would you have a look at it?
[02:25] <Hobbsee> oh yay.  i need to get a 16mb source, because i cant remember a command that i want to use.  grumble.
[02:25] <danimo> Hobbsee: see, he ignores me ;)
[02:26] <Hobbsee> danimo: he's busy, and it's a sunday.  he'll come back.
[02:26] <danimo> Hobbsee: only one more day :)
[02:26] <danimo> Hobbsee: yeah, I was kiddin
[02:26] <Hobbsee> danimo: he ignores me too, at times, you know
[02:26] <Hobbsee> yeah, fortunately :P
[02:26] <danimo> quick, someone donate Hobbsee a flat rate
[02:27] <Hobbsee> heh
[03:31] <mhb> Hobbsee: how come?
[03:31] <Hobbsee> mhb: i fixed the bug!
[03:31] <mhb> THE bug? :o)
[03:32] <Hobbsee> well, a bug.
[03:32] <Hobbsee> the one that makes the dvd support not properly install
[03:32] <Hobbsee> i just need an uploader for it... *pokes Riddell*
[03:33] <mhb> that reminds me of the bug I have to solve :o)
[03:34] <Hobbsee> mhb: hehe, which one?
[03:34] <mhb> Hobbsee: in my own code ... (a tiny contribution to mountconfig, not even worth mentioning :o)
[03:34] <Hobbsee> mhb: ah.  well...
[03:37] <mhb> Hobbsee: yeah, I should stop chatting and get back to work :o)
[03:37] <Hobbsee> mhb: heh.  chatting is good ;)
[03:38] <Hobbsee> what bug shall i fix next?  hmmm...
[03:41] <toma> is there someone on edgy that can check if a package installs?
[03:43] <Hobbsee> toma: yeah, which one?
[03:43] <toma> Hobbsee: http://kubuntu.omat.nl/edgy/
[03:44] <toma> 39K only
[03:45] <Hobbsee> toma: yep, that's installable
[03:45] <toma> Hobbsee: oki, thanks
[03:48] <bddebian> Hello
[03:48] <Riddell> Hobbsee: hi
[03:48] <toma> hi bddebian
[03:48] <Hobbsee> heya Riddell.  you're in luck, i bugged zul, so you wont have to upload for me :P
[03:48] <bddebian> Hello toma, Riddell
[03:49] <Hobbsee> assuming we can make it work
[03:49] <Riddell> danimo: I've not looked at replacing arts no, mostly because it would be a patch I'd have to maintain
[03:50] <danimo> Hobbsee: so, there you go
[03:52] <Hobbsee> oh yay.  oo.o is still broken.
[03:54] <danimo> Hobbsee: yeah
[03:55] <danimo> Hobbsee: I am building Qt 4.2 on dapper now. I really should package it though
[03:55] <Hobbsee> for dapper?  why
[03:55] <danimo> Hobbsee: no, edgy
[03:55] <danimo> sorry
[03:56] <danimo> Hobbsee: I can't just take the old dsc file, since the QtDbus stuff would require me to extend it
[03:56] <Riddell> danimo: qt-copy is packaged as qt4-x11-kdecopy in edgy, but it's failed to build on the buildds and I'm not sure why
[03:56] <danimo> Riddell: ah, ok
[03:56] <danimo> Riddell: now that's not good
[03:56] <danimo> Riddell: since it compiled fine for me
[03:57] <danimo> or compiles so far
[03:57] <danimo> Riddell: is threre a way to see the build logs?
[03:58] <Riddell> it compiled fine for me locally, something about the buildd setup is making it break
[03:58] <danimo> ah, ok
[03:58] <Riddell> http://librarian.launchpad.net/3643847/buildlog_ubuntu-edgy-i386.qt4-x11-kdecopy_4.2.0~svn20060706-0ubuntu1_FAILEDTOBUILD.txt.gz
[03:58] <danimo> 4.4 MB? *yikes*
[03:59] <Riddell> the error will be near the end :)
[03:59] <danimo> cp: cannot stat `debian/tmp//usr/lib/libQtDBus.so': No such file or directory
[03:59] <danimo> yes, so the libQtBus stuff is causing it headaches
[04:00] <danimo> Riddell: and applying the patches seems to go wild
[04:00] <Riddell> hmm
[04:01] <Riddell> so if I just remove that file from the list that need to go into the .debs it should be ok
[04:02] <danimo> Riddell: I think the problem is deeper down in the build process
[04:02] <danimo> Riddell: because we ultimately need that lib, no? :)
[04:03] <Riddell> yeah, it must be missing some dbus dependency
[04:06] <Hobbsee> Riddell: when were you wanting another meeting, btw?
[04:07] <Riddell> week on wednesday?
[04:08] <Hobbsee> Riddell: okay, 2100UTC?
[04:08] <Riddell> yeah
[04:09] <Hobbsee> s
[04:10] <Riddell> I can't remember, what was it for?
[04:11] <Hobbsee> Riddell: kopete fixes
[04:11] <Hobbsee> Riddell: with mdz
[04:11] <danimo> bah, konvi crash
[04:12] <danimo> Riddell: thanks for taking care about aaa 4
[04:12] <Riddell> it did need some taking care of that
[04:13] <Riddell> Hobbsee: not too sure, I seem to remember uploading it
[04:13] <Hobbsee> Riddell: it doesnt seem to be in https://launchpad.net/distros/ubuntu/dapper/+source/kdenetwork/+builds
[04:13] <Riddell> Accepted kdenetwork 4:3.5.2-0ubuntu6.1 (source)
[04:13] <Riddell> it must still be in the to be approved queue
[04:14] <Riddell> we'll need to poke an ubuntu-archive member
[04:14] <Hobbsee> Riddell: want to do it when they're around.  i'm going to go to bed....
[04:14] <Riddell> yep
[04:14] <Hobbsee> but we probably should get that fixed.
[04:15] <Hobbsee> Riddell: where can we see the approved queue?
[04:15] <Riddell> I don't know if we can
[04:15] <Hobbsee> Riddell: we can see new, not sure about approved though.
[04:16] <Riddell> this is different from NEW though I think
[04:16] <Riddell> it's not in https://launchpad.net/distros/ubuntu/dapper/+queue
[04:16] <Hobbsee> Riddell: okay
[04:29] <freeflying|away> Riddell: bug 54522 will you review the patch?
[04:29] <Ubugtu> Malone bug 54522 in libx11 "wine under zh_CN.UTF-8 locales performs too slow" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54522
[04:36] <Sime> mhb: hi
[04:37] <mhb> Sime: remember me? :o)
[04:38] <mhb> Sime: I started to work on the smbfs -> cifs port, but my samba server was down, so I couldn't test it
[04:39] <Sime> mhb: ok
[04:40] <mhb> Sime: but it seems to work now
[04:41] <Sime> mhb: network browsing inside mountconfig works and you can select a share and it gets the address right etc etc?
[04:42] <mhb> Sime: yeah
[04:42] <mhb> Sime: the browsing is the same
[04:42] <mhb> Sime: it only rewrites the output address
[04:42] <Sime> mhb: ok, good
[04:44] <mhb> Sime: I'll send you the diff
[04:44] <Sime> mhb: good<EMAIL_ADDRESS>[04:47] <Hobbsee> night all
[04:47] <mhb> Sime: btw: nobody complained before about the fact that "smbfs" was not present in Kubuntu by default, but was used in mountconfig?
[04:47] <Sime> mhb: nope,
[04:49] <danimo> does anyone know a host that deliberately still runs an echo service?
[04:50] <Riddell> I don't even know what that is
[04:50] <danimo> Riddell: port 7, echo's all input
[04:50] <danimo> Riddell: quite a paradise for DoS'es, hence usually disabled
[04:51] <danimo> Riddell: but it comes in handy sometimes
[04:55] <mhb> Sime: one moment please
[04:55] <pygi> kwwii, hey ;)
[04:55] <mhb> Sime: Kubuntu behaves weird when I insert the line through mountconfig
[04:56] <kwwii> howdy pygi
[05:00] <pygi> how is you kwwii ?
[05:00] <mhb> Sime: it's an interesting problem
[05:01] <mhb> Sime: the "cifs" filesystem doesn't accept the "user" option
[05:02] <mhb> Sime: because it uses the "user=" option as an alias to "username="
[05:02] <mhb> (at least the documentation suggests that)
[05:06] <mhb> Sime: but even "smbfs" refuses to mount directly as an user because:
[05:06] <mhb> Sime: smbmnt must be installed suid root for direct user mounts (1000,1000)
[05:08] <kwwii> pygi: really busy, unfortunately
[05:08] <kwwii> pygi: and you?
[05:08] <pygi> kwwii, eh, sorry to hear that :-/
[05:09] <pygi> kwwii, I am good, relaxing a little today
[05:09] <pygi> it was a hard week, tho some good things did happen :)
[05:09] <kwwii> hehe, lucky you :-)
[05:10] <pygi> kwwii, hehe :)
[05:13] <pygi> kwwii, http://libburn.pykix.org/wiki :)
[05:15] <kwwii> nifty...although I do not have an optical disk
[05:16] <pygi> =P
[05:16] <pygi> bon appetit
[05:16] <kwwii> thanks :-)
[05:16] <Sime> mhb: smbmnt isn't installed suid on kubuntu I'm guessing?
[05:20] <mhb> Sime: sure, that's the reason why smbfs won't mount as user
[05:20] <mhb> Sime: but cifs won't mount as well
[05:21] <Sime> mhb: cifs will work as root still?
[05:21] <mhb> Sime: yeah, no problem as root
[05:21] <mhb> Sime: or through the Enable/Disable mountconfig dialog
[05:22] <mhb> (if you use sudo, of course)
[05:22] <Sime> mhb: Does that problem only apply to cifs and smbfs? or do other mount helper programs need suid too?
[05:25] <mhb> Sime: cifs and smbfs both don't use the core "mount", but their own mount commands
[05:25] <mhb> Sime: mount.cifs and smbmount, I think
[05:25] <Sime> mhb: some other file systems use helpers too.
[05:27] <mhb> maybe so
[05:28] <mhb> Sime: I have only mount.smb and mount.cifs installed, though
[05:28] <mhb> Sime: if you can point me to the specific filesystems, I'll check them
[05:28] <mhb> Sime: name some that use helpers
[05:29] <Sime> mhb: looking on my system, that appears to be all of them.
[05:31] <Sime> a storm is coming through here right now
[05:32] <mhb> Sime: where are you?
[05:33] <Sime> Nijmegen, NL
[05:35] <mhb> Sime: I sent you the diff... if there is something wrong, let me know
[05:37] <mhb> Sime: I still need to fix the user mounting
[05:38] <Sime> mhb: thanks
[05:38] <mhb> Sime: no problem
[05:39] <Sime> mhb: the whole smbfs+cifs problem affects dapper (you're not using edgy?)
[05:40] <mhb> Sime: I have them both
[05:41] <mhb> Sime: and Firefox refused to load last week, so I was using dapper
[05:41] <mhb> Sime: I'll check it
[05:41] <mhb> Sime: I'll be right back
[05:51] <mhb> I'm back (Edgy Eft)
[05:52] <mhb> Sime: smbmnt lacks SUID in Edgy, too
[05:53] <mhb> Sime: cifs reports: mount error 1 = Operation not permitted
[05:56] <Sime> mhb: :-/ I'm not sure if it is worth trying to do something about this in the gui.
[06:00] <mhb> Sime: probably not
[06:01] <mhb> Sime: the only thing that bothers me is that when I add the line through mountconfig, the KDE media pop-up will appear
[06:02] <mhb> Sime: and when I want to display the folder, it shows an error
[06:03] <Sime> mhb: mmmmmm... you mean the "What do you want to do with this disk?" popup?
[06:03] <mhb> Sime: that one
[06:06] <mhb> Sime: when I mount it through mountconfig (that works fine), the icon on the desktop doesn't look like it should
[06:07] <mhb> Sime: and when I want to access the drive through the icon (note that it's mounted ok), Konqueror displays Could not mount device.
[06:07] <mhb> " The reported error was: "
[06:07] <mhb> and that's it
[06:13] <mhb> Sime: OK, I'll try to RT(F)M some more :o)
[06:25] <Sime> mhb: I'm just looking at your patch. The line: nmboutput = os.popen("nmblookup "+ parts[0] ,"r")
[06:25] <Sime> mhb: can you change that to:
[06:26] <Sime> mhb: nmboutput = os.popen(["nmblookup",parts[0] ] ,"r")
[06:26] <Sime> mhb: and see if it still works.
[06:26] <Sime> mhb: I'm just being paranoid about the security aspects of that line.
[06:29] <mhb> Sime: sure
[06:30] <Sime> mhb: os.popen() will go through a shell if you're not careful. (-> danger)
[06:31] <mhb> Sime: I think I understand
[06:33] <mhb> Sime: TypeError: popen() argument 1 must be string, not list
[06:34] <Sime> mhb: weird, the docs say something different. http://docs.python.org/lib/os-newstreams.html
[06:34] <mhb> Sime: I'm looking at it too
[06:34] <Sime> mhb: "Also, for each of these variants, on Unix, cmd may be a sequence..."
[06:36] <mhb> Sime: maybe it's just for the following popen2 ... variants, I dunno
[06:36] <mhb> Sime: I'll try that
[06:36] <Sime> mhb: there is also the "subprocess" module in Python 2.4. It is a lot more modern (read: sane)
[06:37] <mhb> Sime: ok
[06:38] <mhb> Sime: I tried to work with the modules that already were there
[06:39] <mhb> Sime: should I rewrite the code to use subprocess?
[06:42] <Sime> mhb: yeah that is fine.
[07:13] <mhb> Sime|pizza: done :o) but the libref was a bit confusing (I thought I need only "from subprocess import Popen", but I was wrong)
[08:14] <Sime> mhb: I'm back
[08:17] <mhb> Sime: I'll send you the version with subprocess
[08:17] <mhb> if I read the documentation correctly, it should not call /bin/sh anymore
[08:24] <mhb> Sime: sent
[08:31] <bddebian> re
[08:33] <Sime> mhb: it looks good
[08:34] <mhb> better, at least :o)
[08:35] <Sime> mhb: the only problem I can think of is that when people upgrade from dapper to edgy, mountconfig won't understand smbfs in thier /etc/fstab.
[08:35] <Sime> mhb: (I don't think that is going to be a big problem).
[08:39] <mhb> Sime: so what should I do?
[08:40] <mhb> Sime: a warning message stating that smbfs is deprecated in favor of cifs?
[08:40] <Sime> mhb: will smbfs work in edgy?
[08:47] <mhb> Sime: well, as it worked in Dapper (it is still available as an external package)
[08:51] <mhb> Sime: but cifs works even without it
[08:54] <Sime> mhb: that's ok.
[09:04] <Sime> mhb: thanks, I just commited your fix to svn!
[09:04] <mhb> Sime: that's great
[09:05] <mhb> Sime: although the pop-up "What do you want to do" worries me ...
[09:05] <mhb> Sime: I'll fix it ASAP
[09:45] <Riddell> arts should be fixed in kde 3.5.4 dapper builds now
[09:45] <Riddell> if you install libarts1-akode
[09:59] <apachelogger> Riddell: ready for 1.4.2-beta1? ;-)
[09:59] <Riddell> blah
[09:59] <Riddell> where is it?
[10:00] <apachelogger> not yet fetched
[10:00] <apachelogger> I'd just wait till you're ready ;-)
[10:00] <apachelogger> anyway, gotta start fetching in some minutes
[10:49] <omeow> Let's see if the font problem is fixed...
[10:50] <kwwii> re
[10:50] <pygi> yo kwwii :)
[10:52] <toma> hey kwwii
[10:54] <kwwii> howdy :-)
[10:54] <omeow> Hi.
[10:55] <omeow> Still the same problem. =/
[10:56] <omeow> Is there a meta package that lets me re-install everything currently installed?
[10:56] <omeow> Maybe that would fix the problem.
[11:07] <Lure> Riddell: http://linuxhelp.blogspot.com/2006/07/kubuntu-606-lts-excellent-linux.html
[11:09] <omega> Riddell, is there any way I can test the packages you patched with the xinerama improvements on dapper?
[11:09] <omega> If so, then I'll just re-install dapper tomorrow and test it on that.
[11:09] <omega> Edgy is a bit too on the edge.
[11:09] <omega> :)
[11:14] <Riddell> omega: it's only in edgy
[11:14] <Riddell> ooh, Lure's back :)
[11:15] <Lure> Riddell: yep - still recovering my mailbox after two week vacation... ;-)
[11:18] <omega> Riddell ar, that's a shame.
[11:18] <omega> Guess I'll have to stalk some people in order to get my font problem fixed.
[12:07] <kwwii> time for bed, see you all tomorrow
[12:07] <omega> Bye. :)