[08:54] <BlueT_> @schedule
[08:54] <Ubug2> Schedule for Etc/UTC: 04 Jul 20:00: Technical Board | 05 Jul 20:00: Edubuntu | 06 Jul 20:00: Ubuntu Development Team | 12 Jul 12:00: Edubuntu | 13 Jul 02:00: Ubuntu Development Team | 17 Jul 13:00: Kubuntu
[02:59] <fouadbajwa> Hi


[00:01] <Kmos> http://linux-foundation.org/weblogs/openvoices/linus-torvalds-part-i/
[00:02] <hunger> Running htop I see ~70 console-kit-daemons running... I guess that is due to htop not noticing multithreading. Isen't that a bit excessive?
[00:05] <tjaalton> slangasek: actually, there's need for one more upload.. openchrome lacks a patch to extract pci-ids in a text file, but fortunately the patch for via applies and works..
[00:15] <slangasek> tjaalton: ok.  at least it's now installable, so we can move ahead with test images :)
[00:15] <tjaalton> sure
[00:16] <tjaalton> I can put it on hold until tomorrow if needed?
[00:18] <slangasek> as long as that's the only change you're making, it doesn't sound like it would disrupt anything, and it would certainly help get better feedback from openchrome users on the alpha
[00:18] <slangasek> so please go ahead
[00:18] <tjaalton> ok, thanks
[01:54] <Sefram> why is the Gusty installer CD olny working with the pnpacpi=off option as a boot parameter on my machine?
[01:54] <Sefram> any ideas?
[01:55] <Sefram> without pnpacpi=off i get an error about 8139cp is not right for my RTL-8139C PCI network card and that i should use 8139too instead??
[01:55] <Burgundavia> Sefram: no idea, but file a bug
[01:56] <cjwatson> ... on the kernel (linux-source-2.6.22 package)
[01:57] <Sefram> what have i to regard while installing when it works only with pnpacpi=off??
[02:00] <Sefram> i got the tip from here: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/22575   seems to be an address ressoure conflict in pci address space...
[02:00] <ubotu> Launchpad bug 22575 in linux-source-2.6.15 "ISAPNP grabbing I/O region reserved for PCI device on 2.6.12  (regression from 2.6.10)" [Medium,Confirmed]
[02:01] <Sefram> Ubotu: smarty lol
[02:01] <ubotu> Sorry, I don't know anything about smarty lol - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[02:08] <calc> Hobbsee: does chrootwait go away automatically?
[02:09] <Hobbsee> calc: not necessarily
[02:10] <calc> Hobbsee: hmm can you fixup openoffice.org to retry, i think the reason it failed was due to the archive being updated when it tried to build
[02:11] <calc> unless something really did break the chroot's due to unauthenticated debs?
[02:12] <Hobbsee> calc: given back
[02:12] <calc> ok
[02:13] <calc> Hobbsee: thanks :)
[02:13]  * Hobbsee wonders what the chroot problem actually is
[02:18] <slangasek> I wouldn't be surprised if it was just a case of the mirror being in an inconsistent state due to having to futz around with the rsyncing and so forth
[02:32] <bddebian> slangasek: Hey, I have a new asc upstream in games SVN if you'd rather upload that? :)
[03:24] <_MMA_> Does the package gdm 2.20.2-1ubuntu2 include the changes from upstreams 2.20.3 release?
[03:40] <alephant> Please forgive my being slightly off-topic: How are updates to packages indicated to apt?  Is there a datastream which sez "foo-1.2 upgraded to foo-1.3"?  Or does apt simply compare the most-recent copy of the package as indicated by Packages.bz to the locally-installed package?
[04:44] <slangasek> bddebian: mutter mumble if someone would fix paragui then we could upload asc to Debian and sync it...
[04:49] <bddebian> slangasek: What's up with paragui?
[04:50] <slangasek> bddebian: it ships a .la file that has references to a crapload of other .la's that it doesn't depend on
[04:52] <bddebian> Ah the SDL "team" :)
[04:52] <slangasek> bddebian: and indeed, the asc upload FTBFS on all archs because of this, so sure, I'll take a new upstream that I can sync after
[04:52] <bddebian> Hmm, 2.0.1 didn't FTBFS on unstable for me
[04:54] <bddebian> asc 2.0.1 that is
[04:55] <slangasek> the build failures are entirely paragui's fault
[04:55] <slangasek> well - no, the latest one is my fault, because I didn't verify first that directfb-dev still ships a.la
[04:56] <StevenK> Which it doesn't
[04:58] <slangasek> yes, which is why things Broke
[05:01] <emgent> launchpad died
[05:02] <slangasek> bddebian: so where's this asc package that needs sponsorin'?
[05:02]  * bddebian does another build of asc out of curiosity
[05:02] <bddebian> slangasek: I just removed it from mentors
[05:05] <bddebian> Damnit, now it's puking trying to pull in libbz2-dev
[05:08] <bddebian> I have another issue while my pbuilder updates.  I've built a new stormbaancoureur.  However, one file (engine.tga) is rendered from a 3D model that the author purchased.  He claims he has copyright but is that possible?
[05:10] <bddebian> F**k, is libbz2-dev broken now too?
[05:11] <lifeless> bddebian: its possible and there is no way to tell; have him assert the appproporiate copyright statement and you're good
[05:12] <slangasek> bddebian: it wouldn't ftbfs on unstable because the paragui binaries in unstable were built against a good libsdl, and the ones in hardy were built against a bad libsdl
[05:13] <slangasek> libbz2-dev... broken how?
[05:13] <slangasek> installed cleanly for me
[05:13] <bddebian> uninstallable in my sid pbuilder
[05:14] <StevenK> The libsdl in Hardy is bad?
[05:17] <slangasek> not anymore
[05:17] <slangasek> all about the Timing!
[05:18] <bddebian> libparagui is in universe still?
[05:19] <slangasek> it should be somewhere else?
[05:20] <bddebian> Hmm, and 1.0 or 1.1? :)
[05:21] <slangasek> well, 1.0 is the one it's been building against, beyond that I have no idea
[05:21] <bddebian> I wonder if 2.0.1 would build against 1.1
[05:25] <bddebian> Gah wtf, libbz2-dev installs fine if I pbuilder-login
[05:31] <LaserJock> hmm, should the topic be changed for the Alpha 3 freeze?
[05:32] <bddebian> E: Failed to fetch http://ftp.debian.org/debian/pool/main/b/bzip2/libbz2-dev_1.0.4-1_i386.deb: 404 Not Found
[05:32] <bddebian> E: Unable to correct for unavailable packages
[05:32] <bddebian> gaaahh
[05:33] <slangasek> LaserJock: yes, thanks :)
[05:35] <emgent> keescook, ping
[05:35] <LaserJock> slangasek: np ;-)
[05:35] <keescook> emgent: pong
[05:36] <emgent> keescook, wordpress diff 2.1 is ready
[05:36] <keescook> emgent: cool, make a bug report for it and get it attached.  nice work.  :)
[05:37] <emgent> ok thanks :)
[05:39] <slangasek> bddebian: libparagui1.0 fixed, so where did asc go after it was removed from mentors?
[05:39] <bddebian> slangasek: I'm throwing it back on mentors as I type
[05:40] <bddebian> I can't test build in on unstable though for whatever the fsck is going on with my pbuilder. (I switched the build-deps to libparagui1.1)
[05:41] <slangasek> I'm... less likely to sponsor a package with library changes that haven't been tested
[05:41] <bddebian> Well I wanted to test it but I can't build it.  I can switch it back if we want to get it in
[05:45] <slangasek> switching it back would be good if you want me to look at sponsoring it; otherwise I can just get the already-uploaded asc given back on the buildds to take care of the bug I was after
[05:47] <bddebian> Let me switch it back.  I've been trying to get this in forever
[05:49] <bddebian> pabs3: !?
[05:49] <pabs3> hi bddebian :)
[05:50] <bddebian> Man, I can't hide anywhere anymore :)
[05:50]  * pabs3 was wondering who to contact about patches.ubuntu.com
[05:50] <pabs3> :)
[05:51] <bddebian> pabs3: lifeless suggested we might get away with the engine.tga thing in stormbaancoureur if he provides copyright.  Would you disagree?
[05:52] <pabs3> that'd be offtopic here, perhaps #debian-games is better?
[05:53] <pabs3> about patches.ubuntu.com, would it be possible to remove changelog-only patches? for eg http://patches.ubuntu.com/s/synfig/synfig_0.61.07-1build1.patch
[05:54] <bddebian> Oh, build1 versions aren't really patches, just rebuilds
[05:56] <pabs3> yeah, but they do show up on packages.qa.d.o, which can be annoying when I go to check for a patch and find it only bumps the changelog
[05:56] <bddebian> Ah yes, makes sense
[06:01] <bddebian> slangasek: http://mentors.debian.net/debian/pool/main/a/asc/asc_<IP_ADDRESS>-1.dsc
[06:22] <slangasek> bddebian: downloading gradually
[06:23] <bddebian> NP, I gotta get my old arse to bed anyhow
[06:48] <sam__> can any one guide me in streaming??
[06:50] <calc> how do i search for a file in hardy?
[06:50] <calc> there are still no contents files?
[06:51] <calc> i'm getting this error: /usr/include/mono-1.0/mono/metadata/threads.h:17:41: error: mono/metadata/threads-types.h: No such file or directory
[06:51] <calc> and need to know where that file is
[06:52] <sam__>  i am getting RTSP/1.0 461 Unsupported Transport from rtsp server ..?????
[06:52]  * calc wonders if libmono-dev is just fscking buggy
[07:00] <calc> yep mono is a just buggy
[07:01] <calc> pochu: ping
[07:01] <calc> pochu: bug 181422
[07:01] <ubotu> Launchpad bug 181422 in mono "thread-types.h is missing" [High,New] https://launchpad.net/bugs/181422
[07:10] <dholbach> good morning
[07:11] <sam__> i guess no one wanna help me ... ok..
[07:15] <torkel> sam__: wrong channel for that kind of question, try #ubuntu
[07:16] <pitti> Good morning
[07:29] <emgent> pitti, good morning :P
[07:44] <pitti> hi emgent!
[08:53] <hunger> The hardy gcc gets an ICE when building kdeedu her.
[09:16] <viviersf> is there anywhere i can get a list of all packages are used for the live cd ?
[09:16] <pochu> calc: pong, looking
[09:17] <evand> viviersf: http://cdimage.ubuntu.com/daily-live/current/hardy-desktop-i386.manifest
[09:19] <viviersf> evand, the manifest is ubuntu-desktop + live cd components
[09:19] <pitti> calc: OO.o FTBFS> "mcs not found" -> missign build dep?
[09:19] <viviersf> evand, i need a list of just the stuff thats extra, i can do it manually, i just want to see an easy way
[09:20] <pitti> viviersf: you can look at the 'ship-live' seed, but that does not include dependencies which are pulled in by those and which are not needed by ubuntu-desktop
[09:21] <viviersf> pitti, cool, is that a package ?
[09:22] <pitti> http://codebrowse.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.hardy/files
[09:23] <viviersf> thanks pitti, that will do
[09:27] <geser> good morning
[09:29] <seb128> hey geser
[09:30] <pitti> hi geser
[09:36] <coyctecm> hey guys :)
[09:38] <geser> Hi seb128, pitti
[09:57] <pochu> calc: I'm merging mono 1.2.6+dfsg-5 from Debian which fixes this (in -4):
[09:57] <pochu>    * debian/patches/fix_threads.h.dpatch:
[09:57] <pochu>      + Don't include threads-type.h in threads.h and moved functions to the
[09:57] <pochu>        correct header, fixes compiling of OpenOffice.org's Mono bridge.
[09:57] <pochu>        (taken from upstream SVN revision 91687 + 91817)
[09:59] <seb128> pitti: do you know if there is any hardy language pack upload scheduled?
[09:59] <pitti> seb128: the guys are working on it, but I haven't heard a concrete deadline
[09:59] <pitti> carlos: ?
[10:00] <carlos> pitti: let me check it with jeroen...
[10:00] <seb128> I'm wondering if we will ever have a cycle where rosetta is ready and language packs uploaded early ;-)
[10:00] <seb128> apport is all broken here for weeks now and I was waiting for translation updates before investigating
[10:02] <pitti> seb128: oh? what's wrong with apport?
[10:02] <carlos> seb128, pitti: danilo is working on a small problem that affects Slovenian translations since long time ago and that requires to be fixed before opening Hardy
[10:03] <Tonio_> hi there
[10:03] <seb128> pitti: http://people.ubuntu.com/~seb128/Capture-apport-gtk.png
[10:03] <Tonio_> is there someone here familiar with gcj/ecj packages except doko ?
[10:03] <carlos> seb128, pitti: He expects to get a script run later today that should fix the data so we are ready to start with imports
[10:03] <seb128> pitti: basically the text is invalid utf8
[10:04] <seb128> carlos: ok, thanks
[10:04] <pitti> seb128: ah, you mean the translations are broken? ok, since it works just fine here
[10:04] <seb128> carlos: happy new year btw
[10:04] <seb128> pitti: well, I was wondering if that's the translations or the code but was waiting on a language pack update before investigating
[10:04] <carlos> seb128: same for you, did you enjoy your vacations? :-)
[10:04] <seb128> carlos: yes, was nice to spend some time away from the computer ;-)
[10:05] <carlos> :-D
[10:05] <seb128> carlos: how was your honeymoon?
[10:05] <carlos> seb128: 'short'
[10:05]  * carlos hides
[10:05] <seb128> ahahah, good one ;-)
[10:05] <carlos> the only problem was when we went to Paris, we moved from 30 degrees to -2 degrees....
[10:05] <seb128> you have been lazy enough, fix rosetta now!
[10:05] <seb128> cold is better, isn't it? ;-)
[10:06] <carlos> seb128: not yet, next month, this month I'm not working in translations :-)
[10:06] <carlos> seb128: not really ;-)
[10:06] <pitti> carlos: reminds me about my transition from vacation in Nice to distro sprint in Oslo (25 -> -12 degrees)
[10:06] <carlos> wow
[10:06] <carlos> that's even worse
[10:07] <pitti> the guys at the airport to Nice wondered why I brought thick sweaters, gloves, scarf, etc :)
[10:07] <Fujitsu> Going from Australian summer (it was 42 the day I left) to -4 is quite bad, I find.
[10:27] <soren> Hm... Rhythmbox core dumps after 10.6-10.7 seconds. Every time. Very annoying.
[10:27] <seb128> soren: backtrace?
[10:27] <Fujitsu> soren: Regardless of what you've told it to do beforehand?
[10:27] <soren> Fujitsu: Yup.
[10:28] <soren> Fujitsu: Regardless of whether or not it's playing anything, too.
[10:28] <soren> seb128: I'll report it with apport in a bit.
[10:28] <seb128> good
[10:29] <Fujitsu> It works fine for me, though at one stage I did make it segfault on start every time by disabling Cover Art.
[10:29] <Fujitsu> soren: The time is seemingly arbitrary and uniform?
[10:30] <soren> Fujitsu: Yup.
[10:31] <soren> Fujitsu: Minimum observed: 0m10.652s, maximum observed: 0m10.702s.
[10:31] <soren> Fujitsu: I've done it ~10 times.
[10:31] <seb128> soren: maybe it's shocking on a file and is consistent on how long it needs to reach it
[10:32] <soren> seb128: Could be. However, with 4 GB of RAM and a not too impressive music collection, I doubt it could take as much as 10 seconds to go through it.
[10:32] <seb128> RAM doesn't really matter there
[10:32] <seb128> that's rather IOs
[10:32] <soren> seb128: WEll, if everything is cached, it does.
[10:32] <soren> ..and it is. My hard drive is idling.
[10:32] <seb128> it needs to go through the library to know if it changed
[10:32] <soren> *drives
[10:33] <seb128> weird
[10:33] <Fujitsu> soren: strace isn't useful?
[10:33] <seb128> send the bug using apport that will give us some idea about the crash ;-)
[10:33] <soren> seb128: I'm trying... It's something like /usr/share/apport/apport-gtk -c /var/crash/_usr_bin_rhythmbox.1000.crash, isn't it?
[10:34] <soren> seb128: Ah, it's just taking forever to upload, probably.
[10:34] <seb128> soren: double click on the crash in nautilus
[10:35] <seb128> soren: you should get the apport window about the crash before having it sending anything
[10:36] <pitti> seb128: apport -c will do the same, so that's fine
[10:36] <pitti> (double click is just more comfortable :) )
[10:36] <soren> seb128: It tells me I should have an up-to-date system before doing anything. I'd better obey.
[10:37] <soren> pitti: Well, except that you have to fire up nautilus and all that jazz first.
[10:37] <soren> pitti: If you happen to have nautilus open in /var/crash anyway, then yes :)
[10:37] <seb128> having a parameter to not require the uptodate system would be nice
[10:38] <seb128> I often have whatever package which doesn't matter for the backtrace not uptodate
[10:58] <pochu> calc: mono merge ready, but I'll have to wait for slomo to come back unless some else wants to volunteer :)
[11:12] <geser> pitti: should pkg_create_dbgsym honour the -X option from dh_strip?
[11:13] <geser> see bug #180364
[11:13] <ubotu> Launchpad bug 180364 in ocamlnet "ocamlrpcgen no longer works on Gutsy. Probably a wrongly stripped binary" [Undecided,New] https://launchpad.net/bugs/180364
[11:13] <pitti> geser: I don't think so, why?
[11:13] <pitti> pkg_create_dbgsym does not strip anything off the original binaries
[11:14] <geser> have you then an explanation for this bug?
[11:15] <pitti> geser: not really; I think it should be tested with a local build of ocaml, both with and without pkg-create-dbgsym installed
[11:15] <geser> in my pbuilder debian/tmp/usr/bin/ocamlrpcgen works as intended but the one from debian/libocaml-ocaml-bin (or the deb) doesn't
[11:15] <pitti> ah
[11:15] <pitti> geser: does your pbuilder have pkg-create-dbgsym installed?
[11:16] <geser> when I set NO_PKG_MANGLE or add -Nlibocaml-ocaml-bin to the dh_strip call the one from debian/libocamlnet-ocaml-bin works too
[11:16] <pitti> the only thing p-c-d does to the original binary is adding the .gnu.debuglink section so that gdb can find the separate symbol files
[11:16] <geser> pitti: it has
[11:16] <pitti> aha, then it seems it is the culprit
[11:19] <geser> so adding -Nlibocaml-ocaml-bin to the dh_strip call the right fix?
[11:19] <pitti> no, that just sounds like a workaround
[11:19] <pitti> if it works correctly without p-c-d, we should fix the latter
[11:23] <geser> I checked now where the binary breaks. Adding .gnu_debuglink breaks it.
[11:24] <pitti> ugh
[11:24] <pitti> but.. that's just an innocent extra elf section... *whine*
[11:24] <pitti> geser: ok, does 'file <original binary>' say anything special?
[11:25] <pitti> geser: or even better, can you tell that it must not be touched from the readelf -h output?
[11:25] <geser> ocamlrpcgen.working: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), not stripped
[11:25] <pitti> ok, that's not useful then
[11:26] <pitti> or an 'ocaml_bytecode' section in objdump -x or so?
[11:28] <pitti> geser: I added a p-c-d task to this bug (the ocaml task is for the no-change rebuild then) and added this question
[11:32] <geser> pitti: objcopy -R .gnu_debuglink ocamlrpcgen seems to be enough to break it
[11:33] <pitti> geser: ok, so we must not do that then
[11:33] <pitti> geser: I think the best fix is to make p-c-d not touch the binary at all if it has ocaml bytecode
[11:33] <pitti> so I just need to get a good test for that
[11:34] <pitti> something objdump -x binary | grep -q '\.ocaml_bytecode' like
[11:37] <geser> pitti: http://members.ping.de/~mb/tmp/objdump.output
[11:38] <soren> seb128: The rhythmbox bug was already reported by pochu: bug 179205
[11:38] <ubotu> Bug 179205 on http://launchpad.net/bugs/179205 is private
[11:38] <pitti> geser: thanks; I think I'll go with caml_release_bytecode
[11:39] <pitti> geser: just for final verification: objdump -x binary | grep -qw caml_release_bytecode
[11:39] <pitti> ?
[11:39] <seb128> soren: alright, and it has been fixed upstream already apparently
[11:40] <soren> seb128: Orly?
[11:40] <seb128> soren: ?
[11:40] <soren> "orly" = "oh, really"
[11:40] <soren> :)
[11:40] <seb128> soren: look at the upstream task on the bug
[11:40] <seb128> ah, ok
[11:40] <pitti> geser: is objdump -t enough?
[11:41] <soren> seb128: Oh, upstream bug of the duped lp bug. Right.
[11:42] <seb128> soren: no, of the non dupped bug (the one which is Fix Commited)
[11:42] <seb128> but right ;-)
[11:42] <geser> pitti: objdump -t ocamlrpcgen | grep -qw caml_release_bytecode exits with 0
[11:42] <soren> seb128: Er.. Um.. Yes, you seem to be right :)
[11:42] <pitti> geser: cool, thanks
[11:43] <soren> seb128: Do you intend to upload a fix or should I do it?
[11:43] <seb128> soren: you are welcome to do it since you can test the fix ;-)
[11:43] <soren> seb128: Will do. It's not in bzr or anything, is it?
[11:44] <seb128> soren: no, just grab the patch from svn, copy to debian/patches and upload
[11:44] <soren> seb128: Alright.
[11:44] <seb128> soren: http://svn.gnome.org/viewvc/ is handy to get diffs for GNOME modules
[11:48] <pitti> anyone running Kubuntu here? does "x-terminal-emulator -e dpkg -l" work, i. e. runs dpkg -l in a new terminal?
[11:49] <pitti> I'm not sure whether the KDE alternative of x-terminal-emulator correctly recognizes -e
[11:49] <pitti> xterm and gnome-terminal do
[11:51] <geser> pitti: is it intended that "objcopy -R foobar binary" modifies the binary even if the section doesn't exist? because the filesize changes from 1248876 to 269652
[11:51] <pitti> geser: I'm not sure whether it's intended, but I noticed that a thing like that gets rid of a lot of cruft
[11:51] <soren> seb128: Oh, I used the bzr import from launchpad instead. Thanks, though.
[11:52] <pitti> at least it has done that for years
[11:55] <\sh> pitti: konsole does know about -e
[11:55] <\sh> pitti:  -e <command>              Execute 'command' instead of shell
[11:55] <pochu> calc: do you need mono for alpha-3?
[11:56] <pitti> \sh: so if you do "x-terminal-emulator -e dpkg -l" it opens a Konsole window with dpkg -l output?
[11:56] <pitti> and closes it again when it's finished?)
[11:57] <\sh> pitti: well, running gnome right now so I'm on gnome-terminal, but "konsole -e dpkg -l" works like a charm
[11:57] <\sh> pitti: kde3 that is
[11:57] <Riddell> pitti: works for me
[11:57] <pitti> Riddell, \sh: great, thank you
[11:59] <\sh> mvo: pingeling...did you hear about my fatal experience when dist-upgrading from dapper to gutsy via edgy/feisty?
[12:10] <geser> pitti: thinking about the pkg_create_dbgsym bug again: does it make sense to want to add a .gnu_debuglink for binaries which aren't going to be stripped?
[12:12] <pitti> geser: not really, no
[12:13] <geser> what about passing the -X option from dh_strip to pkg_create_dbgsym to not add those links for the listed binaries as they are stripped anyway later?
[12:14] <geser> this would fix it for the ocaml problem and any further binaries which don't like to be stripped
[12:15] <geser> argh, there is a not missing in the first sentence: as they aren't stripped anyway later
[12:15] <pitti> geser: that would work, yes; we already have a flag $nodebuglink which is passed to pkg_create_dbgsym but it only gets enabled if dh_strip builds a -dbg package on its own
[12:15] <pitti> we could extend this to pass down a "don't touch" blacklist
[12:19] <mvo> \sh: no, did you file a bug?
[12:19] <jsgotangco> mvo!
[12:19] <mvo> \sh: I would be very interessted in the logs
[12:19] <mvo> hey jsgotangco
[12:23] <ogra> hmm, tasksel fails on the current daily ... known fact ?
[12:23] <ogra> ah, missing language-pack-en
[12:25] <ogra> hmm
[12:25] <\sh> mvo: there are no logs...but evms is the bug
[12:26] <ogra> weird, langauge-pack-en in on the CD
[12:26] <ogra> *is
[12:26] <ogra> i wonder why its not found
[12:26] <\sh> mvo: we used a root server from strato, dapper lts installation...and evms is installed by default, but it wasn't running...after upgrading from dapper to edgy to feisty to gutsy, our two swap spaces were not there anymore, but locked by a process, which you don't see even with lsof...
[12:27] <\sh> mvo: I was fighting with it several hours, till soren told me to remove evms from the system...after that it worked...
[12:27]  * Fujitsu got that on a number of systems, and thought the distupgrader was meant to handle that.
[12:27] <\sh> mvo: evms on dapper is still being enabled by /etc/init.d/ and now it's got enabled with udev I think...so we need to check what happens with dapper -> hardy directly...
[12:29] <mvo> \sh: could you send me the logs please (if you used the release-upgrader) - it should automatically remove evms on feisty->gutsy
[12:29] <mvo> \sh: logs in /var/log/dist-upgrade/*
[12:30] <\sh> mvo: I didn't ;) I used apt-get dist-upgrade
[12:30] <mvo> \sh: aha, ok :)
[12:30] <\sh> mvo: but I think many people dealing with debian/ubuntu on servers will not use release-upgrader ,-)
[12:32] <mvo> \sh: we have a text-frontend!
[12:32] <torkel> \sh: probably depends on if they know about it or are using apt-get dist-upgrade because they allways had
[12:32] <\sh> torkel: that's what I meant
[12:32] <mvo> \sh: I'm not a expert on the evms stuff, but afack we can not just unconditionally remove it
[12:33] <mvo> \sh: we definitely need to release note it
[12:33]  * mvo wonders if we have a expert on evms
[12:33] <Tonio_> anyone has an idea where I can download https://edge.launchpad.net/ubuntu/+source/gcj-4.2/4.2-20070707-1ubuntu2 please ?
[12:33]  * Mithrandir hides from mvo
[12:33] <\sh> mvo: if we can determine if it was in use on dapper or not .. it could help...
[12:33] <Fujitsu> mvo: Release noting and perhaps modifying Dapper's apt to screech if somebody tries to do it directly...
[12:33]  * mvo catches Mithrandir
[12:33] <Tonio_> links are dead and since now the package build-depends on itself, this version is the only one I can use to build the package on feisty
[12:33]  * Mithrandir plays dead
[12:34] <\sh> mvo: if evms is being enabled by some magic variable in /etc/default/evms or something ... we could use this info during the update
[12:35] <mvo> \sh: the release upgrader does that, it checks if evms is in use by looking into /proc/mounts and if not, removes it
[12:35] <\sh> Fujitsu: well, as canonical explained, that dist-upgrades from lts to lts is working without any problem...it's likely to happen
[12:35]  * ogra tickles Mithrandir
[12:35]  * Fujitsu stabs Mithrandir to make sure he isn't just playing dead.
[12:35] <mvo> but I don't know the details, why evms causes this trouble if it is not used
[12:35] <\sh> mvo: no other way possible outside dist-upgrader? some magic in udev to determine the state of evms?
[12:36] <mvo> Mithrandir: is there some bugreport about this to figure what the probelm is ?
[12:36] <mvo> \sh: I think if we could solve it at a package level instead of working around it in the release-upgrader, that would be the best course of action
[12:36] <Mithrandir> mvo: the problem is evms tries to grab all discs and partitions whether they're evms volumes or not.
[12:37] <geser> Tonio_: LP still has the debs; click on the package you need, open the "Published as" portlet, select the architecture you need, download the deb
[12:37] <Fujitsu> And causes much confusion when one tries to work out why only the non-LVM /boot partition won't mount.
[12:38] <Tonio_> geser: sure but I need to build this on feisty
[12:38] <Tonio_> geser: that's why I really need the source package...
[12:38] <Fujitsu> Tonio_: The broken links are a bug I filed a couple of weeks back.
[12:38]  * Fujitsu grabs links.
[12:40] <\sh> mvo, Mithrandir: I'll file a bug against emvs...(but I'm not sure if it's a bug in evms) but I wonder why evms is being used when it wasn't running at all...
[12:41] <soren> Tonio_: Eh?
[12:41] <soren> Tonio_: The source is right there on the page you linked to?
[12:42] <persia> soren: librarian doesn't have those files :(
[12:42] <Tonio_> Fujitsu: AHHHHHHHHHH, great
[12:42] <Fujitsu> persia: Librarian does have those files. kiko's code is dodgy when the packages aren't published anywhere.
[12:43] <persia> Err.  Right.  s/:($/At that location./
[12:43] <soren> persia: Oh, right.
[12:43] <soren> #  Removed from disk  on 2007-07-21.
[12:43] <Mithrandir> \sh: it's being run from the initramfs
[12:43] <Fujitsu> soren: The files are still in Librarian, just not on drescher.
[12:44] <soren> Fujitsu: You're probably right.
[12:44] <\sh> Mithrandir: hmm...more difficult
[12:47]  * soren lunches
[12:50] <geser> Tonio_: http://mirror.linux.org.mt/mirror/ubuntu/pool/main/g/gcj-4.2/gcj-4.2_4.2-20070707-1ubuntu2.dsc
[12:51] <Tonio_> geser: thanks a lot !
[13:22] <bigon> could someone makes a give-back for gossip (with libloudmouth1-dev >=1.3.3-1)
[13:23] <Mithrandir> bigon: given-back
[13:25] <geser> Mithrandir: is it safe to ask for give-backs of the packages in CHROOTWAIT?
[13:29] <Mithrandir> geser: in general, they should be given-back automatically.  Any in particular?
[13:29] <\sh> mvo / Mithrandir: bug #181491 for the evms problem
[13:29] <ubotu> Launchpad bug 181491 in evms "dapper -> edgy -> feisty -> gutsy update fails " [Undecided,New] https://launchpad.net/bugs/181491
[13:29] <geser> Mithrandir: if they are given-back automatically then I can wait
[13:38] <bigon> Mithrandir: thx
[13:54] <pitti> mvo: if I have an apt.Cache() object, is there a fast method to update it after I installed a package? (for .isInstalled) or do I need to regenerate it from scratch?
[13:57] <mvo> pitti: cache.open() should do
[13:59] <pitti> mvo: hm, that seems to take as long as generating a new apt.Cache()
[13:59] <pitti> I used c.open(None)
[14:01] <mvo> pitti: it needs to generate the binary cache after a install, it should be possible to speed it up a bit (for installs), I can look into that. you may consider showing some progress informration if that is a UI issue
[14:01] <pitti> mvo: ok; no, please don't spend any effort on this, I was just curious
[14:02] <mvo> pitti: ok :) I may still, I got a interessted idea that I would like to test
[14:12] <calc> pochu: yea there was more wrong with OOo that I uploaded than just the missing header but I ran into that while fixing it on my box
[14:13] <calc> pochu: i think it is probably too late for alpha-3 at this point :\
[14:16] <cjwatson> calc: right now, openoffice.org is uninstallable in hardy; we can't release alpha-3 with it like that
[14:16] <cjwatson> it needs to be fixed
[14:16] <cjwatson> (one way or another)
[14:18] <pitti> good morning calc
[14:19] <azeem> did Ubuntu officially evaluate the Liberation Fonts license?
[14:19] <azeem> mjg59: ^^ do you know, maybe?
[14:19] <mjg59> Not to the best of my knowledge
[14:20] <mjg59> My recollection is that it's free but GPL incompatible
[14:20] <azeem> I heard today OOo upstream added the fonts recently
[14:20] <azeem> mjg59: well, fonts don't need to be GPL compatible, do they?
[14:20] <mjg59> Only if embedded in GPLed works
[14:20] <mjg59> So, not generally
[14:20] <azeem> I had a chat with aj about it earlier, as the debian-legal thread last May immediately got hijacked by nutcases
[14:21] <calc> cjwatson: ok i can do the mono merge then upload new OOo that I have on my box
[14:21] <azeem> so there's two exceptions, one is the official FSF-recommended font exception
[14:21] <azeem> the other is some sort of anti-tivoization restriction it seems
[14:21] <cjwatson> calc: what are the changes in the new OOo?
[14:21] <mjg59> Yeah, I told the people involved I wasn't really happy with describing an additional restriction as an exception
[14:22] <mjg59> But, still
[14:22] <calc> cjwatson: very few changes mostly to deal with the way mono was split over the holidays, mono was broken over the holidays as well see bug 181422
[14:22] <ubotu> Launchpad bug 181422 in mono "thread-types.h is missing" [High,In progress] https://launchpad.net/bugs/181422
[14:22] <calc> pochu: ping
[14:22] <calc> seems pochu didn't include his merge work for mono on the bug report :\
[14:22] <azeem> mjg59: and then there is the strange IP discaimer plus "Title to the Software and any component, or to any copy, modification, or merged portion shall remain with [Red Hat]"
[14:23] <mjg59> I don't have a freedom issue with that (others might)
[14:23] <mjg59> But it's still weird and potentially unenforceable
[14:23] <mjg59> Unless it simply means "We are still copyright holders, even if you modify it", in which case, that's kind of obvious
[14:24] <broonie> But then lawyers often like pointing out the obvious.
[14:24] <calc> pochu: i need the merge where is it
[14:25] <calc> well he seems to not be here right now so i can look into remerging mono from debian
[14:25] <geser> calc: try http://emilio.pozuelo.org/~deb/mono_1.2.6+dfsg-5ubuntu1.dsc
[14:26] <calc> geser: ah great :)
[14:26] <geser> that one he asked slomo to sponsor
[14:26] <azeem> mjg59: if I read this right, they own the copyright of the changes I make, even if I don't distribute them; is that something Ubuntu thinks is alright?
[14:27] <cjwatson> calc: ok, thanks
[14:27] <ogra> cjwatson, pkgsel seems broken as well atm
[14:27] <cjwatson> ogra: what's up with it? I hadn't heard
[14:28] <ogra> i had a file not found with it ... let me reproduce (my virtualbox just crashed and took the kept error with it, somethig about pre-pkgsel.d being empty)
[14:29] <cjwatson> hmm, sounds plausible
[14:29] <calc> pochu: nevermind geser gave me the url above to sponsor :)
[14:30] <mjg59> azeem: The QPL has similar issues, but I'm not sure that's what it means
[14:30] <mjg59> azeem: It may well just be "Red Hat are still a copyright holder even if you modify it"
[14:31] <mjg59> But clarification might be nice - RH legal are friendly people, IME
[14:31] <cjwatson> ogra: odd that that would be a fatal error (rather than just syslog noise), though
[14:31] <ogra> i had a proper red screen ...
[14:31] <ogra> install stopped
[14:32] <ogra> i'm in base-install gimme 10 min
[14:32] <azeem> mjg59: do you know a good contact address for that, by chance?
[14:32] <azeem> mjg59: (I thought the QPL was an issue and was mostly ignored cause all important code is bi/tri-licensed to sane licenses)
[14:33] <mjg59> azeem: We still ship QPL-only code
[14:33] <cjwatson> ogra: I'm rsyncing a current image, but it'll be a while
[14:33] <azeem> ok
[14:33] <ogra> i'll get you the syslog
[14:33] <mjg59> azeem: Indeed, we *have* to ship Qt under the QPL as well - otherwise only GPL-compatible code can link against it
[14:33] <ogra> its easily reproducable
[14:33] <azeem> hrm, right
[14:34] <mjg59> (debian-legal seem to conveniently ignore this)
[14:34] <azeem> however, the QPL doesn't claim to be the GPL+exceptions
[14:34] <azeem> oh well
[14:35] <azeem> mjg59: anyway, thanks
[14:35] <mjg59> No problem
[14:45] <cjwatson> ogra: can I get syslog?
[14:45] <cjwatson> my rsync is at 49%, so this is probably faster
[14:45] <ogra> cjwatson, http://paste.ubuntu-nl.org/51357/
[14:45] <ogra> copying the full log to p.u.c
[14:47] <cjwatson> ogra: the tasksel failure is the real problem, I think
[14:47] <ogra> cjwatson, http://people.ubuntu.com/~ogra/syslog
[14:47] <ogra> (sorry, german)
[14:47] <cjwatson> tjaalton mentioned the same error yesterday on netboot but we didn't get into it
[14:47] <cjwatson> German is fine
[14:48] <ogra> to me it looks more like the language pack triggers it though
[14:48] <cjwatson> nah
[14:48] <cjwatson> well, probably isn't helping, but being unable to find the standard task is the real blow-up I think
[14:49] <cjwatson> the log ordering is a bit screwed but so it goes
[14:49] <cjwatson> de.archive's Task headers look ok
[14:49] <cjwatson> I wonder if the CD is screwed
[14:50] <hunger> Is there a known bug wrt. creating users? I used useradd to create one and then used it to log into gnome and all I got was a white screen.
[14:50] <ogra> i added the ltsp-client-builder udeb to the installer seed could it be that this broke anything (i didnt do anything additionally but adding it)
[14:50] <cjwatson> hunger: you should use adduser, for starters
[14:51] <cjwatson> ogra: shouldn't think so, it hasn't run yet
[14:51] <ogra> right
[14:51] <hunger> cjwatson: Aehm... right that is what I used:-)
[14:51] <ogra> its run right after pkgsel
[14:52] <ogra> (and needs preseeding to actually run)
[14:53] <hunger> cjwatson: It would be cool if only one of useradd and adduser would get installed:-)
[14:54] <cjwatson> hunger: since adduser uses useradd internally, I don't think that's likely
[14:55] <azeem> move useradd to libexec!
[14:55] <cjwatson> azeem: GNUisance ;-)
[14:56] <hunger> cjwatson: Well, it is not the user creation process that gives me a white screen:-)
[14:57] <cjwatson> right, my guess is that it only works if you're in some group or other - but that would certainly be a bug
[14:57] <cjwatson> check .xsession-errors
[14:57] <ogra> audio is a good guess i bet
[14:57] <hunger> cjwatson: I testet this by deleting all the major config files of an existing user: Now I get a white screen there, too.
[14:57] <pochu> calc: great. will you sponsor it for me? I pinged slomo about it, so if you are going to upload it let him know so you don't duplicate work :)
[14:58] <hunger> kde starts fine by the way.
[15:01] <tjaalton> pitti: I'll test the new cupsys for dapper
[15:02] <pitti> tjaalton: oh, great! thanks
[15:02] <cjwatson> ogra: ok, that's really weird, the CD's Packages file looks fine too
[15:02] <cjwatson> I wonder if this is an apt bug
[15:03] <ogra> i have the machine still here (snapshotted now)
[15:05] <cjwatson> can you chroot into /target and run 'apt-get install standard~'?
[15:05] <ogra> couldnt find package standard~
[15:05] <cjwatson> ogra: err, sorry, I mean standard^
[15:06] <ogra> ah :)
[15:06] <ogra> couldnt find package standard^
[15:06] <ogra> err
[15:06] <ogra> s/package/task
[15:07] <pochu> cjwatson: ok to upload mono 1.2.6+dfsg-5ubuntu1? (currently we have -1ubuntu1). It fixes an issue with the OOo build.
[15:08] <cjwatson> pochu: yes
[15:08] <cjwatson> ogra: does 'apt-cache show apparmor | grep Task:' show anything?
[15:09] <ogra> unable to locate package apparmor...
[15:09] <ogra> no packages found ...
[15:09] <pochu> cjwatson: thanks
[15:10] <pochu> calc: slomo will take care of the mono upload.
[15:10] <cjwatson> ogra: ...
[15:10] <ogra> looks like it doesnt find anything beyond the bootstrapped packages that are installed
[15:10] <cjwatson> my head hurts, need more coffee
[15:11] <ogra> hmm
[15:12] <cjwatson> so certainly pkgsel arranges for only the sources added by base-installer to be used at that point
[15:12] <cjwatson> (to avoid expensive downloads)
[15:12] <ogra> i cant see the cdrom if i'm chrooted
[15:12] <cjwatson> but base-installer seems to be doing the right thing, so I'm a little puzzled
[15:12] <cjwatson> oh
[15:12] <mvo> pitti: I filed bug #181518 so that we can do dapper->hardy upgrades (small patch to update-manager). this means that we need to attack the dbus restart problem soonish (before this version of u-m is accepted into dapper-proposed)
[15:12] <ubotu> Launchpad bug 181518 in update-manager "check of LTS dist upgrades" [Undecided,New] https://launchpad.net/bugs/181518
[15:12] <ogra> hmm, i can but it doesnt appear mounted
[15:13] <ogra> apt-get update moans
[15:13] <cjwatson> ogra: good call, I see the problem now
[15:13] <ogra> i see stuff in /cdrom though
[15:13] <cjwatson> it's an artifact of fjp's work to make multi-CD installs work
[15:13] <ogra> ah
[15:13] <cjwatson> and muggins here got the ordering a bit wrong when merging
[15:14] <cjwatson> I'll figure out how it's supposed to work and fix it - thanks!
[15:14] <ogra> :)
[15:19] <pitti> mvo: oh, right, that
[15:21]  * calc got mono uploaded
[15:21] <seb128> calc: <pochu> calc: slomo will take care of the mono upload.
[15:22] <calc> pochu: sorry i didn't see that since i was working on the upload, did he already do it? i needed it for the OOo i have to do in the next few minutes
[15:23] <slomo> calc: there were some things that needed changes... well, let's fix it with next upload then, nothing critical
[15:23] <calc> slomo: oh sorry about that :(
[15:25]  * calc is now doing the OOo test build with new mono
[15:37] <pitti> pochu: please use debuild -v <previous ubuntu version> when merging
[15:39] <pochu> pitti: acked (slomo just told me that :)
[15:39]  * pitti hugs pochu
[15:50]  * pochu hugs pitti back :)
[16:04] <siretart> asac: are we going to stay with network-manager 0.6.5 for hardy, or do we want to go for 0.7.x? I'm asking because I'm curious to know what to do about wpasupplicant
[16:04] <siretart> read: merge the 0.6.x branch from debian, or stay with 0.5 for hardy
[16:04] <tjaalton> I've heard that 0.7 supports modems, so n-m support for 3G would be way cool
[16:08] <asac> siretart: not sure ... we should probably start to implement the debian plugin for the system-settings and publish a preview version to get an idea about its suitability for a LTS release.
[16:08] <sladen> n-m that /worked/ would be "way cool"
[16:09] <sladen> or rather, could cope with situations where the PC is not in a state == first boot
[16:12] <seb128> what bug is that one?
[16:14] <siretart> asac: I see. well, FYI, the plan for debian is to keep tracking the 0.6 branch of wpasupplicant. need to ask mbiebl about nm
[16:15] <pitti> lool: I think our remaining avahi change (http://merges.ubuntu.com/a/avahi/avahi_0.6.22-2ubuntu1.patch) is equally relevant for Debian; WDYT, can it be merged?
[16:15] <asac> siretart: debian should ship the right nm + wpasupplicant combinatino as well imo.
[16:16] <asac> siretart: but most likely 0.7 will be ready in time for next debian stable release
[16:16] <siretart> asac: I'd assume so, right. however I haven't heard complaints from the nm maintainers there
[16:19]  * pitti looks at http://launchpadlibrarian.net/11226590/apt-show-versions_0.12ubuntu1.debdiff
[16:20] <pitti> is it just me who thinks that maintaining debian/ubuntu-patches is more effort and error-prone than just using MoM? at least for such trivial merges?
[16:21] <siretart> pitti: I think such patches are best kept in either launchpad or the debian bts
[16:22] <pitti> siretart: well, it's a patch that doesn't apply to Debian
[16:22] <pitti> but it's so trivial and obvious, and MoM does it just fine, so I think it's just unnecessary overheade
[16:22] <pitti> s/e$//
[16:22] <siretart> It might not apply, but having it around would not hurt there
[16:22] <siretart> right
[16:23] <pitti> warp10: anyway, sponsored; thanks
[16:47] <kkubasik> hey, has anyone been having problems with cairo and firefox?
[16:47] <kkubasik> http://pastebin.com/m211fcc81
[16:51] <tjaalton> could someone translate from Spanish to English: "il file con la lista dei file del pacchetto `xserver-xorg-core' contiene un filename vuoto"
[16:51] <jpatrick> that's italian
[16:51] <tjaalton> oh :)
[16:51] <tjaalton> damn me
[16:51] <jpatrick> if it was spanish, I would have gladly helped you :)
[16:52] <tjaalton> heh
[16:52] <tjaalton> I should've known
[16:55] <pitti> "the rows with the list of the rows of the package ` xserver-xorg-core' contain a filename empty" -- hmm
[16:56] <tjaalton> it's bug 181530, and doesn't make sense to me
[16:56] <ubotu> Launchpad bug 181530 in xkbset "package xkbset None [modified: /var/lib/dpkg/info/xkbset.list] failed to install/upgrade: il file con la lista dei file del pacchetto `xserver-xorg-core' contiene un filename vuoto" [Undecided,New] https://launchpad.net/bugs/181530
[16:56] <tjaalton> at least there is no file conflict
[16:57] <pitti> tjaalton: maybe the /var/lib/dpkg/info/xkbset.list is empty?
[16:57] <tjaalton> disk full?
[16:58] <pitti> possibly
[16:58] <warp10> pitti: sorry for late response, was away. I tought it was trivial and obvious indeed, but maybe it could be useful someway, so I updated it :)
[16:59] <pitti> msgid "files list file for package `%.250s' contains empty filename"
[16:59] <pitti> tjaalton: ^ grabbed from italian dpkg.po
[17:00]  * pitti pats his unpacked langpack tree for grepping for translations
[17:00] <slangasek> pitti: "the row" is "la fila", not "il file" :)
[17:01] <seb128> pitti: can you look in this unpack tree if the french apport translation is valid utf8? ;-)
[17:01] <pitti> slangasek: good morning
[17:01] <slangasek> morning
[17:01] <pitti> slangasek: that was just babelfish; my own Italian is a magnitude worse :)
[17:01] <pitti> seb128: rookery:/srv/language-packs.ubuntu.com/gutsy-proposed/sources-base/
[17:02] <seb128> pitti: danke
[17:02] <pitti> seb128: I can look for you in a bit, off to dinner
[17:02]  * seb128 learns every day thanks to pitti ;-)
[17:02] <seb128> pitti: no, I'll manage, thanks
[17:02] <seb128> *hug*
[17:03] <slangasek> pitti: no, I think your own italian would only be a magnitude slower, I don't think it's possible to be a magnitude worse ;)
[17:04] <_MMA_> seb128: Does the package gdm 2.20.2-1ubuntu2 (hardy)  include the changes from upstreams 2.20.3 release?
[17:05] <tjaalton> pitti: thanks, weird
[17:05] <seb128> _MMA_: no, but I'll upload 2.20.3 after the freeze
[17:05] <seb128> _MMA_: why?
[17:06] <_MMA_> Ahh... Killer. Im looking to see that bug where you can set the background color go away.
[17:06] <seb128> _MMA_: it's supposed to be fixed in 2.20.3
[17:06] <seb128> _MMA_: it can probably wait an extra day ;-)
[17:07] <_MMA_> Oh sure. Just a visual eye-sore when Ubuntu Studio has it set to black but it comes up light brown.
[17:17] <hunger> Is there a way to not start compiz? I think my white-screen-when-using-gnome problem is compiz related.
[17:19] <ogra> hunger set /desktop/gnome/applications/window_manager/current and default to metacity
[17:19] <ogra> (gconf keys)
[17:20] <hunger> ogra: Thanks!
[17:21]  * hunger wonders where the config file with those keys is hidden.
[17:21] <hunger> Sorry, I'm a kde person:-)
[17:35] <hunger> That indeed helps. I can log back into gnome again.
[17:42] <sladen> full disk?
[17:45]  * pitti hugs seb128 back
[18:00] <pochu> will the hardy cds ship any translation packages? specifically the spanish ones?
[18:01] <seb128> pochu: depending of the CD space
[18:02] <seb128> pochu: not easy to say now
[18:02] <pochu> Right. And do you know whether Gutsy shipped any?
[18:02] <seb128> gutsy shipped some, dunno the exact list, cjwatson or pitti most likely know
[18:03] <pochu> maybe the ones in http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.gutsy/live ?
[18:03] <seb128> pochu: right
[18:04] <pochu> thank you seb128
[18:04] <seb128> you are welcome
[18:11] <pitti> asac: the history substring search in ffox3 is the best thing since slice bread!
[18:14] <seb128> maybe I should give firefox3 a try just to see what it looks like ;-)
[18:14] <asac> yeah ;) ... I agree that it rocks!
[18:15] <cjwatson> it's nice, except that if your mouse happens to be hovering over the area occupied by the substring search results pop-down, it's impossible to type just the substring and not select whatever it was that the mouse is hovering over
[18:15] <cjwatson> i.e. pressing Enter in the URL bar prefers to select the thing being hovered over by the mouse rather than whatever you typed in the URL bar
[18:16] <asac> good catch. haven't noticed before
[18:18] <cjwatson> do you want a bug?
[18:18]  * cjwatson blinks at bug 180525
[18:18] <ubotu> Launchpad bug 180525 in firefox-3.0 "firefox-3.0 pornlib resizes images into works of abstract art" [Undecided,New] https://launchpad.net/bugs/180525
[18:19] <slangasek> "oh, /cubic/ interpolation, I thought you said /cubist/ interpolation"
[18:21] <asac> cjwatson: yes, please open a bug
[18:22] <asac> didn't find an upstream duplicate on first attempt, but will have to check again later. bugzilla is sometimes hard to use :/
[18:22] <seb128> bugzilla rocks ;-)
[18:29] <cjwatson> asac: OK, I hope bug 181575 is a comprehensible description. I found it quite hard to describe clearly
[18:29] <ubotu> Launchpad bug 181575 in firefox-3.0 "pressing Enter in URL bar selects mouse hover target in substring-search pop-down" [Undecided,New] https://launchpad.net/bugs/181575
[18:29]  * asac looking
[18:30] <asac> cjwatson: thats fine. thanks
[19:07] <slangasek> tjaalton: is there any chance that your latest openchrome changes could have negatively affected a Radeon chip?
[19:08] <slangasek> tjaalton: Riddell is reporting (informally) that alpha3 X is screwed up on this chip: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon IGP 330M/340M/350M
[19:10] <tjaalton> slangasek: Xorg.0.log would help
[19:11] <tjaalton> sounds strange enough :)
[19:11] <slangasek> yeah
[19:11] <slangasek> will have to wait for Riddell to resurface then, I guess
[19:12] <slangasek> what little other information there is is here: http://iso.qa.ubuntu.com/qatracker/result/1210/50
[19:12] <slangasek> bryce: unless you happen to have access to something with that chipset and could verify?
[19:13] <bryce> heya
[19:13] <bryce> hmm, I just have one ATI based system
[19:13] <tjaalton> there are reports that ati 6.7.197 has had regressions
[19:13] <bryce> wait, no two.
[19:14] <bryce> I think one is an R350, lemme check
[19:14] <tjaalton> you lucky b.. :)
[19:14] <bryce> my fiance is thankfully tolerant of my computeraholic issues
[19:16] <bryce>  Radeon R350 [Radeon 9800 Pro]
[19:17] <bryce> unfortunately this system isn't on Hardy
[19:17] <seb128> 01:00.1 Display controller: ATI Technologies Inc RV350 AP [Radeon 9600] (Secondary)
[19:17] <seb128> that's my desktop and it's running hardy
[19:18] <seb128> 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AP [Radeon 9600] (prog-if 00 [VGA controller])
[19:18] <seb128> and it works fine with the current ati driver
[19:19] <tjaalton> riddell has a laptop apparently
[19:20] <tjaalton> slangasek: there's a newer driver on wiki.u.c/XorgOnTheEdge
[19:20] <bryce> is there a LP# for riddell's bug?
[19:21] <tjaalton> I would've noticed it :)
[19:25] <bryce> my other -ati is X600
[19:30] <claude> stgraber: ping
[19:31] <claude> stgraber: stop talking, please
[19:33] <stgraber> claude: :)
[19:44] <slangasek> bryce: no LP#, no; he seems to have taken off ill before he could get to that point
[19:45] <slangasek> the problem was reported with the LiveCD; I suppose that shouldn't make a difference, but
[19:46] <bryce> ok, I'll cut a CD and give it a go
[20:09] <sabdfl> Riddell: thanks for taking care of the geoip sync
[20:10] <tjaalton> bryce, slangasek: the ati bug is likely bug 180343
[20:10] <ubotu> Launchpad bug 180343 in xserver-xorg-video-ati "ATI driver update causes Display Corruption" [Undecided,New] https://launchpad.net/bugs/180343
[20:10] <bryce> thanks
[20:11] <slangasek> tjaalton: great, thanks
[20:11] <slangasek> Riddell: ^^
[20:11] <bryce> (cd's about halfway burned; will test it after lunch.  bbiab)
[20:17] <tjaalton> bryce: I'll ask alex about that bug
[20:26] <tjaalton> bryce: ok, I'll compile git master, and ask people to test that
[20:48] <bryce> booting, bbiaw
[21:04] <tjaalton> slangasek: new driver attached to the bug, waiting for test results
[21:06] <slangasek> tjaalton: cheers
[21:08] <bryce> slangasek: kubuntu booted up just fine on my R350
[21:08] <bryce> I did find one issue though, but it's unrelated
[21:09] <bryce> so perhaps the issue Riddell ran into was specific to his R350M?
[21:10] <Riddell> sabdfl: welcome
[21:10] <Riddell> bryce: wouldn't surprise me, this laptop is full of odd hardware bits
[21:10] <tjaalton> bryce: actually that's RS200M
[21:10] <tjaalton> Riddell: please try the driver from bug 180343
[21:10] <ubotu> Launchpad bug 180343 in xserver-xorg-video-ati "ATI driver update causes Display Corruption on Radeon IGP 330M/340M/350 " [High,Confirmed] https://launchpad.net/bugs/180343
[21:13] <bryce> Riddell, slangasek:  I ran into this issue when trying to access the monitor config admin tool:  http://people.ubuntu.com/~bryce/tmp/snapshot1.png
[21:13] <Riddell> tjaalton: the radeon_drv.so file attached there seems to work ok
[21:13] <tjaalton> wohoo!
[21:13] <bryce> :-)
[21:13] <slangasek> bryce: hrm, curious
[21:14] <Riddell> bryce: yeah, known issue, I've not had a chance to look at it
[21:14] <bryce> okie
[21:14] <bryce> yeah, figured as much
[21:37] <tjaalton> ok, I've got the commit that fixes this ati issue ()
[21:37] <tjaalton> RADEON: Make sure all old IGP chips have HasSingleDac set
[21:37] <tjaalton> duh
[22:19] <tjaalton> slangasek: should I roll an update with that patch?
[22:22] <slangasek> tjaalton: sounds good.  Not sure I'll reroll images for it, but if it lands in good time, it'd be nice to have
[22:23] <tjaalton> ok
[22:24] <slangasek> and if it doesn't land, and least we've got good info to put in the release notes :)
[22:24] <tjaalton> yeah :)
[23:00] <phomes> is there a reason for that gnome-games is stuck at 2.20.1 for gutsy? (and <IP_ADDRESS> for hardy btw) We are getting a ton of crasher reports that should be fixed from these old versions


[07:10] <lotuspsychje> good morning to all
[07:10] <lotuspsychje> Bashing-om: staying up late mate?
[07:12] <Bashing-om> lotuspsychje: Just a tad . A few loose ends to make sure are bound . On my way out soonest :)
[07:13] <lotuspsychje> :p
[07:17] <lotuspsychje> !info linux-image-generic artful
[07:54] <Bashing-om> lotuspsychje: ; all . Packing it in . Off to bed . What I have going on will run overnight :) \o
[07:54] <lotuspsychje> okay mate have a nice1
[07:55] <lotuspsychje> !info lollipop
[07:55] <Bashing-om> away .
[08:06] <lotuspsychje> !info lollypop
[13:24] <BluesKaj> Hiyas all
[14:27] <daftykins> BluesKaj: hi hi \o
[15:03] <BluesKaj> hey daftykins, how goes it?
[15:04] <daftykins> BluesKaj: all good here thanks :) bit more painting going on - http://i.imgur.com/kLDaNw1.jpg all well for you?
[15:08] <BluesKaj> yup, just ordered  a 3pak of molex to sata power cable/connectors for an extra hdd I'm hooking up. It's a windows drive, but I have keep my hand in and up to date (sort of) because my windows user friends rely on me
[15:09] <daftykins> :)
[15:15] <BluesKaj> they're techie enough with their musical instrument equipment/guitar amps etc,  but have little interest about their pcs
[15:15] <daftykins> so often the way
[15:20] <BluesKaj> your cat spotted something interesting , wonder what it was ...every moving thing looks like prey to most cats :-)
[15:22] <daftykins> :D
[17:41] <immu> yo all
[17:42] <daftykins> o/
[17:45] <immu> hey daftykins whats up? where are others?
[17:49] <BluesKaj> immu, check the nicklist , but most are lurkers
[17:52] <immu> hey BluesKaj hows your kdesystem
[17:52]  * Bashing-om back on duty :)
[17:52] <BluesKaj> hey Bashing-om
[17:52] <BluesKaj> running fine immu
[17:53] <Bashing-om> BluesKaj: \0 See that you have been kept occupied :)
[17:54] <BluesKaj> yeah , a few misunderstandings due language barriers I'm afraid
[17:54] <BluesKaj> due to
[17:55] <BluesKaj> and also ommitted important info, as usual :-)
[17:56] <Bashing-om> BluesKaj: Yeah - that too is my most difficult hurdle to overcome . My comminications skills still reek .
[17:58] <BluesKaj> Bashing-om, usually it's questioner who omits the needed info , and usually it's not mentioned until we're already gone in the wrong direction
[17:59] <oerheks> .. last minute information change, luv' those trolls..
[18:00] <BluesKaj> I've given up the sata to usb guy , his story keeps changing
[18:00] <oerheks> and in the end they fixed it themselves :-D
[18:01] <BluesKaj> or finally ask the right question in another forum
[18:01] <immu> how many days left for 17.10 release :)
[18:02] <oerheks> 70 days or so?
[18:02] <oerheks> https://wiki.ubuntu.com/ArtfulAardvark/ReleaseSchedule
[18:21] <immu> oerheks, thats no fun, more in asking like real humans do :)
[18:23] <daftykins> immu: not much, been painting today
[18:36] <immu> is your painting done, daftykins ?
[18:37] <daftykins> nah, much much more to do
[18:37] <daftykins> there'll be spots that couldn't be done when the scaffolding comes down, too
[19:14] <immu> okie
[21:18] <Bashing-om> !mint
[21:20] <oerheks> !chocolate
[21:20] <oerheks> oh
[21:29]  * Bashing-om just lazy - but chocolate chip cookies all around .
[21:30] <daftykins> !cookie | everyone
[21:30] <daftykins> ;D


[00:19] <mkanat> poolie: Guessing based on RHEL4 -> RHEL5, I'd guess that RHEL5 will stay relevant for about a year and a half.
[00:20] <poolie> hi there
[00:20] <poolie> ok
[00:21] <poolie> iow roughly the same timeline, or perhaps a bit later than we may need to support 3.x
[00:37] <mkanat> poolie: Yeah, and RHEL6 has 2.6.5.
[00:37] <mkanat> poolie: So, I imagine you're still catching up from vacation and all. Will you be able to take a look at the loggerhead work at any point?
[00:37] <poolie> oh, hi
[00:39] <poolie> wow, nine reviews
[00:39] <poolie> mkanat, you should ask jam too, as he's patch pilot this week
[00:39] <mkanat> poolie: Okay.
[00:42] <poolie> hi spiv!
[00:42] <spiv> Hi :)
[00:44] <poolie> welcome back
[00:46] <mkanat> poolie: The specific review that I'm waiting on is https://code.launchpad.net/~mkanat/loggerhead/raw-prefix/+merge/44682
[00:46] <poolie> yeah, just reading it
[00:47] <mkanat> poolie: Okay. :-)
[00:47] <poolie> to be precise, i'm just asking for a second review from someone who's handled this issue elsewhere
[00:47] <poolie> it looks good to me
[00:47] <mkanat> poolie: Okay.
[00:47] <mkanat> poolie: I've also handle this issue elsewhere, FWIW.
[00:47] <mkanat> *handled
[00:48] <mkanat> poolie: How does authentication work for loggerhead for private branches on launchpad, do you know?
[00:48] <mkanat> poolie: The LP version of this may need some special magic.
[00:49] <poolie> i know you're familiar with it
[00:49] <poolie> s/it/xss elsewhere
[00:49] <poolie> i don't know much about how it works in detail
[00:50] <mkanat> Not just XSS, but almost this specific issue, of serving untrusted content.
[00:50] <poolie> we had a big internal thread about xss in general, so i just thought i'd let those people comment if they want to
[00:50] <mkanat> Okay. :-)
[00:50] <poolie> you're right it may need to be updated if this is deployed
[01:04] <poolie> mkanat, i replied
[01:05] <poolie> can i help with anything else?
[01:07] <mkanat> poolie: Awesome, thanks. That should be it for now.
[01:57] <lifeless> mkanat: private branches have oauth triggered
[01:57] <mkanat> lifeless: All right. And how is that persisted?
[01:57] <lifeless> mkanat: well, not oauth, but auth in general
[01:57] <mkanat> lifeless: Like HTTP Auth?
[01:57] <lifeless> mkanat: cookies. It seems to be pretty bustified just now.
[01:57] <mkanat> lifeless: Okay.
[01:57] <mkanat> We'll have to do something special for that, then.
[01:58] <lifeless> I'd just use the timelimitedtoken table
[01:58] <lifeless> its meant to be pretty generic
[01:58] <mkanat> Is that in LP?
[01:58] <lifeless> yes
[01:59] <mkanat> Okay. Yeah, that's what I'd use. I don't think codebrowse has access to that, though, no? Or I'd just get one via the API?
[01:59] <lifeless> the way it works is this:
[01:59] <lifeless>  - we advertise a url on the appservers
[01:59] <lifeless>  - requests to said url:
[01:59] <lifeless>     - add a token
[02:00] <poolie> lifeless, do you mean you give a positive or a negative value to the manual "feed to pqm" step?
[02:00] <lifeless>     - generate a redirect to the content-domain with the token as a query parameter
[02:00] <lifeless> poolie: manually feeding allows user control and approval-before-landing.
[02:01] <poolie> because you can say status=approved, comment='approved conditional on fixing X'?
[02:01] <lifeless> mkanat: the 'content-domain' is a wild-card domain so that no user supplied content can attack each other or lp cookies.
[02:01] <lifeless> poolie: yes
[02:01] <poolie> is that any better than saying status=needreview, vote=approved, comment='ok to land when you do x'?
[02:01] <lifeless> poolie: yes, in several ways
[02:02] <lifeless> poolie: firstly the approver is the reviewer not the lander; secondly the mp gets out of the to-review queue.
[02:02] <mkanat> lifeless: But loggerhead is not a part of launchpad, so I'm not quite sure what you're advising me to do.
[02:02] <lifeless> mkanat: the one deployed at bazaar.launchpad.net is
[02:02] <lifeless> mkanat: its an appserver in the general sense
[02:03] <mkanat> lifeless: Okay.
[02:03] <mkanat> lifeless: And so it can use the LP APIs and so forth and generate a token?
[02:03] <lifeless> we may need more api glue etc to let loggerhead issue a token, but thats doable.
[02:04] <mkanat> lifeless: Okay. I've already got the domain system in place in loggerhead itself.
[02:04] <mkanat> lifeless: I just need to check and validate a token for private branches.
[02:04] <lifeless> mkanat: so each branch gets its own domain ?
[02:05] <mkanat> lifeless: Yeah.
[02:05] <lifeless> kk
[02:07] <poolie> so, getting it out of the queue, if you want, is equally well accomplished by setting it to wip
[02:07] <poolie> i don't see how the identity of the approver makes the process less blocking
[02:08] <lifeless> you asked how it was better
[02:09] <poolie> is this better?
[02:09] <poolie> on the one hand you have
[02:09] <poolie> A says "I'm marking the approved (but not really approved)"
[02:09] <lifeless> thats not what I'm saying
[02:09] <poolie> and in the other case, B says "I'm marking this approved because A said it was ok when I did X and I've now done it"
[02:10] <lifeless> I'm saying 'approved but consider X or Y'
[02:10] <lifeless> which is approved
[02:10] <lifeless> but maybe not time to land it
[02:10] <poolie> ah, so not conditionally approved, but
[02:10] <poolie> approved, with comments
[02:10] <mkanat> lifeless: Where in the API would I look to generate myself a token?
[02:10] <lifeless> mkanat: tokens aren't exposed in the API yet
[02:10] <lifeless> mkanat: this is the glue needed that I mentioned
[02:10] <mkanat> lifeless: Ahh, okay.
[02:11] <lifeless> would you care to file a bug requesting the ability to hand out tokens ?
[02:12] <spiv> poolie: marking as vote: approve, status: WIP also tends to hide a branch, whereas currently +activereviews gives a fairly good indication of branches that are close to landing.
[02:12] <mkanat> lifeless: Sure.
[02:12] <lifeless> mkanat: thanks!
[02:12] <poolie> spiv, true, but...
[02:12] <spiv> I think that's more an issue with Launchpad than PQM vs. Tarmac though.
[02:13] <poolie> i think the ui is just lacking a bucket for "needs piloting, not review per se"
[02:13] <poolie> right
[02:13] <lifeless> I think it would be nice for a reviewer to be able to land something trivially
[02:14] <lifeless> I don't like the idea of being unable to clearly say 'this is ok now' without causing it to land.
[02:14] <poolie> agree on both points
[02:14] <lifeless> landing, like deploying, is something I think human action on adds value
[02:14] <poolie> and vote=approve, status=unchanged doesn't quite feel like it captures the second
[02:15] <mkanat> lifeless: https://bugs.launchpad.net/launchpad/+bug/697485
[02:15] <poolie> it's close, but there's a distinction between "my opinion is this is ok" and "i'm concluding the discussion: this is ok"
[02:15] <poolie> istm the real fix for that is either adding a 'queued' state, or a 'merge' button
[02:15] <poolie> and/or perhaps revisiting the relation between votes and states
[02:16] <lifeless> the queued state has been ripped out
[02:16] <lifeless> a new implementation is ticking along slowly AIUI
[02:16] <poolie> right
[02:16] <poolie> i think going to tarmac is a step towards this?
[02:16] <poolie> for example, it would make it more rewarding for me, or spiv, or whoever, to add a queue db and ui to launchpad
[02:17] <lifeless> I think putting the new implementation in is a step torwards having tarmac
[02:17] <lifeless> anyhow, I was simply expressing an opinion
[02:17] <lifeless> I doubt I'll be landing anything in bzr in the short term
[02:18] <poolie> i'm glad you read it
[02:18] <poolie> and i appreciate your opinion
[02:19] <spiv> Is it easy to teach tarmac to look for a comment saying "tarmac: ok" or something, not just checking the status?  That might work around the conflation of status==approved and "robot should merge it" that lifeless is talking about.
[02:19] <lifeless> there are plugins to do that AIUI
[02:20] <lifeless> that sort of thing anyhow
[02:28] <lifeless> mkanat: I've triaged it to high
[02:28] <mkanat> lifeless: Awesome, thank you.
[02:29] <lifeless> mkanat: in the new work structure we'll have two teams working on high bugs, it will get got to within a year :(
[02:29] <mkanat> lifeless: Hahaha, wow, okay.
[02:29] <lifeless> we have a massive backlog we're trying to sort out
[02:29] <mkanat> poolie: That will limit the rollout of /raw/ on LP ^^^^^^^^^^^^^^
[02:29] <lifeless> there are a few options
[02:30] <mkanat> I could just deny access to /raw/ on private branches until it's ready.
[02:30] <lifeless> if there are stakeholder requests for this, we can make it semi-first-among-equals
[02:30] <lifeless> mkanat could do the patch to lp
[02:30] <lifeless> we can let the teams know its there and see if anyone cherry picks it as an interesting thing within the high bucket.
[02:30] <mkanat> lifeless: I'd be happy to write the patch, but that would revolve around contracting emails.
[02:30] <mkanat> *details
[02:30] <mkanat> (Not emails.)
[02:33] <lifeless> yeah
[02:33] <lifeless> I realise that
[02:33] <lifeless> what I've done is all I can sensibly within our current constraints
[02:33] <mkanat> lifeless: Yeah, I know. :-) I appreciate it. :-)
[02:43] <mathrick> btw, has anyone in position to fix it noticed the saily PPA build failures with bzr-svn?
[02:43] <mathrick> *daily
[03:16] <poolie> mkanat, i guess if you just merge all your stuff to one branch suitable for use on lp that would be good for now
[05:25] <mkanat> poolie: Okay.
[08:12] <vila> hi all !
[08:23]  * fullermd waves at vila.
[08:23] <vila> _o/
[08:25] <fullermd> Seems like a year has passed since last I saw you around   ;p
[08:27] <poolie> hi vila
[08:27] <poolie> i'm going now though
[08:28] <vila> poolie: take care !
[08:28] <vila> fullermd: same here, on the other hand, that's one less before we can just relax and enjoy the show :D
[08:29] <vila> . o O (Nothing beats black humor to start the day... )
[08:29] <fullermd> Wait.  There's going to be a time when we can relax?
[08:29] <vila> hmm, I hope "black humor" has the same meaning in English than in French...
[08:29] <vila> Oh yes we can !   I took out a good half dozen before I realized how futile it was...
[08:32] <vila> nah, you got it all wrong, ghosts CAN trigger bugs, it only works one way... Think about the potential for fun..
[08:32] <fullermd> Oh, I know; we already have a bunch of those files I think  :p
[08:34] <fullermd> And filed, too.
[08:35] <vila> see ?
[08:35] <vila> :D
[08:36] <vila> Now think about looking at those poor souls running in circles searching for a way to reproduce these oh-so-funny bugs :)
[08:36] <vila> decades of fun !
[08:36] <vila> not mentioning leaks (of all kinds :)
[08:37] <fullermd> But you can't even let anybody know.  Launchpad logins don't work from the afterlife.  You'll have to file a bug about tha.... crud.
[08:39] <vila> really ? I thought 'ether' in ethernet was afterlife related...
[08:40] <vila> Otherwise, I'm sure that with all these new wireless protocols...
[08:41] <fullermd> I think it means that trying to debug problems in ethernet makes you drowsy.
[08:43] <vila> right, this just means the latency increases, shouldn't be too hard to address
[08:44] <fullermd> Heaven has too many dropped packets, and hell has hellacious latency.
[08:50] <vila> tsk, heaven, you're sooo optimisitic...
[08:52] <fullermd> What, with this angelic face?  Where else would I end up?
[08:52] <vila> ;)
[08:53] <fullermd> Alrighty, I just blew an hour sorting video clips.  Must be time for bed.
[08:54] <vila> bed ?
[08:56] <fullermd> Yeah, it's this thing that's sorta like sitting in front of the computer, except with less fans and more horizontality.
[09:21] <xanalogica> sleep is a poor substitute for caffeine.
[10:54] <matkor> Hi ! How can I resolve this:   Conflict adding file foo.OTHER.  Moved existing file to foo.OTHER.moved.
[10:54] <matkor> I just want current version of foo to be commited.
[10:56] <matkor> bzr resolve foo gives: foo is not conflicted
[10:57] <matkor> argh
[10:57] <quicksilver> bzr rm foo.OTHER.moved
[10:57] <quicksilver> bzr resolve foo.OTHER.moved
[10:57] <quicksilver> but having .OTHER files hanging around sounds broken to me
[10:57] <quicksilver> sounds like someone accidentally added some conflict files
[11:09] <vila> matkor: quicksilver is right, you were already in trouble with foo.OTHER already present (that's the one in conflict now by the way, not foo, foo *was* in conflict somehow in the past)
[11:11] <matkor> quicksilver, vila. Ah great thanks.
[14:21] <bialix> heya
[14:21]  * bialix looking for jam
[14:21] <bialix> who can help me with lp:bzr-merge-into plugin?
[14:21] <bialix> it refuses to work for me
[14:27] <maxb> Isn't that the one which was never updated to work with 2a?
[14:29] <bialix> I'm using pre-2a formats
[14:29] <bialix> but maybe it does not work with new bzr
[14:29] <bialix> maxb: thanks
[14:31] <bialix> it's not big deal to do everything manually
[14:56] <catphish> g'day
[16:31] <psusi> one thing that annoys me about bzr is that when you look at a merge commit, it shows a bunch of modifications as if you did them, instead of them coming in because of the merge.  Is there a way to fix that?
[16:36] <maxb> It's not clear what you mean. To me, the fact that the commit is a merge commit fully explains that the changes it introduced involved a merge
[16:43] <rjek> It documents who did the merge, and no information about the constituant changes is lost.  I see no problem.
[16:43] <glyph> psusi: Yeah, I can't see what you mean by that either.  It definitely does not look like "you did them"; there are fields in the metadata for each revision describing the author and committer, and you can look to see who did the changes.
[17:04] <psusi> glyph: see http://bazaar.launchpad.net/~psusi/ubuntu/natty/e2fsprogs/merge/revision/45
[17:04] <psusi> it shows files added, removed, and modified
[17:04] <psusi> but I didn't touch them
[17:05] <psusi> the only file I touched was debian/changelog
[17:08] <maxb> psusi: But, you performed a merge which caused all those files to be modified in that branch
[17:08] <psusi> sure, but I did not modify them in that commit
[17:09] <maxb> That's a very fine semantic difference, which starts to break down as soon as any amount of intra-file merging occurs
[17:10] <psusi> git understands the difference and the diff only shows parts you had to modify to complete the merge... the fact that the upstream branch modified a bunch of files is covered by the commits in the upstream branch history, not by the merge commit
[17:11] <maxb> How do you ask git for such a diff?
[17:11] <psusi> git log -p or --stat
[17:13] <psusi> only any parts YOU actually changed are shown... changes pulled in by the merge are not... which makes sense since they are already documented in other commits
[17:14] <glyph> There's something to be said for that
[17:14] <glyph> my understanding is that git immediately commits the merge, conflict markers and all
[17:14] <glyph> and then you effectively have to merge again once you've sorted out the mess
[17:14] <psusi> no... you commit once you have sorted out any conflicts
[17:14] <jamey_uk> My boss is thinking of switching us from svn to git, but I think git looks overly-complex (no experience with it yet). I like bzr; would git be a pain and is bzr a lot less hassle?
[17:14] <glyph> jamey_uk: _I_ think so :)
[17:15] <psusi> but if there were no conflicts, then the log shows no files modified, and the diff is empty
[17:15] <glyph> jamey_uk: #git might have a different idea
[17:15] <jamey_uk> yeah, going to have to ask in there in a second :)
[17:15] <glyph> psusi: sounds like an interesting feature.  bzr could probably have a logging mode where it did that by examining diffs.
[17:16] <psusi> jamey_uk: bzr seems to aim more at being user friendly/easier to understand... I've been using both lately and for the most part, find them equivalent... but there's a few things, like this issue, that I prefer about git
[17:18] <jamey_uk> why is it better that it commits immediately in this case?
[17:18] <psusi> the other day I was very thrilled with git because I found a commit in linus's kernel tree and was describing to an ubuntu developer that it obsoletes a patch they had been carrying.  Within seconds I was able to point him to the commit so he could review it, and ask git to verify what upstream release it made it into, and that it was present in the Ubuntu tree
[17:19] <psusi> jamey_uk: it doesn't... what I like better about merges in git is that it doesn't make all of the ( possibly hundreds ) of changes you are merging appear to be one massive patch applied by the merge
[17:20] <jamey_uk> well, merging is a new concept for me to be honest... so this is going slightly above my head
[17:21] <jamey_uk> so when you do a large merge with bzr it does it all as one patch, and git does lots of small patches?
[17:22] <mgz> no.
[17:22] <mgz> what psusi is on about sounds like a ui nitpick to me, unless what glyph said is right (which it may be)
[17:23] <mgz> merging in any dvcs is a way of preserving the individual changes in another branch without flattening them into one big patch
[17:26] <jamey_uk> I'm trying to join #git to get opinion from the other side but FreeNode is telling me: "#git :Cannot join channel (+r) - you need to be identified with services". Yet I registered recently and I am identified :/
[17:32] <mgz> jamey_uk: any luck yet? try #freenode if not.
[17:33] <jamey_uk> mgz, yeah no luck, going to ask in #freenode now, thanks
[17:33] <maxb> psusi: I don't suppose you know *how* git calculates what to display in that case? I'm having trouble thinking of any way it can separate the two concepts without an intermediate commit.
[17:33] <mgz> well, I guess that's at least one thing bzr has going for it. "Can join IRC channel"
[17:34] <jamey_uk> :D
[17:43] <mgz> jamey_uk: quite a few people actually use bzr clients against svn servers at their work, so there's a fair bit on experience on the mailing list about that.
[17:43] <mgz> it's a way to get your feet wet without doing a big switch.
[17:44] <mgz> but starting with a new little project is probably better for actually learning stuff like developing in feature branches and more distributed workflows.
[17:48] <jamey_uk> yeah I'm thinking of converting our repo to bzr, playing around with making a new feature and such. Although, #git just pointed me to http://whygitisbetterthanx.com/ and the 'cheap local branching' does look good, I'm trying to thoroughly understand the difference. Seems to me just to be bzr branches into a new directory, which is a clone of the original branch, whereas git keeps it as one directory. Is this correct?
[17:48] <maxb> bzr-svn is pretty amazing, but can get awfully slow if used against one-repository-for-the-entire-company's-code svn repositories.
[17:49] <maxb> Also, bzr-svn's representation of files being moved or renamed in svn is rather suboptimal
[17:49] <maxb> By which I mean if you try to merge such changes, it's pain and mess
[17:49] <jamey_uk> why would one use bzr-svn? to get used to bzr's commands whilst still using the same svn repos?
[17:51] <maxb> To get some of the benefits of bzr before the entire team will switch
[17:51] <maxb> Also to actually do a conversion
[17:51] <jamey_uk> ah right
[17:51] <glyph> jamey_uk: bzr can do cheap local branching too
[17:51] <maxb> The thing about git's "Cheap local branching" is that git makes it particularly easy to manage multiple branches within a single repository and working tree
[17:52] <jamey_uk> ah really? I was just told it's a lot more painful when doing lots of branching
[17:52] <maxb> bzr can do much the same, but it's not quite as elegant
[17:52] <glyph> jamey_uk: it's just that bzr starts with a default model which is easy to understand and lets you optimize it once you understand what's going on, whereas git starts with a model that's a mess and hard to understand but super fast
[17:52] <jamey_uk> ah, akin to *nix versus osx
[17:52] <jamey_uk> in a sense
[17:52] <glyph> jamey_uk: 'bzr init-repo --no-trees .'
[17:52] <glyph> then bzr will put all of the revisions into a bucket in '.'
[17:53] <maxb> "Cheap local branching" workflows are possible with bzr, either by setting up a bzr repository, branches, and checkout manually, or by using the bzr-colo plugin for helpful UI additions
[17:53] <glyph> and you can make hundreds of little branches, which are all directories, without copying the whole history
[17:54] <jamey_uk> ahh, when I fired up bzr-explorer the main thing I didn't understand was when I was creating a new repo, I couldn't get my head around what the different types of repo actually meant
[17:54] <mgz> I still prefer the shared repo approach, which performs well and is hard to screw up with, it's only when you get something the size of the kernel you can't use that any more.
[17:54] <jamey_uk> I guess I just don't fully understand the concepts for bzr repos
[17:54] <mgz> actually having a seperate dir for each branch means it's clear what a branch is and where you're working.
[17:55] <jamey_uk> yeah I quite like that aspect
[17:55] <glyph> mgz: why doesn't that work?
[17:55] <jamey_uk> if I convince my boss for us to try-and-then-switch to bzr, do you think there'll be things he'd complain about that git does better?
[17:55] <glyph> mgz: with somethign the size of the kernel, I mean
[17:55] <maxb> One day, bzr will have true git-like branching. It's been hypothesized for a long time
[17:56] <jamey_uk> some context: small web dev team, main repo has ~5000 commit history, 3 people working and frequently need to branch the code but currently don't bother (too much of a headache)
[17:56] <maxb> jamey_uk: The one thing that git has that bzr can't touch is speed. git is blazingly fast. bzr is "usually fast enough"
[17:57] <maxb> Of course, git is also heinously confusing unless you study its philosophy, whereas bzr is quite friendly :-)
[17:57] <jamey_uk> ah, that might be what sways my boss. what about web-based tools for browsing bzr vs git repos? it's not that important, but something we're interested in having
[17:57] <mgz> glyph: mostly because having more than one working tree blows the cache, though also people like not having to do full recompiles when switching branches in the same dir.
[17:57] <maxb> That's the main trade-off as I see it
[17:58] <jamey_uk> yeah, it's the 'heinously confusing' aspect of git that makes me want to shove it away with at ten-foot pole and run into the loving arms of bzr
[17:58] <mgz> glyph: there's precisely one project I have on my dir where any of that actually applies, but people make choices based on what the big boys do.
[17:59] <maxb> jamey_uk: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes <-- this is the Bazaar web viewer. It's called Loggerhead
[18:00] <mgz> for something the size jamey is talking about, none of this really matters, git or a single on-disk tree wouldn't be a useful speed increase.
[18:01] <jamey_uk> so I wouldn't really notice a difference in speed between the two doing regular commit, push, pull stuff? the repo's probably less than a few hundred meg
[18:02] <maxb> I reckon you could notice the difference, but it wouldn't be sufficiently great to cause concern
[18:03] <jamey_uk> what are the equivalents to gitorious for bzr?
[18:03] <maxb> uh, remind me what gitorious is?
[18:03] <maxb> :-)
[18:03] <mgz> having some big binary things versioned might make a difference on spinning rust, having to create megabytes of jpegs can take a little time.
[18:03] <jamey_uk> it looks like a nice hosting/backup solution for git repos
[18:04] <jamey_uk> mgz, spinning rust?
[18:04] <mgz> disk, sorry.
[18:05] <jamey_uk> heh
[18:05] <mgz> generally, you can just push a bzr repo to your server, and use whatever normal file backup mechanism you have.
[18:06] <maxb> I would have to say that Bazaar lacks anything similar to Gitorious
[18:06] <maxb> These questions are ones I'm confronting trying to introduce Bazaar at my organization too
[18:06] <mgz> if you want third party hosted things, there are some options but fancy bzr access (or fancy git access) for commercial will generally mean paying someone.
[18:07] <maxb> I specifically don't want a hosted solution.
[18:07] <mgz> launchpad provides a similar offer to git hosting sites.
[18:07] <maxb> Unfortunately it fails to provide a self-deployable offering
[18:08] <mgz> can you download the github infra?
[18:08] <mathrick> jamey_uk: spinning rust is magnetic, rotating media (ie. HD), with all their poor access time characteristics, as opposed to SSD and other truly random access solutions
[18:08] <maxb> To be an ideal solution for me, Bazaar really needs what would essentially be the Launchpad Code feature extracted into a standalone deployable
[18:09] <jamey_uk> yeah, that would be very useful
[18:09] <jamey_uk> thanks very much for your help, I'm still undecided so might just try out both
[18:09] <mgz> is that mostly the web front end?
[18:09] <mgz> or does it include other things maxb?
[18:09] <mathrick> psusi: try bzr log -n0 to see sub-commits in bzr merges
[18:10] <mgz> matherick, I don't know an easy way to see what changed during the merge itself, unless it happened to be from the last rev anyway
[18:11] <maxb> mgz: Key other things are the ability to rename and delete branches, manage branch statuses, etc.
[18:11] <mgz> then diff -r 6.1.1..7 works
[18:12] <mathrick> mgz: good question, doesn't comparing the merge revision with the last revision merged in do what you want?
[18:13] <mgz> not if it's from a few revisions back, because the common parent isn't the rev you care about
[18:13] <mathrick> I don't get what you mean/
[18:13] <mgz> I think maxb actually has a better grasp on this than I do, but basically...
[18:14] <mathrick> if what's from a few revs back?
[18:15] <mathrick> also, what psusi says makes sense, and it'd probably be possible to introduce a new revision specifier, something like mergerev:1234, to ask for that
[18:15] <mgz> the same command would be diff -r3.24.1..19 or whatever, which would give you the difference between rev 3 and rev 19, where you actually want the (unrelated to merge branch) 18 as one parent.
[18:15] <mathrick> although the exact UI implications need to be thought out
[18:15] <mgz> I agree some ui to do this would be useful.
[18:16] <mathrick> mgz: I still don't think I understand what you mean about rev 18
[18:16] <mathrick> why'd you want r18 if it's unrelated?
[18:17] <mgz> well, what changed between rev 3 (which the feature branch is from) and rev 19 includes all the changes from 4..18 - which you don't want in your diff right?
[18:17] <mathrick> mgz: but that's not what psusi wanted. He was asking (AIUI) to be able to see what conflict resolution changes he made in order to be able to merge fully
[18:18] <mgz> so we have three parents. 3, common to both, 3.24.1 from the feature branch, and 18, from trunk.
[18:18] <mathrick> which should be bzr diff -r 123..<last rev merged in with 123>, assuming 123 is the merge rev
[18:20] <mgz> well, that's backwards, but yes... *only* if the feature branch originated at r 122
[18:20] <mgz> otherwise you get all the other changes since then, because those are also differences between the branches.
[18:20] <mathrick> no, I don't think you get what I mean
[18:20] <mathrick> I have a branch here
[18:20] <mgz> try it and see.
[18:20] <mathrick> revno: 15 [merge]
[18:21] <mathrick> which merges in revno: 12.1.1
[18:21] <mathrick> bzr diff -r 15..12.1.1 gives me a diff of what I did to resolve conflicts
[18:21] <mathrick> actually, it should be the opposite order
[18:21] <mathrick> but you get what I mean
[18:23] <mgz> does that branch have non-reverted changes at 13 and 14?
[18:23] <mathrick> yes
[18:23] <mathrick> hmm
[18:23] <mgz> because if I do `bzr diff -r93.2.1..103 lp:testtools` that includes the trunk changes since branching.
[18:23] <mathrick> I see, it lists the changes from 13 and 14 too, you're right
[18:24] <mathrick> that's indeed a problem
[18:25] <mathrick> what's really needed is -n for diff, the way it already works for log
[18:26] <mathrick> psusi: that deserves to be put in a bug on launchpad
[18:34] <mathrick> btw, for all the people discussing git-vs-bzr, there's https://launchpad.net/bzr-colo
[18:34] <mathrick> which is basically in-place branches git-style, just built on top of today's bzr
[18:35] <mgz> which I'd claim it git's usability with bzr's speed, but... that's not entirely fair.
[18:35] <glyph> mgz: yeah, that's kinda how I feel about it :)
[18:35] <mgz> git's hard to use in lots of other ways too, apart from its branch layout.
[18:35] <mkanat> Srsly.
[18:36] <glyph> colocated branches do have one nice usability feature which bzr lacks though
[18:36] <mgz> and bzr doesn't need plugins to be slow!
[18:36] <glyph> which is a way to synchronize a big pile of unrelated development all at once
[18:36] <mathrick> howso?
[18:36] <mgz> yeah, there are certainly circumstances where you plain just need them.
[18:37] <mathrick> but once _you actually understand the concept and benefits of colocated branches_, bzr-colo works just fine
[18:37] <mgz> people with super-fancy editors also seem to require one working tree for all branches as well.
[18:37] <mathrick> I'd argue that bzr's approach is about 100x easier for people to grasp at the beginning
[18:38] <mathrick> mgz: you mean like eclipse? Why? Because it gets confused about "workspaces" and "projects" or something?
[18:38] <mathrick> but wouldn't replacing files behinds its back confuse it even more?
[18:38] <mgz> I think it had problems yeah, there were threads on the list about it at any rate.
[18:39] <mathrick> the eclipse / MSVC way of writing code is annoying as hell
[18:39] <mathrick> because you can't just have files, you need projects and what not
[18:40] <mathrick> and it's supremely useless for browsing code you're not working on
[18:40] <mathrick> anyway, bzr-colo gives you in-place branches and works well
[18:41] <mathrick> which is something to keep in mind next time git people come in asking
[18:49] <psusi> mgz: actually, jamey pretty much nailed it... bzr does squash all of the merged commits into one big patch
[18:49] <psusi> it tells you that they came from another merge, but the diff makes it look like one big patch
[18:50] <mgz> psusi: no, that's not actually what it *does*, but it may well be how it gets presented to you
[18:50] <psusi> mgz: right
[18:51] <mgz> anyway, as mathrick suggested: <https://bugs.launchpad.net/bzr/+filebug>
[18:52] <mgz> including examples of what the git command does vs. where you had the problem with bzr would be helpful I'm sure
[18:53] <mgz> eg, you linked a loggerhead page, so it could probably also be targetted to loggerhead as well.
[18:53] <psusi> maxb: no, I don't know how git does it, but I would imagine it does the auto merge and then the diff is taken against that... at least that is what the output looks like
[18:54] <psusi> hrm... ok
[18:54] <maxb> psusi: in which case... bzr squashes no more than git does. git just has a pretty rendering mode
[18:55] <psusi> I suppose
[19:00] <mathrick> psusi: you don't need to give technical details of what git does
[19:01] <mathrick> just explain what it gives _you_ as the user
[19:01] <mathrick> thinking how best to do it is something for later
[19:03]  * mathrick wishes people would learn to give good bug reports, which specifically does NOT include guessing what the receiver might want to hear or do. Just give the relevant information and describe the problem / shortcoming accurately as it affects you
[19:03] <psusi> aye
[19:05] <psusi> https://bugs.launchpad.net/bzr/+bug/697810
[19:07] <mathrick> psusi: good, could you also add a comment with an example output of git vs. what bzr says in the same situation? That will make it slightly clearer what you mean
[19:36] <psusi> mathrick: ok
[19:46] <psusi> mathrick: how's that?
[19:49] <mathrick> psusi: the best way of presenting command output is to paste it verbatim instead of paraphrasing, but yeah, that's good enough
[19:50] <mathrick> now there's a record in the bug tracker, someone has a chance of looking at it properly
[19:51] <mathrick> though, hmm, actually bzr log -p seems to do exactly what you want I think
[19:52] <psusi> in the example I listed, log -p shows +bar in b... if you add --include-merges, it is shown in both r2 and r1.1.1
[19:56] <psusi> because of this, reviewing the merge commit for non trivial marges is impossible since the diff is the sum of all changes on the other branch, plus any local changes you had to make during the merge, if any.
[19:58] <psusi> this might be a more concrete example.  say you have a variable that is used in several places, and on another branch, they add another reference to that variable.  In the mean time, you rename the variable.  When you do the merge, it will add the new refernece to the old variable name, which you will then need to rename to the new name to get the code to compile.
[19:58] <psusi> with git the diff for your merge will only show the one line change where you rename the reference added in the other branch
[19:58] <psusi> with bzr, you see ALL changes done on the remote branch
[19:59] <mathrick> I know, I was just trying to see if log -p didn't do that already, since it seems to for _some_ situations, but not all, oddly
[19:59] <psusi> hrm... where is a situation where it does do that?
[20:00] <mathrick> psusi: my local branch here which has a rather simple conflict-resolving merge
[20:01] <psusi> I wonder what the difference is between that and http://bazaar.launchpad.net/~psusi/ubuntu/natty/e2fsprogs/merge/revision/45, which was a simple merge with the only conflict being debian/changelog
[20:02] <mathrick> it's rather odd, I get exactly what I'd expect to in that conflict-resolving merge, but in a simple merge with _no_ changes, I get a bunch of junk from the merged revisions output
[20:02] <mathrick> *no conflicts
[20:03] <psusi> hrm...
[22:11] <zyga-efika> Should the lp: alias work out of the box with bzrlib.branch.Branch.open() ?
[22:11] <zyga-efika> in other words: how do I get  Branch for lp:foo ?
[22:23] <mgz> enable plugins?
[22:24] <mgz> bzrlib.plugin.load_plugins()
[22:24] <zyga-efika> oh
[22:24] <zyga-efika> let me see
[22:24] <zyga-efika> do I need bzrlib.initialize() around this?
[22:24] <mgz> nope.
[22:24] <zyga-efika> thanks
[22:24] <mgz> (that may change, but is currently true)
[22:26] <zyga-efika> .hmm, I got NotBranchError
[22:26] <zyga-efika> oh sorr
[22:26] <zyga-efika> it's sensitive to trailing slash
[22:26] <zyga-efika> nice
[22:26] <zyga-efika> thanks
[22:27] <zyga-efika> still odd
[22:27] <mgz> a, what exactly failed for you there?
[22:28] <spiv> open_containing() rather than open() will probably make it work with trailing slashes.  It returns a tuple of (branch, rest_of_path) rather than just the branch though.
[22:28]  * mgz bows to spiv
[22:31]  * spiv waves back
[22:34] <zyga-efika> how can I get a Revision instance from a branch given a revno?
[22:34] <zyga-efika> I need to inspect something for a particular revision, it's likely embedde in the properties
[22:34] <zyga-efika> the time of commit
[22:37] <spiv> revid = branch.get_rev_id(revno)
[22:37] <spiv> rev = branch.repository.get_revision(revid)
[22:37] <zyga-efika> oh
[22:37] <zyga-efika> it's on the repository object
[22:37] <zyga-efika> thanks
[22:38] <spiv> (Or branch.dotted_revno_to_revision_id if you have a dotted revno)
[22:38] <zyga-efika> thanks, let me check this out now
[22:42] <zyga-efika> spiv: is the revision.timestamp the time of commit?
[22:43] <poolie> zyga-efika, yes
[22:43] <poolie> hi all
[22:43] <zyga-efika> poolie: thanks
[22:44] <spiv> Hi poolie
[23:48] <poolie> hi spiv
[23:48] <poolie> spiv, i was thinking about topics for the sprint
[23:48] <poolie> i'm keen to just let people hack together, especially with jelmer full time from monday
[23:51] <poolie> was thinking of either finishing named branches, or finishing novfs
[23:54] <maxb> named branches == colocated branches?
[23:55] <poolie> right
[23:55] <poolie> other options are to say that finishing work already in progress, or finishing high bugs, is best
[23:58] <maxb> colocated branches would remove one of the bzr-points from http://whygitisbetterthanx.com/ :-)