[04:38] <micahg> bluesabre: would another day be problematic for the 2 open things you wanted me to review?
[04:39] <bluesabre> micahg: I think that should be okay.  Do you know when the 14.04.1 freeze is?
[04:39]  * micahg checks
[04:40] <micahg> hum, should be Thursday
[04:40] <micahg> err...next thrusday
[04:44] <micahg> away
[05:01] <Unit193> OK.
[05:09] <bluesabre> ok, that should be fine then.  Thanks micahg
[05:15] <bluesabre> heading to bed, back tomorrow
[06:10] <Unit193> pidgin and xfburn seem to be the only thing holding us back on to gst 0.10.
[06:10] <Unit193> And as noted on the bp, pidgin 3.0.0 should have it fixed.
[06:20] <Noskcaj> Unit193, I've sent an email to the xfburn maintainer asking if he could look into porting it
[07:21] <Noskcaj> xfburn's maintainer says it will be ready sometime in august
[07:35] <Unit193> Well huh.
[20:06] <Noskcaj> Success! https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions/XFCE
[20:46] <Unit193> Wow, nice.
[20:48] <pleia2> ah yes, I was just reading the TB email, nice work Noskcaj :)
[20:48] <knome> o hai pleia2!
[20:48] <pleia2> oops
[20:48] <knome> haha
[20:48] <pleia2> :D
[20:49] <knome> no worries, i'm watching footbal
[20:49] <knome> +l
[20:49] <Unit193> Personally a bit surprised it was accepted.
[20:49] <knome> Unit193, why not?
[21:25] <Noskcaj> bluesabre, Will we want parole 0.6.2 or 0.7.0 in utopic?
[23:19] <bluesabre> Noskcaj: probably 0.7.0, but we are aiming for a short 0.7 cycle that is for testing and implementing other fixes/features
[23:20] <Noskcaj> bluesabre, ok. I'll package 0.7.0 then.
[23:21] <bluesabre> thanks, there are some new build-deps, cli options for if we want to enable clutter (I recommend that we do) https://bazaar.launchpad.net/~smd-seandavis/parole/parole-gtk3-debian/revision/17
[23:22] <Noskcaj> ok
[23:23] <bluesabre> ochosi, we may want to consider setting cluttersink as default in xubuntu-default-settings, let me know your thoughts (or anybody else with an opinion)
[23:24] <Noskcaj> bluesabre, Do we include clutter in xubuntu already?
[23:24] <bluesabre> Noskcaj, we do not, so perhaps hold off on adding the new clutter stuff
[23:24] <Noskcaj> if not, i'd like to upload without it, then have a team discussion on if we want it
[23:24] <bluesabre> right
[23:24] <bluesabre> :)
[23:26] <Noskcaj> is the gtk ifdef enforced from build-time or run-time? (just wondering)
[23:26] <ochosi> runtime
[23:27] <ochosi> (i think)
[23:27] <bluesabre> build-time
[23:27] <ochosi> heh, ok :)
[23:27]  * ochosi concedes
[23:27] <Noskcaj> I'll put a depends-version on >= 3.10 to be safe then
[23:27]  * bluesabre is probably wrong
[23:27] <bluesabre> okie dokie
[23:31] <ochosi> Noskcaj: nice one! (the xfce microreleases)
[23:31] <Noskcaj> ty
[23:31] <Noskcaj> The only thing currently MRE worthy is clipman, but i'll try and get parole 0.6.2 into trusty later
[23:31] <ochosi> bluesabre: clutter by default, not sure... thing is though, without installing it by default, ppl can't easily select/use it
[23:32] <bluesabre> right
[23:32] <bluesabre> discussion-worthy I think :)
[23:32] <ochosi> yup
[23:32] <ochosi> haven't checked how heavy clutter is
[23:32] <Noskcaj> There might be something we can MRE to precise too, if it's worth the effort
[23:32] <ochosi> night everyone!
[23:32] <Noskcaj> g'night ochosi
[23:33] <Noskcaj> clutter bring with it clutter transitions, for one
[23:34] <bluesabre> we're mainly using clutter because its backend seems to work on everything, and it works well in X or mir/wayland
[23:34] <bluesabre> but it is a bit more resource-intensive
[23:35] <bluesabre> but the clutter deps only add the option to use clutter, the x and xv backends are still selectable
[23:36] <bluesabre> Noskcaj: haven't pushed out 0.6.2 yet, will either do it tonight or tomorrow
[23:36] <Noskcaj> cool


