[01:05] <jj-afk> back on later
[08:40] <apw> smb`, morning
[08:41] <apw> smb`, any idea what is going on on bug #634487
[08:41] <ubot2> Launchpad bug 634487 in linux "t1.micro instance hangs when installing java" [High,Confirmed] https://launchpad.net/bugs/634487
[09:37] <apw> tumbleweed, about?  i have just pushed a new test kernel for bug #717114 ... it seems the previous one was triggering some blocking and slowness
[09:37] <ubot2> Launchpad bug 717114 in xorg-server "[i945gm] Screen Corruption with new Xorg stack with terminal programs" [Critical,Confirmed] https://launchpad.net/bugs/717114
[09:38] <apw> tumbleweed, see if that one works as well ... seems to for me
[09:38] <tumbleweed> apw: ah I was going to ask you if you would, thanks
[09:40] <apw> tumbleweed, i have it here on my test box, and it seems to work well
[09:52] <tumbleweed> apw: LGTM
[09:55] <apw> tumbleweed, excellent
[09:56] <tumbleweed> apw: and now there's another patch...
[10:00] <apw> tumbleweed, another patch?  whats the subject
[10:02] <tumbleweed> Fix tiling corruption
[10:03] <tumbleweed> oh that was just for trunk, the previous one was for stable
[12:00] <fairuz> I built a kernel from linaro tree
[12:00] <fairuz> when I boot, i got this modprobe: FATAL: Could not load /lib/modules/2.6.38-00509-g47dc59f/modules.dep: No such file or directory
[12:00] <fairuz> any idea? thanks
[12:06] <TeTeT> on Natty with the recent -7 kernel I tried to transfer a large file (~100 GB) via clonezilla and it stopped after 12G. Only a hard reset was possible, the log contains these messages over and over again: http://pastebin.ubuntu.com/582056
[12:07] <TeTeT> is the r8169 driver broken for large data transfer?
[12:22] <fairuz> I got this error http://pastebin.com/CGD220mH when I tried to boot my compiled kernel
[12:25] <ogra_> doesnt look like your kernel package was properly installed
[12:26] <ogra_> usually the postinst runs the necessary commands (i.e. depmod to create modules.dep)
[12:28] <fairuz> ogra_: any suggestion to fix this? What I do is just clone the git tree, then compile it using a defconfig
[12:28] <fairuz> ogra_: It should work I suppose?
[12:28] <ogra_> no idea if that will work, usually we build packages in ubuntu ;)
[12:29] <fairuz> ogra_: sorry a stupid question..what's you call a package :D
[12:29] <ogra_> the missing modules.dep shouldnt stop you from booting
[12:29] <ogra_> a .deb file
[12:29] <ogra_> which cares for regenerating the initrd, call the right commands etc after installing the files
[12:30] <fairuz> ogra_: I see the initrd in my boot partition but no idea what it is :D
[12:30] <fairuz> ogra_: I just replace the old uImage with the new one
[12:31] <fairuz> ogra_: maybe that cause the problem?
[12:31] <ogra_> on a sidenote i'm not sure how linaro handles the configs, they might be genereated from multiple files during buld
[12:31] <ogra_> so defconfig might or might not work
[12:32] <fairuz> ogra_: hmm that's frustrating to hear :D
[12:32] <ogra_> look at the kernel area on the ubuntu wiki, there are hints how to build proper kernel packages
[12:33] <ogra_> or talk to the linaro guys about their kernel tree and how to build it, it might differ from ubuntu
[12:34] <fairuz> ogra_: I'm confused. =) Actually I want to build a kernel for my Ubuntu
[12:34] <ogra_> for what arch ?
[12:34] <fairuz> ogra_: arm
[12:34] <ogra_> heh
[12:35] <ogra_> what arm architecture is that ?
[12:35] <ogra_> board/SoC
[12:35] <fairuz> ogra_: Pandaboard Omap4430
[12:35] <ogra_> why dont you use one of the existing kernels then ?
[12:35] <fairuz> ogra_: there is one for 2.6.38?
[12:36] <ogra_> in natty, yes
[12:36] <fairuz> ogra_: damn, i'm wasting time compiling then :D
[12:36] <ogra_> https://launchpad.net/ubuntu/natty/+source/linux-ti-omap4/2.6.38-1204.5
[12:37] <fairuz> ogra_: you save my life :D
[12:37] <ogra_> note that there is no HDMI driver for .38 yet
[12:38] <fairuz> ogra_: ah ok, I use ssh then
[12:38] <ogra_> you need to use DVI and set the omapfb comdline args (same options as for a beagleboard)
[12:38] <ogra_> indeed, or use ssh ;)
[12:38] <fairuz> ogra_: I dont really need the display actually
[12:39] <fairuz> ogra_: actually the reason i want a new kernel build is that before, i use 2.6.35 and i want to apply some patch
[12:39] <fairuz> ogra_: to appy patches, we have to recompile?
[12:39] <fairuz> ogra_: if you say no, i will kill myself
[12:40] <fairuz> :D
[12:41] <ogra_> indeed you have to recompile to apply a patch ;)
[12:41] <fairuz> ogra_: :D
[12:42] <fairuz> ogra_: so I think why not use a more recent kernel that already have all the patches
[12:43] <fairuz> ogra_: what's the difference from the TI omap kernel in natty than the upstream kernel?
[12:43] <fairuz> ogra_: the compile steps is different?
[12:44] <ogra_> it has additional patches from TI
[12:44] <ogra_> the package is built like any other ubuntu kernel package
[12:45] <fairuz> ogra_: being lazy. Did they put an already built kernel image there? :D
[12:46] <ogra_> yes, click on the armel build on the link i gave you above
[12:47] <fairuz> ogra_: I click here https://launchpad.net/ubuntu/+source/linux-ti-omap4/2.6.38-1204.5/+buildjob/2313441
[12:47] <ogra_> just copy back your original kernel, boot your panda, log in, wget the .deb file and run dpkg -i on it
[12:48] <ogra_> yaou want linux-image... and probably linux-headers... and linux-tools...
[12:48] <fairuz> on the *.udeb file?
[12:48] <ogra_> no the .deb files
[12:49] <ogra_> udeb are special packages used by debian-installer
[12:51] <fairuz> ogra_: I don't see any .deb files
[12:51]  * ogra_ sees them at the link
[12:51] <fairuz> ogra_:
[12:51] <fairuz> ogra_: :D
[12:53] <fairuz> ogra_: I see a list of bonary packages and a list of built files
[12:53] <fairuz> ogra_: and on built files list, all of them are .udeb
[12:54] <fairuz> ogra_: I see them now . Sorry\
[12:55] <fairuz> ogra_: anything I should backup apart from the old kernel image>
[12:55] <fairuz> ?
[13:03] <apw> ogasawara, about ?
[13:04] <ogasawara> apw: yep
[13:50] <lil_pete> hi guys. im trying to modprobe a driver module (ath6kl, wifi-driver for toshiba folio 100 tablet), but i get the error message "unknown symbol in module", dmesg reports "unknown symbol outer_cache". anybody an idea what went wrong?
[15:20] <ogasawara> tgardner, apw: whenever you both are free, lets mumble and circle the wagons
[15:20] <tgardner> ogasawara, ok. I'll be off the phone in awhile.
[15:36] <apw> tumbleweed, about still?
[15:36] <apw> heh actually forget that, abject failure on my machine
[16:38] <kees> apw: what's your kernel upload schedule looking like? I have yet another yama ptrace fix for chrisccoulson. I wanted to prioritize sanely...
[16:40] <tgardner> kees,  you should be talking to ogasawara who will replace apw whilst he's off on vacation.
[16:40] <kees> tgardner: oh! cool, thanks. ogasawara: same question ;)
[16:40] <apw> kees, well we need an upload today for the compiler change, and i hope to slp in an i915 fix if its not an abi bumper
[16:41] <apw> then its leaans call, freeze is thursday so it would likely be monday or not
[16:41] <tgardner> apw, yet another compiler change? whats getting twiddled now?
[16:42] <apw> there have been two uploads for multi-arch this week which has caused a lot of kaos
[16:42] <apw> this time not a compiler payload change, more where things go etc
[16:42] <ogasawara> kees: indeed, I'd prefer not to have to do an additional upload beyond what andy does, but if we need to, monday would likely be the latest.
[16:43] <apw> (for beta)
[16:43] <ogasawara> kees: how quickly can you get the patch to the mailing list?
[16:43] <apw> ogasawara, you thinking what i'm thinking?
[16:43] <kees> ogasawara: right, it's not critical. I just wanted to catch it if going today. i'll send the patch to the list today
[16:44] <apw> that if its small and not a bumper i could get it in
[16:44] <kees> it's 2 lines
[16:44] <ogasawara> apw: yep, was thinking that :)
[16:44] <apw> kees, got it 'now' ?
[16:44] <apw> so i can see if its a bumper
[16:44] <kees> apw: gimme 10 minutes?
[16:44] <apw> np
[16:51] <kees> apw: okay, sent to list
[16:57] <apw> kees, looks pretty small and non-bumperish
[17:00] <kees> apw: should be yeah.
[17:01] <kees> stupid threads :)
[17:01] <tgardner> kees, needs a bug report for Maverick SRU
[17:02] <kees> tgardner: okay, i'll open it with the reproducer and reply on list
[17:06] <apw> let us know the LP#
[17:16] <ogasawara> tgardner: bug 728746 was on the release meeting agenda and seems like a quick fix by just adding some symlinks to the broadcom firmware files.
[17:17] <ogasawara> tgardner: do you prefer a pull request against the the linux-firmware git repo or a merge request for the bzr tree?
[17:17] <ubot2> ogasawara: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/728746)
[17:17] <tgardner> ogasawara, linux-firmware isn't in a bzr repo
[17:17] <tgardner> this is for natty?
[17:17] <kees> apw: 737676
[17:18] <ogasawara> tgardner: yah natty.  hrm, I thought I saw a bzr repo on launchpad.
[17:18] <ogasawara> tgardner: but that answers my question :)
[17:19] <tgardner> ogasawara, it might already be fixed upstream: linux-firmware: wl12xx-Update STA firmware ?
[17:19] <apw> ogasawara, you get bzr branches from the uploader, it pushed the uploads into a branch
[17:19] <tgardner> ogasawara, nm. its nor
[17:19] <tgardner> not*
[17:20] <tgardner> ogasawara, doh! this should be linux-firmware-nonfree
[17:24] <tgardner> ogasawara, ok, I'm just being a dope. it _is_ in linux-firmware, so just send a pull request.
[17:24] <ogasawara> tgardner: ack
[17:56] <bjf> tgardner, you have time to review an lts-backport-maverick branch? this is my first time running the script and i want to make sure things went as expected
[17:56] <tgardner> bjf, can do
[17:56] <tgardner> did it run clean?
[17:56] <bjf> tgardner, yes, and it built
[17:56] <tgardner> bjf, then its likely correct
[17:56] <bjf> tgardner, zinc.canonical.com:/srv/kernel.ubuntu.com/git/bradf/ubuntu-lucid lts-backport-maverick
[17:57] <tgardner> k, gimme a bit
[17:57] <bjf> tgardner, the changelog "looks odd"
[17:57] <bjf> tgardner, mostly the version numbers
[18:05] <tgardner> bjf, looks right. before uploading you'll probably wanna make sure all of the bugs referenced in the changelog have a  linux-lts-backport-maverick package entry.
[18:05] <bjf> tgardner, huh
[18:06] <tgardner> bjf, some of the bugs were likely created before some of your tools.
[18:08]  * tgardner --> lunch
[18:39] <bjf> tgardner, do you use an orig.tar.gz when packaging lts-backport-maverick ?
[18:40] <tgardner> bjf, nope.
[18:40] <bjf> tgardner, thanks
[19:07] <kristian-aalborg> hi all
[22:39] <kristian-aalborg> jjohansen: ping
[22:39] <jjohansen> hey
[22:42] <jjohansen> kristian-aalborg: ^
[22:42] <nelhage> Hey, I'm looking at the latest Maverick git, and I have a question about the commits you backported.
[22:43] <nelhage> I see you backported d281da7ff6f70efca0553c288bb883e8605b3862 ("Make tiocgicount a handler"), but not 0bca1b913 or 0587102cf, which actually convert drivers to use the new handler.
[22:43] <nelhage> Am I missing something, or does that not actually fix the bug?
[22:43] <kristian-aalborg> jjohansen: I'm setting up a *third* machine shortly to try to build, I might have some questions
[22:44] <jjohansen> kristian-aalborg: ok
[22:45] <kristian-aalborg> I have a transcript of the chat the other day, I hope it's not going to be necessary - but always nice with someone around who's familiar with what you're trying to do


