[11:23] <cyphermox> apw: ogra_ tells me you could possibly help me with a debug kernel for mako -- I'm trying to figure out what's up with SCO on the device and running into major problems, it would very much help if we could make sure WLAN_DEBUG is defined when building the prima staging driver, and for log level to be way up for MAC, SME, and BAP for that driver
[11:23] <cyphermox> (basically, any bluetooth-related crap)
[11:27] <ogra_> apw, i can do a cross build for him on my lappie, but that will likely take significantly longer so if you have some spare time that would be nice
[12:10] <Kano> Hi apw , why is 6.23 not in git?
[12:36] <apw> pththhth
[12:49] <Kano> apw: why is still no .orig file used?
[12:50] <ohsix> i think he probably gave you the answer you could expect for any question
[12:51] <Kano> well, it is really bad style when there is a final kernel
[12:51] <ohsix> oh, they're not making linux anymore?
[12:53] <Kano> well, usually is better to see the diff against a kernel release than only a complete tar or not
[12:53] <Kano> btw. using a tar.xz orig would be smaller as well
[12:56] <apw> Kano, change one thing at once, when i can get this heap of shit to build, then we can sort that out
[13:00] <Kano> btw. there is a new firmware file in linux-firmware.git
[15:45] <cking> apw,  what was the command you used to list out the udev CPU info the other day?
[15:46] <apw> cking, /var/lib/udev had that in
[15:55] <rtg> apw, pushed a 3.13.1 rebase since it looks like your bits are gonna build
[15:58] <apw> rtg, great
[17:09] <ogasawara> infinity: do we have any recommended docs for building custom netboot images?  (eg I want to build with a custom test kernel)
[17:09]  * ogasawara check the google
[17:10] <infinity> ogasawara: Probably not, but ask tomorrow, and me or Colin can give you guys some quick pointers.
[17:11] <ogasawara> infinity: ok thanks
[17:31] <jarkko> are you how busy here? :D
[18:36] <BenC> Anyone happen to have a system with a Broadcom 5720 and mind dumping the firmware for me?


[08:40] <knome> pleia2, not a great amount of #lovexubuntu submissions :/ we should bang it more...
[10:16] <bluesabre> knome: maybe show of some examples or current submissions so people have something to base off of?


[23:10] <naptastic> Hi! I have an Ubuntu 22.04 system and I'm gradually massaging its configuration into what I need. The motherboard has two Ethernet interfaces. I have both configured the same way (bridge slaves) but one still gets itself a DHCP lease even though it's not supposed to. Why, and how do I stop it?


