[04:28] <jsgigax> is there an easy terminal command in lubuntu to flip desktop 180 degrees?  Just have a monitor that only easy way to hook up is upside down.
[04:29] <jsgigax> the place to do it in gui is grayed out
[04:34] <guiverc> jsgigax, you haven't said what release, in 18.04 I'd likely use xrandr (https://wiki.ubuntu.com/X/Config/Resolution) but I've not used it with any LXQt based newer release
[04:36] <jsgigax> it's latest fully updated so he says
[04:36] <jsgigax> kinda just middle man here honestly
[04:38] <guiverc> jsgigax, 19.10 still relies on X so it'd likely still work; but I've not used it in years (maybe not since 16.04), it's all I know and thus what I'd try first if I needed it for my box
[04:40] <jsgigax> I'm pretty sure he's tried that, however, I just showed up right before he's basically given up
[04:42] <guiverc> the only other option mentioned in aforementioned wiki page is modifying xorg.conf; you'll have to wait & see if others are more suggestions as I'm out sorry
[04:43] <lynorian> jsgigax is this a vga monitor?
[04:43] <lynorian> I think rotation of flipping did not work over vga based on how the analog signal is sent over the wire
[04:44] <jsgigax> yes it is
[04:48] <jsgigax> should it work with DVI?
 I think that is why that option is grayed out
 Hello
 Does Lubuntu have opensauce in 20.04
 Sry, I mean openbox
 Window Manager😅
 Yes. it is still openbox
 @kc2bez [Yes. it is still openbox], Nice, will try it
 And will help report bugs (if there are any still left) before actual release
 I'm sure there will be none
[23:50] <honjaakuma> Hi


[19:18] <rneese> hey guys having a issue with the arduino ide on arm64 hirsute
[19:25] <rneese> Picked up JAVA_TOOL_OPTIONS:
[19:25] <rneese> java.lang.UnsatisfiedLinkError: /usr/lib/aarch64-linux-gnu/liblistSerialsj.so.1.4.0: /usr/lib/aarch64-linux-gnu/liblistSerialsj.so.1.4.0: undefined symbol: sp_get_port_usb_vid_pid
[19:31] <rneese> but its not giving enough info to report or attempt fix
[19:34] <rneese> https://pastebin.com/ccbXfBYS full error
[19:38] <rneese> how to report all this issue
[19:40] <ogra> https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1916278
[19:41] <ogra> (i guess)
[20:00] <rneese> ok
[20:00] <rneese> surprised they have not fixed it already
[20:00] <rneese> o well
[20:00] <rneese> thanks


[03:00] <callmepk> good morning
[04:04] <duflu> Oops. Hi callmepk
[05:00] <callmepk> Oh, hi duflu
[05:07] <pieq> hello everyone :)
[05:08] <pieq> duflu, hey, have you ever experienced this? Pressing the Super key seems to register, but doesn't show the dash in Ubuntu 20.04
[05:08] <pieq> duflu, I'm helping a friend and he's using a lot of different input methods (English, French, Japanese, Chinese). His Ubuntu is setup in French
[05:08] <duflu> pieq, for secondary keyboard layouts it's a common complaint, almost fix released: https://bugs.launchpad.net/bugs/1871913
[05:08] <pieq> When I switch to the French keyboard, pressing Super (the Windows key) shows the dash as it should
[05:09] <pieq> duflu, thanks for confirmation
[05:09] <duflu> No worries
[05:09] <pieq> so weird.... the key is seen, cause I can see the focus changes when I press it
[05:10] <pieq> but it's just that overview doesn't show up
[05:10] <duflu> pieq, yeah the fix is in mutter. I did not look very closely
[05:21] <pieq> duflu, thanks a lot for pointing these out.
[05:21] <pieq> At least I know it's gonna work at some point :D
[05:37] <seb128> goood morning desktopers
[05:40] <duflu> Morning seb128
[05:40] <seb128> hey duflu, how are you today?
[05:41] <duflu> seb128, feeling good. You?
[05:41] <seb128> I'm alright :)
[05:41] <seb128> the ubuntu dock seems to have a sad time this cycle :-/
[05:42] <duflu> seb128, I think it might be related to the fact that 3.36 support wasn't done at all by upstream in time. Marco had to rush it in, and we didn't get long to flesh it out
[05:43] <seb128> well, we should now
[05:43] <seb128> I guess that's something for Trevinho?
[05:44] <duflu> seb128, it's done already(?)
[05:44] <duflu> He's working on the bugs frequently
[05:44] <duflu> I'm surprised how many icon grid issues are due to the ubuntu-dock
[05:45] <seb128> right, I just saw a few extra issues reported now
[05:45] <seb128> e.g bug #1872268
[05:45] <duflu> Not 100% sure that's ubuntu-dock but it seems likely
[05:45] <seb128> or bug #1876889
[05:45] <duflu> yeah
[06:35] <didrocks> good morning
[06:39] <duflu> Morning didrocks
[06:40] <didrocks> hey duflu
[07:19] <seb128> lut didrocks, how are you?
[07:21] <didrocks> ça va, et toi seb128 ?
[07:23] <seb128> ça va :)
[07:26] <seb128> today is an easy launchpad bugs day
[07:28] <didrocks> heh :)
[07:28] <didrocks> today is telling to people not to use their own custom kernel without ZFS module shipped and expecting zsys to work
[07:28] <didrocks> … nor any other zfs commands
[08:00] <Laney> o/
[08:01] <didrocks> hey Laney
[08:03] <Laney> sup didrocks
[08:03] <Laney> having fun with bug reporters?
[08:06] <duflu>      \o
[08:07] <Laney> _o< quack
[08:07] <duflu> Actually I'm in Australia so...
[08:08] <duflu> °\
[08:16] <duflu> Whee, gnome-shell 3.36.2 for everyone
[08:17] <didrocks> Laney: yeah, fortunately, they did run the apport hook which helped diagnosing the issue :)
[08:57] <seb128> hey Laney
[09:09] <KGB-0> mutter ubuntu/master Daniel van Vugt * [close] merge request !63: Add lp1877075.patch to fix top crash LP: #1877075 * https://deb.li/WKaF
[09:15] <Laney> hey seb128!
[09:20] <KGB-0> mutter debian/master Daniel van Vugt * [open] merge request !64: Add backend-x11-Reintroduce-XInitThreads.patch * https://deb.li/3EytF
[09:21] <KGB-0> mutter Daniel van Vugt 166602 * commented merge request !63 * https://deb.li/5q67
[09:24] <duflu> The KGB knows everything
[09:37] <tjaalton> seb128: marking bugs fix committed before a patch has actually landed proposed is very confusing
[09:38] <tjaalton> that's what sru-review will do
[09:39] <seb128> tjaalton, feel free to set to triaging, having it unconfirmed was even wronger since there is a fix uploaded in the review queue
[09:39] <seb128> tjaalton, I do use fix commit for desktop bugs when a fix has been commited to the vcs usually, makes easier to see what is in the landing pipes
[09:39] <tjaalton> set it 'in progress'
[09:40] <tjaalton> ok
[09:45] <seb128> tjaalton, sorry for the confusing, i will keep that in mind for bugs on your components and use in progress next time even if it's uploaded
[09:46] <tjaalton> seb128: thanks, no worries
[11:53] <tsimonq2> In case this has mildly annoyed anyone else: https://salsa.debian.org/lintian/lintian/-/merge_requests/310
[11:53] <tsimonq2> e.g. gtk+2.0 will have one less warning. I'm sure this applies to many other packages as well.
[12:05] <Laney> |o/
[12:06] <Laney> \o|