[01:18] <MK``> Is this channel ever active? ^^
[01:18] <enqueue> yes
[01:23] <MK``> There are some Japanese characters in unicode that seem to be switched in ubuntu, no matter what application or font I use. It's the combining dakuten and handakuten. a) あ゙     b) あ゛     | a) is the combining character, and acts as such on most of my friends' assorted windows installations, but it shows opposite for me, with b) combining. I checked in many fonts and it's all the same, even the same fonts they used on win
[01:23] <MK``> dows
[01:23] <MK``> Any idea what that is?..
[03:18] <Emmanuel_Chanel> hi


[08:42] <apw> rharper, hrmm, no that just sounds odd to me normally they would be the same as even your first level ports are on a hub
[08:42] <apw> rharper, i would ask you to file a bug, and get straight to bisecting for it as it worked before
[10:32] <tjaalton> is the amd64 build of 4.4.0-9 stuck somehow?
[10:34] <tjaalton> https://launchpad.net/ubuntu/+source/linux/4.4.0-9.24/+build/9279168
[11:13] <tjaalton> nah, done now
[11:34] <apw> tjaalton, was stuck indeed
[11:34] <tjaalton> ah
[11:35] <tseliot> apw: hey, would this be a good pull request? http://paste.ubuntu.com/15256740/
[11:38] <tseliot> bjf: my work is complete, and applies cleanly, with zero conflicts ^
[11:38] <tseliot> and it works well :)
[11:39] <apw> tseliot, i am just going to assume you are jesting
[11:39] <tseliot> so, if that pull request is good, shall I paste it in the bug report or send it to the mailing list?
[11:40] <tseliot> apw: I didn't say it was just a couple of commits
[11:40] <apw> tseliot, so you are serious ... ugg, good in the sense it is properly formed, bad in the sense there is like 200 commits
[11:41] <apw> tseliot, i'd need to fetch it to see how impactful it is in !amdgpu
[11:42] <apw> tseliot, but if its what you need, sending it to the mailing list is your next thing ... but do add some "why" to the top of the pull request
[11:42] <tseliot> apw: ok, I am also going to complete the bug report, just in case
[11:46] <apw> tseliot, thanks indeed
[11:47] <apw> tseliot, though i man never invite you to meet my parents after this
[11:47] <tseliot> apw: am I detecting a hint of sarcasm? :P
[11:47] <apw> just a hint
[11:47] <tseliot> :D
[15:49] <rtg> leitao, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1481357/comments/13
[16:04] <peat-psuwit_> Could anyone help with using backport tree? I ran ./gentree.py --integrate ... and it said "no such file or directory: <kernel-target>/backports/Kconfig"
[16:10] <apw> peat-psuwit_, i am not sure i know what gentree.py is for ?
[16:10] <peat-psuwit_> apw: like, in this one: https://github.com/ubuntu-phonedations/backports
[16:11] <peat-psuwit_> apw: I don't know what it's called.
[16:12] <apw> hrm, you would have to talk to the phonedations lot, and i am struggling to find out where they hang out
[16:15] <bdmurray> apw: Do you have an opinion on bug 1550719? My specific question is should usb-devices be in addition to lsusb or instead of?
[16:15] <peat-psuwit_> apw: Ok, Thank you. I guessed they might be in #ubuntu-touch. I'll try to ask there.
[16:16] <apw> peat-psuwit_, worth a shot indeed
[16:17] <apw> bdmurray, if the upstream maintainers are complaining we have something missing in our bug reports it seems reasonable to add it, we're uploading a ton of stuff already i am sure it will not make the size any different; someone would want to check that file is password freee, bit i expect it to be so
[16:18] <bdmurray> apw: okay
[16:19] <apw> yeah reading the rest of the commentary it seems that this is not expected to have private info in it, so that sounds fine, i wonder if lsusb is any use with that attached, but one problem at a time :)
[16:33] <leitao> rtg, replied to your comment. Thanks!
[16:35] <rtg> leitao, I'm pretty sure we have not changed how the initrd is built, so I'm wondering if the tester actually installed both kernel packages.
[16:36] <leitao> rtg, right. It might be a problem with the test. I will double check that
[16:36] <leitao> Thanks
[16:40] <leitao> rtg, yea. It seems that they wish to have something that never existed in 3.19, which means that this is NOT a regression.
[16:41] <rtg> leitao, I'm good with that :) I'm going to assume until otherwise notified that the bug is solved.
[17:32] <jdstrand> jsalisbury: fyi, I left feedback for bug 1547619
[17:54] <jsalisbury> jdstrand, ack, I'll take a look
[18:05] <jdstrand> jsalisbury: thanks!
[18:06] <jsalisbury> jdstrand, np.  sorry that we have to use the upstream kernel for testing.
[19:13] <rtg> jderose, could you open a new bug regarding ureadahead ?
[19:15] <jderose> rtg: after looking into it more, i don't think there's an issue... the warnings about relative paths seem expected, even though there are a lot of them these days
[19:16] <jderose> rtg: but if it seems like there is a new bug, i'll definitely file a bug :)
[19:16] <rtg> jderose, I haven't looked in awhile. Is there actually valid ureadahead info being generated ?
[19:17] <jderose> rtg: i'm not 100% sure about that, it's a bit hard to tell from the logging. currently my theory is valid entries are being generated, but that there are (for whatever reason) a lot more relative paths that are getting ignored during the scan
[19:18] <rtg> jderose, I'll try to remember to have a look tomorrow.
[19:20] <jderose> rtg: this caught my attention at first because there are so many ureadahead warnings in syslog, but maybe their expected, dunno
[19:20] <rtg> jderose, I haven't touched it since Ubuntu was concerned about boot speeds (which has been a few releases)
[21:56] <ngomes> hello , i have a question
[21:56] <apw> (just ask if you have a question)
[21:57] <ngomes> as far as my understanding from linux,  the hardware devices are probed from the kernel in order to load apropriate driver. my question is : as far as hardware is probed , wouldn't it be faster to write to a file the hardware , than to always probe hardware every single boot ?
[22:10] <xnox> ngomes, .... you are assuming kernel has a device to read a file from.
[22:10] <ngomes> xnox, i know few about kernel , just wondering
[22:10] <xnox> does not scale, cause hardware is different each time one boots, or even resumes from suspend/hybernation
[22:10] <ngomes> how is different ?
[22:11] <xnox> and it often needs to be re-initialised, in a device specific manner.
[22:11] <ngomes> i dont see any load module when i resume from suspend
[22:12] <ngomes> at least, at dmesg
[22:12] <xnox> ngomes, usb devices attached/detached missing, firmware updates changing how hardware is seen, bios updates changing properties as to what sort of things stuff depends on.
[22:12] <xnox> in bios a user can go and change which things are available/visible/enabled, etc.
[22:13] <xnox> it really is a different world each time. And probing, and loading things on demand is often faster than disk-io reading caches =)
[22:13] <ngomes> would give a load error, no problem ?
[22:13] <ngomes> hmm ok
[22:14] <ngomes> i really don't know how probe works , so yeah , overall might be faster
[22:14] <xnox> ngomes, https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface
[22:15] <ngomes> that's ACPI , isnt that about power management ?
[22:16] <xnox> before one can power things on and off, one needs to configure and find them....
[22:20] <ngomes> xnox, so kernel talks AML to ACPI in order to gather info about the hardware components ?
[22:23] <ngomes> ok, i get a better ideia
[22:23] <ngomes> thanks for all
[22:23] <ngomes> byebye


