[00:08] <bluesabre> I think I'm going to extend the patches to support both
[00:09] <bluesabre> also, good evening everyone
[00:10] <bluesabre> whether I get to those packages tonight remains to be seen
[00:57] <bluesabre> brainwash: not that you're around, but a fixed xfce4-settings has been pushed to utopic (will land when freeze is lifted tomorrow).  I'll be working on trusty uploads this weekend.
[00:59] <bluesabre> I'll also expand the gdmflexiserver patches to first try gdmflexiserver, then dm-tool upon failure
[01:01] <Unit193> Heh, alright.  xscreensaver looked like it checked what was running/installed, but anywho I'll leave how to do it up to you, if you choose. :P
[01:01] <bluesabre> I'll figure it out... none of these things are as smart as they seem :)
[01:01] <bluesabre> though, I might ping you this weekend Unit193, if you're around ;)
[01:02] <bluesabre> anyway, gotta run again, bbl
[01:02] <Unit193> Hah, you're the programmer. :P
[01:02] <Unit193> Tschau.
[02:51] <skellat> In light of the pinkness bug, I got out there preemptively on AskUbuntu and submitted a Question + Answer combo: http://askubuntu.com/questions/528116/why-did-my-highlights-turn-pink-in-xubuntu-14-10
[03:14] <ali1234> nice
[03:18] <ali1234> can we make the installer load this in a hidden iframe also? https://www.youtube.com/watch?v=ky3Ordfqn88
[03:47] <skellat> ali1234, That is pure evil
[03:47] <ali1234> i'm still watching it
[04:18] <Unit193> 5 minutes.
[06:22] <Noskcaj> ali1234, That's worse than the 10 hour nyan cat and the 10 hour darude sandstorm
[06:28] <elfy> hi Noskcaj
[06:30] <Noskcaj> hey elfy
[08:01] <ochosi> morning folks
[09:09] <ochosi> just subscribed ubiquity to https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1365815
[09:09] <ochosi> actually xubuntu-default-settings is not the right package anyway, the wallpaper-symlink for ubiquity is generated in xubuntu-artwork
[09:10] <ochosi> but i checked, we haven't changed anything there, so the location that ubiquity tries to access here should still be fine
[09:10] <ochosi> http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/bin/ubiquity-dm#L369
[09:10] <ochosi> also briefly scanned the changelog of ubiquity, but nothing caught my eye
[09:10] <ochosi> so i hope xnox (or someone else) can shed some light on this
[09:13] <elfy> that one is a pain - it goes, it comes back, it goes ...
[09:18] <knome> hmmh
[09:18] <knome> i think i just hit the "black screen after suspend" bug the first time
[09:18] <knome> let me try if i can reproduce
[09:21] <knome> looks like TTY7 is black
[09:21] <knome> TTY1 works
[09:21] <knome> ochosi, ^
[09:27] <ochosi> knome: you're on 14.04.1 and have activated the fix?
[09:35] <knome> how do i specifically activate it?
[09:35] <knome> i've been on 14.04.1 for some time, and this is the first time i see this bug
[09:35] <knome> so i would have imagined i don't have it / have the fix activated, but...
[09:36] <ochosi> just read our blog, man
[09:36] <ochosi> http://xubuntu.org/news/laptop-users-fix-available-for-the-black-screen-on-unlock-bug/
[09:36] <ochosi> ;)
[09:36] <knome> bah, overrated!
[09:37]  * knome boots
[09:37]  * ochosi boots knome
[09:39] <ochosi> you know, the problem with this bug is that it's often just a problem with suspend
[09:40] <ochosi> as soon as you can reproduce it, you can try 1) the fix linked above and 2) to disable l-l to be sure
[09:40] <ochosi> (disabling light-locker in the sense of: disabling lock on suspend)
[09:42] <knome> ochosi, yeah, TTY7 is still blank
[09:43] <knome> but please understand, locking *with light-locker* has worked before
[09:43] <ochosi> you mean lock-on-suspend with light-locker, i presume
[09:43] <knome> yes
[09:43] <knome> that :P
[09:43] <knome> i'll try disabling light-locker next
[09:43] <knome> just a sec...
[09:44] <knome> so with light-locker disabled, what was the way to go to suspend again?
[09:45] <ochosi> just disable lock on suspend, not light-locker itself
[09:45] <knome> aha
[09:45] <ochosi> but yeah, you can suspend any way you want (close the lid, use the logout menu)
[09:45] <knome> sorry for being a bit green, it's a long time since i thought about this the last time
[09:45] <ochosi> np
[09:45] <ochosi> actually there could be a difference between closing the lid and using the logout menu, iirc
[09:45] <ochosi> only the lid created problems
[09:46] <knome> yes, i'll look into that too next
[09:46] <knome> yeah, that fixes the issue
[09:48] <knome> and yeah, even with lock on suspend enabled, suspending from the menu works
[09:48] <ochosi> yup
[09:48] <knome> now that i've pinpointed it, how can i help debug this further?
[09:48] <ochosi> it's a weird bug to begin with
[09:49] <ochosi> are you using all default packages of 14.04?
[09:49] <ochosi> or e.g. newer versions of xfpm or ll
[09:49] <knome> nope, all default
[09:49] <knome> actually...
[09:49] <knome> now that you mention it
[09:49] <knome> i just enabled the xubuntu-dev staging PPA
[09:49] <ochosi> huhu
[09:49]  * knome facepalms
[09:50] <knome> so is it a regression?
[09:50] <ochosi> not really, but the variable names for handling the lock on suspend case in xfpm has changed
[09:50] <knome> aha
[09:50] <ochosi> so older versions of lls won't work with that nicely
[09:50] <knome> aha
[09:50] <knome> so why isn't there a new version of l-l-s in the staging PPA?
[09:51] <ochosi> i wasn't all too happy with that change, since it breaks backward compatibility, but yeah, better ask bluesabre ;)
[09:51] <knome> bluesabre, PING
[09:51] <ochosi> oh let the guy get some sleep :)
[09:51] <knome> tbe, bluesabre was the one suggesting me to install the PPA for the new mousepad :P
[09:51] <knome> is there something i can manually do to make this work?
[09:52] <ochosi> well you don't have to upgrade *all* packages from that PPA
[09:52] <knome> no, but it's easiest that way
[09:52] <ochosi> you can try to downgrade to xfpm 1.2 from 14.04
[09:52] <ochosi> and then re-apply the fix as mentioned on the blog
[09:52] <ochosi> or you can try to set the right variable for xfpm
[09:52] <ochosi> sry, gotta get back to work now
[10:16] <knome> ochosi, pinned to the version in the archive, redid the fix mentioned, but suspending with lock on suspend when closing lid is still broken
[10:38] <bluesabre> :(
[10:38]  * bluesabre is not a fan of this bug
[10:38] <knome> nope
[10:39] <bluesabre> knome: want to be an experiment?
[10:40] <knome> well i obviously can/want do stuff
[10:41] <bluesabre> can you re-update to the PPA version?
[10:42] <knome> sure, a bit later
[10:43] <knome> i need to do something for a client first
[10:43] <bluesabre> the logic was flipped, and the fix worked for some, not for others...
[10:43] <bluesabre> and the bug does not affect me, so I am coding in the dark...
[10:44] <bluesabre> try each of the following, followed by a log out, and then back in. I want to know which setting actually fixes the issue
[10:44] <bluesabre> xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/logind-handle-lid-switch -s false
[10:44] <bluesabre> xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/logind-handle-lid-switch -s true
[10:45] <bluesabre> (do this after enabling light-locker and lock-on-suspend from l-l-s)
[10:45] <bluesabre> but yeah, just some time today :)
[10:46] <knome> i'll do it in ~15mins
[10:46] <bluesabre> awesome
[10:47] <bluesabre> I might have to release an updated light-locker-settings, and this would be really good to know before 14.10 is released :)
[11:10] <knome> brb
[11:10] <knome> i mean, from the laptop ->
[11:13] <bluesabre> knome: do we have screenshots of simple-scan anywhere?
[11:13] <knome> bluesabre, no, how?
[11:13] <knome> /why?
[11:13] <bluesabre> I figured out how to add minimize/maximize to headerbars
[11:13] <knome> aha
[11:14] <bluesabre> slight ui change... but much better for consistency
[11:14] <knome> umm, does xfce4-power-manager need other packages to be able to update?
[11:14] <bluesabre> -data, -plugins
[11:14] <knome> pinning it back to 500 doesn't do anything
[11:14] <knome> aha
[11:16] <knome> what :D
[11:16] <knome> only -plugins would be upgraded
[11:16] <knome> this is silly...
[11:17] <knome> right, wrong syntax from me
[11:17] <knome> ok, let's see...
[11:18] <knome> ok, first thing done
[11:18] <knome> will try to suspend now
[11:20] <knome> first thing failing
[11:20] <bluesabre> l-l-s, things enabled, property set, and logged out after setting?
[11:20] <knome> yes
[11:21] <bluesabre> k
[11:21] <knome> have done second thing now and will try to suspend
[11:21] <bluesabre> logged out first?
[11:21] <knome> yes
[11:21] <knome> the second option works
[11:21] <bluesabre> neat
[11:21] <bluesabre> and troublesome
[11:22] <knome> i remember editing some file at some point
[11:22] <knome> related to power management
[11:22] <bluesabre> ochosi ^ so, allowing logind to handle the lid switch works... is that correct?
[11:22] <knome> where's the related logind conf files?
[11:23] <bluesabre> /etc/systemd/logind.conf ?
[11:23] <knome> probably..
[11:23] <knome> it has #HandleSuspendkey=suspend
[11:24] <bluesabre> adding this fix to xfpm made overrides in that file not matter anymore
[11:24] <knome> aha
[11:24] <bluesabre> or, that was the plan
[11:24] <knome> well apparently, the problem in my case is when logind *doesn't* handle suspending
[11:25] <bluesabre> indeed
[11:25] <bluesabre> all this is confusing, and I do not know what should and should not work at this point...
[11:25] <knome> as always, if there is anything i can do to help fixing it, i'm willing :)
[11:25] <bluesabre> well, you figured out the setting that works for you
[11:25] <knome> not just because i want my laptop's suspend to work...
[11:25] <bluesabre> so that might be a start
[11:26] <bluesabre> :)
[11:26] <knome> i should clean my monitor
[11:35] <bluesabre> knome: https://bugs.launchpad.net/ubuntu/+source/xubuntu-default-settings/+bug/1373887
[11:35] <ochosi> bluesabre: yes, logind has to handle the lid switch
[11:35] <bluesabre> ah
[11:35] <bluesabre> good to know
[11:36] <bluesabre> new l-l-s coming today ;)
[11:36] <ochosi> but only if lock-on-suspend is enabled ;)
[11:36] <bluesabre> right
[11:36] <ochosi> but yeah, we've had that before
[11:36] <bluesabre> where it was flipped, it was confusing
[11:36] <ochosi> yeah, i never felt flipping was a really good idea
[11:36] <bluesabre> well, it was a lot of reverse-logic before
[11:36] <ochosi> made a confusing issue even more confusing ("are you using the version before or after the flipping..?")
[11:37] <bluesabre> the setting actually makes sense now
[11:37] <ochosi> right, maybe we should just write things down somewhere
[11:37] <bluesabre> logind-handle-lid-switch now means "logind handle lid switch"
[11:37] <bluesabre> :D
[11:38] <bluesabre> knome: thanks for testing :)
[11:38] <knome> np
[11:38] <knome> i understand that it's always so much easier to do that with somebody who you know, and who understands something about xubuntu
[11:38] <knome> which is why i'm more than willing to help
[11:39] <ochosi> do we need another +1 for the UIFe?
[11:39] <bluesabre> ochosi: if you want
[11:39] <bluesabre> I just subscribed ubuntu-release, so it will make it pop up in their queue
[11:40] <knome> ochosi, what about the flash of content before unlocking?
[11:40] <ochosi> cool
[11:40] <bluesabre> I'll ping them tonight after the freeze is lifted
[11:40] <knome> i proposed ochosi a hacky solution, which should work, however..
[11:40] <ochosi> knome: nothing we can do about that. same thing happens with xscreensaver potentially. it's related to locking after waking up
[11:40] <knome> sure, but what about my idea about the timeout?
[11:41] <ochosi> what if for some reason that process of suspending gets "stuck"?
[11:41] <ochosi> then you end up with a black screen
[11:41] <ochosi> there are just too many pitfalls with this approach imo
[11:41] <knome> the timeout should take care of that as well
[11:41] <knome> because when it times out, it unblanks the screen
[11:42] <ochosi> iirc your idea was to black out the screen when locking (with a black top-level window), then do suspend and on wakeup lock the screen
[11:42] <bluesabre> gotta run, bbl
[11:42] <knome> yes, something like that
[11:42] <ochosi> ttyl bluesabre, hf!
[11:43] <knome> ta bluesabre
[11:43] <knome> and hf
[11:43] <ochosi> the only real solution is to find out why suspending after the vt switch doesn't work properly
[11:44] <knome> i'm not disagreeing with that :)
[11:44] <knome> but how far from that are we really?
[11:44] <ochosi> and it's probably not that much more work than trying to implement your hack :)
[11:44] <knome> and is it possibly a hardware issue?
[11:44] <knome> well then get hacking on your solution then! :P
[11:44] <ochosi> that depends, if i or someone else would actually have time to spend on it, then maybe we wouldn't be too far away
[11:45] <ochosi> but i don't have time atm
[11:45] <knome> i understand there is no exact timeframe to give
[11:45] <knome> but i was thinking about an estimation
[11:45] <knome> is this affecting ubuntu as well?
[11:45] <ochosi> ubuntu doesn't switch vt when locking
[11:45] <knome> ok, so why do we do that?
[11:45] <ochosi> gah, sorry, i really don't have time for this right now
[11:45] <ochosi> -> back to work
[11:46] <knome> that's okay :P
[11:46] <brainwash> that's a funny question :)
[11:46] <knome> ttyl
[11:46] <knome> brainwash, i don't think it's funny. what in it do you think is funny?
[11:46] <brainwash> light-locker requires lightdm + greeter to lock the screen
[11:47] <brainwash> which starts in a new vt
[11:48] <brainwash> light-locker 2.0 will hopefully get rid of the vt switching, but we don't know when it will be ready :(
[11:52] <brainwash> do gtk3 apps hide the normal title bar now? if no, what is the benefit of adding minimize/maximize to gtkheaderbars?
[11:55] <brainwash> maybe I'm not up-to-date
[11:56] <brainwash> bug 1301873 is still open
[12:14] <knome> bbl. ->
[12:53] <bluesabre> brainwash: if you're running utopic, open simple-scan
[12:53] <bluesabre> CSDs work correctly in xfce now
[12:53] <bluesabre> gotta run
[12:54] <brainwash> how does it work correctly? who fixed that?
[12:55] <bluesabre> its part of gtk 3.10 or 3.12
[12:55] <bluesabre> fixed in the toolkit
[12:55] <brainwash> good news I guess
[17:05] <elfy> ochosi: http://pad.ubuntu.com/b2notes
[17:05] <elfy> bbl
[17:11] <ochosi> elfy: thanks, fixed some small typos, but the rest looks good! nice work
[17:13]  * bluesabre added a space
[17:15]  * knome removed bluesabre's space
[17:16]  * bluesabre adds more spaces, html doesn't care
[17:16] <knome> waat
[17:16] <knome> you make me sad
[17:17]  * bluesabre fixes mistake in judgment
[17:21] <knome> boo for pad adding spaces :(
[17:24] <bluesabre> for vbox, its host+F1 (usually right-ctrl + F1)
[17:24] <elfy> thanks bluesabre - saved me time :p
[17:25] <knome> bluesabre, righty
[17:25] <bluesabre> ;)
[17:25] <elfy> not sure about other vm's though - hence not putting anything there
[17:26]  * knome shrugs :)
[17:28] <knome> moved striked stuff at the bottom
[17:33] <elfy> looks better like that :p
[18:12] <elfy> ochosi: so what we going to do about marking these images
[18:13] <elfy> others are marking ready regardless
[18:16] <bluesabre> we should probably just mark ready... everyone else has the same issue, and I think the decision is to release now and fix lightdm after
[18:17] <elfy> was my thinking
[18:18] <bluesabre> great minds...
[18:18] <bluesabre> :)
[18:18] <elfy> I've asked the question, though <jibel> there is progress on the 'boot to black screen' issue but it wont be fixed for beta2 in another channel confirmed that thinking
[18:19] <elfy> other than things we can't fix I'm happy
[18:19] <elfy> a bit happier with the testing turnout
[18:20] <elfy> can't say I'm impressed though
[18:24] <bluesabre> :)
[18:24] <bluesabre> its an improvement, but we can do better
 elfy: Yeah, we're going to ignore that issue and fix it ASAP after the beta.
