[09:21] <lool> Mar 25 09:00:52 babbage init: Re-executing /sbin/init
[09:21] <lool> getty on ttymxc0 doesn't come up anymore
[10:28] <ogra> lool, on my image or on an installed system
[10:33] <lool> ogra: Any system where you upgrade libc6 or run "init u"; see #-devel
[10:33] <ogra> heh, i just read the latest changes on the bug :)
[10:34] <ogra> lool, btw, how about seeding flash-kernel to desktop on armel and make redboot-tools a dep ?
[10:36] <ogra> so we have it in at least, even though there might be hooks missing we can write a howto to make an sd bootable from a running system
[10:37] <lool> ogra: Perhaps boot instead?
[10:37] <ogra> we have a separate boot seed ?
[10:37] <ogra> thats new to me
[10:37] <lool> We do
[10:37] <ogra> oh
[10:37] <ogra> does desktop/live use it =
[10:37] <ogra> ?
[10:40] <lool> Dunno
[10:40] <lool> ogra: I just grepped for grub in the seeds, I would expect flash-kernel to be selected in similar situations
[10:40] <ogra> i'll talk to colin
[10:41] <ogra> ogra@osiris:~/Devel/seeds/ubuntu.jaunty$ ls
[10:41] <ogra> blacklist  desktop  development  dns-server  doc  dvd  dvd-live  lamp-server  live  mail-server  openssh-server  postgresql-server  print-server  samba-server  server  server-ship  ship  ship-live  STRUCTURE  supported  tomcat-server  virt-host
[10:41] <ogra> hmm, where do you see that boot seed ?
[10:46] <ogra> lool, grub is a dep of the linux-image-* package on x86 and amd64
[10:47] <lool> ogra: That's how I'd expect flash-kernel as well
[10:47] <ogra> i'll file a bug against linux-image-*-imx51 so flash-kernel gets in there, we need a MIR for redboot-tools though
[10:48] <lool> ogra: The boot seed is in platform.jaunty
[10:48] <ogra> intresting
[10:48] <lool> ogra: Happy if you do the redboot-tools MIR; I can then review it
[10:48] <ogra> ok
[10:48] <ogra> redboot-imx is still not approved :/
[10:48] <ogra> i think doko looked at it but didnt even leave comments on the bug
[10:49] <ogra> (its funny that ecos made it but redboot didnt yet)
[10:50] <lool> I think people are reluctant to touch archive-ish stuff at the dawn of a beta release
[10:51] <ogra> well, we want it in post beta at least
[11:01] <ogra> Bug #348382
[11:01] <ubot4> Launchpad bug 348382 in linux "linux-image-*-imx51 is missing a dependency on flash-kernel" [High,New] https://launchpad.net/bugs/348382
[11:02] <lool> ogra: arm tag...
[11:03] <ogra> lool, what about the redboot binary ? do we want flash-kernel to depend on it and overwrite redboot on every flash-kernel run (i assume thats the safest to guarantee the SD is actually bootable)
[11:04] <suihkulokki> genarally on arm systems updating users's bootloader is to be avoided
[11:04] <ogra> well, but we cant be sure the binary is actually in place
[11:04] <ogra> all we see from flash-kernel is the fis table
[11:05] <ogra> which doesnt mean there is a redboot binary
[11:05] <ogra> i was wondering if we can just rely on the presence of redboot once we find a fis table
[11:06] <ogra> i'm not sure we can
[11:18] <lool> ogra: I think installing redboot is entirely different from flash-kernel's task
[11:18] <lool> ogra: And isn't needed
[11:18] <lool> flash-kernel is run on kernel installs and upgrades, and on initramfs creation and updates
[11:19] <lool> If we need to install redboot, we will need a redboot udeb and a tool to write it, perhaps flash-kernel, perhaps a new one
[11:19] <lool> Just like install-grub
[11:20] <lool> s/install-grub/grub-install
[11:33] <NCommander> We need an MIR for flash-kernel
[11:33] <NCommander> ^- lool ogra
[11:33] <ogra> NCommander, ??
[11:33] <ogra> its used on nslu2
[11:33] <NCommander> flash-kernel is in universe
[11:33] <NCommander> unless someone moved it without me looking
[11:34] <NCommander> Correction
[11:34] <NCommander> It was promoted two weeks ago
[11:34] <NCommander> (er, three)
[11:35] <ogra> we need redboot-tools in main though
[11:36] <NCommander> Ugh
[11:36] <ogra> wh yugh
[11:36] <ogra> its tiny enough
[11:37] <ogra> more important is that someone finally approves redboot-imx
[11:56] <ogra> lool, geezy, ubiquity seems to work on the babbage
[11:56] <ogra> it went properly through partitioning and is now in base install
[11:56] <lool> Cool
[11:57] <ogra> i'm sure it will fail with the last step, but if we can get the rootfs installed properly we can worst case add a howto for setting the SD to do a local boot
[12:29] <ogra> hmm, ubiquity is at 66% of base install already :)
[12:30] <ogra> though i just noticed i picked the wrong usb key as targe device :/
[12:30] <ogra> *target
[12:30] <ogra> 2G will not suffice
[15:16] <lool> dave_m_: http://people.ubuntu.com/~ogra/arm/babbage/ has a recent image with redboot, kernel, desktop live session and all
[15:17] <ogra> sadly my board commits suicide at 80-90% of the install every time
[15:18] <lool> ogra: are you sure it's not the bug which was affecting persia?
[15:18] <ogra> i'm just trying with shut down syslog
[15:18] <ogra> lets see where that gets me
[15:19] <persia> ogra, Don't shut down syslog.  Just comment out the kern.* line in /etc/syslog.conf, and kill -HUP syslogd.
[15:20] <ogra> persia, that makes /var/log/debug and /var/log/syslog still grow to 1200s of megabytes
[15:20] <ogra> *100s
[15:21] <ogra> so now i'm trying without any syslog and without USB NIC
[15:21] <ogra> its at 60%
[15:21] <persia> OK.  I just had syslog and kern.log.  /var/log/debug wasn't so bad.
[15:21] <persia> I'm at 64% with kern.log commented out right now.
[15:21] <ogra> the same messages go into all three
[15:22] <ogra> i really like the option to attach partitions to the end of the disk
[15:22] <ogra> that makes it easy to keep 20M free space on my target SD
[15:22] <ogra> where i then can install and configure redboot and fis manually i hope
[15:24] <ogra> i also switched to install from SDHC to SDHC now ... std. SD was just to slow
[15:49] <lool> dave_m_: You might run into https://bugs.launchpad.net/ubuntu/+source/linux/+bug/348504 if installing to USB; happy to hear about your install report
[15:49] <ubot4> Launchpad bug 348504 in linux "USB issues with linux-image-2.6.28-11-imx51 fill /var/log" [Undecided,New]
[15:50] <dave_m_> Not currently trying this, but I'll keep my eyes open...
[15:52] <dave_m_> ogra, lool: I now have updated RedBoot and the kernel, but it looks like the MMC driver is not built in... it looks like I need an initrd to boot fully.  Can someone advise me on how to set up RedBoot to pass the initrd data?
[15:54] <lool> dave_m_: I can boot fully of the SD card without an initramfs
[15:54] <lool> dave_m_: Try to add a rootdelay
[15:55] <dave_m_> lool: Not used that before... it is rootdelay=<secs>, or what?
[15:56] <lool> Yes
[15:58] <dave_m_> ok
[16:03] <dave_m_> lool: Seems to be working for me now. No rootdelay= option needed; perhaps I got the root= argument wrong before.
[16:10] <Martyn> Good morning
[16:10] <Martyn> lool, is there a way to get the live image to use a serial console instead of the framebuffer?
[16:10] <Martyn> or does the live image lack a serial getty?
[16:10] <lool> Martyn: It lacks the serial getty
[16:11] <Martyn> poodles
[16:12] <Martyn> *grumble*
[16:12] <Martyn> that means I'm going to have to poke around the office for a monitor, keyboard .. -sigh-
[16:15] <dave_m_> Martyn: you can probably add a serial login just by adding an extra file for ttymxc0 in /etc/event.d (using e.g., tty1 as a template)
[16:16] <lool> dave_m_: It's not trivial to do for the lice image
[16:16] <lool> *live
[16:16] <lool> Because it's a read-only rootfs with a ramdisk overlay
[16:16] <dave_m_> lool: Ah, yes, I see the problem...
[16:17] <ogra> Martyn, we have a way to modify redboot without the need of serial now btw
[16:17] <dave_m_> lool: Is the rootfs really non-modifiable, or is it just mounted ro by default?
[16:18] <Martyn> ogra : yay!  the commandline tool works!
[16:18] <lool> dave_m_: You can't write to squashfs
[16:18] <ogra> dave_m_, its modifiable while it run
[16:18] <dave_m_> lool: Right, I wasn't sure what type of fs was used.  Fair enough.
[16:18] <Martyn> yay for unionfs
[16:18] <ogra> aufs :)
[16:19] <Martyn> okay, aufs :)
[16:20] <Martyn> ogra : where can I snag the new tool?
[16:20] <ogra> its about to enter the archive, but lool made a pre packaged version ...
[16:22] <ogra> https://launchpad.net/~lool/+archive/ppa redboot-tools ...
[16:22] <Martyn> we still get ttyfail on the new image?
[16:22] <Martyn> thank you lool
[16:23] <ogra> Martyn, depends on your hwclock :)
[16:26] <Martyn> ogra : I set the hwclock a while ago though.   Shouldn't it be able to survive being unplugged for a day?
[16:26] <Martyn> there's a huge honking capacitor or battery on the board, after all
[16:28] <Martyn> aw, come ON
[16:28] <Martyn> if I go into text mode, none of the tty's will work if the hwclock has reset?
[16:28] <ogra> it doesnt survive more than 10min here
[16:28] <Martyn> i -have- to reset it in X?
[16:29] <Martyn> Oh, I'm -so- going to go solder in a damned lithium battery to the RTC now
[16:29] <ogra> heh
[16:29] <Martyn> because this is frigging annoying
[16:29] <Martyn> shrink wrap, two wires, some double sticky tape, and my handy capacitive welder
[16:29] <Martyn> this is like the /ninth/ board I've seen from pegatron where they pull this crap
[16:29] <ogra> if i set it once it survives reboots ... if i unplug it goes back to 1970 after a while
[16:30] <Martyn> yeah, it means they used a /really/ weak capacitor with a leak characteristic equivalent to a sieve
[16:31] <Martyn> and as usual, they don't even provide a couple pins to connect a battery to.  "Who would need it?"
[16:31] <Martyn> i'll make up a lithium cell battery backup, document the procedure, and make the link available later
[16:32] <Martyn> ogra : is there a way to address this in 9.04?  It's definitely a bug.
[16:32] <Martyn> Even if the date is insane, the getty should spawn >and< authentication should still work.
[16:33] <ogra> file it, its a bug in useradd that it enforces the password to be reset if your system is at 1970
[16:35] <Martyn> so the bug is in useradd and not in the PAM configuration?
[16:38] <Martyn> Filed
[16:38] <Martyn> or not?   500 error
[16:41] <Martyn> why does the useradd bug cause tty to fail?
[16:41] <Martyn> or the RTC clock being wrong?
[16:44] <ogra> useradd creates the autologin data during boot ... the second field in /etc/shadow is zero
[16:44] <Martyn> *snarl*
[16:44] <ogra> which enforces that you should update your pw immediately
[16:44] <ogra> the ttys on the livesystem all use autologin
[16:44] <Martyn> right, which snarfs login, and the tty's spin
[16:44] <ogra> which fails if the pw needs to be updated
[16:44] <ogra> right
[16:47] <Martyn> Okay, I think I have a fix for the wonky network driver
[16:48] <ogra> if you file a bug for it and attach a patch we can get it included by the kernel team
[16:48] <Martyn> should the bug be filed against mx51/kernel?
[16:48] <ogra> linux
[16:48] <ogra> mention imx51 in the description and add an arm tag
[16:49] <Martyn> will do.  I'm going to stress test the solution for a couple hours to see if I get lockups
[16:55] <Martyn> asix diver works nicely now :)
[16:56] <Martyn> but my patch makes the internal nic work too slowly
[16:59] <dave_m_> lool: Now I have the kernel working, I am seeing the ludicrously enourous amount of usb-storage debug you mentioned...  Is there a way to turn this off without rebuilding the kernel?
[17:04] <persia> dave_m_, I've been advised that it would be difficult, and have edited syslog.conf to reflect my desire for significantly less information to be saved to disk (commented out the kern.log and debug.log sections).
[17:04] <persia> Mind you, one needs to do this *each boot* with the live environment, which is a bit annoying.
[17:05] <dave_m_> persia: Is the debug enabled on all architectures?  This seems excessive for a production kernel...
[17:05] <Martyn> dave_m : Won't they be turning that off in the final build?
[17:05] <dave_m_> Could be... wasn't sure whether a further rebuild was proposed.
[17:05] <Martyn> I'm still looking for a way to disable the SCSI detection at boot.  Costs 50 seconds for nothing.
[17:05] <dave_m_> But it makes sense.
[17:06] <persia> dave_m_, No.  As far as I can tell, it's just for armel.
[17:06] <persia> I understand a new kernel is planned without the messages, but likely not until after the Beta release.
[17:06] <dave_m_> persia: No problem
[17:06] <Martyn> that makes sense
[17:07] <Martyn> Okay, I've corrected the error in the fec / SMSC LAN8700 code
[17:07] <dave_m_> Martyn: I'm not seeing the big SCSI detection delay, have you got something unusual plugged in?
[17:07] <Martyn> I'm going to leave my tests running for a couple hours.  If I see no errors, I'll submit the patch
[17:08] <Martyn> dave_m : Nothing's plugged in at all, but the board has a USB->SATA on the motherboard
[17:08] <Martyn> so it sits there and tries to detect a disk that isn't there.
[17:08] <Martyn> too bad the live image doesn't pay attention to "noscsi"
[17:09] <dave_m_> Hmmm, I've got a disk plugged in there, but I haven't usually seen it actually wait even when nothing was plugged in. This sounds like a bug somewhere.
[17:09] <ogra> Martyn, can you subscribe (not assign) me to the bugs you file ?
[17:10] <Martyn> fec.c is a bit of fail
[17:10] <Martyn> absolutely
[17:10] <Martyn> Just right now I got a 500 server error when trying to file a bug.
[17:10] <Martyn> I'll look at it again when I come back from a trip to the computer store (Fry's)
[17:11] <Martyn> <-- ran out of ethernet cable.
[17:13] <dave_m_> Martyn: Is your network bug causing really slow throughput?
[17:18] <persia> dave_m_, That sounds like bug #348333
[17:18] <ubot4> Launchpad bug 348333 in linux "armel/imx51: Poor ethernet behavior with 2.6.28" [Undecided,New] https://launchpad.net/bugs/348333
[17:19] <dave_m_> I may stick with FSL's 2.6.26 until this is resolved... network throughput appears 20-50x faster for me
[17:20] <dave_m_> ...so long as it's being dealt with in the meantime.
[17:21] <lool> dave_m_: If you don't have an USB ethernet adapter, I recommend you do indeed
[17:21] <persia> It's at least reported.  Some people report that using a USB network adaptor works around it: it seems related specifically to the onboard adaptor.
[17:22] <dave_m_> lool, persia: In general, the new kernel seems fine though.  I thought I ought to give it a try.
[17:23] <lool> dave_m_: It works ok for me in, but then I use that ethernet usb adapter and I don't use usb storage
[17:23] <lool> ogra: To clarify, the target install we discussed was not really SD card in an USB reader
[17:23] <lool> ogra: We came back to this after the call on boot options
[17:24] <ogra> lool, oh
[17:24] <lool> ogra: The target install scenario is to use the install SD card as install media *and* as the place to host kernel and initrd and all
[17:24] <lool> ogra: That is, use the redboot partition with fis data, config and all from the install SD card to boot the installed system
[17:24] <ogra> so only modify the cmdline with fconfig then
[17:24] <lool> So the SD media is destroyed
[17:24] <dave_m_> I've subscribed to https://launchpad.net/bugs/348333; I'll probably switch to this kernel when this issue has been sorted
[17:24] <ubot4> Launchpad bug 348333 in linux "armel/imx51: Poor ethernet behavior with 2.6.28" [Undecided,New]
[17:25] <lool> ogra: Yes, and install target kernel and initramfs
[17:25] <ogra> lool, fine with me, makes the howto a lot shorter
[17:25] <lool> ogra: *however* I think installing to a SD card in an USB reader is an useful option, so if you like to document how to achieve it, that's welcome
[17:25] <ogra> well, i'd only modify the cmdline then
[17:25] <ogra> the install kernel and initramfs wont differ
[17:25] <persia> Yes they will.
[17:26] <persia> If nothing else, the installed initramfs won't contain casper.
[17:26] <ogra> not in functionallity
[17:26] <ogra> just in size
[17:26] <persia> Well, size and content, but yes.
[17:26] <lool> so highest priority: make sure we have an installer an a howto which covers install to anything + boot from install SD
[17:26] <ogra> as son as you drop boot=casper it will behave the same
[17:26] <ogra> right
[17:26] <lool> And lower priority: have another guide for people who want to create an autonomous SD card
[17:26] <lool> An installed one that is
[17:26] <ogra> yep
[17:27] <ogra> i'll do the latter post beta ... the former tonight
[17:27] <lool> ogra: The install kernel will differ in that they will be generated from the installed system; typically after release you might get an updated kernel which has security updates
[17:27] <ogra> i just need to confirm the preseeding works, then i'll change the script and roll the final image
[17:27] <ogra> lool, we dont even have flash-kernel in beta
[17:28] <ogra> we can have all that for final
[17:28] <ogra> but beta will be different
[17:28] <lool> ogra: All my arguments are for final and are what I would aim at for beta; I prefer looking at our release target and making concessions than looking at we can do now, and have to redo everything for final
[17:29] <lool> For instance I don't mind instructions which tell you to use a PPA or to disable syslog or whatever for beta
[17:29] <ogra> for now my howto will be: install with ubiquity (working around the known bugs) ... install redboot-tools ... modify cmdline of SD
[17:29] <lool> If that gives an installation experience which works technically like the final one will, but with extra steps
[17:29] <lool> That's ok
[17:29] <ogra> right
[17:30] <ogra> for final some of that will be automated anyway by flash-kernel
[17:30] <lool> Yes
[17:30] <lool> ogra: One thing I didn't look into is who's responsible for setting the installed system to run flash-kernel
[17:31] <ogra> the linux-image package
[17:31] <ogra> oh, wait, you mean kernel-img.conf settings i guess
[17:31] <ogra> hmm
[17:32] <ogra> could we make flash-kernel postinst do that ?
[17:32] <ogra> i dont think kernel-img.conf is a conffile of any sort so a maintainer script could add it if its missing
[17:34] <persia> Isn't that what flash-kernel-installer does?
[17:34] <ogra> whats flash-kernel-installer ?
[17:34]  * ogra never heard of it
[17:35] <ogra> is that a udeb ? i cant find it in apt-cache
[17:35] <persia> Yes, it's a udeb.
[17:36] <ogra> ah
[17:36] <persia> It consist primarily of a postinst that checks the subarchitecture, and maybe does stuff to make flash-kernel work.
[17:36] <persia> s/consist/consists/
[17:36] <lool> persia: it is
[17:37] <ogra> yeah
[17:37] <ogra> its postinst writes kernel-img.conf
[17:37] <persia> lool, OK.  Then for alternates, we just need to have flash-kernel-installer in the initrd, which is done.  For the live images, we need to have the relevant logic be performed during the ubiquity run.
[17:38] <persia> I need to look at flash-kernel-installer a bit more, but I think that's just creating a component to drive it, and running that component out of install.py.
[18:36] <ka6sox-work> does anyone know how to get ahold of dave mandala? I met him @ the Canonical Booth @ SCALE and talked to him about making update-manager-core available for non-supported old releases available so that we could easily upgrade.
[18:43] <ogra> ka6sox-work, he is usually around here, might be in a meeting or so, just idle here for a while
[20:17] <Martyn> re
[20:17] <Martyn> The driver edit didn't work.  I got a full lockup of the fec
[20:18] <Martyn> Rx stops receiving packets.
[20:26] <Martyn> dreck, I'm getting "no route to host" when trying to hit ports.ubuntu.com
[23:22] <Guest94492> hey guys
[23:23] <Guest94492> where I can download ubuntu-ARM source code?
[23:24] <Guest94492> it's opensource?
[23:25] <Guest94492> Hello?
[23:28] <lool> _Carlo_: It's the ubuntu source code, it's at archive.ubuntu.com
[23:29] <_Carlo_> witch folder?
[23:30] <_Carlo_> dists -> indices -> poll -> project
[23:40] <lool> _Carlo_: Perhaps you should start with the ubuntu wiki
[23:40]  * lool => bed &
[23:45] <_Carlo_> or you tell me where I get