[12:00]  * lool waves
[12:01] <davidm> #startmeeting
[12:01] <MootBot> Meeting started at 06:01. The chair is davidm.
[12:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[12:01] <NCommander> morning
[12:02] <davidm> persia, thanks for running meeting last week.
[12:02] <davidm> OK, from the top, action items from last week.
[12:02] <davidm> [topic] persia to file bugs to fix mobile-setup-wizard issues
[12:02] <MootBot> New Topic:  persia to file bugs to fix mobile-setup-wizard issues
[12:03] <lool> https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20090219
[12:04] <davidm> [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20090219
[12:04] <MootBot> LINK received:  https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20090219
[12:04] <lool> persia: around?
[12:05] <lool> ogra: woot
[12:05] <ogra> meep
[12:05] <lool> davidm: Let's skip persia's items for now, and we'll get back to  them at the end if he shows up
[12:05] <davidm> moving on
[12:05] <davidm> [topic] NCommander to take over driving ship-seed-for-mobile-images to close it (co)
[12:05] <MootBot> New Topic:  NCommander to take over driving ship-seed-for-mobile-images to close it (co)
[12:06] <NCommander> Done.
[12:06] <NCommander> Implemented during berlin.
[12:06] <davidm> OK
[12:06] <NCommander> Spec was closed too, fully tested under Steve's guidance
[12:06] <lool> is the bp status up-to-date?
[12:06] <NCommander> lool, should be.
[12:07] <davidm> [topic] NCommander to reset arm-softboot-loader to "Drafting", and work towards a solution in #ubuntu-arm over the next week.
[12:07] <MootBot> New Topic:  NCommander to reset arm-softboot-loader to "Drafting", and work towards a solution in #ubuntu-arm over the next week.
[12:08] <NCommander> Its on drafting, but nothing came out of u-arm (I didn't really get time to bring the subject up in depth)
[12:08] <lool> Carry over?
[12:08] <davidm> Lets look at this off line carry over for now.
[12:09] <davidm> [topic] davidm to update roadmap to reflect specs targeted for jaunty
[12:09] <MootBot> New Topic:  davidm to update roadmap to reflect specs targeted for jaunty
[12:09] <davidm> done
[12:09] <davidm> persia, you about?
[12:09] <lool> davidm: Was there a quick boot spec?
[12:09] <davidm> Foundations ended up with it.
[12:10] <lool> ok
[12:10] <davidm> [topic] ogra to add nslu2 enablement to the Roadmap
[12:10] <MootBot> New Topic:  ogra to add nslu2 enablement to the Roadmap
[12:10] <ogra> just done
[12:10] <ogra> :)
[12:10] <davidm> [topic] lool to follow up with NCommander to further extend the r
[12:10] <MootBot> New Topic:  lool to follow up with NCommander to further extend the r
[12:10] <NCommander> the r?
[12:11] <davidm> I'n  not sure what that was, incomplete sentence from last week
[12:11] <ogra> (moved "NSLU2 enablement" to Other though)
[12:11]  * NCommander has no idea if we extended it ...
[12:11] <ogra> NCommander, just do it :P dont always ask questions :P
[12:11] <lool> "the roadmap"
[12:11] <NCommander> Ah
[12:11] <ogra> ah :)
[12:12] <lool> I added some bugs to the RM, didn't particularly discuss with NCommander
[12:12] <davidm> OK
[12:12] <lool> Should be ok
[12:12] <davidm> [topic] NCommander to test fix for 280699
[12:12] <MootBot> New Topic:  NCommander to test fix for 280699
[12:13] <davidm> NCommander, ??
[12:13] <NCommander> I didn't see I was assigned to it, but the bug is closed in LP
[12:13] <NCommander> I think that number is wrong.
[12:13] <lool> The bug id is 280669 not 699
[12:13] <NCommander> Ooh
[12:13] <ogra> bug 280669
[12:13] <lool> " Doesn't detect second part of SSD drive on jax10  "
[12:14] <ogra> ah
[12:14] <lool> davidm: You can fail me on the next action   :-P
[12:14] <NCommander> i386 latest kernel had success. Haven't checked with lpia yet.
[12:14] <NCommander> I'll post results to the bug.
[12:15] <davidm> [topic] NCommander to finish drafting arm-softboot-loader
[12:15] <MootBot> New Topic:  NCommander to finish drafting arm-softboot-loader
[12:15] <davidm> lool, I did and moved on ;-)
[12:16] <NCommander> not a lot of progress, other things were on my plate
[12:16] <davidm> OK, I'll co
[12:16] <lool> Carry over
[12:16] <davidm> Moving on to roadmap
[12:17] <davidm> [topic] roadmap review
[12:17] <MootBot> New Topic:  roadmap review
[12:17] <lool> ogra: offline-installer?
[12:17] <davidm> ogra, offline installer
[12:18] <ogra> hmm, well, there is script for now, i didnt manage to add something on top of vm-builder as i would like to yet
[12:18] <ogra> i'll put the script into bzr and roll a ppa package for it
[12:18] <davidm> OK
[12:18] <ogra> seems many people use it though
[12:18] <lool> ogra: Anything else to do in the spec?
[12:19] <ogra> lool, a GUI, but given that we are post FF i'll develop that out of distro in PPA as well and make it adaptable for later vm-builder backend usage
[12:19] <davidm> ogra, ??
[12:19] <davidm> OK, thanks
[12:19] <lool> ogra: You should update implemenetaion status
[12:20] <lool> Either defer for jaunty or consider it beta available
[12:20] <davidm> unr-handling-jaunty Stevenk
[12:20] <ogra> oki
[12:20] <lool> BTW there's a bp title which is "Offline Installer" and is completely unrelated
[12:20] <davidm> Stevenk is making good progress
[12:21] <lool> I think we should have a look at the patch merging progress as well
[12:21] <lool> (Probably next week when stevenk is around)
[12:21] <davidm> and I am upgrading 7 bugs that are currently filed and milestoneing them
[12:21] <davidm>  general-resolution-for-touchscreen ogra??
[12:22] <ogra> evtouch seems our only bet here, there are still bugs with it
[12:23] <ogra> while upstream seems to have done some work on evdev all this is hardwired to the usbtouchscreen kernel driver
[12:23] <ogra> which only supports three devices
[12:23] <ogra> i'm just filing the necessary bugs for evtouch to track status
[12:23] <lool> ogra: Could you update implementation progress?
[12:23] <ogra> yep
[12:24] <davidm> arm-softboot-loader NCommander
[12:24] <NCommander> Previously discussed, in the progress of redrafting.
[12:24] <davidm> Actually we covered it's status already
[12:24] <davidm> selection-of-arm-images ogra
[12:24] <ogra> well, no kernels yet, as soon as we have them we'll have a tool :)
[12:25] <davidm> lpia-versus-i386 lool
[12:25] <davidm> this is defeered until next cycle is it not?
[12:25] <lool> No update, it's in good shape and only needs some infrastructure before jaunty + 1
[12:25] <lool> (Which is for infinity to setup)
[12:25] <lool> Will report if there's progress on this front
[12:26] <lool> (spec status is up-to-date)
[12:26] <davidm> OK that is the roadmap
[12:26] <davidm> on to bugs I guess
[12:26] <lool> Yup
[12:26] <davidm> bug #299847
[12:26] <lool> ogra, NCommander: you both worked on it
[12:27] <NCommander> I managed to work out its an alignment issue (the results change when you play with the padding)
[12:27] <ogra> well, its clearly identified, but there is no solution yet
[12:27] <lool> What's needed to move this forward?
[12:27] <NCommander> Normally GCC pads correctly onto the boundary, but this library does some weird things with structs
[12:27] <ogra> and it actually only showing on the buildds
[12:28] <NCommander> ogra, I was going to test it on the other piece of ARM hardware I got yesterday to see if it happens there
[12:28] <NCommander> It might also be worth a test on the slug, to see if it only happens on ARMv5
[12:28] <davidm> OK NCommander please test on your hardware
[12:28] <ogra> i will do that as soon as bug 331510 is solved
[12:29] <lool> The last comment says "it seems to be an alignment issue"; can we get a smaller test case of the alignment issue?
[12:29] <NCommander> lool, huh?
[12:29] <lool> NCommander: Can we get a smaller C test case reproducing the issue?
[12:30] <NCommander> Oh. Well, I can see the structs causing the breakage, I just need to figure out how to write some code that acts a test case
[12:30] <NCommander> The problem is this libraries structs are extremely odd (they're passing arries to unsigned shorts in functions)
[12:30] <lool> Well if it's sure it's an aligment issue, why do we need to test on other hardware?
[12:31] <NCommander> lool, mostly because I have no idea why we're having an issue. The kernel has a mechanism to correct alignment automatically.
[12:31]  * NCommander misspoke
[12:31] <NCommander> I'm fairly sure its the alignment. Its the only thing that seems to fit.
[12:32] <NCommander> Which, when enabled, still didn't fix the issue on the buildds, but changing the padding changes the results of the failures, and even causes different tests to fail.
[12:32] <ogra> hey, someone already added my bug to the roadmap ...
[12:32]  * ogra reverts his edit
[12:32]  * davidm is fast
[12:32] <lool> Ok, so NCommander are you taking the lead on this bug?
[12:33] <ogra> :)
[12:33] <NCommander> Yeah
[12:33] <lool> NCommander: Could you set yourself as assignee?
[12:33] <davidm> Ok
[12:33] <davidm> bug #322217: ixp4xx d-i firmware doesn't boot need to upload a changed APEX and rebuild d-i
[12:33] <NCommander> I'm going to kick upstream an email, maybe then can enlightment on the insanity of this library.
[12:34] <ogra> davidm, fixed
[12:34] <ogra> but bug 331510 newly introduced
[12:34] <davidm> ogra, are you taking the lead on this?
[12:34] <lool> ogra: What's the fix committed task in jaunty?
[12:35] <lool> ogra: on #322217; there's a task on linux; it's fix committed, what is it?
[12:35] <ogra> davidm, indeed
[12:35] <lool> "
[12:35] <lool> "
[12:35] <lool> adding linux task, teh endianess of the kernel image is wrong and needs to be flipped
[12:35] <lool> I guess it's done?
[12:35] <ogra> lool, thats done, right
[12:35] <ogra> firmware is done as well
[12:35] <lool> ogra: Could you close the linux task?
[12:35]  * ogra thought he closed all tasks already
[12:35] <lool> It's only fix committed
[12:36] <lool> ogra: bug 331510 isn't milestoned nor tracked for jaunty
[12:36] <ogra> lool, i just filed it at the beginning of the meeting :)
[12:36] <lool> ogra: Could you set milesone + track in jaunty + assign yourself ot it?
[12:36] <ogra> i'll do the paperwork afterwards
[12:36] <davidm> Ok
[12:36] <davidm> moving on
[12:36] <davidm> bug #319729: missing pselect() and ppoll() syscalls on ARM need to forward upstream to linux-arm-kernel
[12:37] <lool> amitk isn't around
[12:37] <lool> I think it was determined in the release meeting that this was fairly important
[12:37] <lool> There was discussion between pgraner and scott on they topic
[12:37] <lool> *the
[12:37] <davidm> OK OK will follow up with amitk off-line
[12:38] <lool> Ok
[12:38] <davidm> OK that was the end of the list any opens?
[12:39] <lool> can't think of any
[12:39] <lool> usual reminders about spec status and activity reports I guess :-)
[12:39] <davidm> OK then we can actually end the meeting early
[12:39] <NCommander> I do have a quick annoucement
[12:39] <lool> With persia and stevenk missing, we didn't cover much
[12:40] <davidm> Need to see what happened to persia
[12:40] <NCommander> As of last night, there are no more ARM specific failures in main. (there are a few general failures, and a few packages on x86 that got built on ARM by accident)
[12:40] <davidm> StevenK is on holiday today to tomrrow
[12:40] <lool> wow congrats
[12:40] <NCommander> (I nailed down KDE's last remaining main package
[12:40] <davidm> CGreat
[12:40] <NCommander> universe is slightly less happy, but at least main is on par with the Intel ports ;-)
[12:40] <lool> NCommander: on to universe and beyond!
[12:41] <NCommander> lool, on my todo already ;-)
[12:41] <lool> SCNR
[12:41] <NCommander> SCNR?
[12:41] <davidm> lool, what do we do about x86 packages that can't get built on ARM?
[12:41] <lool> davidm: If they don't make sense on arm, they should be listed in P-a-s
[12:42] <lool> It's just cosmetic I think
[12:42] <NCommander> We also have a few LP farts
[12:42] <NCommander> When the port was bootstrapped, LP ignored P-a-s at first on ARM
[12:42]  * NCommander looks at libx86 on ARM ...
[12:42] <davidm> I think we inherit  P-a-s from Debian?
[12:42] <lool> davidm: In all cases, no need to worry about it
[12:42] <lool> davidm: Yes
[12:43] <lool> davidm: Albeit I don't know whether it's still working properly as Pas moved to git in Debian and that needed some adjustments on our side
[12:43] <lool> Also the team maintaining Pas was made of 4 people actually connected to canonical IIRC, and the new team isn't connected at all I think
[12:43] <davidm> Ok thanks
[12:43] <lool> Actually 3/4 were related to canonical
[12:43] <lool> So I don't know whether that calls for a different handling of Pas or not
[12:44] <davidm> do we need to take this up with someone?
[12:44] <davidm> Ok lets take it off line and close the meeting
[12:44] <lool> davidm: We could do it as a low priority task I guess; reviewing whether more packages need to go in there and sending that to Debian
[12:45] <davidm> close meeting going once
[12:45] <davidm> lool, OK that makes sense
[12:45] <davidm> close meeting going twice
[12:46] <davidm> #endmeeting
[12:46] <MootBot> Meeting finished at 06:46.
[12:46] <lool> davidm: thanks for chairing
[12:46] <ogra> thanks
[23:45] <keffie_jayx> @now caracas
[23:46] <nhandler> keffie_jayx: The bot no longer manages the meeting schedule. Look at the Fridge's Google Calendar instead
[23:46] <keffie_jayx> nhandler, thanks