[00:46] <tartar> I wonder, though, if writing to console in upstart scripts in Lucid could block?
[00:47] <tartar> I hear plymouth owns the console and bug 785242 implies that writing to it may cause a dead lock.
[00:54] <SpamapS> tartar: you should only have one 'console owner' active at one time
[00:55] <SpamapS> tartar: you can have some other console owner after plymouth exits
[15:08] <cwillu_at_work> I want to set up a job that will ignore its start-on stanza based on a test, but can still be started manually via "start foo-job"
[15:08] <cwillu_at_work> is there an environment variable or something I can check to distinguish?
[15:08] <SpamapS> cwillu_at_work: pre-start is for that
[15:08] <SpamapS> cwillu_at_work: in pre-start, you can just run 'stop' and the job's start will be cancelled
[15:09] <cwillu_at_work> sure
[15:09] <cwillu_at_work> but that would also trigger if I ran "start foo", wouldn't it?
[15:09] <SpamapS> cwillu_at_work: the env variable to check is '$UPSTART_EVENTS'
[15:09] <cwillu_at_work> ah, thanks
[15:10] <SpamapS> cwillu_at_work: it will be empty with a manual start/stop
[15:13] <cwillu_at_work> perfect
[16:54] <tartar> thanks, SpamapS
[16:55] <tartar> I guess this prevents from easily debugging upstart scripts by echo-ing messages
[16:59] <tartar> Although the hardest cases that need debugging may lose that tmpfs file on reboot.
[17:02] <SpamapS> tartar: you can have console output as many times as you want
[17:02] <SpamapS> tartar: only console owner is dangerous
[17:02] <SpamapS> tartar: and newer upstarts log everything to /var/log/upstart now
[17:08] <tartar> But I thought plymouth could block these writes to the console when it makes itself busy.  The console output lockup bug made me think that "owning" the console meant plymouth injecting itself into the data flow between /dev/console and the screen.  I guess I mis-interpreted the bug.  (I disliked the newer upstart logging into separate files from each conf file.  This makes observing the timeline difficult).
[17:08] <SpamapS> tartar: yes plymouth can block, but its job is to not block, and multiplex things properly.
[17:09] <SpamapS> tartar: cat /var/log/upstart/* | sort works
[17:09] <SpamapS> tartar: the date/time stamps are ISO and sort perfectly
[17:09] <tartar> By "blocking" I mean stopping the upstart scripts where they try to write to stdout.
[17:10] <tartar> Thanks for the sort trick.  I did not see timestamps in some Ubuntu 12 setup.
[17:11] <SpamapS> tartar: some things don't have timestamps actually
[17:12] <SpamapS> tartar: so you're right about that ;)
[17:12] <SpamapS> perhaps upstart should have that as an option
[17:12] <SpamapS> tartar: I'm on crack. I spot checked 2 things, and they had timestamps, but those two things were both openstack components which log with a nice structured logger
[17:13] <SpamapS> tartar: its just raw "whatever the programs printed"
[17:13] <SpamapS> slangasek: ^^ possible upstart feature idea.. add timestamps to logs
[17:25] <slangasek> SpamapS: yes, I've been thinking we ought to do that.  Could you file a bug report so we don't lose it?
[17:26] <slangasek> (and/or provide a patch? :)
[17:29] <SpamapS> looking at both right now
[17:30] <SpamapS> https://bugs.launchpad.net/upstart/+bug/1154207
[19:21] <xnox> if my crazy idea works, it will be wonderful.
[19:25] <SpamapS> xnox: in the US we say it like this: "Hey, watch this!"
[19:25] <SpamapS> [boom]


[13:38] <qengho> Hi. I want to manage some of ubuntu/+source/chromium-browser's bugs, but LP doesn't think I'm a bug supervisor.  How can I change it?
[13:38] <dobey> qengho: aren't you an ubuntu dev?
[13:39] <qengho> Er, hrm.  I don't have upload rights, if that's the same thing.
[13:40] <qengho> I've been happy getting sponsors, so far.
[13:40] <cjwatson> qengho: https://wiki.ubuntu.com/UbuntuBugControl
[13:40] <qengho> thx.
[13:40] <dobey> yeah, you need to be a member of that
[13:41] <dobey> (which i thought you were, but maybe you let it expire)


[18:32] <Brainstorm> Updates for Bangladesh: +243 cases (now 1.6 million), +3 deaths (now 27989), +17387 tests (now 10.9 million) since 19 hours ago


[06:47] <dholbach> good morning
[08:13] <elacheche> Morning!
[13:10] <svij> dholbach: dpm: hey! I think we are ready to start the Call for Contributions today for UbuCon Eu. I've added http://ubucon.org/en/events/ubucon-europe/talks/ and http://ubucon.org/en/events/ubucon-europe/wishlist/
[13:10] <svij> so we could post the announcement on fridge
[13:21] <dpm> svij, excellent!
[13:21] <svij> also, here's the announcement: https://docs.google.com/document/d/16AMWwK_cpFY4zr5HYB-CKkGQAHp36dhRNZMTkOQPvLA/edit
[13:22] <dpm> svij, dholbach and I are about to start a meeting, so we might not be too responsive in the next ~30 mins to 1h
[13:22] <svij> ok!
[13:22]  * dpm starts looking at the announcement
[14:30] <philipballew> dpm, hey can I send you a pm?
[14:45] <svij> philipballew: no, I need him first. :P
[14:56] <philipballew> svij, you cant always get what you want!!! :)
[14:56] <Kilos> hahaha
[14:57] <svij> philipballew: pff
[15:04] <svij> dpm: dholbach: I need to go off for an hour in a couple of minutes. If it's okay for you, than I would like to post the announcement today (or I can ping someone else to post it there on the weekend)
[15:05] <dholbach> svij, I was in calls all afternoon - let me check the draft in 20 mins
[15:05] <dholbach> double-check rather :)
[15:05] <svij> yep!
[15:05] <dholbach> I'll give you feedback
[15:05] <dholbach> and yes, just talk to folks in #ubuntu-news-team to get it on the fridge
[15:06] <svij> ok
[15:06] <dholbach> or their mailing list
[15:06] <svij> I'll need to go now, will check in ~one hour
[15:06] <dholbach> cool
[15:06] <dholbach> thanks svij!
[15:12] <philipballew> dholbach, got a second for a quick pm?
[15:13] <dholbach> in a call
[15:13] <philipballew> no worries. maybe later
[15:13] <dholbach> feel free to PM - I'll respond later
[15:34] <dholbach> can a English native speaker take a look at https://docs.google.com/document/d/16AMWwK_cpFY4zr5HYB-CKkGQAHp36dhRNZMTkOQPvLA/edit too?
[15:34] <dholbach> svij needs a review
[15:35] <Kilos> who can edit it dholbach
[15:36] <Kilos> The UbuCon Europe is an event for everybody: for beginners, developers and experts. The main topics will covers hopefully everything about Ubuntu and Open Source Software. Be sure to join the conference
[15:36] <Kilos> should be
[15:37] <Kilos> the main topics will hopefully cover bla bla
[15:37] <Kilos> i read further
[15:37] <dholbach> Kilos, svij will pick it up once he's back (in half an hour I think)
[15:37] <dholbach> I will need to run
[15:37] <dholbach> thanks a lot Kilos!
[15:37] <Kilos> ok ill be here
[15:37] <Kilos> my pleasure to be able to help
[15:39] <dholbach> <3
[15:59] <dholbach> all right - weekend time - have a good one everyone!
[16:00] <Kilos> cheers dholbach
[16:00] <Kilos> have a good one
[16:00] <dholbach> thanks
[16:11] <svij> Kilos: thanks! fixed that one
[16:12] <Kilos> then when you done dholbachs changes it looks fine to me
[16:12] <svij> yep, done it
[16:12] <Kilos> cool
[16:17] <davidcalle> dpm: popey: mhall119, have a nice weekend o/
[16:18] <dpm> mhall119, I need to run now. Would you mind assisting svij if he needs help with the ubucon EU announcement?
[16:18] <dpm> you too davidcalle!
[16:18] <svij> dpm: have a nice weekend!
[16:19] <dpm> thanks svij, have a good one too!
[16:23] <mhall119> no problem, I'm here if you need me svij
[16:41] <balloons> Good morning all. A most happy Friday to you
[17:02] <svij> mhall119: I just need someone who can publish it on fridge
[17:02] <jose> I can
[17:02] <jose> #ubuntu-news please :)
[17:02] <jose> I'm working on some stuff but will do so shortly
[17:02] <svij> yay
[17:48] <mhall119> svij: https://www.reddit.com/r/Ubuntu/comments/4cwymi/announcing_ubucon_europe_and_call_for/
[17:48] <svij> mhall119: upvoting… :)
[17:48] <svij> thx!
[18:07] <mhall119> svij: do you have a facebook page for ubucon europe?
[18:07] <svij> yes
[18:07] <svij> https://www.facebook.com/Ubucon-Europe-1099898853356780/?fref=ts
[18:07] <svij> and twitter too: https://twitter.com/ubuconeurope
[18:09] <mhall119> I don't have access to the Twitter account, but I've posted on the Ubuntu FB and G+ accounts for you
[18:09] <mhall119> the FB one should syndicate to Twitter
[18:09] <svij> ah great, just saw it, thanks! :)
[19:35] <svij> mhall119: I've removed the UbuCon Summit focus from ubucon.org homepage. It now links to UbuCon Europe. Doesn't make sense to still show old ubucon summit information on there
[19:50] <mhall119> svij: agreed


[01:03] <adamant1988> nixternal: ping
[03:12] <nixternal> adamant1988: pong?
[06:37] <Burgundavia> meeting is now on the fridge
[06:37] <nixternal> Burgundavia: is that what you were pinging me for?
[06:38] <Burgundavia> ya, the fridge has a nasty habit of logging you out if you do nothing for about 5 minutes
[06:38] <Burgundavia> can we get that fixed?
[06:40] <beuno> Burgundavia: great, scheduled!
[06:40] <beuno> now I'm going to get some of that sleep everyone is talking about...
[06:40] <Burgundavia> I figured with both you and nixternal on board, we were good
[06:40] <nixternal> Burgundavia: we are planning on fixing the entire fridge, at least I hope
[06:41] <Burgundavia> ah, rocking
[06:41] <Burgundavia> should we just merge it into the general ubuntu website?
[06:42] <beuno> Burgundavia: absolutely, we'll have more the enough to talk about
[06:42] <beuno> I'm out, g'night
[06:43] <nixternal> Burgundavia: I believe Matthew has plans for it
[06:43] <nixternal> I don't think they are going to merge, they of course want to keep it seperate
[06:43] <Burgundavia> be nice if he shared some of them
[06:43] <nixternal> we aren't "official" enough I guess
[06:44] <Burgundavia> arghhh
[06:44] <Burgundavia> this is exactly why Red Hat got nailed a few years ago
[06:44] <Burgundavia> they learned their lesson
[06:44] <nixternal> well, it is going to take Ubuntu the same thing
[06:44] <Burgundavia> I hope Canonical doesn't have to learn it the hard way
[06:44] <nixternal> they will
[06:44] <nixternal> they seperate and don't support smaller projects such as Marketing, the Fridge, and so on
[06:45] <Burgundavia> they support Marketing
[06:45] <Burgundavia> that is out fault, as we are not holding regular meetings, etc.
[06:46] <Burgundavia> once we are holding regular meetings and get diy published, we can start working more regularly with them
[06:46] <nixternal> well, Canonical needs to do some marketing themselves
[06:47] <Burgundavia> they do
[06:47] <Burgundavia> they have a fair number of case studies, etcl.;
[06:47] <nixternal> the only support I ever seen from them is someone came to one of our meetings before and said, "oh ya sounds good" to every point brought up
[06:48] <Burgundavia> well, I have seen christina armstrong on lp
[06:48] <Burgundavia> she is doing lots with the new website
[06:48] <Burgundavia> it would be nice if they could hang out on irc a bit more, however
[06:48] <nixternal> well, they don't need to hang out on IRC, we do have a mailing list. They could say "hey, this is what we are thinking about, is it possible to get some help, or what do you think?
[06:49] <nixternal> all of Ubuntu's marketing doesn't come from this team nor Canonical
[06:49] <nixternal> it comes from the users, distro watch, blog posts, and cheesy news sites
[06:49] <Burgundavia> well, to be fair, a lot of the marketing list is useless ideas being thrown around
[06:50] <Burgundavia> aside from the fridge and the uwn, little is currently being done by us
[06:50] <nixternal> tis why I have stayed quiet
[06:50] <Burgundavia> indeed
[06:50] <Burgundavia> I would like to see the case study stuff get pushed a little more
[06:50] <nixternal> I just finished working an Executive Marketing contract with the Chicago Cubs, talk about fun
[06:51] <nixternal> jesus, their marketing and management suck just as bad as the team does
[06:51] <Burgundavia> I am coming to washington dc in april
[06:51] <Burgundavia> can you make the drive?
[06:51] <nixternal> I just came back from there last night
[06:51] <Burgundavia> ah
[06:51] <nixternal> I took my daughter back home since I have this week off for spring break
[06:52] <nixternal> brb
[06:56] <Madpilot> Burgundavia, what's in DC in April?
[06:56] <Burgundavia> computers in libraries
[06:57] <Burgundavia> we are going to 9 events in april, hence why I have been pressed into service
[06:58] <Madpilot> that's conference season this year, evidently
[07:01] <nixternal> April is super busy again for me
[07:01] <nixternal> March has been nice and calm except for midterms
[08:31] <jenda> is ubuntu.com down?
[08:34] <jenda> Burgwork: I'm not very happy about you scheduling the meeting an entire 3 hours after you asked if everyone is OK with the time :(
[06:00] <Burgwork> jenda: sorry, I had gotten a few acks, so I went ahead and did it
[06:01] <jenda> alright
[06:02] <jenda> no problem really - but obviously I would be much happier if we rescheduled it to a day I could come.
[06:04] <jenda> beuno: how would a day later be for you?
[06:05] <beuno> as long as it's in the same time frame (or a few hours earlier), it's fine
[06:05] <jenda> Burgwork: you?
[06:05] <Burgwork> jenda: works for me
[06:06] <jenda> nixternal: and you? Sunday, April 1 20:00 UTC meeting?
[06:06] <juliux> hi jenda
[06:06] <juliux> jenda, i think we need more stickers from you;)
[06:07] <jenda> O_O !!!!
[06:07] <nixternal> works for me
[06:07] <jenda> You germans are Craaaazzyyy!
[06:07] <jenda> juliux: how many?
[06:07] <jenda> :)
[06:07] <juliux> jenda, i will see it in the next days
[06:08] <jenda> juliux: ok, cool.
[06:08] <juliux> jenda, but i think we have only 300 ubuntu stickers left
[06:08] <jenda> 497	644	438	371
[06:08] <jenda> whooops
[06:09] <jenda> I have 497 U, 644 K, 438 X and 371 Edu
[06:09] <jenda> You can have them all
[06:09] <jenda> And you can also have more, but it'll take longer.
[06:11] <juliux> i will e-mail you in the next weeks
[06:11] <juliux> the next show in german is at the end of may beginig of june
[06:11] <jenda> ok
[06:12] <juliux> so we have around 2 month
[06:12] <jenda> plenty of time.
[06:12] <jenda> juliux: any feedback on the quality and images?
[06:12] <juliux> not yet
[06:12] <jenda> ie. should the next batch be the same, or does something have to change?
[06:12] <jenda> ok
[06:12] <juliux> but the people love the 3d effect
[06:13] <jenda> ...so it should be on the other types as well, correct? (it's just on Ubuntu now, I think)
[06:13] <MitchM> <3 Jenda
[06:13] <jenda>  :)
[06:13] <MitchM> How is diy comming along ? ;)
[06:17] <juliux> jenda, it don t have to be but it looks better
[06:17] <jenda> MitchM: not bad, just waiting on some cooode...
[06:18] <jenda> Ah, heeere you are!
[06:18] <beuno> aaah... yes, hello, I dropped a penny
[06:18] <jenda> :)
[06:18] <beuno> so... meeting is changed to sunday?
[06:19] <jenda> I suppose so - so far there's only one person who has agreed to saturday and hasn't acked to sunday yet - nixternal
[06:19] <nixternal> scroll up, I acked already :)
[06:19] <jenda> ah
[06:19] <jenda> ok, sunday it is, then :)
[06:20] <beuno> isn't there a launchpad feature to handle this?
[06:20] <beuno> Burgwork: will you change it in the fridge?
[06:21] <Burgwork> beuno: have you sent the new time to the mailing list?
[06:22] <jenda> Burgwork: I have
[06:22] <beuno> Burgwork: I have now
[06:22] <jenda> beuno: don't ;)
[06:22] <beuno> oooh
[06:22] <jenda> argh
[06:22] <jenda> :)
[06:22] <beuno> well
[06:23] <beuno> at least they'll notice  :D
[06:23] <jenda> MitchM: why don't you have an unaffiliated cloak?
[06:23] <jenda> beuno: ;)
[06:23] <jenda> MitchM: ie. would you like one?
[06:30] <beuno> jenda, mitchM__, the DIY website is almost done, I need to dedicate a bit over an hour and then upload
[06:30] <beuno> you should be able to add content to it and see if it needs any final touches
[06:30] <MitchM__> jenda, I would love one jenda :)
[06:31] <MitchM__> beuno, great work on the DIY site (everyone)
[06:31] <MitchM__> I always enjoy going there.
[06:31] <beuno> I just got hung up with launchpad folks last night, which ended up by me doing this:  https://help.launchpad.net/BzrHowto
[06:31] <MitchM__> ouch :0
[06:31] <MitchM__> :) *
[06:32] <jenda> MitchM__: cloaked
[06:32] <beuno> and opening bugs and such
[06:32] <MitchM__> jenda, wonderful :) thanks !
[06:32] <jenda> MitchM__: however, this nick ain't linked.
[06:32] <MitchM__> haha yeah... I just made a couple changes to the Network; killed me pretty good ;)
[06:33] <MitchM> :)
[06:35] <meatballhat> juliux: got the polo shirt, btw  ;-)   Thanks!
[06:35] <juliux> meatballhat, cool
[06:35] <juliux> meatballhat, is the size ok?
[06:35] <meatballhat> juliux: it's perfect ;-)
[06:35] <juliux> great
[06:36] <meatballhat> juliux: my dogs were *amazed* by the smell of the packaging ... :P
[06:36] <juliux> ???
[06:36] <meatballhat> ...all the various foreign scents it had picked up  :)
[06:36] <meatballhat> hehe
[06:37] <jenda> ROFLMAO
[06:37] <meatballhat> jenda: I see beuno's pushing up his code soon?
[06:38] <jenda> meatballhat: he better ;)
[06:38] <meatballhat> heehee .... ;-)
[06:39] <jenda> BTW, UWN people...
[06:39] <jenda> I prodded Matthew Nuzum to add the UWN to the news list at the top of *ubuntu.com
[06:40] <jenda> (which includes ubuntuforums.org)
[06:40] <beuno> jenda:   :D    any news yet?
[06:40] <meatballhat> very cool  B-)
[06:40] <jenda> well, it's on his to do list ;)
[06:41] <jenda> he said he sees the case for the UWN to be up there, just that there are too many things there already.
[06:41] <jenda> also, I made this: http://www.ubuntuforums.org/showthread.php?p=2335723
[06:41] <beuno> that's encouraging!
[07:14] <poningru> juliux, jenda: re: swag should we prod canonical to start making swag instead of marketing people making swag?
[07:14] <poningru> just so that loco teams can get some free swag as well
[07:16] <juliux> poningru, i am not sure if that is a good solution
[07:16] <poningru> juliux: hmm? explain
[07:16] <juliux> poningru, my experiences with canonical and shipping stuff are not the best ones
[07:17] <poningru> heh
[07:17] <juliux> poningru, for the german locoteam it was and is easier to make the stuff self
[07:17] <poningru> oh hmm
[07:18] <juliux> then we know when it is finished and we know that it will be there when we need it
[07:19] <juliux> i requested on time a conferenc pack
[07:19] <juliux> it takes 8 weeks
[07:19] <juliux> and around 10 mails to get it
[07:20] <poningru> hmm maybe we should get jono to come to the meeting
[07:20] <juliux> that is a good point
[07:47] <jenda> poningru: what exactly are you asking?
[07:47] <jenda> aaah
[07:48] <jenda> No. It's a community effort :)
[07:48] <jenda> We don't make Canonical run forums or stuff like that. We just do it ourselves.
[07:48] <poningru> right
[07:49] <poningru> but then poor loco teams dont get swag
[07:49] <jenda> If they like it, they'll support us.
[07:49] <jenda> Not entirely true.
[07:49] <poningru> how so?
[07:49] <jenda> I'm able to make a profit on the stuff, and I intend to use it for the locoteams most in need.
[07:49] <jenda> The German LoCo makes money too, and it's able to buy stickers from me ;)
[07:50] <poningru> hmm
[07:50] <jenda> I've sent some posters to the French LoCo and the Venezuelan one free of charge - although effie_jayx will probably try to pay for it somehow.
[07:50] <jenda> And obviously the Czech LoCo, too.
[07:51] <jenda> So if enough people buy or donate to the cause, LoCos can get supplied for free. Even as is, they can get very good stuff cheaply.
[07:51] <poningru> hmm
[07:52] <poningru> I guess -fl should start printing materials then
[07:52] <jenda> nothing's stopping you ;)
[07:53] <jenda> Ohio might be doing some stuff too, I hear rumors ;)
[07:58] <meatballhat> jenda: owwww
[07:58] <meatballhat> whaaa?
[07:58] <jenda> poningru: you know that a good part of DIY is all about convincing people they should make swag, right? :)
[07:59] <poningru> heh did not know that
[07:59] <poningru> jenda: see my entire thinking was lets have the lmi country loco's do the printing where it would be greatly cheaper
[08:00] <poningru> and then ship to other countries
[08:00] <jenda> lmi?
[08:00] <meatballhat> jenda: the Roughcuts - being 1-color - cost about 1/5 what "Highway" will cost  :P
[08:00] <jenda> Well, that's what I'm thinking ;)
[08:00] <poningru> lower and middle income
[08:00] <jenda> In fact, I think I wrote this down somewhere... /me looks
[08:00] <jenda> it's definitely the way it should be done.
[08:00] <poningru> jenda: so if it costs like 1USD to make a shirt in peru or something
[08:01] <jenda> ...and since I reside in one such country,... ;)
[08:01] <poningru> hehe
[08:01] <poningru> yeah
[08:01] <poningru> well I dont know if I consider eastern europe such a country anymore ;)
[08:02] <poningru> s/country/area
[08:02] <poningru> you know what I meant
[08:03] <poningru> :p
[08:03] <jenda> depends - it's a lot cheaper here than in neigbouring Germany for example.
[08:03] <jenda> Although there obviously are other countries which are even better.
[08:03] <poningru> hmm ic
[08:03] <poningru> how much is it to have a shirt made there?
[08:03] <jenda> about $5
[08:04] <poningru> hmm see thats really cheap compared to here
[08:04] <poningru> 50% cheaper infact
[08:04] <jenda> it would obviously differ a lot depending on type/number/print
[08:04] <poningru> right
[09:19] <atoponce> great. now i gotta rearrange my irssi windows... :)
[09:20] <jenda> :)
[09:21] <tonyyarusso> atoponce: /window move is nice
[09:21] <atoponce> yeah. it's just organizing it in a fashion that is easy to recall later
[09:22] <atoponce> like, put all the loco channels next, then the utah channels, etc
[11:53] <Wicks> lo all
[11:53] <beuno> howdy Wicks
[11:56] <jenda> aloha
[11:58] <Wicks> take 2... lo all!
[12:01] <beuno> take 2, howdy Wicks
[12:03] <Wicks> hey - mac wanted to reboot. as soon as my wifi card is supported im giving mac os the 2 gig partition it deserves
[12:03] <jenda> take 2, aloha? :)
[12:05] <beuno> Wicks: great, I've seen quite a few users with ubuntu on mac
[12:06] <Wicks> it seems to work fantastically on every model of mac... except this one lol
[12:06] <Wicks> hey jenda


[00:03] <spiv> Good morning.
[00:24] <yann2> is there a good reason why I wouldnt want to have +w for group on .bzr/checkout/dirstate ?
[00:25] <yann2> I got problems by pushing because that file belongs to another user, although the group is set correctly, the user seems to need to write there
[00:29] <spiv> yann2: Odd, I wouldn't have thought that push would need to write to that file at all.
[00:30] <yann2> it might be the update I just added before actually :)
[00:30] <spiv> yann2: the reason not to set group +w for that is if you don't want to allow other users in that group to tell bzr that files have been added or deleted, or that merges have been made...
[00:31] <spiv> (Or that renames have happened, or conflicts resolved, etc, i.e. changes to the state of the checkout)
[00:31] <spiv> Yeah, the update would make sense :)
[00:31] <yann2> well users in the group can basically remove the .bzr folder :)
[00:32] <yann2> I think the problem is that I do an automated update before doing a push... mmmmh, I ll look into that, thanks...
[02:32] <RenatoSilva> how to diff between branches?
[02:37] <spiv> D'oh, missed RenaotSilva
[02:38]  * jelmer waves to spiv
[02:38] <spiv> For the record: "bzr help diff"
[02:38] <spiv> Hi jelmer
[02:38] <spiv> Any progress on the bzr-svn/chk issue?
[02:39] <jelmer> spiv: No, I need to follow up on your email but I haven't had the time to do so yet (travelling at the moment).
[02:39] <spiv> I was CC'd on part of a thread, but don't know if I'm missing any discussion, and probably the discussion ought to happen on (or at least summarised on) the bug...
[02:39] <spiv> Ah, ok.
[02:39] <spiv> To UDS, I guess?
[02:40] <jelmer> spiv: No, although I am in the US. Google Summer of Code mentor summit and GitTogether
[02:40] <spiv> Oh, heh.
[02:40] <spiv> So near and yet so far!
[02:40] <spiv> (not that I'm at UDS this time either)
[02:42] <jelmer> spiv: Are you going to the epic?
[02:46] <spiv> I am
[02:48] <jelmer> Cool
[07:50] <vila> hi all !
[07:51] <GaryvdM> Hi vila
[07:52] <vila> _o/
[15:10] <mgz> I see jml has blizted a bunch of testtools things
[15:10] <mgz> wonder if he'd prefer follow up bugs for continuing issues or reopening the current ones
[15:11] <lifeless> mgz: new bugs
[15:14] <mgz> will do, just found a mp for one of them and added a comment too.
[15:14] <mgz> I guess I could subscribe to testtools somehow.
[15:23] <mgz> ...might just put up some branches for these test failures, some of them are shallow.
[15:34] <mgz> hm, Python doesn't expose raise. I guess kill covers it anyway.
[17:11] <RenatoSilva> bzr qlog shows "Failed to decode using utf8, falling back to latin1", why?
[17:12] <RenatoSilva> isn't bzr aware of the encoding of the file?
[17:13] <abentley> RenatoSilva: bzr does not store any information about file encoding.
[17:13] <abentley> RenatoSilva: Individual commands can guess the current file encoding, if they choose.
[17:14] <RenatoSilva> if they choose? a command needing to print file content ought to do that, doesnt it?
[17:15] <RenatoSilva> what's funny is that file is latin1 and diff in bzr qlog shows file as utf8 (drop down in bottom) but the chars are ok
[17:16] <abentley> RenatoSilva: No, generally just emitting the bytes to the console works quite well.
[17:16] <abentley> RenatoSilva: And for binaries, it's generally the only thing that can be done.
[17:16] <RenatoSilva> hmm this is a bug, it tries to decode from utf8 and something defaults to latin1 (msg above), but the drop down is not updated
[17:17] <RenatoSilva> by emiting the bytes to console you mean relying on python's guessing right
[17:19] <abentley> RenatoSilva: Actually, it means relying on the console to have an encoding that is compatible with the files' encoding.
[17:19] <RenatoSilva> where console is the python's stdout object
[17:20] <abentley> RenatoSilva: The console is written to via python's stdout object, but it is not, itself, anything to do with python.
[17:20] <RenatoSilva> by console you mean the terminal?
[17:21] <abentley> RenatoSilva: yes, it is usually a terminal.
[17:46] <radix> hey guys
[17:47] <radix> is there an easy idiomatic solution to "the g+w problem" yet?
[17:47] <radix> i.e., when I bzr push with bzr+ssh to a repo on a shared server, I want it to be group writeable
[17:47] <radix> do I still have to use a debian "alternative" and a wrapper script? :(
[17:54] <mwhudson> radix: i'm not aware of any new stuff in that area
[17:55] <radix> ok
[17:57] <radix> it'd be really nice if bzr serve had an option for that :)
[18:30] <gthorslund> hi! is there a way in bzrlib to just check status for uncommitted changes. what I've found is http://people.canonical.com/~mwh/bzrlibapi/bzrlib.status.html#show_tree_status . so I guess it would be possible to put something on top of this, but is there a better way?
[18:47] <arthur_> Hi. I have got two separate repo 'a' and 'b'. On 'b' a 'bzr pull' from 'a' was performed at some point, long ago. Now I want to consolidate 'a' and 'b' using 'bzr join' under the same repo and it fails since there are duplicates in the inventory. Any help to work around this problem would be appreciated.
[18:49] <gthorslund> arthur_: can't you just pull all from 'a' into 'b'?
[18:49] <maxb> arthur_: Could you explain a little more about the kind of history these repositories contain? It seems very odd that you would want to 'bzr join' repositories which already share ancestry. Why is 'bzr merge' not the right tool at this point?
[18:50] <arthur_> alright. maybe I should rewind a little and listen to your suggestions. Here is the situation.
[18:50] <arthur_> I just joined a company where they currently have ~20 repositories for various services.
[18:51] <arthur_> We want to consolidate into a single repo.
[18:51] <arthur_> while keeping the history. How should I proceed?
[18:51] <dash> well, repos don't contain history so much as revisions :)
[18:52] <arthur_> dash: well. you got my point
[18:53] <maxb> arthur_: I think you should not proceed. It is natural and expected for various separate services to live in different repositories
[18:54] <arthur_> maxb: there are much more tied than you think. Think of them as interfaces and implementations rather than services.
[18:54] <maxb> So it truly makes sense for every developer who works on any of them, to work in a tree containing all of them, and to _always_ branch and tag them as a combined tree?
[18:55] <arthur_> maxb: most changes are across 3-5 services... so with the current layout it is pretty complex.
[18:56] <maxb> And the problem is that in the past, some services started as branches of other services?
[18:56] <arthur_> maxb: that's right. one of them...
[18:56] <maxb> hmm. This isn't going to be very nice :-/
[18:57] <arthur_> which prevents me from doing a join. Believe me I was pissed when the very last join failed :)
[18:57] <maxb> I cannot think of any workaround which will preserve the ability to follow all files history back to where it naturally began
[18:57] <maxb> The only workaround I can think of is to effectingly delete and re-add the entire contents of one of the trees with duplicate file-ids
[18:58] <arthur_> maybe I should do that on only the set of files that were common at the time
[18:58] <arthur_> the pull was done pretty early (revno 6)
[19:07] <lifeless> gthorslund: yes, you can layer things on top of that api
[19:07] <lifeless> gthorslund: or the status command object
[19:07] <lifeless> and there is now a hook for that too
[19:16] <gthorslund> lifeless: since cmd_status is using show_tree_status that feels like a higher level then I need. looking at show_tree_status it appears to be nothing lower level that would be useful for me, so I guess show_tree_status would be right for me then.
[19:19] <lifeless> gthorslund: depends on what you're trying to do, I guess
[19:27] <gthorslund> lifeless: I'm looking at changing revert calls in bzr-bisect with update calls instead. if there have been local changes done I kind of end up with a mess of .moved files and other. (revert just removes local changes). I refuse starting without those changes being handled some way first.
[19:27] <gthorslund> hi mtaylor!
[19:27] <lifeless> gthorslund: iter_changes is probably what you want, then.
[19:31] <gthorslund> lifeless: so http://people.canonical.com/~mwh/bzrlibapi/bzrlib.tree.InterTree.html#iter_changes would be my homework then, right?
[19:33] <lifeless> yes
[19:33] <lifeless> show_tree_status calls into this
[19:33] <lifeless> if you want a crib sheet
[19:35] <mtaylor> hi gthorslund !
[19:36] <gthorslund> mtaylor: I'm hacking some python. hope that makes you proud of me ;-)
[19:37] <gthorslund> lifeless: looks like it should give me enough of clues. thx
[19:37] <mtaylor> gthorslund: excellent
[20:01] <beuno> hi jam!
[20:01] <beuno> got a minute to help me with meliae?
[20:01] <beuno> jam, we have servers blowing up all over the place and we'd like to do some diagnosing
[20:02] <mwhudson> beuno: jam is here at uds, so might not be very responsive
[20:02] <beuno> mwhudson, well, lucky you, I hear you're quite involved in meliae as well  :)
[20:03] <mwhudson> beuno: eh, a bit
[20:03] <mwhudson> beuno: mostly a cheerleader :)
[20:03] <beuno> mwhudson, what would be your guess if we only get a partial meliae dump?
[20:04] <mwhudson> beuno: are you looking at jam's blog posts?
[20:04] <beuno> mwhudson, I am
[20:04] <mwhudson> beuno: missing a flush?
[20:05] <mwhudson> beuno: how are you invoking meliae?
[20:05] <beuno> mwhudson, this is what we have: https://pastebin.canonical.com/39038/
[20:06] <mwhudson> beuno: meliae trunk?
[20:06] <beuno> mwhudson, 0.1.3~1.CAT.8.04
[20:07] <beuno> which I presume is some sort of monster we backported to hardy
[20:07] <mwhudson> seems pretty recent
[20:07] <mwhudson> although not tagged in trunk, naughty jam
[20:09] <beuno> mwhudson, does that script look like we'd need to flush anything?
[20:09] <mwhudson> no
[20:09] <mwhudson> beuno: you get a nice 200 response back?
[20:09] <beuno> mwhudson, not really, it complains about not being able to write to "+meliae"
[20:10] <beuno> although it does write teh .json file
[20:10] <mwhudson> beuno: ??
[20:10] <beuno> mwhudson, scratch that
[20:10] <beuno> I do get a 200
[20:10] <mwhudson> beuno: i guess it's hard to say, but is the dump massively truncated or a little bit?
[20:10] <jam> mwhudson: what needs to be tagged?
[20:11] <mwhudson> jam: there's no 0.3.1 tag in lp:meliae
[20:11] <beuno> 3:23 < beuno> (ami-hardy-i386)ubunet@ip-10-122-34-239:~$ wget http://<IP_ADDRESS>:8881/+meliae --no-check-certificate
[20:11] <beuno> 13:23 < beuno> --18:23:00--  http://<IP_ADDRESS>:8881/+meliae
[20:11] <beuno> 13:23 < beuno>            => `+meliae'
[20:11] <jam> mwhudson: I don't think I did an official release, but I'm not positive
[20:11] <beuno> 13:23 < beuno> Connecting to <IP_ADDRESS>:8881... connected.
[20:11] <beuno> 13:23 < beuno> HTTP request sent, awaiting response... 200 OK
[20:11] <beuno> 13:23 < beuno> Length: unspecified [text/html]
[20:11] <beuno> but I think it's something wrong with the return
[20:11] <mwhudson> jam: oh ok
[20:11] <beuno> 13:23 < beuno> +meliae: Permission denied
[20:11] <beuno> 13:23 < beuno> Cannot write to `+meliae' (Permission denied).
[20:11] <beuno> is what I get
[20:11] <jam> mwhudson: I only have 0.3.0 here
[20:11] <beuno> mwhudson, the process is ~800mb, and the dump is 13mb
[20:11] <mwhudson> beuno: run that in a directory that you have write access to :-)
[20:11] <beuno> I'd expect a lot to be missing
[20:12] <mwhudson> or wget -O- or something
[20:12] <beuno> mwhudson, heh, of course, wget wanting to write
[20:12] <beuno> would that truncate the output file?   doesn't seem so
[20:12] <jam> beuno: dump_all_objects() is what you want to be using, and will try to find everything
[20:12] <mwhudson> it does seem unlikely
[20:13] <jam> however, being 13MB is not strictly a truncated file
[20:13] <beuno> jam, https://pastebin.canonical.com/39038/
[20:13] <beuno> well
[20:13] <jam> if you were reading and it said that there was broken content, *that* would be truncated
[20:13] <beuno> I say it's truncated because at the end there is half a line
[20:13] <jam> beuno: well, that is what I was pointing at.
[20:13] <beuno> yes, that's exacly what I get
[20:13] <beuno> :)
[20:14] <jam> so there was an issue that os.fdopen().flush() wasn't actually flushing if you used the raw FILE * pointer
[20:14] <jam> which was fixed (checking the rev)
[20:14] <jam> beuno: you have "0.1.3" that is 0.1 series, not 0.3 series
[20:14] <jam> definitely upgrade to trunk
[20:14] <beuno> aha
[20:15] <beuno> ok
[20:15] <beuno> that's a good first step
[20:15] <mwhudson> doh!
[20:15] <jam> if it is just the truncation thing, that should make a big difference
[20:16] <mwhudson> beuno: sorry for missing that :)
[20:16] <beuno> mwhudson, no worries!  this is a lot of progress!
[20:16] <jam> beuno: Flush was fixed in the 0.2.1 ish timeframe
[20:16] <beuno> thanks jam, mwhudson, I'll update the server and see what happens
[20:17] <jam> beuno: I believe mwhudson did something similar but returned the dumped content to the url rather than dumping it to disk, I'm curious why you prefer this method.
[20:18] <jam> (certainly from a remote user, it would be nice to get the raw content back.)
[20:19] <beuno> jam, I'm actually locally on the server, but what was there was this django middleware to trigger the dump
[20:53] <jam> beuno: any luck?
[20:53] <beuno> jam, just managed to get trunk on the server
[20:53] <beuno> waiting for some more tests that are going on to finish
[20:53] <beuno> and will try again
[20:54] <jam> beuno: sounds good. If you need help debugging the dump, let me know.
[20:54] <beuno> jam, will do, thanks. Hope to try again in 10-15
[20:54] <jam> you aren't in UDS, right?
[20:55] <beuno> no  :(
[20:55] <beuno> missed it this time around
[20:56] <jam> np
[20:56] <jam> would have been nice to sit over your shoulder while you worked with it
[20:56] <beuno> yeah, would of been great
[20:57] <beuno> I'll break more servers next uds you are there too
[20:57] <jam> beuno: well if necessary, there is always "screen"
[20:58] <jam> anyway, switching rooms, bbiab
[21:04] <beuno> jam, so, with the new version, they don't seem to truncate, although they do seem small
[21:05] <beuno> they are smaller than expected
[21:05] <beuno> but size may not matter after all
[21:07] <jam> beuno: if you have very large strings, we only dump 100bytes of a given string
[21:07] <abentley> jam, I am thinking that my algorithms in https://dev.launchpad.net/Code/BranchRevisions are slightly wrong, in that they assume that there is a single mainline_parent entry for each revision.
[21:07] <jam> if you have lots of small objects, then the dump is usually about the same to larger than mem
[21:08] <jam> abentley: IIRC, it could still work, you would just search multiple tips concurrently
[21:08] <jam> I'd have to look closely again, though
[21:08] <jam> beuno: there is also 'dark' memory that I've run into, which can be a lot more than I would like
[21:08] <abentley> jam, this affects "Branch page" and "Merge proposal page".
[21:08] <dash> jam: oh, that reminds me, thank you for writing meliae
[21:08] <dash> jam: it has made my life easier. :)
[21:09] <jam> zlib.decompress and zlib.compress tend to have a lot of buffers that aren't particularly accessible, for example
[21:09] <jam> dash: I'm very happy it has proven useful to you. It certainly helped me. Feedback always welcome, btw
[21:09] <dash> jam: well the only thing i'd change is the license. ;)
[21:10] <jam> dash: to?
[21:10] <abentley> jam: I worry that a given revision might not be the head of a mainline_parent_range.  Maybe the simplest thing is to accept ANY maninline_parent_range where the revision is mentioned.
[21:10] <dash> something shorter :) gplv2 or apache/mit/etc
[21:10] <jam> dash: why v2 vs v3?
[21:11] <abentley> jam: i.e. not the range table per se, but any entry in mainline_parent_range where the revision id is correct.
[21:11] <jam> (v3 is canonical policy unless there is specific reason to do otherwise, so if you have specific reasons, I'm willing to listen)
[21:11] <abentley> jam: argh, "mainline_parent"
[21:11] <dash> ah, i wasn't aware of that.
[21:11] <jam> ok
[21:12] <dash> jam: my real preference is permissive licenses, personally. it's just that gplv3 makes people in legal very nervous :)
[21:12] <dash> anyway, it's not like i'm distributing it to customers, so whatever :)
[21:13] <abentley> jam, maybe "SELECT range FROM mainline_parent_range WHERE revision = %s ORDER BY DIST DESC LIMIT 1"?
[21:13] <abentley> jam, err "SELECT range FROM mainline_parent WHERE revision = %s ORDER BY DIST DESC LIMIT 1"?
[21:14] <jam> dash: atm meliae is designed more as a helper than something you would bundle in your package, though
[21:14] <jam> so the license doesn't matter as much
[21:15] <jam> abentley: well that query doesn't require it to be the head
[21:15] <dash> jam: Sure.
[21:15] <dash> like i said, not a big deal.
[21:18] <abentley> jam, right, because there might not be an entry where it's the head.
[21:19] <abentley> jam, so this way at least you find the entry where it's closest to the head.
[22:13] <jam> beuno: any interesting insight ?
[22:13] <beuno> jam, well, not from the meliae dump
[22:13] <beuno> it seems normal
[22:13] <beuno> which is baffling
[22:13] <beuno> since we see that processes memory grow over 1gb
[22:14] <beuno> but, we found a piece of code that, when removed, stops the server from dying under a small amount of load
[22:14] <jam> beuno: 1 are you sure you are dumping while it is at its peak, 2 it could be memory fragmentation
[22:14] <jam> 3) ISTR that Thread objects take up a lot of memory, which may not be tracked
[22:14]  * beuno nods
[22:14] <jam> there are other possible hidden memory allocations
[22:14] <beuno> right
[22:15] <beuno> I am slowly getting into this part of the world
[22:15] <beuno> so no good ideas yet
[22:15] <beuno> the other problem we have
[22:15] <beuno> is we can't really reproduce it locally
[22:15] <jam> beuno: if the dump is small enough, you could bz2 it and put it somewhere and I'll give it a look
[22:15] <beuno> only on ec2 instances on staging
[22:15] <beuno> jam, sure, it's 14mb and it should shrink quite a bit
[22:16] <beuno> will email
[22:22] <beuno> jam, sent
[23:35] <mgz> jml: in case you didn't see it, I can make those SIGINT tests pass, just whether or not you think the ctypes hackery is worth it.