[01:38] <snap-l> dammit, someone already registered some ideas I had for domain names
[01:38] <snap-l> shouldiwearpants.com and amiwearingpants.com
[01:42] <snap-l> Dammit, and hungerpan.gs is already taken
[01:43] <snap-l> And so is psychic.tv
[01:43] <snap-l> Whiat is this world coming to?
[01:44] <brousch> The world is squatted
[03:16] <snap-l> Just stripped my nook books of DRM
[03:16] <snap-l> piss-easy
[03:17] <snap-l> Should Microsoft make good on buying and destroying Nook, I'm taking the content with me to another device.
[03:17] <snap-l> Be it a Tablet or what, I don't care.
[03:53] <rick_h_> evening
[03:54] <rick_h_> snap-l: was going to ask you about the nook stuff
[03:54] <rick_h_> you can have a windows8 tablet book reader
[04:33] <greg-g> rick_h_: jcastro btw, thanks much for picking up the tab(s) last night. :-)
[05:56] <rick_h_> jcastro: https://store.yubico.com/store/catalog/index.php?cPath=20
[05:56] <rick_h_> greg-g: np, thanks for the good times
[12:51] <snap-l> rick_h_: The same day you have a non-tiling window manager is the day I'll gladly use a Windows 8 tablet book reader.
[12:51] <snap-l> Also saw the Microsoft Store they're building in Sommerset.
[12:51] <snap-l> I wish them every opportunity to waste money.
[12:51] <brousch> rick_h_: Now you need to do it just for snap-l
[12:57] <snap-l> heh
[12:57] <fitztrev> grand opening june 28th with kelly clarkson performing live
[12:57] <fitztrev> ha
[13:37] <jrwren> ugh
[13:39] <flipsidecreation> no ugh, its friday
[13:49] <jrwren> FRIDAY< FRIDAY< GOTTA GET DOWN ON FRIDAY
[13:49] <flipsidecreation> yup@
[13:49] <flipsidecreation> yup!
[14:09] <snap-l> Well, that was fun
[14:10] <snap-l> apparently the USB backplane my UPS was connected to isn't working
[14:10] <snap-l> so I moved it, and it suddenly declared the UPS was critically low
[14:10] <snap-l> *poof*
[14:13] <jrwren> :(
[14:24] <rick_h_> snap-l: heh, been on unity a lot this week :P
[14:28] <snap-l> rick_h_: And?
[15:25] <rick_h_> snap-l: and it's non-tiling :P
[15:28] <greg-g> and he's going to kill someone
[15:28] <greg-g> I think is the answer snap-l was going for
[15:37] <snap-l> Yeah, I should have quantified it better
[19:39] <greg-g> snap-l: help me remember cellphone stupidness: sprint/ting uses XYZ for it's standard, in the Europe they use...?
[19:45] <snap-l> sprint / Verizon use CDMA
[19:45] <snap-l> AT&T / TMo use GSM
[19:46] <snap-l> GSM is the European standard
[19:51] <snap-l> greg-g: ^^
[20:00] <greg-g> snap-l: so I don't get to use my phone in Amsterdam, then, at all, right?
[20:00] <greg-g> snap-l: I guess I can use WIFI in various places, but that's kind of lame
[20:00] <greg-g> oh well
[20:03] <snap-l> greg-g: Yeah, unfortunately the Ting phone is domestic
[20:04] <snap-l> but, you could get a burner for cheap in Amsterdam
[20:23] <rick_h_> greg-g: yea, I bought a CDMA mifi unit and when I went to copenhagen got a local sim and hooked my phone up to the mifi around town
[20:41] <greg-g> rick_h_: ah, yeah
[20:59] <UnFixed> even if you got a gsm phone, it would still have to be unlocked to use internationally
[20:59] <UnFixed> also
[21:00] <UnFixed> my sprint home connect should have been delivered today. need to head home and try it.
[21:06] <jrwren> what does that do?
[21:06] <snap-l> The home connect? Allows you to hook landline phones to cell service.


[16:31] <arraybolt3> teward: *shoves a pot of freshly brewed coffee your way* hi I require ops here, no context, thx :D
[16:31] <arraybolt3> ok so really I'm about ready to help hook up Matrix-to-IRC bridging.
[16:31] <arraybolt3> ravage (Nils) asked if I had a Lubuntu room I had ops permissions in on both sides. I have Admin in the Lubuntu Development Matrix room, but needs ops here also.
[17:42] <teward> arraybolt3: enjoy the stick for now
[17:42] <teward> *sips caffeine*
[17:42] <arraybolt3> ty!
[17:47] <Nils[m]> done
[17:47] <AaronRainbolt[m4> ⚠🚨⚠ IRC BRIDGING SETUP IN PROGRESS 🚨⚠🚨
[17:47] <arraybolt3> hey!
[17:47] <AaronRainbolt[m4> hah, nice!
[17:47] <ravage__> yay
[17:47] <AaronRainbolt[m4> test
[17:47] <AaronRainbolt[m4> hmm, doesn't propagate myroomnick changes
[17:47] <Nils[m]> you can only have one irc nick
[17:47] <AaronRainbolt[m4> lemme try the nuclear solution
[17:48] <Nils[m]> you can use !nick
[17:48] <Nils[m]> on the bots DM
[17:48] <AaronRainbolt[m4> ah ok
[17:48] <Nils[m]> see !help for all commands
[17:48] <arraybolt3> fantastic
[17:49] <AaronRainbolt[m4> ...
[17:49] <AaronRainbolt[m4> right, so the matrix and IRC nicks are entirely disconnected, that makes sense
[17:49] <AaronRainbolt[m4> also it takes time an eternity to do a name change everywhere, now we know
[17:50] <Nils[m]> i think that m4 is also a typo
[17:50] <Nils[m]> it should be [m]
[17:50] <Nils[m]> but they can fix that soon
[17:51] <arraybolt3> um, I see another bug on this end
[17:52] <tsimonq2> Very nice :)
[17:52]  * AaronRainbolt[m4 uploaded an image: (11KiB) < http://localhost:8008/_matrix/media/v3/download/ubuntu.com/MvrvxKqgVGASmNrQpoeCbKaK/Screenshot_20240501_125210.png >
[17:52] <Nils[m]> thats  a known issue
[17:52] <Nils[m]> they need to fix that config setting
[17:52] <AaronRainbolt[m4> ah ok
[17:52] <Nils[m]> see the irc bridge matrix room
[17:53]  * teward yawns
[17:53] <AaronRainbolt[m4> yep
[17:53] <SimonQuigley[m]> Also hmm tsimonq2
[17:53] <SimonQuigley[m]> Do IRC uses leave the Matrix room once they leave the channel?
[17:54] <arraybolt3> aaand with that I surrendered my op privs here :face_palm:
[17:54] <tsimonq2> Ah okay nice it removes the @ :)
[17:54] <arraybolt3> but whatever, it seems to work
[17:54] <AaronRainbolt[m4> the issue I was pointing out earlier was emoji weirdness
[17:55] <AaronRainbolt[m4> but that may have just been a problem with my particular combination of terminal + tmux + SSH + IRC client.
[17:55] <ravage__> you should set a better irc nick aaron :D
[17:55] <arraybolt3> kk :P
[17:55] <Nils[m]> will continue here. only on hextchat to see the "real" irc side
[17:56]  * AaronRainbolt[m4 uploaded an image: (17KiB) < http://localhost:8008/_matrix/media/v3/download/ubuntu.com/EdSDIRsvQjmUhqToyUkPSOxJ/Screenshot_20240501_125628.png >
[17:56] <AaronRainbolt[m4> hmm...
[17:57] <Nils[m]> that in interesting. no idea how you got that strange nick in the first place
[17:57] <Nils[m]> you could try a reconnect
[17:57] <teward> theoretically
[17:57] <Nils[m]> and see if you can change it then
[17:57] <teward> you can change the nick you show via Matrix bridge here
[17:58] <teward> it might require changing in their user settings @ the bridge side
[17:58] <teward> depending on the bridge software
[17:58] <teward> *remembers this from the ancient Libera bridge that was terminated*
[17:58] <Nils[m]> it is the same software
[17:58] <Nils[m]> but the !nick command should just work really
[17:58] <arraybolt3> oh now it worked
[17:58] <arrayboltMatrix> that did it
[17:59] <Nils[m]> nice
[17:59] <wxl> oh hai
[17:59] <arrayboltMatrix> heya
[17:59] <SimonQuigley[m]> Who am I sending this !nick to?
[17:59] <wxl[m]> Neat
[17:59] <arrayboltMatrix> I think what's happening is the [m] is getting parsed as a command.
[17:59] <ravage__> we could have a little bot war here now with ubottu
[17:59] <arrayboltMatrix> SimonQuigley[m]: You should see an invite to the IRC bot user.
[18:00] <SimonQuigley[m]> ravage__: Just wait until the return of lugito :P
[18:00] <arraybolt3> !pro
[18:00] -Ubottu[m]:#lubuntu-devel- Ubuntu Pro (https://ubuntu.com/pro) provides extra security fixes for software in the Ubuntu archive. It is free for both personal and business use for up to five desktop machines. Without it, you will continue to receive normal Ubuntu updates.
[18:00] <SimonQuigley[m]> hahahahahaha
[18:00] <Roberalz[m]> Jajajjajaja
[18:00] <Nils[m]> i think you can just decide on one
[18:01] <Nils[m]> i do not care which one really atm 🙂
[18:01] <AaronRainbolt> maybe the [m] isn't getting parsed weird. It just keeps "whois request timed out" every time I try.
[18:02] <ravage__> never had a problem with that before
[18:02] <AaronRainbolt> oh, you know what, I know why.
[18:02] <wxl[m]> This is why I changed my display name to my nick a while back
[18:02] <AaronRainbolt> There's a user called AaronRainbolt[M] from my presence in the KDE rooms.
[18:02] <wxl[m]> Also IRC doesn’t play well with Unicode
[18:02] <ravage__> oh ok thats not ideal
[18:03] <ravage__> we already dicussed if we should use something else
[18:03] <ravage__> but no decision yet
[18:03] <AaronRainbolt> the circled "m" you suggested doesn't work on IRC it seems.
[18:03] <AaronRainbolt> I tried it and got told it had illegal characters
[18:03] <wxl[m]> wxl[m]: This
[18:04] <tsimonq2[m]> I think we should go with the Matrix ubottu and kick out the IRC one - it gives a nice, clean notice on IRC
[18:04] <nils[m]> maybe someone can mute the IRC one. thats a little nicer than a kick
[18:05] <tsimonq2[m]> Works for me
[18:05] <tsimonq2[m]> Who has mod powers IRC-side again? :P
[18:05] <nils[m]> aaron said he has 😄
[18:06] <tsimonq2> Not anymore :P
[18:06] <arraybolt3> teward: HALP
[18:06] <arraybolt3> yeah I forgot those powers are transient when I left the room :facepalm:
[18:06] <teward> you have chanserv +o use it
[18:06] <teward> learn to use your flags :P
[18:06] <arraybolt3> I have them permanently?
[18:06] <arraybolt3> I thought it was a temporary thing :P
[18:06] <teward> until me or IRCC remove it :P
[18:07] <teward> (stay on me and simon's good side and you won't lose em xD0
[18:07] <teward> *grumpily hisses at a Windows server*
[18:07] <arraybolt3> hey, it works!
[18:08] <arraybolt3> tsimonq2: ok yes you were saying
[18:08] <AaronRainbolt> teward: My condolances.
[18:08] <arraybolt3> lol that looks so out of context on the IRC side - that was re: the windows server
[18:09] <teward> :P
[18:09] <nils[m]> edit a message. i like how they "solved" that 🙂
[18:09] <wxl[m]> Hey Chris Guiver when you get a chance can you take a look at [this post](https://discourse.lubuntu.me/t/dual-screen-setup-settings-not-remembered-24-04-lts/4863) on Discourse? I know you regularly use multi monitor set ups so this is likely an ideal job for you
[18:10] <tsimonq2[m]> how does someone get muted on IRC again?
[18:10] <nils[m]> good question
[18:10] <wxl[m]> Uhhhh
[18:10] <tsimonq2> teward: hi yes how do we do this ubottu muting again?
[18:10] <arraybolt3> hmph
[18:10] <arraybolt3> lemme figure it out
[18:10] <nils[m]> looks like /msg chanserv quiet ?
[18:10] <arraybolt3> probably just a flag of some sort
[18:10] <tsimonq2> ok :)
[18:11] <wxl[m]> +b
[18:11] <nils[m]> or just mode +q
[18:11] <nils[m]> should do it too. thats not permanent
[18:11] <teward> /mode #channel +q NICK!IDENT@HOST#GECOS
[18:11] <teward> who do we need to squish
[18:11] <tsimonq2> ubottu itself
[18:11] <tsimonq2> here
[18:12] <arraybolt3> that seems to have done it
[18:12] <arraybolt3> that was the Matrix side one
[18:12] <teward> ye but it's flaky xD
[18:12] <teward> whatever
[18:12] <arraybolt3> for some reason /msg chanserv quiet was unauthorized on this end
[18:12] <arraybolt3> but the flags worked
[18:12] <teward> yeah you have +o not +* on all the flags.  quiet requires extra flags
[18:12] <wxl[m]> q is permanent but unlikely b allows the user to join the channel
[18:12] <tsimonq2[m]> !help
[18:12] <teward> wxl[m]: might cause problems on the bridge if we're not careful but we can refine things later
[18:12] <AaronRainbolt> that's not a great one to use
[18:12] <teward> i nieed more caffeine
[18:13] <wxl> !help
[18:13] <AaronRainbolt> because !help doesn't exist on the Matrix side yet
[18:13] <nils[m]> then we need to kick the matrix one
[18:13] <tsimonq2[m]> can we mute the IRC one instead of the Matrix maybe?
[18:13] <AaronRainbolt> or ever
[18:13] <nils[m]> it will still answer here
[18:13] <AaronRainbolt> sure
[18:13] <tsimonq2[m]> er other way around
[18:13] <wxl> uh oh
[18:13] <wxl> didn't work
[18:13] <arraybolt3> !pro
[18:13] -Ubottu[m]:#lubuntu-devel- Ubuntu Pro (https://ubuntu.com/pro) provides extra security fixes for software in the Ubuntu archive. It is free for both personal and business use for up to five desktop machines. Without it, you will continue to receive normal Ubuntu updates.
[18:13] <arraybolt3> tada
[18:13] <nils[m]> that worked
[18:13] <tsimonq2[m]> perfect
[18:13] <wxl[m]> But not IRC
[18:13] <wxl> !pro
[18:13] -Ubottu[m]:#lubuntu-devel- Ubuntu Pro (https://ubuntu.com/pro) provides extra security fixes for software in the Ubuntu archive. It is free for both personal and business use for up to five desktop machines. Without it, you will continue to receive normal Ubuntu updates.
[18:13] <arraybolt3> the IRC side bot is now muted, only the Matrix side is enabled.
[18:14] <wxl> oh well it  didn't
[18:14] <wxl> !help
[18:14] <AaronRainbolt> You're seeing the Matrix side one.
[18:14] <tsimonq2[m]> wxl @libera_wxl:chat.staging.ubuntu.com: do you have notices disabled?
[18:14] <AaronRainbolt> !help isn't defined matrix-side.
[18:14] <wxl[m]> That’s the issue
[18:14] <AaronRainbolt> !pro is.
[18:14] -Ubottu[m]:#lubuntu-devel- Ubuntu Pro (https://ubuntu.com/pro) provides extra security fixes for software in the Ubuntu archive. It is free for both personal and business use for up to five desktop machines. Without it, you will continue to receive normal Ubuntu updates.
[18:14] <nils[m]> !ubottu
[18:14] -Ubottu[m]:#lubuntu-devel- I am the Ubuntu help bot. You can find information about my code and commands here (https://git.buechner.me/nbuechner/ubottu)
[18:14] <wxl[m]> Well good because that’s the only one that matters 🤣
[18:14] <tsimonq2[m]> ahhhh I see I like it
[18:14] <AaronRainbolt> haha
[18:15] <AaronRainbolt> I have the login to the bot for adding new factoids as we want. The Ubuntu Matrix Council however wasn't really a fan of some of the more newcomer off-putting ones like !help and !patience, so we haven't added those yet and hope to not have to.
[18:15] <nils[m]> a lot of them were just very old and outdated. sometimes borderline rude
[18:16] <nils[m]> im sure we can do better
[18:16] <wxl[m]> !goaway
[18:16] <wxl[m]> See that one is missing too
[18:16] <arraybolt3> now if we want the Matrix-side one muted instead, we can unmute the IRC ubottu and then on the Matrix side re... lol... set the power level of the Matrix side one lower.
[18:16] <tsimonq2[m]> https://git.buechner.me/nbuechner/ubottu/src/branch/main/ubottu/bot.py#L266 that should use distro-info-data and the host should keep the archive distro-info-data up to date instead of hardcoding ;)
[18:16] <nils[m]> i can create an account for you
[18:16] <nils[m]> plan is to move it to github soon
[18:17] <tsimonq2[m]> Sounds good :)
[18:17] <tsimonq2[m]> nils[m]: Might just wait for this actually
[18:17] <nils[m]> im note even sure i wrote that line myself
[18:17] <nils[m]> i did a lot of c&p from the original bot
[18:17] <wxl[m]> If anyone uses samba please go help [here](https://www.reddit.com/r/Lubuntu/s/673UuJ9ZMw)
[18:17] <arraybolt3> I don't use it
[18:18] <nils[m]> oh right. now i know why
[18:18] <nils[m]> i only read the package lists of those atm
[18:18] <nils[m]> to be expanded 🙂
[18:19] <arraybolt3> so ok, I think this was definitely a successful experiment.
[18:19] <arraybolt3> Shall we get Eickmeyer in on the fun now since he wanted to be part of early access testing also?
[18:19] <teward> yo Eickmeyer wake the hell up and join in the evilchaos.  also give coffee.
[18:20] <teward> unless genii does firstg.
[18:20] <teward> first*
[18:20] <AaronRainbolt> Erich Eickmeyer: pinging from all directions
[18:20] <nils[m]> just a warning that i did not get confirmation that the config will be 1:1 copied from staging to stable yet 🙂
[18:20] <AaronRainbolt> IRC bridging party
[18:20]  * genii slides teward towards the coffeepot
[18:20] <AaronRainbolt> nils[m]: understandable, we'll have more fun hooking up the production instance I'm sure :)
[18:21] <wxl[m]> Long time no see genii
[18:21]  * teward absorbs the coffeepot and the coffee inside. Now he needs more
[18:21] <teward> genii has 'coffee' as a ping still xD
[18:21] <AaronRainbolt> I see him every so often. Just mention anything caffeinated and he appears out of nowhere
[18:21] <genii> hehe yes
[18:21] <teward> he's the coffee dealer xD
[18:21] <Eickmeyer> So uh... I'm just out here working on my moving responsibilities and stuff when all the sudden I see pings. So uh... ?
[18:22]  * wxl[m] guzzles maté
[18:22] <arraybolt3> Eickmeyer: The IRC bridge just came into existence.
[18:22] <wxl[m]> Jeez Erich killjoy much?
[18:22] <ErichEickmeyer[m> Oh. Bridging. Fun.
[18:22] <AaronRainbolt> lol, hey, people have lives, including Ubuntu devs
[18:22] <ErichEickmeyer[m> It's a little... slow.
[18:23] <AaronRainbolt> not horribly on my end?
[18:23] <arraybolt3> it has like a second or so of lag right now
[18:23] <arraybolt3> sometimes not even that
[18:23] <wxl[m]> It’s faster than the old bridging from freenode from what I can tell
[18:23] <ErichEickmeyer[m> Probably because it had to create a client for me.
[18:23] <nils[m]> yes you join on the first message
[18:23] <AaronRainbolt> ah
[18:23] <nils[m]> that takes a moment
[18:24] <AaronRainbolt> that makes sense, it did seem a bit slow when I first started.
[18:24] <nils[m]> i think a reverse dns for that IP would be nice
[18:24] <nils[m]> also we wait for ipv6 to be enabled in the future
[18:25] <nils[m]> so every user gets its own ip
[18:29] <AaronRainbolt> alright, bridging is set up satisfactorily it looks like, I'mma de-op on IRC side and then go back to building a Qt6 component.
[18:29] <teward> *burps*
[18:29] <arraybolt3> ah, that'll work too
[18:29] <arraybolt3> I was mid-typing the command :P
[18:30]  * teward is faster
[18:30] <arraybolt3> evidently!
[18:45] <tsimonq2[m]> Aaron Rainbolt: oi I think copying is done
[18:45] <AaronRainbolt> it is indeed, I'm fighting with squid-deb-proxy here
[18:46] <AaronRainbolt> I'm certain the build is going to be faster locally than remotely so I'm trying to get all my ducks in a row over here
[18:47] <AaronRainbolt> One of the stack of dream projects I have is a single downloadable "packaging portal" that you just download, unpack, run, and it gives you a VM to do your packaging and development work in, pre-configured to work right.
[18:47] <AaronRainbolt> Can't hardly find breathing room for new projects that aren't critical, but that's another thing I'd like to do.
[18:48] <tsimonq2[m]> AaronRainbolt: We have similar ideas heh
[18:49] <AaronRainbolt> Something with sbuild, eatmydata, ccache, squid-deb-proxy, and chroots / mk-sbuilds all ready to go
[18:49] <tsimonq2[m]> Did you see the conversation I had with juliank yesterday in #ubuntu-devel?
[18:49] <AaronRainbolt> The base can be the latest Ubuntu LTS, and it can have various lightweight chroots for running debuild since the distro you debuild with can determine whether the build works or not (sometimes latest dev edition isn't the right one)
[18:49] <AaronRainbolt> tsimonq2[m]: I did not.
[18:49] <tsimonq2[m]> AaronRainbolt: Go take a peek :)
[18:49] <tsimonq2[m]> (When able)
[18:49] <AaronRainbolt> difficult, IRC client scrollback is missing
[18:50] <AaronRainbolt> peeks in logs
[18:50] <tsimonq2[m]> https://irclogs.ubuntu.com/2024/04/30/%23ubuntu-devel.html#t18:30
[18:51] <AaronRainbolt> ah that's neat
[18:51] <AaronRainbolt> the thing I've noticed though is that sometimes the host system's environment can mess with sbuild.
[18:52] <AaronRainbolt> For instance if you're dealing with a CDBS package (yes, they still exist), you have to use Ubuntu 20.04 as your host, latest dev edition won't work.
[18:52] <AaronRainbolt> But if you're dealing with a sufficiently new package, you can't use Ubuntu 20.04 or 22.04 or whatever as your host, you need the latest dev edition.
[18:52] <AaronRainbolt> So something that allows you to run the debuild step in a chroot of some sort would be really nice.
[18:55] <tsimonq2[m]> AaronRainbolt: These are rare but they do still exist heh
[18:56] <tsimonq2[m]> AaronRainbolt: It really does depend on your setup; I always use the latest development release so this doesn't really affect me :P
[18:56] <AaronRainbolt> That's true, but I've had the CDBS crud eat my face off before and had to go spin up a 20.04 VM for it :-/
[18:58] <tsimonq2[m]> Ancient build systems sometimes require ancient host systems :P
[18:58]  * tsimonq2[m] runs
[18:59] <tsimonq2[m]> Aaron Rainbolt: mitya57 just requested we update qt6-base to -6~1
[19:00] <AaronRainbolt> so basically we have to restart the bootstrap
[19:00] <tsimonq2[m]> Yep, wanna be in the driver's seat? Fairly easy process compared to some of the stuff we've went through heh
[19:01] <arraybolt3> sure thing
[19:02] <tsimonq2[m]> First step is to get the -6 revision from experimental. Not sure if LP has picked it up yet (pull-debian-source qt6-base experimental) - if not, take a look at the pool in incoming.debian.org
[19:04] <teward> tsimonq2[m] you're hereby conscripted to see if debian-keyring has an update yet
[19:04] <teward> if not i'mma go to war
[19:04] <tsimonq2[m]> After that, I've been just editing the existing changelog entry to have the ~1 suffix, setting it to UNRELEASED, then doing dch -r to get my name in the changelog - makes it clear I hold responsibility for the upload.
[19:04] <tsimonq2[m]> Lmk when you're there
[19:04] <tsimonq2[m]> teward: https://tracker.debian.org/news/1520081/accepted-debian-keyring-20240324-source-into-unstable/
[19:04] <AaronRainbolt> will do
[19:05] <AaronRainbolt> -6 is in experimental 🎉
[19:08] <tsimonq2[m]> Thomas Ward: I hereby conscript you to go look at Council in Matrix :P
[19:08] <teward> @tsimonq2[m] I hereby conscript you to rerun those dcut commands I sent you an eon ago to get my upload rights back for some package
[19:08] <teward> packages*
[19:08] <tsimonq2[m]> 🫡
[19:10] <tsimonq2[m]> Aaron Rainbolt: Once the changelog is good, you'll need to go disable the doc packages. They're at the bottom of d/control - you can simply comment them out. Also need to comment out Build-Depends-Indep
[19:11] <tsimonq2[m]> And actually if you want to see what changes I made for bootstrapping exactly, just debdiff -5 and -5~1
[19:11] <tsimonq2[m]> Basically just making a bunch of stuff comments XD
[19:11] <wxl[m]> Ok so we have products on Teespring again. Who wants to add that to the slideshow?
[19:11] <AaronRainbolt> I also disabled everything doc-related in d/rules
[19:11] <AaronRainbolt> since our master doc said to do that
[19:12] <tsimonq2[m]> correct :)
[19:12] <AaronRainbolt> so ok, local build, if that's good then lots of throwing things at the PPA blindly
[19:12] <tsimonq2[m]> wxl[m]: Design channel for better eyes?
[19:12] <wxl[m]> Ok
[19:13] <tsimonq2[m]> AaronRainbolt: any chance I could spot check the diff between -6 and -6~1 ? It can save us an hour :P
[19:13] <AaronRainbolt> sure :)
[19:13] <AaronRainbolt> one sec...
[19:17] <AaronRainbolt> Simon Quigley: https://termbin.com/fwmt
[19:17] <tsimonq2[m]> s/noble/oracular/ in the changelog
[19:18] <AaronRainbolt> ah great
[19:18] <AaronRainbolt> thankfully I'm building with an oracular chroot so it should still work
[19:18] <AaronRainbolt> but the upload itself will need that fixed
[19:19] <tsimonq2[m]> -		-DINSTALL_DOCDIR=share/qt6/doc \
[19:19] <tsimonq2[m]> +		# -DINSTALL_DOCDIR=share/qt6/doc
[19:19] <tsimonq2[m]> This isn't needed, the config value exists to provide a location for docs *if* they are installed, otherwise they're installed to a different location
[19:20] <tsimonq2[m]> Otherwise LGTM - send it at thr PPA :)
[19:20] <tsimonq2[m]> s/thr/the/
[19:20] <tsimonq2[m]> If it passes, cool go ahead and upload as-is to oracular, plus now we have binaries to work with
[19:20] <tsimonq2[m]> If it fails, cool, now we all know at the same time
[19:21] <AaronRainbolt> awesome
[19:22] <tsimonq2[m]> Rationale for skipping the local build is that it takes an hour to build, on fast hardware... some of them are smaller though, like the entire next layer takes maybe 5 mins a pop to build
[19:22]  * AaronRainbolt sent a code block: http://localhost:8008/_matrix/media/v3/download/chat.staging.ubuntu.com/OaRuMBzNDfAzkieUPsBtgZZu
[19:22] <AaronRainbolt> something about a missing sqlite3.c???
[19:22] <teward> (we really need to fix that link problem)
[19:23] <ThomasWard[m]> AaronRainbolt: did you install the corresponding Qt libraries for it at builddeps?
[19:23] <ThomasWard[m]> tsimonq2[m]: define "fast hardware" xD
[19:23] <ThomasWard[m]> sits here with an entire server farm at his fingertips
[19:23] <AaronRainbolt> ThomasWard[m]: I better have, I didn't change the non-independent deps!
[19:24] <tsimonq2[m]> AaronRainbolt: Do you still have that one entry commented out in debian/rules?
[19:24] <AaronRainbolt> I do
[19:24] <AaronRainbolt> lemme try fixing it
[19:24] <tsimonq2[m]> my theory is, that'll fix it
[19:24] <tsimonq2[m]> If it at least gets past cmake, I'd say throw it at the PPA ;)
[19:31] <AaronRainbolt> kk
[19:31] <AaronRainbolt> it does not!
[19:32] <tsimonq2[m]> How are you building this package exactly?
[19:32] <tsimonq2[m]> At this point I'd say it really comes down to build deps
[19:32] <teward> may I ask which package/component this is?
[19:33] <AaronRainbolt> teward: qt6-base
[19:34] <tsimonq2[m]> https://salsa.debian.org/qt-kde-team/qt6/qt6-base/-/blob/experimental/debian/control?ref_type=heads#L39
[19:34] <tsimonq2[m]> sqlite3 is explicitly a build dep
[19:34] <AaronRainbolt> tsimonq2[m]: `sbuild --extra-repository="deb https://ppa.launchpadcontent.net/lubuntu-dev/oracular-qt-bootstrap/ubuntu oracular main" --extra-repository-key=/tmp/myrepo.asc -d oracular-amd64-shm`
[19:34] <tsimonq2[m]> AaronRainbolt: Can I get a full build log?
[19:35] <AaronRainbolt> tsimonq2[m]: https://termbin.com/3okx
[19:35] <ThomasWard[m]> tsimonq2[m]: but are we sure that it's actually including the **core code** because the build log suggests `../../../3rdparty/sqlite/sqlite3.c` and NOT the libsqlite3 ldd linked versions unless that sqlite3.c is linked somewhere
[19:35] <tsimonq2[m]> AaronRainbolt: You sure that's the right one? :P
[19:35] <ThomasWard[m]> i wonder if the 'sqlite3.c' it's referring to is supposed to be part of qt6 core/base/tarball and it's not
[19:35] <AaronRainbolt> tsimonq2[m]: um... seems to be a glitch
[19:35] <AaronRainbolt> oh my word, yes, that's the right one
[19:35] <AaronRainbolt> 🤦
[19:35] <AaronRainbolt> ok, so!
[19:36]  * ThomasWard[m] helps Aaron facedesk hard
[19:36] <AaronRainbolt> (╯°□°）╯︵ ┻━┻
[19:36] <AaronRainbolt> why can't you just live without the GPG key?!
[19:36] <tsimonq2[m]> AaronRainbolt: it can wanna know how?
[19:36] <AaronRainbolt> oh I know how, [trusted=yes] but I'm paranoid of that option
[19:37] <AaronRainbolt> then again I am accessing the PPA over https so it is a viable option
[19:37] <AaronRainbolt> anyway I got the key downloaded already so, trying again.
[19:39] <AaronRainbolt> ThomasWard[m]: perhaps. Right now it has a build depends on libsqlite3-dev though so I would expect it to work, though maybe it's trying to statically link the sqlite amalgamation
[19:39] <AaronRainbolt> er, more like statically compile in but whatever
[19:39] <AaronRainbolt> actually src/3rdparty/sqlite is specifically excluded from the tarball according to debian/copyright
[19:39] <AaronRainbolt> so it must be doing something to get the right part linked in...
[19:40] <ThomasWard[m]> and now you know why it's failing to find the dependencies at build time since it's excluded from the tarball.  time to deep dive on that :p
[19:40] <AaronRainbolt> maybe it was that one commented line, I see -DFEATURE_system_sqlite=ON in the rules file
[19:40] <AaronRainbolt> so maybe my comment broke the whole thing
[19:42] <AaronRainbolt> yep, it made it this time
[19:42] <AaronRainbolt> alright, PPA upload time
[19:43] <ThomasWard[m]> glad we figured that one out xd
[19:43] <ThomasWard[m]> s/xd/xD/
[19:43] <AaronRainbolt> thanks Vim highlighting for throwing me off
 "so it must be doing something to..." <- Yes, it's best practice to dynamically link instead of statically link when uploading to Debian, especially if the library already exists
[19:48] <tsimonq2[m]> When packaging new software that's something I always heard from my sponsors... check for other software within the tarball as such and set it to dynamically link to what is in the archive
[19:49] <tsimonq2[m]> Actually this flag right here: https://salsa.debian.org/qt-kde-team/qt6/qt6-base/-/blob/experimental/debian/rules?ref_type=heads#L82
[19:50] <tsimonq2[m]> So looking for the vendored SQLite3 source in the tarball was a red herring ;)
[19:50] <tsimonq2[m]> Anyway, Aaron Rainbolt how goes it?
[19:51] <AaronRainbolt> Uploading to the PPA now.
 "sits here with an entire server..." <- hi thanks I'll take an instance with 8 cores, 16 threads, 64 GB RAM, and a 2 TB disk please
[19:52] <AaronRainbolt> upload complete.
[19:55] <tsimonq2[m]> Thanks!
[19:59] <tsimonq2[m]> Aaron Rainbolt: could you upload to oracular if the build passes in the PPA?
[19:59] <AaronRainbolt> sure thing
[20:00] <AaronRainbolt> @room If anyone missed the XApp room notification someone posted in Ubuntu Flavors or some such recently, go find it and join it, it looks like it could be very useful to us.
[20:00] <AaronRainbolt> Jeremy Bicha: "https://blog.linuxmint.com/?p=4675 < scroll ahead to the Xapp part since that work could help theming for several desktop flavors"
[20:01] <AaronRainbolt> It looks like an initiative to make applications that work cross-desktop rather than being bound to any one particular desktop, in an effort to help all desktops have good working apps.
[20:01] <AaronRainbolt> GTK is losing important features at the moment so there's some discussion about potential exit routes.
[20:02] <AaronRainbolt> https://matrix.to/#/#xapp:matrix.org
[20:13] <AaronRainbolt> gah, I forgot to enable other architectues beyond amd64!!!
[20:13] <AaronRainbolt> Gosh. Now I get to delete the whole PPA and try again.
[20:13] <AaronRainbolt> face_desk_no3
[20:17] <tsimonq2[m]> AaronRainbolt: That's building for other arches, publishing was enabled it looks like
[20:17] <tsimonq2[m]> (Meaning, the binaries for other arches seem to have published from a copy)
[20:17] <tsimonq2[m]> Anyway, it's qt6-base, I wouldn't worry about the re-copy finishing before re-uploading :)
[20:18] <AaronRainbolt> kk
[20:18] <AaronRainbolt> sorry about that
[20:19] <tsimonq2[m]> No problem, I've done that before heh
[20:22] <AaronRainbolt> alright, it's churning away correctly now
[20:23] <tsimonq2[m]> Aaron Rainbolt: so the three packages on the next level won't need followups in oracular, unless they decide to reject those for whatever reason
[20:23] <tsimonq2[m]> That being said, feel free to follow the bootstrapping process for the next three. If you're confident, go ahead and upload to the PPA. If you'd like to do a build test, you could wait for the PPA to finish publishing... or you could just grab the debs :P
[20:23] <AaronRainbolt> there's no risk of incompatibilities stemming from not bootstrapping the next three? One soname changed in qt6-base.
[20:23] <AaronRainbolt> That's what the -6 upload did.
[20:24] <AaronRainbolt> adding a t64 to a library
[20:24] <AaronRainbolt> might have been name-only and not ABI, but I'm not sure
[20:24] <tsimonq2[m]> AaronRainbolt: The other three are already in the oracular queue but haven't been accepted yet, which means unless the upload need modifications, they're good
[20:25] <tsimonq2[m]> AaronRainbolt: You're prob not wrong - yeah maybe do a simple build test?
[20:26] <AaronRainbolt> kk
[20:26] <tsimonq2[m]> * The other three are already in the oracular queue but haven't been accepted yet, which means unless the uploads need modifications, they're good
[20:29] <tsimonq2[m]> Aaron Rainbolt: hmm on second thought, don't the Qt reverse dependencies actually have the -dev package as a build dep?
[20:29] <AaronRainbolt> dunno yet
[20:29] <tsimonq2[m]> The -dev package hasn't changed in name, its dependencies have though
[20:29] <AaronRainbolt> still soname bumps can oftentimes mandate NCRs, no?
[20:29] <AaronRainbolt> Installing a -dev package also pulls in the corresponding library binary.
 "It looks like an initiative to..." <- is there a repo or something somewhere where someone could get more clarity?
[20:31] <AaronRainbolt> Not really, right now it's more of a discussion about how to do things. Apparently a lot of the Linux Mint apps are so-called "XApps" though.
[20:32] <tsimonq2[m]> AaronRainbolt: The bootstrap for those three result in rebuilds regardless :)
[20:32] <tsimonq2[m]> What I'm saying is, the PPA does need the three bootstrapped, yes, but the archive queue doesn't need duplicate uploads if no changes are required
[20:32] <AaronRainbolt> ahhhh ok.
[20:32] <tsimonq2[m]> Yeah, sorry for not being clearer
[20:35] <wxl[m]> so with regards to the IRC bridge, should we now consider the development channel permanently set up or do we expect another iteration? (perhaps not being on staging?)
[20:36] <nils[m]> Everything will break one more time
[20:36] <nils[m]> But bridging it again is one command so it's not a big deal
[20:37] <nils[m]> And I think the plan is to shut down staging and spin up production
[20:37] <nils[m]> So there should not be a big gap
[20:50] <wxl[m]> Nils: nice. should we bother bridging our other channels now then or just wait?
[20:53] <nils[m]> I would just wait
[20:53] <wxl[m]> makes sense
[20:54] <nils[m]> If we don't run in any big problems I think we can make the switch next week
[20:54] <wxl[m]> ooh exciting
[20:54] <nils[m]> They rolled out some more features with the bridge
[20:54] <wxl[m]> now i can move all my carefully monitored irc channels to a window i don't monitor very much :)
[20:54] <nils[m]> But I haven't heard about any problems with that yet
[20:55] <wxl[m]> and to be clear, we're bridging specific channels not the entirety of libera, right? so, for example, i'll still have to watch #ubuntu-release on IRC
[20:56] <nils[m]> We bridge specific rooms. Release would be something we could actually bridge
[20:56] <nils[m]> Ubotto and queuebot should be almost feature complete on matrix
[20:57] <nils[m]> So we could do the mute thing again and see how it goes
[20:57] <wxl[m]> is the intention that we bridge ALL of the ubuntu IRC channels or is that decided on a case by case basis by the heads of each channel?
[20:57] <nils[m]> But I haven't talked to any of the ops in there yet
[20:57] <nils[m]> We have a list of the top 20 or so to start with
[20:57] <nils[m]> And we would prefer not to bridge rooms with 4 people in jt
[20:58] <wxl[m]> makes sense :)
[20:58] <nils[m]> Maybe it is time to move to matrix for them
[20:58] <nils[m]> Or rot on IRC :D
[20:59] <nils[m]> And only official Ubuntu rooms will be bridged. So only #ubuntu-*
[21:00] <nils[m]> Another condition is that at least someone from that irc room is to have a look at the matrix side of things too
[21:00] <nils[m]> * room is willing to have
[21:01] <wxl[m]> you mean only #buntu
[21:01] <nils[m]> Yes sorry
[21:01] <wxl[m]> s/#/\#\*/, s//\*/
[21:01] <wxl[m]> sheesh i can matrix
[21:02] <wxl[m]> wow this is so exciting
[21:02] <nils[m]> Mint will ship a matrix client with their next release
[21:02] <nils[m]> And drop hexchat
[21:02] <wxl[m]> how many years ago was it that we used the freenode bridge to get us on matrix? and Simon Quigley thought it wouldn't stick (of course he was a heavy telegram user then)
[21:03] <wxl[m]> wow nice
[21:03] <nils[m]> I liked the old Bridge
[21:04] <nils[m]> I think is was a mix of bad maintenance and politics that causes the problems
[21:04] <nils[m]> Also a general bridge for all rooms is really hard to manage
[21:04] <wxl[m]> i liked it, too, at least from the perspective of easily being able to self-bridge things but i suspect it was a nightmare to manage
[21:05] <wxl[m]> and performance sucked bad
[21:05] <nils[m]> I have been running my own bridge for the last 3 months or so
[21:05] <nils[m]> I really like it
[21:05] <nils[m]> Already removed hexchat
[21:06] <nils[m]> And I can join all rooms with that
[21:06] <nils[m]> But it's limited to my homeserver
[21:07]  * nils[m] uploaded an image: (199KiB) < http://localhost:8008/_matrix/media/v3/download/xentonix.net/HGLcfdUNlmCDBtBtXVeKZGPp/1000008158.jpg >
[21:08] <nils[m]> Already have some of the bigger rooms in there
[21:13] <nils[m]> From the irc side that picture is still not available. Hope they fix the config soon :)
[21:22] <wxl[m]> I'm sure I could run my own homeserver but I'm pretty convinced that's not as simple as I would prefer. I mean, I don't think I'd run my own Mastodon instance for the same reason.
[21:24] <nils[m]> Not everyone needs his own homeserver for sure
[21:25] <nils[m]> And mastodon does not work that great with only one user
[21:25] <nils[m]> It's a little difficult to get the federation going then
[21:27] <nils[m]> In case anyone wants to try a bridge to WhatsApp telegram or signal let me know
[21:27] <nils[m]> Discord too
[21:27] <nils[m]> I can whitelist users on my bridges
[22:47] <tsimonq2[m]> Aaron Rainbolt: still around by chance?
[22:47] <AaronRainbolt> yep
[22:47] <AaronRainbolt> currently doing quite a bit of dayjob work
[22:47] <tsimonq2[m]> looks like we're just waiting on riscv64 - I think we should be okay to upload qt6-base to the oracular queue?
[22:47] <tsimonq2[m]> if you're busy I can jump in
[22:48] <AaronRainbolt> nah I can do it
[22:48] <AaronRainbolt> Um.
[22:48] <AaronRainbolt> arraybolt3@kf-XE:~/Public$ dput -f oracular ./qt6-base_6.6.2+dfsg-6~1_source.changes
[22:48] <AaronRainbolt> No host oracular found in config.
[22:48] <tsimonq2[m]> cool sounds good :)
[22:49] <tsimonq2[m]> AaronRainbolt: > <@arraybolt3:ubuntu.com> ```... (full message at <http://localhost:8008/_matrix/media/v3/download/chat.staging.ubuntu.com/ogULZhKsWradYdyGqSeTMhhF>)
[22:49] <tsimonq2[m]> or just switch to regular dput from dput-ng :P
[22:51] <AaronRainbolt> bah, I'm tired. It's dput -f ubuntu, not dput -f oracular
[22:52] <tsimonq2[m]> Apparently so am I 😂
[22:52] <tsimonq2[m]> wxl @wxl:ubuntu.com: hi looks like you get to bootstrap Qt
[22:53] <tsimonq2[m]> kthxbai
[22:53] <tsimonq2[m]> 😂
[22:53] <AaronRainbolt> hey, I can do more of it!
[22:53] <wxl[m]> Nice try
[22:53] <tsimonq2[m]> I'm joking, go for it heh
[22:55] <tsimonq2[m]> Aaron Rainbolt: I just synced over the next round of bootstrapping, but qt6-declarative will need a modification so I don't plan on copying that over - that being said, it's the next step once these three have published amd64 binaries
[22:55] <tsimonq2[m]> (which might be in like an hour)
[23:06]  * wxl[m] uploaded an image: (11KiB) < http://localhost:8008/_matrix/media/v3/download/ubuntu.com/DbWADuxpaPxZgEmXFaNaLLGE/image.png >
[23:06] <wxl[m]> ^ note: localhost
[23:46] -queuebot:#lubuntu-devel- Unapproved: accepted lubuntu-artwork [source] (oracular-proposed) [24.10.1]
[23:47] <AaronRainbolt> Looks like vorlon just pushed The Button for making oracular things happen
[23:49] <wxl[m]> no message to ubuntu-devel list yet so now's your chance to upload before the rush!
[23:51] <arraybolt3> it says "active development" in LP now, woohoo!


[00:06] <berto-> jelmer: no luck on figuring out my os x issues.  i'm going to work on it and when i have it working i'll report back.  i gg for now.
[00:06] <berto-> ttyl.
[00:07] <jelmer> ok
[00:07] <jelmer> bye
[00:11] <lifeless> jelmer: I've filed a bug
[00:14] <jelmer> lifeless: k
[00:14] <lifeless> jelmer: the item_keys_introduced_by function is the current failing thing
[00:15] <ToyKeeper> jelmer: I have a working diff panel in bzrk, but I'm not happy with it and I've been too busy to fix it.
[00:15] <jelmer> ToyKeeper: ah, ok
[00:15] <ToyKeeper> jelmer: If you want it, it's at lp:~toykeeper/bzr-gtk/bzr-vis-enhancements
[00:16] <jelmer> ToyKeeper: I'll wait until you're happy with it
[00:16] <beuno> jelmer, lol, I was just about to send the same patch to the list  (minus the tortoise bits that sneaked into your patch)
[00:17] <ToyKeeper> I probably need to fix some things in DiffWidget.  It doesn't like to have its contents changed after it gets displayed.
[00:17] <mbp_> hello all
[00:17] <ToyKeeper> Also, is there any existing way to save preferences, or should I make something up?
[00:19] <jelmer> ToyKeeper: We generally just use the bazaar configuration infrastructure
[00:22] <beuno> mornin' mbp_   (poolie-in-disguise)
[00:22] <lifeless> hi mbp_
[00:26] <jelmer> hi Martin
[00:26] <jelmer> lifeless: I'm a bit confused about the use of iter_lines_added_or_present_in_keys()
[00:27] <lifeless> jelmer: ignore that, look at the top of the frame
[00:27] <jelmer> lifeless: would it be valid to just retrieve those keys' contents and yield their lines one by one?
[00:27] <lifeless> top-frame
[00:27] <jelmer> ahh
[00:31] <lifeless> jelmer: :)
[00:39] <lifeless> bug 243998
[00:39] <lifeless> jelmer: this is by design; perhaps you could enlarge on why it affects you?
[00:48] <jelmer> lifeless: I've got a plugin that registers a post-push hook
[00:49] <jelmer> that hook will push a index.html page (with a quick description of how to check out the branch, and its history) if there is no remote working tree
[01:01] <lifeless> jelmer: nice; you should catch NotLocalUrl
[01:02] <jelmer> lifeless: that's what I'm doing at the moment
[01:03] <jelmer> it does seem like something that the API could handle for me though
[01:03] <jelmer> since it does have enough data to return a proper value
[01:04] <lifeless> jelmer: it sounds like you want 'has_working_tree' or something; thats really a Look-before-you-leap style method though; I'd question its value
[01:04] <jelmer> lifeless: that's what we're talking about here though
[01:04] <jelmer> this function *is* called has_working_tree()
[01:04] <jelmer> it's not open_working_tree() I'm referring to
[01:05] <lifeless> hmm
[01:05] <jelmer> I think it's perfectly sensible for *open_workingtree()* to raise NotLocalUrl if it's a remote URL
[01:12] <baco> Hi, I am trying to run a smart server via inetd with this line «4155  stream  tcp  nowait  baco  /usr/bin/bzr /usr/bin/bzr serve --inet --directory=/srv/bzr/» and when I do telnet to the port I get «bzr: ERROR: unknown command "--inet"»
[01:13] <baco> where is the problem?
[01:16] <mwhudson> lifeless: have you looked at the btrees in the zodb?
[01:16] <mwhudson> (i sort of doubt they're suitable, but probabyl worth a look)
[01:16] <lifeless> mwhudson: I found something that looked like it was that; it uses marshall
[01:16] <lifeless> mwhudson: / pickle
[01:17] <mwhudson> there's a string/string version isn't there?
[01:17] <lifeless> mwhudson: and wants to update - its a disk hash table rather than anything else
[01:17] <mwhudson> yeah, the write-once stuff isn't part of its world
[01:18] <mwhudson> anyway, just a thought
[01:18]  * mwhudson wanders off for a bit
[01:19] <lifeless> mwhudson: http://pypi.python.org/pypi/zc.dict/1.2.1 is what I looked at
[01:19] <lifeless> and http://pypi.python.org/pypi/zope.bforest/1.2
[01:20] <mwhudson> ah, i think i was thinking about bforest and had forgotten a lot of details
[01:21] <lifeless> there is a ZODB.BTrees apparently
[01:21] <lifeless> but I'm having trouble finding it :)
[01:22] <lifeless> (in pypi that is)
[01:23] <lifeless> also there isn't SSBTree, only I or O
[01:24] <lifeless> (as far as I can tell to date)
[01:26]  * lifeless considers running bzr search over zope, so he can find this damn code
[01:27] <lifeless> davidstrauss: how did you go with loggerhead?
[01:28] <davidstrauss> lifeless: haven't tried installing it yet
[01:28] <davidstrauss> lifeless: i'll probably try tomorrow
[01:28] <davidstrauss> lifeless: but thanks for asking
[01:28] <spiv> baco: that's weird, it's like it isn't seeing the 'serve' part of the command line
[01:29] <lifeless> davidstrauss: no probs; I think most people run loggerhead from source, but I may be wrong
[01:29] <baco> spiv: I bet is the inetd server, I am changing it now
[01:32] <baco> spiv: yeah, I was right, is wried anyways, but do not install inetutils-inetd, openbsd-inetd is the one that works
[01:35] <lifeless> mwhudson: yeah, zodb.btrees is not suitable; two reasons - it pickles. and it pickles.
[01:35] <lifeless> mwhudson: oh, and it is mutable, and complex.
[01:36]  * spiv buys lifeless a Pickle-Me-Elmo
[01:36] <lifeless> ewww
[03:42]  * igc lunch
[04:08] <StevenK> lifeless: Continuing from -devel, this is the worrying output:
[04:12] <StevenK> Conflict adding files to libmokoui.  Created directory.
[04:12] <StevenK> Conflict because libmokoui is not versioned, but has versioned children.  Versioned directory.
[04:12] <StevenK> Conflict adding file libmokoui.  Moved existing file to libmokoui.moved.
[04:12] <StevenK> (libmokoui is a directory, so 'Conflict adding file' is worrysome
[04:12] <lifeless> StevenK: you add files to directories
[04:13] <lifeless> StevenK: can you create a new branch of the one you were merging into
[04:13] <lifeless> StevenK: and then repeat the merge from the one you were merging from
[04:13] <lifeless> StevenK: (I want to eliminate the chance of local edits causing issues)
[04:15] <StevenK> lifeless: There were no local edits, same behavior from a fresh branch
[04:16] <lifeless> StevenK: ok, please file a bug
[04:17] <lifeless> StevenK: 'adding files' could be clearer I guess, but something is almost certainly wrong if two well formed branches can't merge in that manner without the error about being unversioned
[04:17] <StevenK> lifeless: I suspect the branches haven't seen each other before, but bzr should be able to merge them
[04:18] <lifeless> StevenK: if they don't have a common parent it would error
[04:19] <StevenK> Can I teach it the common parent? I don't see why it's adding files, either, file lists are the same.
[04:19] <lifeless> StevenK: if they have a common parent, then they've seen each other before :). directories added to both sides should (and appear to have) cause a simple conflict - the 'Conflict because libmokoui is not versioned, but has versioned children.  Versioned directory.' is what is spurious and seems to have propogated
[04:19] <lifeless> StevenK: does it say 'branches have no common parent cannot merge' ?
[04:19] <lifeless> StevenK: or words to that effect?
[04:19] <StevenK> Branches have no common ancestor, and no merge base revision was specified.
[04:19] <StevenK> I suspect I "branched" this using cp
[04:20] <lifeless> StevenK: ok. that says bzr thinks these are entirely separate projects.
[04:20] <lifeless> StevenK: using 'cp' is fine, unless you then bzr init and add and give everything brand new identity
[04:20] <StevenK> I may well have done that, I'm not certain.
[04:21] <lifeless> StevenK: so. you know bzr has an inode concept right? files and directories have identity separate from path.
[04:21] <lifeless> StevenK: 'bzr add' assigns identity to a file/directory
[04:21] <lifeless> StevenK: bzr merge when two files/directories share a path but don't share identity -> conflict
[04:23] <StevenK> Hm. Drat.
[04:23] <lifeless> StevenK: so, every file that is in common between these two separate projects will conflict. This is appropriate - consider two separate projects with different COPYING contents.
[04:23] <lifeless> StevenK: or even the same, but then one changes its mind; we shouldn't consider them to be the same file.
[04:24] <lifeless> StevenK: there is a genuine bug here - the 'Conflict because libmokoui is not versioned, but has versioned children.  Versioned directory.' error is spurious AFAICT
[04:24] <lifeless> StevenK: but you've also, almost certainly, made your life harder by doing 'bzr init' rather than 'bzr branch' at some point in the past.
[04:24] <StevenK> Can I fix that?
[04:25] <lifeless> StevenK: in some senses yes. Essentially, for every common path you need to pick one file id and choose it. That file id will keep its history, the other will show up as deleted at this point
[04:25] <lifeless> StevenK: if there is an upstream/downstream relationship here, you should take the upstreams file ids.
[04:28] <StevenK> lifeless: Okay, so how I pick/change the file ids?
[04:29] <lifeless> StevenK: bzr st *should* show you foo and foo.moved for every conflicting path
[04:29] <lifeless> StevenK: before we go further, can you file a bug with:
[04:29] <lifeless> the two branches
[04:30] <lifeless> the output of 'bzr version-info' in each branch
[04:30] <lifeless> and the output of the merge; I'll clean it up into an actual bug report on the thing I think is going wrong
[04:35] <StevenK> lifeless: Submitted, bug 244115
[04:42] <lifeless> StevenK: thanks
[04:42] <lifeless> StevenK: so
[04:43] <lifeless> StevenK: in your tree right after the merge
[04:43] <lifeless> StevenK: if you do 'bzr diff -r branch:THINGYOUMERGEDFROM'
[04:43] <lifeless> StevenK: we want to keep adjusting your working tree until that diff looks reasonable
[04:43] <lifeless> StevenK: with no delete+add pairs etc
[04:43] <lifeless> StevenK: (assuming the branch you merged from is your 'upstream'.)
[04:44] <lifeless> StevenK: if you are the upstream, we'll use 'bzr diff' to do this test
[04:57] <lifeless> StevenK: ping me when you are back
[05:06] <StevenK> lifeless: I'm back
[05:07] <StevenK> lifeless: I've adjusted the working tree so that the diff looks good already
[05:07] <lifeless> StevenK: right, so does the above make sense?
[05:07] <lifeless> StevenK: against -r branch:, or your local branch?
[05:07] <StevenK> Local
[05:07] <lifeless> StevenK: and which branch has more history ?
[05:08] <StevenK> % bzr di -r branch:../trunk | diffstat | tail -n 1
[05:08] <StevenK>  40 files changed, 5141 insertions(+), 4244 deletions(-)
[05:08] <StevenK> Ah ha
[05:09] <StevenK> lifeless: trunk
[05:09] <StevenK> lifeless: The only changes in the ubuntu branch are under debian/
[05:09] <lifeless> StevenK: try bzr st -r branch:../trunk
[05:09] <StevenK> (trunk has no debian/)
[05:10] <StevenK> lifeless: It has two headings: removed: and added: and both list every file
[05:10] <lifeless> StevenK: right, you've resolve in the wrong direction :)
[05:11] <lifeless> StevenK: can I ask, as you trying to do 'uupdate via merge' ?
[05:12] <StevenK> lifeless: Basically, yes
[05:12] <lifeless> StevenK: so, this is why james_w is working on mass conversions and history joining
[05:14] <lifeless> StevenK: lets get you unblocked - bzr diff -r x..y ../trunk | bzr patch, is likely better
[05:14] <StevenK> x..y being what?
[05:15] <StevenK> Revision numbers, of course, but which?
[05:16] <lifeless> StevenK: well whatever you passed the merge command to make it do something
[05:17] <StevenK> lifeless: I essentially have that on my local branch as it is
[05:26] <lifeless> StevenK: does 'st' show a pending merge ?
[05:31] <StevenK> bzr: ERROR: Revision {('vcs-imports@canonical.com-20080410144539-rrh49m2mt78576ft',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x11ba350>".
[05:31] <lifeless> StevenK: I'd bzr revert and do 'bzr diff -r x..y ../trunk | bzr patch' TBH
[05:32] <StevenK> lifeless: I did
[05:32] <lifeless> StevenK: merging across separate imports is not easy
[05:32] <lifeless> StevenK: if you reverted, then you shouldn't be getting an error
[05:32] <StevenK> lifeless: It was a new branch
[05:34] <lifeless> StevenK: what was it
[05:34] <StevenK> lifeless: Sorry?
[05:35] <lifeless> StevenK: I have no idea what you're talking about anymore, read up and imagine you have only what you've told me to work off :)
[05:36] <StevenK> lifeless: Okay, so I started with a fresh branch using 'bzr branch', and then ran 'bzr di ... | bzr patch'. 'bzr st -r branch:../trunk' gave that error I pasted above.
[05:36] <lifeless> StevenK: ok.
[05:36] <lifeless> StevenK: just 'bzr st'
[05:36] <lifeless> no -r here, because we're not trying to produce a related branch
[05:36] <StevenK> Two files modified
[05:36] <StevenK> Which are the two files changed
[05:36] <lifeless> StevenK: any pending merges ?
[05:37] <StevenK> Nope.
[05:37] <lifeless> StevenK: commit and move on :)
[05:37] <StevenK> lifeless: But when trunk moves on, I can't just merge, I'll have this pain again?
[05:38] <lifeless> StevenK: yes.
[05:38] <StevenK> Can I make the pain stop? :-)
[05:38] <lifeless> StevenK: yes, build from upstream rather than having an unrelated branch
[05:38] <lifeless> 'bzr branch upstream; do stuff'
[05:38] <mwhudson> beuno: are you here/awake ?
[05:44] <StevenK> lifeless: Well, actually, if I could smush the two branches together, it would be ideal. ubuntu for everything under debian/ and trunk for everything else.
[05:46] <lifeless> StevenK: so
[05:46] <lifeless> StevenK: I described above what you need to do to sync up correctly
[05:46] <lifeless> StevenK: but we have to do this on 13K branches, doing it adhoc is really not that useful - james_w will be doing toolchain support for this
[05:47] <StevenK> lifeless: I've done bzr branch upstream, I'm just not sure what I can do to get the files from the existing ubuntu branch into the new one while preserving history
[05:48] <lifeless> StevenK: bzr merge -r 0..-1 ../ubuntu/debian
[05:48] <lifeless> StevenK: you did say that no changes were outside ./debian right ?
[05:50] <StevenK> lifeless: Right
[05:51] <StevenK> lifeless: -1 == HEAD isn't so intituive, either
[05:51] <lifeless> StevenK: -0 is hard to represent
[05:52] <StevenK> lifeless: The code can't have a constant set for HEAD?
[05:52] <lifeless> probably can :)
[05:52] <StevenK> Even if HEAD is a CVS-ism
[05:54] <StevenK> Grumble. bzr log doesn't show history
[05:56] <lifeless> StevenK: have you committed the merge?
[05:57] <StevenK> lifeless: Yes.
[05:57] <lifeless> StevenK: then it should
[05:58] <StevenK> lifeless: bzr merge .... ; bzr ci -m "<msg>"
[05:58] <lifeless> StevenK: bzr log --show-ids -r -1
[05:59] <lifeless> StevenK: does it have one or two parents?
[06:02] <StevenK> lifeless: It has one parent
[06:03] <lifeless> StevenK: so, let me introduce you to 'bzr st'
[06:03] <lifeless> its a great way of seeing what a commit will do
[06:04] <lifeless> :)
[06:04] <StevenK> lifeless: uncommit and then st shows added files, not a pending merge
[06:05] <lifeless> StevenK: of course; do a revert
[06:05] <lifeless> StevenK: then the merge again and see if st shows a pending merge
[06:05] <StevenK> lifeless: No, just added files
[06:06] <lifeless> abentley: is there some other way to join separate imports than 'merge -r 0..-1'? its not adding a pending parent for StevenK .
[06:07] <abentley> lifeless: I can't think of one.
[06:07] <lifeless> abentley: I am sure it used to, I think this is a merge regression - do you agree?
[06:07] <abentley> lifeless: Also, the only reason it wouldn't add a pending parent is if one had already been set.
[06:08] <abentley> ie the merge had been done in the past.
[06:08] <lifeless> abentley: in that case though, merge wouldn't need a -r at all ;)
[06:08] <lifeless> abentley: I think its still considering it a cherry pick
[06:08] <abentley> in that case, the merge should be a no-op.
[06:09] <abentley> My code certainly didn't do that.
[06:10] <lifeless> abentley: yah, like I say I think its a regression
[06:10] <abentley> I tried a merge -r 0..-1 and it behaved as expected.
[06:10] <lifeless> abentley: oh, no I know
[06:10] <lifeless> abentley: I know whats going on and why :)
[06:10] <abentley> Was a file specified in the merge?
[06:11] <lifeless> StevenK: ok, heres what to do
[06:11] <lifeless> abentley: yes
[06:11] <lifeless> StevenK: revert / uncommit etc until you have whats in trunk
[06:11] <lifeless> StevenK: then:
[06:11] <lifeless> bzr merge -r 0..-1 ../ubuntu; bzr revert . ; bzr merge -r 0..-1 ../ubuntu/debian; bzr st
[06:13] <abentley> lifeless: There is "join", of course.  That's less general than you asked about.
[06:13] <StevenK> Okay, bzr st now shows a pending merge, but there was a bunch of errors from the other 3 commands.
[06:13] <lifeless> StevenK: thats ok
[06:13] <abentley> lifeless: also the merge-into plugin.
[06:13] <StevenK> And that's impressively counter-initutive :-)
[06:13] <lifeless> StevenK: it should ahve your ubuntu files etc; and you can just commit now
[06:14] <lifeless> abentley: yes, doing join and deleting and rearranging is probably the preferred ui
[06:14] <StevenK> I wonder if I can remove the 'submit' branch shown in bzr info
[06:14] <lifeless> StevenK: like I say, you're doing something that there is not much toolchain support for yet, and you can only do because you have the special case of no overlapping files
[06:15] <StevenK> Ah. We're trying to outsmart bzr a little too, I suspect?
[06:17]  * StevenK blinks. The merge works, but debian/ doesn't exist?
[06:18] <lifeless> StevenK: its not listed in 'bzr st' ?
[06:18] <StevenK> bzr st doesn't show anything. I've commited.
[06:18] <lifeless> StevenK: log -v -r -1 ?
[06:19] <StevenK> It shows the merge, and it that it added every file
[06:19] <StevenK> s/and it/and/
[06:21] <lifeless> StevenK: 'every file'?
[06:22] <StevenK> lifeless: Well, added every file, such as AUTHORS, NEWS, README, etc
[06:22] <StevenK> lifeless: I can pastebin the output, if you wish?
[06:23] <lifeless> StevenK: sure
[06:24] <StevenK> lifeless: http://paste.ubuntu.com/23876/
[06:25] <lifeless> StevenK: looks fine to me
[06:25] <lifeless> StevenK: lines 16 through 18
[06:25] <lifeless> StevenK: etc
[06:25] <lifeless> StevenK: what about 'bzr st -r -2..-1' ?
[06:26] <StevenK> lifeless: No output
[06:27] <lifeless> StevenK: ok, I think the last merge didn't quite do what we wanted
[06:27] <lifeless> StevenK: uncommit :)
[06:27] <lifeless> StevenK: repeat the 15:11 < lifeless> bzr merge -r 0..-1 ../ubuntu; bzr revert . ; bzr merge -r 0..-1 ../ubuntu/debian; bzr st
[06:27] <lifeless> step
[06:27] <lifeless> and make sure debian is present and everything ok before you commit
[06:27] <StevenK> lifeless: bzr st still shows a pending merge
[06:27] <lifeless> revert too
[06:27] <StevenK> lifeless: Or revert and redo?
[06:28] <StevenK> Done. And:
[06:28] <StevenK> ls: cannot access debian: No such file or directory
[06:29] <lifeless> uhm
[06:29] <lifeless> bzr st
[06:29] <lifeless> does it list debian etc?
[06:29] <StevenK> It just shows a pending merge
[06:29] <StevenK> % bzr st
[06:29] <StevenK> pending merges:
[06:29] <StevenK>   Steve Kowalik 2008-04-19 Add missing X[BS]-Python-Version fields.
[06:29] <StevenK> ...
[06:29] <lifeless> bzr merge -r 0..-1 ../ubuntu/debian --force ; bzr st
[06:30] <StevenK> bzr: ERROR: Revision {('',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x1349e10>".
[06:30] <lifeless> argh
[06:30] <lifeless> bzr revert
[06:30] <StevenK> Okay
[06:30] <lifeless> bzr branch ../ubuntu ./tempdir
[06:30] <lifeless> bzr join tempdir
[06:30] <lifeless> bzr mv tempdir/debian debian
[06:31] <lifeless> bzr rm --remove tempdir
[06:31] <lifeless> bzr st
[06:32] <StevenK> bzr: ERROR: Can't join trees because KnitPackRepository('file:///home/steven/canonical/moko/libmokoui2/ubuntu/.bzr/repository/') doesn't support rich root data.
[06:32] <StevenK> You can use bzr upgrade on the repository.
[06:32] <lifeless> ugh
[06:33] <lifeless> StevenK: that Revision {('',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x1349e10>" is a bug
[06:33] <lifeless> StevenK: what version of bzr do you have?
[06:33] <StevenK> Woo, another one
[06:33] <StevenK> lifeless: 1.4
[06:33] <lifeless> StevenK: try 1.5
[06:33] <lifeless> bzr merge -r 0..-1 ../ubuntu; bzr revert . ; bzr merge -r 0..-1 ../ubuntu/debian --force ; bzr st
[06:34] <StevenK> Try that with 1.5?
[06:34] <lifeless> yes
[06:35]  * StevenK digs for the bzr PPA
[06:42] <StevenK> lifeless: 1.5 still gives bzr: ERROR: Revision {('',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0xf979d0>".
[06:45] <lifeless> StevenK: ok, file a bug I guess
[06:45] <lifeless> or try 1.3
[06:51] <StevenK> lifeless: 1.3.1 gives the same error
[06:54] <lifeless> bleep
[06:54] <lifeless> bugger a file for sure
[07:09] <StevenK> lifeless: Not sure what the bug is. :-)
[07:09] <lifeless> getting that error
[07:18] <Suigintou> "My husband comes from a family where the men are always in charge. He was very nice to me when we were dating and after we got married he changed like he thinks he is my master. I feel like a slave sometimes and if I don't do what I am supposed to he yells and curses at me and he even spanks me. He doesnt usually hit me too bad but I am thinking that if we have a baby maybe he would be nicer with a child in the house. What do you peo
[07:18] <Suigintou> ple think I should do."
[07:18] <Suigintou> lol, stupid women
[07:23] <lifeless> Suigintou: thats really not on topic for this channel
[07:23] <lifeless> Suigintou: not to mention being offensive
[08:04] <lifeless> mbp_: I have some initial figures on the B+Tree index approach
[08:05] <lifeless> mbp_: looks like 2 IO's for up to 250K keys
[08:05] <lifeless> mbp_: and 3 for up to 125M keys
[08:07] <Suigintou> wrong channel, in fact, wrong network altogether, really sorry
[08:59]  * igc dinner
[10:15] <gour> hi, how is bzr with handling (bigger) binary files, e.g. movies
[10:17] <gour> i tried to add (by mistake) some rendered files (*.ac3, +.m2v, *.mpg) where *.mpg is ~220MB and darcs was on knees using 1GB of memory + 1GB of swap :-/
[10:18] <gour> it's my old video-project and i'll definitely migrate it from darcs
[10:18] <beuno> gour, yeah, not so good. It uses about 3x the amount of memory of the file's size
[10:18] <beuno> if you hace enough ram, you can pull it off, but, in general, it's probably not the best idea
[10:18] <gour> bzr?
[10:18] <beuno> yeah, bzr
[10:19] <lifeless> gour: its improvable
[10:19] <lifeless> gour: and sounds like better than darcs :)
[10:19] <gour> hmm, 3x is till better than 2GBs for ~220MB file
[10:19] <gour> *still
[10:19] <gour> hopefully, it does not try to keep them all at once in memory
[10:20] <gour> lifeless: good. let me burn & print DVD first, then i'll check how bzr does
[10:20] <beuno> lifeless, what's improvable?
[10:20] <gour> during that attempt my machine become totally non-responsible :-/
[10:21] <lifeless> beuno: memory use
[10:22] <beuno> lifeless, the estimate is still 3x the file's size though, right?
[10:22] <gour> it's not very common use, but when doing video-editing it might be useful to be able to store files
[10:22] <lifeless> beuno: we can do better
[10:22] <lifeless> beuno: we don't today, but we can
[10:26] <beuno> lifeless, right, that reminds me of some bug where the user asked if we could warn them before adding a file that would probably run out of memory while committing. Is that too difficult to do today?
[10:26] <lifeless> beuno: its tricky
[10:26] <lifeless> beuno: some people have 8GB RAM
[10:27] <lifeless> beuno: some ave 8GB VM and 2GB ram
[10:27] <lifeless> beuno: at what point is 'out of memory' is it thrashing? is it hitting swap? etc
[10:27] <lifeless> using a non refcounting python would help too
[10:27] <beuno> hm, yeah, may be worth working on the actual problem then
[10:28]  * gour has 1GB only :-(
[10:29] <beuno> gour, well, 1GB should be enough for 220mb files
[10:30] <gour> darcs used 1GB + 1GB swap to add 15M + 180M + 222M
[10:30] <gour> and machine was down
[10:30]  * gour --> copy-shop to print DVD cover. bbl
[11:37] <ToyKeeper> gour: For large files like that, you might find rsnapshot more appropriate...  at least, if you just want to be able to retrieve old versions.
[11:38] <ToyKeeper> Or, perhaps rdiff-backup, if you make small changes to big files (like changing the ID3 tag in a mp3)...  could be more space-efficient.
[11:41] <gour> ToyKeeper: well, when i work with cinelerra i keep its project (xml) files and some graphic files under vcs, so it was mistake to add those rendered files and interesting (darcs) result. now, when i finish with burning, i'll check how will bzr react
[12:39] <mkanat> ERROR: Repository KnitPackRepository('file:///home/mkanat/projects/mw/.bzr/repository/') is not compatible with repository RemoteRepository(bzr+ssh://control.trusthosting.net/var/www/html/everythingsolved.com/bzr/mingleware/.bzr/) ?
[12:44] <mkanat> Is that telling me that I can't use bzr+ssh with a rich-root-pack repo??
[12:44] <lifeless> mkanat: its telling you that one of repositories is rich root and one isn't
[12:45] <lifeless> mkanat: really shoukld make the error clearer
[12:45] <mkanat> lifeless: Hmm, I thought I made them both rich-root.
[12:45] <mkanat> lifeless: They're both rich-root-pack, I just checked.
[12:47] <mkanat> lifeless: At least, that's what .bzr/repository/format says.
[12:51] <mkanat> What's the difference between .bzr/branch-format and .bzr/branch/format ?
[12:54] <mkanat> Hmm, guess I need a newer bzr on the server side, that's my guess.
[12:58] <lifeless> mkanat: possibly; what version is it?
[12:58] <mkanat> It's 1.3 on the server, 1.5 on the client.
[12:58] <lifeless> .bzr/branch-format is the control dir format
[12:58] <mkanat> Ah, okay.
[13:00] <lifeless> (before 0.8 we didn't have split out repository/branch/checkout objects)
[13:00] <lifeless> so its named whackily, but backwards compatible
[13:00] <mkanat> Ahh. :-)
[13:00] <mkanat> Hmm, upgrading the server didn't help.
[13:01] <mkanat> sftp checkout works fine, bzr+ssh doesn't.
[13:02] <lifeless> mkanat: file a bug please
[13:02] <mkanat> lifeless: Okay, will do.
[13:03] <mkanat> Ah, it's already filed as bug 205579.
[13:04] <lifeless> mkanat: you sure its the same?
[13:05] <mkanat> lifeless: Yep, identical problem.
[13:56] <Pilky> I dunno if there are any other Xcoders in here but if there are then this may interest you: http://www.mcubedsw.com/blog/index.php?/site/comments/build_numbers_from_bazaar/
[14:24] <jelmer> Pilky, nice
[14:29] <Tsmith> after a branch merge, do you just delete the branch?
[14:31] <beuno> Tsmith, a little more information may be needed to answer that question  :)
[14:31] <beuno> you where working in a branch separate from the mainline
[14:31] <beuno> and you merged that into, let's say trunk?
[15:22] <guilhembi> abentley: hi! I wrote several posts on support issue 00002413
[15:22] <abentley> guilhembi: Hi there.  I saw them.
[15:22] <guilhembi> abentley: even the latest one?
[15:23] <abentley> "I missed your comment?"
[15:23] <abentley> I did see that.
[15:24] <guilhembi> abentley: ok, thanks
[15:24] <abentley> Right now, I'm looking into this tests directory conflict.
[15:24] <guilhembi> abentley: uber-great!
[15:24] <guilhembi> abentley: mysterious how mysys/tests/Makefile.am wasn't imported...
[15:25] <abentley> If mysys/tests *was* deleted, possibly Makefile.am was deleted at the same time.  But I can't say whether that happened yet.
[15:28] <guilhembi> abentley: and I don't know either if it was deleted. Looking for creation history when the file exists, is easy, but for deletion history when it's missing, is not, and it's not specific to bzr.
[15:28] <abentley> Yeah.  I can do it, it'll just take a bit.
[15:30] <guilhembi> abentley: after doing some grep somewhere, it looks like it was never deleted and never existed in 6.0-ndb
[15:33] <abentley> So far, I've determined that the file was created in mysql-5.1-telco-6.2-merge revno 2555.13.2
[15:38] <guilhembi> abentley: is that the same as sp1r-mtaylor@solace.(none)-20080425063223-04764 ?
[15:38] <abentley> guilhembi: Yes.
[15:43] <abentley> guilhembi: So it looks like my results match yours<EMAIL_ADDRESS>is not a descendant of 'sp1r-mtaylor@solace.(none)-20080425063223-04764'
[15:43] <guilhembi> abentley: uh, did I say that...
[15:44] <abentley> Therefore the first didn't delete the directory created by the second.
[15:45] <abentley> It doesn't have the directory because it never had the opportunity to get it.
[15:45] <guilhembi> that I agree
[15:46] <abentley> So now I have to find out why bzr thought it did.
[16:43] <gour> heh, finally i found time to test how bzr handles binary files...i tried to add the same 3 binaries which put darcs on the knees (15M, 180M and 222M) and bzr handled them OK
[16:44] <gour> sure, there is room for improvement for the memory usage, but it was workable, while with darcs my machine almost stopped responding using all of 1GB RAM as well as 1GB of swap
[17:19] <NfNitLoop> so I'm doing a "push" to a remote (windows) filesystem.
[17:19] <NfNitLoop> slooow. :p
[17:19] <NfNitLoop> (The connection is just slow & laggy)
[17:20] <NfNitLoop> I imagine a pull would go much more quickly...  but I'm not sure if I have rights to install bzr on that end.  >.<
[17:37] <bpeterson> can I "clean out" a shared repo? can I get rid of the revision stored there that no longer have branches?
[17:39] <jam> bpeterson: I believe there is a plugin for it (bzr-remove-revisions), but there isn't a core garbage collection command
[17:40] <bpeterson> what does bzr pack do?
[17:40] <jam> bpeterson: combines small packs into larger ones
[17:40] <bpeterson> oh
[17:40] <bpeterson> thanks
[17:42] <bpeterson> are there plans to add some garbage collection type thing?
[18:35] <jam> abentley: ping, a question on the _merge_names logic
[18:36] <abentley> jam: pong
[18:36] <jam> abentley: you have this logic:
[18:36] <jam>         if this_name is None:
[18:36] <jam>             if name_winner == "this":
[18:36] <jam>                 name_winner = "other"
[18:36] <jam>             if parent_id_winner == "this":
[18:36] <jam>                 parent_id_winner = "other"
[18:36] <jam> Which seems to say "if this wants to delete the file, switch and consider "other" to introduce it
[18:36] <jam> Am I understanding that correctly?
[18:37] <abentley> jam: If you have a conflict, and so you need a name for it, and there's no name in THIS, use the name in OTHER.
[18:37] <jam> abentley: and if you don't have a conflict?
[18:38] <jam> It only does something if the _merge_contents happens?
[18:38] <jam> Is this just reserving a potential name?
[18:38] <abentley> I believe that the name isn't used if there is no conflict.  I would have to double-check, though.
[18:39] <jam> abentley: ok, it made it a bit harder to debug what was going on.. but if it is just reserving the name, it doesn't seem to be a problem
[18:39] <jam> It uses "if changed: self._merge_contents()" and in this case changed == False
[18:43] <abentley> jam: I believe this is the case that handles directory deleted in X, directory has files added in Y, merge X and Y.
[18:44] <jam> sure
[18:45] <abentley> It adjusts the path associated with the file, but is silent about whether anything is present at that location.
[18:47] <jam> abentley: sure, it seems my lca_multi_way logic is giving the right result
[18:47] <jam> but at a higher level I'm setting "changed=True" because the file is different versus *one* of the basse
[18:47] <jam> bases
[18:47] <jam> so it is picking OTHER for the filename, and then conflicting because of the other work
[18:48] <jam> oh well, at least the multi-way logic is correct :)
[18:52] <abentley> Ah well.
[18:53] <abentley> jam: In other news, it seems that VersionedFile is dead, dead, dead in bzr.dev.
[18:54] <jam> VersionedFiles is dead, long live the VersionedFiles
[18:54] <jam> VersionedFile is dead, long live the VersionedFiles
[18:54] <jam> I guess that works better :)
[18:54] <abentley> So we don't need to hoist get_line_list into it.
[18:55] <abentley> But iter_files_bytes looks to be efficiently implemented.
[18:55] <jam> So does it have an "add_bytes" method then?
[18:56] <abentley> No, just add_lines.
[18:58] <abentley> PlanMergeVersionedFile is still a VersionedFile, though.
[18:58] <abentley> We should probably fix that.
[18:58] <jam> abentley: actually, when I look closer, it doesn't look like it is done efficiently across multiple versions
[18:58] <Odd_Bloke> jelmer: I notice you've updated a few of your PQM branches recently.  Are those things I should be interested in?
[18:58] <jam> abentley: it seems to extract the deltas needed efficiently
[18:58] <jam> but then it does
[18:59] <jam> record.get_bytes_as('fulltext')
[18:59] <jam> for *each* record
[18:59] <jam> And Knits seem to do
[18:59] <jam>         if storage_kind == 'fulltext' and self._knit is not None:
[18:59] <jam>             return self._knit.get_text(self.key[0])
[19:00] <jam> unless the get_record_stream is smarter than I thought
[19:00] <jam> still looking
[19:01] <Odd_Bloke> thumper: You seem to have some relatively recent unmerged branches too, should I be interested in those?
[19:01]  * Odd_Bloke notes that he will bug by email if he hasn't received a response by this evening (BST).
[19:01] <abentley> Odd_Bloke: thumper has submitted at least some of those to lifeless for review.
[19:02] <jam> abentley: it looks like if you pass "include_delta_closure" it then expands all the requested texts into fulltexts
[19:02] <Odd_Bloke> abentley: Thanks, that's helpful to know. :)
[19:03] <jam> abentley: so it looks like it might, indeed, be done properly, but man the layering makes it difficult to see
[19:03] <jam> I suppose any time you pass "include_delta_closure" actually means that you always want fulltexts?
[19:03] <abentley> Odd_Bloke: https://code.edge.launchpad.net/~lifeless/pqm/trunk (see list of proposed merges)
[19:04] <Odd_Bloke> abentley: Cool, thanks.
[19:05] <abentley> I have no idea what include_delta_closure would mean.
[19:05] <Odd_Bloke> Pretty cool to see LP being used for this sort of stuff.
[19:05] <jam> abentley: well it is get_record_stream(keys, ordering, include_delta_closure)
[19:06] <jam> It seems to me that 'include_dellta_closure' would be a flag to include the deltas necessary to build everything into the record stream
[19:06] <jam> but not necessarily unpack them into fulltexts
[19:07] <abentley> jam: That's how I read the comment.
[19:07] <abentley> or docstring, rather
[19:09] <jam> abentley: yeah, but it seems all callers mean "give me fulltexts" and use it as such ...
[19:09] <jam> fetch() passes False, callers that want fulltexts pass True
[19:10] <jam> I'm guessing this is a case where Robert started thinking one way
[19:10] <jam> ended up a different way
[19:10] <jam> and didn't update all the places inbetween
[19:15] <abentley> jam: Yeah.
[19:15] <abentley> It seems he could trivially have done LinesContentFactory, and avoided the memory bloat.
[19:18] <jam> except the trivial implementation would have to apply all the deltas for each fulltext
[19:18] <jam> getting one which does the minimum amount of work before each request would be possible
[19:18] <jam> but non-trivial to write
[19:18] <jam> certainly it seems that the api would work with that situation, though.
[19:19] <abentley> He's already calling get_content_maps, which ought to be efficiently returning lines.
[19:23] <abentley> And it looks like he doesn't expect anyone to hold on to a ContentFactory, in which case there's no memory wasteage.
[20:00] <abentley> jam: It looks like PlanMergeVersionedFile has become a VersionedFiles, so get_line_lists should probably hang off _PlanMerge.
[20:02] <jam> Well... we could also just use get_record_stream() directly, since it seems to be on all VersionedFiles, record.get_bytes_as('fulltext') will return the lines.
[20:02] <jam> At least, as I understand the structuring.
[20:04] <abentley> jam: actually PlanMerge has get_lines, which returns lines for list of versions.
[20:04] <abentley> So there's already a friendly multi-get method.
[20:05] <jam> so... the 'get_lines()' api changed...
[20:05] <jam> oh, I guess this is on PlanMerge
[20:05] <jam> nm
[20:21] <jelmer> Odd_Bloke, hi
[20:21] <jelmer> Odd_Bloke, possibly - one replaces automake with setup.py
[20:22] <jelmer> the other uses a python module for gpg signature verification rather than invoking gpgv directly
[20:22] <jelmer> (the latter was causing breakage on my machine)
[20:26] <NfNitLoop> "breakage"?
[20:34] <abentley> jam: I posted the merge-delete-and-change tests to the list.
[20:36] <abentley> jam: I don't really understand the remaining test you wanted.
[20:38] <jam> The one for "ha_ndbcluster.cc"
[20:39] <jam> abentley: The idea is to have a merge which cannot be solved by the first LCA analysis
[20:39] <jam> nor by using just unique_lca + first lcas
[20:40] <abentley> This is a text merge?
[20:53] <jelmer> abentley, Is there any reason creating a merge directive requires write access to the repository?
[20:58] <abentley> jelmer: Yes.  It fetches the head revision of the submit branch into the local branch.
[21:07] <jelmer> abentley: Ah, that makes sense. Thanks!
[21:07] <jelmer> Related to this..
[21:08] <jelmer> Is there any easy way to upgrade read locks to write locks?
[21:08] <abentley> jelmer: Only if you control the whole call stack.  If you might want a write lock, take a write lock.
[21:20] <Odd_Bloke> jelmer: Is there any specific reason that the distutils one hasn't been merged, or has it just not been reviewed yet?  That'd make my life easier, because I just don't understand autotools.
[21:20] <jelmer> abentley: hmm, ok
[21:22] <Odd_Bloke> It would also reduce the number of files that are created in the root of the branch.
[21:32] <abentley> jam: One thing I forgot to mention; the problem with using a non-unique LCA during criss-cross is that disputed resolutions get silently resolved in favour of one side.  But this is what MySQL wants, no?
[21:55] <abentley> jam: I haven't been able to concoct a merge scenario for the last test.
[21:55] <mwhudson> beuno: hello
[21:55] <beuno> morning mwhudson!
[21:56] <jam> abentley: I'm happy to have a test with "weave" that asserts that is what it does. I can't say for sure what they would prefer, as at this point we have bad graphs all over the place messing things up :)
[21:56] <mwhudson> beuno: the new_theme needs a symlink icon
[21:56] <jam> In *general* they feel like if "bzr gannotate" shows the line as in the history
[21:56] <jam> they shouldn't be bothered by a conflict
[21:56] <jam> and the criss-cross different resolutions is something that you can't detect
[21:56] <jam> using gannotate
[21:56] <mwhudson> beuno: i tried to say this in email yesterdary but sent it to poolie instead :)
[21:57] <jam> So I think it is more of "If you can't answer 'why is this conflicted', don't show me a conflict".
[21:57] <beuno> mwhudson, it should have one, I may of forgot to add it
[21:57]  * beuno checks
[21:58] <abentley> What is this responding to? "I'm happy to have a test with "weave" that asserts that is what it does..."
[21:59] <jam> abentley: That a mixmatched resolved conflict is silently ignored. You can write an XFail test or just a plain test for that if you want.
[22:00] <jam> I *can* say that --lca as it is implemented now still conflicts more than --weave, and they are worried about the "silently unclean merge" bug.
[22:01] <abentley> jam: I was trying to say that we might make them happy by writing a merge3 that uses a non-unique LCA.
[22:01] <jam> maybe, but --weave does the job too
[22:02] <mwhudson> beuno: bug #242580 is odd, and worrying
[22:02] <ubott2> Launchpad bug 242580 in loggerhead "Current trunk tends to peg CPU at 100% after running a while, for no obvious reason" [High,New] https://launchpad.net/bugs/242580
[22:02] <abentley> jam: --weave is making you do major surgery to the inventory code.  I'm not saying it's the wrong approach.  But I would be remiss in not pointing out the merge3 option.
[22:04] <lifeless> moin
[22:04] <beuno> mwhudson, is it related with what's happening in LP?
[22:05] <mwhudson> beuno: well, hard to say!
[22:06] <mwhudson> but he's only serving 18 branches
[22:06] <beuno> mwhudson, yeah. I suppose if this was widespread, the gnome mirror would be on it's knees
[22:07] <mwhudson> otoh, he does seem to be accessing branches over http
[22:07] <mwhudson> well, some branches
[22:08] <mwhudson> the name resolution failures could easily be running out of fds too, i'd guess
[22:08] <mwhudson> beuno: in any case, i hacked up a branch to help with the LP issues last night, let me push it
[22:10] <beuno> mwhudson, oh, cool. It closes the branch?
[22:10] <lifeless> jam: what sort of bad graphs do we have?
[22:10] <beuno> mornin' lifeless
[22:11] <jam> abentley: bad paths are making me do it :) And if we picked the wrong lca, we would be in the same position
[22:11] <mwhudson> beuno: it makes History objects ephemeral
[22:11] <mwhudson> beuno: and caches the expensive to calculate stuff elsewhere
[22:11] <jam> remember, we have (path1, None, None) for bases, and path2 for THIS, path1 for OTHER
[22:11] <jam> So if you pick the None LCA, you get the wrong answer
[22:11] <jam> if you pick the path1, you get the right answer for *this* file.
[22:12] <lifeless> whats the None, None there?
[22:13] <beuno> mwhudson, I'll take a peak at the branch.
[22:13] <mwhudson> beuno: https://code.edge.launchpad.net/~mwhudson/loggerhead/dont-hold-branches-open
[22:13] <mwhudson> there's some pretty nasty code in places, but i like the idea
[22:14] <mwhudson> beuno: have you thought about a prettier file listing at all?
[22:15] <beuno> mwhudson, this is related to the new theme?  Prettier the what we have now?
[22:15] <beuno> now == new theme
[22:15] <mwhudson> beuno: i haven't looked in the new theme...
[22:16] <mwhudson> beuno: ah sorry, i was vauge
[22:16] <mwhudson> vague
[22:16] <mwhudson> beuno: i meant BranchesFromFileSystemServer.directory_listing
[22:17] <beuno> mwhudson, ah, yes. I tried the other day, but my brain was fried and I was taking too many shortcuts  :)
[22:17] <jam> lifeless: The 'path' in that base is None, because the file doesn't exist there
[22:17] <beuno> I have 2 branches half-baked.  Proper setup.py, and template for directory listing
[22:17] <jam> it was added in one of the LCAs
[22:18] <mwhudson> beuno: both sound like good things :)
[22:18] <beuno> mwhudson, for starters, I thought we could use the same that we use to navigate branches/projects, and see what can actually be improved later on
[22:18] <mwhudson> beuno: mmm
[22:18] <lifeless> jam: so its (id, revision, path) ?
[22:19] <mwhudson> beuno: that sounds like it would be difficult because of shortcuts /i/ took in wsgi-ify :)
[22:19] <jam> lifeless: no it is (path_in_base1, path_in_base2, path_in_base3)
[22:19] <jam> we have 3 common ancestors
[22:19] <jam> (least common ancestors)
[22:19] <beuno> mwhudson, yes, that's what provoked less-then-acceptable hacks, and made me discard it  :P
[22:19] <jam> if we go all the way back to the unique_lca, the path is None, because it didn't exist yet
[22:20] <jam> So you see base = None, this = path2, other = path1
[22:20] <jam> aka, conflict
[22:20] <lifeless> and they want it to resolve to path2 no conflict?
[22:20] <jam> For *one* of the LCAs, you can see base = path1, this = path2, other = path1, aka path2 wins
[22:20] <jam> lifeless: yes, because that is *true* for the file in question
[22:20] <jam> it is only because we can't see it for the criss-cross throwing off our base selection
[22:21] <beuno> mwhudson, do you have any specific ideas for that bit?
[22:21] <jam> if we picked the base from the per-file graph, we would do it "correctly"
[22:21] <lifeless> jam: does the per file graph help? ok
[22:21] <mwhudson> beuno: not really, but start from scratch :)
[22:21] <lifeless> jam: and you've tried taking the per file graph an indexing from there back to the inventory contents?
[22:21] <jam> lifeless: no, I don't want to have to extract the full inventory for every file
[22:22] <jam> just to get the path, etc. each time
[22:22] <mwhudson> beuno: tbh, what i generate already with the standard macros.pt stuff wrapped around it would probably be ok
[22:22] <lifeless> jam: you don't have to though
[22:22] <beuno> mwhudson, heh, good, that's what I did.  Those are the two remaining bits I think we need, apart from new theme, to release 1.6
[22:22] <lifeless> jam: well, to be clear: you don't have to do full upgrading to Inventory to get the path out - from bzrlib.plugins.search.inventory import ids_to_paths
[22:22] <mwhudson> beuno: i'd like to put a vote in for dont-hold-branches-open :)
[22:22] <beuno> mwhudson, I can make it look better with the current approach then, generate it through python
[22:23] <mwhudson> beuno: and see if that fixes mkanat's problem
[22:23] <beuno> mwhudson, sure, I've got to go home and pick up some stuff, and I'll review/test it
[22:24] <lifeless> jam: thats reasonably close to being tweakable to process lines through the regex just-in-time
[22:25] <mwhudson> beuno: it's not really ready yet from a code clarity POV, but testing would certainly be appreciated :)
[22:25] <lifeless> abentley: can you help me understand bug 244115 ?
[22:25] <ubott2> Launchpad bug 244115 in bzr "merge between two branches fails" [Undecided,Confirmed] https://launchpad.net/bugs/244115
[22:26] <jam> lifeless: except it won't work if we change serialization formats, etc. I think I have a reasonable solution using our current apis, that should even perform decently, I just have to implement it.
[22:26] <jam> I can actually get the path correct using simple lca lookups
[22:26] <jam> the problem is that the file shows up as "changed" because of the [path, None, None] stuff
[22:26] <jam> so I need to do the same "is this actually changed" at a higher level
[22:26] <lifeless> abentley: I don't understand why it sees libmokoui as unversioned
[22:27] <beuno> mwhudson, I'll try and poke holes in it  :p   and, also, Peng is *really* good a poking holes
[22:27] <mwhudson> :)
[22:29] <abentley> lifeless: I don't really have time.  This is a cherrypick into an unrelated tree.  It adds a file to libmokoui, which doesn't exist, because this is an unrelated tree.  It doesn't add libmokoui because this is a cherrypick.
[22:29] <lifeless> abentley: I'll double check, but I was pretty sure libmokoui existed in both trees
[22:36] <lifeless> abentley: thanks, I get the cause now; I've commented back in the bug
[22:37] <jelmer> Odd_Bloke, IIRC lifeless didn't see a good enough reason to switch over from automake
[22:37] <lifeless> I didn't see the need to recreate all the existing automake support for docbook etc in setup.py and then maintain it
[22:38] <lifeless> its 'create more work because we like work'
[22:39] <Odd_Bloke> Yeah, I found the bug a while after asking and forgot to mention it.
[22:40] <Odd_Bloke> Well, by the looks of it, jelmer has already recreated the existing support in his patch.
[22:40] <lifeless> Odd_Bloke: its not a one time thing
[22:40] <lifeless> Odd_Bloke: that is code, it has to be bugfixed and maintained
[22:42] <jelmer> lifeless: Maintaining python code with automake has the same problems but the other way around
[22:43] <lifeless> jelmer: I'm happy to chain into setup.y if the automake python support is going to give us grie
[22:43] <jelmer> (the reason I ended up working on this was because I was looking into debianizing pqm but it was installing into the wrong directory)
[22:43] <lifeless> f
[22:58] <lifeless> jelmer: well, like I say, I just don't want the maintenance burden of reinventing automake + autoconf + make and all that dependency checking and correctness in setup.py
[22:58] <lifeless> If I'm going to maintain a build tool; it will be something clean :)
[22:59] <jelmer> heh
[22:59] <lifeless> jelmer: so if you want to migrate the bits that are problematic for debian to a setup.py file, and have ./configure && make chain through to that - thats ok and I'll review and merge.
[22:59] <jelmer> lifeless: the docbook stuff is the only bits that should remain in the end
[22:59] <mwhudson> at least libtool isn't involved
[23:00] <lifeless> mwhudson: well yes
[23:13] <jelmer> lifeless, That still keeps the heavy dependency on automake and just complicates things by using more build systems
[23:14] <jelmer> lifeless: My patch replaced 143 lines of automake+autogen with 162 lines of setup.py
[23:15] <lifeless> jelmer: and it was correct? or does it build doco every run unconditionally etc etc?
[23:15] <lifeless> jelmer: I think we're just not connecting here -
[23:19] <jelmer> lifeless: yes, it is - even if it wasn't, that's a different issue
[23:21] <jelmer> lifeless: sorry, I do indeed still don't see your point
[23:26] <lifeless> jelmer: so my issue is about having a NIH build tool for docbook in pqm; I think its wrong
[23:26] <lifeless> jelmer: I don't think that code belongs in the pqm tree
[23:26] <jelmer> lifeless: it's not a NIH build tool - it's just a distutils wrapper that calls xmlto
[23:26] <lifeless> I'll have to recheck the patch then
[23:29] <jelmer> Should I sent an updated bundle to the list, ccing you?
[23:30] <jelmer> I've just resolved some conflicts after merging trunk
[23:38] <lifeless> jelmer: to the patch, sure
[23:40] <mbp_> good morning
[23:41] <jam> mbp_: good morning, didn't we a have a call today? (and what have you done with poolie? :)
[23:42] <mbp_> hm
[23:42] <mbp_> silly irssi
[23:42] <mbp_> jam, i think we talked last week so i had it down for next weex
[23:43] <jam> poolie: well, my gcal shows it as this monday, but we did have a separate call last week
[23:43] <jam> I'm happy to bump it if you prefer
[23:43] <poolie> i'm away next tuesday so how about if we talk either monday or wednesday
[23:45] <jam> wed is good
[23:47] <jelmer> lifeless, sent
[23:47] <jam> poolie: hopefully the google calendar invite made it through properly
[23:48] <jam> but that puts the next meeting as Tues July 8th US, Wed July 9th AU time
[23:48] <jam> And for now, the next is Mon, Jul 20th / Tues Jul 21st.
[23:50] <poolie> um
[23:50] <poolie> do you mean the 21st/22nd?
[23:50] <poolie> " Cross your fingers and try again in a few minutes, or talk to the person who set up this event." :-)
[23:51] <poolie> i have it on paper anyhow
[23:53] <lifeless> jelmer: to the bug?
[23:53] <jelmer> lifeless, no, to the list
[23:53] <lifeless> jelmer: could you please send attach it to the bug?
[23:53] <jelmer> k
[23:54] <lifeless> thanks


[01:22] <martalli|home> .msg nickserv identify jyestham
[01:23] <martalli|home> ugh
[06:56] <ajmorris_> i installed mozilla thunderbird 2.0, and now it won't run as mozilla-thunderbird cannot be found, in the installed files section of thunderbird there is no mozilla-thunderbird in /usr/bin, is version 2.0 broken?
[01:36] <nopcode> hey
[01:36] <nopcode> why is there a kernel package namend 2.6.22 when no such kernel exists according to kernel.org?
[01:37] <Tm_T> nopcode: because it's unstable version?
[01:37] <nopcode> uhm
[01:38] <Tm_T> unstable here means "not released as stable yet"
[01:38] <nopcode> yeah but then it'd be 2.7
[01:38] <Tm_T> no
[01:38] <Tm_T> that would be unstable unstable
[01:39] <nopcode> hm
[01:39] <nopcode> ok
[01:39] <nopcode> i just saw 2.6.26 is the very latest unstable
[01:39] <nopcode> are there packages for that?
[01:39] <nopcode> my realtek r8169/r8111 gigabit NIC doesnt work
[01:40] <nopcode> (that is with 2.6.22)
[01:40] <Tm_T> not that I know, but noone stop you building one
[01:41] <digitalpardoe> nopcode: 2.6.26 could be the latest unstable but it doesn't mean ubuntu are going to distribute it.
[01:41] <nopcode> well i'd rather want networking before i start getting the dependencies for kernel building
[01:41] <nopcode> for obvious reasons
[01:42] <digitalpardoe> In what way doesn't your ethernet work?
[01:43] <nopcode> the drivers loads then it says "link down"
[01:43] <nopcode> and dhcp doesnt answer
[01:44] <digitalpardoe> Did it work in Feisty? If you really want to be kernel building you should try Gentoo rather than Ubuntu.
[01:45] <borschty> you could install the 2.6.20 kernel, which i think is still in the repos
[01:45] <nopcode> i am using feisty
[01:45] <nopcode> i just took the kernel package from gutsy
[01:45] <nopcode> dude what? i always build my own kernel
[01:46] <markc> nopcode: do you use a nvidia gfx card ?
[01:46] <nopcode> dont tell me you're not expected to do that in ubuntu
[01:46] <digitalpardoe> Revert to the feisty kernel then and see if your drivers load.
[01:46] <nopcode> markc: yeah
[01:46] <markc> working okay ?
[01:46] <nopcode> digitalpardoe: i only upgraded because it didnt work there with 2.6.20
[01:46] <nopcode> markc: on windows, yeah
[01:47] <nopcode> with ubuntu i had to remove the "splash" option because that gave me a permanent black screen on boot
[01:47] <markc> nopcode: I just joined the channel, so you compiled 2.6.22-1-rt yourself and don't have nvidia.o ?
[01:47] <nopcode> i dont care about nvidia now
[01:47] <nopcode> i need to get my NIC to work
[01:47] <nopcode> a realtek r8169/8111 something gigabit nic
[01:47] <nopcode> i'm running the 64 bit version btw
[01:47] <markc> nopcode: right, so your nvidia is not working either
[01:48] <nopcode> what?
[01:48] <nopcode> i dont expect it to work
[01:48] <nopcode> since i didnt install any drivers yet
[01:48] <nopcode> i'm getting framebuffer-X11 i think
[01:48] <markc> so you didn't try to rebuild the restricted package ?
[01:48] <markc> as well
[01:48] <nopcode> hey man
[01:49] <nopcode> i cant do _anything_ without network card
[01:49] <nopcode> i need that for getting packages
[01:49] <digitalpardoe> Perhaps the 64bit kernel doesn't have support for your network cards then.
[01:49] <nopcode> it does
[01:49] <nopcode> the driver even loads
[01:49] <nopcode> it just says "link down" and doesnt work
[01:49] <markc> what driver is it ?
[01:50] <nopcode> r8169
[01:51] <markc> I just "upgraded" to gutsy and FWIW there is no r8169 that comes with 2.6.22-1-rt
[01:51] <nopcode> r8111?
[01:52] <nopcode> hm
[01:52] <nopcode> well atleast some driver loaded ;)
[01:52] <nopcode> ah wait
[01:52] <nopcode> 8168 maybe?
[01:52] <digitalpardoe> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/86798
[01:52] <ubotu> Launchpad bug 86798 in linux-source-2.6.20 "r8169 driver does not detect link" [Medium,Confirmed]
[01:52] <markc> r8619 not r8169
[01:53] <markc> sorry, I typed that wrong, should have pasted
[01:53] <nopcode> windows says r8168 / r8111
[01:54] <nopcode> brb
[01:54] <digitalpardoe> It might be worth trying the workthrough on the bug page, just to see.
[01:57] <nopcode> ok lets see
[02:03] <nopcode> re
[02:03] <nopcode> no didnt work
[02:04] <nopcode> i booted with the cable unplugged and inserted it after boot
[02:04] <nopcode> didnt work
[02:04] <nopcode> then i tried cycling the module, no luck
[02:04] <digitalpardoe> Not sure what the issue could be then. Have you tried booting from the 32bit live CD to see if it is an issue with the 64bit driver.
[02:33] <IdleOne> !gutsy
[02:33] <ubotu> Gutsy Gibbon is the code name for the next release of Ubuntu (7.10). See https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-April/000276.html and https://wiki.ubuntu.com/GutsyReleaseSchedule Support in #ubuntu+1
[03:01] <gortiz> !list
[03:01] <ubotu> I am ubotu, all-knowing infobot. You can browse my brain at http://bots.ubuntulinux.nl - Usage info: http://wiki.ubuntu.com/UbuntuBots
[04:00] <Dink> Quick question .... libk3b2 is being held back on initial dist-upgrade ... known issue or should I just force the package install later ?
[07:01] <Answer> anybody here that can help with wep key?
[07:02] <cliebow_> Answer, perhaps..
[07:03] <Answer> I have a wired connection to the device, I put in the ssid and the wep key and it does not work.  with key:off I can associate to an AP.  I have verified the ssid and key are correct.  I can see the AP with iwlist scan
[07:05] <Answer> it seems very similar to http://madwifi.org/changeset/2081  and https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/30596
[07:05] <ubotu> Launchpad bug 30596 in netcfg "WEP key for wireless takes only uppercase" [Medium,Unconfirmed]
[07:13] <Answer> from everything I can see it is online, but it is not   http://paste.ubuntu-nl.org/19649/
[07:15] <cliebow_> not sure i have an answer..wireless has been really wierd in kernels past <IP_ADDRESS> (my opinion)
[07:16] <cliebow_> Answer, you might try something called wifi-radar..i've had good luck wit that
[07:17] <Answer> I do not understand.  I have 11 examples of WEP that work and one that I cannot make work
[07:18] <Answer> I've got wpa/wpa2/leap/eap-fast/peap/ieee8021x whatever - and i'm stuck on a stupid wep key
[07:19] <Answer> How can I track down the incompatibility here
[07:19] <Answer> I have the same brand model firmware of the access point with an identical config in a test environment and it works
[07:20] <Answer> so it must be something behind the ap with the controller or radius server
[07:21] <PocketIRC> Is it true that it propably will be only like..2 of the ideas that will make it into gutsy?
[07:21] <cliebow_> ?
[07:23] <Toma-> what ideas
[07:24] <PocketIRC> all the ideas in the forums
[07:24] <gord> forums are not the place to suggest ideas to make it into ubuntu
[07:28] <PocketIRC> gord: http://ubuntuforums.org/forumdisplay.php?f=253
[09:17] <raf256> hello
[09:45] <crimsun> of course not.
[09:46] <crimsun> all 131 others of us are dead.
[10:38] <brainsik> ah!
[10:38] <raf256> crimsun: I was going to ask some questions, because #ubuntu have higher newb-to-signal ratio then debian have grumpy-to-signal, but seeing how its quiet here I am shy now