[12:15] <didrocks> and first blog post on ZFS support in ubuntu 20.04 LTS published: https://twitter.com/didrocks/status/1263443082625855490 :)
[13:22] <oerheks> hi didrocks, good writing, bookmarked!
[13:26] <didrocks> thanks oerheks :)
[13:26] <seb128> didrocks, nice one indeed :)
[13:28] <didrocks> thx seb128, I hope the other will hold up on the standard :p
[13:28] <didrocks> others* (8 others remaining to publish)
[13:28] <seb128> I'm sure they will :)
[13:28] <didrocks> heh
[14:20] <Laney> why am I so stupid
[14:20] <Laney> you can't build-depend on a source package
[14:20] <Laney> :(
[14:23]  * seb128 hugs Laney, weekend is coming don't worry :)
[14:23] <Laney> thanks seb128
[14:23] <Laney> think I need it!
[14:28] <Laney> good thing is that TDD made me find the issue
[14:31] <Laney> Ran 1 test in 0.531s
[14:31] <Laney> OK
[14:31] <Laney> woohoo!
[14:42] <hellsworth> good morning desktopers
[14:43] <didrocks> hey hellsworth
[14:43] <hellsworth> o/
[14:50] <marcustomlinson> hey hellsworth
[14:50] <hellsworth> hey marcustomlinson
[14:52] <seb128> hey Heather, how are you?
[14:54] <hellsworth> oh i'm pretty alright :) you seb128 ?
[14:54] <seb128> I'm good thanks!
[14:57] <hellsworth> i found a new bug introduced in libreoffice 6.4.4 yesterday.. the save icon disappears once the document needs to be saved. i wonder if this is related to the main.xcd changes too
[14:57] <hellsworth> marcustomlinson: maybe you have some advice on how to chase this down?
[14:58] <kenvandine> hellsworth: that sounds like an annoying bug
[14:58] <hellsworth> yeah..
[14:58] <hellsworth> or maybe seb128 has some advice with his expert debugging :)
[14:59] <hellsworth> there are no helpful journalctl logs when this icon disappears
[14:59] <seb128> hellsworth, it would be easy enough to copy the main.xcd from the previous deb over if you want to see if that makes a difference
[14:59] <hellsworth> the icon set is the same so it's whatever is causing the icon to change
[14:59] <hellsworth> seb128: excellent idea
[14:59] <hellsworth> thank you :)
[14:59] <seb128> hellsworth, I would probably start by doing a strace -f of the libreoffice process
[15:00] <seb128> and see if it stats for an icon and fail to get it at this time
[15:00] <kenvandine> maybe the icon name they look for changed
[15:00] <hellsworth> ok i can try that
[15:00] <hellsworth> oh kenvandine good thinking
[15:00] <seb128> is the build in a ppa or something?
[15:00] <hellsworth> (you folks are a fountain of information :) )
[15:00] <hellsworth> seb128: yes it's here https://launchpad.net/~hellsworth/+archive/ubuntu/libreoffice
[15:03] <hellsworth> oh man strace -f is intense
[15:04] <seb128> yeah, you want to > log or -e open or something to limit the syscalls
[15:05] <seb128> hum, that ppa tries to install openjdk-11 and libreoffice-java for me
[15:05] <seb128> is that expected?
[15:06] <seb128> 242M more disk space to use
[15:06] <hellsworth> umm hmm interesting. i didn't notice that..
[15:06] <seb128> shrug, and now libreoffice segfaults on start :p
[15:06] <seb128> well I install with no recommends to avoid the java
[15:07] <seb128> maybe that was not smart
[15:07] <hellsworth> i installed this on a focal vm that had no previous libreoffice on it
[15:07] <seb128> same here, I'm testing on a focal iso in a VM
[15:08] <hellsworth> oh no i'm wrong.. looks like i upgraded my 6.4.3 to 6.4.4
[15:11] <Trevinho> doko: bug 1793496 is in bionic queue for a while, ping SRU team to get that in :)
[15:11] <Laney> Trevinho!
[15:12] <seb128> hey Trevinho
[15:12] <seb128> hellsworth, that ppa segfaults on start in a VM for me :/
[15:14] <hellsworth> hmm interesting.. well let me purge my libreoffice and install it fresh from this ppa and see if i hit that too
[15:15] <seb128> what I did is boot a focal amd64 iso in virtualbox, enable the ppa and install libreoffice
[15:15] <seb128> could also be livecd specific
[15:18] <hellsworth> yeah i think it's livecd specific
[15:18] <hellsworth> i just purged libreoffice in my installed focal vm and reinstalled it. it launches just fine from either the desktop icon or command line
[15:23] <Laney> could be an OOM thing or something, that's quite big for unpacking onto an overlay
[15:24] <seb128> ah right
[15:24] <seb128> still it wants to pull java :p
[15:27] <hellsworth> ok i got a readable strace of only 3k lines...
[15:27] <hellsworth> let me look at 6.4.3 and see if that installs libreoffice-java by default too
[15:32] <hellsworth> yeah it doesn't hmm ok not sure why 6.4.4 is doing that..
[15:48] <hellsworth> so libreoffice-java-common is installed in focal by default with 6.4.4-rc2 but it *is not* installed by default in debian testing with the 6.4.4-rc1 in their archive
[15:49] <seb128> hellsworth,  https://launchpad.net/~hellsworth/+archive/ubuntu/libreoffice/+files/libreoffice_1%3A6.4.3-0ubuntu1_1%3A6.4.4~rc2-0ubuntu1~ppa1.diff.gz
[15:49] <seb128> has
[15:49] <seb128> -Depends: libreoffice-base,
[15:49] <seb128> +Depends: libreoffice-base-nogui | libreoffice-base,
[15:49] <seb128> and -nogui depens on java
[15:50] <seb128> so that's probably it
[15:50] <hellsworth> ah that's it!
[15:50] <seb128> hum, though that's for libreoffice-report-builder-bin-nogui
[15:51] <seb128> hellsworth, how do you trigger your icon issue?
[15:51] <seb128> I tried in writter and it has an icon here
[15:52] <hellsworth> just start typing and the icon goes away
[15:52] <hellsworth> and you don't see it.. so strange
[15:52] <seb128> for me it turns from a blue arrow to a red arrow
[15:52] <seb128> do you use the default theme?
[15:52] <hellsworth> so when you start typing the save icon arrow should turn from blue to red. what i see is instead of getting the red arrow icon, i have no icon
[15:52] <seb128> wfm...
[15:52] <seb128> in writers
[15:52] <hellsworth> yep default theme
[15:52] <hellsworth> i have the same problem in calc too
[15:53] <seb128> weird
[15:53] <hellsworth> i guess let me go try on a fresh focal vm...
[15:53] <hellsworth> this vm has been around for a while and used quite a bit.. mabye i put it in some funky state along the way
[15:53] <seb128> or another user on the same one?
[15:54] <hellsworth> oh there's an idea
[15:54] <hellsworth> i'll try that first
[15:55] <hellsworth> yeah a new user works just fine. i see the red arrow now..
[15:56] <hellsworth> ok so glad to know this is a non issue!!
[15:56] <hellsworth> and i'll just look into the java bit
[15:56] <hellsworth> seb128: thanks a million for helping me test this!
[15:56] <seb128> np!
[16:23] <tsimonq2> Laney: Thoughts on what XS-Debian-Vcs-* could be changed to that's more pretty? Upstream is asking: https://salsa.debian.org/lintian/lintian/-/merge_requests/310
[16:23] <hellsworth> libreoffice-report-builder-bin is in the Depends section of the libreoffice Package in the debian control file so why the hell is libreoffice-report-builder-bin not installed on a debian system with libreoffice
[16:24]  * hellsworth shurgs and goes to find a snack
[16:26] <Laney> tsimonq2: Dunno, does that have to be approved by policy or something? Don't know about you but I'd not really have the energy / interest for that
[16:28] <Laney> Feel free to design something if you want, make sure to care about derivatives-of-derivatives though
[16:28] <tsimonq2> Laney: Probably. For now I'm hoping the MR can be merged regardless of name choices.
[16:29] <tsimonq2> That's a good point.
[16:29] <Laney> $DISTRO-Vcs-foo isn't that bad IMO
[16:29] <Laney> it lets you recurse on dpkg-vendor --query Parent
[16:30] <tsimonq2> I agree.
[16:56] <seb128> hellsworth, k, testing again from an installed system it doesn't bring new/different packages from before, so I guess it was buggy from my part to test from an live session, sorry for the confusion and stressed created
[17:02] <hellsworth> no i think it's a valid problem. if i purge libreoffice* and install from this ppa, it deffinitely brings in way more than is installed in a debian system
[17:03] <seb128> k
[17:03] <hellsworth> there is definitely a package difference from debian that needs to be solved.. will continue down that path after my 1:1 (hint.. hint.. kenvandine)
[17:05] <kenvandine> hellsworth: just a minute
[17:09] <hellsworth> seb128: https://paste.ubuntu.com/p/trh23PMwcK/ is the list of packages i see installed on a focal system with this 6.4.4 ppa . is that the same for you?
[17:14] <seb128> it does seems similar yes
[17:15] <seb128> sorry, need to step out for dinner and co but I will read backlog later if I can still be useful for something
[17:22] <Laney> see you tuesday folks!
[17:34] <hellsworth> no worries seb128 thanks for verifying you see the same packages installed as me
[20:21] <hellsworth> seb128: if suggests are automatically installed, then libreoffice-java-common is expected because libreoffice-base installs libreoffice-report-builder which installs libreoffice-java-common
[20:22] <seb128> hellsworth, no, recommends are but not suggests
[20:22] <seb128> unsure if Debian does auto install Recommends nowadays though, could be a difference
[20:22] <hellsworth> it was confusing though because on all of bionic, focal, and bullseye.. the seeded libreoffice packages are slightly different that what apt installs (if no libreoffice* pkg exists)
[20:22] <hellsworth> oh ok so recommends would do it then


[09:50] <BenC> I'm trying to think of a good reason why we have a linux-source-2.6.x.deb package, but I'm having a hard time justifying it
[09:52] <torkel> because people are used to it?
[10:07] <BenC> used to it doesn't mean it's worth having :)
[10:07] <BenC> most people assume they can use it to build the same packages we do, and that's just incorrect
[10:08] <BenC> what most people want is "apt-get source linux" not "sudo apt-get install linux-source"
[12:03]  * BenC fires off the 2.6.26-1.1 upload
[12:05] <BenC> rtg: what was that you talk me last night, that adam said would pull in the last version?
[12:05] <rtg> hang on...
[12:05] <BenC> *told
[12:06] <rtg> an option to dpkg-buildpkg, e.g., '-v2.6.24-18.36'
[12:07] <BenC> Oh, I already knew about that
[12:08] <BenC> rtg: that just sets the .changes file to include all changelog entries later than that version
[12:09] <BenC> as opposed to just the current upload
[12:31] <fabbione> BenC: are you killing linux-ubuntu-modules?
[12:32] <fabbione> BenC: (for intrepid i mean)
[13:00] <BenC> fabbione: yeah
[13:00] <fabbione> ok
[13:01] <fabbione> so all external modules are back into main tree?
[13:06] <BenC> fabbione: yeah, pretty much
[13:13] <fabbione> BenC: it's kind of astonishing that no matter what, everything always collapse again.
[13:13] <fabbione> BenC: specially when we discussed that in regards of API/ABI breakage from lum
[13:13] <fabbione> and i suggested to go back
[13:29] <BenC> I never said going back wasn't possible
[13:29] <BenC> just that we couldn't do it in hardy
[13:29] <fabbione> nah there was time for hardy...
[13:29] <BenC> nah, there wasn't :)
[13:30] <BenC> time to do it, sure, but some one with that time, that's a different story
[13:30] <fabbione> there was.. you are just too slow :P
[13:30] <fabbione> that's why you have 24h/day and weekends
[13:30] <fabbione> weekends are boring without hacking :)
[13:31] <BenC> lol, my weekends aren't boring, but I definitely don't spend them hacking
[13:31] <BenC> you're married, your don't have time either :P
[13:33] <fabbione> ahhaha
[13:34] <torkel> BenC: married and with small kids you have nights to hack on :-)
[13:35] <fabbione> torkel: no you don't.. kids keep you busy
[13:40] <tjaalton> especially at night..
[21:57] <mnem0> what is the difference between linux-ubuntu-modules-2.6.24-18-386 and linux-ubuntu-modules-2.6.24-18-generic ??
[22:06] <amitk> mnemo: the flavour. -386 is for older machines, -generic for 686+ machines
[22:07] <mnemo> so I really want the latter then, for a modern machine??
[22:10] <amitk> mnemo: depends on what kernel you have installed. 'apt-get install linux-image-generic' ought to take care of all dependencies, really
[22:11] <mnemo> but how do I choose kernel between -i386 and -generic?
[22:11] <amitk> mnemo: what is the output of 'cat /proc/version_signature'?
[22:12] <mnemo> it's currently Ubuntu 2.6.24-18.32-386
[22:13] <mnemo> but I think I got both installed in grub for some reason
[22:13] <mnemo> and i'm more interested in general what is the difference between -i386 and -generic so I know which one to use in the future etc
[22:14] <amitk> mnemo: if your processor is something released in the last 2-3 years, it is a safe bet to go with -generic.
[22:15] <mnemo> yea I know -generic boots and works fine when I select it from grub
[22:15] <mnemo> but is -generic faster because it's optimized for 686 or something like that?
[22:18] <amitk> mnemo: yes. It will use optimizations, new instructions, etc. for newer processors.
[22:18] <mnemo> okay cool
[22:18] <mnemo> thanks for explaining it to me
[22:19] <amitk> np
[23:21] <bmm> Hi everybody. For starters, thanks for your work on the kernel. I'm desperately waiting for 2.6.25+ because of lan driver fixes, so I was looking around at the launchpad pages and wanted to mention two things:
[23:22] <bmm> 2.6.26 ia64 for intrepid has run and failed to build because of a missing: debian/rules.d/ia64.mk
[23:22] <bmm> (which seems like a small mistake?)
[23:23] <bmm> The kernel-team contact information link to the wiki doesn't work, see https://launchpad.net/~kernel-team on the right lower side.
[23:23] <bmm> So, that's all I wanted to mention. Keep up the good work and looking forward to the new versions.
[23:24] <bmm> Thanks for reading!
[23:30] <mrec__> hi anyone awake?
[23:30] <mrec__> https://bugs.launchpad.net/ubuntu/+bug/204578
[23:31] <mrec__> it would be great if someone could integrate the driver from mcentral.de into ubuntu