[01:11] <_nemesis_> hallo, i found a bug, uptime: 02:04:31 up 8588 days, 23:09,  4 users,  load average: 0.41, 0.42, 0.35
[01:12] <_nemesis_> uname -a: Linux 8101 2.6.24-22-generic #1 SMP Mon Nov 24 18:32:42 UTC 2008 i686 GNU/Linux
[01:13] <_nemesis_> what can i also search for, to prove that this uptime is real ;)
[02:45] <phix> hey
[02:45] <phix> installing on an encrypted volume, LVM, on dual boot system, when defining  /boot partition grub is setup to boot off hd0,0 instead of hd0,1 and kernel for /boot/$kernel_version instead of /$kernel_version
[02:45] <phix> bug, some one file it, I CBF, my day off :P Lol
[03:17] <ScottK> lool: If you have any ideas about how to get that spec approved, I'm all ears.
[03:32] <phix> ScottK: what specs?
[03:54]  * Hobbsee scratches head at kees
[04:21] <NCommander> hey ScottK
[08:31] <karthik_>  hey i need to switch netween workspaces.. how does it happen internally in the code?
[09:04] <teddyb> hi
[09:05] <teddyb> http://packages.ubuntu.com/search?keywords=spice&searchon=names&suite=intrepid&section=all : doesn't have spice
[09:05] <teddyb> ubuntu has gnucap, but no spice, which is practically the basis for all circuit simulations
[09:06] <teddyb> gentoo pulls from: http://www.ibiblio.org/pub/Linux/apps/circuits/spice3f5sfix.tar.gz and creates a package. it'd be nice if a similar package was created for ubuntu
[09:06] <teddyb> my only worry is that the spice on that link is from 1999. not to say that old is bad, but if there hasn't been _any_ activity since, it's a bit concerning
[09:07] <teddyb> also gnucap isn't really fully compatible with spice. there are lots of annoying little fixes that have to be introduced to patch the differences
[09:08] <persia> karthik_, Look at libwnck
[09:10] <teddyb> this might help http://osmirrors.cerias.purdue.edu/pub/gentoo/portage/sci-electronics/spice/spice-3.5.5.ebuild : the ebuild has a few good tips to clean
[09:10] <teddyb> for example, spice doesn't like any more optimization than -O1
[09:12] <teddyb> also, this patch: http://osmirrors.cerias.purdue.edu/pub/gentoo/portage/sci-electronics/spice/files/spice-3.5.5-gcc-4.1.patch seems to be relevant
[09:13] <teddyb> i don't have ubuntu on me right now (i use ubuntu at uni, and my current computer is my old gentoo box). i'll see if i can get a vm running soon of ubuntu and i'll try to crank out a spice package
[09:13] <teddyb> that is if someone else isn't working on something similar
[09:14] <persia> teddyb, spice isn't very free: you might look at easyspice with ngspice or gEDA.  Alternately, if I'm wrong, you're welcome to submit a package.
[09:14] <teddyb> the other package i'd been longing for on ubuntu (and even on gentoo it's pretty unstable) is ngspice
[09:14] <teddyb> i checked out gEDA, but it needs a spice backend
[09:14] <persia> teddyb, See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[09:14] <teddyb> easyspice is a gui as well i believe
[09:15] <teddyb> will do. i have a slow connection, so it'll take a while :(
[09:16] <persia> teddyb, Actually, as it turns out, there are license issues even with ngspice: see Debian bug #299748
[09:16] <teddyb> i'm also not an expert by any means. i'm just a student who's trying to learn this on the side, but are you sure about the spice isn't very free line?
[09:18] <teddyb> hmm, well gentoo has a sci-electronics/ng-spice-rework ... i wonder what that is.
[09:18] <pwnguin> wha'ts wrong with ngspice?
[09:18] <teddyb> yeah, it's bsd and gpl-2?
[09:18] <teddyb> http://ngspice.sourceforge.net
[09:19] <persia> pwnguin, Dunno: the bug cites license issues, and it was removed.
[09:19] <teddyb> i'm still looking through the debian bug (downloading an ubuntu cd takes a lot of bandwidth, so pages load slowly :( )
[09:20] <persia> teddyb, Looking at http://embedded.eecs.berkeley.edu/pubs/downloads/spice/index.htm, it looks like it should have become free in 2007 (which is more recent than the 2005 date for the removal).  If you'd like to investigate, and get it back in, that wouldn't be bad, but be sure to only use the post-free sources.
[09:20] <teddyb> check this gentoo ebuild as well btw: http://osmirrors.cerias.purdue.edu/pub/gentoo/portage/sci-electronics/ng-spice-rework/ng-spice-rework-15.ebuild
[09:20] <teddyb> sure, i wouldn't mind.
[09:20] <pwnguin> odd. the guy who filed the legal issue bug had an ieee email
[09:20] <pwnguin> do they hand those out to all members?
[09:21] <teddyb> i guess it's good to keep on multiple distros. keeps everyone on their toes :)
[09:21] <teddyb> i think so
[09:21] <teddyb> have yet to get a membership (can't justify the cost yet)
[09:21] <persia> All full members, yes.]
[09:22] <pwnguin> have you seen oregano?
[09:23] <persia> Hrm.  The 1994 Berkeley "Research Software license Agreement" doesn't look all that free: it permits redistribution, but only gratis (or with charge for supporting materials), and has the advertising clause.
[09:23] <teddyb> oregano needs spice backend
[09:23] <teddyb> they are all frontends in ubuntu's repositories. the only exception is gnucap
[09:23] <teddyb> and it's good, but i've been running into a lot of problems rectifying the differences between what the ibiblio circuits books say to use for circuit simulations on spice and what gnucap will work with
[09:24] <persia> Well, it looks like spice got free in 2007, so with a bit of work, and some license review, it ought be suitable for inclusion.
[09:24] <teddyb> wonderful
[09:24] <pwnguin> "got free"
[09:24] <persia> pwnguin, Well, it was made more free.  See the homepage.
[09:24] <pwnguin> fyi, the guy who does the fedora electronics lab spin also pays attention to ubuntu
[09:25] <teddyb> lab spin?
[09:25] <pwnguin> a remix
[09:26] <pwnguin> comes with a bunch of things installed by default like gEDA
[09:26] <teddyb> oh, i thought you were being negative or something
[09:26] <teddyb> oh yeah, there's a fatty DVD of electronic programs available through gEDA iirc. ngspice is one of the things found on it
[09:26] <persia> Are Fedora remixes conventionally called "spin"s?
[09:27] <pwnguin> persia: i think so.
[09:27] <pwnguin> they only recently tried the idea
[09:29] <pwnguin> http://spins.fedoraproject.org/
[09:32] <teddyb> so it seems as though the spice3f5sfix is antiquated. would it make more sense to package ngspice then?
[09:33] <teddyb> especially considering ngspice is based on the berkeley spice3f5?
[09:33] <persia> teddyb, If ngspice inherited the freeness of spice, yes, but you'll want to check the licenses carefully.
[09:34] <teddyb> i don't know if i'm qualified to do that
[09:34] <emgent> HNY people.
[09:34] <teddyb> i'm not a lawyer and i don't want to taint ubuntu with legally dubious packages
[09:35] <teddyb> does ubuntu have any sort of legal consulation for package maintainers?
[09:35] <persia> teddyb, You can ask for input on the freeness of a license in #ubuntu-motu
[09:36] <persia> The ultimate decision lies with the archive admins, but they don't tend to have time to speculatively consult.
[09:36] <persia> If you can get a couple of the MOTU to agree that the license is probably free, the archive admins will review and check.
[09:36] <pwnguin> teddyb: you could always just ask debian about it ;)
[09:36] <persia> And you could always package it for Debian, and let Ubuntu inherit it :)
[09:37] <teddyb> oh true
[09:37] <teddyb> it'll hit main by 2035 ;)
[09:37] <pwnguin> in fact, i bet there's a rocket enthusiast who might appreciate ng-spice
[09:38] <persia> heh
[09:38] <teddyb> oh, just googling for ngspice debian gets a few packages already made
[09:39] <pwnguin> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489768
[09:40] <teddyb> particularly annoying: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489768#15
[09:40] <persia> Why is that annoying?
[09:40] <teddyb> that was more than a month ago, but then again, i guess thanksgiving, winter break, etc.
[09:41] <pwnguin> they may have forgotten to follow up
[09:41] <persia> Also, it means that someone else is chasing the licensing situation, which can only be a good thing :)
[09:41] <teddyb> well, i remember being tangentially interested in this in the summer and not getting much feedback from anyone related to ubuntu, so i quickly gave up and got back to other stuff
[09:42] <teddyb> but i really have nothing better to do, so might as well make it worth my while. i'll see if i can send an email out to either "Gudjon I. Gudjonsson"<EMAIL_ADDRESS>[09:42] <teddyb> or to the ngspice people
[09:42] <pwnguin> get some debian people interested in it ;)
[09:43] <persia> I'd recommend sending a follow-up to the bug first, asking about the status, just so nobody else does that: those working on it only need to be poked once.
[09:43] <teddyb> you keep ;)... but i'm not too sure why. are they difficult people to work with or something?
[09:43] <pwnguin> i donno
[09:43] <pwnguin> too lazy to use : i guess
[09:44] <teddyb> i know a lot of ubuntu people (developers especially) are extremely friendly and willing to help. colin watson definitely springs to mind
[09:45] <teddyb> and these two people i met on irc.. persia and pwnguin :)
[09:45] <pwnguin> well, if ngspice is good enough for ubuntu, its usually good enough for debian
[09:46] <pwnguin> in which case, you'd want someone in debian to take up debian's end of the deal
[09:46] <teddyb> what's ubuntu's policy with old packages that are no longer getting support by the way?
[09:46] <teddyb> like spice3f5
[09:46] <teddyb> is it better to have crufty old packages in the repositories just in case someone wants them?
[09:47] <pwnguin> well, if it's a case of "never works" it's probably a waste of compile time and just a gordian knot
[09:47] <persia> teddyb, Opinion is split.  There are several folk who argue they are potentially useful, and others that argue they should be gone.
[09:48] <pwnguin> if it's old and functional, I don't see the pain
[09:48] <teddyb> gordian knot.. hmm, wiki'ing. also, it works. i just compiled it earlier today and it works
[09:48] <pwnguin> i mean, by that criteria we would probably lose our only font editor
[09:48] <persia> Practical result is that packages typically get removed when either 1) they get removed from Debian, or 2) there are persistent unfixable compilation, runtime, or legal issues that attract the attention of a developer
[09:48] <teddyb> although, it was gentoo patched, which could mean the original source was a dog and i ended up with a stallion
[09:49] <pwnguin> well, upstream is active
[09:49] <pwnguin> in the case of ngspice
[09:49] <persia> teddyb, If the patches are good, there's no reason not to use them :)
[09:49] <pwnguin> so as persia says, no reason they can't be pushed upstream or sideways
[09:50] <persia> Generally, I prefer both :)
[09:50] <teddyb> yeah, but spice3f5 isn't. i'll definitely look more into ngspice, but since spice works as well... why not?
[09:51] <teddyb> anyway, i'm really tired, should head to bed. it's been a pleasure discussing this with the two of you. thanks for all your input
[09:51] <teddyb> goodnight
[09:53] <pwnguin> im super confused about where the tarball for ngspice-rework018 is
[09:54] <pwnguin> oh, apparently they don't know how to seperate packages correctly =/
[09:55] <pwnguin> so the mingw version supercedes -18
[12:33] <veloc1ty> moin
[13:17] <crid> Hi all. And happy new year!
[13:18] <crid> If I have some project I would like to see in repsitories of Ubuntu. What I should do?
[13:18] <crid> Project which I'm talking about is here: http://ait.berlios.de
[13:21] <sebner> !revu | crid
[13:23] <crid> thanks
[15:04] <anilg> Hi.. is there a bounty system at launchpad?
[15:05] <persia> anilg, There used to be, but it was mostly delinked or removed because it didn't turn out to work so well.
[15:06] <persia> anilg, For more detail, you might ask in #launchpad next week.
[15:06] <anilg> Thanks. Why next week?..
[15:08] <persia> Because it seems that most of the #launchpad folk are on vacation this week.
[15:21] <savvas> what's a bounty system? :p forgive my ignorance
[15:22] <persia> savvas, A place where one posts work one wants done, and remuneration on offer for the work.
[15:22] <persia> Others can add to the remuneration, or volunteer for the work.
[15:24] <savvas> like revu for packagers?
[15:24] <savvas> looks interesting, thanks
[15:24] <persia> Not really.  It's about money.
[15:24] <savvas> ah :P
[15:25] <savvas> now it makes sense :) rent-a-coder hehe
[15:26] <anilg> savvas: yes.
[15:26] <anilg> A bounty system makes sense on a palce like launchpad.. I wonder what didnt work out
[15:31] <savvas> anilg: What would happen if people place money on something they want done that doesn't get implemented? Would they allow team cooperation or single-person updates when using such a system and how would the team share the money, by length of bytes?
[15:32] <anilg> I would assume folks would collaborate, and start off with what everyone would do and how they would share the bounty
[15:33] <anilg> usually bounties are small tasks that individuals can take up
[15:33] <anilg> so its more of a do this and get this
[15:35] <savvas> then there's the possibility of abuse, a lot of people taking up a lot of tasks and never doing anything :p I hope that's not the case in the real world though
[15:36] <Mithrandir> not all bounty systems allow you to lock a bounty, it's just a race to completion.
[15:36] <savvas> and quality :)
[15:37] <savvas> but then people with money would actually run the development with "do this and do that" tasks
[15:37] <Mithrandir> savvas: yes, and?  It's not like you can't effectively do that today, if you have enough money.
[15:38] <Mithrandir> usually, bounties have been tiny compared to how much it'd cost to hire somebody to do the work
[15:38] <savvas> hm.. you mean making custom versions of programs?
[15:39] <savvas> without actually touching the official releases? if it wouldn't be dependant to the projects' trunk, then I'm all for it!
[15:40] <savvas> er.. * if the projects' trunk wouldn't be dependant to the tasks
[15:40] <Mithrandir> integration into mainline is usually a condition on most bounties.
[15:40] <savvas> yes, that :)
[19:52] <bbechdol> Hello everyone
[19:53] <bbechdol> Happy New Year :)
[19:59] <pwnguin> Mithrandir: i dont think the problem with the lp bounties was in the race to finish part; it's probably a function of a) tiny bounties funded by individuals and b) failure to aggregate bounty across individuals
[20:00] <pwnguin> so one guy says "i'll pay 20 dollars for this"
[20:00] <pwnguin> and another guy says "i'll pay 40"
[20:01] <pwnguin> lp didnt add up those bids; and nobody will work for a 20 dollar project
[20:23] <rootard> Hi all (and hny), I'm having a strange issue with dpkg unpacking a symlink that overwrites a file (in the same package)
[20:23] <rootard> This is on Nexenta (OpenSolaris) so it's not strictly an Ubuntu issue but I'm looking for some pointers on where to dive into
[20:24] <rootard> there is a file "/usr/bin/tcsh" and a link "/bin/tcsh -> /usr/bin/tcsh"  and when the package is unpacked (via dpkg -X tcsh_*deb /) then /usr/bin/tcsh becomes a link to /usr/bin/tcsh
[20:25] <rootard> however, if I unpack to another directory (dpkg -X tcsh_*deb tmp) then the directory structure is fine
[20:26] <andersk> Is there a reason you are unpacking the package to / rather than installing it (dpkg -i tcsh_*.deb)?
[20:26] <rootard> to try and debug the issue
[20:26] <rootard> dpkg -i   does the same thing
[20:27] <andersk> This sounds like what might happen if you somehow had /bin a symlink to /usr/bin (or vice versa), though that would be really weird.
[20:28]  * rootard smacks self
[20:28] <rootard> crap
[20:28] <pwnguin> heh
[20:28] <pwnguin> why would you do that?
[20:29] <rootard> good question... I don't know what that is done but it seems to be a Solaris'ism
[20:29] <rootard> :-/
[20:29] <rootard> *why
[20:30] <rootard> well, thanks. The patch to the package is simple then.
[20:35] <rootard> Hmm, if I were to make the patch a little more robust than just commenting out the "ln -s" in debian/rules, how might I approach this? I think hurd (last time I used it...) had some kind of crazy /usr -> /  setup.
[20:35] <rootard> so just detecting /bin to be a symlink isn't enough.
[20:36] <rootard> is there some (simple/portable) way to see if /usr/bin is the same as /bin ?
[20:39] <andersk> Checking whether /bin is a symlink with [ -L /bin ] is probably close enough.
[20:40] <andersk> It's dangerous for a package to install anything into a symlinked directory.
[20:40] <pwnguin> if the symlink is usually there in nexenta
[20:40] <pwnguin> it's probably the case that the nexenta developers have solved this before
[20:40] <rootard> I think it will always be there. I just checked a Solaris 10 host and it's the same
[20:45] <andersk> You could try checking whether [ "$(stat -Lc %D%i /usr/bin)" = "$(stat -Lc %D%i /bin)" ], I guess.
[20:48] <rootard> bash seems to support if [ /bin/ -ef /usr/bin/ ]
[20:49] <andersk> Oh, cool.  (So does dash.)
[23:49] <kolby_> are any developers here paid by canonical?
[23:52] <Hobbsee> a fair few of them
[23:52] <Hobbsee> likely not here right now, though
[23:53] <kolby_> I don't think I have a good enough resume to apply.