[01:39] <broder> pleia2: haha, yeah, i finally disabled the HUD because i was pair programming with someone and they kept mocking me
[01:45] <broder> gah. wait, i actually just noticed that alt tab doesn't work. if disabling the hud means none of my alt keys work, i.....well, i will be very unhappy


 Looking good apart from the few fails
 I will look at qtimageformats SIGILL on armhf later today. In the mean time I think you can do the rebuilds.
 qtremoteobjects is not a regression. qtquickcontrols is a regression, but I will retry it first.
 @mitya57 [qtremoteobjects is not a regression. qtquickcontrols is a regression, will also …], I retried qtquickcontrols about an hour ago.
 @mitya57 [I will look at qtimageformats SIGILL on armhf later today. In the mean time I th …], If you are sure, I'll get those done in a minute
 @RikMills [If you are sure, I'll get those done in a minute], Why not?
 @mitya57 [Why not?], I just meant that if you are sure the stack is complete and buildable against. It was more a turn of phrase than anything. I am sure it is all good.
 In the worst case some packages can dep-wait. As far as I know Launchpad they should not build against 5.12.8.
 Oops. my rebuild script was still set to focal. just as well I did not upload. Will take a short while to regenerate the sources
 rebuilds uploaded
 @mitya57 [I will look at qtimageformats SIGBUS on armhf later today. In the mean time I th …], Looks like a real bug: unaligned access in https://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/painting/qicc.cpp?h=v5.14.2#n447
 …which doesn't seem to be easily fixable because unaligned access is all over that file :(
 I filed https://bugreports.qt.io/browse/QTBUG-84267 for now because I want some advice from upstream before spending hours on it.
 qtcreator needs new qbs, which I will work on.
 qbs needs more work because there are many changes between 1.14 and 1.16. Will continue tomorrow.
 In the mean time I fixed deepin-qt5dxcb-plugin and tried to fix gammaray, but not fixed completely.
 thanks. I have not checked through yet, but anything in sync with debian do you want to fix there and copy, or not that bothered as it will get done eventually with debian transition?
 I will upload directly packages that are in Qt/KDE team, and file bugs for others. But later, I have little time as usual and want to finish the transition in Ubuntu first.


[13:12] <kaliya> Hi.Is there any way a LP comment may be removed?
[13:13] <wgrant> kaliya: What sort of comment?
[13:13] <kaliya> A comment under a bug
[13:13] <kaliya> Public bug
[13:13] <kaliya> Can the project owner remove it somehow?
[13:14] <cjwatson> We can hide bug comments if you tell us which ones.
[13:14] <cjwatson> (And preferably give a reason why ...)
[14:07] <cjwatson> kaliya: Don't know if you saw my reply just before my IRC host rebooted, but I hid your comment
[14:08] <kaliya> Thanks alot cjwatson
[14:08] <kaliya> I thanked already, but you got disconnected :)
[16:57] <dpm> cjwatson, I don't seem to be able to link a related branch to a bug. Is this a known issue?
[16:57] <cjwatson> dpm: What happens when you try?
[16:58] <dpm> cjwatson, oh, it did get linked
[16:58] <cjwatson> (about to give a talk, replies will be slow)
[16:58] <dpm> cjwatson, np, sorry for the noise, please ignore
[16:58] <dpm> it just took a while for the branch to show up
[16:58] <dpm> as "Related branches"
[17:01] <cjwatson> ok
[17:02] <cjwatson> maybe you were just on a DB slave for some reason
[17:16] <dobey> dpm: fwiw, i think the best way to do the linking is to use bzr commit --fixes= in the branch, rather than using the web interface on lp to link a branch; this way it's in the branch metadata
[17:17] <dpm> dobey, I had already done that
[17:18] <dpm> but it was easier for me to do the two clicks on the web interface to send the MP :)
[17:21] <dobey> :-/
[17:57] <dpm> cjwatson, when you've got a minute, could you help me figure out why this snap build failed? https://code.launchpad.net/~dpm/+snap/ubuntu-calculator-app
[18:56] <cjwatson> dpm: That's a known issue with xenial snap builds due to a snapcraft incompatibility; it'll be fixed in the next launchpad-buildd rollout, hopefully later this week
[18:58] <dpm> cjwatson, ok, thanks. Is there a bug I can subscribe to get notification of when it gets fixed?
[20:44] <ondrej> hey, is there a similar procedure for arm64 as for armhf to be enabled on the PPA?
[20:47] <cjwatson> ondrej: You can do it yourself now.
[20:47] <cjwatson> ondrej: "Change details" on the PPA
[20:48] <cjwatson> ondrej: (not announced yet because we're still nailing down a few details, but it's been true for a few weeks)
[23:33] <mwhudson> huh, i guess there is no page like https://launchpad.net/ubuntu/+source/golang/+publishinghistory for a ppa?