[18:29] <elfy> I'll mark them now
[18:29] <elfy> done
[18:31] <elfy> draft blog post done from the pad
[18:34] <knome> elfy, ta :)
[18:34] <knome> elfy, please mention that in the pad
[18:34] <elfy> mention what in the pad? that I'm not impressed
[18:35] <elfy> done :)
[18:36] <knome> tara ;)
[18:42] <Unit193> bluesabre: Updates got me a scroll up button, next to minimize.
[18:43] <bluesabre> Unit193..? screenshot
[18:43] <elfy> we got a screenshot button too :(
[18:43] <elfy> oh dear
[18:45] <Unit193> bluesabre: https://unit193.net/buttons.png
[18:45] <bluesabre> bizarre
[18:46] <elfy> I'm not seeing that - but I've customised that stuff
[18:46] <bluesabre> which wm theme?
[18:46] <Unit193> Numix
[18:54] <bluesabre> not seeing that even in the guest session...
[18:55] <Unit193> Well that's weird, nothing changed here...  Well it's not important.
[18:55] <bluesabre> does it affect your guest session or a new user? just making sure I didn't break anything
[18:57] <Unit193> Bah, have to restart lightdm...
[19:01] <Unit193> Okay, so no idea how that hit then..
[19:02] <bluesabre> lol
[19:02] <bluesabre> ochosi put an easter egg in xfwm
[19:02] <Unit193> Guess so.
[19:03] <Unit193> Also, guest session kind of stinks. :P
[20:08] <elfy> I wonder if we should put a disclaimer of some sort on the b2 post - "We don't like marking this as ready for use given the VM bug"
[20:08] <knome> well, i don't know
[20:08] <knome> tbh, the virtual installations are not *so* important
[20:08] <knome> they don't blow up anybody's computer
[20:08] <knome> and it's relatively easy to rerun an installation with another image
[20:08] <elfy> whole thing is meh
[20:09] <knome> yes, it is, but i don't think it is too critical to not call them beta-stage-ready
[20:24] <elfy> oh ...
[20:24] <elfy> why would I ever think that I could work with the wiki without pulling my hair out
[20:25] <Unit193> Drunk?
[20:26] <knome> elfy, no hair left?
[20:26] <Unit193> Chest hair...
[20:26] <elfy> knome: indeed
[20:26] <elfy> anyway - beta2 notes done - https://wiki.ubuntu.com/UtopicUnicorn/Beta2/Xubuntu
[20:26] <knome> thanks!
[20:29] <elfy> includes is all up the swanee though
[20:29] <knome> want me to look at it?
[20:29] <elfy> hang on
[20:30] <knome> sure...
[20:30] <elfy> fixed it
[20:30] <knome> :)
[20:30] <elfy> though it's a bit useless :D
[20:30] <knome> as alwyas
[20:30] <knome> always too
[20:30] <elfy> even more so this time - it's empty :p
[20:30] <knome> hah
[20:31] <knome> hmph
[20:33] <elfy> changed our link on the main release notes
[20:34] <elfy> what's the hmph for knome - the emptiness or something else
[20:35] <knome> i continued the thing in the right channel, -offtopic :)
[20:35] <elfy> aah
[21:06]  * bluesabre gets to packaging xfpm 1.4.1
[21:09] <elfy> well I'm off now
[21:09] <bluesabre> seeya elfy, have a good night
[21:09] <slickymaster> nighty elfy
[21:09] <elfy> I'll do my best bluesabre :)
[21:10] <elfy> wiki and blog are both done bluesabre just in case anyone in -release needs anything
[21:10] <bluesabre> ok, good to know
[21:10] <elfy> -release only have ochosi and me as contacts
[21:16] <bluesabre> Unit193: poke
[21:17] <Noskcaj> bluesabre, Are you going to try and merge from debian for the new xfpm? Corsac has packaged it
[21:18] <bluesabre> Noskcaj: not sure if its worth it.  We have several differences with debian and nothing extra has diverged since 1.4.0
[21:18] <Noskcaj> ok
[21:18] <Noskcaj> i'll try and get all the deltas smaller next cycle anyway
[21:18] <bluesabre> thanks for the tip though :)
[21:21] <bluesabre> Unit193: nvm, figured out it
[21:21] <bluesabre>  /unping
[21:26] <Unit193> bluesabre: Too bad, pooong. :D
[21:29] <bluesabre> :D
[21:31] <dreambit> o
[22:32] <bluesabre> knome: new light-locker-settings pushed to utopic, and staging ppa for trusty
[22:33] <knome> aha
[22:33] <knome> how does that help?
[22:33] <knome> i mean... what's the change too
[22:33] <bluesabre> when you say lock, it sets the right setting for xfpm to not black screen
[22:34] <knome> aha
[22:34] <knome> but isn't that something you switched?
[22:34] <knome> and the other thing doesn't work for others?
[22:34] <Unit193> http://launchpadlibrarian.net/185784036/light-locker-settings_1.4.1-0ubuntu1_1.4.2-0ubuntu1.diff.gz
[22:34] <bluesabre> xfpm < 1.3.2 uses old light-locker-settings, xfpm > 1.4.0 uses the new
[22:34] <knome> okay
[22:35] <bluesabre> just poked you because you had an issue with that earlier :)
[22:35] <knome> yep


[18:42] <dax> !amdgpu is <alias> amd
[18:42] <dax> !no, radeon is <alias> amd
[18:42] <dax> !no, radeon is <alias> amd
[18:42] <dax> !-radeon
[18:43] <genii> heh
[18:43] <dax> whatever, it can stay that way then
[18:43] <dax> (ati is an alias to amd)