[01:26] <wgw> Hello, first day with Ubuntu-Mate: I was trying to download a program and it asked for my password, but I can't for the life of me remember it? Any help?
[01:27] <wgw> When i installed the program I remember it saying something about install as superuser. Don't know what that is.
[04:21] <kevin_> hola
[05:50] <alkisg> vlt: if you're on LAN, fat clients are the way to go... all these remote screen technologies will never be good enough for LAN, because you just can't fit 2.5 gbps per client on a normal gigabit lan
[05:50] <alkisg> LTSP may even completely drop thin client support in version 6
[11:04] <vlt> Hello. Nearly everything in my Ubuntu 16.04 MATE system is localized/translated, also Thunderbird but not its Lightning module. What do I need to install do get also that in my local language?
[15:15] <hugomonizdorego> Hello All
[15:42] <harold_> hi
[16:03] <dbrass> Anyone knows how to identify which software is responsible for an unlabelled notification icon in the notification tray in ubuntu-mate?
[17:36] <douglas_> can I also run unity 8 desktop in addition to mate on ubuntu mate 16.10?
[17:57] <sixwheeledbeast> You could use the Munity panel
[17:58] <sixwheeledbeast> or maybe install Ubuntu and then install the DE's you want to try.
[18:53] <nomic> z.z
[19:01] <vlt> Hello. Nearly everything in my Ubuntu 16.04 MATE system is localized/translated, also Thunderbird but not its Lightning module. What do I need to install do get also that in my local language?
[19:01] <Akuli> is it translated on windows?
[19:03] <vlt> I don't know.
[19:03] <Akuli> then it's possible that there are no translations for it
[19:03] <Akuli> maybe not in your language, maybe not in any language
[19:16] <alkisg> vlt, https://bugs.launchpad.net/ubuntu/+source/lightning-sunbird/+bug/545778
[19:22] <alkisg> vlc, debian sid does have proper packages, so we'll see them in ubuntu in the future, https://packages.debian.org/search?keywords=lightning
[19:28] <alkisg> vlt ^
[23:08] <vlt> And again: Thank you, alkisg!


[08:09] <constant__> hi all. can anybody tell me where displayconfig-gtk gets its' list of monitors from?
[08:10] <didrocks> constant__: Hi. I think that you'll get more answers on #gnome in irc.gnome.org
[08:11] <constant__> thnx didrocks!
[08:11] <didrocks> y/w ;)
[08:16] <constant__> is Bryce online or does it just appear that way..?
[18:53] <Nafallo> anyone noticed xorg acting up?
[18:54] <Nafallo> my alt acts as compose or something, and my right mouse button does not work.
[18:54] <Nafallo> no idea what's gone wrong, but I want it reverted before I go insane!
[18:54] <Nafallo> ehrm. make that MORE insane
[19:02] <Nafallo> so yeah. that was some random terminal starting instead of terminator.
[19:02] <Nafallo> likely a compiz bug I've assigned to mvo.
[19:06] <Nafallo> so ehrm... please do not reset compiz to use 'xterm' as my terminal application (whatever did that)
[21:13] <mpontillo> YokoZar: re: bug 371975, were you working to get that fix in upstream? I was looking at it to try to get the hang of the bzr workflow. I made the change here that was suggested to make it consistent with Evolution: http://bazaar.launchpad.net/~mpontillo/nautilus/ubuntu/revision/11?remember=8&compare_revid=8
[21:34] <mpontillo> ah, nevermind. just saw seb128's comment on that bug. which is why I asked; I agree that the best place to change it is upstream, and not in Ubuntu
[21:40] <mpontillo> by the way, I like the direction that bzr takes packaging. I felt less like I'm walking on eggshells, when compared to juggling patches by hand
[23:08] <YokoZar> mpontillo: Thanks for the patch!
[23:45] <mpontillo> np. odd; gnome's bugzilla didn't like the patch from quilt. http://bugzilla.gnome.org/attachment.cgi?id=134325&action=edit shows the filename but "View Attachment As Diff" shows "file_not_specified_in_diff"
[23:47] <hggdh> mpontillo, works for me
[23:51] <mpontillo> hggdh: really? I meant this link: http://bugzilla.gnome.org/attachment.cgi?id=134325&action=diff - the text in the gray background after "(-)"
[23:53] <hggdh> mpontillo, darn!
[23:53] <hggdh> I stand corrected
[23:53] <hggdh> weird
[23:55] <hggdh> mpontillo, take out the "a/"
[23:55] <hggdh> or "b/"
[23:56] <hggdh> you are one directory above