[13:34] <mlankhorst> greyback: so did you take a look yet why I get touch events instead of pointer events?
[13:36] <greyback> mlankhorst: with mir alone, or with unity8?
[13:39] <mlankhorst> unity8 only
[13:39] <mlankhorst> nested mir works normally
[13:57] <greyback> mlankhorst: ok, is because qtmir forwards on all input events as touch events - even if they started as mouse. Should be fixed by https://code.launchpad.net/~mir-team/qtmir/port-to-event-2.0/+merge/248067
[13:59] <mlankhorst> oke
[14:00] <mlankhorst> ah new version
[14:31] <mlankhorst> greyback: are you sure it works? i apply it from r310 onward onto my qtmir snapshot from the 0.11 ppa and I still don't get touch events
[14:31] <greyback> mlankhorst: I've tested it with Qt stuff, it appeared to work ok.
[14:34] <mlankhorst> do you recompile anything else?
[14:34] <greyback> nope
[14:35] <mlankhorst> hm what version of mir do you use? trying from the port-to-event one I get /QtSensors    -o CMakeFiles/unityapplicationplugin.dir/mirsurfaceitem.cpp.o -c /home/mlankhorst/nfs/xorg/port-to-event-2.0/src/modules/Unity/Application/mirsurfaceitem.cpp
[14:36] <mlankhorst> /home/mlankhorst/nfs/xorg/port-to-event-2.0/src/modules/Unity/Application/mirsurfaceitem.cpp: In member function âbool qtmir::MirSurfaceItem::updateTexture()â:
[14:36] <mlankhorst> /home/mlankhorst/nfs/xorg/port-to-event-2.0/src/modules/Unity/Application/mirsurfaceitem.cpp:396:21: error: âclass mir::graphics::Renderableâ has no member named âbuffers_ready_for_compositorâ
[14:36] <mlankhorst>      if (renderable->buffers_ready_for_compositor() > 0) {
[14:36] <greyback> mlankhorst: 0.11 was released, I'm working off that
[14:37] <mlankhorst> hm oke
[14:59]  * alan_g disappears to reboot
[15:17] <mlankhorst> greyback: lp:~vanvugt/mir/fix-buffers_ready_for_compositor breaks it on 0.11
[15:20] <greyback> mlankhorst: ah sorry, I thought PPA 12 had released. I'm working off mir 0.11 in that ppa
[15:20] <greyback> so you need to merge all the qtmir branches listed there too, in order for anything to compile
[15:21] <mlankhorst> which was sort of what I did..
[15:21] <greyback> fix-buffers_ready_for_compositor does not go anywhere near the input code
[15:21] <mlankhorst> except the other way around, grab your branch and stuff it on top of the qtmir there
[15:22] <greyback> which should work
[15:28] <greyback> mlankhorst: running your client with MIR_CLIENT_INPUT_RECEIVER_REPORT=log will at least show if you are getting mouse events or not
[15:28] <greyback> http://unity.ubuntu.com/mir/component_reports.html out of date
[15:29] <mlankhorst> oke
[15:29] <mlankhorst> odd, don't see anything from that
[15:39] <mlankhorst> do you need debug enabled or something?
[15:50] <mlankhorst> greyback: can you try yourself with my xmir package? see if you get touch or mouse events..
[15:52] <greyback> mlankhorst: I can. Where is your xmir package? And what x app should I run?
[15:53] <mlankhorst> xev is fine
[15:53] <mlankhorst> ppa:mlankhorst/ppa, I was only getting events when holding mouse buttons in my xev window
[16:05] <kgunn_> alf_: since duflu is out of sync, would you mind keeping an eye out for assisting greyback in debugging ?
[16:05] <kgunn_> alf_: long story short...seems there's a bug, but can't repro with demo server
[16:05] <kgunn_> only happens with xmir
[16:06] <alf_> kgunn_: sure
[16:07] <alf_> greyback: ^^ let me know if you need something
[16:07] <greyback> alf_: will do, am trying to repro currently
[16:14] <greyback> mlankhorst: here's a sample of hte output I'm getting from xev: http://pastebin.ubuntu.com/10144336/
[16:15] <greyback> mlankhorst: the first chunk is pure mouse motion
[16:15] <greyback> the second chunk is me interacting with the touchscreen
[16:15] <greyback> I'm unsure how to interpret those MotionNotify events
[16:15] <greyback> what should a touch event look like to X?
[16:32] <mlankhorst> greyback: do you only get events when the button's down?
[16:33] <greyback> mlankhorst: no
[16:33] <greyback> all motion events are being reported
[16:42] <greyback> mlankhorst: there's something going weird with branches though. Trying to merge fix-buffers_ready_for_compositor into port-to-event-2.0 does nothing for me, and the build fails for that reason
[16:54] <greyback> mlankhorst: try this branch, it works for me with mir 0.11: lp:~gerboland/qtmir/port-to-event-2.0-with-mir0.11
[17:29] <racarr> Morning, lemme know if this xmir-event/2.0-qtmir thing I see in backscroll needs assistance :)
[17:29] <mlankhorst> greyback: weird..
[17:57] <racarr> confirmed that OSK bug is gone from silo
[18:27] <greyback> yays


[19:37] <dudedude> bueller
[22:59] <kaendfinger> Hello!
[23:00] <kaendfinger> I need a team for an Application. Will you guys look at it and refer me to somebody who can help? https://bitbucket.org/pagepress/pagepress/


[12:21] <enyc> OoOoOOo didnt realize this channel existed...
[12:23] <enyc> Query on tracking-down an installer-annoyance...  In 18.04 installer custom partitioning  keeps "auto-mounting" linuxswap-partitions (even if manually onmounted before starting ubiquity)..
[12:24] <enyc> This makes creating/formatting a new crypto partition impossible (even if not using the swap for the encrypted install), it complains about unsafe-swap mounted etc...  and/or other failure cases in trying to modify partitions because swap mounted --    Any idea if this is acutalyl a ubiquity-issue  or some underpinning udev/systemd/whatever thats' setup for live-cd-mode that does stuff upon
[12:24] <enyc> rescanning ptbl etc?.
[12:26] <enyc> I notice theres' a large number of bugs (and old bugs!) in launchpad associated with ubiquity ...  suspect many defunct now.
[15:52] <enyc> I'm happy to collect syslogs and whatever...  but be good to be given a $clue on above please =)


[08:59] <koell> Can someone help me? I've placed the "file menu" applet in my lxde panel. Now if I click on it I get a dropdown of my home folder. But when I click on open folder or open terminal, nothing happens. Also its really weird there are no files shown, only folders.
[14:34] <leszek> hi
[15:56] <Subroutine> sorry, if someone did reply to my question, can you do it again, my irc dropped for a minute
[15:59] <Ahmuck> hi.  i added spanish language to my lubuntu install, however now i am unable to spell check english, only spanish.  is there a way to switch the language from one to the other in lubuntu?
[16:02] <Subroutine> Ahmuck: you can change language in preferences>Language support
[16:05] <Ahmuck> Subroutine: does not work
[16:06] <Ahmuck> the dialoge states that English is the last language and anything after that is ignored
[16:06] <Ahmuck> however, it's not ignored
[16:06] <Ahmuck> when I move Spanish to the top by dragging it places it at the top rather than under English (US)
[16:06] <Ahmuck> I however want English (US) to be at the top of the list in that order
[16:06] <Ahmuck> something broke?
[16:10] <Ahmuck> my real problem is i've lost spell check support for thunderbird an d libreoffice.  they are spell checking for spanish, which is ok, but not prefered
[16:12] <Subroutine> Ahmuck: dont know if this will help, but i would try removing spanish and if you spellcheck works afterwards try readding spanish again
[16:13] <Subroutine> there probably is better way of doing it, but i dont know - im still pretty noob for linux
[16:25] <Subroutine> i have added commands to ~./config/lxsession/Lubuntu/autostart instead, but where can i add them for all users?
[16:34] <Subroutine> Ahmuck: also look at this http://ubuntuforums.org/showthread.php?t=1977274
[17:35] <koell1> Does someone use Dropdown folder applet in lxde panel?
[19:11] <urielvigilant> How to install Nokuntu on Lubuntu
[19:11] <urielvigilant> How to install Nokuntu on Lubuntu


[04:15] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/use-new-processor/+merge/186228
[04:23] <wgrant> StevenK: k
[04:24] <StevenK> wgrant: Thanks, it'll land after 49-0 hits devel.
[04:24] <wgrant> Yes
[04:37] <StevenK> wgrant: Microservices?
[12:32] <Ursinha> wgrant, cjwatson, https://code.launchpad.net/~ursinha/launchpad/bug-1201485/+merge/186305