[07:24] <qbsd> running kubuntu 17.04 here with virtualbox 5.1.22 installed, as well as the extension pack. usb pass through is horribly broken. I can remember in the past when it did work. anyone know anytrhing about this?
[07:49] <qbsd> and, of course, updating to 5.1.26 via locutusofborg ppa makes no difference...   doesn't anyone test any of this anymore?  Way to go Oracle!
[07:49] <tsimonq2> qbsd: Why don't you use virt-manager? It's way better.
[07:50] <qbsd> guess it's time to look for another virtualization solution, this just ain't gonna cut it...
[07:50] <tsimonq2> I've had loads of problems with Virtualbox.
[07:50] <tsimonq2> VirtualBox, rather.
[07:50] <qbsd> gonna have to try something as it looks like this just isn't going to get fixed
[07:51] <qbsd> it used to work, about a year ago
[07:51] <tsimonq2> qbsd: What do you expect, it's Oracle :)
[07:51] <qbsd> been going downhill ever since
[07:53] <qbsd> guess I'm going to have to learn kvm, back a long time ago xen had kvm beat performance-wise by a long shot but I've heard kvm caught up
[07:54] <tsimonq2> Like I said, virt-manager is awesome :)
[08:01] <ahoneybun> ahh 4am
[08:04] <acheronuk> I only see one usb related bug at present: https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bugs?field.searchtext=usb
[08:05] <acheronuk> if that one is your issue, please add to it. if not, please report a new one
[08:05]  * acheronuk has not had any trouble like that with vbox when I was using 17.04
[08:07] <qbsd> I used to be able to pass through a usb wifi rtl8187 and use it in guest machines, did it all the time. haven't done since before I installed 17.04 - it used to work fine; it does not now
[08:07] <qbsd> never tried running vbox as root though
[08:08] <qbsd> might try that to see if it might better match the #1576768 PR
[08:13] <qbsd> I did see an error in the vbox logs that was fixed by changing the udev rules to alter permissions in /dev, but no affect on the usb problem
[08:13] <qbsd> didn't mess with the script that sets up the usb nodes yet
[08:14] <qbsd> when I first saw that I thought "ugly kludge hack"
[08:16] <qbsd> oh well, enough of this nonsense for one night. time to leave it alone for a while
[08:45] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » linode-01 build #1676: SUCCESS in 52 sec: https://kci.pangea.pub/job/mgmt_docker/label=linode-01/1676/
[08:46] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » master build #1676: SUCCESS in 59 sec: https://kci.pangea.pub/job/mgmt_docker/label=master/1676/
[08:48] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-01 build #1676: SUCCESS in 3 min 51 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-01/1676/
[08:49] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-02 build #1676: SUCCESS in 4 min 18 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-02/1676/
[09:06] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kwayland build #67: FAILURE in 56 sec: https://kci.pangea.pub/job/artful_unstable_kwayland/67/
[09:12] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kwayland build #68: STILL FAILING in 33 sec: https://kci.pangea.pub/job/artful_unstable_kwayland/68/
[09:23] <BluesKaj> Hiyas all
[10:44] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[10:44] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kwayland build #69: FIXED in 1 hr 31 min: https://kci.pangea.pub/job/artful_unstable_kwayland/69/
[11:12] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[11:12] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kmail build #106: FIXED in 27 min: https://kci.pangea.pub/job/artful_unstable_kmail/106/
[11:23] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[11:23] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kmail build #61: FIXED in 38 min: https://kci.pangea.pub/job/artful_stable_kmail/61/
[11:37] <acheronuk> please test: https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging-misc/+packages?field.name_filter=kaffeine
[13:48] <clivejo> acheronuk: do you know what that Franklin guy is talking about on -devel ML?
[13:48] <clivejo> I used artful (17.10) alpha and the XDG_MENU_PREFIX problem is still there. ?
[14:09] <mparillo> acheronuk: kaffeine installed cleanly from the PPA to a clean AA VM from today's ISO. It launched like the picture, but do you have a good url / test file to test running it?
[14:14] <clivejo> is vlc now on our iso ?
[14:16] <mparillo> clivejo: Yes,
[14:17] <mparillo> I just installed today's ISO maybe three hours ago.
[14:17] <clivejo> :)
[14:20] <mparillo> It is a "Media player" whilst kaffeine is a  "Media Player"
[14:20] <clivejo> LOL
[14:20] <clivejo> a big player
[14:22] <mparillo> I suppose those come from Appstream data?
[14:25] <clivejo> probably the desktop file
[14:29] <clivejo> try editing /usr/share/applications/org.kde.kaffeine.desktop and change the generic name to player
[14:36] <mparillo> Thanks. It works. I needed sudo, but I did not need to re-start KDE.
[14:37] <mparillo> s/KDE/Plasma/
[14:37] <clivejo> dunno which version is correct
[14:37] <clivejo> I prefer Player myself
[14:37] <mparillo> Dolphin is File Manager. FF is Web Browser
[14:45] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » linode-01 build #1677: SUCCESS in 54 sec: https://kci.pangea.pub/job/mgmt_docker/label=linode-01/1677/
[14:45] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » master build #1677: SUCCESS in 59 sec: https://kci.pangea.pub/job/mgmt_docker/label=master/1677/
[14:48] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-01 build #1677: SUCCESS in 3 min 44 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-01/1677/
[14:49] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-02 build #1677: SUCCESS in 4 min 10 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-02/1677/
[15:44] <acheronuk> mparillo: I just tried on random ones on my hd etc
[15:44] <acheronuk> seems good anyway, going by bug #1707489
[17:15] <acheronuk> any more people tested ktorrent from https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging-misc/+packages?field.name_filter=ktorrent
[17:15] <acheronuk> despite being a git snapshot, that seems pretty good here
[17:16]  * acheronuk pokes weegie
[17:16] <acheronuk> :( still dead
 Do you use harulds release script to combine translations?
 releaseme? yup
 Could that be included in our tooling?
 not sure.
[19:39] <clivejo> anyone know who Chowdhury Masum (saydulk) is?
[19:41] <acheronuk> nope
[19:41] <tsimonq2> nope
[19:41] <clivejo> badge collector?
[19:42] <acheronuk> https://launchpad.net/~saydulk
[19:47] <acheronuk> plausible, though has joined 10 teams today. if he really wants to yellow belt, he'd need to come on here and get involved
[23:07] -kubuntu-ci:#kubuntu-devel- Project mgmt_merger build #918: SUCCESS in 7 min 19 sec: https://kci.pangea.pub/job/mgmt_merger/918/
[23:22] -kubuntu-ci:#kubuntu-devel- Project xenial_stable_kgoldrunner build #18: STILL FAILING in 13 min: https://kci.pangea.pub/job/xenial_stable_kgoldrunner/18/
[23:22] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kdev-python build #134: STILL FAILING in 14 min: https://kci.pangea.pub/job/xenial_unstable_kdev-python/134/
[23:25] -kubuntu-ci:#kubuntu-devel- Project zesty_stable_kalzium build #27: STILL UNSTABLE in 17 min: https://kci.pangea.pub/job/zesty_stable_kalzium/27/
[23:27] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_ksmtp build #6: STILL UNSTABLE in 19 min: https://kci.pangea.pub/job/zesty_unstable_ksmtp/6/
[23:40] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_kstars build #285: STILL UNSTABLE in 32 min: https://kci.pangea.pub/job/zesty_unstable_kstars/285/


[00:56] <bodhi_zazen> doctormo: I took a look at your video, looked good
[00:56] <bodhi_zazen> I like your idea
[01:02] <doctormo> bodhi_zazen: At least it'll kick off content creation some more
[05:14] <MRBANX> hello helpers and fellow noobs (if any like me :o )
[05:15] <MRBANX> anyone home?
[05:17] <MRBANX> looking for some Radeon 9000  low resolution mode problems
[20:52] <doctormo> pleia2, cproffit, Vantrax, greg-g, bodi-zazen: http://divajutta.com/doctormo/learning/command-line/ <- I now have pdfs of all the materials required to teach the command line basics class. Everything is draft obviously.


[07:38] <Kamion> on an existing Ubuntu system, 'debootstrap hoary /path/to/new/hoary/chroot'
[07:38] <T-Bone> Kamion: good point, but i'd rather be able to tell at the end "installation worked fine from A to Z"
[07:38] <T-Bone> debootstrap doesn't handle system configuration as d-i does
[07:38] <Kamion> T-Bone: you can do that later - if it's just dependency fixups and things it is much more efficient to use debootstrap during development
[07:38] <T-Bone> Kamion: besides, it needs an existing ubuntu system, which i don't have yet, given i've ripped my box to test ubuntu ;)
[07:39] <Kamion> you don't have to do an install from scratch every time, and if you're working effectively you shouldn't
[07:39] <T-Bone> Kamion: agreed
[07:39] <Kamion> do you have an existing Debian system?
[07:39] <T-Bone> Kamion: doh! Dude, don't be so harsh on me :^)
[07:39] <Kamion> I'm not, just trying to help you avoid the stuff I wasted time on :-)
[07:39] <Kamion> I used to burn CDs for every test ... *shudder*
[07:39] <T-Bone> Kamion: i have an existing system on the zx6000 which heats alot and sucks lot of current. I'll try to setup a Debian system on the zx2000 instead :)
[07:40] <T-Bone> Kamion: lol
[07:40] <Kamion> ok, you can install Ubuntu's debootstrap.deb on a Debian system harmlessly
[07:40] <Mithrandir> Kamion: I used to make floppies
[07:40] <Kamion> (make sure to pick the hoary version)
[07:40] <Kamion> Mithrandir: at least they're relatively quick to write ...
[07:40] <mdz> Kamion: is there a package we could tuck (a fixed version of) update-cd into?
[07:40] <Kamion> mdz: update-cd?
[07:41] <mdz> Kamion: that little script I wrote to fix up the checksums and such on the CD after modifying it
[07:41] <Kamion> oh, there's a script in debian-cd called update-cd too, heh
[07:41] <mdz> yeah, noticed that the other day
[07:41] <Kamion> can't think of one offhand ...
[07:41] <T-Bone> Kamion: for the install archive, i can use stuff on the ISO as the repo served by apache?
[07:42] <Kamion> T-Bone: not quite, I don't think everything that netboot needs is there
[07:42] <Kamion> (there's a bug about that - we remove the netboot stuff to save space)
[07:42] <Kamion> you can try though, I've never tested that on ia64
[07:42] <T-Bone> s/ko/kB/, for you english speakers ;)
[07:43] <T-Bone> Kamion: but if i complete with the tarball you pointed me at?
[07:43] <mdz> Kamion: when I was doing busybox init test cycles, I set up a grub entry on my laptop to boot an initrd from disk, and used that with the CD-ROM
[07:43] <mdz> so I could quickly modify the initrd and test, without writing a new CD
[07:43] <Kamion> T-Bone: it'll be extra udebs you need, not stuff from that tarball
[07:43] <mdz> even better would have been a grub stanza to netboot, but for some reason the grub package doesn't have networking enabled
[07:43] <Kamion> mdz: yes, that's what I do on powerpc often
[07:43] <T-Bone> Kamion: k. Any easy way to fetch these?
[07:44] <mdz> Kamion: do you know if there's any reason why networking isn't enabled in grub?
[07:44] <Kamion> T-Bone: try first to see if it works
[07:44] <Kamion> T-Bone: otherwise debmirror
[07:44] <Kamion> unfortunately our netboot sucks, it always goes to archive.ubuntu.com unless you fiddle about in expert mode
[07:45] <T-Bone> debmirror? *G*, I hope i don't have to mirror everything, i'll have disk space issues otherwise :P
[07:45] <Kamion> mdz: no ... I didn't know it had networking support
[07:45] <Kamion> T-Bone: main/debian-installer is not a large component, you don't need to re-mirror all the debs, just grab a few more udebs
[07:45] <mdz> Kamion: it's way cool, you can say things like kernel (nd)/vmlinuz; initrd (nd)/initrd.img and it will load them via tftp
[07:46] <T-Bone> Kamion: ok
[07:46] <Kamion> oh, tftp, right
[07:46] <Kamion> I don't know, maybe size issues or something?
[07:46] <mdz> I guess it would make stage2 bigger, but stage2 isn't small anyway
[07:48] <ogra> is stuart bishop around by chance ?
[07:55] <Kamion> ogra: he's 'stub', not on channel
[07:56] <ogra> Kamion: thanks....
[07:56] <dholbach> has anybody problems with evolution on AMD64? to be precise: "floating point exception"
[07:56] <ogra> nope
[07:56] <ogra> i got lots ofg others here, but evo is fine for me
[07:56] <dholbach> ogra you have the newest available?
[07:57] <ogra> oh, 35 updates....
[07:58] <ogra> since it works for me and there are only libs to update for evo, i would suspect one of these
[07:59] <dholbach> i had a floating point exception for gnome-launch-box (which depends on e-d-s too) the other day
[07:59] <ogra> i still have that one
[08:00] <dholbach> ogra: hm?
[08:00] <ogra> gnome-launch-box
[08:00] <ogra> floatingpoint error.....
[08:00] <dholbach> well, there was only one release yet
[08:00] <Nafallo> I got no answer in #ubuntu, so this question might be better asked here :-).
[08:01] <Nafallo> can someone explain why fluxbox is missing menuitems?
[08:01] <ogra> dholbach: did you have any strange keyboard behavior or broken encoding recently ?
[08:01] <dholbach> ogra: the imendio guys said it worked nice on their amd64, they reckon it's because of gcc3.3 *shrug*
[08:01] <dholbach> ogra: strange encodings: not more than in the last months
[08:01] <dholbach> ogra: strange encodings: not more than in the last months already
[08:01] <ogra> killall metacity ==
[08:02] <ogra> it suddenly appeared out of the blue ....
[08:02] <dholbach> ogra: metacity in 2.9.5-0ubuntu1 behaved quite strange... 2.9.8-0ubuntu1 fixed it
[08:03] <ogra> i mean the encoding, not the command :-P
[08:03] <lamont> pitti: you around?
[08:03] <ogra> the right part is what i see.... the left what i type...
[08:03] <pitti> lamont: yep
[08:04] <dholbach> ogra: metacity seems to save itself from being wiped out :-p
[08:04] <dholbach> ogra: sorry... don't know what could cause this at all
[08:05] <ogra> dholbach: i suspect either xkb or the kernel, since i also have some weird key repetition probs
[08:06] <dholbach> ogra: we seem to be the only ones having bugged computers :-)
[08:07] <ogra> maybe the arch.....
[08:07] <ogra> YOUR DOG ??
[08:07] <mdz> ogra: sounds like meta was stuck on?
[08:08] <dholbach> ogra: :-)
[08:08] <Nafallo> ogra: I have got no problems except that metacitybug some day ago :-P.
[08:08] <ogra> mdz: i wouldnt know how to switch it on or of
[08:09] <ogra> mdz: i.e. meta has no lock function on my keyboard afaik
[08:09] <ogra> Nafallo: amd64 ?
[08:09] <Nafallo> ogra: indeed
[08:10] <ogra> and i really start to suspect xorg....
[08:10] <Nafallo> ogra: I haven't got any :-P
[08:12] <ogra> lspci also shows a whole lot of unknown devices.... probably this machine is simply to new...
[08:12] <ogra> (2 weeks old)
[08:13] <ogra> mdz: btw, is there a chance to get the new nediswrapper into amd64 for hoary ?
[08:13] <thom> it's in, isn't it?
[08:13] <ogra> oh, already ?
[08:14] <ogra> wow, thom is right
[08:15] <mdz> what is the point?  there's no ndiswrapper kernel module for amd64
[08:15] <ogra> /lib/modules/2.6.10-2-amd64-k8/misc/ndiswrapper.ko
[08:15] <ogra> :-D
[08:15] <mdz> from which package?
[08:15] <thom> mdz: lrm
[08:15] <thom> daniel added it last week iirc
[08:16] <mdz> thom: weird, why?
[08:16] <mdz> on i386, it's built by linux-source
[08:16] <ogra> ndiswrapper-modules-2.6.10-2-amd64-k8: /lib/modules/2.6.10-2-amd64-k8/misc/ndiswrapper.ko
[08:16] <ogra> hmm
[08:16] <mdz> ndiswrapper-modules? that's something you built yourself
[08:16] <ogra> looking
[08:17] <ogra> argh, yes
[08:17] <mdz> my word
[08:17] <mdz> lrm is bigger than the kernel
[08:17] <thom> hrm, i thought i saw it go past in the changelogs
[08:17] <mdz> mizar:[/tmp]  apt-cache showsrc linux-source-2.6.10 linux-restricted-modules-2.6.10 | grep orig
[08:17] <mdz>  063a64fc0efd9c9901cf07effef1b747 46244465 linux-source-2.6.10_2.6.10.orig.tar.gz
[08:17] <mdz>  71eda5caf8a927676e3ee573e2b0801e 46930820 linux-restricted-modules-2.6.10_<IP_ADDRESS>.orig.tar.gz
[08:18] <thom> yeesh
[08:18] <Kamion> nvidia rpms IIRC
[08:18] <ogra> isdn....avm drivers ?
[08:19] <Kamion> anaconda is giving me flashbacks to boot-floppies
[08:21] <azeem> the source?
[08:31] <Kamion> azeem: yes
[08:31] <azeem> I thought it was mostly in python?
[08:32] <Kamion> the early stuff is in C
[08:33] <Kamion> and is really horrible
[08:35] <wasabi> Is there a push for getting Mono in main?
[08:35] <thom> not for hoary
[08:36] <wasabi> k
[08:36] <thom> it's been in and been removed again
[08:36] <mdz> there's nothing which provides motivation for enduring the pain that is mono
[08:36] <wasabi> Beagle.
[08:37] <wasabi> Basically what Im fighting now.
[08:37] <Kamion> not in hoary
[08:37] <wasabi> Missing dbus-cil
[08:37] <wasabi> Yeah.
[08:37] <Kamion> beagle will likely be the motivation for hoary+1
[08:41] <whiprush> there's a link to sid .debs for dbus-cil in bugs.d.o
[08:47] <dholbach> maybe fate is giving a broad hint... evolution, streamtuner and mozilla-thunderbird don't work, maybe i'd better get working again :-)
[08:47] <Mithrandir> dholbach: how have you broken m-t?
[08:48] <ogra> Mithrandir: he installed it
[08:48] <dholbach> Mithrandir: just installed it (and the proposed plugins), then i selected "don't import anything" (since there was no alternative)) and it mysteriously broke off, then i started it again from the console and saw it tried to "Registering Enigmail account manager extension." over and over again
[08:49] <Mithrandir> dholbach: uhm
[08:49] <Mithrandir> dholbach: $arch?
[08:49] <dholbach> amd64
[08:49] <dholbach>  ***** Registering: Clean Compreg! ****    -      Registering Enigmail account manager extension.    -     Enigmail account manager extension registered.     -       observe:      -     nothing here: null      -      observe called       -      FILE: [xpconnect wrapped nsIFile] *** loading the extensions datasource
[08:50] <dholbach> over and over again :-)
[08:51] <Mithrandir> dholbach: weird, worksforme
[08:53] <ogra> Mithrandir: did you see some weird key repitition probs on amd64 in X or the encoding switching out of the blue ?
[08:56] <thom> wasabi: dbus-mono is in universe i believe
[08:56] <thom> providing libdbus-cil
[08:56] <wasabi> gmmmm
[08:56] <wasabi> I thought apt-get install was supposed to find provides
[08:57] <wasabi> nope, not in universe
[08:58] <Mithrandir> ogra: I ran it through ssh, so no
[08:58] <ogra> hmm...
[08:58] <ogra> k
[08:59] <mdz> pitti: here?
[09:00] <pitti> mdz: yes
[09:00] <dholbach> Mithrandir: here's what it says in the end: DOUBLE-CLICK: 400 --> -1 THRESHOLD: 8 --> -1 Fontconfig error: Cannot load default config file
[09:00] <dholbach> /usr/lib/mozilla-thunderbird/run-mozilla.sh: line 159: 20852 Segmentation fault  "$prog" ${1+"$@"}
[09:00] <mdz> pitti: I was just thinking that we may have a problem with the language pack / -update arrangement
[09:00] <Mithrandir> dholbach: so it's probably related to some fontconfig problems you have
[09:01] <mdz> pitti: I think we will run into the dpkg bug where it doesn't handle replaces properly if the unpack order is different
[09:01] <mdz> since we are not removing the files from the replaced package
[09:01] <dholbach> Mithrandir: there are none i'm aware of... hmmmm
[09:01] <pitti> mdz: why should we remove them? they are just replaced by newer versions
[09:02] <mdz> pitti: we shouldn't remove them
[09:02] <mdz> pitti: I am saying that we will encounter this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=164595
[09:02] <mdz> pitti: and probably we need to fix that bug before language packs can be considered releasable
[09:03] <pitti> mdz: hm, thanks for the pointer
[09:03] <pitti> mdz: I try to reproduce it
[09:03] <mdz> pitti: perhaps talk to Keybuk about it when he returns
[09:04] <pitti> yes, will do
[09:04] <Kamion> fixing that bug would be a Really Good Thing anyway
[09:05] <dholbach> Mithrandir: /usr/lib/mozilla-thunderburd/run-mozilla.sh says: MOZ_PROGRAM=""  which seems to be the problem
[09:05] <Kamion> I wonder if anyone's reviewed the patch in #184635
[09:06] <pitti> mdz: ah, now I understand
[09:06] <pitti> mdz: that means if I install an update pack the second time, I will get errors because the replaced files are not owned any more by the base package?
[09:07] <mdz> pitti: if you unpack a new language-pack and language-pack-update, and language-pack-update is unpacked first, it will fail
[09:07] <mdz> (assuming language-pack-update replaces some files)
[09:08] <pitti> mdz: hmm, the update package should always be unpacked first, because the base package conflicts to older versions
[09:09] <Mithrandir> dholbach: same here, no problem
[09:12] <Kamion> night all
[09:12] <pitti> Night Kamion!
[09:13] <ogra> night
[09:14] <pitti> mdz: okay, I can reproduce the problem
[09:24] <amu> mdz: bug confirmed, it's very strange, reportbug say all time, bug report will be send to ubuntu, it goes finally to debian
[09:26] <dholbach> amu: my reportbug tells me it'd be sent to debian (at least for universe stuff)
[09:27] <amu> dholbach: warty or hoary?
[09:27] <mdz> amu: as I said in the bug, all of the patches are in merge-o-matic
[09:28] <mdz> amu: you just need to apply the diff which was already there
[09:28] <tritium> from now on I'll stick to attaching patches rather than pasting in bugzilla.  The newlines only confuse.
[09:28] <mdz> amu: did you do that already?
[09:28] <dholbach> amu: hoary
[09:31] <amu> mdz: patching it, isnt the problem, i try to understand why the problem comes, since i merged the package.
[09:32] <amu> dholbach: hmm on my hoary it says: Will send report to Ubuntu (per lsb_release)
[09:32] <mdz> amu: the old version contained a patch which set the default bts to 'ubuntu'
[09:32] <mdz> amu: you dropped that patch
[09:33] <amu> mdz: i set the default to ubuntu, it still sends to debian
[09:34] <amu> mdz: ok, as i understood it's urgend, so i'll just apply the patches and recheck it
[09:35] <mdz> amu: I don't know what you tried, but setting 'bts ubuntu' in reportbug.conf (i.e., restoring the dropped patch) does exactly what I expect (reports the bug to Ubuntu)
[09:35] <mdz> I just tested it to be sure
[09:38] <mdz> amu: I also tried it without that, using the autodetection, and that works too
[09:38] <mdz> amu: but ubuntu should be the default as a safeguard
[09:38] <ogra> while you are at it.... is there any chance that we can collect the OTU bugs anywhere else (additional) then the mailing list....?
[09:38] <mdz> because clearly there are some cases where it does not work correctly
[09:38] <ogra> MOTU even
[09:38] <mdz> ogra: that is up to you and haggai to decide
[09:39] <ogra> ok...great :)
[09:39] <amu> mdz: ok, testing it now
[09:41] <Nafallo> ogra: stealing malone, are you? ;-)
[09:41] <mdz> ogra: I talked to haggai and bradb about malone
[09:41] <mdz> ogra: you can review with them, but it seems that the consensus is that malone is not ready
[09:41] <ogra> is malone ready yet ?
[09:41] <mdz> ogra: so you must decide whether you can wait, or if you need something immediately
[09:41] <ogra> thats what i thought
[09:43] <ogra> it would be essential to have _something_ to stabilize for hoary at least and the mailing list is a pita to search all the bugreports in 19245 mails i got in there currently...
[09:44] <ogra> is it likely that malone gets stable enough before hoary preview ?
[09:44] <ogra> bradb ? ^^
[09:45] <bradb> ogra: We (kiko, mpt and I) intend to have something usable for distro by mid next-week.
[09:45] <bradb> They're on their way to Montreal as we speak.
[09:45] <ogra> hmm, sounds enough to me....
[09:46] <ogra> bradb so lets talk then again....
[09:46] <bradb> ogra: sure, sounds good
[09:48] <sivang> ogra: we should get gazpacho in universe also...
[09:48] <sivang> IIRC It's was not auto synced from debian
[09:49] <crimsun> ogra: I'll just email you diff.gzs against what's currently in universe ;)
[09:49] <ogra> sivang: look in the build logs if it ftbfs.... if not, trigger elmo for a sync....
[09:49] <sivang> ogra: yes, I should, do you where they are?
[09:49] <ogra> crimsun: thanks :)
[09:49] <sivang> lamont something? ;-)
[09:50] <crimsun> sivang: yes, under his dir on people.u.c
[09:50] <sivang> crimsun: ok, looking
[09:50] <ogra> https://www.ubuntulinux.org/wiki/BuildDaemons
[09:51] <mdz> ogra: they need more than rebuilds
[09:52] <ogra> sivang: if you plan to go for MOTU, you should also see the other pages listed here https://www.ubuntulinux.org/wiki/MOTURecruitment
[09:52] <ogra> mdz: as i understand it, mostly a build dep or a dep change against python2.4 is enough...
[09:53] <sivang> bad, all links in lamont's wiki page for the builddaemons are broken..
[09:53] <sivang> ogra: where I can see recent build logs?
[09:53] <ogra> assuming 2.4 is downwards compatible....
[09:53] <rcaskey_> what kind of hardware does the i386 buildd run on
[09:53] <ogra> sivang: http://people.ubuntu.com/~lamont/buildLogs/
[09:54] <mdz> ogra: for native module packages, you need to add a new python2.4-foo package and arrange for it to be built with the new version of python
[09:54] <ogra> sivang: most recent: http://people.ubuntu.com/~lamont/buildLogs/byDate/today.html
[09:54] <mdz> ogra: for python programs, sometimes it is enough to test with the new python and update a dependency
[09:54] <mdz> at any rate, source changes are required :-)
[09:55] <ogra> mdz: and thats the majority i guess...since most modules pkgs are in main anyway
[09:55] <mdz> ogra: will you remove support for 2.2 and 2.1 where it has not been done already?
[09:55] <mdz> I think doko has done many of them already
[09:55] <ogra> in universe ?
[09:55] <mdz> yes
[09:55] <ogra> i didnt know he also cares for that...
[09:56] <mdz> ogra: in general, if a change in main breaks many things in universe, we try to help with it
[09:56] <sivang> ogra: well, the talked package I was thinking about (gazpacho) is not there, where could it be elsewhere found?
[09:56] <mdz> but with a strong MOTU team, you guys can handle those things
[09:57] <bradb> ogra: sorry, one quick note: when i said "distro" by the way, i meant "universe" not that main can just drop Bugzilla.
[09:57] <ogra> mdz: currently the team is 4 ppl :/
[09:57] <bradb> ogra: but yeah, i get the impression that you're a MOTU, so you should be among the intended early adopters of distro Malone
[09:57] <ogra> bradb: great, thats exactly what i want as a MOTU
[09:58] <ogra> mdz: ... which i wouldnt consider ...strong....
[09:58] <shaya> hmm
[09:58] <shaya> ubuntu install kills vmware beta
[09:58] <rcaskey_> what is Malone?
[09:59] <ogra> mdz: and we all have other (big) tasks....
[09:59] <ogra> rcaskey_: https://launchpad.ubuntu.com/malone
[10:00] <rcaskey_> ahh
[10:01] <rcaskey_> universe has been very good to me, the only real issue is that I really needed to scrap esd in favory of polypaudio
[10:01] <rcaskey_> but that directly relates to base
[10:02] <ogra> rcaskey_: whats your favorite package from universe ?
[10:02] <rcaskey_> wesnoth ;)
[10:02] <ajmitch> ogra: heh, I've got some packages for you for universe ;)
[10:02] <ogra> rcaskey_: like to adopt it andbecome a MOTU ?
[10:03] <mdz> elmo: is python2.2 able to move into universe now?
[10:03] <mdz> ogra: that's why we need to grow the team :-)
[10:03] <ajmitch> ogra: the python programs mdz was talking about
[10:03] <rcaskey_> maybe, we will see, I'm still trying to find someone to sign my key ;)
[10:03] <ogra> mdz: thats hat i'm trying ;)
[10:03] <ogra> what even
[10:03] <ajmitch> ogra: I've started rebuilding some of the packages
[10:03] <crimsun> rcaskey_: I've already converted two hoary machines to polypaudio this afternoon.
[10:04] <rcaskey_> crimsun: was there ever a final decision on what was to be odne about that
[10:04] <rcaskey_> the BOF notes weren't very complete i'm afraid
[10:04] <crimsun> rcaskey_: not afaik. I've pinged jdub RE: polypaudio, but I believe he was/is asleep.
[10:05] <mdz> rcaskey_: www.biglumber.com
[10:05] <crimsun> rcaskey_: if the plan is to transition to polypaudio as transparently as possible, we can keep gst using esdsource and esdsink and just use the default polypaudio setup
[10:06] <ogra> ajmitch: send me a pointer where i can review them<EMAIL_ADDRESS>[10:06] <mdz> rcaskey_: polypaudio is likely to happen for Hoary, but it isn't ready yet
[10:06] <ajmitch> ogra: sure, each package needs modified, so it takes a little while..
[10:06] <ajmitch> grep-dctrl showed 155 of them at last count
[10:06] <crimsun> mdz: out of curiosity, what's keeping it in universe?
[10:06] <ogra> ajmitch: go on... we still have about 2 months.....
[10:06] <mdz> crimsun: nothing in main depends on it
[10:07] <rcaskey_> mdz: GA is very short on oSS types it sees
[10:07] <rcaskey_> the Debian devel map was very sparse  (yes I know Ubuntu is not Debian but...)
[10:07] <crimsun> mdz: hmm, ok. It is literally a drop-in replacement.
[10:07] <ajmitch> ogra: usually there'll be a new binary package built, so debian/control, rules, and install files generally need changed for each
[10:07] <mdz> rcaskey_: biglumber finds 16
[10:08] <ogra> ajmitch: i know.... jst put the source pkgs online anywhere, point me to them and i'll upload them if i consider them ok...
[10:09] <mdz> crimsun: I accept jdub's assessment that it is not time to switch everything over yet
[10:09] <crimsun> mdz: ok.
[10:10] <crimsun> mdz: oh, and regarding the earlier question whether my key is in the strong set, the answer is "yes"
[10:10] <crimsun> mdz: not many signatures at all, but 'yes'
[10:11] <mdz> crimsun: a link into the strongly connected set should be sufficient
[10:11] <ajmitch> mine ought to be in the strong set now
[10:11] <crimsun> ok, I'll try to make it to our next meeting and have our steering committee sign
[10:13] <rcaskey_> I don't suppose the notary public signs ;)
[10:14] <sivang> mdz: what is the "strong" set?
[10:16] <crimsun> sivang: http://www.dtype.org/keyanalyze/explanation.php
[10:16] <ogra> sivang: everything valid/trustworthy you find at the keyservers
[10:16] <crimsun> my lug is the largest on biglumber.
[10:18] <seb128> lamont: could you kick nautilus with eel2 2.9.90-0ubuntu3 ?
[10:19] <lamont> seb128: kicked, I thikn
[10:19] <seb128> thanks
[10:20] <lamont> seb128: btw, ximian-connector is ftbfs: non-PIC (libexchange.a) in shared object. :-(
[10:23] <ajmitch> ogra: placing stuff on webserver now
[10:23] <ogra> ajmitch: fine :)
[10:23] <jdub> GOOD MORNING FREEDOM LOVERS!
[10:23] <jdub> happy australia day! :)
[10:23] <pitti> Hi jdub!
[10:23] <ajmitch> uh oh
[10:23] <ajmitch> hi jdub
[10:24] <ogra> morning....jdub
[10:24] <opi> hi jdub :)
[10:24] <opi> morning, hehe, I'm going to bed now :}
[10:24] <lamont> creating libnautilus-private.la
[10:24] <thom> jdub: happy colony day
[10:24] <lamont> /bin/sed: can't read /usr/lib/libgnome-menu.la: No such file or directory
[10:24] <lamont> seb128: ^^^
[10:24] <crimsun> moin jdub :)
[10:24] <jdub> opi: waking australians is always a good alarm clock ;)
[10:24] <jdub> thom: haw haw ;)
[10:24] <ajmitch> unfortunately our national holiday falls on a weekend this year :)
[10:24] <seb128> lamont: it has picked 0ubuntu2 again, I said 0ubuntu3 :p
[10:25] <lamont> seb128: lol
[10:25] <lamont> I'll wait a little bit then
[10:25] <seb128> ok
[10:25] <seb128> or just put a dep-wait ?
[10:26] <opi> jdub: <kid voice>you'll beeeeeee sorrry</kid voice> :)
[10:26] <seb128> jdub: I'm not happy with ximian guys again, they release crappy versions every time, out of this should be fine :p
[10:26] <crimsun> gotta run out, see you guys.
[10:27] <ogra> ciao crimsun...and congrats ....
[10:27] <ogra> :)
[10:27] <opi> g'night all
[10:28] <lamont> seb128: depwaited this time :-P
[10:28] <ogra> OMG..... backports has xorg now ????
[10:28] <ajmitch> oh dear
[10:28] <lifeless> hhhaaaa
[10:28] <ogra> poor users
[10:29] <ajmitch> guaranteed to break everyones' systems on upgrade to hoary?
[10:29] <seb128> lamont: thanks :) BTW how the depwait works ? It looks for the deps every ... ?
[10:30] <lamont> seb128: the packages are 'dep-wait libeel2 (>> ...0ubuntu2)'
[10:30] <lamont> once a libeel2-dev  (actually) newer than that (>>) is in the archive, the package will automagically transition to needs-build
[10:31] <lamont> so it'll actually be triggerd by the needed package entering the archive.  If the build still fails, then the chroot is polluted, and I have more work to do.
[10:32] <seb128> lamont: but how does it notice the new package ? inotify ? :)
[10:33] <seb128> after each mirror update all the dep-wait are reconsidered ?
[10:33] <jdub> Setting up openoffice.org2-debian-files (1.9.64-0ubuntu2) ...
[10:33] <jdub> /var/lib/dpkg/info/openoffice.org2-debian-files.postinst: line 7: /usr/share/openoffice.org-debian-files2/install-hook: No such file or directory
[10:35] <ogra> ajmitch: pretty likely yes...
[10:35] <ajmitch> ogra: 3 done, on http://ajmitch.dhis.org/debuild/ubuntu/python/
[10:35] <tritium> jdub, I posted a patch to fix that
[10:35] <ajmitch> well, the 3rd one will be there soon :)
[10:35] <ajmitch> just grab the .dsc & .diff.gz, I think
[10:36] <ajmitch> hmm, I should make sure I only copy over the ubuntu-versioned ones
[10:36] <tritium> jdub, please see bug #5853.  I think my patch is correct.
[10:37] <jdub> thom: nooooooo!
[10:38] <ajmitch> python-ctypes done as well
[10:38] <lamont> seb128: as part of the mirror update, after new packages are installed, all the dep-waits are visited
[10:40] <seb128> ok, nice
[10:40] <ogra> ajmitch: -XubuntuX versions apply only if you made ubuntu specific changes to the package....
[10:41] <ajmitch> ogra: since python2.4 isn't default in debian, I made them ubuntu-versioned
[10:41] <ogra> ajmitch: ok
[10:41] <jdub> so dtrace has been released
[10:41] <ogra> ajmitch: just wanted to point it out, since i made this mistake ;)
[10:41] <jdub> the tarball is dtrace.tar.gz
[10:41] <jdub> no version
[10:41] <jdub> and the tarball is insane
[10:41] <jdub> usr/src/cmd/dtrace/
[10:41] <jdub> etc.
[10:41] <ajmitch> how evil
[10:41] <ogra> jdub: eternal version ;)
[10:42] <jdub> well, they have been talking about it like it's perfect ;)
[10:42] <ajmitch> looks like it was made for some 80s UNIX system ;)
[10:42] <dholbach> wow this is not friendly:  http://bugs.debian.org/292214  :-/
[10:44] <ajmitch> not unexpected :)
[10:45] <tritium> jdub, did that fix work for you?
[10:45] <ogra> dholbach: i warned you ;)
[10:45] <dholbach> ogra: i blame reportbug for it :-)
[10:45] <ogra> dholbach: it was a bug in reportbug....
[10:46] <ogra> dholbach: already fixed ;)
[10:46] <dholbach> ogra: i'll tell ari about
[10:47] <ajmitch> I should really try & build on a faster computer :)
[10:47] <ajmitch> either that or make a cup of coffee for each build I do..
[10:49] <dholbach> ajmitch: i could do with a fresh cup myself :-)
[10:53] <tritium> seb128, looks like evo-exchange can't authenticate OWA https:// urls
[10:54] <tritium> but, at least it's no longer contacting localhost instead of my exchange server
[10:56] <jbarroso_> hi people, I'm now on Ubuntu Hoary .... when I finish to move a window and I pup up mouse button, all my screen is redraw slowly. I'm using nvidia drivers from ubuntu repository
[10:57] <ogra> doko ?
[10:57] <kent> the bookmark-section of the Places menu in the panel seems to have issues with folders with spaces in it. For example, i added "/home/kent/Musik film och liknande" to the gtk-filechooser-widget as a bookmark. But when i try to open that with the Places menu, i get this message: http://leviatan.kicks-ass.org/dumps/places-bookmarks.png
[10:57] <jbarroso_> when I click on title-bar of a window, screen is redraw slowly too ....
[10:57] <jbarroso_> do you know about it ?
[10:57] <seb128> kent: what version of gnome-panel ?
[10:57] <kent> seb128, 2.9.4 (going to bugzilla in a few seconds.)
[10:58] <seb128> kent: fixed in 2.9.90, update
[10:58] <kent> seb128, oh. thanks. i wont bugger bugzilla then :)
[11:01] <ajmitch> ok, so python2.2 is segfaulting trying to build this package, which is a little worrying
[11:06] <sivang> seb128: I have modified bits of the g-s-t pkg to allow a default profiledb to be installed with the package, it's failing on the "05_no_ubuntu_warning" patch, any idea? (I didn't change stuff wrt to that)
[11:07] <ogra> argh .....
[11:07] <seb128> sivang: nop
[11:07] <seb128> sivang: what have you changed ?
[11:07] <ogra> whats wrong with http://cdimage.ubuntu.com/ ????? !!!!!
[11:07] <ogra> elmo ^^^^^^^^^ !
[11:08] <mdz> whoa, that's a lot of punctuation there
[11:08] <mdz> it looks perfectly fine to me
[11:08] <dholbach> ogra: to me too
[11:09] <ogra> www.grawert.net/cdimage.png
[11:09] <sivang> seb128: first, I changed stuff in in file.pl.in, to split to storage of configuration files xml from the other cache and debug data.
[11:09] <kent> hmm,  bugzilla.ubunto wont send me my password (yep, forgot it). I did a search on bugzilla and found no bug on hoary gaim that when i kill gnome-panel it also kills gaim and gaim will not respawn. Seems lika gaims plugin for notific.area is buggy or something.
[11:10] <dholbach> ogra: well yes, that looks somehow wrong :-)
[11:10] <sivang> seb128: then I added 2 lines to the rules file, to create /etc/g-s-t and to install the config data there.
[11:10] <seb128> kent: yep, there is no bug open for that
[11:10] <ogra> http://cdimage.ubuntu.com/daily-live/current/: The requested URL /daily-live/current/ was not found on this server.
[11:11] <kent> seb128, will wait for bugzilla to send me my password. not sure where that mail went, and i cant get it to send it again.  its probably just taking a few min.
[11:11] <seb128> ok
[11:12] <Kamion> looks like it's broken on mirnyy, which is one of the two hosts that cdimage now round-robins to
[11:12] <ogra> ah...that explains it
[11:12] <Kamion> mirnyy's new in that round-robin, I guess elmo's still fixing it up
[11:36] <ogra> could someone change the topic in #ubuntu ? i think the metacity warning is obsolete
[11:41] <ogra> opi: morning ;)
[11:41] <opi> ogra: gaaa. I can not sleep.
[11:41] <opi> ogra: I've been flamed once again by gf, because instead of rest I'm doing some Wiki work at ubuntulinux.org ;)
[11:44] <opi> mine supports me too
[11:44] <opi> but she don't see me often nowdays, even in we live in same flat ;)
[11:44] <mdz> ogra: you can't change it?
[11:45] <ogra> mdz: i cant give me op status....
[11:45] <Kamion> you don't need operator privileges to change the topic unless the +t channel mode is set
[11:45] <ogra> opi: mine neither, but she knows everything i do is right ;)
[11:46] <opi> how do I make intend in moinmoin? :)
[11:46] <ogra>  #ubuntu :You need to be a channel operator to do that
[11:46] <ogra> :(
[11:46] <Kamion> ... evidently somebody set +t then, ok
[11:48] <thom> #3091 is such crack
[11:55] <nakeee> I have a glibc bug I'm trying to get people to apply a patch to for almost year and a half now if not more
[11:56] <nakeee> the guy who wrote the patch tried the glibc bugzilla/mailing list
[11:56] <nakeee> I tried debian bugzilla and I htink the maintainer didn't understand what the bug is
[11:56] <thom> nakeee: #debian-glibc might be more interested; or ping jbailey
[11:56] <azeem> there's no 'debian bugzilla'
[11:56] <nakeee> azeem: debian bug system:)
[11:57] <doko> ogra: pong
[11:58] <nakeee> no I move to ubuntu so if the patch would get there it's good enough for me:) jbailey is ubuntu's glibc person?
[11:58] <nakeee> now
[11:59] <azeem> nakeee: what's the bug number?