[00:00] <dev001> fullermd: There's a fc13 bug, https://bugzilla.redhat.com/show_bug.cgi?id=611405#c5, that seems to suggest that tho the warning exists, the problem has been negated.  hm ...
[00:01] <fullermd> As far as I know (which isn't too far, so don't put much weight on it), there's not actually a _problem_ that it's broken.    I'm widely known as a calm, patient, tolerant kind of guy.
[00:03] <dev001> heh
[00:05] <dev001> fullermd: i'll post @ https://launchpad.net/paramiko.  maybe that'll get some attention.  thx.
[00:12] <dev001> fullermd fyi -> https://bugs.launchpad.net/paramiko/+bug/271791.  already there ...
[00:15] <fullermd> Mightn't hurt to pile yourself onto that and up the count of people hitting it.
[00:18] <dev001> fullermd: piled.
[00:55] <mtaylor> james_w: fascinating ... related to something else I was just trying building source packages on a lucid box ... and there I'm getting :
[00:55] <mtaylor> tar: tests/r/information_schema.result: Cannot open: File exists
[00:55] <mtaylor> tar: Exiting with failure status due to previous errors
[00:55] <mtaylor> dpkg-source: error: tar --no-same-owner --no-same-permissions --anchored --no-wildcards -xkf - gave error exit status 2
[00:55] <james_w> mtaylor: yeah, that's what I get too. Did you see the dpkg bug that I filed?
[00:56] <mtaylor> james_w: oh - no. I should go look
[00:58] <mtaylor> there it is
[00:59] <mtaylor> james_w: so essentially I'm just screwed for now :)
[01:02] <james_w> mtaylor: yeah, not a nice way to fix it
[01:02] <james_w> mtaylor: you can get your packages building with an ugly solution
[03:54] <FryGuy-> is there anything I can do in bazaar about my horrible line-ending situation on windows? We're currently using sourcesafe, but I've just been using bazaar and merging the changes manually (and I wrote a script to push bazaar -> ss). This works great for the windows c++ code i'm using
[03:55] <FryGuy-> However, I'm doing another project now, with a different tool. We recently switched from a unix version of a tool, to a windows version of a tool, and it's been generating mostly CRLF, but some LF in everything it saves out
[03:55] <FryGuy-> Everything in sourcesafe gets set to LF (from what I can tell), but the tool writes out the files with a mix.
[03:56] <FryGuy-> When I try to commit my changes to bzr, it rightly says there's a bunch of changes. Is there anything I can do, short of dos2unix everything manually before checking in, to change this?
[03:58] <FryGuy-> and the tool gets seriously confused if I just change everything to CRLF (so I can't just change everything at once, and use the tool normally after that)
[04:02] <lifeless> you can probably use a filter
[04:04] <FryGuy-> would that help for things like qdiff?
[04:10] <lifeless> probably
[07:48] <vila> hi all !
[07:53] <AfC> ! lla ih
[07:53] <AfC> (we're upside down here)
[07:57] <methods2> can i edit a log message ?
[07:57] <AfC> methods2: short answer, no (which sucks, even if there is a good reason for it)
[07:58] <AfC> methods2: medium answer: if its your commit, and recent (ie, -1) then `bzr uncommit` & then re- `bzr commit`
[07:58] <AfC> methods2: otherwise, no
[07:59] <AfC> methods2: long answer, you _can_ use the evil rebase plugin, but assuming this will only change YOUR [copies of] revisions and not any revisions out in thew wild, causing history divergence, and the end result of not getting rid of the message you want to change
[07:59] <AfC> so,
[07:59] <AfC> methods2: no
[07:59] <methods2> lmao
[07:59] <methods2> ok
[08:00] <methods2> satic it is
[08:00] <AfC> {shrug} it's all a consequence of immutable revisions and the (good) idea of wanting to preserve history for future merging purposes.
[08:00] <methods2> :]
[08:00] <methods2> satic was the typo in my log message
[08:00] <AfC> yeah, well
[08:00] <AfC> you'll get over t
[08:01] <methods2> already am
[08:01] <methods2> but a part of me never will
[08:01] <methods2> lol
[08:01]  * AfC still hasn't
[08:01] <AfC> :)
[08:03] <vila> Well, as far as concepts are involved, immutable is more important than preserving history. Once you've published your revision you want to make sure that everybody is referring to the same thing via the revision-id...
[08:04] <vila> Regarding history, your log message *is* the one you typed when the revision was created, any change to that *should* be tracked.
[08:04] <vila> Now, when people ask about this feature, they are right.
[08:04] <vila> There should be a way to edit such details, but given the constraint above, it's not a trivial problem
[08:06] <vila> The solution is certainly around making rebase/rewrite easier to use for such scenarios ensuring that only a minimal amount of data need to be distributed so propagate this kind of change...
[08:06] <vila> s/so prop.../to prop.../
[08:07] <vila> i.e. editing log should be a first-class citizen operation
[08:08] <AfC> vila: sure
[08:08] <AfC> vila: we've talked about it; the problem is that every time we raise it
[08:09] <AfC> the whole discussion gets torpedoed because someone turns it into the generic history editing problem,
[08:09] <AfC> (including texts, parent/child relationships, metadata, and tags etc)
[08:10] <AfC> rather than just keeping it constrained to "I want to commit a revision (sic) that magically alters [overlays] a previous log message"
[08:10] <AfC> which really ought to be do-able.
[08:10] <AfC> whereas the general case is indeed nasty.
[08:12] <vila> Well, it is doable to day as you pointed out above. With some limitations that... can only be addressed by more-or-less adressing the general case. Managing a "simple" overlay will quickly become more complex once people (rightfully) ask: we both fixed the bogus log entry, which version should be kept ?
[08:14] <vila> AfC: We should *at* least make your "medium answer" easier to use for recent (> 1) commits
[08:14] <AfC> vila: which actually (much to my personal disgust) brought me [after 4 years of going to lots of trouble to convince people to write good log messages] to realizing that I probably would have been better off with a ChangeLog file after all.
[08:14] <vila> AfC: hehe, at least the ChangeLog is versioned and as such address the problem :)
[08:15] <AfC> vila: yeah... it sure would be nice for something to do that in 1 step... cutting and pasting the commit message as (quite unhelpfully) formatted & indented by uncommit is a pain in the ass
[08:16] <AfC> so I still write good(-ish) commit messages, but my enthusiasm has waned substantially.
[08:16] <AfC> anyway
[08:16] <AfC> there are bigger problems facing the human race
[08:16] <vila> Well, I do typos....
[08:16] <AfC> like,
[08:16] <AfC> vi vs emacs
[08:18] <vila> ... but I still consider commit messages as capturing the intent at commit time. I.e. best effort. Errors occur. Tracing fixes is good.
[08:18] <vila> So, I kind of like the fact that my typos get tracked :)
[08:19] <AfC> vila: yeah, but that's not the point, and we both know it; in most projects, commit messages ARE considered the ChangeLog entry, and those projects build their release notes right out of history. bzr is just not good at serving that need.
[08:20] <AfC> anyway
[08:20] <AfC> nothing new
[08:20] <AfC> tough problem
[08:21] <AfC> there are bigger problems facing the human race
[08:21] <AfC> like,
[08:21] <AfC> why is there cat hair in my keyboard?
[08:21] <AfC> like,
[08:21] <AfC> why do I have to move to another cafe to get a coffee?
[08:21] <AfC> (See ya :))
[08:22] <vila> :)
[08:56] <knittl> vila: you recommended using bzr ppa?
[09:00] <vila> knittl: yes
[09:00] <vila> any problem ?
[09:00] <knittl> yeah. there's no package for maverick
[09:01] <vila> 8-/
[09:03] <vila> maxb: Is there any reason for not building packages for maverick in the bzr ppa ?
[09:04] <bialix> who I can ask about lp:bzr-website?
[09:05] <vila> knittl: try https://edge.launchpad.net/~bzr-beta-ppa/+archive/ppa , it seems to contain the right stuff
[09:06] <knittl> okay
[09:06] <vila> maxb: is it just that you copy the packages for bzr-beta-ppa to bzr-ppa *except* for maverick ?
[09:08] <vila> maxb: hmm, or am I mixing bzr-beta-ppa with the 'proposed' one you mentioned (which I can't find on lp by the way) ?
[09:09] <vila> ha, found it https://edge.launchpad.net/~bzr/+archive/proposed
[09:10]  * bialix waves at vila and says bonjour
[09:10] <vila> bialix: hey sacha !
[09:10] <knittl> so i should use proposed? but there are only two packages python-testtools and subunit
[09:10] <vila> privet
[09:11] <bialix> poolie has already eoled, hasn't he?
[09:11] <vila> knittl: huh, I see the same packages in proposed/maverick than in bzr-ppa/lucid
[09:11] <bialix> sorry
[09:11] <vila> bialix: eowed on tuesday I think ;)
[09:12] <knittl> i don't xD
[09:12] <vila> knittl: argh
[09:13] <bialix> vila: oh, so he's enjoying vacation?
[09:13] <vila> knittl: I'm at a loss here, I didn't closely follow what happen there, we need to wait for GaryVdm or maxb to pop up
[09:13] <vila> bialix: AIUI, yes
[09:13] <knittl> ok. i'll be here
[09:14] <bialix> vila: ok
[09:21] <bialix> vila: as I can see from log now only poolie maintains the bzr-website. I guess I need to wait for his review for may changes
[09:22] <bialix> s/may/my/
[09:27] <vila> bialix: where is your mp ?
[09:27] <bialix> right now filing the first (trivial)
[09:27] <bialix> https://code.launchpad.net/~bialix/bzr-website/mailman-icon/+merge/33878
[09:28] <bialix> then want to update info on released versions because it's out of date
[09:31] <vila> bialix: cool, thanks for caring about that
[09:31] <bialix> vila: do you know either bazaar.canonical.com using lp:bzr-website to update regularly or not?
[09:33] <vila> bialix: I think it is
[09:33] <bialix> hmmm
[09:33] <vila> bialix: if not, it should :)
[09:35] <bialix> it seems my patch is not quite right. there is build.py script which (I think) ought to update the index.html. maybe the site updated regularly using build.py? strange, while there is generated index.html then? questions, questions, questions. I need to wait for poolie
[09:36] <vila> bialix: yeah, things like that should be documented in this branch
[09:37] <bialix> vila: there is readme but it seems incomplete now
[09:38] <vila> bialix: yup, my point exactly
[09:39] <zoyd> hi
[09:41] <zoyd> what's the 'svn update' equivalent in bzr; i have an incomplete 'bzr branch' checked-out
[09:44] <AfC> zoyd: depends on what hole you've got yourself stuck in, but
[09:44] <AfC> zoyd:
[09:44] <AfC> $ bzr pull URL
[09:44] <AfC> in that branch will probably get you where you want
[09:44] <AfC> on the other hand, if you did branch and it never finished,
[09:44] <AfC> I think you have to start again
[09:44] <AfC> [there's a bug open for that, I believe]
[09:44]  * zoyd tries
[09:45] <zoyd> hmm, appears like i'll have to start over
[09:53] <AfC> zoyd: if you're on a really dodgy network link
[09:53] <AfC> zoyd: then try
[09:53] <AfC> $ bzr init dir
[09:53] <AfC> $ cd dir
[09:53] <AfC> $ bzr pull -r 1 URL
[09:53] <AfC> $ bzr pull -r 10 URL
[09:53] <AfC> $ bzr pull -r 20 URL
[09:53] <AfC> ...
[09:54] <AfC> that'll get you (safe) incremental pull,
[09:55] <AfC> for whatever Δ you find sustainable
[09:55] <vila> you can even omit URL once the first one succeeds (or use --remember URL if/when needed)
[09:55] <AfC> vila: yes, of course you're right
[09:55] <vila> AfC: damn bzr fighting copy/paste :)
[09:56] <bialix> vila: what is landing procedure for lp:bzr-website branch? can you cancel merging of my first patch?
[09:56] <zoyd> and that will resume the download then?
[09:56] <vila> bialix: no idea, I tried to pqm it to see, and cancelling is... hard. Don't worry, I'll take the blame for it :)
[09:57] <AfC> zoyd: no, it'll pull whatever you tell it to.
[09:57] <AfC> zoyd: if you're on revno 10
[09:57] <AfC> and you say pull to revno 20, well, you'll get 11,12..20
[10:01] <vila> knock knock ? Am I still here ? (I've got a lot of network failures all at once, trying to find a pattern...)
[10:01]  * zoyd checks if there's a way to know what revision you're at .. "nnnnkB  nkB/s - Fetching revisions:Inserting stream" is very sparse
[10:01] <vila> zoyd: where are you pulling from ?
[10:01] <zoyd> lp
[10:02] <AfC> zoyd: no
[10:04] <zoyd> then, why not do a 'bzr pull -r <latest-revision>'?
[10:07] <vila> zoyd: lp seems down for me right now...
[10:07] <vila> zoyd: or at least experimenting transient failures, you've been warned ;)
[10:08] <zoyd> lp is very slow here
[10:08] <vila> zoyd: in generall or just now ?
[10:08] <zoyd> :)
[10:08] <vila> funny typo :)
[10:08] <vila> I can't ping it right now :(
[10:09] <vila> can't ping google.com either...
[10:09] <zoyd> bzr branch is reporting a '11059kB 1kB/s ..' but a 'du -sh .bzr' shows 4.1MB only
[10:10] <vila> zoyd: interesting... anything in .bzr.log ?
[10:12] <zoyd> hhm no
[10:13] <vila> ha, my dns servers are back...
[10:13] <zoyd> ok, now 'du -sh' updated to 6.3MB
[10:13] <vila> so is lp of course
[10:13] <zoyd> weird, the buffer wasn't written even after a 'sync'
[10:15] <zoyd> seems it dumps to disk after large intervals
[10:16] <zoyd> 14MB downloaded, but 7.5MB on disk. funny.
[10:17] <zoyd> no wonder the thing can't resume :)
[10:21]  * maxb pop us
[10:21] <maxb> *up
[10:21] <maxb> vila: Hi. The situation is simply that no one really took the decision to support maverick fully yet
[10:22] <maxb> Also, many of the packages are already up to date in maverick itself
[10:23] <vila> knittl: ^
[10:23] <vila> maxb: thanks !
[10:23] <knittl> ok. so maverick is as recent/outdated as the ppa
[10:23] <knittl> :D
[10:24] <vila> :)
[10:24] <vila> knittl: I guess my initial "use stable version" recommendation doesn't really apply to maverick ;-)
[10:25] <zoyd> btw, is a web-directory sufficient to publish a repository/branch, or does one need to open any ports?
[10:25] <maxb> knittl: what specifically is missing for maverick?
[10:25] <vila> zoyd: for read-access, http is good enough
[10:26] <vila> maxb: almost everytinh since only testtools and subunit are available ;)
[10:26] <maxb> erh?
[10:27] <maxb> Oh, well the PPA is naturally always to be used in conjuction with maverick itself, so there's no point in uploading to the PPA until there's something newer than maverick itself to upload
[10:27] <vila> maxb: https://edge.launchpad.net/~bzr/+archive/proposed?field.series_filter=maverick
[10:27] <knittl> well, i'll have to live with it ;)
[10:27] <maxb> live with what?
[10:28] <maxb> You can still install everything you need from maverick itself, AFAIK
[10:28] <knittl> not having 'nightly' builds
[10:28] <maxb> bah
[10:28] <maxb> If you want nightly, run from a branch :-)
[10:29] <vila> maxb: I recommended against that yesterday :) But I didn't realize knittl was running maverick nor what exactly he wanted
[10:30] <vila> knittl: also note that there is a work in progress to make python-2.7 the default in maverick while bzr 27 support may not be perfect yet
[10:30] <maxb> hmm. I'd love to continue this conversation, but I'm still in bed, and need to be in the office in a meeting in 30 minutes, so bye!
[10:30] <vila> maxb: hehe
[10:30] <knittl> have fun xD
[10:31] <vila> maxb: and thanks for popping up for the clarifications !
[10:31] <knittl> yeah. thanks :)
[10:33] <vila> knittl: by the way, maxb is fully right, maverick is pretty much as the same level than bzr-ppa/lucid so I don't think you're losing anything here
[10:33] <vila> knittl: what exactly to you need ? bzr ? plugins (which ones) ?
[10:34] <knittl> i'm comparing bzr+git+hg (again xD) and it would be good if i could compare the most recent versions
[10:35] <vila> knittl: then bzr 2.2.0 sounds good enough if maverick is the reference platform
[10:35] <knittl> git and hg is compiled from source
[10:35] <knittl> :P
[10:35] <vila> knittl: with different settings than the binary provided by maverick ?
[10:36] <knittl> no, but more recent
[10:36] <vila> I see
[10:37] <vila> knittl: so back to yesterday discussions, 'make' + 'python setup.py' ought to work, bugs welcome if not
[10:37] <knittl> yeah, bzr-svn complained ;)
[10:38] <vila> well, that's exactly the kind of problem I warned about :-)
[10:38] <knittl> i know
[10:39] <knittl> good ol’ plugin system, everybody brings in in discussions ^^
[10:40]  * jelmer wakes up
[10:40] <jelmer> knittl: I'm not following, what did bzr-svn complain about?
[10:40] <vila> knittl: yup and the ppas is the answer for people that don't want broken setups :)
[10:40] <knittl> version mismatch
[10:43] <vila> jelmer: hi :)
[10:53] <cbz> jelmer - i'm having a problem with certificates, pycurl appears to be choking on a wildcarded ssl certificate
[10:53] <jelmer> cbz: ah, ok - that wouldn't be related to bzr-svn though, it's an issue with pycurl in general.
[10:53] <cbz> jelmer: interestingly it seems to work on windows but break on linux
[10:55] <jelmer> cbz: Do you have pycurl installed on windows?
[10:56] <cbz> i guess it's using whatever is bundled in with the windows bzr installer
[11:05] <zoyd> oh, this checkout won't get done
[13:17] <bialix> vila: as I can see that patch is not landed, do you have any error message from pqm?
[13:18] <vila> bialix: yes, I got one, I'm not allowed to land. I tried to tell you but you had just disconnected, thank for poking (one less item in my stack :-)
[13:19] <bialix> vila: yep, i-net suddenly died for me. ok, thank you. I'll wait for poolie's review
[13:21] <vila> bialix: I had transient DNS faillures too, very unusual
[14:07] <rubbs> Ok, I know this question is probably asked billions of times, but is there a status on SVN externals type functionality? Being able to checkout/branch within another branches working tree? It's not that important for us, but the answer may influence which workflow i encourage (read force) my devs to use.
[14:10] <jelmer> rubbs, the feature you're looking for is called nested trees
[14:11] <rubbs> ah. I do some doc lookups. Thank you.
[14:11] <jelmer> rubbs, it's not implemented yet, though I've seen Martin say that it's one of the next things on his list.
[14:11] <vila> ghaa, what are the names of the plugins that offer an approximation of nested trees... my memory is failing right now :(
[14:12] <vila> scm-proj ?
[14:12] <rubbs> jelmer: ah, thanks. I think at this point I'll have to assume it won't be done in time.
[14:12] <jelmer> vila: bzr-externals, bzr-scmproj, config-manager
[14:12] <rubbs> We're looking to migrate in Oct/Nov time fraim
[14:12] <bialix> bzr-externals
[14:12] <rubbs> I'll check out bzr externals
[14:13] <vila> jelmer, bialix: thanks :-}
[14:20] <vila> how on earth can a python deprecation warning be emitted randomly....
[14:20] <vila> ...but persistently on babune...
[14:20] <rubbs> Well, first you must sacrifice a chicken, then throw salt in for directions... I'll just direct you to a black magic expert.
[14:21] <rubbs> ;)
[14:21] <vila> I do the chicken thing every morning, but tell me more about the salt one...
[14:54] <vadi2> bzr-fastimport mentions to do "front-end | bzr fast-import -", but I don't have front-end. Where does it come from?
[14:58] <maxb> vadi2: front-end is a placeholder term for "thing that exports from your source vcs". Which specific vcs are you exporting from?
[14:58] <vadi2> From git
[14:59] <vadi2> Can you suggest the command I should try? I'm not sure
[15:01] <vadi2> Ah, there is bzr fast-export-from
[15:01] <maxb> Yes, you could use that, or you could use git fast-export directly
[15:02] <montywi> hi!
[15:02] <montywi> anyone that can help with getting rid of a .THIS file that shows up in 'bzr gcommit' but doesn't exist on disk?
[15:03] <montywi> This happend after doing a merge where someone had deleted files changed in my tree, which I wanted to keep.  I copied the name.c.THIS file to name.c and did 'bzr resolved name.c' but now name.c.THIS still shows up in bzr gcommit
[15:04] <GaryvdM> montywi: What does bzr status say?
[15:08] <vadi2> How can I set a working tree for the bzr branch?
[15:09] <maxb> vadi2: bzr checkout (bzr co)
[15:10] <vadi2> Hrm. But I just created this branch and imported stuff from git into it. What do I check out?
[15:11] <GaryvdM> vadi2: Maybe you allready have a working tree. What does bzr info say?
[15:12] <vadi2> $ bzr info
[15:12] <vadi2> Shared repository with trees (format: 2a)
[15:12] <vadi2> Location:
[15:12] <vadi2>   shared repository: .
[15:17] <vadi2> It seems doing init again and re-importing worked, it's pushing happily now.
[15:22] <niemeyer> Hey there!
[15:22] <niemeyer> I'm trying to decide between looms and pipelines.. can anyone provide some insight into the difference between these?
[15:23] <niemeyer> Are either of these obsolete?
[15:23] <niemeyer> s/Are/Is
[15:23] <vadi2> Er, that went pretty terrible. All it did was duplicate my folders + files, with one set being what I want, and another set being taken off some other random branch...
[15:24] <vadi2> Is it possible to repair? All I did was import and then push to a new branch on launchpad
[15:33] <niemeyer> Found a useful thread about it
[15:33] <niemeyer> http://markmail.org/message/imo4jop3gcm3lgr4#query:+page:1+mid:sjjtebxtdh3th43m+state:results
[15:33] <vila> niemeyer: they are both maintained. I personally prefer looms but it seems to be a matter of taste
[15:33] <niemeyer> In case some else cares
[15:33] <niemeyer> vila: Cool.. I'm just finding it a bit hard to find anything comparing the two, and why someone might prefer one over the other
[15:35] <vila> niemeyer: both of them have some rough edges, my preference is mainly because I prefer to handle *one* loom rather than a set of branches. On the other hand some commands fly better with multiple branches than multiple threads. It heavily depends on your workflow...
[15:36] <niemeyer> vila: I don't have any workflow to handle the situation where I want to split work across several branches/threads/whatever to make it easier to review/merge/understand
[15:36] <niemeyer> vila: (besides a totally manual one)
[15:37] <niemeyer> vila: So I'm really trying to learn which workflow to adopt :)
[15:37] <niemeyer> vila: Do you know of any blog posts/documents which compare the workflows?
[15:37] <vila> "Looms on the other hand currently have no parent pointers per-thread. " is one such example. I.e. each pipe has its own branch.conf where loom has only one
[15:37] <niemeyer> vila: I see, that's interesting
[15:38] <vila> splitting will work for both and even the resulting graph should be pretty similar (but since I don't use pipelines I'm not definitive on this)
[15:38] <vila> s/graph/revision graph/
[15:39] <vila> 'switch' works for both too, it becomes important once you start pulling in your lowest thread (or first pipe).
[15:40] <vila> Generally your first thread is your upstream project and you then define successive layers that you want to propose/review independently
[15:41] <vila> so at commit time you decide where you want to commit. At various times you merge the lower threads into the upper ones (using 'up-threa' or 'up-thread <thread>')
[15:42] <vila> In any case you more or less need to know which threads haven't been merged up to the top
[17:23] <smoser> Hey all, I've got a question.  I'm wanting to create a bzr repository with results of test runs.
[17:23] <smoser> the log output is around 10M size .
[17:24] <smoser> is there any benefit to checking in a output-testrun.tar.gz rather than output-testrun/*.
[17:24] <dash> no, that's probably worse
[17:24] <smoser> If bzr is doing intelligent things in the repository, it seems like doing so may not buy me anything other than local storage (on checkouts)
[17:24] <smoser> which i really dont care about.
[17:25] <smoser> dash, thats what i was thinking.  My eperience with git is that it is very good at keeping .git to a small size.
[17:26] <smoser> bzr does similar things ?
[17:32] <rubbs> smoser: yes, it does do similar things
[17:33] <rubbs> IIRC bzr will even pack better than gz
[17:33] <smoser> so there is no good reason to compress the contents (other than a larger local checkout)
[17:34] <rubbs> with bzr, no, it's best to avoid checking in binaries as much as possible.
[17:34] <smoser> right.
[17:34] <rubbs> so if it's a log, your better off keeping it plain text and bzr will do the right thing.
[17:35] <smoser> so my only question, then woudl be if it is possible to check out only a given directory (or set of files) from a bzr repository
[17:36] <smoser> ie, not do a full checkout, so that i could avoid the local space if I had to, just to see files
[17:36] <smoser> (obviously I can just rm -Rf <other files> afterward, but wonder if i can only check out the onees i want)
[17:37] <rubbs> IIRC there is no way to check out only a subset of the branch at this point
[17:37] <rubbs> not sure if it's planned or not either
[17:41] <smoser> fair enough. In this case, I wouldn't mind having the whole repo (.bzr dir), but would only want to check out certain files at a given revision.
[17:41] <smoser> its probably not a common use case
[17:45] <rubbs> I think it's asked about every once and a while, but like I said I'm not sure about the planning or status of said feature.
[19:08] <niemeyer> lifeless: Sorry, I guess this is a better channel for that kind of question
[19:08] <niemeyer> Btw, just found out about bzr merge -i
[19:08] <lifeless> its nice :)
[19:08] <niemeyer> Does it actually bring the commit message/etc?
[19:08] <niemeyer> Or is it just a helper to cherrypick without history?
[19:09] <lifeless> its a helper to do partial merges
[19:09] <lifeless> so it has all the limitations of a cherrypick
[19:10] <lifeless> as/when cherrypicking is improved, it will improve
[19:10] <maxb> lifeless: Hi, do you possibly have time to read my email https://lists.ubuntu.com/archives/bazaar/2010q3/069878.html, and if you agree, activate a new ~bzr/builddeps PPA so I can work on that over the weekend? (New PPA requires team admin)
[19:11] <lifeless> maxb: I can certainly read it, but I'd want poolie to ack it - has he ? I say this because I'm a bit out of the loop on bzr right now
[19:12] <maxb> Fair enough. Is poolie travelling or something, do you know? I've not seen him on IRC for a while
[19:12] <lifeless> yah
[19:13] <lifeless> he may pop up today/tomorrow
[19:13] <niemeyer> lifeless: Ok, so no history merging..
[19:13] <niemeyer> (right now)
[19:14] <lifeless> yeah
[19:20]  * niemeyer starts a major manual branch split
[20:27] <ScottK> Does bzr support doing partial branches/checkouts, or is it required to branch/checkout the entire repository?
[20:28] <mkanat> ScottK: Whole branch.
[20:28] <mkanat> ScottK: But you could do a lightweight checkout, too.
[20:33] <ScottK> That makes checkouts faster, but doesn't really address my use case.
[20:34] <mkanat> ScottK: Okay. What's your use case?
[20:35] <ScottK> I've got a project were we'd like to have stuff in a bzr repo that only a few people actually need and it's a large/painful chunk of third party code.
[20:36] <ScottK> It'd be nice if there was some way the people who didn't need that could manage to not pull it down when they branch/checkout.
[20:36] <mkanat> ScottK: Hmm. Eventually, subtrees will solve that.
[20:37] <ScottK> I sold bzr on this project on the basis of svn people can use it like svn and git people can use it ~like git (dvcs anyway) and this is the one place we've run into where that's not quite true.
[20:37] <mkanat> Yeah.
[20:38] <mkanat> ScottK: Somebody else in this channel might have a better idea of how to solve your problem.
[20:38] <ScottK> OK.  Thanks.
[20:38] <mkanat> ScottK: If it's really only a few people that need it, though, you could just put it into a separate branch.
[20:38] <mkanat> But then they would have to know to branch that branch into the right place when checking out.
[20:39] <ScottK> Yep.  That's part of the problem, needing to know that and to know in advance what might need to be treated this way.
[20:39]  * mkanat nods.
[20:39] <mkanat> ScottK: I'm guessing this is an enormous amount of data?
[20:39] <ScottK> mkanat: Not in terms of say gigabytes, but compared to the rest of the tree, yes.
[20:42] <mkanat> Okay.
[20:46] <hno> Packaging question. Is there any good arguments why to package bzr-gtk + olive-gtk if also packaging qbzr + bzr-explorer?
[21:03] <ScottK> Some people have an odd affinity for gtk?
[21:15] <hno> ScottK: No idea. What triggered the question is that bzr-gtk just got dropped from Fedora due to not having an active Fedora maintainer.
[21:15] <dobey> what was the command to dump a revision's data in raw form?
[21:16] <ScottK> hno: I'm a fan of desktop environments that start with K, so you're unlikely to get good arguments from me.
[21:18] <hno> ScottK: I actuallly run Gnome, but never use bzr gui tools or even care what desktop environment i run in.. happy to run qt/kde apps under gnome when I need them.
[21:18] <rubbs> ScottK: not that it helps with checking out a subtree, but you may be able to hide some of that data with views.
[21:18] <maxb> Well, I do like bzr-gtk's integration into the libnotify notifications, even though I use qbzr for most stuff
[21:18] <dobey> bzr-gtk has some nice stuff
[21:18]  * hno maintains bzr for Fedora.
[21:18] <ScottK> The couple of times I've wanted a gui for bzr, I used qbzr.
[21:19] <dobey> ScottK: that's only because it's not called kbzr ;)
[21:23] <hno> dobey: can you specify what nice stuff you think bzr-gtk adds?
[21:26] <dobey> gdiff
[21:27] <james_w> the back button in gannotate
[21:33] <hno> dobey: The diff in bzr explorer looks nicer to me. But gdiff is a lot easier to run from the command line.
[21:34] <dobey> what's bzr explorer?
[21:34] <hno> james_w: Indeed. That back button is very powerful
[21:34] <hno> dobey: qbzr after it got split in qbzr qt bindings and bzr-explorer GUI application.
[21:35] <hno> same split is taking place for bzr-gtk btw.
[21:35] <mgz> hno: is gdiff from the commandline significantly different from qdiff?
[21:36] <dobey> i don't know. i don't really use bzr-gtk stuff any more
[21:36] <hno> mgz: Thanks. qdiff is equivalent to gdiff, and looks visually much nicer.
[21:39] <dobey> i don't think bzr-gtk has really been developed much in the 'look nice' department
[21:44] <mgz> s/bzr-//
[21:44] <hno> james_w: qannotate provides a full history view you can navigate. In some ways similar to the back button in gannotate, but not quite the same. Plus qannotate apparently have trouble showing revision numbers properly.. (cuts initial digits on revisions >999 for me)
[21:45] <hno> so +1 for gannotate there.
[21:45] <dobey> mgz: if you want to bash some toolkit, do it in #anti-$toolkit or something please
[21:45] <dobey> :)
[21:45] <mgz> :)
[21:49] <hno> The differences between qdiff and gdiff is not just pure visual candy. qdiff also shows a more detailed diff showing at character level what changed.
[21:50] <mgz> qbzr devs would probably be interested in you filing bugs on where you think they could improve qannotate hno.
[21:51] <mgz> might also be true for gdiff, but I'm not really sure there are any active devs.
[21:52] <hno> mgz: I know. Goal for tonight is to find if there is any reason for me to get bzr-gtk to resurrected in Fedora, or if it should be let to die until further notice.
[22:02] <hno> I thinks I will let it die in piece for now. Can easily get resurrected should someone feel sufficiently strongly that it's needed, and I guess we will know when Fedora14 ships without bzr-gtk.
[22:43] <Walex> Is there a largish (Linux kernel sized) publically accessible Bazaar2 repo that I may clone to play around with?
[22:43] <Walex> Either that or something not quite as large but still significant. Lots of small files (like headers, sources) in particular.
[23:45] <hno> Walex: Far from linux kernel size, but I find that the squid repository is sufficiently large to expose many sizing issues in bzr operations.. pretty sure there is larger examples around.
[23:50] <mkanat> Walex: I think people use the emacs repo usually for that.


[16:40] <delgurth> Hi: I'm using mibbit webirc and I'm trying to join #ubuntu-nl
[16:40] <delgurth> but I'm banned from there
[16:40] <delgurth> and I'
[16:41] <delgurth> and I'm not getting a +e ban for #ubuntu-nl I guess when I join #ubuntu-proxy-users
[16:47] <Myrtti> that channel is only for joining #ubuntu from mibbit
[16:53] <delgurth> so no way to join #ubuntu-nl from mibbit I guess?
[16:54] <Myrtti> SWAT, JanC ^
[16:58] <JanC> delgurth: AFAIK there are other people using mibbit in #ubuntu-nl ?
[16:59] <JanC> I see at least one at the moment
[17:00] <LjL> JanC: yes but you have a ban on part of his IP
[17:00] <Pici> JanC: *!?=52*@gateway/*
[17:00] <LjL> a small part of it, so he could easily not be the target of that ban
[17:00] <delgurth> perhaps better if I get a launchpad mask? ;)
[17:00] <LjL> delgurth: if you are an ubuntu member, you can get one
[17:00] <Pici> delgurth: unaffiliated cloaks do not override gateway cloaks.
[17:00] <JanC> I'll check our internal ban tracker  ツ
[17:01] <delgurth> I'm just a normal launchpad person, so guess it's not for me. And seeing above comment, won't help me either :)
[17:03] <delgurth> only helped a few people on the forums, that doesn't qualify me as a member :)
[17:03] <Pici> !member | delgurth
[17:04] <delgurth> cheers pici
[17:04] <delgurth> as said above, I'm not active enough to be one, yet ;)
[17:05] <delgurth> anyways, I'll wait till janc fixed my ban. Thanks for the help people
[17:05] <JanC> delgurth: I'm trying to find out who banned that address  ツ
[17:08] <tsimpson> 52* is quite a large range
[17:09] <tsimpson> 82.*.*.*
[17:12] <Nafallo> /8
[17:13] <Nafallo> Addresses in network    - 16777216
[17:21] <JanC> delgurth: I removed the ban
[17:25] <delgurth> JanC: thanks
[22:19] <calc> please kickban BSuntu from #ubuntu
[22:20] <calc> hmm someone beat me to it :)
[22:21] <tsimpson> calc: this channel doesn't deal with #ubuntu
[22:21] <calc> oh
[22:21] <tsimpson> and you should use the ops trigger if there is an issue, get's our attention quicker
[22:21] <calc> ok
[22:21] <calc> just !op or something like that?
[22:22] <LjL> yes
[22:22] <tsimpson> yes
[22:22] <LjL> best would be !ops | nickname-causing-trouble
[22:22] <LjL> only use it when it's needed, though
[22:24] <calc> ok
[23:45] <ubot4> In #ubuntu-cym, ianto said: ubot4: Croeso is Croeso i'r sianel Ubuntu Cymru