[08:44] <jamespage> cpaelzer: morning - I think the component mismatches for the openstack team that you detailed yesterday should be cleared - coreycb worked some optional dependencies to Suggests rather than Recommends/Depends
[09:23] <cpaelzer> thanks jamespage, I've seen the ping by coreycb himself
[09:23] <cpaelzer> they are indeed gone
[10:13] <jamespage> cpaelzer: great
[13:35] <enr0n> Can a core dev please retry the remaining autopkgtest failures blocking systemd on jammy? retry-autopkgtest-regressions --blocks systemd -s jammy
[13:35] <enr0n> These are flaky tests AFAICT
[13:55] <dbungert> enr0n: done
[13:55] <enr0n> dbungert: thanks!
[16:12] <enr0n> bdmurray: exim4 autopkgtest fails quite often on ppc64el (https://autopkgtest.ubuntu.com/packages/e/exim4/jammy/ppc64el), and is currently blocking systemd in jammy. I can keep having it retried, but I wonder if the test should be hinted due to the frequency of failures.
[16:17] <dbungert> Eickmeyer[m]: I updated LP: #1983862 with a few options on what to do about Audacity, and none of them are great.  You spoke up in support of this for Ubuntu Studio.  Thoughts?
[16:19] <Eickmeyer[m]> dbungert: ahasenack had been working on a fix to get a newer version in that supported ffmpeg5, but it required a newer version of wxwidgets which only recently got in. I don't know what else happened there.
[16:20] <dbungert> I believe new wxwidgets is in, but now there is a feature freeze problem, and it needs verification that the included telemetry is not invasive.  Given that upstream says telemetry can be turned off entirely, the telemetry may be a non-issue.
[16:20] <Eickmeyer[m]> Basically, we have to get Audacity 3.1 in to support ffmpeg 5.
[16:20] <Eickmeyer[m]> I agree. If telemetry can be turned off, I say JDI.
[16:21] <Eickmeyer[m]> And yes, even though FF is in effect, this is a bugfix that has been being worked-on prior to FF.
[16:21] <Eickmeyer[m]> So, afaiac, it shouldn't need a FF, but I'd check with someone on the release team just to confirm. Maybe sil2100 if you have a chance, can you confirm?
[16:22] <Eickmeyer[m]> s/FF/FFe ^
[16:22] <dbungert> Archive version of Audacity is 2.4.2, and there seem to be quite a few features done since then.  I think they would need scrutinzed.
[16:23] <Eickmeyer[m]> Fair, but without that, no Audacity, which would make a very angry userbase.
[16:24] <dbungert> Agree
[16:24] <dbungert> I've probably spent too much time on this issue as is - can someone from Studio make the case for a FFe?
[16:27] <Eickmeyer[m]> dbungert: I'll do it, since I'm really the only person who can.
[16:27] <philroche> waveform: RE livecd-rootfs is consistently failing with "No space left on device". Is this kinetic images? Can you share logs? We were seeing the same on GCE images and it appears to have been caused once the linux-gcp kernel rolled from 5.15 to 5.19 on September 2nd
[16:31] <waveform> philroche, yeah it's kinetic images -- I *think* the two logs I diffed were<EMAIL_ADDRESS>(pass) and<EMAIL_ADDRESS>(fail, same version but yes the kernel jumped from 5.15 to 5.19)
[16:32] <philroche> we're still confirming but it was likely the same for you and we need to bump the image size for all kinetic builds
[16:34] <ahasenack> Eickmeyer[m]: I only worked on that because it was my +1 maintenance week. Otherwise I don't touch non-server packages generally
[16:35] <Eickmeyer[m]> ahasenack: ok, then I guess I'm going to have to drive this. dbungert, I'm working on the FFe now.
[16:37] <dbungert> Eickmeyer[m]: Thanks.  Like I mention above, I think none of the options are great.
[16:53] <Eickmeyer[m]> dbungert: FFe done, same bug 1983862
[16:53] <Eickmeyer[m]> I think it makes the case that the only reason it's an FFe in the first place is the timing of the upload of wxwidgets being so late.
[17:37] <ahasenack> rbasak: hi, can you please reject nfs-utils from jammy unapproved? (https://launchpad.net/ubuntu/jammy/+queue?queue_state=1&queue_text=nfs-utils)
[17:37] <ahasenack> I have a new upload ready that does not address the hardening flags bug
[17:38] <ahasenack> I just wontfix'ed that jammy task of #1980095
[18:01] <bdmurray> enr0n: I retried it and it passed for me
[18:03] <enr0n> bdmurray: works for me, thanks!
[18:19] <rbasak> ahasenack: done, but note that you can upload over the top :)
[18:22] <ahasenack> I know, but I wanted to avoid the risk of having the wrong one deleted :)
[19:58] <icey[m]> hey utkarsh2102 , thanks for the renewal :)
[20:04] <utkarsh2102> icey: hey, sure thing! :D


[05:34] <nhandler> Why is ~launchpad-dev (an open team) setup so you need an admin to renew subscriptions?
[05:43] <wgrant> Most probably an oversight that can be trivially fixed by a whole lot of people who are currently flying or about to fly.
[05:43] <wgrant> Ah, I just got a warning too.
[06:00] <nigelb> wgrant: you're flying there too?
[06:02] <wgrant> nigelb: No.
[06:02] <nigelb> wgrant: Gah.
[19:14] <sarhan> Hi


