=== jmp_ is now known as _jmp_ [02:11] * semiosis is back. [02:11] * semiosis is away. please leave a /msg [02:11] * semiosis is away. please leave a /msg [02:11] * semiosis is away. please leave a /msg [02:12] semiosis: could you turn that off please? [02:12] yes i did already, very sorry about the malfunction! [02:12] :( [02:12] np (: [03:12] in 12.04 why do i have this window shadow glitch? http://i.imgur.com/7bTMK.png [03:14] I kinda like it [03:14] it may look nice there but trust me it gets annoying [03:15] I can imagine. You may want to check out #ubuntu, it's active right now - been kinda dead in here. [03:15] heh [03:18] also, #ubuntu is where to go for general help, not here :) [03:18] mhm [03:57] Good morning [03:59] * slangasek waves [04:02] Guten morgen pitti [04:06] perl: warning: Setting locale failed. [04:06] perl: warning: Please check that your locale settings: [04:06] LANGUAGE = (unset), [04:06] LC_ALL = (unset), [04:06] LANG = "en_ZA.UTF-8" [04:06] are supported and installed on your system. [04:06] perl: warning: Falling back to the standard locale ("C"). [04:06] ________ [04:06] < pitti! > [04:06] -------- [04:06] \ ^__^ [04:06] \ (oo)\_______ [04:06] (__)\ )\/\ [04:06] ||----w | [04:06] || || [04:06] (oops) [04:07] that's during dist-upgrade? [04:09] I think my container just isn't set up properly (I think I just need to install some langpacks) [04:12] at least a locale [04:14] highvoltage: is that on Ubuntu (the container)? [04:14] highvoltage: if so, you might be hit by a remaining apparmor glitch where for some reason /usr/lib/locale/local-archive can't be generated from within the container [04:14] highvoltage: copying it from the outside to /var/lib/lxc//rootfs/usr/lib/locale/locale-archive will "fix" it [04:15] Good morning pitti :) [04:15] jjohansen: I think I forgot to poke you about that one. I thought it was fixed a while ago but apparently it wasn't. localegen can't generate it and apparmor doesn't log any reject, so a bit tricky to figure out [04:15] hey RAOF, how are you? [04:16] Home! :) [04:16] RAOF: How many hours did it take this time? :D [04:16] Good. I slept well, and woke :) [04:16] (didn't you have fun returning back from the sprint?) [04:17] nigelb: In terms of flight time, not much - just only 19ish hours. In terms of door-to-door time, somewhat worse due to the 6hr layover in Melbourne. But I got to have a shower and change my clothes there, so that was good. [04:17] Yeah, lots of fun getting back from the sprint! [04:17] Nothing like that this time :) [04:17] Heh [04:53] any SRU team members around? [04:56] * micahg looks for infinity or SpamapS [05:04] pitti: can I get a pre-SRU ACK please on bug 939863 (we'd like to roll it into a security update to save on the churn), it's a textual change [05:04] Launchpad bug 939863 in libav (Ubuntu Precise) "Warning message from ffmpeg program needs update" [Low,In progress] https://launchpad.net/bugs/939863 [05:06] micahg: that's http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=blob;f=debian/patches/04-ffmpeg-warning-change.patch;h=0472d450a743ff0b3918c80e91da16d4c4b35d2b;hb=HEAD ? [05:06] what difference does it make? the old and new texts by and large say the same? [05:06] pitti: yeah, it's less inflammatory WRT the libav/ffmpeg split [05:07] heh, ok [05:07] seems fine to me, it's not translated anyway [05:07] ok, thanks [05:08] I'll upload to quantal tomorrow as my jet engine laptop keeps shutting off when I build it [05:09] make -j1 [05:09] yeah, I suppose I could disable parallel === jmp_ is now known as _jmp_ [05:46] infinity: SpamapS: unping === smb` is now known as smb [07:21] mvo: done, see bug 999501 (and it's now linked to the merge request) [07:21] Launchpad bug 999501 in app-install-data-ubuntu (Ubuntu) "[SRU] Please fix description for unity-mail" [Undecided,New] https://launchpad.net/bugs/999501 [07:21] mvo: can you please add a precise target? === dholbach_ is now known as dholbach === fabbione is now known as seek_and_detroy [07:30] good morning === seek_and_detroy is now known as fabbione [07:42] mitya57: thanks, I add the precise target now [08:36] am I right in thinking that dh with=python2 won't work as intended? :) [08:45] (I'm asking because I'd like to update python-django{,-south} in quantal) === cking_ is now known as cking === tkamppeter_ is now known as tkamppeter [09:02] dholbach: you mean "dh --with=python2"? [09:02] yes [09:17] pitti, yes :-) [09:18] I believe it is misspelt in Debian's python-django-south and I'd forward the patch if necessary [09:24] Am I correct in thinking that bug #997891 just needs to be reviewed by the SRU team now? [09:24] Launchpad bug 997891 in sphinx (Ubuntu Quantal) "sometimes cannot build pdfs for de, sl, pt, es, nl, pl, or it locales" [Undecided,Confirmed] https://launchpad.net/bugs/997891 [09:31] dholbach: I'd be surprised if that didn't just fail hard with "dh: Unknown sequence with=python2" [09:36] elky: only as a 2nd step. First it needs to get uploaded (sponsored) by someone and then the SRU teams reviews it from the upload queue. [09:39] geser, well i can't do any kind of uploading, who should I poke? :) [09:40] elky: the bug is in the sponsoring queue, I assume the queue should start processing soon again as all the patch pilots are back from UDS [09:40] ok cool :) [09:40] s/back/recovered/ [09:40] * elky hides from StevenK [09:40] Muahaha [09:41] eep! [09:42] elky: don't hide from StevenK but hunt him instead to sponsor your bug [09:42] ooh, good idea [09:43] * StevenK glares at elky. [09:43] wasn't my idea! [09:43] elky: Do you have a debdiff? [09:43] I seem to recall you several times trying to get me to do this stuff. You should be over the moon with happiness! [09:44] elky: Haha [09:44] StevenK, it's attached to the bug [09:45] elky: Catalyst!? [09:45] I don't live in your country anymore. [09:46] elky: Yes. This is a *bug*. [09:46] Sydney nearly killed me [09:46] :-( [09:46] Hay, anyone know how I can get ubuntu to use libGL.so from fglrx instead of mesa's [09:47] StevenK, it's perfectly fine if you telecommute. the other commute is less fine. [09:48] if I remove the mesa libraries, it cannot then find libGL at all, although it shows up fine in ldconfig. I guess that there's something broken in my setup such that ld can't find the library? [09:49] StevenK, did you find the debdiff yet? :P [09:49] elky: I'm building a source package. [09:49] elky: Don't make me come over there. [09:49] Would that work? [09:50] aww, we made him feel ignored :( [09:51] elky: My first upload to quantal done. [09:51] Now the precise one? :P [09:51] Is it fine to SRU new upstream relleases? [09:52] cjwatson, it doesn't seem to fail when using '--with=python2' [09:52] elky: Yes, yes. [09:52] vibhav, https://wiki.ubuntu.com/StableReleaseUpdates?action=show&redirect=SRU#New_upstream_microreleases [09:52] thanks [09:53] StevenK, so if I pestered enough, would you bring Sarah? :P [09:53] elky: Likely [09:53] woo! [09:54] Haha [09:54] * elky sits here poking StevenK in the ribs. [09:54] That will not make me upload quicker. [09:54] heh [09:57] dholbach: well, --with=python2 is the correct spelling, so that's not surprising :-) [09:57] oh? [09:57] You asked about with=python2 [09:58] but "--with python2" works too [09:58] --with python2 is fine as well [09:58] ok, then we're good [09:58] thanks cjwatson :) [09:58] then doko once corrected me for nothing :) [09:58] elky: precise-proposed also uploaded.l [09:58] :D [09:58] s/l$// [09:58] * elky hugs StevenK [09:58] normal getopt_long style semantics [09:58] elky: My bill is in the mail. :-P [09:59] I'll send you pineapple lumps? [09:59] How about beer? [09:59] Would that make it through customs? [09:59] I don't see why not. [10:00] kiwis on one side, aussies on the other? [10:00] elky: Did you get the two e-mails from the uploadprocessor? [10:01] not yet, gmail might be lagging [10:02] oh wait, they would have gone to my catalyst address... sec [10:02] Ha ha [10:03] or not? [10:03] maybe greylisting [10:03] I can't check *that*, sadly. [10:04] yeah, it's not a terribly long one, but it is there [10:04] I thought people came to the conclusion that greylisting is now pointless. [10:04] oh, is it? [10:04] the janitor hit the bug, so i guess that's something [10:04] * pitti still uses it on his servers [10:05] it cuts out a fair bit still [10:05] and in all fairness, one less is worth it. [10:05] I get about 1 spam a day through my filters. [10:05] Mostly none [10:15] still no mails :( [10:28] hi guys !!! [10:28] is anyone from the libdbusmenu/appmenu in here ? [10:31] doctorpepper, it might help if you just ask whatever specific question you have - if nobody replies, you could try #ubuntu-desktop as well [10:32] anyone seen reports of network manager dropping valid network connections, likely at about the dhcp refresh time intervals? [10:37] dholbach: actually i am hitting a bug [10:38] he's asking you to describe it. [10:38] doctorpepper, I'm not a libdbusmenu/appsmenu expert, but you could for example mention which bug (maybe bug number) it is, and say that you're up for providing more information, etc. [10:41] StevenK, seems like I'm not getting the mails [10:41] when running gtk3 apps on kde with the appmenu applet on the top pannel the menu are exported to the appmenu applet but also visible and functionnal on the application window [10:42] elky: I can forward them if you wish. [10:43] StevenK, please do :) [10:44] for instance i have this problem with gedit but dont have it with gimp-2.8 or inkscape [10:45] doctorpepper, ok - if nobody answers here, I'd suggest filing a bug report (https://help.ubuntu.com/community/ReportingBugs) and adding all the information you have - you could also try raising it in #ubuntu-desktop - in any case a bug report will be helpful [11:43] infinity: do you know anything about the eglibc/armhf build failure? [11:43] gcc-4.6 -fno-stack-protector -U_FORTIFY_SOURCE -march=armv5t -mfloat-abi=soft ../ports/sysdeps/unix/sysv/linux/arm/sysdep.S -c -isystem /build/buildd/eglibc-2.15/debian/include -I../include -I/build/buildd/eglibc-2.15/build-tree/armhf-armel/csu -I/build/buildd/eglibc-2.15/build-tree/armhf-armel -I../ports/sysdeps/arm/elf -I../ports/sysdeps/unix/sysv/linux/arm/eabi/nptl -I../ports/sysdeps/unix/sysv/linux/arm/eabi ... [11:43] ... -I../ports/sysdeps/unix/sysv/linux/arm/nptl -I../ports/sysdeps/unix/sysv/linux/arm -I../ports/sysdeps/unix/sysv/linux -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../ports/sysdeps/unix/sysv -I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv ... [11:43] ... -I../ports/sysdeps/unix/arm -I../ports/sysdeps/unix -I../nptl/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../ports/sysdeps/arm/eabi -I../ports/sysdeps/arm/fpu -I../ports/sysdeps/arm/nptl -I../ports/sysdeps/arm -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../ports -I../nptl -I.. -I../libio -I. -nostdinc ... [11:43] ... -isystem /usr/lib/gcc/arm-linux-gnueabihf/4.6/include -isystem /usr/lib/gcc/arm-linux-gnueabihf/4.6/include-fixed -isystem /build/buildd/eglibc-2.15/debian/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DHAVE_INITFINI -DASSEMBLER -I/build/buildd/eglibc-2.15/build-tree/armhf-armel/csu/. -pipe -O2 -fstrict-aliasing -g -Wa,--noexecstack -o ... [11:43] ... /build/buildd/eglibc-2.15/build-tree/armhf-armel/csu/sysdep.o -MD -MP -MF /build/buildd/eglibc-2.15/build-tree/armhf-armel/csu/sysdep.o.dt -MT /build/buildd/eglibc-2.15/build-tree/armhf-armel/csu/sysdep.o [11:43] {standard input}: Assembler messages: [11:43] {standard input}:302: Error: lo register required -- `add pc,r3,#(0xffff0fc0-0xffff0fff)' [11:43] oops, sorry, that was longer than I expected! [11:50] * nigelb blinks [11:50] is this where we point and laugh? === MacSlow is now known as MacSlow|lunch === dendro-afk is now known as dendrobates [11:58] why do I get this error when trying pbuilder-dist on precise? [11:58] distro_info.DistroDataOutdated: Distribution data outdated. [12:01] I'm guessing it's lacking quantal data, but why does it have to be a fatal error ._. [12:02] mlankhorst: upgrade to the most current available distro-info-data [12:02] (you're not the first person to point out the awkward error handling; it's been looked at) [12:04] hm, didn't have -updates enabled === dendrobates is now known as dendro-afk === gaspa1 is now known as gaspa === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk === MacSlow|lunch is now known as MacSlow [13:47] ok, did first uploads to quantal. [14:01] should I contact someone about my binutils-{armel,armhf}-cross packages which went into NEW or just wait for them to be processed? [14:02] wait (unless it's really urgent) [14:02] geser: it is not so will just wait [14:22] * mterry is rocking out to dholbach's Flashing Lights mix [14:24] * dholbach hugs mterry :-) [14:24] mterry, I'm glad you like it - it's what kept me from falling into bed too early yesterday :) === zyga_ is now known as zyga [14:24] * highvoltage loaded the link but the flash applet didn't want to play the actual track :'( [14:25] dholbach, heh. :) It's good! [14:25] highvoltage, really? that's weird [14:27] dholbach: ah just figured it out, what I thought was the flash applet was just javascript, and the actual flash was blocked by flashblock, got it playing now :) [14:32] urgh, just filed bug 999711 -- we're getting dangerously close to bug 1e6! [14:32] Launchpad bug 999711 in pygobject (Ubuntu Precise) "pygobject 3.2.2 stable update" [Undecided,New] https://launchpad.net/bugs/999711 [14:32] Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1 [14:32] * pitti wonders what kind of bug mpt will file this time === yofel_ is now known as yofel [14:39] thanks dholbach, that's really relaxing. [14:48] yofel: I gather you're working on KDE SC 4.8.3 packaging, and ScottK suggested I should talk to you about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672553. I've reached the point where this and some archive admin are the only things blocking me uploading a Python 3 port of ubiquity to quantal; would it be OK if I uploaded that patch in advance of Debian? That is, are the package names OK, or would they need to be ... [14:48] Debian bug 672553 in pykde4 "pykde4: Add Python 3 support" [Wishlist,Open] [14:49] ... python3-pykde4* instead (I noticed the Qt bindings are named differently between Python 2 and 3)? [14:50] looking [14:54] chrisccoulson, I'm scheduled to patch pilot this thursday. You are scheduled next thursday. I'm looking to switch, if you're interested [14:56] mterry, just do your shift today if you have time? there is no desktoper on schedule [14:56] seb128, well, I'm trying not to do it this week at all [14:57] mterry, oh ok, I guess just move it, there is no strict need to find somebody to swap with [14:58] mterry, I might do some sponsoring on thursday, I skipped my turn during UDS [14:58] seb128, you're so blase! [14:58] lol === larsu_ is now known as larsu [14:59] * mterry wishes blueprints didn't spam everyone all the time [14:59] I feel like I'm standing over the shoulder of someone as they update a blueprint [15:06] wg 38 [15:06] doh [15:06] * mneptok has an odd moment of synchronicity [15:07] mterry: earlier i *almost* said "cjwatson: i just read Proust's _Remembrance Of Things Past_. it was awesome! want me to paste it?" [15:08] mterry: if you want a *painful* blow-by-blow account of every small detail, those are the books for you. [15:08] cjwatson: not sure there either, but looking at the debian python policy the naming convention seems to result in python3-pykde4. So I would go with that [15:08] mneptok, :) === BenC__ is now known as BenC [15:13] cjwatson: I haven't had a chance to dig into it yet, but something's emitting v7 instructions, and then having a sad. I'm still trying to kick a nasty flu here. [15:14] infinity, welcome to the club [15:14] though my flu turned out to be a pneumonia [15:15] ogra_: still have it? you should really be resting. [15:15] * ogra_ just spent a horrid night with his chest wrapped in pepper patches ... [15:15] it waqs like sleeping (or rather not sleeping) in hellfire [15:15] hi all [15:16] after pbuilder-dist build ../_.dsc , I cannot find my .deb file [15:16] highvoltage, well, the fever is down and i am getting bored .... cant do much physical stuff but typing works :) [15:16] why? [15:17] hey alo21, #ubuntu-packaging and #ubuntu-motu might be a better place for that [15:17] highvoltage: thanks [15:19] dholbach, hmm, i got a membership renewal mail for ubuntu-sponsors ... do i need to renew that individually ? i though ubuntu-dev would be automatically a member of it [15:19] (or ubuntu-core-dev at least) [15:20] it isn't and I can't remember the reasoning for it in the beginning [15:20] Because sponsorship is a voluntary thing. [15:21] If there was a group that was an intersection of ~canoical and ~ubuntu-core-dev, maybe you could make them all members of ~ubuntu-sponsors, but we can't force all community devs to be sponsors if they don't want to. [15:23] why not ? [15:23] slangasek: you are merging faster than I can create merge proposals ;-) [15:23] even if you're in the team, it's still up to you whether you ever DO actually get around to sponsoring anything at all [15:23] the tech board could define that as a requirement for core-dev members [15:23] Because that's not how "voluntary" works. :P [15:23] if the rules for that team are like that ... [15:23] ogra_: Retroactively defining what core-dev means might not go over well. [15:24] no, not retroactively indeed [15:24] i always thought it was a part of core-dev to be a sponsor [15:24] Nope. [15:24] i always had the impression that being one did kind of imply you were up for mentorship type stuff [15:24] And now you know. ;) [15:24] heh, yeah [15:25] maco: well, I guess someone wouldn't sign up for something with that much responsibility without being willing to take the responsibilities that comes with it :) [15:25] I don't really see being a member of ~ubuntu-sponsors as giving me any additional responsibilities [15:25] if a core dev said no to being directly asked to sponsor something, i'd expect some justification either of the "it's wrong" "i'm working on another package" or "oh god, grub? don't ask me! ask cjwatson!!!" variety [15:26] It's just that I wouldn't be able to remove sponsors from bugs if I weren't. [15:26] maco: Being able to upload and being willing to review and sponsor uploads for others don't seem to be immediately related, even if most of us do both. [15:26] (And I imagine some people would rather not have the nagging bug mails if they prefer to never sponsor) [15:26] * infinity shrugs. [15:26] i got nagging bugmail from being on the sponsors team? [15:26] i dont remember that [15:26] I have no strong opinions, given that I'm a member of both teams, and most of us are, but I see no point in redefining it now. [15:27] but then i did get a ton of bugmail already from taht summer i triaged a few hundred bugs... [15:27] ugh, its almost unbelievable how badly borked lp:ubuntu/juju is.. [15:27] * SpamapS gives up trying to fix it with bzr rename [15:28] * ogra_ notes that juju means something like "magic" [15:28] SpamapS, swing your wand ! [15:28] push --force (overwrite?) it if you have a better packaging branch [15:29] Laney: I'm told that will forever preclude the package importer from working [15:29] isn't that what you want? [15:29] no, I want to be able to work in harmony w/ the importer [15:30] cjwatson: otherwise the patch looks fine to me, as I need to upload pykde 4.8.3 I can add your patch with right names and upload it today [15:30] I'm happy to "own" it and push to it most of the time, but if somebody does an upload for some other reason.. I need the importer to record it there, or I'll revert something [15:30] Laney: and really, UDD is supposed to work *for* us, not against us. [15:31] It worked fine when I was the only one pushing [15:31] well, you can have distributed development without the package importer [15:31] but then the importer did something vile and now I can't merge-upstream [15:31] you'd just have to be on top of not missing non-UDD uploads [15:31] which I agree could be annoying [15:32] I've reported a bug in bzr at this point, but its really confusing and I'm just done w/ it.. :-/ [15:33] The response was to try and "let it do that" and then fix w/ renames [15:34] but I already tried it and got a few of the renames wrong.. (80+ files get moved to $dir.moved) [15:35] Which I don't understand at all. I should be able to just import the upstream source and have that be the "source of truth" === zyga_ is now known as zyga [15:35] mneptok: smartass :) [15:35] xnox: you can still create a merge proposal for the precise branch, if you like ;) [15:35] yofel: ok, python3-pykde4 is fine by me. will you sync that into quantal as well? [15:36] infinity: ah, so this is just a side-effect of the known compiler problem? [15:36] slangasek: I did now.... =) I guess I will experience SRU process first-handedly now. [15:37] xnox: :) Speaking of which, can you please update the bug description with the needful from https://wiki.ubuntu.com/StableReleaseUpdates#Procedure ? (At minimum, the [Test Case] section) [15:37] SpamapS: the UDD people can normally reset branches that have got into funny states such that the importer can work with them again; IIRC maxb specialises in this kind of thing [15:38] slangasek: ok. [15:38] cjwatson: right I want the other way. I want to reset the branch such that *I* can work with it. The importer is quite happy. [15:38] cjwatson: for now I'll upload to quantal as I need 4.8.3 in there now. Later I'll coordinate with ScottK for debian. [15:38] yofel: ok, sounds good [15:39] cjwatson: it seems to me that there is a disconnect between whatever the importer does and what merge-upstream expects [15:39] does the importer use import-dsc? [15:42] ev: I have put two workitems on the https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-wubi-publishing [15:43] not sure if anything else needs to happen on that one. [15:45] SpamapS: the importer uses import-dsc [15:45] or something built around the same libraries, anyway [15:45] xnox: why wouldn't we just upload to main? [15:45] ev: because I do not want windows cross-compilers in main. [15:46] SpamapS: but that doesn't automatically mean it works with merge-upstream, because import-dsc will synthesise file-ids from scratch whereas merge-upstream will make them match the upstream branch [15:46] or any other random packages. [15:46] what's wrong with having a windows cross-compiler in main? [15:46] xnox: why? [15:46] indeed [15:46] plus archive reorg [15:46] I can think of at least one delta against Debian we could drop by having a Windows cross-compiler in main [15:46] note that there are other cases where we're carrying a delta from Debian in order to keep mingw out of main... I think it's worth revisiting this [15:46] * slangasek nods [15:47] ok. [15:47] SpamapS: if I were you, I would explore the following path: (a) do it all with merge-upstream (b) push over auto-imported branch (c) get the UDD people to reset things so that the importer starts from that point [15:47] but we will still want PPA to have wubi daily builds =) [15:48] if the build is good enough, we can upload it to main. [15:48] SpamapS: there is not likely to be any sensible way to get things working with merge-upstream starting from an auto-import with different file-ids [15:52] cjwatson: whats confusing is that I was using merge-upstream, then let just one auto import work, and the auto import is what broke things [15:53] Yes [15:53] cjwatson: so I guess the moral of the story is never let the importer do new upstreams [15:53] Yes [15:53] Not if you expect to use merge-upstream again, anyway [15:53] We basically need https://wiki.ubuntu.com/DistributedDevelopment/Specification#Phase_5:_Current_upstream_in_Bazaar before that will work [15:53] le sigh. Ok well I can at least move forward with something other than "pretend UDD is dead" now [15:55] cjwatson: I would expect merge-usptream to handle the upstream code the same way import-dsc does though [15:55] cjwatson: like, this even breaks w/ merge-upstream of a tarball [15:55] Sure [15:55] merge-upstream doesn't know the right file-ids if you merge from a tarball [15:55] This all essentially flows from bzr having strong rename handling [15:56] Even if two files have the same name, they aren't the same file as far as bzr is concerned (especially for merging) unless they have the same file-id [15:56] makes sense.. I would have thought though that it would just take the entire corpus of the dir, and just do deletes/adds.. not try to do renames [15:56] and by it, I mean merge-upstream and import-dsc [15:57] Adds don't work unless it knows what file-ids to use [15:57] What's probably happening is that it's added whatever new files are in the new release with different file-ids, so the next merge considers them to be contents conflicts - i.e. a file with different history but the same name [15:57] so what I really want is for bzr to just take the upstream source, as-is, and not *ever* conflict it. I say "I want this tarball" and it should just take that tarball and insert it by name, not file id. [15:58] No such thing in bzr [15:58] Every file has a file-id, it's an intrinsic part of the model [15:59] Sure, I see why it works that way, and I'm wanting a way around it. ;) [15:59] If you have a bunch of conflicts and just want to take the other side of them, you can use 'bzr resolve --take-other' (or --take-this, as appropriate) to speed things up [15:59] I'll at least try that.. [15:59] Best done in a throwaway branch for testing [16:00] but these are rename conflicts where the whole source dir gets renamed to src.moved [16:00] and then as you suggest, the new files are in src .. [16:00] Which is probably because the directories were added with different file-ids [16:00] You can see this sort of thing with 'bzr ls --show-ids' [16:00] And/or 'bzr st --show-ids' [16:01] I get why it works that way. What I don't get is why there's no "just start over with this tarball" [16:01] Um [16:01] Sure, you can start over, but that's not enough for you; you need it to correspond to the ancestry of the branch you're merging from [16:01] That information isn't in a tarball [16:02] I actually don't need that [16:02] I mean, I don't think I do [16:02] Youo do [16:02] If you didn't, we wouldn't be having this conversation [16:02] I don't merge in other branches.. I just want the upstream source.. always as-is. [16:02] You're using merge-upstream, yes? [16:02] yeah [16:02] From a branch or a tarball? [16:03] I've tried both.. it actually doesn't matter to me. [16:03] I like using the branch, because it gives me the bzr### revnos automatically [16:03] Then you do need the ancestry [16:03] but thats like, 1 step I can do myself with bzr export [16:03] In the branch case, you need the ancestry to match the branch you're going to be merging from in the future [16:04] In the tarball case, the thing is that when you do a merge from something unversioned (.dsc, tarball), bzr has to just make up file-ids, and (AFAIK) it won't do that the same way every time because newly-generated file-ids include timestamps [16:04] ok so really what it sounds like to me is, if you use merge-upstream, you can't let the importer do imports anymore [16:04] So successive import-dsc and then merge-upstream from tarball won't match [16:04] could somebody look @ https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/937522 please? Would like to get it closed :) to many spam getting in it [16:04] You can let it do them for non-new-upstream-release uploads [16:04] xnox: foundations-q-btrfs-requirements> could you please copy the pad contents rather than pointing to the pad from the whiteboard? I don't think we should rely on the pad being persistent over the long term [16:05] slangasek: ok. [16:05] and the pad isn't completely public [16:05] You can let it do them otherwise too, but you're going to have to overwrite it and get admin help to reset state [16:05] The "some people use bzr, some people upload directly" model was only meant to be a transitional mechanism, not so much something people rely on forever [16:06] cjwatson: i have the impression a bunch of those uploading directly are waving their canes and telling those using bzr to get off their lawn [16:06] the other reason to copy pad contents to blueprints is that work items won't be harvested from the pads [16:06] cjwatson: also that thing with quilt and evil [16:07] well, workitems are supposed to go in a separate section now [16:07] cjwatson: indeed. I see the problem. I think the answer then, is to roll back to before the importer got involved.. and commit those locally.. push --overwrite.. reset state.. and then never let the importer do its thing again [16:07] maco: "that thing with quilt and evil" - you'll have to be more specific ;P === BenC__ is now known as BenC [16:07] SpamapS: +1 [16:07] cjwatson: or rather, never let the importer do an upstream again. ;) [16:07] slangasek: ive complained about quilt+bzr=evil and .pc dir and such on the mailing list quite enough :P [16:07] SpamapS: not bothering to fix the importer after you push --overwrite would also seem to have this effect ;) [16:08] heh.. true [16:08] slangasek: i know the dev guide has a very convoluted workaround for it available, i just think it's convoluted [16:08] (and of course depends whether the last person just ditched the .pc dir or what) [16:08] (which just adds more convoluted) [16:11] xnox: grub2 SRU uploaded [16:11] slangasek: ok, I better update the bug then. [16:40] pitti: at UDS you'd mentioned something about line numbers only appearing in tracebacks that end in Import errors. Is that right? === zyga_ is now known as zyga-afk [16:54] hrm, why are we suggesting pbuilder and not sbuild? http://developer.ubuntu.com/packaging/html/packaging-new-software.html [16:57] SpamapS: those that wrote the document favoured it i think.. that is how these things work :) [16:57] i'm sure dholbach would welcome patches :) [16:58] Yeah this document is really confusing [16:58] it never mentions 'bzr add' for instance [16:58] I'm trying to see how we suggest people start out with UDD [16:59] SpamapS, Daviey: thanks for your interest in it (although it's not only me who'd welcome patches) - at our session at UDS barry said he'd look over the packaging guide bugs tagged with 'udd' and set the importance of them [17:00] I hope that on the udd and u-devel mailing lists we can get some folks interested in having a look over them [17:00] I wonder if we should revisit https://blueprints.launchpad.net/ubuntu/+spec/foundations-m-dpkg-xz given that debian uses xz by default for udebs now and the discussions are hot about switching xz by default in debian. [17:00] because I agree that some of the bits ARE confusing [17:00] well like its not clear how to start out a packaging branch [17:05] xnox: my feeling there is that we have the basic support in place and it's not a current priority for us, but if Debian does it then we'll follow naturally [17:05] I think the steps involve tagging the first commit with an upstream-xxx tag.. [17:05] it helps that we don't need to worry about lucid upgrades any more [17:05] SpamapS, 'bzr dh-make' handles a lot of the initial tagging/importing/adding of files, but it could be clearer. [17:06] *OH* [17:06] my eyes did not see 'bzr dh-make' [17:06] hi all [17:06] they saw 'dh-make' [17:06] asomething: thats helpful. Did not see that! [17:06] cjohnston: ok. [17:06] How could I know if I had installed my personal pakage? [17:06] cjwatson: ok. [17:06] package* [17:07] cjohnston: sorry, tab-completion fail. [17:07] xnox: (I do think that getting the basic support in place for precise was important, of course) [17:21] anyone around that can get merge proposals originally targeted against precise that are uploaded to quantal out of the sponsorship queue? [17:21] https://code.launchpad.net/~kroq-gar78/ubuntu/precise/meep/fix-990137/+merge/103959 [17:21]