[01:00] <Hobbsee> bug 300257
[03:13] <dwg> I'm told this is the place I should mention this
[03:14] <dwg> I found and fixed a bug in libopal - packaged fix in my ppa
[03:14] <dwg> but the bug report (https://bugs.launchpad.net/ubuntu/+source/opal/+bug/297123) has had no response at all
[03:18] <RAOF> dwg: Is your debdiff attached to that bug?
[03:20] <dwg> RAOF: uh.. not as such
[03:20] <dwg> RAOF: just a pointer to the PPA, and a link to where the same bug has been fixed upstream
[03:23] <RAOF> https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff?action=show&redirect=MOTU%2FRecipes%2FDebdiff might be useful to you then.
[03:28] <dwg> RAOF: alrighty, I'll make one of those and attach once launchpad is up again
[03:29] <RAOF> dwg: If you've pulled the patch from upstream then it's likely there'll be a fixed package in Jaunty anyway, since we'll likely have a new release in there.  It's probably worth checking that, too.
[03:29] <dwg> RAOF: well, quite possibly
[03:30] <dwg> RAOF: it's a one-liner, though, so just folding in the patch seemed as easy
[03:32] <dwg> RAOF: I came up with the fix independently while debugging; the upstream link came after when I went to check if upstream needed fixing as well
[03:35] <RAOF> I suspect I'd need to actually see the bug to be more help at this point.
[03:36] <greg-g> and getting the fixed package into Debian is also a good way to get it in Ubuntu "automatically"
[03:41] <dwg> greg-g: hrm.. this is a "main" package, not "universe"
[03:43] <greg-g> dwg: generally the same thing applies to main, I think. (I am not a core-dev or motu, so I could be wrong)
[03:43] <dwg> greg-g: well, not doubt it helps, but this is a reasonably serious bug, ubuntu ought to be able to fix it without having to wait for someone else to do it first
[03:44] <dwg> (I don't actually know if the bug is fixed in Debian yet)
[03:45] <greg-g> dwg: well yes, for a serious bug it is good to get the patch in UBuntu quickly, but it is also good to then get it in Debian so we don't have to maintain a diff  (I obviously haven't looked at your bug report, just stating generalized good practices)
[03:46] <greg-g> anyways, it seems you know what you're doing, so, carry on :)
[06:34] <dholbach> good morning
[06:52] <maco> dholbach: morning
[06:52] <dholbach> hi mac
[06:52] <dholbach> maco
[07:28] <maco> dholbach: re bug 278418 icon-naming-utils? so apparently there are *many* ways to go after that one then
[07:34] <dholbach> maco: icon-naming-utils includes a mapping of file names and {gnome,tango,tangerine,human,...}-icon-theme make use of it to generate myriads of symlinks
[07:35] <dholbach> maco: it might make sense to forward the change to upstream and include it in Ubuntu and rebuild the icon themes with it
[07:45] <maco> ah ok
[09:46] <Hew> Hey guys. pidgin-musictracker has been renamed from just musictracker in Debian, which has now been synced to Jaunty. However, it now FTBFS. Two questions: Should I report the FTBFS as a bug against pidgin-musictracker? and what happens with the bugs listed under musictracker, do they need to be moved? Thanks.
[10:18] <Hobbsee> Hew: the source package is the same, isn't it?
[10:19]  * Hobbsee is also somewhat unconvinced that the package has been renamed, so far
[10:19] <Hobbsee> ah.  so it is.
[10:21] <dwg> RAOF_:  I've now attached a debdiff for the bug I mentioned earlier today
[10:21] <Hobbsee> Hew: move bugs:  yes.  report FTBFS: no, we have other ways to track it.  if you were reporting it, it would be against p-m
[10:27] <Hobbsee> oh, and the one i just filed shouldn't be moved ;)
[10:58] <Hew> Hobbsee: Thanks, I'll deal with those other bugs then :-)
[11:01] <Hobbsee> Hew: you're welcome :)
[11:50] <Hobbsee> !ping
[11:50] <BUGabundo_work> can some one give me a pointer on this
[11:50] <BUGabundo_work> https://bugs.edge.launchpad.net/ubuntu/+source/alsa-driver/+bug/296738
[11:50] <maco> Hobbsee: hazzing fun?
[11:50] <Hobbsee> maco: indeed - studying.  Noticed this was very quiet though, and wondered what was happening
[11:51] <BUGabundo_work> is there anything I can do to manually make alsamixer remember its volume?
[11:51] <maco> BUGabundo_work: yeah, it should Affects: linux
[11:51] <BUGabundo_work> really?
[11:51] <maco> alsa-driver is only if you manually compile the alsa-source
[11:51] <BUGabundo_work> kernel? why?
[11:51] <BUGabundo_work> it was triaged
[11:52] <maco> obviously not by crimsun or me
[11:52] <BUGabundo_work> yeah
[11:52] <BUGabundo_work> just saw the activity log
[11:52] <BUGabundo_work> just a plain (forum) user
[11:52] <BUGabundo_work> can you triage it now?
[11:53] <BUGabundo_work> it sucks to have to increase 2 or 3 levers everytime I rebbot
[11:53] <maco> BUGabundo_work: crimsun had me change this page to reflect that most should be linux by default https://wiki.ubuntu.com/DebuggingSoundProblems
[11:54] <maco> i can try
[11:54] <maco> i dont have his expertness though :P
[11:56] <maco> BUGabundo_work: what device options do you have under Default Mixer Tracks?
[11:58] <afflux> I'm having issues understanding bug 301597. python3.0 depends on python3.0-minimal = 3.0~rc3-0ubuntu3. Why is python3.0 processed before python3.0-minimal then?
[11:58] <maco> afflux: the order they are processed is non-deterministic. if one *needs* to be processed first, use pre-depends in the package's dependency list
[11:59] <afflux> alright. Should I add a debdiff for a pre-depends then?
[11:59] <maco> so python3.0 pre-depends on python3.0-minimal
[11:59] <maco> i think so
[11:59] <afflux> will do
[11:59] <afflux> thanks
[12:26] <BUGabundo_work> back maco... sorry
[12:26] <BUGabundo_work> let me check the device
[12:26] <BUGabundo_work> HAD Intel Alsa Mixer is the one selected
[12:28] <BUGabundo_work> maco one thing I noticed is that ever since I upgrade to jaunty
[12:29] <BUGabundo_work> console alsamixer will only show me PA and not alsa controls
[12:29] <BUGabundo_work> is this the expected behaviour?
[12:29] <maco> BUGabundo_work: im not on jaunty, but are you running "alsamixer" or "alsamixer -c0"?
[12:30] <BUGabundo_work> ahhh -c0 show more stuff
[12:30] <BUGabundo_work> why is that?
[12:30] <maco> BUGabundo_work: since the pc speaker is now separated out, you have to specify which card you're talking about
[12:31] <BUGabundo_work> the cat of proc/asound/cards show me just one
[12:31] <BUGabundo_work> the zero one
[12:31] <BUGabundo_work> but why does plain "alsamixer" just show PA?
[12:32] <maco> i dont know the reasoning, but i assume so that it has something to show at all
[12:33] <BUGabundo_work> ok
[12:33] <maco> i just know you have to do -c0
[12:33] <maco> crimsun drilled it in :P
[12:33] <BUGabundo_work> due you know the origin of sound clipping on PA?
[12:34] <BUGabundo_work> vlc, gnome-sound-recorder
[12:34] <maco> you mean where large files don't play all the way?
[12:34] <BUGabundo_work> all leave serious gaps between every 2 secs of playback/recording
[12:34] <BUGabundo_work> no need for large files
[12:34] <BUGabundo_work> I recorded 5 sec of mic audio and it sucks...
[12:34] <maco> no, i don't. id guess something to do with buffering...
[12:35] <maco> but as for that bug you mentioned before
[12:35] <BUGabundo_work> had to use audacity to work
[12:35] <maco> your issue is that your sound all went *poof*, right?
[12:35] <BUGabundo_work> but then audacity doesn't playback
[12:35] <BUGabundo_work> lol
[12:35] <BUGabundo_work> gets muted, yes
[12:35] <BUGabundo_work> on every boot
[12:35] <BUGabundo_work> if I hibernate (most) of the times its okay
[12:36] <maco> oh...are you sure you have the same bug as the reporter?
[12:36] <BUGabundo_work> okay
[12:36] <BUGabundo_work> lets start from the begginnig
[12:36] <BUGabundo_work> is this it https://bugs.edge.launchpad.net/ubuntu/+source/alsa-driver/+bug/296738?
[12:36] <maco> oh, ok read further
[12:36] <maco> the summary at the top isnt descriptive
[12:37] <BUGabundo_work> humm
[12:37] <BUGabundo_work> maybe I should have opened a new bug ....
[12:37] <BUGabundo_work> that bug is getting too confused
[12:37] <BUGabundo_work> mine is very simple
[12:37] <BUGabundo_work> sound muted after reboot!
[12:38] <maco> reading the part where Kevin talks *other* than the top part, you make sense there
[12:38] <BUGabundo_work> yeah
[12:38] <BUGabundo_work> that's why I subsc to that bug
[12:38] <maco> the part that is in desperate need of linebreaks didn't make sense ;)
[12:38] <BUGabundo_work> eheh
[12:38] <BUGabundo_work> edit the desc as you see fit
[12:39] <BUGabundo_work> maco: I'll have to go have lunch or won't be back on time for work
[12:39] <BUGabundo_work> see you in 50 min!
[12:39] <BUGabundo_work> we'll discuss other sound bugs latter, okay?
[12:39] <maco> BUGabundo_work: im going to bed soon. ill talk to you about this in the eastern us afternoon, k?
[12:40] <BUGabundo_work> I'm here until 5pm GMT
[12:42] <maco> ok
[12:45] <maco> BUGabundo_work: i commented on the bug
[13:20] <BUGabundo_work> I'll take a look maco
[13:37] <BUGabundo_work> maco I added the debug info and a comment
[14:40] <afflux> james_w: hi, just read your mail for the python3.0-predepends-issue
[14:43] <afflux> james_w: is this an issue for -devel or for -motu? I'm not quite sure of the difference between these two lists ;)
[14:45] <james_w> I would say -devel for this one
[14:45] <james_w> while the package is in universe it will be in main sometime soon
[14:45] <james_w> and this issue feels more like a -devel one anyway
[14:45] <afflux> okay
[14:47] <james_w> thanks afflux
[14:47] <afflux> thank you
[15:23] <bddebian> Boo
[15:30] <BUGabundo_work> autch
[15:30] <BUGabundo_work> ei bddebian don't give us scares like that!
[15:32] <bddebian> :)
[16:17] <BUGabundo_work> afinal kal era o pro aris?
[16:34] <samuraipenguin> Hi guys.  question on bug 109289, which diff is being asked for?
[20:49] <chrisccoulson> james_w - do you have a few minutes to talk about system-tools-backends?
[20:49] <james_w> chrisccoulson: for you, anything :-)
[20:50] <chrisccoulson> thanks ;) i've tried to catch seb128 on here too but i'm always on here too late i think
[20:50] <chrisccoulson> i tried running it without an init script for a little while to see if it is something that could be considered for jaunty
[20:51] <chrisccoulson> i tried constantly rebooting and then firing up one of the gnome-system-tools apps to see how reliable it was
[20:51] <chrisccoulson> and i did get an error once unfortunately, although i can't repeat it now
[20:52] <chrisccoulson> but the upgrade bug is actually fixed in jaunty by some other means, assuming the theory about it being started by the system bus is correct
[20:52] <chrisccoulson> i thin you know which bug i'm talking about (sorry, i can't remember the bug number now)
[20:53] <james_w> yeah, I remember
[20:53] <chrisccoulson> bug 294389 is the one
[20:53] <james_w> if it's fixed, that's a good start
[20:54] <james_w> and so we might as well keep the init script I guess, especially if you think it may cause a bug
[20:54] <chrisccoulson> yeah, i've proposed a patch for intrepid SRU. i just wanted to make sure you're aware that dropping the init script might not be a good idea straight away
[20:55] <james_w> cool, thanks
[20:55] <james_w> good to know
[20:56] <chrisccoulson> although, i still think that shipping an init script and a DBUS service should be unnecessary. i don't think both are needed, and if gnome-system-tools fails when the backend doesn't exist, even when it gets started by DBUS, then that's probably a bug in g-s-t
[21:07] <chrisccoulson> just looking at bug 301811
[21:07] <chrisccoulson> very odd. i'm failry sure it's not actually a gnome-power-manager bug
[21:07] <chrisccoulson> does anyone have any idea what might cause a locale-specific bug like that?
[21:14] <james_w> chrisccoulson: isn't that from just having mammoth labels for those sliders?
[21:14] <chrisccoulson> i've just tried it on my machine actually. there are 2 issues. issue 1 is the length of the labels. issue 2 is the length of the sliders also doubles with hungarian locale
[21:15] <chrisccoulson> issue 2 might actually be a g-p-m bug, but i'm not sure
[21:19] <james_w> ah, they double? odd
[21:23] <chrisccoulson> it is a little odd. i think someone reported a similar locale specific issue against firefox a little while ago (all the input dialogs were really long with one locale), but i'm sure that bug was triaged against firefox itself
[23:23] <BUGabundo> I'm at #pidgin trying to debug a memory leak
[23:23] <BUGabundo> anybody here using pidgin (preferebly on 64bits) can check its memory usage on ubuntu?
[23:23] <BUGabundo> VM and Resident Memory