[01:16] <spiv> Good morning.
[01:17] <lifeless> oh hai
[03:05] <AfC> Hm. Can you suggest a reason why installing the bzr-builddeb package wants to bring in the entire libqt stack?
[03:14] <lifeless> its in love!
[03:15] <mwhudson> is qbzr being dragged in somehow?
[03:16] <AfC> mwhudson: as far as I could tell, no
[03:16] <AfC> This was a nearly naked server system;
[03:16] <AfC> (ie, no Desktop)
[03:16] <AfC> I subsequently removed the *qt* and apt didn't try to remove bzr-builddeb
[03:17] <AfC> so I was really at a loss as to wtf
[03:17] <lifeless> recommends vs depends
[03:17] <AfC> I install with -o Install-Recommends=false
[03:17] <AfC> (and it still came in; I look closely for that sort of thing)
[03:18] <lifeless> what does apt-cache bzr-builddeb show for you
[03:18] <lifeless> under depends, recommends & suggests
[03:18] <AfC> (ie, there was something in the Recommends: column that was nothing to do with libqt*
[03:18] <AfC> lifeless: I looked through that too. Its innocent, as far as I can tell
[03:19] <AfC> [which is why I raise this casually here; it was _weird_]
[03:19] <lifeless> so, to diagnose it
[03:19] <lifeless> apt-cache rdepends
[03:19] <lifeless> the package that was being brought in
[03:19] <AfC> yeah, I didn't think to try that at the time
[03:19] <lifeless> and/or remove bzr-builddeb and install it again
[03:25] <AfC> lifeless: I tried that too
[03:25] <lifeless> oh
[03:25] <lifeless> and /var/log/apt/ has some debug stuff
[03:25] <AfC> (I'll keep an eye out for this; at the moment that machine is churning away building things, so...)
[03:25] <AfC> true,
[03:25] <AfC> looking
[03:27] <AfC> ah ha
[03:27] <AfC> it was arora, depending on libqt4-webkit
[03:27]  * AfC wonders what arora is
[03:27] <AfC> some kind of web browser, obviously... but what pulled it? Weird.
[03:28] <fullermd> Well, embedding mail reading in everything was SO 1980's.  So now all apps grow until they can render HTML.
[03:28] <AfC> lifeless: nice call on /var/log/apt/history.log
[03:29] <lifeless> if don't have a browser
[03:29] <lifeless> then the first explicit one listed (if one is) is pulled in
[03:29] <lifeless> someone has a clause like
[03:29] <AfC> some kind of virtual package requirement, presumbably
[03:29] <lifeless> arora | web-browser
[03:30] <AfC> yeah
[03:30] <AfC> eek
[03:53] <poolie> hi all, i'm back
[03:55] <lifeless> wb
[03:59] <mwhudson> poolie: wb
[04:00] <poolie> thanks
[05:09] <andrewblack> Hi. Is there any gotchas in makine /etc a bzr working tree.
[05:09] <mwhudson> andrewblack: bzr doesn't track permissions very closely
[05:09] <spm> andrewblack: permissions on funky files within the /etc tree within the .bzr directory.
[05:09] <mwhudson> so i think you might want to use a wrapper like etckeeper
[05:10] <spm> or lock down /etc/.bzr
[05:10] <mwhudson> http://joey.kitenet.net/code/etckeeper/
[05:10] <andrewblack> ok - will look at etckeeper
[05:10] <spm> mwhudson: nice tag teaming there. high-five :-)
[05:11] <mwhudson> spm: aren't we supposed to do that in a privmsg?
[05:11] <mwhudson> :)
[05:11] <spm> um....
[05:13] <andrewblack> It says it tracks changes during package updates. What about manual changes to /etc/xxxx files
[05:19] <spm> you can manually check those in
[05:19] <spm> it'll also auto check those in next package update
[05:19] <spm> if you want; you can always setup some sort of cron script that alerts/or auto-commits changes
[05:20] <spm> at $job-1, we had a process rule; any /etc or other config changes were always done thru a wrapper script that would check the edited file in/out/diff of an RCS store.
[05:24] <spm> ho hum. said article has gone the way of the dodo. was on the samag.com website; now defunct.
[05:25] <andrewblack> Thanks spm
[05:26] <andrewblack> so basically it sets up the repos in a way that is permission friendly
[05:32] <andrewblack> ok - I wanted to edit a cron job (and get it under bzr first)
[05:32] <andrewblack> turns out the that thing I needed to change was in a file it calls that was already in a bzr tree.
[05:36] <spm> hrm. not so much permission friendly; more permission *unfriendly*. /etc/.bzr ==> 0700 type of thing.
[05:57] <thumper> http://bazaar.canonical.com/en/ seems to be a little old on the released bzr status
[06:06] <poolie> thanks thumper, i'll check why later
[06:06] <thumper> poolie: we should have a chat some time
[06:06] <thumper> soonish
[06:06] <poolie> we should
[06:06] <poolie> now is good with me, if you like
[06:06] <poolie> (or in about 2m)
[06:10] <thumper> poolie: I'm sprinting this week, but would still like to organise something...
[06:10] <thumper> induction for wallyworld_
[06:17] <poolie> yay wallyworld_ !
[06:17] <poolie> thumper: how about now
[06:18] <wallyworld_> hi poolie
[06:18]  * thumper fetches headset
[07:45] <vila> hi all !
[07:45] <vila> wv poolie !
[07:45] <vila> meh
[07:45] <vila> wb
[07:45] <poolie> hello vila, how are you?
[07:45] <vila> first typo in second msg, looks like a good way to start the week :)
[07:46] <vila> poolie: great, about to half the active review queue by landing those long awaited fixes :)
[07:49] <poolie> only 660 messages to go ..
[07:50] <GaryvdM> Hi all.
[07:51] <vila> hey GaryvdM !
[07:52] <poolie> spiv, vila, did either of you do anything about unlocking on interrupts, or coping when we were interrupted?
[07:52] <vila> poolie: nope, I thought you were working on it and then... went to other things
[07:53] <bialix> poolie: ping
[07:55]  * bialix waves at ddaa
[07:55] <GaryvdM> Hi bialix
[07:56] <bialix> Heya Gary! I happy to see you
[07:59] <GaryvdM> I'm trying to write some tests for qlog. I need to create branches with interesting graphs. I looked at BranchBuilder to see if it would make things easier, it helps some what, but one thing that is crufty is having to branch my branch on disk so that I can create a diverging graph. Is there a helper to make this easier?
[08:01] <poolie> np, i might look at it this week
[08:02] <bialix> GaryvdM: invoke `bzr branch` command via self.run_bzr?
[08:05] <spiv> poolie: no, I didn't either.
[08:14] <poolie> what did you two get up to?
[08:17] <vila> poolie: resuming working on transform targeting allowing deleting dirs containing .pyc files
[08:17] <vila> s/resuming/resumed/
[08:18] <poolie> nice
[08:24] <bialix> GaryvdM: can you look at https://code.launchpad.net/~s-dumbie/qbzr/ench_qdiff/+merge/33986
[08:25] <bialix> one russian guy contacted me with patch couple of months ago. then yesterday friend of him decided to finish that patch
[08:25] <bialix> GaryvdM: as I understand some of their changes should be reworked with new toolbar in qdiff. but we don't have one yet.
[08:26] <GaryvdM> bialix: Ok
[08:26] <bialix> we (I) may ask him to split the patch into smaller pieces
[08:26] <bialix> if it helps
[08:27]  * vila banhs head on desktop, from pqm: "Exception processing merge: Unknown branch format: 'Bazaar-NG Loom branch format 7\\n'"
[08:27] <GaryvdM> bialix: Hopefully the search stuff can be made common with annotate too.
[08:27] <vila> yeah, banhs, brohe a teeth doing that
[08:28] <bialix> vila: we're with you!
[08:28]  * fullermd broke a tooth on the bottom of a pool once.
[08:29] <vila> tooth yeah, the only remaining one in fact
[08:29] <vila> fullermd: forgot to check for water ?
[08:30] <fullermd> Oh, no.  There was water.  It was pretty bizarre; I probably couldn't do it again if I tried.
[08:30] <fullermd> Not that I plan on trying, though.  Unpleasant experience.
[08:30] <vila> fullermd: and *that* was the last time you left your basement right ?
[08:31] <fullermd> Well, it shoulda been   :p
[08:31] <vila> :-D
[08:31] <fullermd> But I was young and foolish, and therefor sociable, back then.
[08:31] <vila> fullermd: such a loss of time...
[08:32] <fullermd> I know!  All those afternoons I could have spent plotting the downfall of humanit...   er, studying and improving myself.
[08:45] <poolie> spiv, what's new with you?
[08:50] <vila> errr, what did I miss ? pqm got a faster machine ? I wasn't able to see my requests on http://pqm.bazaar-vcs.org/, yet they have landed...
[08:51] <bialix> today speed of light is much faster I suppose
[08:51] <poolie> hi bialix
[08:51] <poolie> vila, oops
[08:51] <poolie> i suggest you send one you know will fail
[08:52] <bialix> hi poolie
[08:52] <poolie> and make sure that it does
[08:52] <poolie> spiv does my guess on bug 626649 sound plausible?
[08:54] <vila> poolie: you're kidding ? Time to send all those controversial patches instead :)
[08:55] <vila> poolie: yes, very plausible, I waited far too long to report it wanting to write a test for it :-}
[08:57] <vila> poolie: I work around it with: 'bzr unbind ; bzr pull -v ; bzr push ; bzr bind'
[09:00] <poolie> yup, it's a dupe of bug 483661
[09:00] <spiv> poolie: yep, that sounds plausible.  Not 100% sure, but definitely plausible.
[09:03] <spiv> poolie: I did some measurement of where we're at with gcc-linaro, and found a 15% win for one of the cases.
[09:03] <poolie> oh, nice, what was that
[09:04] <spiv> Although for some reason I'm having trouble with getting useful results with --lsprof-file and kcachegrind, I'm not sure why yet.  It might be something about trunk, or something about maverick...
[09:04] <spiv> It turns out that InterTree.iter_changes was doing "if file_id in self.target.all_file_ids()" in a loop.
[09:05] <poolie> so recalculating all the ids every time?
[09:05] <spiv> Right, which means set(tree.inventory)
[09:07] <poolie> maybe that should be deprecated
[09:07] <poolie> hm
[09:07] <spiv> Anyway, Tree already has a __contains__ method that does that check without iterating over an entire inventory, so "if file_id in self.target" is the trivial and faster replacement.
[09:07] <poolie> ok
[09:07] <poolie> no, i guess profiling is probably a better way to find expensive things called repeatedly
[09:07] <poolie> i'd like to delete __contains__ etc
[09:08] <poolie> vila does this mean all those recently merged things of yours perhaps should not have merged?
[09:08] <poolie> or did you integrate them and then send the whole thing?
[09:08] <vila> poolie: investigating
[09:09] <vila> poolie: I went with pqm-submit instead of feed-pqm because looms were involved (and not supported by pqm) but that still use the "regular" pqm way
[09:10] <vila> hmm, looks like I used syntax accepted by python-2.6 but not 2.5, so probably not 2.4 either
[09:11] <vila> that in turn would mean that pqm accepted the merge when selftest failed with a syntax error... bad bad
[09:13] <spiv> vila: !
[09:14] <vila> rhaaaa, on no more py25 on lucid... shudder
[09:22] <vila> spiv: Isn't it a nice way to land a patch ?
[09:25] <vila> poolie, spiv: here is the fix: http://paste.ubuntu.com/485753/
[09:27] <vila> poolie, spiv: I will send this to pqm *now* and check for fallouts (unless you yell loud)
[09:28]  * poolie looks
[09:28] <poolie> vila, is this because py25 won't let you use *args and also regular kwargs?
[09:29] <vila> poolie: seems so, 2.4 and 2.5 fail without and succeed with this patch
[09:29] <poolie> but doesn't pqm use 2.4?
[09:30] <vila> I don't remember if it stills uses 2.4 or 2.5, but I've filled bug #626667
[09:31] <vila> losa: can you help diagnose bug #626667 by checking the recent logs on the bzr pqm instance ?
[09:31] <vila> poolie: ok to land the above fix ?
[09:31] <poolie> vila, i guess so
[09:31] <poolie> i really want to work out why it wasn't rejected though
[09:32] <vila> sent
[09:32] <poolie> as i'm sure you do too :)
[09:32] <vila> poolie: yup, hence the bug
[09:32] <vila> losa: first data point: which python version is used there ? 2.4 or 2.5 ?
[09:33] <lvh> hey
[09:33] <vila> http://paste.ubuntu.com/485756/ hmpf
[09:33] <lvh> I accidentally uploaded some stuff to lp without fixing bzr whoami first
[09:34] <lvh> is there a way to fix my commits?
[09:34] <spiv> vila: not loud yells from me
[09:34] <spiv> s/not/no/
[09:35] <vila> bug 626667 updated... just lovely
[09:36] <bialix> lvh: uncommit, or push --overwrite
[09:37] <lvh> bialix: so if I fix whoami, and then push --overwrite, it'll be fixed? Cool, thanks
[09:38] <bialix> lvh: no
[09:38] <lvh> bialix: huh? what do I do then
[09:38] <bialix> lvh: you have to redo your commits locally and then push --overwrite
[09:38] <bialix> how many of them do you have?
[09:38] <lvh> so 10:36 <bialix> lvh: uncommit, or push --overwrite => uncommit *and* push locally
[09:38] <lvh> twenty or so
[09:39] <lvh> I didn't have a working internet connection to push to lp
[09:39] <lvh> so it took me about a day to notice
[09:39] <bialix> what's wrong with your old whoami?
[09:40] <lvh> lp doesn't link it to my user profile correctly
[09:40] <lvh> it doesn't have my email address
[09:40] <vila> lvh: and you don't get karma ?
[09:40] <bialix> it's not too bad
[09:40] <lvh> vila: maybe, I don't know
[09:40] <lvh> yes, it's not a major issue
[09:41] <lvh> I was just hoping there's a way of letting lp know "oh hey that guy, that's me"
[09:41] <vila> lvh: that's the only consequence I can think of
[09:41] <poolie> lvh it has no address at all?
[09:41] <lvh> poolie: worse, it has a useless one
[09:41] <bialix> 20 commits... you can redo them one by one, or maybe use bzr-rewrite plugin
[09:41] <lvh> It says Laurens Van Houtven <lvh@bruichladdich>
[09:42] <vila> lvh: try adding this email to your lp profile
[09:42] <bialix> you can add it to your profile as alternate mail
[09:42] <lvh> vila: aha, okay
[09:42] <hno> bialix: Is that possible without mail confirmation?
[09:42] <vila> lvh: not sure lp willl accept an invalid email but worth a try
[09:43] <lvh> A confirmation message has been sent to 'lvh@bruichladdich'. Follow the instructions in that message to confirm that the address is yours. (If the message doesn't arrive in a few minutes, your mail provider might use 'greylisting', which could delay the message for up to an hour or two.)
[09:43] <lvh> That'll backfire :)
[09:43] <bialix> lp is too smart
[09:43] <vila> lvh: all you have to do now is register this TLD :-D
[09:44] <hno> lvh: You could as in #launchpad if there is a way around that, or fix up the commits and push again..
[09:44] <bialix> maybe you can file a bug report against lp itself and ask for such deature
[09:44] <lvh> Okay, thanks :)
[09:44] <bialix> s/feature
[09:47] <lvh> https://launchpad.net/bzr-rewrite is that the rewrite plugin I want?
[09:47] <spiv> lvh: yes
[09:49] <poolie> vila is it just me or is --parallel still a bit flaky?
[09:49] <poolie> i get "failed to connect to ssh server"
[09:49] <poolie> oh, heh, and the strace tests are broken by maverick's policy change there
[09:50] <vila> poolie: ENOTENOUGHCONTEXT
[09:50] <vila> poolie: is that with the leaking tests fix landed ?
[09:50] <poolie> ERROR: bzrlib.tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh: Unable to connect to SSH host localhost:51613; [Errno 111] Connection refused
[09:50] <poolie> that's just in trunk as of a few minutes ago
[09:51] <lvh> Okay, so lets say I want to fix all my commits and then push --overwrite, how does rewrite make my life easier
[09:51] <spiv> poolie: on maverick?  That's a paramiko bug relating to IPv6
[09:51] <vila> poolie: sounds like either a transient one or something related to a spiv fix for paramiko
[09:51] <poolie> oh ok, thanks
[09:51] <poolie> how about bug 626679
[09:52] <spiv> I should nag upstream and/or the Ubuntu packager to include my patch, I guess.
[09:53] <bialix> poolie: I'd like to draw your attention to bazaar.canonical.com/en/index.html page
[09:54]  * poolie looks
[09:54] <poolie>  i need to go soon
[09:54] <poolie> hi bialix
[09:54] <bialix> that page has section "Developer's Blog"
[09:54] <poolie> what about it ?
[09:54] <bialix> hi poolie
[09:54] <poolie> but it links to "None", i see
[09:54] <bialix> the section is empty for me.
[09:55] <bialix> but when I'm regenerating the index on my machine it's not empty
[09:55] <bialix> does this index regenerated on the production server?
[09:55] <bialix> it seems production server has no access to wordpress feed, or something like that
[09:56] <bialix> I have no idea how that page deployed, but there is definitely some problem
[09:57] <poolie> i'll check it out on the production server
[09:57] <vila> ping LOSA
[09:57] <bialix> and btw local index has link to http://bazaarvcs.wordpress.com/ and not to None
[09:57] <bialix> something weird
[09:58] <mthaddon> vila: hi
[09:58] <vila> mthaddon: hey !
[09:59] <vila> mthaddon: really bad bug on pqm bzr instance: bug #626667
 losa: can you help diagnose bug #626667 by checking the recent logs on the bzr pqm instance ?
 losa: first data point: which python version is used there ? 2.4 or 2.5 ?