[04:34] <cjwatson> mardy_: who could approve https://code.launchpad.net/~online-accounts/libsignon-glib/packaging/+merge/279981 ?  it's at the root of a build chain on s390x that winds up blocking some things (e.g. telephony-service) due to them building uninstallable binaries, so would be nice to get it shifted


[00:18] <Peng> "Rendering RevisionUI: 51.553565979003906 secs, 35388458 bytes, 15192308 (42.9%) bytes saved" <-- Oops.
[00:21] <Peng> I accidentally loaded it again, and this time it took 73 seconds. :)
[02:04] <sstangl> Does bzr have a way to auto-generate a patch?
[02:05] <sstangl> I want to generate a patch from local branch "development" against local branch "trunk" to be emailed.
[02:07] <sstangl> ah, send.
[02:20] <mib_zv5ff9> I use bazaar to track version changes with my python application...  you know that __version__ attribute seen in most python programs?  I was wondering if those are typically automatically given a value after doing a version commit (and how to do that), or if the developer puts in a number manually?
[03:00]  * rockstar looks around for james_w
[05:26] <lifeless> rockstar: james_w is on utc time
[05:28] <rockstar> lifeless, yea, I knew that, but thought I'd try anyway.
[05:29] <lifeless> 1am - hoopeful :)
[06:44] <abentley> lifeless: morning.
[06:47] <lifeless> hi abentley
[06:48] <abentley> lifeless: When are you flying?
[06:48] <lifeless> leaving hotel at 1100
[06:49] <abentley> I was thinking 11:45
[06:49] <lifeless> that would be too late for my flight, have to be at airport by 1200
[06:50] <lifeless> so I'm catching a lift with davyd
[06:51] <abentley> Okay.  I'm packing right now, but ping me if you want to pair on something, or just hang out.
[06:52] <lifeless> k
[06:52] <lifeless> I'm eating now
[06:53] <lifeless> the 333MB index has under 1MB left to parse
[06:53] <abentley> Teh Rock!
[06:59] <LaserJock> jelmer: around?
[07:01] <Peng> lifeless: With your mailing list message about adding bzr-svn to the PPA, do you mean 0.4.10? Because it's gotten significantly better since then..
[07:01] <lifeless> Peng: 0.4.aything >> None
[07:02] <Peng> 0.4.11exp0? :D
[07:02] <lifeless> well
[07:02] <LaserJock> I updated my bzr-svn branch (0.4) and now it fails to load
[07:02] <lifeless> concretely I'd like something that matches the bzr in each ppa
[07:02] <lifeless> LaserJock: run make
[07:03] <Peng> lifeless: The 0.4 branch matches bzr.dev. :P
[07:03] <lifeless> Peng: if you use the ppa today you end up not having bzr-svn
[07:03] <lifeless> Peng: this is a bug
[07:04] <LaserJock> hmmpf, it needs apr-config
[07:04] <Peng> Are you implying that the PPA works?
[07:05] <Peng> Wow, it's been almost 2 months since 1.5 was released.
[07:05] <Peng> 1 month since 1.6b2.
[07:15] <LaserJock> ok, phew, got it working again :-)
[07:25] <lifeless> time to finish packing
[07:26] <Peng> You people with your lives and traveling and contributions to society... Pssh.
[07:32] <lifeless> :)
[07:33] <LaserJock> oh darn, I'm in a bit of a pickle :/
[07:34] <LaserJock> are there any bzr-tools packages compatible with the bzr 1.6 betas?
[07:34] <lifeless> yes
[07:34] <lifeless> 1.6 bzrtools should be in the beta ppa
[07:34] <LaserJock> ... it's not
[07:35] <lifeless> oh
[07:35] <LaserJock> https://edge.launchpad.net/~bzr-beta-ppa/+archive only has bzr
[07:35] <lifeless> well its at lp:bzrtools I think
[07:35] <LaserJock> *sigh* OK
[07:37] <LaserJock> this well this spagetti of packages is getting messy
[07:39] <lifeless> yes
[07:39] <LaserJock> I can't remove bzr-tools because of bzr-builddeb
[07:39] <lifeless> I'd love some more csript support for the folk doing ppa maintenance
[07:40] <LaserJock> although I suppose I can keep it but use the bzr branch of bzr-tools
[07:40] <LaserJock> but I only need bzr 1.6 because I updated bzr-svn
[07:46]  * Peng doesn't use the packages at all.
[08:07] <LaserJock> Peng: well, I'm a simple user and I'd rather spend time using the VCS than tracking down all the versions
[08:10] <luks> LaserJock: the thing is that it's easier to do `bzr branch lp:bzrtools ~/.bazaar/plugins` than to find the right package
[08:25] <LaserJock> luks: yeah, but then you update and things are screwed
[08:26] <luks> LaserJock: why do you think so?
[08:26] <LaserJock> because that's what I just did
[08:26] <luks> LaserJock: in me experience, things are screwed more if some debian packages refuse to update
[08:27] <luks> *my
[08:27] <LaserJock> I wondered if new stuff was in bzr-svn, and now I'm running after dependencies
[08:30] <Peng> New stuff is most definitely in bzr-svn.
[08:34] <LaserJock> well, I figured being on the 0.4 branch wouldn't be too bad
[08:35] <Peng> It's not bad.
[08:35] <Peng> But it has new C bits, so you have to run make.
[08:35] <LaserJock> except it require a beta bzr
[08:35] <Peng> Oh.
[08:35] <Peng> I run bzr.dev anyway, so I hadn't noticed.
[08:35] <LaserJock> which gives me problems with bzr-tools
[08:47] <LaserJock> hmm, I can't find what reversion the bzr-dep was bumped :/
[09:04] <LaserJock> ok, so I can't branch bzrtools because my current bzr won't work
[09:06] <LaserJock> hmm, so I think I need to start from scratch
[09:11] <Peng> LaserJock: Why won't it work?
[09:13] <LaserJock> Peng: gives me some traceback
[09:14] <Peng> LaserJock: Details?
[09:14] <LaserJock> Peng: so I went back and removed everything bzr
[09:14] <Peng> LaserJock: If it's from a plugin, you can run bzr without plugins temporarily.
[09:14] <LaserJock> reinstalled 1.5
[09:14] <LaserJock> now I'm trying to see if I can get a bzr-svn that works
[09:15] <LaserJock> bah! it want's python2.4
[09:16] <Peng> Bazaar has required Python 2.4 or greater for ages.
[09:16] <LaserJock> no, I mean I have 2.5
[09:16] <Peng> You mean bzr-svn specifically wants python2.4 rather than 'python -- yeah./
[09:17] <Peng> Um, I use bzr-svn's 0.4 branch, and I don't have python2.4.
[09:17] <LaserJock> yeah, I can't use that branch right now
[09:17] <Peng> Why not?
[09:17] <LaserJock> because it requires a newer bzr!
[09:17] <LaserJock> this is the cycle I've been going through
[09:18] <Peng> Oh.
[09:18] <LaserJock> somewhere the bzr dependency got bumped
[09:18] <Peng> There's no cycle for me, but I use the dev branches of everything.
[09:18] <Peng> And don't build packages or anything.
[09:18] <LaserJock> right, which is not great for me
[09:19] <LaserJock> I'm not trying to be necessarily at the tip of development, I just want a set that works
[09:20] <Peng> The tip of development works. :P
[09:20] <LaserJock> if I can find where in the 0.4 branch the bzr dep was bumped I can go back to that revision, but I can't find it
[09:20] <GaryvdM> Hi - I'm having a problem with ext-merge on windows. The file name has / separators and it should have \ .
[09:21] <LaserJock> Peng: I guess, but I'd end up updating a lot of branches to keep up
[09:21] <LaserJock> if I have to do bzr, bzrtools, bzr-svn, and the other plugins
[09:21] <GaryvdM> Is there a api method to get a windows path from a unix path or should is just replace / with \ if on windows?
[09:21] <LaserJock> and if they don't work with the current bzr.dev branch then they break
[09:22] <LaserJock> anyway, I've got to go to bed, I'll trying to think of something tomorrow
[09:23] <Peng> LaserJock: Yeah. I do keep up with them, and it's not too much effort. I update bzr.dev and bzr-svn whenever I'm bored (which is every 2 hours), and update the others whenever I think of it (every week or two?), and things usually work.
[09:23] <Peng> LaserJock: Anyway, good night. :)
[09:23] <Peng> GaryvdM: os.path?
[09:24]  * Peng stares at Freenode.
[09:24] <GaryvdM> This is where it gets the filenames:
[09:24] <GaryvdM> http://bazaar.launchpad.net/~zindar/bzr-extmerge/trunk/annotate/10?file_id=__init__.py-20060218133530-ac9ae4e505cbcfa9#L70
[09:25] <GaryvdM> I'm browsing bzrlib/osutils.py atm
[09:26] <GaryvdM> I think might be able to find something there.
[10:07] <GaryvdM> Is there a way to specify --fixes= after you have commited?
[10:54] <lifeless> Guest12932: you are thashing your name; please stop, its filling the page up with noice
[10:58] <Peng> lifeless: Do you have the ability to ban him?
[11:00] <lifeless> yes, though I think Lnidas is somewhat regular and that seems harsh
[11:02] <Peng> I agree, but temporarily banning people with misconfigured clients isn't an uncommon practice.
[11:03] <Peng> Heck, it's not like anything is going on here anyway.
[11:03] <lifeless> Leonidas: ping
[11:03] <lifeless> Peng: OTOH I'm about to hop on a plane; I won't be around to unban
[11:03] <Peng> lifeless: Oh.
[11:05] <lifeless> which is more of a problem  I feel
[11:07] <Peng> lifeless: Before you go, what's the status of bzr-search? Is it, like, done? Do you think it should be merged into the core?
[11:08] <lifeless> Peng: well, there are some bugs open indicating future work
[11:08] <lifeless> Peng: I consider it alpha status
[11:08] <Peng> That would've been great if he had auto-rejoin off.
[11:09]  * Peng blinks.
[11:09] <lifeless> ok, so its entertaining but useless
[11:10] <lifeless> bah
[11:10] <lifeless> I don't want to kick the username, because I won't be around
[11:10] <lifeless> sorry, but perhaps /ignore Guest* ?
[11:10] <oleavr> or<EMAIL_ADDRESS>[11:10] <Toksyuryel> he's not changing his name to guest, nickserv is
[11:11] <Toksyuryel> because he's not entering the password for the nick
[11:11] <lifeless> oleavr: yeah, I want him/her to be able to join the channel; I will be offline very soon
[11:11] <lifeless> Toksyuryel: oh, interesting
[11:12] <Toksyuryel> given the number of attempts I'd wager that's not the real owner of that nick
[11:12] <lifeless> I'm pretty sure it is
[11:12] <oleavr> lifeless: ah I see
[11:12] <lifeless> oleavr: so if they could msg me and say 'fixed unban me' I would ban them, but as I have to go - bad idea
[11:14] <oleavr> lifeless: yep, understandable :)
[11:14] <lifeless> Toksyuryel: I reckon they are not in front of the pc/not notcing nickserv complaining
[11:14] <Toksyuryel> lifeless: then why does the nick keep changing back?
[11:14] <lifeless> Toksyuryel: client
[11:15] <lifeless> Toksyuryel: or they don't understand why its happening
[11:15] <Toksyuryel> lifeless: what client auto-changes one's nick back?
[11:15] <Toksyuryel> if they don't understand why it's happening it means they don't own the nick
[11:16] <lifeless> 20:15 [freenode] -!-  away     : Auto Away at Thu Jul  3 16:41:12 2008
[11:16] <Toksyuryel> a better script might be an auto-identify script :P
[11:17] <Peng> -Guest2534- VERSION ZNC by prozac - http://znc.sourceforge.net <-- Apparently that client.
[11:18] <Peng> Oh, it's a bouncer.
[11:19] <Toksyuryel><EMAIL_ADDRESS>[11:20] <lifeless> clearly, after 10 days idle this is unlikely to go away in the next 5 hours :)
[11:20] <Toksyuryel> heh heh
[11:21] <lifeless> Peng: so search
[11:21] <lifeless> Peng: I think its alpha - it works but there are some important things to do to make it as slick and smooth as the rest of bzr
[11:22] <lifeless> Peng: getting indices shared between branches; stemming; date ranges; for starters
[11:24] <lifeless> and there is the boarding call; I must go
[11:24] <lifeless> back in 6 or so
[11:24] <Peng> lifeless: D'oh, I was jsut about to say something. Anyway, have a nice flight. :)
[11:24] <lifeless> Peng: oh, I think search is reliable now, just not complete; if that helps with clarity
[11:24] <lifeless> bye
[11:25] <Peng> lifeless: Thanks, it does.
[11:28] <GaryvdM> ping luks
[11:33] <Peng> GaryvdM: FWIW, my IRC client says his last message was 186 minutes ago.
[11:33] <GaryvdM> ok - thanks
[11:36] <luks> GaryvdM: pong
[11:37] <GaryvdM> I wanted to chat about qdiff
[11:37] <GaryvdM> I was thinking for background loading
[11:38] <GaryvdM> The different views each have a append_diff method
[11:39] <GaryvdM> The background loading calls thoughs methods when it has finished a diff.
[11:40] <luks> have you seen my changes to the code from yesterday?
[11:40] <GaryvdM> That will split populate_diff_documents.
[11:40] <GaryvdM> Yes
[11:40] <GaryvdM> Thats why I wanted to chat
[11:41] <GaryvdM> So far - I actually have not written any code. Just reading and planing.
[11:41] <luks> personally, the only thing I'd do is moving sequence matching from the initialization code to populate_diff_documents
[11:41] <luks> and make populate_diff_documents only work on one file at a time
[11:42] <luks> which would be repeatedly called by an idle timer, until all files are diffed
[11:43] <GaryvdM> ok
[11:46] <luks> GaryvdM: I mean, I don't mind any other solution if you think it's better, but this seemed the easiest to me
[11:46] <luks> you are going to write the code, after all, you decide :)
[11:47] <GaryvdM> DiffSourceView.setChanges and DiffViewHandle.setChanges  need the be changed to extendChanges
[11:47] <luks> yep
[11:47] <GaryvdM> Yes - but you know then code better than I so you might be able to give me advice...
[11:48] <GaryvdM>  Ok - time to dive in....
[12:14] <strk> $ bzr update
[12:14] <strk> You tried to execute: bzr serve --inet --directory=/ --allow-writes
[12:14] <strk> Sorry, you are not allowed to execute that command.
[12:14] <strk> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
[12:14] <strk> gnash project, repository on savannah
[12:14] <bob2> lp?
[12:14] <bob2> does 'unset BZR_REMOTE_PATH ; bzr up' work?
[12:15] <strk> no such env
[12:15] <luks> misconfigured server on savannah?
[12:15] <strk> same error with the unset anyway
[13:06] <spiv> strk: sounds like a misconfigured server
[13:12] <strk> they must have changed something within the last 12 hours then
[13:52] <vimes656> hi there
[13:52] <vimes656> I'm using bzr bzr1.5 installed from fink in mac os x
[13:52] <vimes656> I'm always getting a locale error
[13:53] <vimes656> bzr: warning: unknown encoding . Continuing with ascii encoding.
[14:10] <mathrick> hiya
[14:10] <mathrick> I hit a bug in bzr cat
[14:10] <mathrick> http://pastebin.com/f78cd4840
[14:10] <mathrick> I don't know what to make of it
[14:25] <spiv> mathrick: That's https://bugs.launchpad.net/bzr/+bug/175570, I think.
[14:26] <mathrick> spiv: ah, bummer
[15:55] <colbrac> I just posted a patch on the bzr-gtk mailinglist with some dialog cleanup.. any comments?
[15:56] <ToyKeeper> Yeah, but I'm replying on-list.
[16:21] <Leonidas> lifeless: you can unban me already, I've got it working again
[16:21] <Leonidas> my bouncer started to play ping-pong with the services
[16:22] <Leonidas> (sorry for these problems, I'll take a look at the configuration of the bouncer)
[16:24] <Peng> Did the bouncer finally give up or what?
[16:46] <clemente> Hi; I plan to turn my web site into a branch repository to hold different simultaneous developments. But is there an easy way to check out a whole repository with all branches?
[16:56] <liw> clemente, I don't know of such a way; I've occasionally wanted a "bzr branches http://foo/repository" kind of command, which would let one script things
[16:56] <liw> (there might be one, I have not really looked for one throughly)
[16:59] <colbrac> About the olive.glade file: The window_merge is used in MergeDialog in olive. But, unlike the other window_* dialogs, MergeDialog is not in the olive subfolder but in the main folder in merge.py. Is it thus used outside of olive?
[17:01] <clemente> liw: that would be good; otherwise you need to know the exact name of each branch; is it like that?
[17:01] <liw> clemente, as far as I know, you need to know the exact name of each branch to check them all out
[17:17] <mathrick> I'm enhancing Bugs Everywhere to support operations on arbitrary branch URLs, not just working trees in the current directory, and I'm not sure how best to go about re-structuring the bzr backend of it
[17:18] <mathrick> namely, the current implementation happily invokes bzr as a subprocess (ie. plain old popen()), and assumes there is a working tree available. So it can do things like add several files, then commit them all in a batch
[17:18] <Peng> bzrtools adds a "bzr branches" command that recursively finds all branches in the current directory.
[17:18] <mathrick> what is the best way to implement that from python using bzrlib?
[17:18] <mathrick> that is, I want to be able to accept several ops, construct a revision from them, and then push it to a branch
[17:19] <mathrick> having temp files is A-OK, but requiring working trees is not
[17:22] <clemente> Peng: but not on a remote server, I think
[17:23] <clemente> (trying)
[17:25] <clemente> Mmmm :-(
[17:25] <clemente> bzr: ERROR: Could not understand response from smart server: ('UnicodeDecodeError', 'ascii', 's:w7p0aWxlcw==')
[17:59]  * mathrick still looks for someone to help him with navigating bzr's innards
[18:00] <mathrick> to rephrase my question, is it possible to build up a commit without having a (physical) working tree?
[18:25] <clemente> mathrick: I have no idea... Maybe you can construct a pack directly? Or maybe using bzr fast-import... fast-import accepts just a stream of data and does not require files
[18:25] <mathrick> oh, that's certainly a hint, thanks
[18:26] <clemente> It is the same data format that „git fast-export“ creates
[18:28] <lifeless> mathrick: yes
[18:28] <lifeless> mathrick: there are tests that do this using InMemoryWorkingTree
[18:28] <lifeless> or MemoryTree or whatever I called it
[18:28] <mathrick> oh!
[18:29] <mathrick> cool, so reading those tests should tell me everything I need to know?
[18:29] <lifeless> its only as sophisticated as I needed it to be at the time; but further improvements would be welcomed:)
[18:29] <lifeless> mathrick: yah
[18:30] <mathrick> I don't expect my needs to be terribly sophisticated, I follow a rigid protocol and mostly communicate with myself
[18:30] <mathrick> well, somewhat rigid
[18:33] <lifeless> mathrick: well, give it a shot; let me know how it goes
[18:34] <mathrick> yup, doing that now
[18:34] <lifeless> Leonidas: unbanned, thanks
[18:38] <Leonidas> lifeless: thank you. I changed the settings and will change the bouncer to prevent this from happending in the future
[18:38] <lifeless> Leonidas: no probs
[18:50]  * Odd_Bloke returns.
[18:55] <liw> http://www.yosefk.com/blog/dvcs-and-its-most-vexing-merge.html -- that has probably been discussed to death, yes?
[18:56] <mathrick> does put_file_bytes_non_atomic replace the previous contents?
[18:56] <mathrick> liw: the answer is "depends on your merge algorithm"
[18:57] <mathrick> in particular, diff3 fails this test miserably
[19:23] <colbrac> funfact: bzr-gtk trunk is 1000 days old today
[19:23] <colbrac> at least.. according to my olive information dialog :)
[19:28] <lifeless> mathrick: yes it replaces
[19:29] <lifeless> colbrac: cool
[19:33] <clemente> In a repository, I did (knowingly...) „rm -rf branch/“. But since the contents were stored in repo/.bzr and not in the branch, repo/.bzr has still a lot of things I don't want. How can I really remove the remainings of the branch?
[19:34] <lifeless> clemente: you mean a gc?
[19:34] <clemente> yes
[19:34] <lifeless> I should really write that :). Anyhow, the manual way is to make a new repo; branch the branches you want to keep into it and then replace the old repo's .bzr/repository with the new one's.
[19:34] <clemente> but there's no „gc“ command
[19:35] <lifeless> thats what bzr gc will do when I get around to writing it
[19:35] <lifeless> (well, it will optimise away some of the copying, but it will be conceptually the same)
[19:37] <clemente> Thanks, I'll try it. By the way, I had to remove the branch by force because I had interrupted a „branch“ with C-c and then no command I tried could delete it
[19:37] <ToyKeeper> That reminds me... is there a way to see which abandoned branches are in the repo, and maybe get them back?
[19:37] <lifeless> clemente: did you try zr break-lock ?
[19:37] <lifeless> ToyKeeper: bzr hads
[19:37] <lifeless> *heads*
[19:38] <colbrac> bzr heads only shows 2 for me
[19:38] <colbrac> and I have a few more
[19:38] <ToyKeeper> Hmm, must be in some plugin I don't have right now.  I think I've seen it somewhere, though.
[19:39] <colbrac> bzr help heads to the rescue
[19:39] <colbrac> bzr heads --all
[19:39] <colbrac> or even better
[19:39] <colbrac> bzr heads --dead-only
[19:39] <clemente> lifeless: No... In fact I don't know how to remove the branch. Is it remove-tree?
[19:40] <clemente> lifeless: By the way, I thought that command „reconcile“ would be similar to what you said about „gc“. Maybe they share features
[19:51] <lifeless> clemente: to remove a branch its normally just rm -rrf branch
[19:51] <lifeless> erm, -rf I mean :)
[19:51] <lifeless> ToyKeeper: its in bzrtools
[19:51] <lifeless> clemente: remove-tree removes the working tree, so you just have the branch on its own.
[19:54] <clemente> But it's still needed a command to remove a branch which exists in a repository
[19:54] <clemente> Althought rm -rf  + bzr gc   would work, too...
[19:54] <ToyKeeper> Ah, I just hadn't set up a version compatible with bzr.dev yet.
[19:59] <lifeless> clemente: well, yes. generally though a branch is a tiny fraction of a repo
[19:59] <lifeless> clemente: so there has been little user pressure to make this part of the system streamlined (though it will happen) :). In particular, rming the directory leaves the head behind which is beneficial
[19:59] <lifeless> (if you want to recover later :))
[20:03] <Peng> Hmm, I occasionally mess up with bzr-svn and pollute a repo. A gc command would be nice there.
[20:05] <lifeless> Peng: well a first implementation for packs would be refs = last-revision + tags for b in repo.find_branches(); create-pack_from_packs(revs = refs); remove packs matching refs;
[20:06] <Peng> Would it wind up packing everything into one pack?
[20:12] <lifeless> nah, only the ones it has to read to grab shit from
[20:13] <lifeless> theres a little more glue etc in there, that was clearly just a sketch :)
[20:39] <apol> how can I update to a revision from a workingtree?
[20:42] <lifeless> apol: udpate will take you to tip, revert can take you back
[20:42] <apol> mmm
[20:42] <apol> fine
[20:42] <apol> but... update only updates
[20:42] <lifeless> yes, need to add -r to it
[20:42] <apol> lifeless: i need to update it to a certain revision (say as svn up -r213)
[20:43] <lifeless> apol: revert -r 213
[20:43] <lifeless> apol: if you have local edits, shelve them first
[20:44] <apol> lifeless: and with the python interface? is it the old_tree parameter?
[20:45] <lifeless> apol: not sure offhand, builtins.cmd_revert and follow your nose probably
[20:45] <apol> lifeless: cool
[20:47] <apol> thx
[20:47] <lifeless> np
[21:45] <Peng> Huh, Loggerhead's RAM usage has dropped slightly twice today.
[22:52]  * Foskasse http://graphjam.files.wordpress.com/2008/06/gj32.gif LOL!
[22:57] <mathrick> ok, so I can hit https://bugs.launchpad.net/bzr/+bug/175570 with memorytree as well against bzr://
[22:57] <mathrick> it seems that branch.lock_read() does NOT lock the repo
[22:57] <mathrick> even though branch.is_locked() returns true
[22:58] <mathrick> could anyone assist me with debugging that?
[22:59] <mwhudson> mathrick: do you have a testcase ?
[22:59] <mathrick> mwhudson: I will in a second, but I wanted to poke around more in PDB
[23:03] <mwhudson> hm, the traceback in the bug report is out of date
[23:04] <mwhudson> mathrick: it seems to work for me now
[23:05] <mathrick> it doesn't for me
[23:05] <mathrick> I'm running 1.5 btw
[23:05] <mwhudson> mathrick: i'm running 1.6b2 i think
[23:05] <mathrick> mostly because 1.6 breaks loggerhead and it hasn't been updated last I checked
[23:05] <mwhudson> mathrick: this seems like this sort of thing that might have been fixed by accident in the versionedfiles refactoring
[23:05] <mwhudson> mathrick: i'm pretty sure loggerhead works with 1.6...
[23:06] <mathrick> it didn't when I tried
[23:06] <mwhudson> try again :)
[23:06] <mathrick> if it does, then I see no reason to stick with 1.6 :)
[23:06] <mwhudson> http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/revision/181 looks relevant
[23:12] <mathrick> yep, thanks
[23:14] <mathrick> isn't there a PPA for bzrtools?
[23:29] <mathrick> mwhudson: still happens for me on 1.6b2
[23:29] <mwhudson> mathrick: hmm
[23:29] <mathrick> oh, maybe it's because the server is still running 1.5
[23:29] <mwhudson> ah
[23:30] <mathrick> nope
[23:30] <mathrick> reran it as 1.6b2, still happens
[23:34] <mathrick> mwhudson: https://bugs.launchpad.net/bzr/+bug/175570
[23:35] <mwhudson> mathrick: can you pastebin the traceback?
[23:35] <mathrick> mwhudson: I did
[23:35] <mwhudson> if i run bzr serve in one window
[23:35] <mathrick> as a python comment
[23:35] <mwhudson> oh ok
[23:35] <mwhudson> i can run "bzr cat bzr://localhost:4155/README" in another
[23:36] <mathrick> mwhudson: hmm, can you try subdir/README?
[23:36] <mathrick> nah, that happens here for files in the main dir as well
[23:37] <mathrick> mwhudson: what is the format of the repo?
[23:37] <mwhudson> very odd
[23:37] <mathrick> mine is pack-0.92
[23:38] <mwhudson> same
[23:38] <mwhudson> hm, if i run your python code it fails in a different way
[23:38] <mwhudson> http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/revision/181
[23:38] <mwhudson> no
[23:38] <mwhudson> NotImplementedError: <bound method MemoryTree._populate_from_branch of <bzrlib.memorytree.MemoryTree object at 0x7f284c38f8d0>>
[23:39] <mathrick> oh
[23:40] <mathrick> mwhudson: definitely something is not in sync at your place
[23:40] <mathrick> it's implemented and supposed to work
[23:41] <mwhudson> oh
[23:41] <mwhudson> that's because i have symlinks in the tree i'm testing with, it seems
[23:43] <mwhudson> ok, now it fails the same way as for you
[23:45] <mwhudson> mathrick: http://pastebin.ubuntu.com/27148/ seems to summarize the problem
[23:46]  * mwhudson pulls in latest bzr.dev
[23:54] <cyberix> I'm working on a bzr branch and it uses the bzrlib from my Ubuntu installation instead the one from that branch ( without my permission ;-)
[23:54] <cyberix> How do I force it to use the one that comes with it
[23:54] <cyberix> s/bzr branch/bzr bzr branch/
[23:55] <Verterok> cyberix: /path/to/branch/bzr selftest ;)
[23:55] <Verterok> cyberix: s/selftest/<any_command>/
[23:58] <cyberix> That is what I'm doing
[23:59] <Verterok> hm, cyberix: try with: PYTHONPATH=/path/to/branch:$PYTHONPATH /path/to/branch/bzr