[00:00] <james_w> the bug on the nightlies was that they didn't build them at all
[00:01] <james_w> pyrex wasn't installed because the usual debs don't need it as the tarballs contain the c files
[00:01] <lifeless> oh!
[00:01] <lifeless> righto
[00:01] <james_w> I fixed that, but neglected to check the paths
[00:01] <lifeless> so, can you check then, that the so's are going to the right place
[00:01] <lifeless> and if they aren't make the build fail
[00:01] <james_w> just looking now
[00:01] <lifeless>  / workaround
[00:02] <lifeless> I'd rather the dailies fail if the .so's won't be available to the user.
[00:04] <james_w> todays uploads have python*/*-packages/bzrlib/*.so
[00:04] <lifeless> thats great
[00:04] <james_w> I can add a check that that glob matches something at build time
[00:04] <lifeless> please
[00:05] <lifeless> look for one of the pyrex based ones
[00:06] <lifeless> Noldorin: http://pastebin.ca/1533156
[00:10] <ronny> sup
[00:10] <ronny> lifeless: what are the current plans for python3 support?
[00:10] <Noldorin> lifeless: same result
[00:10] <lifeless> ronny: there aren't any
[00:11] <lifeless> Noldorin: can you paste the output please?
[00:11] <Noldorin> sure
[00:11] <lifeless> ronny: by which I mean, that we'll accept patches making it easier to use a porting tool etc
[00:11] <Noldorin> lifeless: http://pastebin.ca/1533161
[00:11] <lifeless> ronny: but we need to keep supporting python 2 for 5 more years or so
[00:11] <lifeless> ronny: and python 3 is basically a different language/platform
[00:12] <lifeless> Noldorin: _wow_
[00:12] <lifeless> Noldorin: can you do that again, with -Dtransport please
[00:12] <Noldorin> sure
[00:13] <Noldorin> indeed, it is behaving rather unusually :P
[00:15] <Noldorin> lifeless: http://pastebin.ca/1533166
[00:20] <Noldorin> lifeless: making any sense to you?
[00:21] <lifeless> Noldorin: yes, look at lines 33, 34, 35
[00:22] <lifeless> we read a file twice
[00:22] <lifeless> then get an error renaming the directory above it
[00:22] <lifeless> I suspect this is just too much damage to reliably work around it
[00:22] <lifeless> showing that trace to your sysadmins should convince them something is wrong pretty quickly :)
[00:22] <lifeless> I'll update the bug with more info
[00:23] <Noldorin> heh, fair enough
[00:23] <Noldorin> thanks :)
[00:23] <lifeless> and do whatever I can to help them get to a cause
[00:23] <Noldorin> lifeless: do you recommend i just point the admins to the bug report, or specifically this trace?
[00:25] <lifeless> Noldorin: both I suspect
[00:26] <Noldorin> right
[00:27] <Noldorin> not sure what i can expect them to do however :(
[00:27] <Noldorin> if the problem is due to IIS6
[00:27] <lifeless> IIS has many options
[00:27] <lifeless> it could be a backing server
[00:27] <lifeless> they can file a bug with microsoft
[00:27] <lifeless> etc
[00:27] <lifeless> I wouldn't want to assume they can't do anything ;)
[00:28] <Noldorin> yeah, i know
[00:28] <Noldorin> it certainly doesn't heart to try
[00:28] <Noldorin> it's just i'm not optimistic!
[00:28] <Noldorin> but yeah
[00:28] <Noldorin> if you could update the bug report with the new info, that would be great :)
[00:29] <lifeless> I will be doing so shortly
[00:29] <Noldorin> great
[00:30] <Noldorin> the latest -Dtransport trace should really be attached there, of course
[00:47] <spm> *** FYI. restarting codehosting for a Cherry Pick ***
[00:52] <JoaoJoao> Hello
[00:53] <lifeless> hai
[00:54] <JoaoJoao> So, when I cancelled a bzr merge, when I tried the same bzr merge, bzr complained about already existing upload packs
[00:56] <Noldorin> lifeless: i have to go now, but i plan on emailing my host tomorrow.
[00:57] <Noldorin> if the bug report will be updated by then, that would be helpful
[00:57] <Noldorin> anyway, i'll let you know the result.
[00:58] <JoaoJoao> it looks like it's related to the bug https://bugs.launchpad.net/bzr/+bug/165293
[01:01] <Noldorin> lifeless: is that alright...? if you're busy, i could always update it myself. but i feel you understand the issue significantly better than me
[01:04] <lifeless> Noldorin: Its in my queue to update
[01:04] <Noldorin> :)
[01:04] <Noldorin> right ho
[01:04] <Noldorin> bye
[01:04] <lifeless> JoaoJoao: you hit ctrl-C while bzr was doing the merge?
[01:06] <JoaoJoao> yep
[01:07] <lifeless> ok, I suspect you've found/provoked a bug in the final insertion stage
[01:07] <lifeless> what repo do you have - info -v will tell you
[01:07] <lifeless> it prints a repository line
[01:08] <lifeless> Noldorin: bye ;)
[01:08] <JoaoJoao> you mean the format?
[01:09] <JoaoJoao> it's 2a
[01:09] <lifeless> ok
[01:10] <lifeless> bzr dump-btree .bzr/repository/pack-names
[01:10] <lifeless> pastebin the output (its not personal)
[01:24] <lifeless> JoaoJoao: ^
[01:30] <lifeless> igc: could I beg three reviews off you?
[01:30] <lifeless> https://code.edge.launchpad.net/~lifeless/bzr/bug-398668/+merge/10288
[01:30] <lifeless> has two reviews listed in the last comment
[01:30] <lifeless> and after that, the main branch itself
[01:33]  * lifeless foods
[01:35] <JoaoJoao> lifeless: I'm not at the computer with the repo, I'll post that tomorrow, ok?
[01:35] <lifeless> ok
[02:05] <lifeless> bbiab
[02:58]  * igc lunch
[03:22] <[1]reggie> anyone got a second to answer a question about bundles?
[03:22] <bob2> best to just ask
[03:22] <[1]reggie> sorry
[03:22] <[1]reggie> our commit messages have a bundle file attached.  I uncommitted some revs and then reverted them (mistake).  now I want to reapply from the bundles
[03:23] <[1]reggie> but when I save a bundle file to my desktop and then do bzr merge <bundle file>  it just says nothing to do
[03:23] <[1]reggie> this is bzr 1.1
[03:23] <[1]reggie> 1.17
[03:24] <[1]reggie> I thought the bundle file contained the "diff" of the revision and it could be applied right from the bundle
[03:29] <jam> [1]reggie: if you are getting 'nothing to do' that probably means the changes are already merged (by ancestry, if not by diff)
[03:29] <jam> I'm not user about "uncommitted some revs and then reverted them"
[03:29] <jam> if you reverted some changes and then committed
[03:30] <jam> then I would see how you would get the behavior you are seeing
[03:30] <jam> *uncommit* should remove them from the ancestry, such that 'bzr merge' will re-apply it.
[03:30] <[1]reggie> jam, could the problem be the encoding of the bundle?  it's not a readable diff.  it's encoded for email
[03:30] <[1]reggie> does merge handle the unencoding or do I have to do that?
[03:31] <jam> [1]reggie: possible. If we can't detect that it is a real bundle, then we would probably try to merge the containing dir
[03:31] <jam> though last I looked at the code, it would read through as much as it could to find the # Bazaar bundle ... header
[03:31] <jam> even if it was in the middle of an email
[03:31] <jam> (inline vs attachment)
[03:31] <lifeless> I suspect a commit-of-the-revert rather than an uncommit
[03:31] <jam> [1]reggie: so my initial thought is that you didn't uncommit as much as you thought you did
[03:31] <lifeless> so the bundle is already merged, as jam says above
[03:32] <[1]reggie> i basically did several bzr uncommit --local
[03:32] <jam> [1]reggie: there is also the possibility that you could pull the revision-id directly from the bundle
[03:32] <[1]reggie> and then a bzr revert
[03:32] <jam> [1]reggie: uncommit --local will be negated by you next 'bzr update'
[03:32] <jam> *your* next
[03:32] <jam> since you didn't uncommit the remote revs
[03:53] <[1]reggie> jam, ok,  sorted some things out but I hit a new snag
[03:53] <[1]reggie> the uncommit command told me that I coudl restore to this tip by running a certain bzr pull command
[03:53] <[1]reggie> but I neve rpushed the commits that I uncommitted
[03:54] <[1]reggie> and when I run the pull command it says the branches have diverged and I need to run bzr merge
[03:54] <[1]reggie> but bzr missing says I'm up to date and bzr merge says nothing to do
[03:54] <[1]reggie> I thin it is confused
[03:54] <jam> [1]reggie: are you doing "bzr merge . -r revid:..." ?
[03:54] <jam> not just plain "bzr merge"
[03:55] <[1]reggie> the command it gave me to run was bzr pull . -r<EMAIL_ADDRESS>[03:55] <[1]reggie> but that says 'these branches have diverged'
[03:57] <jam> [1]reggie: because you've done commits since the uncommit, the histories have diverged
[03:57] <jam> you can do "bzr merge . -r<EMAIL_ADDRESS>[04:41] <RenatoSilva> Instead of keeping a changelog file for changes in software releases, I want to keep a changes_from_previous file, that is, a changelog for the current release only, so that each changeset would be a revision of that file matching the related release. What do you think, is it a good idea?
[04:56] <doctormo> I wanted to ask if it's possible to warn someone if they are about to commit a forbiden (or highly questionable) file type, such as pdf, doc, jpeg. We want to make sure our learning courses for ubuntu have only the sources.
[04:58] <lifeless> yes, a precommit hook can do policy checks and abort commits that fail $whatever-your-policy is
[04:59] <doctormo> useful
[05:07] <spm> doctormo: fwiw, if you go down that path - don't just rely on "*.(pdf|jpg)" for example; Suggest you use file(1) against the suspect. Assuming I'm not telling you stuff you didnt already know. :-)
[05:08] <doctormo> spm: This is an offical Ubuntu project to teach people how stuff works, the course writers will need help understanding bzr to get into development. I was thinking gtk-bzr
[06:45] <johnjosephbachir> if both branches and checkouts can be branches, what is the value of having a mirror branch vs a mirror checkout?
[06:45] <johnjosephbachir> s/can be branches/can be branched
[06:46] <ronny> johnjosephbachir: branches carry the history along
[06:46] <ronny> checkouts just point to it
[06:46] <johnjosephbachir> so do non-lightweight checkouts
[06:46] <johnjosephbachir> they carry all the history
[06:47] <fullermd> If you're never committing to it, there's no significant difference.
[06:47] <bob2> if you are, the default merging behaviour differs
[06:47] <fullermd> Though of course, you can't really branch a checkout.  When you think you are, you're branching a branch, which you find by pointing at a checkout of it.
[06:47] <bob2> 'bzr up' can do unpleasant things
[06:47] <johnjosephbachir> okay
[07:03] <vila> hi all
[07:04] <vila> hmpf, massive upgrade all around, massive reboots will follow :) bbar
[07:11] <spm> hey vila-massive-reboots!
[07:24] <gsuveg> re
[07:27] <gsuveg> i srtongly thinkig about write netbeans bzr plugin
[07:31] <lifeless> that would be great
[07:31] <gsuveg> i use netbeans
[07:31] <gsuveg> and doesnt exist bzr only git
[07:58] <vila> lifeless: inserting CountingDecorator has no effect (unsurprisingly but I checked anyway), do you still want it ?
[07:59] <lifeless> vila: it totally should for parallel=fork
[07:59] <vila> lifeless: yeah, we both wish, but it doesn't work
[08:00] <lifeless> do you get a progress bar?
[08:00] <lifeless> parallel=subprocess will add its own decorator.
[08:00] <vila> oh yes, I always have a pb, the # tests is missing though
[08:01] <lifeless> I mean a counter ;)
[08:01] <vila> yes, I got the counter but without indication of how many tests *will* be run, I can live with that for a while though
[08:02] <vila> it's better than not having it (man, 2 weeks without it... such a joy to get it back ;-)
[08:02] <lifeless> ok
[08:02] <lifeless> I did the better API
[08:02] <lifeless> it needs a review I think, in subunit. You could do that if you wanted ;)
[08:02] <vila> Already ? Great, I'll have a look
[08:03] <vila> lp:~lifeless/subunit/push-pop-progress ?
[08:06] <lifeless> something like that
[08:06] <lifeless> a week and a bit back actually ;)
[08:06] <vila> yeah. 20090808 sounds like that
[08:08]  * fullermd begins to lose hope that bundlebuggy will display the page...
[08:08] <vila> lifeless: I still can't imagine when you can have a negative delta with PROGRESS_CUR, care to enlight me ?
[08:09] <vila> fullermd: wait for abentley to be bacl from vacations and restart his BB host ?
[08:09] <fullermd> Well, I don't so much have any _need_ to see it...
[08:10] <vila> stop hoping then :)
[08:10] <vila> but he's supposed to come back today...
[08:10] <fullermd> That's sorta my mantra.  Everything's easier when you give up hoping   :)
[08:10] <gsuveg> nono. hope is important
[08:11] <vila> I think the trick is not to give up but to accept that not all hopes can be fulfilled :)
[08:11] <vila> ... and keep smiling anyway (yeah, right...) :-D
[08:14] <fullermd> It takes more muscles to frown than to smile, but it doesn't take any to just sit there with a stupid expression on your face.
[08:14] <lifeless> vila: test filtering
[08:17] <vila> lifeless: ooooh, excellent, thanks
[08:40] <OllieR> will be a bzr up stop if a shell session is terminated/
[08:40] <OllieR> ?
[08:45] <lifeless> OllieR: if it gets SIGHUP'd
[08:45] <lifeless> its up to your shell
[08:45] <OllieR> ok so yeah the update would fail?
[08:46] <OllieR> can you do a disown on that command then
[08:46] <bob2> screen's easiest
[08:46] <OllieR> i tried but then it asks for a password and doesn't allow my input
[08:47] <OllieR> can't think how I would do it
[08:47] <fullermd> That's what nohup is for...
[08:49] <OllieR> ok but can i issue a password with nohup?
[08:50] <lifeless> I'd use screen
[08:50] <lifeless> :)
[08:51] <fullermd> nohup doesn't disconnect it from the terminal.  It just blocks SIGHUP.
[08:53] <fullermd> Of course, it also may screw with std{out,err} and do other such manipulation, so something like screen can be a better choice (and for other reasons as well), but it's a simple choice.
[09:00] <OllieR> lifeless: thanks screen is ideal :)
[09:09]  * igc dinner
[09:43] <thumper-afk> can we move cbranch into bzr.dev?
[09:43] <thumper> it is the only reason I still have bzrtools
[09:49] <vila> thumper: You just don't like bzrtools, are you ? I knew it...
[09:49] <thumper> vila: I love it
[09:49] <thumper> I use cbranch and shelve
[09:49] <thumper> now shelve is in trunk
[09:49] <thumper> I want cbranch there too
[09:50] <thumper> because right now, bzrtools won't run with bzr.dev or the nightly ppa
[09:50] <thumper> which for me is a serious PITA
[09:50] <vila> Yeah, you want to empty bzrtools, you don't like it, stop pretending :-D
[09:50]  * vila is afraid the initial joke went unnoticed :-D
[09:51] <pygi> vila, :P
[09:51] <vila> thumper: hmm, bzrtools still hasn't relaxed it's compatibility policy and refuse to load ?
[09:52] <thumper> no...
[09:52] <thumper> vila: I did notice
[09:52] <thumper> vila: I just ignored it :)
[09:52] <vila> thumper: abentley is coming back from vacations today right ? The patch is easy enough (jam used such a patched version to build the windows installers)
[09:53] <thumper> vila: oh, I'm sure it is simple
[09:53] <thumper> vila: but this isn't the first time things have gotten out of sync
[09:53] <thumper> vila: and since it is pretty trivial to make this right
[09:53] <thumper> vila: lets DTRT
[09:54] <vila> thumper: as for your initial question, past 2.0 the overall worflow UI will be reworked so certainly cbranch feature will be taken into account
[09:54] <lifeless> I wouldn't want to bring cbranch in before 2.0
[09:55] <lifeless> and after 2.0, well as vila says theres a big overhaul to do
[09:55] <vila> thumper: ha ! You're preaching the chore (sp?) !! But try again with abentley :-D
[09:55] <thumper> well, we're almost there now anyway
[09:55] <thumper> I know, I know, I'm just frustrated
[09:55] <lifeless> thumper: talk to your wife about that :)\
[09:55] <thumper> I'm running the 1.18 branch build locally instead of my system installed package
[09:56] <fullermd> vila: "choir".  Though, for some of us, choir WOULD be a chore...
[09:57]  * vila giggles
[09:58] <vila> fullermd: by the way, using merge proposals on LP is now the preferred way for submissions,
[10:00] <vila> fullermd: regarding your DWIM revisions, 1) using mp will ensure a better tracking, 2) it will certainly get more attention once 2.0 is out 3) Can't you try it as a plugin ? Such features are really hard to judge without using them for a while....
[10:00] <fullermd> Well, that requires uploading a branch, rather than just sending a bundle.  And that means either waiting forever, or stacking, and from all the fun stacking seems to be giving everyone for 2a upgrades...
[10:01] <vila> fullermd: bzr.dev is not in 2a (yet) and push is stacked by default on lp and works flawlessly, just give a try, really
[10:01] <fullermd> I don't see how it could work as a plugin, since it requires changing functions.
[10:01] <vila> *All* merge proposals (i.e. the vast majority of landed patches) for the last releases came from stacked branches on lp
[10:01] <vila> monkey patching ?
[10:01] <fullermd> Well, yeah.  If it were in 2a already, issues stacking causes upgrading to 2a would be moot   :)
[10:02] <fullermd> (and for changes like those trivial cleanups in revspec.py in my other [MERGE], it seems insane to create and upload branches for 3 lines of change)
[10:03] <fullermd> I'm vaguely aware of what monkey patching it, but I haven't the slightest idea how to go about it, nor would I want to if it were at all avoidable.
[10:03] <thumper> fullermd: pushing a stacked branch to lp is pretty quick
[10:03] <vila> you should talk to lifeless one of these days, he add some n lines patches (with n quite small) landed in no time with that
[10:03] <thumper> fullermd: also, when the merge directive stuff for 2a is sorted out
[10:03] <thumper> fullermd: you can use bzr send
[10:03] <thumper> fullermd: and LP will create the branch for you
[10:04] <OllieR> does anyone else get this. I commit a single character change in one file and I need to upload 3mb for the commit to finish. doesn't make any sense...
[10:04] <vila> thumper: hey ! Right I think the md stuff *is* sorted out (in trunk if not in 1.18), what email should be used ?
[10:04] <fullermd> It's still conceptual overhead of having a branch around, for a change I could write on my hand in ballpoint.
[10:05] <thumper> vila: well, LP needs to be updated for it to work
[10:05] <vila> fullermd: ho, come on, the point is how that branch/bundle is handled *once* you have created it
[10:05] <vila> thumper: ha, right,
[10:05] <fullermd> I'm also still ill at ease with the fact that the LP merge requests go off to the team, not the list.
[10:05] <thumper> vila<EMAIL_ADDRESS>[10:05] <vila> thumper: thnks for the reminder, sry for being lazy :)
[10:06] <fullermd> Maybe with internal stuff that's no difference, but with something like the DWIM revspecs, which is a user-visible change, I'd sure like the opportunity for users on the list to be able to see and comment on it before it lands or is rejected.
[10:06] <vila> fullermd: right, I keep forgetting that, because, in my case, all the mp related mails are filtered in the same mailbox than the list :-/
[10:06] <fullermd> I feel like the move to LP reviews really cuts off a lot of the chance for community desirability discussion.  Maybe that's intentional.
[10:06] <vila> fullermd: not intentional !!!!
[10:06] <fullermd> Well, it is for me too ('cuz otherwise it ends up in the -bugs mailbox.  Have I mentioned how much I hate LP's mail sending stuff lately?)
[10:06] <vila> eeerk, how can you imagine that :-(
[10:07] <fullermd> I don't, quite, but nobody seems at all concerned that essentially all the code reviews are no longer seen by anybody other than the devs and a few non-dev masochists like me who joined the team...
[10:07] <vila> I had some troubles to define my filters correctly but it's all godd now and *I* am quite happy with lp mails...
[10:08] <vila> fullermd: that's a good point, I really think every dev has more or less handle the filtering and don't realize that ...
[10:09] <vila> fullermd: there were talks at one point about tagging the mails and let people tweak some preferences in their subscription, I think it's worth raising the point again
[10:09] <OllieR> modified system/application/models/select_model.php (I added one word to this file)
[10:09] <OllieR> [###############-    ]   9211kB @   26kB/s | Uploading data to master branch - Stage:Copying content texts:Copied record 178/196
[10:09] <OllieR> It just seems crazy
[10:11] <vila> fullermd: Anyway, overall, I'm convinced there is value in your DWIM rev spec and that surely is worth discussing and get more exposure, I was trying to give my understanding on the apparent lack on feedback so far
[10:11] <fullermd> OllieR: What protocol are you talking across?
[10:11] <OllieR> sftp://
[10:12] <fullermd> So it's presumably repacking something, which requires downloading N% of the repo, then re-uploading it.
[10:12] <OllieR> fullermd: ok so is there any way to speed this up?
[10:12] <fullermd> If you can use a smart protocol, that should all happen server-side, and not have to shuffle the data across the network twice.
[10:14] <vila> OllieR: keep in mind that if it's indeed a repack that is occuring, it shouldn't occur frequently (1 every 10 then 100 then 1000 commits)
[10:15] <vila> OllieR: another option is to issue 'bzr pack' on the server side, but that also requires bzr on the server
[10:16] <lifeless> OllieR: its bzr doing autocompaction
[10:16] <lifeless> OllieR: it will happen very rarely, and it keeps the repository performance good
[10:18] <OllieR> fullermd: how do you mean a smart protocol?
[10:18] <fullermd> OllieR: bzr[+something]://
[10:20] <domas> I just wanted to share how I am pleased with 'bzr co'  grabbing 600M of RAM  on my virtual machine :-))
[10:22] <lifeless> domas: do you have the C extensions? they can help a _lot_
[10:22] <domas> I hope I do, um. :) I guess I'd use PPA builds
[10:27] <OllieR> This is think is the problem
[10:27] <OllieR> checkout of branch: /home/bazaar/mycompany/example.com/screenings/trunk
[10:27] <OllieR>    shared repository: /home/bazaar
[10:28] <OllieR> so every tree uses a single shared repository dispite the fact that they are usually not related
[10:28] <OllieR> i.e. /home/bazaar/mycompany/example2.com/web/trunk is completely different code to /home/bazaar/mycompany/example.com/screenings/trunk
[10:31] <OllieR> http://bash.pastebin.com/m646edb67 - 7gb repo
[10:33] <OllieR> Could anyone advise on this setup?
[10:35] <fullermd> Well, it sounds like a situation where you (not necessarily you personally, but you somebody-associated) control the server.  So using bzr+ssh instead of sftp probably wouldn't be all that hard.
[10:35] <fullermd> And it would certainly mitigate issues like this by not getting the network involved in stuff it doesn't have to be.
[10:37] <OllieR> i just ran a bzr pack on the server and then committed again from my local system and it was a lot faster
[10:37] <OllieR> I will look into bzr+ssh
[10:37] <lifeless> OllieR: the pack didn't make a difference :)
[10:38] <OllieR> fullermd: do you know if having one shared repo for all projects is a bad idea? I would assume I should have a shared repo for each project...
[10:38] <lifeless> OllieR: the previous commit had already done the tuning :)
[10:38] <OllieR> lifeless: I cancelled the commit, as it was taking forever
[10:38] <OllieR> then can a pack on the server
[10:38] <lifeless> ah
[10:38] <lifeless> ok
[10:38] <OllieR> then committed from local
[10:39] <fullermd> OllieR: Well...   it doesn't _gain_ you much, in cases where there's no shared history.
[10:40] <OllieR> fullermd: but it could potential slow things down?
[10:40] <fullermd> And at some level, it will slow things down, since there's a lot of data there you can't possible care about at any given moment, you've got more to troll through to find the stuff you do.
[10:40] <fullermd> Now, whether that's significant, is an empirical question...
[10:41] <fullermd> I'd say that putting repos at project boundaries makes more sense, since that's where most of your sharing is.
[10:42] <OllieR> yeah everything on this dev box seems to all of a sudden slowed right down
[10:42] <fullermd> I think it's axiomatic that one-repo-for-everything is going to be slower.  But how much slower?  If it's 2% slower, who cares?  If it's 20% slower, that may be another matter.
[10:43] <fullermd> It seems unlikely for it to have caused a sudden dropoff, unless you just put something new and huge into it.
[10:43] <fullermd> A 300 meg project in a 7 gig repo is going to be slower than a 300 meg project in its own 300 meg repo.
[10:43] <fullermd> But it'll still be way faster than a 7 gig project in its own 7 gig repo.
[10:45] <OllieR> ok thanks for the info
[10:46] <lifeless> generally we have log tree depth
[10:46] <lifeless> so it shouldn't matter much
[10:46] <lifeless> 200+ way fan out on a typically B+Tree index in recent repo foramts
[10:47] <lifeless> which is to say, you need 200 times as much data to add a single additional level to the index.
[13:04] <andrea-bs> Hello! How can I upgrade the working tree of a branch?
[14:17] <NEBAP|work> hi
[14:17] <NEBAP|work> I´m using bzr push to push the history to a location that is backed up daily
[14:18] <NEBAP|work> now using push with (X:\Folder\Folder) also uploads the working tree what I don´t need
[14:18] <NEBAP|work> what can I do to prevent doing this?
[14:19] <hmeland> See "bzr init-repo --no-trees".
[14:20] <NEBAP|work> so I should initialize the repo on the server at first?
[14:20] <hmeland> Yes, as a parent directory of wherever you're pushing your branch to.
[14:21] <hmeland> You can use e.g. a sftp:// URL to "bzr init-repo".
[14:21] <NEBAP|work> so sometimes push just pushes the history and sometimes it pushes the working tree, too, depending on the protocol?
[14:23] <hmeland> Depends on both the protocol you're pushing over (sftp, local file access, etc.) and how the destination has been set up prior to the push.
[14:23] <garyvdm> hmeland: you can also just do bzr remove-tree REMOTE_BRANCH
[14:24] <NEBAP|work> k
[14:24] <garyvdm> I meant NEBAP|work ^^
[14:24] <garyvdm> NEBAP|work: I would do what hmeland suggested if you are pushing multiple branches.
[14:25] <NEBAP|work> so if I want to push to a non-existing local location without pushing the working tree, I should do:
[14:25] <NEBAP|work> bzr init-repo --no-trees
[14:25] <NEBAP|work> bzr push
[14:25] <NEBAP|work> ?
[14:25] <hmeland> You can use "bzr reconfigure --use-shared --with-no-trees X:\Folder\Folder" to convert your existing stand-alone branch to a shared repository without any working tree.
[14:26] <NEBAP|work> hmm
[14:26] <hmeland> NEBAP|work: Yes, with the appropriate target arguments.
[14:26] <NEBAP|work> using push with the ftp protocol automatically pushes only the history
[14:26] <NEBAP|work> does it create a shared repo automatically?
[14:26] <NEBAP|work> or is it still a standalone tree without the working tree?
[14:27] <hmeland> No, but updating the working tree over ftp isn't done, due to it being hard to detect whether there would be any conflicts.
[14:27] <NEBAP|work> k
[14:28] <NEBAP|work> so using ftp the push destination is still a standalone tree?
[14:29] <hmeland> Yes.  You could then later do "bzr update" in a shell on the target host to update the working tree.
[14:29] <NEBAP|work> k
[14:29] <NEBAP|work> no that was just for info :)
[14:30] <NEBAP|work> just thinking which is the better solution, creating a shared repo and pushing to it
[14:30] <hmeland> Whereas that wouldn't do anything in a branch in a tree-less repo.
[14:30] <NEBAP|work> or deleting the working tree of the standalone puhs ..
[14:30] <NEBAP|work> s/puhs/push
[14:34] <NEBAP|work> would be good to offer an option to push without the working tree like "bzr push --no-trees"
[14:42] <jam> morning all
[14:42] <jam> fjalvingh: are you around?
[14:42] <jam> vila: how's it going?
[14:43] <vila> morning jam !
[14:43] <fjalvingh> jam: morning, Jam
[14:43] <NEBAP|work> jam: morning
[14:43] <vila> going fine, but I reailzed time is running and I tsill haven't reviewed 1.19-merge_sort :-/
[14:45] <jam> vila: I was wondering about that. as I made sure to submit it before you woke up, and yesterday you said "I'm ready to review" :)
[14:46] <vila> jam: yeah, went into balancing --parallel=fork and ran into bumps... mutli-thread debug is so fun ;)
[14:58] <vila> jam: and besides, when i said "ready to review", I had actually reviewed most of your commits, but you added ~15 more :-)
[15:04] <vila> jam: overall you added new implementations in tsort, leaving the old ones without deprecating them, right ?
[15:05] <vila> hmm, not really :-/
[15:05] <jam> vila: I moved tsort.topo_sort, but not merge_sort
[15:05] <jam> I don't want to implement 'mainline_revs'
[15:05] <jam> and some other stuff
[15:05] <jam> because it is cruft
[15:05] <jam> And there is at least 1 place that needs to add a node to the graph
[15:06] <jam> before calling merge_sort
[15:06] <jam> so I need that functionality before I can completely deprecate the existing implementation.
[15:06] <vila> yeah, re-reading your cover letter, sorry for the noise
[15:07] <Stavros> hello
[15:07] <Stavros> i have a bunch of commits in my repo which I did, but different computers show different names. can i change them?
[15:10] <vila> abentley: welcome back !
[15:10] <abentley> vila: Thanks!
[15:13] <Stavros> any idea how i can change my email address retroactively in commits?
[15:13] <vila> Stavros: short answer: you can't
[15:13] <Stavros> aw
[15:13] <Stavros> long answer?
[15:14] <vila> there were talks about 3 distinct solutions (none fully available  yet AFAIK):
[15:14] <vila> 1) use some variation of bzr-rebase
[15:15] <vila> 2) handle some aliases in bzr so that the same user can be "credited" for all his emails
[15:15] <vila> 3) fast-export, hack hack, fast-import (this is rude :)
[15:15] <quicksilver> write a script which rebuilds your repo one commit at  atime
[15:16] <quicksilver> saving commit messages but altering email addresses
[15:16] <quicksilver> and also changing your boss's name to BADGER BADGER BADGER BADGER BADGER, just because you can.
[15:16] <Stavros> hmm, can i export the repo in a format i can easily parse and substitute the emails?
[15:16] <luks> which is what the fast-import/export method does
[15:16] <Stavros> quicksilver: i am the boss :(
[15:16] <Stavros> so i'll go with MUSHROOM
[15:16] <vila> Stavros: LOL
[15:16] <Stavros> what's fast-export/import, btw?
[15:17] <Stavros> also, is bzr-rebase useful/mature/stable?
[15:17] <luks> http://bazaar-vcs.org/BzrFastImport
[15:17] <luks> and yes, it is
[15:17] <vila> https://edge.launchpad.net/bzr-fastimport
[15:18] <Stavros> oh aha, interesting
[15:18] <Stavros> let me get that
[15:19] <Stavros> hmm, i need to run something other than setup.py install?
[15:21] <fjalvingh> Stavros: you might just do bzr branch lp:bzr-fastimport fastimport into your bzr plugins dir
[15:21] <Stavros> ah right, thanks
[15:22] <Stavros> how can i get the branch without the repo?
[15:22] <fjalvingh> Stavros: lp: means get repo from Launchpad?
[15:23] <Stavros> yes, i mean get just the "clean" copy, without the .bzr dir
[15:23] <Stavros> i guess i can just delete it afterwards
[15:23] <fjalvingh> Stavros: just remove the .bzr afterwards.
[15:23] <Stavros> thanks
[15:23] <fjalvingh> Stavros: It won't hurt though and you can easily update later on
[15:24] <Stavros> that is true, i should redownload it
[15:24] <vila> Stavros: or you can use 'bzr export' to get a clean tree
[15:25] <fjalvingh> Stavros: just "bzr pull" inside the branch
[15:25] <vila> Stavros: but why do you want that ?
[15:26] <Stavros> vila: OCD :P
[15:26] <vila> Stavros: ha, good, fine, no problem, JDI :)
[15:27] <Stavros> what's jdi?
[15:27] <Stavros> also, i figure i can do bzr co lp:bzr-fastimport and then bzr up whenever i want to update
[15:27] <jam> Stavros: "just do it"
[15:28] <Stavros> ah
[15:28] <Stavros> hmm, this fast-export file is binary
[15:28] <Stavros> i was hoping for base64 encoding or something
[15:29] <Stavros> i can't edit this without breaking it..
[15:29] <fjalvingh> Stavros: It is not really binary; it is text intermixed with blobs which can be binary
[15:29] <Stavros> fjalvingh: yes, but editing will break the blobs
[15:29] <fjalvingh> Stavros:  Only if you edit inside them
[15:30] <Stavros> really? text editors can handle that sort of thing?
[15:30] <Stavros> should i use vim?
[15:30] <fjalvingh> Stavros: some can; you could also try something like sed or so
[15:30] <Stavros> ah, that should work very well
[15:31] <fjalvingh> Stavros: but before trying all this: be aware that this will make a new, idependent repo
[15:31] <fjalvingh> Stavros: so if you have other branches lying around merges will no longer work
[15:31] <Stavros> so i won't be able to push it to the parent repo any more?
[15:32] <jam> Stavros: well, you could push --overwrite, but otherwise no
[15:32] <fjalvingh> Stavros: only by overwriting.
[15:32] <Stavros> hmm
[15:32] <Stavros> that might be acceptable
[15:32] <Stavros> i will try
[15:32] <jam> Stavros: you basically say "this is the new ancestry, forget about the old"
[15:33] <Stavros> ah
[15:33] <Stavros> hmm
[15:33] <fjalvingh> Stavros: and one other thing: if you have renames followed by edits in the same commit (something common in Java) import will probably fail..
[15:34] <Stavros> hmm, that shouldn't be the case, thanks for the heads up though
[15:40] <Stavros> it crashes with "cannot import name serializer", that's odd
[15:40] <Tak> hrm, is it normal for a pull to show all pulled changes as conflicts?
[15:41] <Stavros> Tak: not normal, but it can happen
[15:41] <Stavros> if you changed things, that is
[15:42] <igc> night
[15:42] <fjalvingh> igc: Good night
[15:43] <[1]reggie> bzr tag keeps giving me bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~mysql-clr-team/connectornet/6.1/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
[15:43] <Tak> well, yeah, they're valid changes from upstream, but all the conflicts are empty for tree, with stuff in merge-source
[15:43] <Tak> so I'm not sure why they weren't just merged in
[15:44] <[1]reggie> I've done bzr lp-login <my login name> and then done bzr push --remember lp:<lp home of project>
[15:44] <[1]reggie> but bzr tag still is trying to use http instead of bzr+ssh
[15:44] <[1]reggie> what am I doing wrong?
[15:45] <Stavros> jesus, 1.17 is out? what am i doing with 1.13?
[16:00] <[1]reggie> nm, got it working
[16:09] <gus1> So I just upgraded to jaunty ppa bzr (from normal jaunty bzr) and my stacked bzr-svn repo is complaining with "ERROR: SvnRepository(...) is not compatible with KnitPackRepository(...) different serializers".   Is that some known problem?
[17:43] <Etenil> Hello there
[17:44] <Etenil> I'm having a small problem with my repository
[17:44] <Etenil> I have a base code in the root directory
[17:45] <Etenil> and several independant applications that rely on the base code in sub-folders
[17:45] <Etenil> basically, I'd like to version the root directory and each sub-directory independently
[17:45] <Etenil> do you know how I could proceed?
[17:52] <fjalvingh> Etenil: You cannot, really.
[17:53] <Etenil> fjalvingh, really??
[17:54] <Etenil> what should I do then?
[17:54] <Etenil> move my applications out of the common codebase?
[17:56] <fjalvingh> Etenil: In time there will be the nested trees extension. But it's progress is slow.
[17:56] <fjalvingh> What I did is just not to manage the root itself.
[17:57] <Etenil> yeah, that's what I did so far, but I need to have at least `index.php' in the root folder
[17:57] <fjalvingh> I created separate repositories/branches for the shared projects
[17:58] <fjalvingh> Etenil: Hmm.. It might be that you can just branch /inside/ the root.
[17:58] <fjalvingh> So there are separate branches (not related) and the one is /inside/ the other
[17:58] <fjalvingh> The outer one has the directory for the inner one as .bzrignored
[17:59] <fjalvingh> Limitation would be that the inner branch always is a single directory which in turn contains the other dirs
[17:59] <Etenil> oh, so I could ignore each sub-folder that contains an app
[17:59] <fjalvingh> There is also something called the "config" extension/plugin but I don't use that one.
[18:21] <jenred> hello! Is it possible to revert a merge that hasn't been committed?
[18:21] <jenred> and if so how thx
[18:22] <beuno> jenred, yes, but theres no way to distinguish it from the changed you had that weren't committed yet (if you had any)
[18:23] <jenred> so I merged 2 branches and now I want to drop the branch that I just merged b/c their are too many conflicts
[18:24] <jenred> is there anything like a "unmerge"
[18:24] <beuno> jenred, jsut "bzr revert" should do it
[18:25] <jenred> ok I think that worked thanks!
[18:44] <garyvdm> jam: What does the "known" in KnownGraph refer to?
[18:46] <jam> garyvdm: we know the full ancestry
[18:47] <jam> versus Graph which tries to know as little as possible
[18:47] <garyvdm> jam: I see - So in that case It will work nicely for qlog :-)
[18:50] <jam> yep
[19:04] <vila> garyvdm: but keep in mind that it's a step (a significant one, but a step anyway), the final target is to make it lazy in the end :)
[19:04] <garyvdm> vila: Yes
[19:06] <garyvdm> jam, vila: Would a KnowGraph be mutable? I think for qlog to be lazy, It's going to run merge_sort every time it loads more of the graph.
[19:07] <jam> KnownGraph is not currently mutable
[19:07] <garyvdm> But it will have all of the graph that it wants merge_sort to look at loaded
[19:07] <vila> garyvdm: no, it's not intended to be mutable
[19:07] <jam> I plan to allow it to add new nodes on the end, probably not in the middle
[19:07] <garyvdm> jam: which end?
[19:07] <jam> also, the time for "KG.merge_sort()" is around 40ms for a bzr.dev tree
[19:08] <vila> garyvdm: I call it FullyKnownGraph in my head myself
[19:08] <jam> garyvdm: new revs, not old ones
[19:10] <garyvdm> jam: so if I load bits of the graph, just create a new KG every time some more is loaded?
[19:10] <garyvdm> Or us the old merge sort?
[19:10] <garyvdm> *ues
[19:10] <garyvdm> *use
[19:12] <jam> merge_sort won't give you the right answers without the whole graph
[19:12] <jam> new or old
[19:13] <jam> it needs all ancestors to know if a revision was merged earlier than now
[19:14] <garyvdm> jam: I plan to only do this if bzr-historycache is available. I will use merge_sort to just give me the info I need to lay out the graph, and get the revno from bzr-historycache.
[19:15] <jam> garyvdm: it gives wrong answers for the graph as well
[19:15] <jam> I can give specifics though it takes some drawing
[19:15] <garyvdm> If historycache is not available, I will only load the graph in 2 stages: mainline, and the whole graph
[19:16] <garyvdm> jam: in the order?
[19:17] <garyvdm> Loading the graph lazy is very complex!
[19:17] <jam> so, if you have a long lived branch, that gets merged at rev 10 and rev 20
[19:17] <jam> the revs merged into 10 will show up underneath 20
[19:17] <jam> if you haven't loaded the ancestry from 10
[19:17] <jam> to know that they were first merged there
[19:21] <garyvdm> jam: I see. And there is know way to ensure that for rev a, you have loaded all the revisions that have rev a as a parent (other than loading everything :-()
[19:21] <jam> well there are ways, but nothing we store currently
[19:22]  * vila EODing by shaving 30% of selftest --parallel=fork execution time, YES :-)
[19:22] <jam> gdfo is something that might work well here
[19:22]  * garyvdm goes to read up on what gdfo is
[19:22] <jam> Greatest Distance From Origin
[19:22] <jam> it is part of the KnownGraph code
[19:23] <LarstiQ> not to be confused with Get The F Offline
[19:23] <jam> basically rev.gdfo = max(parents.gdfo) + 1
[19:23] <jam> or Get The F Out
[19:23] <jam> but that is G*t*Fo
[19:24] <LarstiQ> jam: which is phonetically rather close when slurred in Dutch ;)
[19:24] <jam> it is pretty close in american english, too :)
[19:24] <jam> garyvdm: the idea is that if rev1.gdfo >= rev2.gdfo you know that rev1 cannot be an ancestor of rev2
[19:25] <jam> we use it for the KnownGraph.heads() work
[19:25]  * garyvdm is digesting..
[19:25] <jam> anyway, it allows you to load some of the graph
[19:25] <jam> until you reach tips that have gdfo <= the one you have now
[19:26] <jam> since you know that the current one cannot be an ancestor of the others
[19:26] <jam> the main problem
[19:26] <jam> is that you need the whole graph to *compute* gdfo in the first place
[19:26] <jam> vila is trying to figure out how to record it properly
[19:26] <jam> as it interacts with ghosts ... poorly
[19:27] <garyvdm> And would need to be recomputed on merge?
[19:27] <jam> no
[19:27] <jam> the new revs change
[19:27] <jam> but gdfo is stable as long as *ancestors* don't change
[19:27] <garyvdm> I see
[19:28] <garyvdm> So I should hold of trying to make qlog graph lazy until that is done?
[19:29] <jam> i think you could lazily load a lot of things like revision info (I think you already do)
[19:29] <jam> but I wouldn't try to lazy load the graph itself
[19:29] <jam> I'll also note
[19:29] <jam> that in current circumstances, computing a node accurately seemed to take about 50% of the graph of bzr.dev anyway except in trivial cases
[19:30] <jam> stuff like 'brisbane-core' requires a lot of history to be searched
[19:30] <jam> though potentially that is easier with gdfo... not sure
[19:30] <jam> oh, and we have several cases where we merge in a plugin
[19:30] <jam> and a plugin's first rev is gdfo == 1
[19:30] <jam> so we have to load the wholegraph again
[19:31] <jam> that said...
[19:31] <jam> I made loading the whole graph significantly cheaper
[19:31] <jam> OOo went from 33s => 10s
[19:31] <jam> bzr.dev from 1.5s => 300ms
[19:31] <garyvdm> Wow!
[19:32] <garyvdm> This was with KnownGraph?
[19:32] <garyvdm> Will that make it into 2.0?
[19:32] <garyvdm> jam: Yes - revisions are only loaded if they appear on screen. (Or if you do a search, all revisions are load.)
[19:33] <jam> just landed in bzr.dev
[19:33] <garyvdm> jam: :-)
[19:33] <jam> and merge sort is about 3x faster as well
[19:48] <jam> well, 8x if you don't count the time to build the KnownGraph
[20:43] <lifeless> moin
[20:46] <lifeless> jam: I'm quite worried that this will regress shared repo cases
[20:46] <jam> lifeless: it does the same work we do now, just in a tighter loop
[20:46] <lifeless> jam: oh cool, so it doesn't load unreferenced nodes?
[20:47] <jam> lifeless: no
[20:47] <jam> it walks the ancestry, and just loops on ancestors present on the current btree page
[20:47] <lifeless> argh double negatives ;)
[20:55] <lifeless> jam: read your reply on the bug; thats really good
[22:05] <lifeless> jam: around?
[22:06] <jam> yeah, for now
[22:06] <lifeless> I need a quick incremental review, in about 3 minutes
[22:06] <lifeless> for landing 2a default
[22:06] <jam> k
[22:07] <lifeless> its stacking [again]
[22:16] <RenatoCaelum> verterok: hi
[22:17] <james_w> Is there a value I could cache to know if the contents of the working tree have changed at all?
[22:18] <james_w> does the wt have a testament?
[22:19] <lifeless> james_w: tree.has_changes()
[22:20] <james_w> but I don't have the old tree
[22:20] <james_w> I was just watching my commit hook run the tests after I had just done a full test suite run
[22:20] <lifeless> I'll need more context here
[22:20] <james_w> it would be nice if my test runner could write something about the state out
[22:20] <james_w> then the hook could not bother running if the tree it was committing matched that state
[22:21] <james_w> would also solve an issue I have with package maintenance
[22:21] <lifeless> you can make a testament of any inventory; however the working tree inventory may not match disk at all
[22:22] <james_w> caching?
[22:22] <lifeless> reality
[22:22] <james_w> or wouldn't match the inventory of the revision tree it became?
[22:22] <lifeless> neither
[22:22] <james_w> ok
[22:22] <james_w> I'll ponder some more
[22:22] <lifeless> fields like size
[22:22] <lifeless> sha1 etc
[22:23] <lifeless> in a working inventory aren't synced with disk, and even if they were they could become dated asynchronously
[22:24] <james_w> well, it could force a disk scan couldn't it?
[22:25] <james_w> it's racy, but...
[22:25] <lifeless> even if it did, it can skew
[22:27] <lifeless> jam: ugh, I'm having to fix a totally unrelated bug to make this work :(
[22:27] <lifeless> jam: how would you feel about me landing this with the test_repository_clone_preserves.. test made KnownFailure
[22:28] <jam> james_w: not to mention partial commits, etc
[22:28] <jam> lifeless: "landing this" ?
[22:28] <lifeless> default 2a
[22:29] <jam> I don't see a 'test_repository_clone_preserves", do you mean "per_workingtree...test_clone_preserves" ?
[22:29] <lifeless> line 944 in per_repo/test_repo
[22:30] <james_w> jam: yeah, I would compare to the testament of the revision tree being committed, which should account for that sort of thing
[22:30] <lifeless> james_w: myself, I'd made the test suite faster to run
[22:31] <jam> :)
[22:31] <jam> james_w: I think you could generate a testament from the WT, but the internal code wouldn't do that.
[22:31] <james_w> I'm just seeing a version tracking system on one hand, and repeated work from not knowing whether something has changed on the other
[22:31] <jam> easier to stage a commit, and then validate off of that revision
[22:31] <lifeless> james_w: for an off the wall approach
[22:31] <lifeless> james_w: make all your test runs do a commit
[22:31] <lifeless> and uncommit if they fail
[22:32] <james_w> could work :-)
[22:32] <james_w> doesn't really help the packaging case, but neat idea anyway
[22:32] <james_w> as for faster to run, that solves it for one project, but not other cases
[22:33] <jam> lifeless: so I've at least tracked down the test. How is it failing?
[22:33] <jam> as it is actually a fairly common case we've run into because "bzr upgrade repo" doesn't upgrade the branches
[22:33] <lifeless> jam: firstly the whole thing is testing off stuff
[22:34] <james_w> thanks for your time
[22:34] <lifeless>         """Cloning an unstackable branch format to a somewhere with a default
[22:34] <lifeless>         stack-on stack-on branch upgrades branch and repo to match the target
[22:34] <lifeless>         and honour the policy.
[22:34] <lifeless> """
[22:34] <lifeless> my updated docstring
[22:34] <jam> lifeless: what would happen is your local repo was stackable, but the branch format was too old
[22:34] <jam> then pushing that to lp would fail
[22:34] <jam> because it tried to auto-upgrade the repo to abad format
[22:34] <lifeless> yes
[22:34] <lifeless> but
[22:34] <lifeless> that is still broken in trunk
[22:34] <lifeless> its just that the test happens to fail closed
[22:35] <lifeless> what we want is that when there is a policy pointing at a stackable branch, and the source repo-or-branch isn't stackable, that its upgraded to match
[22:36] <lifeless> further, when the source repo is incompatible (e.g. 2a) and the stacked-on is (say)  1.9, we want to not stack
[22:36] <lifeless> but there is a separate bug that it currently aborts
[22:41] <jam> so how is it failing at this point? versus the test passing today
[22:42] <lifeless> the test is changed slightly in my branch, but not enough
[22:42] <lifeless> the thing is that its broken today
[22:42] <lifeless> we actually use the default format /somewhere/ and so the target is often unstackable
[22:42] <lifeless> and the test doesn't notice
[22:43] <lifeless> when the default is changed, we end up with stackable much more often
[22:43] <lifeless> and the test against whether repo is stackable suddenly blows up
[22:43] <jam> lifeless: so last I checked, BzrDir.initialize_on_transport_ex() would create the repo format you requested, but always uses the default branch format.
[22:44] <lifeless> well, init_ex doesn't make a branch
[22:44] <jam> lifeless: it *does* use the default branch for the format and stacking checks
[22:44] <jam> which was a source of bogus "this format doesn't support stacking" messages in the past
[22:45] <lifeless> yes
[22:45] <lifeless> so, there is a broken code path
[22:46] <lifeless> we can either fix it, then land this default branch. or vice verca :)
[22:46] <lifeless> so
[22:46] <lifeless> specifically, there are 7 formats that don't update
[22:46] <lifeless> don't upgrade
[22:47] <lifeless> and the test was simply not noticing that they don't
[22:47] <lifeless> FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormatKnit3)
[22:47] <lifeless> FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormatKnit4)
[22:47] <lifeless> FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormatKnitPack1)
[22:47] <lifeless> FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormatKnitPack4)
[22:47] <lifeless> FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormatKnitPack3)
[22:47] <lifeless> FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormatKnit1)
[22:47] <lifeless> FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormat7)
[22:50] <jam> lifeless: so I'm not going to make you block forever on it. But I'll note things tend not to get fixed once they are marked KnownFailure
[22:51] <jam> I suppose for my balance point.... I'd probably go ahead
[22:51] <lifeless> I think I have a hacked up version
[22:51] <lifeless> its a bit heinous
[22:54] <lifeless> jam: re: KF - I know, but we can file bugs that are critical :)
[22:56] <lifeless> jam:
[22:56] <lifeless> http://paste.ubuntu.com/255402/
[22:56] <lifeless> thats the change vs the branch you reviewed last night.
[22:57] <lifeless> I think it captures what we want more accurately.
[22:57] <jam> lifeless: you've got some serious typos in the docstring, one not introduced by you
[22:57] <jam> "to a somewhere"
[22:58] <jam> and then "stack-on stack-on branch"
[22:58] <lifeless> fixed
[23:00] <jam> the "if stack_on_format in... elif..." seems like it could really use a final "else" clause causing an exception
[23:00] <lifeless> mm
[23:00] <lifeless> you need a long list of formats that just work if you do that
[23:00] <jam> I don't quite understand why you don't just grab the BzrDir format and pass that in
[23:01] <jam> I suppose you are intentionally using a diff format?
[23:01] <lifeless> yes
[23:01] <lifeless> a stackable one matching the serializer
[23:01] <lifeless> the unlisted formats are already stackable
[23:01] <lifeless> and thus its a no-op really.
[23:01] <jam> lifeless: k, probably a comment then
[23:02] <lifeless> done
[23:02] <jam> lifeless: good enough then
[23:02] <lifeless> DoIt?
[23:02] <jam> yep
[23:03] <lifeless> thanks!
[23:18] <goneri> igc: Hi! Can I have you opinion on the branch I did against bzr-fastexport to fix #347729 ?
[23:20] <lifeless> igc s likely still asleep
[23:20] <lifeless> give him a couple of hours
[23:21] <goneri> lifeless: oh ok :)
[23:55] <lifeless> \o/ onto ascii


[02:24] <racarr> yay...hypothetically cross built against rtm
[02:32] <racarr> something didnt work
[08:49] <alf_> greyback: what is "wizard_socket"?
[08:49] <alf_> greyback: (Good morning!)
[08:50] <greyback> alf_: hey. I've no idea, first I've heard of it
[08:50] <greyback> too early to make a harry pooter joke
[08:51] <greyback> alf_: I know hte startup wizard uses qtmir, as it needs to be a mir server in order to have an OSK client. Perhaps it decided to call its own socket that?
[08:52] <alf_> greyback: Any idea where the start-up wizard project is?
[08:53] <greyback> alf_: lp:ubuntu-system-settings
[08:53] <alf_> greyback: thanks
[08:53] <greyback> np
[08:54] <greyback> alf_: yep, wizard/ubuntu-system-settings-wizard.conf sets a wizard_socket
[08:55] <alf_> greyback: So, I guess unity8 has no business connecting to that socket, right?
[08:55] <greyback> alf_: right
[08:56] <alf_> greyback: I think it picks up by mistake, some leftover environment variable somehow
[08:56] <alf_> greyback: I will check the start-up scripts
[08:56] <greyback> alf_: in post-stop, might be good idea to unset MIR_SOCKET
[08:57] <greyback> or else specify exactly the socket for unity8 to connect to in its startup job
[08:59] <alf_> greyback: so ubuntu-system-settings-wizard-cleanup.conf supposedly restores the MIR_SOCKET to its previous value (WIZARD_ORIG_MIR_SOCKET), but there is probably some kind of race there
[09:07] <greyback> alf_: agreed
[09:07] <alf_> greyback: if only I could reproduce it...
[09:07] <RAOF> Can we have a wizard_socket as a mainstay? :)
[09:08] <greyback> RAOF: back to the muggle mines you
[09:08]  * RAOF returns to his lunar abode
[09:12] <duflu> Oh lunar. Cheesy.
[09:14] <duflu> Mirv, tvoss: Can we drop the overly wordy (and wrong) description text here?... https://launchpad.net/ubuntu/+source/mir
[09:14] <duflu> I don't seem to have permission
[09:15] <tvoss> duflu, did you mean launchpad.net/mir
[09:15] <tvoss> ?
[09:15] <duflu> tvoss: No the link I just gave (under “mir” package in Ubuntu)
[09:16] <Mirv> duflu: I don't see any description there, aside from listing the packaging short descriptions
[09:16] <duflu> Mirv: Yes, they're wrong. And very old
[09:16] <Mirv> duflu: so that's a list of debian/control Description: first lines
[09:16] <duflu> Delete please
[09:16] <tvoss> duflu, those are auto generated
[09:16] <duflu> Hmm where from?!
[09:16] <duflu> Maybe from trusty
[09:16] <duflu> ?
[09:17] <tvoss> duflu, I don't know
[09:17] <duflu> Ah yes. Looks like auto-generated  from trusty
[09:17] <Mirv> duflu: is there some difference to the utopic ones on that page? http://bazaar.launchpad.net/~mir-team/mir/utopic/view/head:/debian/control
[09:17] <Mirv> right, trusty
[09:18] <Mirv> that's really a Launchpad problem/choice then
[09:18] <duflu> Mirv: Yeah the ABI levels are different, and the package names are changing a bit
[09:18] <Mirv> it's definitely a bug also that https://launchpad.net/ubuntu/utopic/+source/mir looks similar
[09:18] <duflu> Excellent. Another important Launchpad page with misleading info we can't fix
[09:19] <Mirv> :(
[09:20] <duflu> Mirv: OK thanks for clarifying :/
[09:22] <alf_> greyback: duflu: Any idea how to add ubuntu-system-settings as affected by the bug? The project doesn't track bugs in launchpad (it's tracked in the ubuntu package).
[09:22] <duflu> alf_: I'll do it
[09:22] <alf_> duflu: thanks
[09:22] <duflu> alf_: (Also affects distribution...)
[09:23] <alf_> duflu: ah, right, that one again... :)
[09:27] <duflu> anpok_: Your 0.7.3 is served
[09:27] <duflu> https://launchpad.net/ubuntu/+source/mir
[09:59] <RAOF> Woo! Branches all green.
[10:00] <duflu> RAOF: Time to run away then :)
[10:00] <RAOF> Yup.
[10:01]  * davmor2 lassos ROAF and stakes him down in front of a computer
[13:51] <sil2100> kgunn: hello!
[13:53] <kgunn> uh-oh
[13:53] <kgunn> sil2100: hello ?
[13:53] <kgunn> :)
[13:56] <sil2100> kgunn: sooo, I'm preparing the FFe for touch inbetween stuff, and noticed that some parts of mir are now used in the default utopic desktop images
[13:56] <sil2100> kgunn: we would like to know what things are planned for mir in this cycle still
[13:56] <sil2100> kgunn: can you guarantee ABI stability at least? :)
[13:57] <kgunn> camako: fyi....
[13:57] <kgunn> sil2100: so right now we are truly in bug fix mode
[13:57]  * camako is all ears (eyes)
[13:57] <kgunn> so no FFe needed i think
[13:58] <kgunn> for utopic
[13:58] <kgunn> sil2100: however, yes, we still break ABI every now and then tho we try not to
[13:58] <camako> what is FFe?
[13:58] <kgunn> sil2100: only if a bug fix ends up causing us to do so
[13:58] <kgunn> but we know all our clients....so...
[13:58] <kgunn> FFe = feature freeze exception
[13:59] <kgunn> camako: cause even tho we're thinking phone alot....there's utopic going on delivering to desktop
[13:59] <sil2100> kgunn: ok, so we'll not include mir in the FFe, and simply make sure anything that gets released is a bugfix
[13:59] <camako> I see
[13:59] <kgunn> camako: do you agree with what i said?....i can't see anything that's a "feature" landing before Oct ?
[13:59] <kgunn> everything is really just a bug fix
[14:00] <camako> there will be a 0.8.0 release coming (probably next week)...  which will/should reduce ABI breaks
[14:00] <kgunn> ...and we're not even cheating on definitions :)
[14:00] <kgunn> camako: i think even that is ok....we just can't break client
[14:01] <camako> yeah that's all under control... we have a deprecation path, rather than breakage
[14:01] <sil2100> Excellent
[16:04] <alf_> kgunn: @ lp bug 1371593, is the media hub part of the unity8 process, but something separate from it?
[16:10] <kgunn> alf_: seperate
[16:11] <kgunn> alf_: haven't spoke in a while...have a nice weekend btw
[16:12] <alf_> kgunn: (thanks, you too!) But it is loaded in the unity8 process, right (that's where I got the backtrace from)?
[16:12] <alf_> kgunn: So it's a library used by unity8?
[16:19] <kgunn> alf_: right....
[19:21] <kgunn> rsalveti: so where's the best place to look for quick devel-proposed image#/date/commits ?
[19:22] <kgunn> like a list
[19:22] <rsalveti> ogra_'s changes list?
[19:22] <rsalveti> like http://people.canonical.com/~ogra/touch-image-stats/222.changes
[19:22] <rsalveti> that will at least show what was new in every image
[20:45] <kgunn> rsalveti: sorry to bother...so was working on bisect, flashed image #235 devel-proposed....but
[20:45] <kgunn> need to manually install unity8-autopilot
[20:46] <kgunn> so...it needs to pull in a bunch of stuff
[20:46] <rsalveti> right
[20:46] <kgunn> but are those packages like blown away or something
[20:46] <kgunn> i'm getting
[20:46] <kgunn> Err http://ports.ubuntu.com/ubuntu-ports/ utopic/main python2.7 armhf 2.7.8-6ubuntu1
[20:46] <rsalveti> might need to run apt-get update first
[20:46] <kgunn> rsalveti: but...won't that take me to the latest ?
[20:47] <kgunn> i don't want the latest...i want #235 stuff
[20:47] <rsalveti> that will install the latest dependencies, yes
[20:47] <rsalveti> hopefully that will not cause any issue
[20:47] <kgunn> :-/
[20:47] <rsalveti> but we don't store the older packages
[20:47] <kgunn> well...asking for bisect ain't such a good idea then
[20:47] <kgunn> this sucks
[20:47] <kgunn> "hope"
[20:47] <rsalveti> if the broken package is the one already available *in* the image, then it can still work
[20:48] <rsalveti> I know it's not ideal
[20:48]  * kgunn prepares to chase tail, wild gooses and red herrings
[20:48] <kgunn> rsalveti: thanks for the info
[20:48] <rsalveti> np, good luck
[20:48] <rsalveti> this is painful
[20:49] <kgunn> lol
[20:49] <kgunn> tell me
[21:31] <tvoss> morphis, ping