[10:00] <lvh> Okay, I installed bzr-rewrite. I don't think rebase is what I want if it's anything like git's
[10:00] <vila> mthaddon: a fix for *bzr* is currently landing, but pqm needs to be fixed, we prefer to rely on pqm to *detect* such problems :)
[10:00] <mthaddon> vila: it's a hardy chroot, so python 2.5 is the default
[10:01] <vila> mthaddon: ok, that's one thing
[10:01] <mthaddon> vila: in what way does PQM need to be fixed?
[10:02] <vila> see the bug report, despite an *error* it happily merged the submission
[10:05] <nomatter001> hi
[10:05] <poolie> bialix: it's a problem with the proxy setting being not seen
[10:05] <nomatter001> when doing bzr export i get the following error: bzr: ERROR: zlib.error: Error -3 while decompressing data: incorrect data check
[10:05] <poolie> fixed now, thanks for letting me know!
[10:05] <bialix> poolie: :-)
[10:05] <nomatter001> after googling i found that this means an data error
[10:06] <nomatter001> is there some way to fix this
[10:06] <nomatter001> bzr status / bzr commit and so on still work
[10:07] <bialix> nomatter001: try to branch it to new location
[10:08] <spiv> nomatter001: try 'md5sum .bzr/repository/packs/*' and check that the md5sums match the filenames
[10:10] <mthaddon> vila: pqm just works by submitting if the command you give it returns a "0" exit code - if for some reason the conditions you're describing still return a 0 exit code, then PQM is still doing the right thing
[10:11] <vila> mthaddon: right, so what is this command for the bzr instance ?
[10:11] <nomatter001> spiv: not for all files
[10:11] <lvh> Hi. I don't understand how to use the rewrite plugin to change the author of a bunch of commits.
[10:12] <mthaddon> vila: for which branch?
[10:12] <lvh> bzr rebase appears to be for rebasing branches like git's rebase, which isn't quite what I want (I think).
[10:12] <vila> mthaddon: bzr.dev
[10:12] <vila> mthaddon: but I hope it's the same for all  bzr branches :-}
[10:12] <nomatter001> spiv: for 1 file it is different
[10:12] <nomatter001> spiv: what can i do?
[10:12] <mthaddon> vila: "make check PYTHON=python2.4" :(
[10:13] <vila> mthaddon: LOL, good so it's 2.4 finally, I'll look into 'make check' now
[10:13] <nomatter001> spiv: rename the file?
[10:15] <poolie> i'm off, see you later
[10:15] <vila> mthaddon: wow, reproduced, indeed, there are two commands for the make target and the second one is eating the first error :(
[10:16] <mthaddon> good to have reproduced...
[10:16] <vila> mthaddon: thanks a lot
[10:16] <vila> mthaddon: I've enough info to propose a fix
[10:16] <mthaddon> ok, cool
[10:17] <spiv> nomatter001: if they don't match, the data in the repository doesn't match what bzr thought it was writing to disk, which probably indicates filesystem corruption has occurred :(
[10:17]  * vila re-re-re-re-reading the make doc to find the right prefix
[10:17] <nomatter001> spiv: so what can i do?
[10:18] <nomatter001> spiv: can i get a diff between real data and what bzr thinks it should be?
[10:18] <spiv> nomatter001: ideally, rebuild the repository from backups or other (good) copies that don't exhibit that error
[10:18] <fullermd> First, you reverse MD5...
[10:19] <nomatter001> spiv: i have an online repository which i branched right now where no error happend when i exported
[10:19] <nomatter001> but i made a push into it (i think after error happend)
[10:20] <nomatter001> can this still be valid?
[10:20] <vila> nomatter001: is the file that doesn't match an empty one ?
[10:20] <nomatter001> villa: no
[10:20] <spiv> nomatter001: ok, so I'd make a new repository from that one, and then if you have new data in the damaged one branch/pull the new branches/revisions into it and hope they aren't affected.
[10:21] <nomatter001> spiv: ok thx
[10:21] <spiv> 'bzr check' when you're done should tell you if it the result is ok
[10:22] <spiv> (Although just checking the md5sums would be a good and quick sanity check too)
[10:22] <spiv> nomatter001: out of interest, which filesystem and OS, and has your system crashed at all?
[10:23] <vila> ha, yeah, 'cmd1 | cmd2' in a Makefile... nice way to ignore errors in cmd1...
[10:24] <nomatter001> spiv: archlinux, ext3 and no
[10:24] <nomatter001> no crash at all
[10:25] <vila> nomatter001: then it could be your HD slowly dying :-/
[10:25] <nomatter001> vila: hd is 2 months old
[10:25] <vila> nomatter001: the pack files are named with their md5sum and are *never* modified after that
[10:26] <spiv> nomatter001: wow, that's really surprising then!
[10:26] <nomatter001> vila: would be quickly dying
[10:26] <nomatter001> :-/
[10:26] <vila> nomatter001: what the english expression for that: infant mortality ?
[10:26] <spiv> vila: exactly
[10:26] <vila> nomatter001: some electronic devices die young or never, something like that
[10:27] <spiv> I've also heard "bathtub curve of reliability"
[10:27] <nomatter001> vila: yes i think its called mtbf
[10:27] <vila> nomatter001: *I* would closely monitor this HD
[10:27] <nomatter001> mean time between failure
[10:27] <fullermd> These are hard drives.  It's not a bathtub, so much as an endless abyss.
[10:28] <spiv> It's a question of the shape of the curve, not just where the mean is :)
[10:28] <vila> nomatter001: all reports I've seen about such corruptions were massively empty files after crashes, the few others were hardware problems
[10:28] <nomatter001> vila: ok great ...
[10:29] <vila> nomatter001: I wish you the best but... if you really had no crashes nor rude reboots...
[10:29] <nomatter001> nomatter@nomatter-laptop ~ % uptime
[10:29] <nomatter001>  11:30:52 up 11 days, 14:47,  1 user,  load average: 0.00, 0.02, 0.05
[10:29] <vila> scary, and you're sure the pack file has been created since then ?
[10:30] <nomatter001> vila: hmm thats another question
[10:30] <nomatter001> i have no idea when this files are created?
[10:30] <vila> nomatter001: oh, the modification time should be good for that :)
[10:30] <vila> nomatter001: they are *never* modified ;)
[10:30] <spiv> 'stat that_file' should show you the mtime (and the ctime)
[10:31] <nomatter001> vila: -rw-r--r-- 1 nomatter nomatter 55804179 Aug 10 07:40 925afb86da175268da810b3337d50eea.pack
[10:31] <fullermd> Except by the hard drive  ;)
[10:31] <nomatter001> ok no before
[10:31] <vila> nomatter001: right, so that's before your uptime
[10:31] <vila> fullermd: ;)
[10:31] <nomatter001> vila: i have no idea what happend in that timeframe
[10:32] <nomatter001> but what i know is that i could make exports since then
[10:32] <vila> nomatter001: so hope for a crash, cross your fingers, kill a chicken, and monitor this HD for any suspicious activities ;)
[10:33] <vila> nomatter001: follow spiv directions, if 'bzr check' is ok, then you're fine
[10:36] <nomatter001> ok seems that the online repo is finde
[10:36] <nomatter001> *fine
[10:36] <nomatter001> i'm lucky
[10:36] <nomatter001> so i have only to hope that another of my local branches is ok then i'm rescued
[10:37] <nomatter001> thx for the help so far
[10:38] <vila> nomatter001: if you use a shared repo, you only need to fix the repo
[10:38] <spiv> nomatter001: you're welcome, and good luck with the mysterious corruption :/
[10:38] <nomatter001> vila: how can i fix the repo?
[10:40] <vila> nomatter001: ECONTEXT, I thought you just did that ?
[10:41] <nomatter001> vila: i created a new repository
[10:41] <nomatter001> and branched the trunk branch from the online repo
[10:42] <vila> nomatter001: a shared repo ?
[10:43] <nomatter001> vila: no normal repo
[10:43] <nomatter001> or no shared-repo
[10:43] <nomatter001> damn
[10:43] <vila> nomatter001: let step back
[10:44] <vila> how many branches did you have on your laptop, are they sharing a repo or are they standalone branches ?
[10:44] <nomatter001> i have no idea i just followed the tutorial
[10:44] <nomatter001> i made a repo with bzr init-repo
[10:44] <nomatter001> wo i think a shared one
[10:44] <vila> yup
[10:44] <nomatter001> and in that i had several branches
[10:44] <vila> err, init-repo creates a repo, if your create branches below that, they'll use this shared repo
[10:45] <nomatter001> ok
[10:45] <vila> run 'bzr info' in such a branch and you can confirm that
[10:45] <nomatter001> yes
[10:45] <nomatter001> and this shared repo doesn't work
[10:45] <vila> ok
[10:45] <nomatter001> cause one pack doesn't match the md5
[10:45] <nomatter001> i also have a online-repo
[10:46] <vila> so a shared repo contains all revisions ever created by any branch there
[10:46] <nomatter001> and now i just created a new shared repo
[10:46] <nomatter001> and branched the one branch in the online-repo into the new shared repo
[10:46] <nomatter001> and that seems to work
[10:46] <vila> good
[10:47] <vila> how many branches do you still need to get back ?
[10:47] <nomatter001> vila: only one is important
[10:47] <vila> nomatter001: is it in the online repo ?
[10:47] <nomatter001> vila: the other ones have no changes i still need (all important ones are in trunk and online)
[10:47] <nomatter001> no that one is not online
[10:48] <nomatter001> but if it doesn't work i have the code (outside of the repo online)
[10:48] <vila> ok, but all the changes are still in the working tree, right ?
[10:48] <nomatter001> vila: yes
[10:48] <vila> nomatter001: try running 'bzr revno' in this branch
[10:49] <nomatter001> ok
[10:49] <nomatter001> its 50
[10:49] <vila> nomatter001: try branching this branch under  the new repo, this will transfer all needed revisions from the broken repo to the new one OR fail
[10:50] <nomatter001> vila: ok i'll try right after fixing the testserver (last scriptrun destoyed code there after incorrect export)
[10:51] <vila> nomatter001: meh, this is unrelated right ?
[10:51] <vila> nomatter001: then ping me when you're back
[10:52] <nomatter001> vila: 1 minute
[10:53] <nomatter001> vila: so now i'll try branching
[10:54] <nomatter001> ok seems to work
[10:55] <nomatter001> thx a lot
[10:56] <vila> nomatter001: good
[10:57] <nomatter001> perfect timing: its mealtime ^^
[11:34] <chx> hi. how can i preview what bzr up would do?
[11:38] <vila> chx: bzr missing ?
[11:39] <chx> ooooooo
[11:39] <chx> nice.
[11:39] <chx> thanks
[11:39] <vila> chx, well, not exactly, but it should help
[11:40] <chx> vila: yes, it helped
[11:43] <vila> mthaddon: can you check the last submission on bzr pqm instance, it has not been merged but I got no email either
[11:44] <vila> mthaddon: I've seen it run there but not until the end
[11:46] <mthaddon> vila: all I see is this, but that doesn't seem like it would cause a failure - https://pastebin.canonical.com/36445/
[11:48]  * vila shudders
[11:48] <vila> mthaddon: indeed, I can't see why it would change anything for this submission
[11:49] <vila> mthaddon: but there should exist some more precise log of what happened for it no ?
[11:49] <vila> mthaddon: or is it yet another email-too-big problem ?
[11:50] <mthaddon> vila: https://pastebin.canonical.com/36446/
[11:51] <mthaddon> not sure why you wouldn't have received that...
[11:51] <vila> mthaddon: great, that's a better explanation
[11:52] <vila> mthaddon: this is a random failure I've seen for a long time, first time it happens on pqm though... I'll try to re-submit :-/
[11:52] <mthaddon> k
[11:53] <vila> mthaddon: double shudder, yeah, AFAIK, I'm the only one not receiving such failures, I *receive* some failures, but not all... go debug that...
[11:53] <mthaddon> spam filter?
[11:54] <vila> mthaddon: me ? no. My ISP ? May be, but on which criteria ? Size ? spam filtered on size ? Hard to believe
[11:55] <vila> delayed because of size maybe...
[13:21] <sergio__> salve
[13:22] <sergio__> !list
[13:59] <vila> mthaddon: sorry to bother you again, but re-submitting led to the same result: no merge, no mail :(
[13:59] <vila> mthaddon: if you could confirm that the failure is the same for the same test, it would help
[14:02] <mthaddon> vila: sure, gimme a sec
[14:03] <vila> mthaddon: a whole minute even :)
[14:03]  * vila tries to setup an hardy vm to reproduce
[14:03] <mthaddon> vila: yep, same error
[14:03] <vila> same test then ?
[14:04] <vila> hmm, I wonder what the return address is on pqm emails... may be some mailbox contain same feedback on mails not passing through...
[14:05] <vila> ha<EMAIL_ADDRESS>mthaddon, is that a mailbox you can reach ?
[14:06] <mthaddon> nope
[14:06] <vila> mthaddon: pff, silly me, that's the one that receive the submissions... I wonder what happened when it receives a "can't deliver" mail...
[14:22] <vila> mthaddon: ok, I can reproduce the msg you got here, but that's not a failure and selftest succeds, there should be something else
[14:22] <amogorkon> i need help with diverged branches
[14:23] <amogorkon> i've got rev 43 on my local branch commited and another has rev 43 on their branch, both are connected with trunk
[14:24] <amogorkon> when i want to pull or push to trunk, the branches have diverged
[14:24] <vila> amogorkon: both ?
[14:24] <amogorkon> bzr missing tells i'm missing one rev
[14:24] <amogorkon> dunno, at least on my side
[14:24] <amogorkon> when i try to merge, it says nothing to do
[14:24] <amogorkon> when i try to commit, there's nothing to do
[14:25] <vila> amogorkon: do you have uncommitted changes ? ok, that answers my question
[14:25] <amogorkon> no conflicts
[14:25] <vila> amogorkon: try 'bzr update'
[14:25] <amogorkon> Tree is up to date at revision 43 of branch /home/amogorkon/Dropbox/PiLife bzr
[14:25] <amogorkon> is that good?
[14:25] <vila> meh
[14:26] <vila> bzr missing
[14:26] <vila> bzr info -v
[14:26] <vila> check the later, it seems you should find that something is not as you think it is
[14:27] <vila> amogorkon: and paste the ouput of 'bzr info -v', it will help to understand your setup
[14:28] <amogorkon> http://pastebin.com/5RXJz5Df
[14:30] <amogorkon> what does submit branch mean?
[14:36] <vila> amogorkon: that's where you want your changes to land and is also the default merge source. Generally, that's trunk
[14:36] <amogorkon> that.. is the cause of the issue then, i suppose
[14:36] <amogorkon> how can i change that?
[14:37] <vila> could be.
[14:37] <vila> edit .bzr/branch/branch.conf and either remove the submit_branch line or put your trunk url there
[14:39] <hno> bzr send --remember also changes the submit branch location.
[14:39] <amogorkon> many thanks
[14:39] <amogorkon> i'll try that
[14:40] <vila> now if 'bzr missing' says you're *missing* one rev, 'bzr pull -v' should pull it
[14:41] <vila> amogorkon: are your sure 'bzr missing --mine-only' is empty ?
[14:42] <amogorkon> vila, now it displays me "1 extra revision" - the one i commited previously
[14:43] <vila> amogorkon: then you should push it
[14:44] <mgz> vila: would you be interested in a bug report with the tests that hit hangs with your leak fixes?
[14:44] <mgz> so we don't lose track of them even if we can't fix them now.
[14:44] <vila> mgz: indeed
[14:44] <amogorkon> yeah, i think it works now
[14:44] <vila> mgz: if only to see we get the same ones...
[14:45] <amogorkon> another 40 min of my life spent fixing diverged branches :p
[14:45] <amogorkon> thanks anyway :)
[14:45] <mgz> I'll set up a full before and after run now.
[14:46] <vila> amogorkon: may be worth changing your workflow :)
[14:48] <amogorkon> vila, i'll take it into consideration if this submit branch thing doesn't fix it
[14:51] <amogorkon> okay, thanks again
[14:51]  * amogorkon bows out
[15:14] <mgz> urk, syntax error in test_config I take it you know about vila and that change to the makefile was involving?
[15:15] <vila> mgz: yes and yes
[15:15] <vila> mgz:  the problem *right now* is that I can't land the fix because pqm is failing somewhere else
[15:15] <mgz> what's the patch?
[15:15] <mgz> I'll apply it locally so I can do this comparision
[15:15] <vila> mgz: and since I don't get email failures I don't know where
[15:16] <vila> mgz: lp:~vila/bzr/integration
[15:16] <mgz> ta.
[15:16] <vila> hmm, now I know which test is failing....tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh
[15:19] <vila> oh my, what a mess. I succeds on lucid/py26, fails on hardy/py24, succeeds on hardy/py25 with a traceback, succeeds on karmic/py24, failed on karmic/py25 (like hardy/py24), succeds on karmic/py26 (with the same tb than hardy/py25)
[15:20] <vila> s/I succeds/It succeeds/
[15:21] <vila> quite interesting for a test but obviously it's trying to test too much at once....
[15:23] <vila> ...and poolie mentioned it this morning on maverick...
[15:26] <vila> jam: ping, pp advice needed
[15:26] <jam> hi vila
[15:26] <jam> what's up?
[15:27] <vila> I sent a submission this morning with a syntax error that pqm happily accepted
[15:27] <vila> that was the lockable config files one, 3 things happened then
[15:27] <jam> vila: yeah, I've run into that in the past, too
[15:28] <jam> complained at the time, not much happened, I guess
[15:28] <vila> 1) I sent the leaking test submission (accepted too on top of the previous syntax error merged cleanly)
[15:28] <vila> 2) I noticed that pqm was damn quick and filed bug #626667
[15:29] <vila> 3) I fixed the syntax error and submit the fix
[15:29] <vila> The fix is at lp:~vila/bzr/integration right now
[15:29] <vila> This last submission wasn't merged and I didn't get the failure email
[15:30] <vila> I've been able to reproduce locally (make check PYTHON=python2.4) and this generates a 47M selftest.log which I suspect leads to a too-big email that is dropped somewhere between pqm and me
[15:31] <vila> Anyway, the offending test is bzrlib.tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh
[15:31] <vila> And as I mentioned above:
 oh my, what a mess. It succeds on lucid/py26, fails on hardy/py24, succeeds on hardy/py25 with a traceback, succeeds on karmic/py24, failed on karmic/py25 (like hardy/py24), succeds on karmic/py26 (with the same tb than hardy/py25)
