=== attente is now known as attente_zzz [00:54] im working on a c program for the Software centre... why is it good practice to put 'f' after a float value? === cpg|away is now known as cpg === plant is now known as Aaron === spm` is now known as spm [06:55] Good morning [06:57] stokachu: I am fine with a precise SRU and did upload your fix, but the SRU team rejected it (followed up in the bug); infinity, do you know why gdb was rejected for precise? === yofel_ is now known as yofel === philballew_ is now known as philballew [07:42] good morning [07:50] guten morgen dholbach [07:53] mitya57, доброе утро [07:53] doko_, ScottK: hm, no /usr/bin/python2 in Debian? that's a bit of a bummer [07:53] as /usr/bin/python has been ruined by PEP-394, we need that to reliably get python 2 [07:54] I remember jcristau said he won't allow addition of that symlink for wheezy [07:54] so we'll probably get that later [07:56] hm, that requires hacks like http://bugzilla-attachments.gnome.org/attachment.cgi?id=228194 [07:56] and PEP-394 mandates its existence [07:58] dh_python2 (in Debian) automatically converts python2 shebangs to python, doesn't it? [07:58] that only works for packages, though [07:58] not for custom scripts, jhbuild, or upstream configure/make/make install [08:00] that's sad, yeah [08:08] pitti: write polyglot 2/3 code and then you can pretend that you are in a sensible universe where that PEP doesn't exist [08:08] haha [08:09] pitti: also, any distribution that *actually* points python to python3 has doomed itself to lots of python code failing anyway; who'll notice another one [08:09] yes, that's pretty much what I said in https://bugzilla.gnome.org/show_bug.cgi?id=658237 [08:09] Gnome bug 658237 in general "Fix Python shebang lines" [Normal,Unconfirmed] [08:09] that seems to be a really bad move from Arch [08:10] but formally it's covered by this silly PEP, unfortunately [08:10] (not that this helps in any way to fix the actual breakage of pretty much all programs and custom scripts) === tkamppeter__ is now known as tkamppeter === Tonio__ is now known as Tonio_aw === Tonio_aw is now known as Tonio__ === mcclurmc_away is now known as mcclurmc === doko_ is now known as doko [09:45] Hello, does anyone know about applying seccomp filter rules to a newly spawning process through exec(). Further application of filter should be only for newly spawned process. [10:42] Hi, is there a tool for comparing repositories according to package-differences? [10:51] is anyone around that can sponsor an xorg-server fix? https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1073724. it fixes an incredibly annoying bug with broken pointer barriers in gnome-shell and I believe has no ill effects for unity [10:51] Launchpad bug 1073724 in xorg-server (Ubuntu) "Pointer barriers have gaps along the edge of the screen" [Undecided,Confirmed] [10:51] menace: https://code.launchpad.net/~cjwatson/+junk/suite-diff might help [10:52] not especially polished :-) [10:53] oh nice === Tonio_ is now known as Tonio_aw [10:55] perhaps i have some time for polishing ^^ === Tonio_aw is now known as Tonio_ [11:12] dholbach, hey, I've a libxml2 question for you [11:12] sure [11:12] dholbach, http://launchpadlibrarian.net/119213170/libxml2_2.8.0%2Bdfsg1-5_2.8.0%2Bdfsg1-5ubuntu1.diff.gz [11:12] dholbach, you added a libxml2-udeb binary in that upload but it's not documented in the changelog [11:13] dholbach, what's the deal with that? [11:13] seb128, no, it was automatically added [11:13] it's always added upon ubuntu builds [11:13] hum, "automatically"? by what? [11:14] WITH_UDEB := $(shell dpkg-vendor --derives-from Ubuntu && echo yes) [11:14] debian/rules [11:14] dholbach, ok, I see the rules is doing weird stuff ... it's just weird that it ends up in the diff this way [11:14] dholbach, danke [11:14] seb128, so yes, we can sync from experimental - the problem is https://bugs.launchpad.net/ubuntu/+source/libxml2/+bug/1075146 [11:14] Launchpad bug 1075146 in libxml2 (Ubuntu) "libxml2 2.9.0+dfsg1-3 FTBFS in raring" [High,New] === _salem is now known as salem_ [11:15] I asked for help to decide where to file a bug about the problem (upstream?) or if we need to patch this locally, but so far nobody could figure out where the problem came from [11:15] dholbach, yeah, I ran into that as well, I figured out it's a doko issue ... I'm just merging the current unstable version for now instead [11:16] might be better to just figure out the build problem - AFAIR the unstable diff was not too important [11:16] dholbach, ok [11:17] dholbach, I will look at another package, I don't feel like debugging toolchain issues before lunch ;-) [11:19] seb128, it's just interesting that it's just the new version which FTBFS in raring === kengyu is now known as kengyu_afk [11:31] seb128, libxml2_2.9.0+dfsg1-3.dsc fails in quantal too - it's just weird that it does not occur in sid [11:32] dholbach: do you want to earn extra karma and forward bug 1073323 to debian? [11:32] Launchpad bug 1073323 in gzip (Ubuntu) "Add simple test cases" [Undecided,Fix committed] https://launchpad.net/bugs/1073323 [11:33] dholbach: or are you working on making the upstream tests work in adt? [11:33] pitti, ah yes, I can forward it - I'll add it to my TODO list [11:33] does anyone have a handy script to deduplicate Packages/Sources files, keeping only the newest version? [11:34] bdrung: do you want to upload/forward to Debian bug 1073390, or want me to sponsor/help out? [11:34] Error: Debian bug 1073390 could not be found [11:34] bdrung: I mean bug 1073390 [11:34] Launchpad bug 1073390 in libarchive (Ubuntu) "libarchive-dev needs a compile/link/run test" [Undecided,In progress] https://launchpad.net/bugs/1073390 [11:41] In file included from argmatch.c:28:0: [11:41] ./stdio.h:1012:20: error: 'gets' undeclared here (not in a function) [11:41] err, what? [11:41] that line merely does #include [11:41] (that's a new FTBFS of coreutils in raring) [11:42] seems gets() is only exported if __USE_ISOC11 is not set, which might be a new default in raring [11:43] doko: ^ did you happen to see this already? [11:44] pitti, yes, I think cjwatson did fix something similar in bison [11:44] doko: ooh, thanks for the pointer! [11:44] that's useful indeed [11:46] * pitti tries to remember how dpatch works [11:47] does anybody know why python-markdown is in main (no binaries are)? [11:48] (it is in main according to LP) [11:48] python-markdown | 2.2.1-1 | raring/universe | source, all [11:48] it's not [11:48] so Launchpad lies? https://launchpad.net/ubuntu/+source/python-markdown [11:48] yeah, apparently [11:48] ah, ok [11:49] release (universe) ? [11:54] mitya57: don't get fooled by the "Component: main" field, simply ignore it and look at the table instead [11:55] that's main in debian I believe [11:56] There's even small text saying it comes from the package and may be wrong [11:56] Maybe it needs a tag [11:58] geser, StevenK: Laney is right, it's main in debian, question solved [11:59] pitti: there are various different approaches depending on the exact version of gnulib files involved - you might also look at m4 and diffutils if that helps [12:04] pitti: i was that happen with parted and one more package. [12:05] I've tried to "update" / "bootstrap" gnulib in those packages but failed to do so in a correct manner. [12:06] * xnox likes the patch in bison. [12:11] slangasek, RAOF, SpamapS, other SRU team members: what's the official line from the SRU team on copying updates to the new serie as well as copying them from -proposed to -updates? seems to be done inconsistently at the moment [12:11] xnox: I wouldn't recommend doing a full update [12:11] not unless you're upstream [12:11] xnox: I'm happy to sort out parted if you could push the merge work you've done so far [12:12] pitti: i'll take care of that patch [12:12] I've done it half a dozen times or so now so I can do it pretty much by rote :) === MacSlow is now known as MacSlow|lunch [12:15] xnox: or come to think of it I could just fix it in Debian ... [12:17] cjwatson: ack. [12:17] cjwatson: I think I can just adapt your patch in the ubuntu merge. As it doesn't affect debian yet. [12:18] do we have a bts tag for eglibc2.16 ftbfs? [12:18] (e.g. the gets issue) [12:18] no idea [12:19] I'll do it in Debian anyway, at least in our git repository, as otherwise it'll inconvenience the glibc maintainers [12:22] bdrung: thanks [12:22] cjwatson: I shamelessly stole your reduced backport for bison; that only needed minor unfuzzing and works fine [12:25] cjwatson: hi. sorry to bother you, but did you see my inquiry regarding libav for raring on the mailing list? i have no problem with waiting a few more days, but i just wanted to know if you intend to answer that mail or not. [12:27] siretart: I didn't see it [12:29] cjwatson: Good that I ping you on irc then ;-) -- https://lists.ubuntu.com/archives/ubuntu-devel/2012-November/036083.html [12:31] hm. did I scare him that much? [12:33] hi i would like know if someone can help me to create a new package for bashrc [12:33] siretart: replied now, anyway [12:33] basically i would like add some stuff to default .bashrc for each user [12:33] cjwatson: thanks! [12:34] the only way is skel? [12:39] Peace-, yeah, when a new user is created, the files are copied from /etc/skel, so if you modify the files there then it is copied to each user. is that a problem? [12:39] robru: i have read that put too much stuff on skel is not reccomended [12:39] just that [12:40] Peace-, well I'm not an expert on that. I don't really see why it would be a problem. what are you wanted to add? a ton of stuff? [12:40] robru: :D [12:40] i was asking anyway cuz it works i did already my own package [12:41] so i was just curiorus [12:41] Peace-, it's probably fine. I mean unless you are putting hundreds of GB's in there. it just copies the files, so it's not like the system is bothered by copying some files that are slightly larger than before. [12:43] robru: well i have made this http://code.google.com/p/kde-peace-settings/source/browse/#git%2Fkde-myown-settings%2Fetc%2Fskel [12:43] robru: so i have vlc bashrc and some other little things === Tonio_ is now known as Tonio_aw [12:47] Peace-, yeah those are really tiny, I don't see any problem there [12:47] ok [12:48] pitti: do you have the power to unbreak ddebs.u.c? https://bugs.launchpad.net/daisy/+bug/1075056/comments/1 [12:48] Launchpad bug 1075056 in Daisy "Retracers hung on "ERROR: Package download error, try again later: Failed to fetch..."" [Critical,Confirmed] === cpg is now known as cpg|away [12:49] Peace-: it's not recommended for the *distribution* to put too much stuff there - that policy directive doesn't apply to local packages though [12:50] ev: hm, let me try to regenerate those; which release is that for? [12:50] * pitti sighs at the ddebs.u.c. hack [12:50] for the distribution, there's not only a concern of size, but also what you do about upgrades - usually when you think about this hard the resolution ends up being to put things somewhere else instead, so the advice in policy is there to try to stop people wasting time [12:51] huh, quantal [12:52] I was looking at precise [12:52] but libicc2-dbgsym doesn't exist in quantal as far as I can see [12:53] cjwatson: well i am going to create a package that contains what i want to each user and i should upload it on ppa === Tonio_aw is now known as Tonio_ [12:53] i have already did but i was not sure if this could be a problem for users expecially for skel folder i mean [12:53] anyway as robru said it's very tiny folder so it should not be a problem if some users would install my package === Ursinha_ is now known as Ursinha === attente_zzz is now known as attente [13:00] ev: hm, in quantal libicc2-dbgsym doesn't exist at all in ddebs' indexes.. [13:00] ah, the version in the bug report is for precise [13:03] ah I must've misread the pastebin [13:05] ev: running [13:05] (sorry, doing three things at once) [13:34] Laney: ok, never mind - while I worked out a reasonably uncomplicated set of build-deps to allow both, I think it's probably safer to just bump them to the new version, i.e. prepend "1.0.1.3+really" to both << and >> versions [13:35] pitti: no worries [13:36] anyway. not actually meant to be working today :-) [13:39] cjwatson, "the new -proposed migration system will enforce that this work is done before" ... what "work" for you refer too? is the system checking for nbs status (e.g enforcing that all rdepends are ported to the soname version of a lib when there is an soname update)? [13:39] Yes [13:39] At least if you make those libraries go away in the new source package [13:39] urg === MacSlow|lunch is now known as MacSlow [13:40] I didn't think about that, seems to be problematic [13:40] I don't think it will be [13:40] I view it as an actively good thing [13:40] or we will need start to press the delete source button a lot [13:40] Or people could actually do the damn work to port NBS [13:40] We do it anyway - it's not like this is work we avoid [13:41] well, we also end up dropping stuff, usually at the end of the cycle [13:41] like for e-d-s in quantal [13:41] And it is troublesome when people are lazy and don't do it, because then we discover build failures when we're trying to do urgent updates [13:41] It hurts velocity [13:41] I guess we should drop early and let people add stuff back if they are interested in ported [13:41] We need to stop doing things in a giant rush at the end of the cycle, and do things incrementally through the cycle instead [13:42] That's one of the things I'm trying to move toward [13:42] s [13:42] right [13:42] well I'm all for agressive universe cleaning [13:42] I'm not [13:42] I'm all for *fixing* it [13:42] if there are universe packages which are hard to port and are "for later", a workaround/compromise could be to remove their binaries, but keep the source? [13:42] I've neither the time nor the motivation to port all universe's rdepends to be able to update libs [13:42] Removing the binaries is certainly a possibility [13:42] seb128: That's not my problem, sorry! [13:42] there will always be some universe packages which need lots of upstream work for porting [13:43] And that's one of the things the +1 maint team is explicitly supposed to be helping with [13:43] but for those where we can, we should certainly do it right away rather than having them linger for month [13:43] s [13:43] cjwatson, yeah, and I know different people have different opinions on what to do with universe outdated packages [13:43] I've lost patience with the "universe doesn't matter" thing I'm afraid [13:43] Turns out that to many of our users it does [13:43] cjwatson, infinity: is it possible to have bug https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1036834 re-evaluated for inclusion into precise? [13:43] Launchpad bug 1036834 in gdb (Ubuntu Precise) "[FFe] gdb should be marked "Multi-arch: allowed"" [High,In progress] [13:44] stokachu: I'm not familiar with why it was rejected in the first place ... [13:44] seb128: upload new library soname bump as a new source package & transition main to it, then the old one drops out to universe and you can hand over to motu/+1 [13:44] yea there wasn't any information in teh bug as to why [13:44] cjwatson, it's not that it doesn't matter, is that we have limited resources and we can either spend those improving what 90% of your users run or spend the same time porting universe stuff used in aa magnitude less [13:44] xnox: I don't recommend that except in extreme cases [13:45] seb128: We are doing lots of this work anyway. You're just making the +1 maint team do it instead [13:45] yeah, the libs would pile up over time [13:45] This isn't actually a net saving, it just annoys everyone [13:45] is there a way to see who actually rejected it? [13:45] cjwatson, well, as said I would recommend agressive dropping instead [13:45] stokachu: No [13:45] cjwatson: I understand and agree that fixing stuff is the best way. [13:45] which we sort of did for e-d-s rdepends in quantal [13:45] seb128: Which is no help to people who have it installed, so I do not recommend that unless there is no realistic alternative [13:45] we even dropped evolution-indicator which was canonical's code [13:45] yeah, under the new regime that seems to be the best thing for stuff that's effectively unportable by us [13:45] It is an option, but it is not and should not be the first resort! [13:46] the nice thing is, it forces us to keep the universe in an installable shape all the time! [13:46] who would I talk to in order to get this overruled? [13:46] possibly overruled* [13:46] cjwatson, the alternative is to spend a month of my time porting universe stuff and tell my manager I couldn't deliver thing we should have delivered [13:46] stokachu: None of us can overrule anything until we figure out who did it and why [13:46] seb128: oh nonsense [13:46] It's not a month of your time, stop exaggerating [13:46] cjwatson: I think you might be seeing this under a too absolute perspective [13:46] And I'm not saying it has to be *you* [13:46] cjwatson: for a lot of cases it is actually a month [13:46] should i just post a question in the bug and hopefully someone will say why? [13:46] seb128: 3 people did python3.3 transition of main & universe in less than a week. [13:47] cjwatson, well, we estimated evolution-indicator to be a week worth of time to port to the new e-d-s last cycle and same for pidgin-libnotify [13:47] cjwatson: and we just can't/don't do it and drop instead if upstream abandoned the project; I think that's only fair [13:47] pitti: On the contrary I think seb128 is being way too absolutist. I've done lots of this porting and hey, look, it turns out I delivered plenty of other stuff too [13:47] pitti: where did I say we should *always* port everything? [13:47] (hint: I didn't, and I'm annoyed at being characterised that way) [13:47] cjwatson, well, you are saying that not porting block the migration of the new libs [13:47] we we need to port or drop === dendrobates is now known as dendro-afk [13:48] I said repeatedly that removal is an option, just not the first resort [13:48] seb128: Yes [13:48] cjwatson: i<3u [13:48] cjwatson, so I think we agree, I'm just saying that in practice time constrain mean we will see drops increase (maybe to add things back a bit later when time allows) [13:48] stokachu: might be worth grepping IRC logs and the like [13:48] right, that falls under the "no realistic alternative" exception [13:48] cjwatson, like in practice time for porting comes rather after ff than before [13:49] seb128: we shipped precise and quantal with zero out-of-date binary packages and zero NBS, so I don't see why things would need to change [13:49] we're doing all this work over the course of a cycle anyway [13:49] cjwatson, well, I do consider that we have been agressive in dropping for quantal... [13:49] seb128: well, we did survive it with dropping packages; that seemed to have worked fine? [13:49] and what you're saying is basically that Adam and I get to pick up all your trash at the end [13:49] pitti, we dropped stuff used in quantal, e.g evolution-indicator (indicator-messages' integration for evolution) [13:50] it now just means that we need to do it right away [13:50] or pidgin's indicator-messages integration [13:50] or a bunch of universe rdepends from eds: dates, contacts, ... [13:50] pitti, right, that's what I was saying [13:51] well, we have to pick either: velocity or having a giant universe with a lot of upstream-unmaintained bits [13:51] cjwatson, " and what you're saying is basically that Adam and I get to pick up all your trash at the end" ... sorry I didn't say that, I say we should be more agressive in dropping unmaintained stuff from the archive [13:51] seb128: I think I clearly remember you saying that all indicators will be ported to the new api. If pidgin's indicator-messages integration is dropped.... how are xubuntu & lubuntu getting ther notifications currently? [13:51] and personally I'm favoring the former, even if some of those universe packages might have users [13:51] pitti, that conversation started with me saying that I'm "all for agressive dropping" [13:51] we can't have our cake and eat it too [13:51] they are using the older api, is it still in the archive? [13:51] pitti: cleaning things up as we go should ultimately improve velocity; I don't at all agree that this is a binary thing [13:51] we lose velocity by having to stop and fix the archive all the time in order to land changes [13:51] no, it's not a binary thing; I didn't say that we'd immediatley drop all NBS rdeps [13:51] xnox, they don't I guess [13:52] pitti: I mean it's not a choice between velocity and fixing things [13:52] seb128: 8-? [13:52] (changes> which BTW are often actually in universe - things that customers want but that we haven't yet qualified for main are in universe, for instance) [13:52] cjwatson: well, it is; we need to find a good balance [13:52] pitti: it should not be a choice. one of the things that has absolutely killed our velocity in the past is a constantly broken archive [13:53] and I believe I have pretty clear management backing for fixing that, so if you feel that you have a problem with delivering things as a result then I think you should talk to your manager [13:53] right; but if you have to port 50 rdepends of e-d-s it kills velocity too, as you effectively can't land it for weeks [13:53] or poppler [13:53] so, certainly we have to do that [13:54] poppler is a great example because the desktop team didn't bother to do that at all and it fell to apw [13:54] last time I remember [13:54] dropping 50 rdepends would be crazy talk, just because someone wants a slightly newer library. [13:54] we do bother doing the main desktop part, we are just so overworked that we can't possibly porting universe as well [13:54] Daviey: nobody is proposing that [13:54] like I say, I don't mind some removals, but you need to take a sensible position rather than just "I can't be bothered porting any of this, remove" [13:54] or we need to stop what we are doing to port universe [13:54] Somehow i am failing to see how a newer poppler or e-d-s is a hard-dependency for any feature work. [13:54] Anyone that claims it's not their job to keep the archive good, should renounce their ubuntu-dev membership. [13:54] where "port" is often "reupload" [13:55] I'm just saying that claiming that "porting all rdepends right away is increasing velocity" is not quite right [13:55] I'm not saying that we shouldn't port things right away; I think we should, and I'm quite happy that it's now being enforced [13:55] (with my former archive admin / stable+1 maintainer hat on) [13:56] I mean, lots of the porting people say they don't have time to do I've done in the past, and a pretty sizeable proportion has been a matter of no-change uploads [13:56] so, I'm sorry but I don't see that as a major imposition on anyone [13:56] Daviey, there is a different between "keep the archive good" and "care for everything in universe, including old stuff that you think are unmaintained and have no users" [13:57] cjwatson, well, it's not a "major imposition", I just fear that still like libav stay in proposed for a month and block other things [13:57] and I'm not saying you need to do the latter, only that you actually need to analyse the trade-offs before removing, and if it's just a matter of no-change uploads then why on earth not [13:57] that I agree with [13:57] seb128: many of the unported libav rdeps were on images and really used [13:57] slangasek: hi, do you mind if I do a raring apt upload? [13:57] usually those non ported at those which are non trivial though [13:58] at->are [13:58] seb128: they wouldn't have been that hard for the person who changed libav to do; they were not too bad for me once I figured out the patterns [13:58] e-d-s is certainly a rather extreme case; most libraries are quite a bit easier [13:58] it's not like I'm not speaking from experience here, since I did a lot of the libav porting personally last time round [13:58] pitti, extreme but real [13:58] yeah, but not the common case [13:59] e-d-s was simply not doable without somebody full time for a month [13:59] we did end up dropping tons of stuff [13:59] but at least we didn't block the main image on having all those resolved/dropped [13:59] well, let's see how it goes in practice [14:00] I guess we will need to get down to the "I've looked at it, will take a week of work to port, nobody has time atm, let's drop and add it back later" [14:00] BTW the more stuff we move out to universe (e.g. Kubuntu last cycle) the less I agree with the "universe -> nobody cares" built-in assumption [14:00] on the case by case basis [14:00] the nice thing is that it puts responsibility at the right place for Ubuntu uploads; for Debian syncs, it'll still fall under stable+1, but it's been like that before anyway [14:00] I think we've been way too far on the side of "the uploader can just forget about it" until now [14:01] pitti, I'm not sure I agree with that, because I've to update e-d-s to update GNOME doesn't mean I want to be responsable for the e-d-s rdepends in the archive [14:01] This way, the uploader actually has to think - not necessarily do all the work personally, but do some of it, find people to help, remove stuff if it's too painful [14:01] it'll decrease the speed of landing things (i. e. velocity) a bit, but the net result is much nicer IMHO [14:01] especialy if we want to go to the rolling release thing [14:01] Maybe the real issue here is the ease that a lib transition can be done? I wonder if more scrutiny is the correct answer here? It seems that this is pain we endure when we jump ahead of Debian... no? [14:01] Before, they could make it somebody else's problem all the time, and I honestly think that in the majority of cases - not necessarily all - that was just plain irresponsible [14:02] cjwatson, there is probably a bit of that as well yes... [14:02] Daviey: that'd be velocity again -- Debian's freeze takes very long, we can't afford to wait until they release [14:02] well, let's see how that plays out [14:02] pitti: And you can outline specific reasons for needing a transition ? [14:02] so, I'm probably way too knee-jerk on this, sorry, it's one of my hot buttons [14:02] Daviey: in some cases we do Debian experimental uploads, but that of course doesn't really address the "port all Debian main" issue [14:02] that outweigh the cost? [14:03] I'm not sure that I understand the question; we could also stop updating package versions entirely surely [14:03] I do think that when we drop binaries that amounts to making it the user's problem, which is sometimes even worse, so I don't see that as an automatic solution [14:04] It can be a solution if things are really unused; but I'm just aware that for a developer who might otherwise have to do porting work, the incentive is definitely to say "oh, whatever, nobody cares about this surely" [14:04] (I've done that myself and been occasionally wrong) [14:06] cjwatson, well, as said it's not used or not, it's "what will benefit more user, time spend on the default desktop or time spent on universe packages that we doubt are used"... there is a balance to find for sure, but porting 50 rdepends is taking time even if the fixes are trivial and can easily can put you some days off [14:06] cjwatson, where the said soname update is needed to land some chunck of work you need to land it can be problematic to find those "some days" in between [14:06] seb128: I think that's a price we just have to pay [14:07] Mm, I wonder which of those users actually thank us more for :-) [14:07] (but as cjwatson says, more people than just you can be involved in that) [14:07] pitti, in an ideal work sure I would like to have time to land my features and fix everything in universe, in practice... [14:07] Sometimes the problem is that if you happen to be in the 1% of people who use something, well, that's 100% of you [14:07] And there's only so many times that we get to annoy 1% of users [14:08] seb128: but to be honest, so do the people who need to clean up NBS :) [14:08] pitti: What i am saying is, this specific example.. all i can find as rational is "gstreamer (via gst-libav) requires this version"... That isn't IMO, enough justification. Has anybody looked at if it is a hard requirement? Is it less work to resolve that? [14:08] Anyway, I agree that there is a balance and I guess we'll find some kind of medium between our positions [14:09] (it probably turns out that all that is required is no-change-rebuilds :) [14:13] stokachu: I've followed up to the gdb bug with what I think happened === Tonio_ is now known as Tonio_aw [14:15] stokachu: (erm, really this time - LP timed out on my first attempt) === lynxman_ is now known as lynxman === JamesJRH_ is now known as JamesJRH [14:24] how to add a transition to http://people.canonical.com/~ubuntu-archive/transitions/? file bug or is there a bzr branch that I can could touch? [14:24] hah, gvfs' autopkgtests discovered a Python 3.2 → 3.3 behaviour change in Popen [14:24] * pitti fixes [14:25] ah, seems to be https://code.launchpad.net/~ubuntu-transition-trackers/+junk/transition-tracker - nvm [14:26] ev: ... still waiting on apt-ftparchive to finish... [14:27] :) [14:30] hey, I'm running some tests and I'd like to build a chroot for raring [14:31] I'm using debootstrap but it has no script for raring yet [14:31] are we going to update debootstrap in quantal to make that possible? [14:31] Upgrade to raring or use the debootstrap from quantal-proposed [14:31] or should I use some other means of doing that [14:31] oh, cool [14:31] Or 'sudo ln -s gutsy /usr/share/debootstrap/scripts/raring' [14:31] thanks, let me try those [14:32] It'd have been in quantal as released but we found out about the name too late [14:32] hmm, I'm already using proposed [14:32] siretart: Laney should be able to help (he says, carefully washing his hands) [14:32] with debootstrap 1.0.42 [14:33] zyga: Oh, sorry, it's still in the queue. Just set the symlink manually for now [14:33] thanks [14:33] pitti: hey, any thought on https://bugzilla.gnome.org/show_bug.cgi?id=687525 ? I've SRUs for xfdesktop and thunar waiting for approval to quantal-proposed, but if this gvfs patch is fine for a SRU, I guess it's better than my workarounds. [14:33] Gnome bug 687525 in general "gvfs causes filemanagers to show partitions twice" [Normal,New] [14:33] siretart: yeah, just make a merge proposal for that branch and it will all just magically happen. [14:34] you can't do MPs for junk branches [14:34] but give xnox the address and he'll review it for you :-) [14:34] siretart: there is a README for "how to get started" [14:34] siretart: yeah I used to target the "lp:ubuntu-transition-target and that means merge notification is sent to all people who can merge" [14:35] siretart: but yeah, I'll be happy to merge trackers =)))) [14:35] xnox: https://code.launchpad.net/~siretart/+junk/transition-tracker.libav [14:35] mr_pouit: this looks SRUable to me indeed [14:35] I don't see the button 'merge proposal' [14:35] mr_pouit: just don't take my word as the final one, as I'm neither in -desktop or SRU teams any more [14:36] siretart: right, +junk don't have MPs [14:36] i see [14:36] thanks for the clarification, pitti [14:36] pitti: yeah, but you're a lot in the gvfs git commit log :P. Thanks, I'll look into preparing the sru. === Tonio_aw is now known as Tonio_ [14:37] zyga: accepted the {precise,quantal}-proposed debootstrap uploads now [14:37] siretart: merged. now after some time it will be available on the website. [14:37] xnox: thanks. that'll help me to get started with what to test and upload. [14:40] siretart: ;-) [14:43] cjwatson: ^ which reminds me, do we need an NBS report for -proposed? [14:44] pitti, making a -proposed version of NBS is on the to-do [14:45] ah, thanks [14:45] pitti, just seen on #ubuntu+1-maint ;-) [14:45] but you can use http://people.canonical.com/~ubuntu-archive/proposed-migration/ [14:45] (will take some practice to learn the format) [14:45] because that should provide most of what we need for transition tracking? [14:45] pitti, for completeness ;-) [14:46] Yeah, in practice everything from NBS should show up on update_output [14:46] (or update_excuses if not fully built) [14:46] cjwatson: I need to start creating an NBS report for another (non-primary) archive. I'd greatly like to re-use something you create. [14:46] Which I expect the +1 team to be keeping as low as possible [14:46] Daviey: it's all in ubuntu-archive-tools ... [14:48] cjwatson: Oh, i thought you were going to create something refreshed. Last time i looked at the tool in u-a-t, it had an issue.. Maube i am talking crap [14:48] Well, that's what outputs the reports we use [14:48] I certainly had no intention of rewriting it from scratch [14:49] update_output> For instance the haskell-unordered-containers transition shows up as the first "Trying easy from autohinter" section there and you can see the uninstallables left after the attempt to shove in that plus all its rdeps [14:49] Which mostly corresponds to the yesod* stuff on http://people.canonical.com/~laney/www-test/ghc.html [14:50] * Laney just deleted that [14:50] poo :) [14:50] but anyway, you can imagine :) [14:50] use the normal URL now [14:51] So http://people.canonical.com/~ubuntu-archive/transitions/ghc.html [14:51] Or for the ptlib stuff it's clearer - you can see that just t38modem is left untransitioned [14:52] What the transition tracker does is give you the build-dep/dep hierarchy which in some cases approximates a sensible order to approach the uploads [14:52] The red lines should wind up basically the same as what update_output says [14:53] (There are some confusing haskell autohinter entries further down which are essentially random "what if we try some of these packages but not all of them" heuristics - in this case, ignore them) [14:54] I look forward to running the next perl transition through this - that'll be a laugh) [14:56] apw: the entries in the "main run" section of update_output correspond to attempting to promote single packages rather than groups; so for instance it tries to promote uim, discovers that that makes uim-mozc uninstallable, and backs out [14:56] (I already corresponded with the uploader about that since it needs a mozc merge; it's just an example) [14:56] mjpegtools is a more interesting example that IIRC corresponds to actual NBS [14:58] ScottK, Riddell: hm, apport-kde fails on this: http://paste.ubuntu.com/1337463/ -> known bug? [14:58] And some of the packages are just uninstallable on their own account, for example python-augeas which depends on libpython2.6 [14:58] apw: that roughly help? [14:58] cjwatson, yeah thanks, will poke at it and come back at you [15:02] ScottK, Riddell: i. e. pykde4 incompatibility with py3.3? [15:06] cjwatson: you got it figured out? [15:10] stokachu: I updated the bug [15:10]