[00:09] <maxb> Hmm
[00:09] <maxb> I was going to push 2.3b2 to the beta-ppa
[00:10] <maxb> But now I think it would be better if I first figured out how to make bzr selftest run as part of the build
[00:10] <maxb> But I'm too sleepy for that, so later.
[00:15] <lifeless> mgz: around?
[00:32] <thumper> poolie: I've been thinking about the underlying problem
[00:32] <thumper> poolie: and I've come up with two repeating problems
[00:33] <poolie> ok
[00:33] <thumper> 1) we have no initial idea if we are trying a write or read operation
[00:33] <thumper> 2) we don't have a clear way to ask "does this exist" without poking the filesystem
[00:33] <thumper> by removing the FileNotFound errors
[00:33] <thumper> it opened a world of hurt
[00:34] <thumper> which stopped being able to push branches
[00:34] <thumper> and I can't think of a clean way to get errors out of translatePath
[00:34] <thumper> with lead me to think that we should have an earlier check
[00:34] <thumper> which can have better "smarts"
[00:35] <thumper> I wish we had some smart command that allowed us to say: I want branch "X" for writing
[00:35] <thumper> or I want branch "Y" for reading
[00:35] <thumper> although even that probably isn't enough
[00:35]  * thumper is thinking stacking
[00:35] <thumper> we could then do our smart branch lookup
[00:35] <thumper> with clean semantics early on
[00:36] <poolie> i agree specifying that earlier would be good
[00:36] <poolie> it would also let us give a better message on http
[00:36]  * thumper nods
[00:36] <lifeless> what are the contracts and constraints of translatePath ?
[00:36] <thumper> lifeless: well...
[00:37] <thumper> lifeless: probably best talked through if you're willing
[00:42] <poolie> what do you mean by "without poking the filesystem"?
[00:44] <peitschie> jelmer: are you around atm?
[00:44] <jelmer> peitschie: yep
[00:45] <peitschie> jelmer: cool.  a quick query, I'm recreating our svn repo from scratch, but want to preserve the history from the existing bzr branches.... is fetch ghosts likely to reintroduce any history issues?
[00:46] <peitschie> jelmer: or is there a better way to get the bzr history linked up in the new repository?  theres quite a few branchs (~400 i think...) so manually is a little bit painful :)
[00:48] <peitschie> jelmer: a bit more context might help for you... specifically, we've encountered bug #485601 again... I didn't create the new repo last time as suggested so am doing it now :)
[00:52] <peitschie> jelmer: argh... realised that missed some vital joining bits as well!  What I *mean* to say, is I am creating a new bzr shared repo from the existing svn trunk
[00:52] <jelmer> peitschie: yeah, fetch ghosts should do the right thing in that case
[00:53] <peitschie> jelmer: cool!  that will make this a lot less painful than I feared
[00:54] <poolie> thumper: i'd like to see a bug saying what the behaviour ought to be case by case
[00:55] <peitschie> jelmer: oh... that was a fun experience
[00:55] <peitschie> jelmer: I can't fetch ghosts... as this encounters bug #485601 again
[00:55] <jelmer> :-(
[00:55] <peitschie> i suppose that makes sense... lol... now just gotta find a way to fool things...
[01:00] <peitschie> hmm... there seems to be a specific checkin that has poisoned the broken repo
[01:00] <peitschie> as soon as I attempt to pull any branch across that references this broken rev, things go dodgey
[01:01] <peitschie> awww... i scared jelmer off :(
[01:01] <peitschie> jelmer: if I can hunt down the exact svn checkin that causes this rev error... would that be of any assisstance with the missing chk nodes bug?
[01:03] <jelmer> peitschie: I'm not sure - didn't somebody (you?) already post a script for reproducing the chk node bug?
[01:03] <GaryvdM> Yhea - Productive night for me. - Goodnight all...
[01:03] <peitschie> jelmer: I haven't been able to yet.  I posted some more thoughts about it... but I keep struggling to be able to reproduce
[01:03] <jelmer> g'night Gary
[01:05] <peitschie> jelmer: i'm pretty much shooting in the dark with the latest one, as I spent ages the other night trying various permutations to try and get the crash.  I've posted up on that bug the exact workflow we use essentially... but haven't been able to narrow down why it works 99% of the time
[01:05] <peitschie> jelmer: bzr-svn is frustratingly stable sometimes :D
[01:07] <jelmer> peitschie: a way to reproduce the chk node bug or even a public repository that demonstrates the issue would be a big help.
[01:08] <jelmer> peitschie: unfortunately this is a combination of a bzr-svn and a bzr bug; bzr (imho at least) shouldn't be giving an exception this low in the stack, it should give a sane exception when called with invalid parameters.
[01:08] <jelmer> peitschie: and of course bzr-svn is at fault for calling it with invalid parameters in the first place.
[01:08] <peitschie> jelmer: i know! (programming is my day job too... without reproduction steps it's usually a lost cause) problem is I don't know what I'm looking for really.  I can verify which part of the check is failing on the insert, and have dabbled with dropping break-points in various spots to see the stack... but my knowledge of bzr is lacking heavily
[01:10] <peitschie> jelmer: that would correlate with my impressions too... this is a joint bug of some type.  I can make the exception throw out the chk node it's complaining about... but don't know what to do with it from there.  That is why I was wondering if potentially identifying the file/commit/? that this is related too and comparing this to the svn properties or similar might give some hints?
[01:11] <peitschie> jelmer: of course... i'm still hopelessly unbazaared so have been lurking here for help
[01:14] <jelmer> it should be possible to convert the chk node back to the related file id
[01:15] <jelmer> I need to get some sleep though.. I'm usually around during Australian mornings, or perhaps one of the other bzr devs can help debug.
[01:17] <spiv> jelmer: g'night!
[01:17] <peitschie> jelmer: fair enough :).  Thanks for your help!  sleep well
[01:17] <spiv> Hmm, I suppose my chk-used-by hack could be extended to look at more than just root keys.
[01:17] <jelmer> spiv: hi and goodnight (-:
[01:17] <spiv> :)
[01:18] <peitschie> spiv: would you have some time to give me a hand again?  I've recreated a clean repo from svn trunk, and am trying to branch history across to the new repo... but keep hitting the same chk nodes issue
[01:24] <spiv> peitschie: hmm, what can I do though?  Extend chk-used-by to look at more than just root nodes?
[01:25] <peitschie> spiv: thas pretty much all I was hoping for if you could :)
[01:26] <peitschie> oh... wait... thats a little cool
[01:26] <peitschie> if i fetch the right revision set, I get "Cannot add revision(s) to repository: missing referenced chk root keys"
[01:28] <spiv> peitschie: ah!
[01:28] <spiv> peitschie: that's good :)
[01:28] <peitschie> spiv: if I branched an svn branch that suffered from bug #522637... would bazaar automatically recover from that bug on the way through the branching? or will I then need to reconcile the repo afterwards...?
[01:29] <spiv> peitschie: 'bzr branch' won't usually automatically correct that
[01:29] <spiv> peitschie: but is the source branch an svn branch?
[01:31] <peitschie> spiv: yes.  The "Central" source control is svn, so that has trunk.  So what I did was branch straight from that trunk again.  I'm wondering though if the revision data bzr is finding in there is incorrect tho... and so I am essentially creating a freshly broken repository
[01:31] <spiv> peitschie: ok, that's very interesting
[01:31] <peitschie> spiv: running the chk-used-by i have now gotten 3 revisions in the broken one that use it
[01:31] <spiv> peitschie: because AFAIK bzr-svn is causing CHK records to be created on the fly (because the underlying SVN repo doesn't use that)
[01:32] <spiv> peitschie: which version of bzr itself are you using?
[01:32] <poolie> hi spiv
[01:33] <peitschie> spiv: we only just upgraded to 2.2.1 in the last few weeks.  We've been running on 2.0 & 2.1 for the last 3ish months.... with around 3000 commits to svn in that time... I think roughly 9000 commits to the bzr repo
[01:34] <spiv> 2.2.1 is new enough to have the fix to 522637, so it shouldn't be generating non-canonical CHKs that cause the error you just saw.
[01:35] <peitschie> spiv: that is correct... but I suspect the bug happened prior to 2.2.1 being released.  Looking at this stuff, the bug happened on a commit to svn trunk on sept 1st
[01:36] <peitschie> spiv: what I mean by that is the missing sha1 is referenced by that commit at the earliest
[01:37] <peitschie> spiv: which happened to be a commit to svn directly, so the network repo would have gotten second hand info about that commit when it updated from svn.... mayb a non-canonical chk was created and inserted along side that revision?
[01:37] <spiv> peitschie: hmm
[01:37] <spiv> I wouldn't have thought that the SVN repo would be storing references to CHKs at all, though
[01:38] <peitschie> spiv: let me go look :)
[01:38] <spiv> Because that's an implementation detail of bzr's 2a format
[01:38] <spiv> And not something that would make sense to store in SVN, because it has its own mechanisms already to store trees of files.
[01:38] <peitschie> i know bzr-svn stores a bunch of properties along with the checkin
[01:39] <peitschie> from previous glances it looks like bzr-svn stores enough information to be able to track base revisions and such
[01:41] <spiv> Right
[01:41] <spiv> The CHK stuff is basically just a storage optimisation, though
[01:42] <spiv> It's possible to fully represent the data bzr records without it (just it will tend to be less efficient to do so)
[01:43] <spiv> FWIW grepping the bzr-svn source I don't see any obvious sign that it would ever store CHK info in a SVN repository.
[01:43] <peitschie> ahh k
[01:43] <peitschie> well... the data stored against the rev is things like:
[01:43] <peitschie> slidetraytemperature-20100901004344-1c1ttvdesj7oryzv-1
[01:43] <peitschie> 13860@464e02c1-a7d9-0310-851b-f51ca712b586:products%2FBondAdvance%2Ftrunk%2FBond%2FInstrument%2FInstrumentControl%2FController%2FMessageAdaptors%2FHeatersAdaptor.cs
[01:44] <peitschie> ahh
[01:44] <peitschie> wait
[01:44] <peitschie> so it was merged into svn eventually
[01:44] <peitschie> but the revision was directly committed to bzr first
[01:44] <peitschie> then svn just had the merge committed
[01:46] <peitschie> it looks like the referenced chk root key was introduced as part of a merge
[01:47] <peitschie> that is... the first time this referenced sha appears is when i merged from svntrunk to my feature branch
[01:48] <spiv> Ok, and the bzr repo you are branching into is the same one that has this other bzr branch that has been merged into svntrunk?
[01:48] <peitschie> yep
[01:49] <peitschie> essentially... we have svntrunk, then a network repo that also has a copy of svn trunk + all feature branches
[01:49] <spiv> And this bzr data pre-dates you upgrading to bzr 2.2.1?
[01:49] <peitschie> then each dev has a local repo with a bound branch to their feature
[01:49] <peitschie> yep... this data pre-dates 2.2.1
[01:49] <spiv> If so, it's fairly likely that following the repair instructions on #522637 will fix it.
[01:49] <peitschie> I did run the repair tool for that bug tho
[01:50] <peitschie> so this is the repo after that tool has been run across it
[01:50] <peitschie> and at this point, if I recreate the local devs repo, they can commit to their feature only until someone checks into svntrunk
[01:51] <peitschie> at this point, the dev that committed to svntrunk can continue to commit as per normal, but every other dev hits the missiing chk nodes bug
[01:51] <peitschie> (to recreate teh local dev repo, I simply branch the NETWORK bazaar version of svntrunk into a new repository, so the dev gets all the bzr history with their repo)
[01:52] <spiv> Did the
[01:52] <spiv> repair tool log any lines like "Non-canonical CHK map for ..." in your ~/.bzr.log?
[01:53] <spiv> Also, could you elaborate on "at this point" a bit more?
[01:54] <spiv> Each dev has their own bzr repo, I assume?
[01:55] <peitschie> (i didn't connect that was ur tool btw.  i do appreciate all your work here... i'm in awe of the tool you guys have built here)
[01:55] <spiv> But as soon as they pull/merge a revision from svntrunk that was committed by another dev using bzr-svn they encounter this bug?
[01:56] <peitschie> so.. the setup is as you said
[01:56] <spiv> And precisely on which operation do they get an error?
[01:56] <peitschie> each dev has their own repo, but the feature branchs are actually bound branches that point to the network one (so we keep things backed up in case an individual pc dies)
[01:57] <spiv> (ugh, my grammar is terrible!)
[01:57] <peitschie> *usually* the dev will hit this bug when they attempt to merge & commit changes from svn trunk into their feature branch
[01:57] <peitschie> e.g., bzr merge ..\svntrunk && bzr commit -m "Merging trunk"
[01:58] <peitschie> it will then blow up with bug #522637 at this point, and refuse to commit
[01:58] <spiv> So the merge succeeds, but the commit fails?
[01:58] <peitschie> yep
[01:58] <spiv> That's extra bizarre :)
[01:58] <peitschie> they can then simply throw away the commit, and keep working as normal and committing... but can never get changes in from svn trunk
[01:58] <spiv> And they are definitely using 2.2.1?
[01:58] <peitschie> i never realised how close bizarre and bazaar sounds until ppl say that all the time in real life lol
[01:59] <peitschie> they are now... and the same issue still occurs
[01:59] <spiv> Hmm.
[02:00] <spiv> What if they run the repair tool (on their local repo *and* the bound repo) between the merge and the commit?
[02:00] <spiv> (And does the repair tool log anything about non-canonical chk maps in ~/.bzr.log?)
[02:01] <peitschie> due to how long the repair tool takes I haven't tried that
[02:01] <peitschie> i checked my logs and the first run of the tool has been lost unfortunately
[02:01] <spiv> Yeah, I understand :(
[02:02] <peitschie> i was hoping that once the network repo was fixed, each dev then only needs ~30mins to get their working sets back up again
[02:02] <peitschie> hmm
[02:02] <peitschie> so it appears that either way, teh reconcile has still left this revision hanging in the network repo that causes the missing chk root keys
[02:03] <spiv> This is sounding very much like 522637, though, or something closely related.
[02:03] <spiv> When you say "network repo", you mean the repo that devs have their branches bound to?  Or the SVN repo?
[02:03] <peitschie> the one their branches are bound to
[02:04] <peitschie> oh wait... i meant to say way prior... the merge works, but the commit actually blows up with bug #485601... not the one i had there
[02:05] <peitschie> *but* if I attempt to branch the networked version of svntrunk (this is all bzr only... not svn interaction), I get bug #522637
[02:06] <spiv> Hmm.
[02:07] <peitschie> if it'd help i can draw up a pretty diagram and instructions lol... it is a slightly convoluted workflow to explain :)
[02:08] <spiv> Hmm.  The distinction between those two errors might not be very important: one is that the root node of a CHK map is missing, the other is that a non-root node is missing.
[02:08] <spiv> It's otherwise a sanity check at the same point in the code.
[02:09] <peitschie> thats what i started suspecting.  dont know if that helps anything much tho
[02:09] <spiv> Either way, it suggests that at some point CHK maps are either not being generated correctly (i.e. the wrong nodes), or generated incompletely, or that we are losing nodes during a fetch.
[02:10] <spiv> All 3 options should be equally impossible :)
[02:10] <spiv> The slightly different errors are certainly interesting, and I think a useful hint.
[02:11] <spiv> But I'm pretty sure they are a manifestation of the same root cause.
[02:12] <spiv> What's weird is that these checks are run on every write to the repository.
[02:12] <peitschie> i'm looking at the earliest rev to reference these and seeing where it came from
[02:12] <spiv> So if the merge works, and it does, then the data being pulled across by merge is apparently complete.
[02:13] <peitschie> mm... it's not a big merge either
[02:13] <spiv> (Not necessarily *correct*, bug 522637 can create data that passes this check but causes trouble for new data generated against the bad data)
[02:14] <peitschie> has 2 revs... 1 rev is a single binary file, second rev is a few sources + a bunch of binary files
[02:14] <spiv> Only file modifications
[02:14] <spiv> ?
[02:14] <peitschie> 1st is a file modification, 2nd are all new files
[02:14] <spiv> Hmm.
[02:15] <spiv> Ok, at this point I'd really like to know that it's not another case of 522637.
[02:16] <spiv> I can't see how, but obviously some assumptions need questioning at this point :)
[02:16] <spiv> https://code.edge.launchpad.net/~jameinel/+junk/bzr-check-chk is a plugin that will be useful
[02:16] <peitschie> getting it now...
[02:17] <spiv> You can give it a range of revisions, and it can tell you if they are broken in a way that reconcile --canonicalize-chks will repair
[02:17] <peitschie> range... it works by branch or repo?
[02:17] <spiv> Branch
[02:18] <spiv> So you can use it to relatively cheaply check if e.g. 'bzr merge' from svntrunk has this corruption.
[02:20] <peitschie> i'm running it over the networked repo's trunk at the moment
[02:20] <peitschie> then i'll do it in the branch it first appeared in
[02:20] <spiv> In fact, it seems to me that if 'bzr merge ..\svntrunk && bzr commit' fails on commit but not merge that it's likely that either the new revisions fetched by 'merge' are broken, or the most recent parents of those are, or one of the recent parents of the current tip you are trying to commit on are.
[02:21] <peitschie> that would reflect how it appears to behave
[02:21] <spiv> Note that tool is actually slower than 'bzr reconcile --canonicalize-chks' per revision, so it'll only be faster to use it if you give a range of revisions rather than letting it check the whole repo.
[02:22] <peitschie> if i then delete the individual dev's repo, and create a brand new clone from the network repo again, the problem goes away... until the next bzr checkin lands in svn that both the dev and the remote repo retrieve
[02:23] <peitschie> ok... check-chk on trunk hasn't turned up anything for the revision range where the affected root key was merged in
[02:23] <peitschie> i've widened the range to work earlier slightly and am running again
[02:23] <spiv> Basically at this point I'd really like narrow down where the corruption is being introduced.
[02:24] <spiv> Because so far in isolation all the individual pieces sound fine.
[02:25] <peitschie> ahh the fun of complex interactions :)
[02:25] <spiv> And e.g. glancing at the bzr-svn source it seems to be fetching revisions from SVN to bzr in a totally reasonable way, so I wouldn't tend to suspect it.
[02:25] <spiv> Except that the only people reporting this bug are using bzr-svn...
[02:26] <peitschie> i wonder if it is something related to two different repos with slightly different history available coming up with a slightly different revision somehow
[02:27] <peitschie> svn would b the key then, because of it's effect on ghosting various parts of teh revision
[02:27] <peitschie> under normal bzr operation, the situation doesn't seem quite as common as for bzr-svn
[02:27] <peitschie> (the ghosting situation that is :))
[02:28] <spiv> Possibly, yes.  I mean, in principle that should be fine!    I've been considering throwing together a fuzzer of sorts so that I can set up a repository and essentially simulate a whole bunch of changes being made... working on the theory that i will eventually hit this again
[02:33] <spiv> No, not really.
[02:33] <spiv> I mean, we have a perfectly decent API ;)
[02:33] <peitschie> oh... that check-chks doesn't work with a branch that has ghosts by the way
[02:33] <peitschie> i didn't want to go through the api for fear that it was bzr-svn's use of said api that was doing something "unusual"
[02:34] <spiv> Oh, interesting.  I guess I can see that.
[02:34] <lifeless> well bzr-svn is an implementation of the api
[02:34] <lifeless> so its a bit special in that regard
[02:35] <peitschie>  i can't run check-chk on the clean checkout of svntrunk due to the ghost thing... is there any easy way we can fix that?
[02:36] <spiv> peitschie: specify revisions one by one?
[02:36] <peitschie> lifeless: thats wat was one of the questions... one of teh bugs is only affecting bzr-svn users, which suggests bzr-svn's usage is a little different from standard bzr somehow... likely in some very subtle way... hence why i'm thinking of fuzzing via the file system directly rather than the bzr api
[02:37] <lifeless> peitschie: I think you misunderstand me.
[02:37] <lifeless> peitschie: bzr-svn is an *implementation* of the API
[02:37] <lifeless> peitschie: its not a consumer of it in the usual sense, at all.
[02:38] <lifeless> peitschie: this is what makes bzr-svn glue in so nicely to the core
[02:38] <peitschie> lifeless: ahh.  sorry :S.  gotchya
[02:40] <peitschie> spiv: so far it hasn't reported any issues with either the new or old repo
[02:42] <spiv> Hmm, I wonder if bzr-svn isn't roundtripping inventories perfectly.
[02:44] <peitschie> is there any way to verify that you can think of?
[02:46]  * spiv adds a note to the bug while he's thinking of it, so jelmer will see it
[02:46] <spiv> Basically, compare the CHK root keys before and after roundtripping.
[02:47] <peitschie> hmm
[02:47] <peitschie> i can probably try and branch the revisions just prior to this issue from the broken dir
[02:47] <spiv> i.e. make a revision in bzr repo A, commit/push it to the SVN repo, and fetch it into bzr repo B.  I suppose if you're seeing this bug, and this theory is right, you already have examples of this.
[02:48] <spiv> Then use the bzr APIs to tell you what the CHK root keys for that revision's inventory are in A vs. B.  They are supposed to be the same.
[02:48] <peitschie> the challenge is finding the exact combination that causes it to break :).  things work the large majority of the time... so it is a specific sequence of somethings that does it
[02:48] <spiv> You can probably see how to adapt bzr-check-chk or similar to just print the key for a given revision.
[02:49] <peitschie> yep
[02:50] <spiv> (If this theory is right, then it will pass the 'canonical-form' check, because the bug isn't the layout of the CHK, it's that actual inventory contents for a given revision ID are not the same in the two repos.)
[02:56] <peitschie> (all check-chks came back without any issues btw)
[02:56] <spiv> Ok, that's good to know.  Thanks for that.
[03:05]  * spiv -> lunch
[03:32] <peitschie> spiv: let me know wen ur back... i could use a few more pointers :)
[04:01] <peitschie> spiv: i found the dodgey rev... now i need to get the details out of it somehow
[04:04] <spiv> peitschie: back
[04:04] <peitschie> spiv: wb :)
[04:04] <spiv> peitschie: oh nice
[04:04] <spiv> Tell me more about this dodgy rev!
[04:04] <peitschie> spiv: it's rather ... unexpected.  the key revision is a pure bzr rev that has stacked on an svn rev
[04:05] <peitschie> i don't know how to get other debug info out of it yet... i'm quickly testing checking out these revs against trunk
[04:05] <peitschie> once this single bzr rev gets into a branch, every branch from that point onwards shows the missing chk node entry bug
[04:05] <spiv> A pure bzr rev in the same repo it was created it?  Or a pure bzr rev that has travelled via the svn repo?
[04:05] <peitschie> (when i try and branch it into my clean repo)
[04:06] <peitschie> pure bzr
[04:06] <peitschie> so the dev branched off svn trunk (a rev the repo already had), then performed a checkin to their feature branch (pure bzr)
[04:06] <peitschie> i can pull the svn rev into the clean repo
[04:06] <peitschie> i cant pull the dev checkin to the repo
[04:07] <spiv> "pull the svn rev into the clean repo" -- pull from svn -> bzr, or from the first bzr repo?
[04:07] <peitschie> first bzr => second (new clean from svntrunk) bzr repo
[04:08] <spiv> Ok.  I'd definitely like to know if the chk root keys for that rev in both repos match.
[04:09] <spiv> And I assume both the bzr rev and the rev from svn trunk both pass check-chk?
[04:10] <peitschie> checking now
[04:11] <peitschie> these revs were way outside the range i was checking before
[04:11] <peitschie> back in early june sometime
[04:12] <spiv> What do the two revs look like in terms of changes?  Modifies, adds, deletes?
[04:12] <peitschie> the svn rev just prior is adding 2 files
[04:13] <peitschie> the first bzr checkin after is deletes & modifications
[04:13] <peitschie> check-chks says nothing special for those two
[04:20] <peitschie> im currently branching at various trunk revs to see what happens once that revision lands back into trunk
[04:21] <peitschie> ag... duh.. thats not gonna help because the new repo has all trunk revs >.<
[04:21] <peitschie> ok... whats the best way to get all the info we can about these two revisions that cause the problem?
[04:23] <spiv> Modify bzr-check-chk to print the root keys
[04:24] <spiv> (even if they pass the check)
[04:24] <peitschie> they pass the check without any issues
[04:24] <spiv> and then use that to make sure the root keys for those revs are the same in both repos
[04:24] <peitschie> ahh... thats gonna b fun
[04:25] <peitschie> the second commit is only present in one repo... i can't get it in the other
[04:25] <spiv> Hmm, yeah.  Well, just check that one.
[04:25] <spiv> I think it will match, but I'd like to check my assumptions :)
[04:31] <peitschie> sorry it's taking so long
[04:31] <peitschie> i've dropped pdb into ther and am trying to find what i want on the inventory :)
[04:32] <spiv> inv.id_to_entry.key() and inv.parent_id_basename_to_file_id.key()
[04:32] <peitschie> thnx!
[04:33] <spiv> I don't suppose you're able to send me a copy of the repo that exhibits the problem?
[04:34] <peitschie> its 1.2Gb... so it's a little difficult
[04:35] <peitschie> oh... thats not so good i suspect
[04:35] <peitschie> shas for the svn checkin in question are different
[04:37] <echo-area> Hi
[04:37] <echo-area> I'm getting trouble similar to https://bugs.launchpad.net/bzr/+bug/377261
[04:38] <echo-area> The difference is that I got different stack backtrace than that bug
[04:38] <echo-area> Should I file another bug?
[04:39] <peitschie> echo-area: probably a good idea.  It is easier to mark a bug as a duplicate than split a bug out :).  Make sure you mention the other bug in it as well to make it easier for whoever is checking to see
[04:39] <echo-area> peitschie: Okay, I'll do that.  Thanks
[04:39] <spiv> peitschie: ah, so we are getting close after all!
[04:40] <peitschie> spiv: it is starting to look that way a bit.  wat next?
[04:40] <spiv> peitschie: that probably does explain why the next revision that depends on it can't be fetched
[04:41] <spiv> peitschie: if you don't mind sharing some of your data,
[04:41] <spiv> peitschie: send me the output of print inv.id_to_entry._dump_tree(True) and inv.parent_id_basename_to_file_id._dump_tree(True) for both
[04:42] <peitschie> spiv: i can probably talk to people.. I work at a commercial company so things will need to be a little careful.  Whats the easiest way for you to get 1.2Gb...?
[04:42] <peitschie> spiv: even better :)
[04:42] <peitschie> spiv: so you want that of the rev in question correct?
[04:42] <spiv> Yes, and from both repos
[04:42] <spiv> The output will, I hope, be different :)
[04:46] <spiv> And actually, it'd be great if you can send me the output for the parent revision (or revisions?) of that rev-from-svn too.
[04:46] <peitschie> yep... so you want the rev that breaks things, and it's parent rev in both sides?
[04:47] <peitschie> is 7zip ok for the file?  It's way smaller than zip...
[04:50] <spiv> I *think* so.  bzip2 is also good.
[04:50] <poolie> spiv, there is a 7z in ubuntu
[04:51] <peitschie> spiv: I'm attempting to send it now... i'm behind a proxy tho, so if this fails i can email it
[04:52] <spiv> email is fine, andrew.bennetts at canonical.com
[04:52] <spiv> My IRC client says 'DCC unknown ctcp XXXX from peitschie ...'
[04:52] <spiv> So I guess that's not going to work :)
[04:54] <peitschie> yups :)... emailing now
[04:54] <peitschie> it's sent
[04:54] <spiv> Thanks!
[04:55] <peitschie> now heres to hoping it's useful in some way...
[05:01] <spiv> Received ok, I think this is going to be helpful
[05:01] <spiv> What is r4686 is the rev from svn?
[05:02] <peitschie> thats the one that magically starts breaking things
[05:03] <peitschie> so i have a checkin on a branch just past that point, which i cannot branch into my "clean" bzr repo
[05:03] <peitschie> that reminds me, do you want the info from the checkin just past 4686 as well?
[05:04] <spiv> So interestingly 4685 differs in both revs too
[05:05] <peitschie> i've been chasing those back...
[05:05] <spiv> er, in both *repos*
[05:05] <peitschie> they were differening back to the first bzr checkin made
[05:05] <peitschie> so up until the first checkin, it's all identical.  once the first checkin was made, the files immediately start differing
[05:06] <spiv> The inventories have the same files and directories, with the same IDs, with the same contents and the same lengths and the same executable bits...
[05:06] <spiv> *but* some of those files and directories have different revision IDs
[05:06] <peitschie> i thought so
[05:07] <spiv> Which is the inconsistency that is causing all your trouble.s
[05:07] <spiv> So, how precisely were these two repositories created?
[05:08] <peitschie> so... repo 1 (broken) was created with a check out of the entire svntrunk
[05:08] <peitschie> that then served as our network repo since then (early june)
[05:08] <peitschie> repo 2 was created by rechecking svntrunk out a few days ago... that has had no other use at this point
[05:09] <peitschie> as soon as the first bzr checkin is made to the repo, the bzr info that i'm dumping changes
[05:10] <spiv> peitschie: hmm!
[05:11] <spiv> So adding a new bzr revision to the SVN repo is causing future bzr checkouts from that repo to get different results for old revisions?
[05:11] <peitschie> it is looking like it!
[05:11] <peitschie> i am wondering... we got bitten by https://bugs.launchpad.net/bzr-svn/+bug/587819 ages ago
[05:12] <peitschie> i had to manually delete all bzr revision properties from the svn history
[05:12] <peitschie> i wonder if someone forgot to delete their svn cache prior to a checkin...
[05:12] <peitschie> and if that might have poisoned the stack
[05:14] <spiv> peitschie: ooh, sounds messy!
[05:15] <spiv> peitschie: that sounds plausible
[05:15] <spiv> peitschie: I'm out of my depth on that degree of SVN-fu, though.
[05:15] <spiv> peitschie: I think at this point we need jelmer for further diagnosis
[05:15] <peitschie> spiv: i suspected we were hitting that point as well :)
[05:16] <spiv> I've added some more comments to the bug.  We're definitely much much closer now, thank you very much for your persistence.
[05:16] <spiv> And patience :)
[05:16] <peitschie> it's a pleasure :).. i like working with you guys
[05:16] <peitschie> with those dumps that I sent... I dont mind if you pass them out to a dev or too.. just make sure they don't get too far out of ur sight please :)
[05:17] <spiv> Ok, I'll pass them onto jelmer as well
[05:17] <spiv> You should probably add a bug comment with the suspicions about svn caches and deleting old bzr rev props
[05:19] <peitschie> yep... will do
[05:19] <peitschie> if it is related to that... that took a scarily long time to bite :S
[05:37] <peitschie> spiv: wb :)... another quick query... is it worth me doing a check-out of svn using an older version of bzr (2.0 or 2.1) to see if that is different too?
[05:38] <spiv> Hmm, I don't think so.  But then I still don't quite know what's going wrong, so what would I know? :)
[05:39] <peitschie> hehe... i know that feeling :S
[05:39] <peitschie> i'll hold off then and see how far jelmer can get on wat we've given him
[05:39] <peitschie> thanks again for all your help digging that out... It would have taken me all week to do that without your guidance!
[05:43] <spiv> If my own experience with these bugs is any guide, longer probably ;)
[05:44] <peitschie> aint that the truth... it scares my poor little mind thinking about it :S
[06:23] <mgz> lifeless: I'm around now if you're still after me.
[06:24] <lifeless> mgz: yeah, you fixed timing data from parallel stuff
[06:24] <lifeless> I was wondering if any of that was still in bzrlib, or if its all in testtools nows
[06:25] <mgz> it's moved to testtools basically.
[06:25] <mgz> https://code.launchpad.net/~gz/bzr/use_testtools_timings_625594/+merge/36784
[06:25] <mgz> that's the bzr mp that does it.
[06:29] <lifeless> thanks
[07:06] <vila> hi all !
[07:07] <vila> poolie: did you get an email for the shortcuts failures ? Can I have a copy ?
[07:08] <mgz> vila: yes, lp:~gz/bzr/escape_selftest_console_output_633216 depends on a non-broken-with-unicode testtools version
[07:08] <vila> poolie: regarding the http tests, the code is not called because the http client coalesce the offsets. The tests need to be tweaked to avoid that, but doing so led to a hang when I briefly tried yesterday. Why it hasn't been noticed before is... unfortunate :-/
[07:08] <mgz> and I'd like to see the failure spiv got with it as well.
[07:09] <vila> mgz: yup, hence my ping in the review comments
[07:09] <vila> spiv: ^
[07:10] <vila> poolie: and to avoid problems, please send this mail to my canonical address
[07:11] <vila> poolie: I reported the problem to my ISP but I'm not holding my breath, *one* postmaster for millions of users to handle false positive spams... hmmm, does it blend^W scale ?
[07:11] <mgz> should make pqm post a summary to the mp
[07:12] <poolie> hi vila, i did get a failure mail
[07:12] <poolie> vila: sent
[07:12] <poolie> mgz we should use tarmac
[07:12] <mgz> or that.
[07:12] <poolie> vila, i'm also reviewing your config mp
[07:12] <poolie> or, at least, work out why not to use it
[07:13] <poolie> vila, well, it's nice we noticed now
[07:14] <vila> poolie: noticed what ?
[07:14] <poolie> noticed the http test wasn't reached
[07:16] <vila> ha, yes, we may just get rid of the tests, they try to ensure a pretty unlikely regression and the hang may be a real bug in the test server
[07:25] <vila> poolie: if you can't "work out why not to use it" I'd be happy to land it and work on the *next* steps ;)
[07:28] <vila> poolie: ok, got the PQM failures mail. That's insane, what the hell is different on the pqm instance...
[07:33] <poolie> vila, i meant either use Tarmac or get a good idea why not
[07:33] <poolie> but maybe not today
[07:34] <vila> poolie: did Tarmac allows running the test suite before landing ?
[07:34] <poolie> it should
[07:34] <poolie> i haven't tried this week
[07:34] <vila> ok
[07:34] <poolie> i mean i haven't tried yet; i hope to try this week or next week before UDS
[07:35] <poolie> have you touched fastimport at all?
[07:46] <vila> never
[07:47] <vila> hmm, at least nothing I can recall, I may have fixed some test failures though ;)
[07:57] <lifeless> PQM has code to comment on the MP
[07:58] <lifeless> and rockstar has overhauled the API - a small tweak to use the new API next week, and it should be usable.
[07:58] <lifeless> using tarmac would be good too
[07:59] <lifeless> poolie: I've merged your testscenarios patch; it needed a little tlc to be up to your normal standards, so I did that as I merged.
[08:00] <poolie> thanks, i saw
[08:00] <poolie> vila, are there any unit tests for urllib2_wrappers?
[08:01] <poolie> nm, i can grep
[08:02] <GaryvdM> Morning all.
[08:03] <lifeless> poolie: if you want to depend on testscenarios, I'd be delighted to do a release of it for you
[08:13] <vila> poolie: I don't think so. For historical reasons, I always wrote tests against both _pycurl.py and _urllib.py
[08:32] <vila> poolie: thanks for the review !
[08:33] <vila> poolie: note that s/from fnmatch import fnmatch/import fnmatch/ is actually a genuine case where it's *required* I need to access *another* symbol in the module !
[08:35] <poolie> lifeless: i wouldn't mind
[08:35] <poolie> it's not very compelling at the end because we have the equivalent in hose
[08:35] <poolie> *house
[08:35] <poolie> the main thing i would like to do would be to clean up ad-hoc parameterization by subclassing
[08:35] <poolie> unfortunately it's a bit hard to grep for
[08:41] <lifeless> poolie: grep -i 'base|mixin' tests ?
[08:41] <poolie> that'll be close, also for xxx comments
[08:41] <poolie> if they can all be cleaned up in a good way that'd be quite a positive step
[08:41] <poolie> probably no reason why they can't be
[08:42] <poolie> well, positive for the code and good validation of scenarios
[08:44] <lifeless> yes, OTOH you could in principle delete the in-tree copy eventually :)
[08:44] <lifeless> I'll see about a release this weekend or so
[08:46] <poolie> i'd kinda like to delete the in-tree copy
[08:46] <poolie> i wonder, empirically, how much pain do dependencies cause for packagers?
[08:49] <poolie> vila, i pushed my branch, i'm curious what you think of the tests
[08:53] <vila> poolie: tests are nice
[08:54] <vila> poolie: as for the fix... I don't understand why 'port' is not set in auth... istm it should in which case your fix is not in the right place, but ibmw
[08:55] <vila> poolie: it's especially weird that you create the auth *section* with port, but still get no port in the auth entry
[08:57] <vila> poolie: may be I just don't remember the code path well enough anymore :-/
[08:57] <vila> poolie: ha, right, you explained that clearly in the cover letter, sorry, went straight for the diff
[09:06] <vila> poolie: I replied to your config review and need additional answers to progress :)
[09:11] <poolie> thanks for that
[09:12] <vila> poolie: I've approved you mp for the auth password (port really) and I'm now changing my hat to RM and will announce 2.3b2
[09:13] <vila> poolie: we have installers for OSX and windows ready and maxb is working on the beta ppa (activating the test suite run AIUI) so it should be ready soon too
[09:13] <vila> maxb: Did I get this right ? Do you need help there ?
[09:28] <poolie> thanks vila
[09:45] <maxb> vila: Aaaaaaaaaaaaaaaaaaaagh. Why? WHY!? WHY is bzr packaged using cdbs!??!
[09:45] <poolie> night all
[09:45] <maxb> (I just looked at the debian/rules and cried)
[09:46] <vila> maxb: excuse my Klatchian, but what is cdbs ?
[09:46] <maxb> on the plus side, it appears there is a test invocation already in there, but disabled
[09:46] <maxb> cdbs is an evil monstrosity that results when someone thinks it's a good idea to build an extensible class library of Makefile fragments
[09:46] <maxb> for debian package building
[09:48] <maxb> Well I'm just going to ignore that and pray just toggling the conditional works :-)
[09:48] <vila> hehe, sounds like a plan ;)
[10:06] <aboeing> hi. does anyone know how to insert a revision string into source code from bzr?
[10:07] <aboeing> for example, after a commit, set a variable REVISION_STRING = 1234
[10:11] <lifeless> the feature used to do that is 'filters'
[10:11] <aboeing> lifeless: thanks, would you have an example of this?
[10:12] <lifeless> have a look on the plugins page
[10:12] <lifeless> there's at least one filter there - the end of line one, for windows users.
[10:21] <aboeing> Thanks, found this which looks like what I need: https://launchpad.net/bzr-keywords
[11:20] <inge> Dear Members of bzr channel, we have a problem with bzr and file system access I wonder if anybody can help.
[11:21] <inge> The repositories are located at a server which is mounted to a directory any user can internally access, this is /home/bzr.
[11:21] <maxb> It's always best to actually ask a technical question rather than asking to ask. it lets people gauge whether they have relevant experise.
[11:21] <maxb> * expertise
[11:22] <inge> Anytime I do a bzr co --lightweight /home/bzr/REPOSITORY the bzr command will not return. I can only kill the shell but the bzr process still exists as a zombie and locks a file in the repository "dirstate"
[11:25] <inge> Our assumption is that it could have something to do with NFS4 we migrated to lately, does anybody know something about it?
[11:25] <mgz> if you ctrl+\ where is the process stuck at?
[11:25] <mgz> blaming nfs is probably right.
[11:26] <inge> ctrl+\ does not do anything
[11:29] <Kamping_Kaiser> inge: what were you usinb before you put in nfs?
[11:30] <inge> we where using nfs3, no problems then
[11:31] <inge> I was trying to attach to the bzr process with gdb but that doesn't work.
[11:33] <inge> Am I the only one with this problem?
[11:35] <mgz> feel free to poke around on the bug tracker, nothing springs to mind though]
[11:36] <mgz> you might find it useful to add a break point earlier in the process then step through to work out where the hard hang is happening
[11:48] <vila> inge: yes, there are known issues with nfs4
[11:48] <vila> inge: well, known may be a bit optimistic, the problem AIUI is that we don't understand what is happening, but the suspicion is against nfs
[11:50] <vila> inge: but the 'dirstate' file is part of the working tree, it shouldn't be in the repo
[11:51] <vila> inge: may we don't assign the same meaning to repo here...
[11:57] <vila> inge: thinking more about it, the problem I'm aware of related to nfs4 is about OS locks, which are only used for the dirstate files, so if your working trees are *not* accessed via nfs, i.e. only the branches and their repos, then you should be fine
[11:58] <vila> inge: I'm about to leave for a lunch break, but I'll read and answer your questions if needed when I'll be back
[12:17] <inge> vila: I meant the dirstate file in the branch, e.g.: REPOSITORYNAME/.bzr/checkout/dirstate, this is I think part of the branch. The working  trees are not affected by this problem, nor are the update or commit commands.
[12:21] <vila> inge: checkout/ is what defines a working tree, do you *need* a working tree there ?
[12:22] <inge> I think your suspicion with OS locks could be true, checking out first runs normally, only at the end, maybe some finishing operation, it hangs.
[12:24] <inge> vila: I am a bit confused about the checkout/working tree stuff. Just to explain our setup: We have a central branch/repository on a server A, there only the .bzr directories exist. From the other computer e.g. mine I do e.g. a checkout --lightweight to get a cvs like copy of the current files. So no working tree on the server, only at my personal computer.
[12:25] <vila> inge: right, so: http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief
[12:26] <vila> inge: from what you're describing, REPOSITORYNAME/.bzr/checkout/dirstate shouldn't *exist* so we need to find why it's there and get rid of it
[12:27] <vila> inge: can we do that in1/2 hour ? (I didn't get really get this lunch break ;-)
[12:27] <inge> Yes of course, I will wait.
[12:28] <vila> cool, read this url above, I find it quite good at helping us talk about the same things with the same words
[12:28] <inge> I am already reading
[12:50] <fullermd> Oh look, bzr ls doesn't take multiple args.
[13:05] <vila> fullermd: what a shame, file a bug ;)
[13:05] <vila> inge: I'm back
[13:05] <inge> me too, had to reboot, to many zombies
[13:06] <vila> err, which one of you is really you ? ;)
[13:06] <vila> ha ok
[13:06] <inge> sorry, double entry on notebook
[13:06] <vila> so, basically in the end, you need to: 'bzr reconfigure --no-tree' while logged on the server, but I'd like to understand how you end up there
[13:07] <vila> err, --with-no-trees
[13:07] <inge> I don't know if that really is the problem, but I think I have repository and branch in the same location
[13:07] <vila> inge: it's ok, it's what we call standalone branches as opposed to branches using a shared repository
[13:08] <vila> inge: if you have several branches related to the same project, it's generally best to use a shared repo
[13:08] <inge> I migrated the repositories from cvs using tailor, then multiple branches where generated and cross merging, maybe something went wrong then.
[13:08] <vila> my guess would be that someone has been working on the server and used working trees there
[13:09] <inge> Yes that's what we are in general doing.
[13:10] <inge> Your guess could be true. From time to time I find some files next to the .bzr directory on the server. The guy the files beling to  says he is only working in his working tree, not on the server.
[13:10] <inge> Any idea about that?
[13:11] <vila> it's a bit unclear but I suspect some operation on the lightweight checkout *also* update the remote working tree
[13:11] <inge> bzr: ERROR: Requested reconfiguration of '/home/bzr/trunk/MIP/' is not supported.
[13:11] <vila> on the server ?
[13:12] <vila> ha, right, sorry, that should be 'bzr reconfigure --branch'
[13:12] <inge> yes, I am on the server with ssh
[13:13] <vila> that will remove the working tree too
[13:13] <vila> hmm, check for uncommitted changes first maybe :-}
[13:13] <vila> but the command should do that hopefully
[13:13] <inge> okbzr: ERROR: Working tree "/home/bzr/trunk/MIP/" has uncommitted changes (See bzr status).
[13:13] <vila> :)
[13:14] <vila> pfew
[13:14] <inge> yes uncommitted chages, status shows 100 conflicts with files that are not there, I will need a moment to figure that out
[13:15] <vila> hmm, most probably accumulated cruft
[13:15] <vila> if you can confirm that, 'bzr revert --no-backup' will restore a pristine working tree
[13:16] <vila> but don't use --no-backup if you're unsure
[13:17] <inge> what about the subdirectories in .bzr, checkout and branch, can I delete them?
[13:17] <vila> no
[13:18] <inge> I am unsure about the --no-backup, I don't want a working tree there but a clean repository with no branch and no working tree
[13:18] <vila> never touch anything under .bzr/ unless told otherwise :) The only exception being .bzr/branch/branch.conf but even for that we're working on providing a command to edit it
[13:18] <vila> inge: the --no-backup is to restore a clean working tree so you can do 'bzr reconfigure --branch' which will delete .bzr/checkout
[13:19] <vila> err, and you want a lean *branch* with its own private repository
[13:19] <vila> *clean
[13:19] <vila> unless you also want to use a shared repository for multiple branches but we can look into this later
[13:20] <vila> or unless you are already using a shared repository and suddenly get a branch and a working tree there in which case I misunderstood
[13:25] <inge> Yes I want a shared Repository, and I got this branch and working tree in there. Think it was not created correctly by tailor, or we messed it up during merges
[13:59] <inge> vila: ok I went to all repositories and did bzr reconfigure --branch --force and now the checkouts etc. work, no hangs anymore so far
[14:00] <inge> vila: thank you very much for your help.
[14:01] <vila> inge: great !
[14:01] <vila> inge: if you encounter again some weird combination that ends with a remote working tree, please file a bug with a reproducing recipe !
[14:02] <inge> Ok I will, but this time I really don't know how to reproduce that
[14:02] <vila> sure, no problem
[14:37] <poolie> GaryvdM, hi?
[14:56] <jam> morning vila, hey poolie
[14:56] <poolie> hi there jam
[14:56] <poolie> that's a bad sign :)
[14:56] <vila> hey jam
[14:56] <vila> poolie: :)
[14:57] <jam> poolie: I was thinking the same thing
[14:57] <jam> I shouldn't see vila wake up, and you shouldn't see me come online
[14:57] <jam> though you were saying you wanted to see me around more :)
[15:13] <poolie> good night vila, jam
[15:14] <GaryvdM> Hi jam
[15:15] <vila> poolie: good night ;)
[15:15] <jam> sleep well poolie
[15:15] <jam> hey GaryvdM
[15:35] <cbz> trying to use bzr on windows can't find a set of options that will print out the full content of the file with changes
[15:35] <cbz> Tried bzr --diff --using=/path/to/gnu/diff --diff-options="-iwb -U 100000" - but it only shows the limited section around the changes
[15:39] <cbz> any  ideas?
[15:48] <GaryvdM> cbz: I think you are probably looking command line solution. For that I have no idea, but if you open qdiff, and select Unidiff, and Complete, it will give you that.
[15:52] <trashbird1240> I'm trying to migrate a repository from hg to bzr
[15:53] <trashbird1240> I've used fastimport and everything appears to have worked, but how do I update my working tree or create a branch?
[15:53] <trashbird1240> I've followed http://wiki.bazaar.canonical.com/BzrMigration#Mercurial%20%28hg%29
[17:21] <sender> jelmer: you there? any news on the bzr-svn bug that we spoke about last week? :)
[17:34] <jelmer> sender, hi
[17:35] <jelmer> sender, I remember talking with you about it but I don't remember which bug that was. Do you have the bug #?
[17:35] <jelmer> sender, I should be able to have a look at it after I finish my work day.
[17:46] <vila> jelmer: it seems that  bzr-svn and bzr-rewrite needs an API bump to be used with 2,3b2 anf trunk
[17:46] <vila> abentley: bzr-pipeline and probably bzrtools as well
[17:47] <jelmer> vila: that's already happened
[17:47] <jelmer> vila: are you sure you're using the respective trunks?
[17:48] <vila> jelmer: not me someone on the ML
[17:48] <vila> I thought he said he get latest versions, may be it's not running from source...
[17:49] <jam> vila, jelmer: I think he's using a ppa, and got the latest bzr but not updated plugins
[17:50] <GaryvdM> vila: the only plugin that is in the windows installer that has not been bumped in it's trunk is pipeline.
[17:50] <vila> jam: meh, which ppa then ? The beta one still propose 2.3b1
[17:52] <jam> then again, he says "I'm trying this new release" so he certainly could be running bzr 2.3b2 from source but all plugins from the system
[17:52] <jam> /usr/local/lib/... makes it sound like he ran "setup.py install" at least
[17:53] <GaryvdM> Maybe a debian user?
[17:56] <maxb> Language in that email makes me think he is running setup.py install from *source tarballs*
[18:03] <maxb> Can anyone think of an easy way to figure out if bzr selftest is loading compiled extensions or not?
[18:06] <roryy> i get a warning if i don't have compiled extensions, fwiw
[18:07] <maxb> Normally yes. But I think bzr selftest might be different
[18:13] <jam> maxb: you can check the features themselves, and the end of the selftest tells you "X tests not running because of features ..."
[18:13] <jam> GaryvdM: he was also clear that he was running Ubuntu
[18:14] <GaryvdM> oh - I missed that...
[18:27] <vila> maxb: selftest is no different, I see a warning everytime I run without extensions
[18:27] <maxb> hmm. Then, either I'm lucky and magically the right thing is happening, or ./bzr is picking up the compiled extensions from my system bzrlin
[18:27] <maxb> *bzrlib
[18:29] <vila> maxb: I dunno what you are trying to do, but I have a bzr installed and running './bzr' warns
[18:29] <maxb> I was briefly testing how to run the selftest inside the debian package build
[18:30] <vila> maxb: 'make check' ?
[18:30] <maxb> There was existing code in the debian/rules to do ./bzr selftest --no-plugins,
[18:30] <vila> maxb: or 'make check-nodocs'
[18:30] <vila> ha
[18:30] <vila> may be it's triggered after the extensions are built ?
[18:31] <vila> that would makes sense
[18:31] <maxb> it was triggered before they were built. It still didn't warn in my local test
[18:31] <vila> make clean should get rid of the existing ones
[18:31] <maxb> Anyway, I decided that I need to leave shortly so I threw a best-guess into the bzr-beta-ppa for the builders to chew on
[18:34] <mtaylor> w00t! new bzr error I've never seen!
[18:34] <mtaylor> oh - nevermind
[18:34] <vila> mtaylor: go ahead, we love enthusiastic bug reports ! ;)
[18:35] <mtaylor> vila: $ bzr branch lp:drizzle/elliot
[18:35] <mtaylor> bzr: ERROR: Permission denied: "Cannot create 'elliot'. Only Bazaar branches are allowed."
[18:35] <maxb> heh, that's changed from earlier today
[18:36] <mtaylor> well - in _this_ case, lp:drizzle/elliot isn't valid - it should have been lp:drizzle/elliott
[18:36] <vila> mtaylor: oh yeah, it's a lp one, never made sense to me either
[18:37] <mtaylor> the error message should be "you're an idiot - learn to spell!"
[18:37] <vila> maxb: grrrrrr no module named testtools...
[18:38] <maxb> oh. duh. obviously
[18:38] <vila> maxb: you need it to run the tests, I should have thought about it and warned you
[18:39] <maxb> If I'd actually thought about it, or tested in a chroot, I would have realized
[21:15] <jelmer> sender, still there?
[21:25] <rubbs> is there a reference to all the branch aliases? I created a branch and pushed it to our central server, now I want to bind the one I pushed from to the one I pushed too. What's the easiest way to do that?
[21:25] <jam> rubbs: bzr bind :push ?
[21:25] <jam> bzr help location-alias
[21:25] <rubbs> jam: that did it thanks.
[21:26] <rubbs> ah, awesome that's exactly the help entry i was looking for
[22:04] <slangasek> if a remote branch is stacked on a branch which has been moved, how can I make bzr look at the new location instead?
[22:05] <slangasek> (case in point: lp:~chessy/live-build/live-helper.chessy, and lp:~vcs-imports/live-helper/trunk/ vs. lp:~vcs-imports/live-build/trunk/)
[22:05] <jelmer> slangasek: Hi
[22:05]  * slangasek waves :)
[22:05] <jam> slangasek: edit .bzr/branch/branch.conf to reference the new location?
[22:05] <jelmer> slangasek: I think "bzr reconfigure --stacked-on=<new-url>" <branch-url> should do that
[22:05] <mwhudson> slangasek: use lftp to edit .bzr/branch/branch.conf
[22:06] <slangasek> ah, but I don't have commit access to the remote branch :)
[22:06] <mwhudson> find someone who does :/
[22:06] <jam> hey mwhudson, just checking what the next step for the forker service is. you mentioned pqm being frozen, and I don't really know when to remind you to try and land it again.
[22:06] <slangasek> lool: ping ;)
[22:06] <mwhudson> jam: i'll try to remember when pqm reopens i guess
[22:07] <slangasek> jam, jelmer, mwhudson: thanks, will take it up with the branch owners
[22:07] <jam> mwhudson: do you have a date so I could help you remember? (this week, next, etc?)
[22:07] <mwhudson> slangasek: also an admin or a bazaar-expert (eg thumper) can do this for you
[22:07] <mwhudson> jam: if i haven't merged it by next monday, certainly give me a prod
[22:07] <jam> mwhudson: k, thanks
[22:07] <slangasek> mwhudson: mattman should be around, let's make him do it :)
[22:08] <jam> slangasek: though he isn't in #bzr
[22:09] <slangasek> 5~
[22:09] <slangasek> jam: nevertheless, he's where I can get at him :)
[22:13] <thumper> jam: hi
[22:13] <jam> hey thumper
[22:13] <thumper> jam: do you have 15 minutes for a chat?
[22:13] <jam> I probably have 15, though I'm supposed to chat with poolie today (he probably is sleeping in, since I saw him < 8 hrs ago)
[22:14] <thumper> ok
[22:14] <thumper> jam: skype?
[22:14] <jam> works for me
[22:52] <peitschie> mornin everyone