[15:31] <mgz> okay, I'm going out but have full run of r5395 and r5396 going with the syntax error fix
[15:32] <vila> I feel a urgent need to disable this test to unblock pqm :) Thoughts ?
[15:32] <vila> mgz: and ?
[15:33] <mgz> and nothing till it finishes, I guess :)
[15:33] <vila> jam: I feel a urgent need to disable this test to unblock pqm :) Thoughts ?
[15:33] <vila> mgz: ha, I thought you had the results not that you launched the runs :) Cu !
[15:34] <jam> vila: I'd feel best if you reverted to old code and worked back up
[15:34] <vila> jam: my gut feeling is that this is a latent bug revealed not *caused* by the leaking fixes
[15:34] <jam> so instead of just disabling it, submit a revert patch
[15:35] <jam> that goes before the original borked submission
[15:35] <jam> otherwise I can look more closely
[15:35] <jam> if you want
[15:36] <vila> I'd prefer that yes, that would be more productive, I'm filing a bug right now with details
[15:36] <vila> this test have been failing intermittently for... months across all the platforms on babune
[15:36] <jam> vila: given that you have 3 + patches that you don't actually know if it passed ...
[15:37] <vila> jam: no, I just re-run the tests on my pqm-like setup and that's the only one
[15:37] <jam> I'm not worried about that one test, but if you have 45MB of test failure
[15:37] <jam> that is indicative of many tests failing
[15:38] <vila> jam: no, only one test failure, the 47M are the *normal* subunit output
[15:38] <jam> vila: here it is only 7MB, are you sure?
[15:38] <jam> I've gotten several :)
[15:38] <vila> 7MB compressed ?
[15:38] <jam> possibly
[15:39] <jam> well, compressed and then base64 encoded, I think
[15:39] <vila> 47M uncompressed unfiltered here
[15:39] <vila> jam: subunit stream or | subunit2pyunit stream ?
[15:40] <jam> pqm-stdout.gz IIRC
[15:40] <jam> note the discussion about whether we should remove 'logs' from skipped tests
[15:40] <vila> jam: I have never been able to receive one so I really can't tell
[15:40] <vila> jam: that's why I mentioned the 47M :)
[15:41] <vila> jam: but getting rid of only the skipped ones will not help enough I'm afraid
[15:41] <jam> My mailhost is configured to 10MB attachments
[15:41] <jam> not sure about yours
[15:41] <jam> default is often smaller, like 2-5MB, IIRC
[15:43] <jam> I'd like you to chime in there
[15:43] <jam> since being unable to get PQM output is pretty serious
[15:43] <vila> jam: bug number ?
[15:43] <jam> vila: merge proposal
[15:44] <jam> https://code.launchpad.net/~jameinel/bzr/2.3-filter-tests/+merge/33938
[15:44] <vila> hmm oh yes, I thought it was on testtools
[15:45] <jam> well, lifeless saying "you really should have the log on skips" ...
[15:46] <jam> given that we used to have a single "reason" line, that is now 50 lines of reason + formatting + log
[15:46] <jam> not to mention subunit overhead
[15:48] <vila> Well, I'd be happy to get this stream. I don't really like getting *less* details to debug. Skipped tests are only a minor part of the whole...
[15:48] <vila> jam: can you check which stream you get on failures ?
[15:48] <jam> I often can't get *failure* emails because they go above 10MB
[15:49] <jam> pqm-stdout.gz is the interesting stream
[15:49] <jam> for the subunit stream, everything is in the same output file
[15:49] <vila> jam: yes, I don't have such mails, can you open or forward me one of yours
[15:49] <jam> well, I can't forward it, since you can't get them :)
[15:49] <jam> but I can post it somewhere :)(
[15:49]  * vila slaps himself
[15:59] <vila> jam: further evidence involving this test: bug #579530
[16:00] <jam> think it is a ipv6 vs v4 thing?
[16:00] <vila> jam: not sure in the case at hand, but it confirms that the tests is trying to test too many things at once
[16:12] <la_kavrohi> How can I get my bazaar hook to access branch specific config values? Specifically, those stored in branch.conf.
[16:12] <la_kavrohi> http://dpaste.com/236288/
[16:12] <la_kavrohi> http://dpaste.com/236289/
[16:18] <jam> vila: on chinstrap:~jameinel/pqm-stdout.bz2
[16:19] <la_kavrohi> Nevermind. The push_result.local_branch or push_result.master_branch is the target of the push.
[16:30] <vila> jam: 'time: 2010-08-24 16:55:43.668882Z' is enough identify it as a subunit stream right ? And it's 45M uncompressed anyway
[16:30] <jam> vila: the log is in the subunit stream *and* 'bzr selftest' normal
[16:30] <jam> if that is what you are asking about
[16:30] <jam> so also in "subunit2pyunit' output
[16:31] <jam> and 7MB of stuff we won't look at obscures the stuff we do care about
[16:31] <jam> well, 47MB from what you said :)
[16:31] <vila> jam: but how do you the stuff is not relevant until you understand the failure ?
[16:32] <vila> jam: but how do you know the stuff is not relevant until you understand the failure ?
[16:32] <jam> vila: not failures, *skips*
[16:32] <jam> and test-not-applicable
[16:32] <jam> and xfail
[16:33] <jam> is what *I'm* trying to change
[16:33] <jam> not actual failures
[16:33] <jam> basically everything that wasn't *success* was getting the log attached
[16:33] <vila> then why not keeping *only* failures ?
[16:34] <jam> well, that and errors
[16:34] <jam> but I think that is ~ what I've done
[16:37] <jam> though doing it as a blacklist rather than a whitelist
[16:37] <itamar> anyone know of a wiki that uses bazaar as a backend?
[16:38] <vila> jam: no, you said that you only get rid of the skipped tests, this account for ~10%, this doesn't even guarantee that *I* will get email for failures
[16:38] <jelmer> itamar: wikkid and ikiwiki both can
[16:38] <jelmer> itamar: http://launchpad.net/wikkid, http://www.ikiwiki.info/
[16:38] <itamar> ikiwiki had some caveats I didn't quite understand
[16:38] <jam> vila: well, skips and xfail, I think account for most of it
[16:39] <jam> at the least, it will account far a fair amount of shrinkage
[16:39] <jam> though yeah, probably the subunit overhead might be part of it, too
[16:39] <itamar> I'll look at wikkid
[16:39] <itamar> thanks!
[16:39] <vila> jam: I've been trough enough subunit/testools bugs on xfail and skip to know that they represent only a fraction of the tests...
[16:40] <vila> err, xfail, not applicable not skipped
[16:40] <vila> err, xfail and not applicable not skipped
[16:40] <jam> vila: 2k out of 21k is a significant fraction, I'm trying to determine the verbosity now
[16:42] <vila> jam: will that be enough to goes below the threshold that blocks the emails pqm is trying to send me ?
[16:42] <jam> ah, I see what you mean, I didn't realize success also had a log, since it isn't output by selftest -v, which is where I really cared about it
[16:42] <vila> how about an option for the logs ?
[16:44] <vila> AAAAAAAAAARGHHHHHHH
[16:44] <jam> vila: ??
[16:44] <vila> jam: who was able to land parthm submission ?
[16:44] <jam> other than parth?
[16:45] <vila> anybody ! Currently pqm will accept *any* submission since they all inherit the syntax error
[16:45] <vila> well, anybody than can submit that is
[16:45] <vila> and of course it *has* to refuse the one that fix the error....
[16:46] <vila> bah, yes of course, this the one that fixes the error is the only one that runs the test suite...
[16:48] <jam> 5397 Canonical.com Patch Queue Manager 2010-08-30 [merge]
[16:48] <jam>      (parthm) bzr homepage url fixed in docs. (Parth Malwankar)
[16:48] <jam> looks like parth did it
[16:49] <jam> anyway, yeah, we should do something quick to get pqm back to correct. either your patch or the idea of set -e.
[16:49] <vila> set -e ?
[16:49] <jam> I think for right now, just revert back pre-fix, add the Makefile fix
[16:49] <jam> 'set -e' in bash says if any command fails with non-zero, exit immediately
[16:50] <vila> I don't think we can do that from/for make
[16:51] <vila> ha come on, the leaking test fix have been waiting for far too long and I'm 98% sure it doesn't cause this failure. Don't let the better be the ennemy of the good :-(
[16:51] <jam> vila: we have failures in what was submitted, we don't know how much
[16:51] <vila> jam: have you *looked* at this test ?
[16:52] <jam> of what was submitted since then
[16:52] <jam> I'm not worried about your 1 test
[16:52] <jam> I also don't know why it would fail now when it has been passing for *years*
[16:52] <vila> no, I said it already, only one failure, this test, reproduced locally
[16:52] <jam> vila: how do you know if you aren't getting pqm failure reports :)
[16:52] <jam> ?
[16:52] <vila> I can propose various explanations, and no, it has not been passing for years, it has been *failing* randomly for years
[16:53] <jam> other than knowing that you have an occasional failure locally which doesn't seem to have been happening on pqm
[16:53] <vila> because I don't get my submissions landed either
[16:53] <jam> vila: I don't think I've had a submission kicked back because of that test that I can think of
[16:53] <jam> and I've submitted a lot
[16:53] <jam> vila: right, but you don't know why *PQM* think you can't land it
[16:54] <vila> read the logs, mthaddon gave enough info for me to reproduce
[16:54] <jam> vila: set -e seems to work for me in Makefile
[16:54] <jam> vila: so if it *is* random, then you should also be able to resubmit and have it work
[16:54] <vila> ok, I resign, you're the patch pilot, go, send a revert-fix and don't forget to also unmark the bugs fixed
[17:02] <jam> vila: I'm not trying to be extra difficult, but what you're saying doesn't match up to what I understand. You ran with python2.4 on your machine, and that was the only test that failed?
[17:03] <jam> vila: also, I think we still have a bug with your fix that if the selftest.log has content, but has *no tests* then it still succeeds by accident
[17:03] <vila> jam: yes, starting with bzr.dev as current before parthm submission and adding the fix in lp:~vila/bzr/integration, aka skipping this test until it gets rewritten as proposed in bug #626876
[17:04] <vila> jam: right, but that's a step in the right direction and plug a hole that have been present for *months*
[17:05] <rubbs> Is there anyway to get a launchpad type interface for locally hosted branches? I ask, because I really like the way lp's UI deals with branches and their relationships, but my boss will never go for a third party hosting our code, ever.
[17:05] <jam> vila: the test really isn't that big, all it is doing is implementing an ssh server, which you could pull out anywhere you want  if the number of lines concerns you
[17:05] <jam> the test *is important* to make sure that we actually hook up the whole via ssh code
[17:05] <dash> rubbs: well, worst case you could install launchpad :)
[17:05] <jam> since *all the other tests* skip it and talk over a loopback
[17:06] <vila> jam: I fully realize how important it is, but it fails far too often for far too many different reasons
[17:06] <rubbs> dash: is there documentation on how to do that? I knew it was Open Source, but I couldn't find any way to do that itself.
[17:06] <jam> vila: we need an (single) integration test or we have just as big of a whole
[17:06] <jam> We've certainly in the past broken the ssh connection code
[17:07] <jam> rubbs: there is some stuff around here: https://dev.launchpad.net/
[17:07] <jam> but the big thing is, you have to create your own icons because the lp ones are trademarked
[17:08] <jam> (similar to CentOS vs Redhat, and whatever Debian did with Firefox, IIRC)
[17:08] <rubbs> jam: icons are no big thing. We got a designer here with little to do atm so I can give him that task
[17:08] <rubbs> jam: thank you very much.
[17:08] <vila> jam: I realize that, but the actual test is brittle, I've said it for months as I had to diagnose several failures where it was involved and delete/re-run countless jobs on babune just because it's capricious
[17:09] <vila> jam: and I'm not surprised to see it fail on pqm as fixing the leaks shakes the socket handling code BIG times
[17:09] <jam> vila: but then you remove one test that covers the actual case that people care about (nobody cares if you can connect via a loopback :)
[17:09] <vila> jam: I don't want to suppress it, I want to replace it with several tests to get a better isolation of the failures
[17:10] <rubbs> dash: jam: Oh, this is perfect thank you. I'll look into this right away
[17:10] <jam> vila: the only thing it does after creating an ssh server is 'mkdir'
[17:10] <vila> jam: at least one slave on babune is running a version of paramiko provided by spiv *explicitely* to *not* skip this test already
[17:10] <jam> (well, creating one, connecting to it, and then issuing one command)
[17:10] <vila> jam: and it currently fails for a ConnectionReset !
[17:12] <jam> vila: which honestly sounds like we have a bug in our connection handling...
[17:12] <jam> vila: anyway, my specific point... how can you get more granular on that test
[17:12] <vila> jam: yeah, one that is not reproducible on all platform/python combos ?
[17:13] <jam> I really don't see a way to rewrite it that isn't *connect to an ssh server*
[17:13] <jam> vila: for example, on Windows and different versions of Python, they've had OSError.errno change from being the *windows* error, to a regular errno
[17:13] <jam> (ENOENT versus WINDOWS_ERROR_NO_ENTRY as a not-quite accurate example)
[17:14] <jam> vila: and I know we've had spew to the terminal for a while on Windows because when the client disconnected we would raise the exception rather than suppress it as we did on other platforms
[17:14] <jam> (but it wouldn't die because it was an exception raised in a thread, etc)
[17:18] <vila> well, separating a simple connect/disconnect first, then the simplest hpss handshake and so on up to mkdir
[17:18] <jam> vila: I honestly doubt it is failing because of the mkdir + stuff
[17:19] <vila> jam: exactly why a better isolation will be achieved by *not* having it
[17:19] <jam> vila: if you really thought that mkdir was the problem, you could have trivially fixed that by now. I have the feeling you feel it runs deeper
[17:19] <jam> also ,we only really want 1 test that exercises the handshake code
[17:20] <jam> since it is fairly slwo
[17:20] <jam> slow
[17:20] <jam> if you want to pull out mkdir, I don't care *at all*
[17:20] <jam> I care that we connect to a real ssh server
[17:20] <vila> and this is test is lying anyway, there is no process launched, it's all in the same process and fixing leaks revealed that python + sockets + client + server in the same process... can lead to exceptions being thrown at different points from one excution to the other
[17:22] <vila> my point is: I think we'll be better served by disabling this test until it's fixed (which can only occur soon since it's Critical) than reverting all the work already done and discussing endlessly while pqm is accepting any patch :)
[17:24] <jam> (I think your optimism about 'only occur soon' is a bit high :) however, I am looking over your integration patch, etc now while we're discussing this
[17:24] <jam> and I've queued up some stuff in pqm, as well
[17:24] <vila> meh, it spwans a process
[17:25] <vila> jam: you won't be able to land anything once you fix the syntax error
[17:25] <vila> jam: unless you revert the leking tests submission that is, which doesn't mean that test won't fail either one day or the other
[17:26] <vila> that's the whole point of fixing the leaks, selftest can blow up at any time as mgz realized lately
[17:26] <vila> it hasn't occurred on pqm so far, we're still lucky
[17:28] <vila> not fixing the leaks also means windows test can't be fixed using babune, osx slave can't be added on babune, etc
[17:31] <jam> vila: so the typo... it is only a python2.4 typo? As 'test_config' loads just fine on python2.6
[17:32] <vila> jam: 2.4/2.5, pqm runs in an hardy  chroot with 2.5 as the default python but we override that by running 'make check PYTHON=python2.4' as checked with mthaddon earlier
[17:33] <vila> jam: I discussed the fix with poolie and spiv before sending it, short-circuiting the mp to go faster....
[17:33] <jam> vila: the typo fix?
[17:33] <vila> yes
[17:33] <jam> sure, I'm certainly fine with the change, just trying to understand, as it looks like that fix is already in pqm, but you said it had failed
[17:34] <vila> huh
[17:35] <jam> vila: well, I was trying to submit the 'make check' fix you had, but it is behind your 'integration' fix
[17:35] <jam> which claims to be at 50% complete
[17:36] <vila> yeah, I send that when I saw parthm submission before realizing why it was useless (unless the failure is random...)
[17:37] <vila> jam: check your setup, the test_config.py fix is not in bzr.dev AFAICS
[17:38] <jam> vila: Oh I agree, as I said I'm running 2.6 and wasn't sure why it was a problem
[17:45] <vila> GaryvdM: ping, don't upgrade your bzr.dev branch yet, pong me first
[17:50] <vila> GaryvdM, bialix: can you test lp:~vila/qbzr/config-get-filename-deleted before upgrading bzr.dev ?
[17:52] <vila> jam: if you submitted straight from my branch it should fail, I'd be interested to know if you get a pqm failure mail though :)
[17:53] <jam> vila: well, it has passed 18k tests so far, and is on: bzrlib.tests.test_bundle.V08BundleTester.test_binary_bundle
[17:53] <jam> not sure if that is before or after the test in question
[17:56] <vila> it's the 24199th test out of 24758
[18:01] <jam> vila: well doesn't that suck :)
[18:01] <vila> jam: I had a brief, very brief, instant of pure joy this morning when I saw my submissions land in no time
[18:02] <vila> that was quickly followed by the depressing understanding...
[18:02] <vila> ..and the problem is still not fixed :(
[19:07] <mgz> gra, r5396 didn't run, thought it'd merge over the syntax fix but it lost it
[19:07]  * mgz runs it now
[19:39]  * jelmer waves
[20:02] <jam> vila: I did get the failure with attachment this time
[20:10] <jam> vila: and it is giving a "ConnectionReset" error after spending ~5s (the test runs in 5.6s, I assume that is a timeout of some sort)
[20:11] <jam> and as near as I can tell, that is the server failing to actually respond to the 'mkdir()' request...
[20:12] <jam> log file is in the same plcae
[20:12] <jam> plcae
[20:12] <jam> place
[20:12] <jam> (if my fingers could type)
[20:30] <vila> jam: glad you got this email :)
[20:30] <vila> jam: but it's failing here in 0.533s so not the kind of timeout you're suspecting
[20:30] <jam> vila: so 'set -e' works as I wanted it to
[20:31] <jam> I get the failure early rather than late
[20:31] <vila> jam: good, as long as it works everywhere, I'm happy
[20:32] <jam> vila: well at this point 'test_bzr_connect_to_bzr_ssh' seems to be failing reliably (though it also happens in 665ms here
[20:32] <vila> jam: here ?
[20:32] <jam> I just got it by only running test_transport
[20:32] <jam> on my machine
[20:32] <jam> and on pqm
[20:32] <vila> python and paramiko versions ?
[20:33] <jam> vila: http://www.davidpashley.com/articles/writing-robust-shell-scripts.html#id2384206
[20:33] <jam> python 2.6, paramiko ... ?
[20:34] <vila> regarding the interaction with leaks, the previous sftp server was just leaving threads around never joining them, so this may have hidden the problem
[20:34] <jam> 1.7.5
[20:34] <vila> jam: can you add that to the bug report please
[20:34] <vila> jam: and that's with my fixes for leaks right ?
[20:34] <jam> vila: that is current bzr.dev
[20:34] <vila> ok
[20:35] <vila> jam: only the traceback or more ?
[20:39] <jam> vila: I don't understand "only the traceback"
[20:39]  * vila on phone
[20:39] <vila> jam: but look at bug #628876, there are a lot of variations
[20:39] <jam> fullermd: you use csh? (well, something other than bash), right? Do you know if 'set -e' works there?
[20:40] <jam> vila: wrong bug, I think
[20:40] <jam> 628876 isn't a bug
[20:40] <vila> bug #628876
[20:40] <vila> meh
[20:40] <jam> vila:  bug #626876
[20:41] <vila> bug #636876 gettubg there
[20:41] <jam> you had a 6=>8
[20:41] <vila> twice :)
[20:41] <vila> can type and phone :)
[20:41] <vila> cant :)
[20:41] <jam> vila: everything I saw looks like a variant on connection reset
[20:42] <vila> jam: there are other tbs sometimes
[20:42] <jam> in your python2.5 it is raising EOFError (aka, no more data, aka connection closed)
[20:42] <vila> that can be ignored
[20:42] <vila> on which platform ?
[20:42] <jam> vila: https://bugs.edge.launchpad.net/bzr/+bug/626876/comments/1
[20:43] <vila> jam: that's freebsd
[20:43] <jam> vila: everything looks like connection reset, just variants on how well the python + paramiko + bzr stack handle translating it as such
[20:44] <vila> jam: we shouldn't lose the connection, that's the root problem
[20:45] <vila> jam: and I would happily suspect my fixes if there wasn't *successful* tests
[20:47] <vila> so I'm more inclined to suspect the bug to reveal itself more blatantly now, since, after all, this is what happened numerous times while debugging the leaks,
[20:47] <jam> vila: well it fails if I run the test by itself, so I'm not sure that it has anything to do with leaking threads...
[20:48] <vila> jam: have you tried to establish how many threads/sockets/pipes are involved in this test ?
[20:48] <vila> have a guess
[20:49] <jam> Approx 5
[20:49] <jam> but paramiko does threads also, so I'm not positive
[20:51] <vila> I'd say 2 processes, 7 threads, 3 sockets and 3 pipes
[20:52] <vila> we should be able to get down to 2 processes 3 threads 3 sockets and 0 pipes
[20:53] <jam> vila: perhaps, but it certainly passes @ -r5395 and fails @ -r5396
[20:53] <vila> that's a fact, but it says little about the cause
[20:54] <jam> vila: I think I found it
[20:54] <jam> vila: http://paste.ubuntu.com/485997/
[20:54] <jam> note that you don't actually save a reference to *test_case_server*
[20:55] <jam> nope, not it
[20:55] <jam> at least, not trivially so
[20:56] <vila> that would not explain a succesful test
[20:56] <jam> vila: what successful test, btw
[20:56] <jam> also, I don't seem to be able to get trace information in my log file from the sftp thread, any ideas why?
[20:57] <vila> https://bugs.edge.launchpad.net/bzr/+bug/626876/comments/2
[20:57] <vila> also succeds on hardy/py2.5/paramiko-1.6.4 with a traceback from a thread that can be ignored
[20:57] <vila> - succeeds on karmic/py26/paramiko-1.7.4 with the same traceback than hardy/py25
[20:58] <vila> all of them mentioned in bug #626876
[20:58] <vila> Ha ! Got it right !
[20:59] <vila> all of the run involve 0 to 2 failures in ferry_bytes (including the ConnectionReset except this one comes a bit later in the code)
[21:00] <jam> vila: I'm also getting: No handlers could be found for logger "paramiko.transport"
[21:00] <jam> which would hint that paramiko is trying to warn us about something, but the logging module isn't initialized
[21:02] <jam> which may be "I couldn't actually start up as requested"
[21:02] <vila> that's not in your comment or is it ?
[21:02] <jam> givien the other hints
[21:02] <jam> vila: not sure
[21:02] <jam> I probably didn't paste that part
[21:03] <vila> ok, I got it too on some combinations
[21:03] <jam> vila: I get it much before the final traceback
[21:03] <vila> yeah, at the start of the run, probably when loading
[21:04] <vila> where I get it it's about Random.Pool being BROKEN or something
[21:04] <jam> vila: nope
[21:04] <jam> if I add a "trace.enable_default_logging()" in the middle
[21:04] <vila> nope what ? 8-)
[21:04] <jam> I get: http://paste.ubuntu.com/486002/
[21:04] <jam> vila: not during import
[21:04] <jam> maybe during import of a subprocess or something
[21:05] <jam> vila: that is with this patch: http://paste.ubuntu.com/486003/
[21:05] <jam> Basically, on my machine, I'm not *getting* to ferry_bytes
[21:05] <jam> it fails first
[21:08] <vila> oooh, right, yet another different failure ! Fireworks !
[21:09] <jam> vila: well still a connection failure
[21:09] <vila> but still a problem while client and server are trying to communicate
[21:09] <jam> with this patch: http://paste.ubuntu.com/486003/
[21:10] <jam> on my machine, I'm not even getting into check_channel_exec_request I think
[21:10] <jam> at least, I am unable to log what is happening there
[21:10] <vila> not the way to go then ? :)
[21:13] <jam> vila: I fixed logging, a bit more info now:
[21:13] <jam> http://paste.ubuntu.com/486008/
[21:13] <jam> paramiko is trying to say: Socket exception: Bad file descriptor (9)
[21:14] <vila> right, that's still match the: "someone is trying to read or write at the wrong time" pattern and paramiko use timeouts
[21:15] <vila> jam: no traceback ?
[21:15] <jam> vila: doesn't seem to be one on the server side
[21:15] <jam> trying to sort it out
[21:15] <vila> Connected (version 2.0, client paramiko_1.7.5)
[21:15] <vila> Connected (version 2.0, client paramiko_1.7.5)
[21:15] <vila> Twice ???
[21:16] <jam> vila: I'm playing around with trace stuff, so it is possible I'm just getting 2 outputs to stderr
[21:17] <jam> but yes, it does say that
[21:19] <jam> vila: if I change paramiko to 'raise' where it was just logging I get: http://paste.ubuntu.com/486010/
[21:21] <vila> here is my traceback on babune: http://paste.ubuntu.com/486012/ ferry_bytes is involved
[21:22] <vila> forget about the .bzr.log error
[21:25] <vila> meh, no .bzr.log error there, forget the 'forget' remark ;)
[21:26] <jam> vila: 'failed to load compiled extension' is a bit surprising
[21:26] <vila> the weird thing is that I ran this on windows
[21:27] <vila> jam: fresh branch
[21:27] <vila> we don't care about extensions for this test
[21:28] <vila> hmm, indeed, and it was failing already: http://babune.ladeuil.net:24842/job/selftest-windows/139/#showFailuresLink
[21:29] <vila> I just didn't notice it because it was down to 7 failures on windows (from 306 but for runs interrupted by can't start new thread)
[21:31] <vila> anyway, way too late to continue, EODing
[21:32] <vila> http://babune.ladeuil.net:24842/job/selftest-windows/138/testReport/junit/bzrlib.tests.test_transport/TestSSHConnections/test_bzr_connect_to_bzr_ssh/
[21:33] <vila> is evidence that we *had* a failure with ConnectionReset *before* my patch
[21:34] <vila> jam: so make sure it was passing for you on *windows* *before* my patch
[21:34] <jam> vila: it passes
[21:34] <jam> if I revert
[21:34] <jam> fails after
[21:35] <jam> -r5395 passes, -r5396 fails
[21:35] <fullermd> jam: Not as set -e, no.  There's an -e command line arg just like sh.  Why?
[21:35] <vila> rha, right, same branch, I'm too tired
[21:35] <jam> fullermd: trying to get "make check" to fail if there are any failures. I don't think it is required to run a bash, though
[21:36] <jam> fullermd: we're having the bug that the right kind of error will make PQM think everything is ok
[21:36] <fullermd> Well, it better run a sh.  set -e is standard on Bourne shells AFAIK.
[21:36] <jam> (currently a syntax error)
[21:42] <lifeless> jam: do you need any help with this
[21:43] <lifeless> fullermd: I think its pipefail thats not set
[21:43] <lifeless> fullermd: -e affects the results of a pipe, not the steps
[21:45] <vila> fullermd: yup, as lifeless said, the root cause is an action in a makefile: cmd1 | cmd2
[21:45] <vila> fullermd: cmd1 fails, cmd2 succeeds, make is happy
[21:46] <vila> fullermd: how will you convince make to abort when cmd1 fails ?
[21:46]  * fullermd isn't sure why people are telling me   ;)
[21:46] <lifeless> vila: pipefail
[21:46] <vila> fullermd: oops, it's GNU make :)
[21:47] <lifeless> vila: man bash - look for pipefail
[21:48] <vila> lifeless: just found it, but it's bash, if we require bash in addition to GNU make.... well, that may work
[21:48] <lifeless> you're using bash
[21:48] <lifeless> make doesn't have a shell interpreter
[21:48] <fullermd> _I'm_ not using bash.
[21:48] <lifeless> fullermd: you aren't you're
[21:48] <vila> make use ${SH}
[21:49] <lifeless> true
[21:49] <vila> fullermd: but is it always available on freebsd >
[21:49] <lifeless> anyhow
[21:49] <fullermd> Yes, but make won't use it.
[21:49] <lifeless> easiest way - put the test command in a bash script
[21:49] <lifeless> call that script
[21:49] <james_w> SHELL=/bin/bash in the Makefile and it will
[21:49] <fullermd> There is no /bin/bash on all sorts of systems.
[21:50] <lifeless> fullermd: this is just for pqm, so that point, while entirely true, is irrelevant
[21:50] <vila> easier : https://code.edge.launchpad.net/~vila/bzr/626667-check-no-docs-swallow-errors/+merge/34059
[21:50] <vila> lifeless: ! could be
[21:51] <vila> lifeless: but could fail if the log file is not empty.. somehow
[21:51]  * fullermd just sees this as a good reason to keep working on his make(1) replacement   :p
[21:53] <mkanat> fullermd: You and everybody else? ;-D
[21:53] <mkanat> There actually are like two or three good autotools/make replacements.
[21:53] <fullermd> Well, sure, but mine is obviously the important one.  Everyone else is just marking time 'till I'm done   :p
[21:54] <mkanat> fullermd: lol
[21:54] <fullermd> I don't really need to build a replacement for autotools.  I can slit my wrists with a rusty spoon already.
[21:54] <mkanat> LOL
[21:56] <fullermd> I wasn't overly thrilled with any of the make replacements I saw.  Hence, firing up the ol' Arrogance Engine.
[21:56] <mkanat> Heh. :-)
[21:56] <mkanat> Well, nothing wrong with that. :-)
[21:57] <fullermd> Part of the problem is that I don't want a "build system", so scons and the like are out.  I really do just want a make(1), except without the suck.
[21:57] <vila> jam: so, it seems bzrlib.tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh has never been run on babune except for my tests for leaks where it has always failed :)
[21:58] <vila> jam: so good luck with it, see you tomorrow, keep me informed of your progress !
[21:59] <vila> g'night all
[22:16] <jam> lifeless: I think we have a handle on how to make 'make check-nodocs' fail (set -e works, as would Vincent's suggestion, or figuring out how to set pipefail).
[22:16] <jam> the problem right now is do we disable a test that used to pass, but was a bit brittle in some cases, but now *always* fails
[22:16] <jam> I don't think I've ever had it fail on PQM, but it now fails on PQM and on my machine (where it also used to pass)
[22:17] <lifeless> self.skip ?
[22:18] <lifeless> I mean, mark it as a skip? would that do? then once pqm is locked down safely again, start landing attempts that un-skippify it
[22:24] <jam> lifeless: yeah, to get it unblocked I'll probably do that. I was hoping to actually fix it
[22:24] <jam> but since I'm going off the clock in about 5min, I'll have to take the easy route
[22:28] <bj0_> there was a file in my directory that somehow got renamed to "\",  and when I did a "bzr add ."  it would crash bzr trying to add that file
[23:22] <mgz> okay, film was fun. seems like the entertainment has continued here as well.