[00:05] <Steve45> I just compared the md5checksum for the iso and it matches so that's not the problem
[00:06] <akem> Ok, good, try some usb-creator now to create the boot stick.
[00:08] <Steve45> Thank you I'll do that
[02:44] <Charley> Hi, I am having trouble installing Lubuntu on a pretty old toshiba Satellite laptop
[02:45] <Charley> After installation I get an error on start up that there is no bootable device
[02:47] <Charley> My Bios does not seem to have the "secure boot" or "select an UEFI" options
[02:47] <Charley> Is there anyone here ho might be able to help?
[05:45] <korn788> hello is anyone online that can help me with installing steam
[07:18] <WarSpEcK> hi :)
[07:45] <Sally> I using Lubuntu 19.04 Can i upgrade the  os to 20.04
[07:45] <Sally> Lts
[07:46] <Sally> or do i have to re install the os
[07:47] <guiverc> Sally, the default tools will upgrade you to 19.10 (the fully tested & supported path from 19.04)
[07:50] <Sally> ah cool ty! just noticed that my current os is no longer supported  and did not wish to wipe the drive
[07:51] <Sally> what is the tool name to update?
[07:51] <apt-ghetto> If you reinstall, you are faster (having a backup)
[07:51] <apt-ghetto> To upgrade: sudo apt update && sudo apt full-upgrade && sudo do-release-upgrade
[07:52] <apt-ghetto> And then you have to upgrade from 19.10 to 20.04
[07:52] <guiverc> you should ensure your system is fully-upgraded (it'll be more difficult because 19.04 is EOL; see  https://help.ubuntu.com/community/EOLUpgrades  which shows how to change to point to old-releases.ubuntu.com) - reinstall is far faster (use manual-partitioning & no-format to not wipe your user files, backup first regarldess)
[07:54] <Sally> omg ty so much! still very new to linux
[07:55] <guiverc> also re-install allows you to skip the 19.10; so whilst faster than 19.04->19.10; it'll jump you straight to 20.04 instead of two far longer upgrades
[17:27] <el-x-cutie> is anyone capable of reading this?
[18:09] <tomreyn> no
[18:11] <tomreyn> el-x-cutie: well, maybe someone else. i didn't really read it, though, just glanced at it quickly.
[18:13] <el-x-cutie> thx - seems to work ^^