[00:02] ttx: what does tomcat have to do with eclipse ( https://blueprints.launchpad.net/ubuntu/+spec/server-o-tomcat7-packaging )? [00:15] bdrung_: the jdt has project types that start, add modules & run tomcat instances in the project, iirc [00:16] aha [00:23] everything in Java is connected like that [00:23] its like the borg that way [00:33] Do the launchpad buildds support linux-any in any form yet? [00:34] TheMuso: I thought that was purely a pbuilder problem; I've been happily building and uploading linux-any packages. [00:34] (And they seem to build on launchpad, too ☺) [00:36] Ok thanks, will just use it and see how things go. [00:36] * TheMuso uses sbuild anyway, so... [00:36] Likewise, which is why I wasn't seeing any problems. Others in the ubuntu-x team use pbuilder, and so they've been swapping out linux-any when they touch packages :) [00:38] Right. === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk === fta` is now known as fta === kenvandine_ is now known as kenvandine === asac_ is now known as asac [03:02] hi all [03:45] is felix geyer here on irc? [03:46] https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/753370 the root of their problem was using an informational string as api [03:46] Ubuntu bug 753370 in mesa (Ubuntu) "No Desktop Effects in Kubuntu 11.04 Beta1" [Medium,Fix released] [03:47] Sarvatt: you're the best :] [03:49] ohsix: There was a nice big mesa-dev thread about not parsing GL_VENDOR for blacklists. [03:49] ok cool [03:49] i saw anholt commented on the blag where the guy was raging about it [03:50] i'm no opengl "pro" but i read the red book and i know the informational strings aren't api D: that guy seriously used a lot of words for being exactly wrong [03:50] (if you can gmane me to that thread i'd appreciate it) [03:53] martin (the loud guy) was pretty off base calling it the only solution, to restore some past badness he was already doing [03:53] ohsix: http://article.gmane.org/gmane.comp.video.mesa3d.devel/25597 [03:53] thanks [03:54] There's a bit before that which was in another thread. [03:55] the more the better, i wanna confirm my own prejudices! :D [03:58] eugh even on the bug they suggest changes that include strstr, which is another VERBOTEN thing, prefixes aren't unique [04:07] ohsix: So you think this was appropriate for a point release to drop? [04:08] yes [04:08] ohsix: When people are relying on stuff and it's dropped in a point release I think it's totally reasonable to be upset. [04:08] it's akin to internal debug message strings that aren't translated being changed [04:08] the problem is they were relying on it, not that it changed; it's an opengl thing they should know [04:09] Good bad or indifferent, they were relying on it and KDE 4.6 is released and unlike mesa, they have rules about what can be done in point releases. [04:09] they should have ran with the dialogue about how to do it correctly now that other parties are interested, but i don't see that happening in the stuff i've read so far [04:09] Separate issue. [04:09] oh i don't minimize that they have a problem they'll have to deal with [04:09] They are reworking it for KDE 4.7. [04:10] But for 4.6 they are stuck. [04:10] but the problem existed before they knew it was a problem [04:10] That doesn't parse. [04:10] martin seems to continually imply that their rigid rules are more appropriate and mesa should follow them with respect to information he shouldn't have been relying on anyways [04:10] We shouldn't have to regression test point releases for stuff upstreams removed on purpose. [04:10] the problem = relying on the _RENDERER and _VENDOR string for stuff [04:11] they have other problems with using strstr on _EXTENSIONS too [04:11] Fine, so drop it in a proper development release. [04:11] haha [04:11] It's like mesa is going out of it's way to break stuff. [04:11] i accept that you don't know much about what these strings are and what the opengl specifications says what you can and can't do with them [04:11] I understand that breaking already released software is poor form. [04:12] it isn't ambiguous at all, but it seems martin went and did exactly the wrong thing [04:12] you can break already released software very easily if they do something you were very clear about telling them they shouldn't be doing [04:12] with their use of strstr you can break their software by introducing support for an extension [04:12] it's a non sequitor [04:13] it's not easy to use opengl properly, and people have plenty of room to complain about it, checking versions and loading extensions and whatnot [04:13] it's easier on platforms with a dynamic linker but you generally can't take advantage of that [04:14] Felix IRCs as debfx, btw. [04:14] ok thank you [04:15] I can understand why mesa devs might feel like they weren't required to maintain that, but it seems like a gratuitous change. [04:15] No reason it couldn't have waited for the next development cycle, even if it was technically internal. [04:15] if it wasn't valid information anyways and it was long overdue for removal i don't see when an appropriate time to make the change would have been, presuming things that don't hold true for those strings that is [04:15] those strings can change with the weather [04:16] Apparently. [04:16] generally stuff is only appended, like with "SSE2/MMX" and stuff [04:16] but at best they're for telling an operator about something, it's devoid of information useful for a program [04:16] Generally I think stuff should be removed during development, not in maintenance releases. [04:17] i agree [04:17] It's not unusual for people to end up relying on defact ABI and so it's reasonable not to mess with it more than necessary. [04:17] defact/defacto [04:17] it's definitely a special case; if it were a command line program with unstable output for its tables it'd have a "DONT PARSE THIS OUTPUT" type header on every invocation [04:17] If it'd been in a new development release, I think there would have been no reason to bitch. [04:18] problem with de-facto is it's basically a set of ad-hoc assumptions that are probably not very nuanced and half wrong, and change over time anyways [04:18] Right, but that doesn't mean it's not reasonable to not mess with them more than you have to in maintenance updates. [04:18] i'd probably be right with martin if that was the point he was making, the one you are [04:19] I've discussed it with him. [04:19] but the invective started off in a manner that it was a grave thing to do and what was being done was correct [04:19] This is no doubt not the only point he had, but it was surely one of them. [04:19] To draw a parallel from the real world, just because it's legal, doesn't make it a good idea. [04:20] This may not have been technically an ABI break, but that doesn't make it just fine either. [04:20] We patched it back in with AFAIK zero bad effect. [04:20] i would do it in spite of the people that use it [04:20] because the spec says i'm ok :] [04:21] Which is not a very accommodating way to develop the joint FOSS ecosystem. [04:21] well it's devoid of informational content [04:21] It doesn't excuse gratuitous changes. [04:21] what does it mean that "GEM" is in there? except that it was perceived at one time to mean the distinction for a given thing [04:22] I'm not saying he was right to rely on it, but he did. [04:22] yea, ad-hoc [04:22] nbd [04:24] If there was more reason for doing it than "because we can" I might be more sympathetic. [04:25] well the date & "GEM" was pretty useless, there was a time when it meant something when dri1 and dri2 drivers were in play at the same time [04:25] but it still didn't mean what he took it to mean [04:26] i'm biased though, i'd presume anyone that uses given thing X (opengl) has done the due diligence about reading about X [04:29] Sometimes one is forced to do things one would rather not do. [04:29] I'm not sure why he latched onto that. [04:29] me either [04:30] I'm glad the ubuntu-x people were willing to patch it back in or Kubuntu would have been screwed. [04:30] Here at the distro level we were pretty much stuck between a rock and a hard place. [04:31] yea [04:31] it makes sense to argue for having it temporarily added back [04:32] My only bitch was that it was removed in a maintenance update. [04:32] but not to shore it up by defending the silly thing you did [04:32] From what I know the removal was reasonable, just the timing could have been better. [04:32] People are like that. [04:32] i'd hope the mesa guys make a note of it, but they don't need to really change that; and i'd hope the opengl people doing bad things take note and not do that D: [04:36] their rules might be too rigid if they can't fix something like bad opengl version checking in a minor series, too [04:36] theres always exceptions, this one might not meet the standard but there will be stuff that will [04:36] It depends on how invasive the change would have been and what other regression risk it brought. [04:36] I'm not a kwin developer, so I can't judge. [04:37] https://bugs.kde.org/show_bug.cgi?id=270942 i'm really surprised he wasn't more resistant to relying on newer mesa versions, that's typically something you do as a last resort [04:37] KDE bug 270942 in compositing "Direct Rendering is wrongfully disabled on Intel graphics since mesa 7 10 1" [Normal,Resolved: fixed] [04:38] Agreed. That's a pretty recent release to be relying on. [04:39] ohsix: When he says "Unfortunately version, vendor and renderer are the only information queryable just with OpenGL API." is that accurate? [04:39] he's not wrong, but that doesn't speak to what information you actually get [04:40] all those strings can be "HURF DURF" and not be wrong [04:40] It seems like there's room to improve the information that's provided then as he seems to need something not properly provided by the API. [04:41] well people told him to just call DRI2 extension methods to directly find the information he's stated he's trying to infer [04:41] Sounds substantially more complex. [04:42] the point of opengl is to not really rely on that information, if you need to blacklist a driver version that you know is wrong or something you do it with the entire string, even better if its by md5 or something of that string, so you won't be tempted to make it anything more general [04:42] well it's information he admittedly wants, and you need to use windowing system specific stuff to get some of it; glx at least tells you if you get direct rendering and stuff [04:43] I have a $work project I need to get back to. [04:43] :] [04:50] "users of working drivers (e.g. NVIDIA)" gag [05:43] Good morning [05:43] SpamapS: uh, we ship with that since lucid, don't we? [05:52] pitti: Good morning. for bug 772336 I tried all sorts of things but I am not able to make it work. 1 or 2 methods were really crucial for the code to work. I give it up for now :( [05:52] Launchpad bug 772336 in apport (Ubuntu) "Add feature to take screenshots of the buggy window" [Wishlist,Triaged] https://launchpad.net/bugs/772336 [05:52] ScottK: Hey, you do seem to be taking a large benefit from the GNOME3 discussions on -devel-discuss by informing users about KDE :) [05:52] Those methods were removed from gtk3 [05:53] cdbs: If people don't like what Ubuntu is providing, I'd like them to be aware of the alternatives. [05:53] I think it's better for the project if such people don't leave. [05:53] OTOH, more users == more work, so it's not like it particularly helps me personally. [05:54] ScottK: exactly. Its better for users to move to {k,x,l}ubuntu than change distros altogether if they hate Unity or GNOME [05:54] the more important point here is teaching the fact that "ubuntu" is not just one possible thing, but making them aware of the full richness of choice [05:54] The problem is that many experienced computer users simply aren't in the Gnome 3/Unity target market. [05:55] ScottK: Right now many users frustrated about the Unity move are thinking they'll be bound to use Unity and are changing distros to Arch or Fedora [05:55] I personally think of Ubuntu mroe as a distro base than anything else. All derivatives use the same underlying architecture/drivers/kernel etc, the different DEs just provide users with a choice of interface to use. [05:55] pitti: linux isn't about choice :D [05:55] they forget the fact that GNOME Shell, KDE, XFCE, LXDE are all alternatives, and can run perfectly on their beloved Ubuntu stack [05:55] pitti: Agreed. I think it's unfortunate that Ubuntu Desktop was dropped again in favor of just referring to it as Ubuntu. The term was overloaded enough already. [05:55] cdbs: is that list tracked on gmane? url? [05:56] TheMuso: It would be nice if the terminology matched this perspective. [05:56] ScottK: I am enclined to agree. [05:57] ohsix: Its a recent discussion on -devel-discuss, and there were many similar ones in april as well [05:57] cdbs: ok thanks [05:59] Is it possible to run 3D acceleration in KVM yet? [05:59] I find it amusing that many of the people complaining they no longer have "Gnome" seem to have little understanding of how customized Ubuntu's Gnome already was. [06:00] ScottK: Well, the feedback on Unity by non-technical and casual Windows users has been highly positive, its just the power user who's concerned [06:00] cdbs: See my earlier comment about "not in the target market". [06:00] hmm [06:01] I think when many people saw Mark Shuttleworth's jumping the chasm presentation their first thought was "Cool". Later "But where do I fit into that" hit. [06:02] i'll be severely fretting when there is no panel, i need to monitor my harddrive temperature in my laptop and it's a deal breaker :D [06:03] Hrm I wonder if a temperature indicator is the solution to that, and not just for HD, but for everything. :) [06:04] As to how one would implement that however, is another story. [06:05] Looks like Mark is having trouble with his net connection at Budapest :/ [06:05] Of course you can make your KDE look like Unity if you want too: http://zrchrn.blogspot.com/2011/05/kde-unity-setup.html [06:06] TheMuso: the performance monitor applet that i also use isn't a must have, but apparently a lot of them have changed to the new infrastructure w/gnome 3; so i'll have to wait and see really, which is a bit disconcerting [06:06] Ah ok. [06:06] i'm very very very flexible on any other changes :] === _LibertyZero is now known as LibertyZero [06:32] Hrm ok seems not yet. [06:44] Apparently the new kernel built packages are stuck up in NEW [06:51] Yeah, binary new, always the case for new kernel versions/ABI. [06:51] doko_: https://launchpad.net/ubuntu/+source/cairo/1.10.2-2ubuntu3/+buildjob/2530317 looks like a gcc bug to me, considering -lm is being passed explicitly; can you confirm? [06:53] someone ask sa-bdfl to fix his connection :/ [06:54] he might not be able to [06:54] what's going on in hungary anyways? [07:09] cdbs: design sprint I believe. [07:09] TheMuso: you probably wanted to say that to ohsix . ohsix ^^ [07:10] ohsix: Design sprint, and monday onwards will be UDS [07:10] ah [07:10] WHoops yes I did too. [07:12] TheMuso: I guess you're also at the sprint(s)? [07:12] cdbs: No, I am still at home. I fly out to UDS tomorrow. [07:12] niche [07:23] Stupid planes. [07:23] Haha [07:24] RAOF: Perhaps the airline is partly to blame, too? [07:24] StevenK: No, I think not. [07:24] I think that planes are inherently evil devices projected from a far-future where machines rule over us. [07:25] As such, the airlines are just as much a victim as the rest of us :) [07:25] heh [07:25] RAOF, trouble? [07:25] bryceh: No more than the anticipation of 34 hours worth of travel provides :) [07:25] I have often wondered whether video teleconferencing with sufficiently large pipes will ever replaces sprints/UDS... [07:25] ah [07:26] TheMuso, me too [07:26] Planes are either not fast enough or not comfortable enough. We should totally be doing international travel with huge dirigibles. [07:26] Part of me hopes not, but part of me hopes so. Its the traveling I dislike, but I enjoy my weeks at sprints/UDS. [07:26] Ubuntu Cruise Lines [07:27] sabdfl1 appears to be on a hotel's wireless ;-) [07:27] I'm sure you could fly Hobart→Budapest in a couple of days in a sufficiently awesome dirigible. [07:28] Plus! Room! [07:28] And you can get the chance to be the next Hindenberg! [07:28] TheMuso: Yeah. I really like the meeting-up-with-people parts of sprints/UDS. :) [07:28] hey, 747's have room if you take out every 2-3 rows [07:29] StevenK: Nah. I wouldn't make the airframe out of rust and aluminium :) [07:29] lol [07:29] RAOF: I think the hydrogen may have helped ... [07:29] There's an obvious solution for that, too :) [07:30] StevenK, actually I heard that probably immediately rose straight up, it was mostly the doping on the skin [07:30] StevenK: "Hindenburg" :) [07:30] pitti: Bah :-) [07:33] Speaking of travel... [07:33] * TheMuso starts collating data to transfer to notebook. [07:33] hey bryceh, informed guess :-) [07:39] RAOF: didn't I see somebody recently prototyping commercial dirigible flight for the first time in a long time? [07:42] http://en.wikipedia.org/wiki/P-791, maybe [07:45] * ScottK wants suborbital space planes. [07:46] Anywhere on earth in ~30 minutes flight time or less. [07:46] That would be very nice. [07:46] * bryceh wants subterranean high speed intercontinental mega-trains [07:47] Mind you I'd want them to not use X windows anywhere in them. [07:47] hey [07:47] lol [07:47] ScottK, as long as you're using gtk and metacity you'd be fine [07:47] Oh dear. No. [07:48] I am trying to manually merge conky. Here is the debdiff I got http://paste.ubuntu.com/603994/ I imported the changes from previous ubuntu version, What I dont understand is one extra patch file in debian/patches . That patch is not even included in series file. From where did it came? Can I remove it? [07:48] * ScottK doesn't know what people use for flight safety critical U/I work, but I'm betting that's not it. === dendro-afk is now known as dendrobates [07:50] ScottK: Actually, at XDS last year we went to a flight control research centre, where they were demonstrating X-based air traffic control terminals :) [07:50] It was neat! [07:51] * RAOF wants evacuated point-to-point tunnels dug through the Earth. 43 minutes to anywhere! [07:51] That concerns me, what about the earth's inner stability? [07:51] pneumatics people movers. hello 19th's century's 21st century! [07:53] can anyone please look at my query? :( I just posted few minutes ago. [07:53] ScottK: well, if companies are using EC2 for remote in-home monitoring of patient's heartbeats, why not :) [07:54] c2tarun: the debdiff there is old debian->old ubuntu? [07:54] ah, no, that's a NEWS at the top, not a changelog [07:54] slangasek: oh no not the top, please look at line 115 and then the series file in the end [07:54] c2tarun: is conky-1.8.0/debian/patches/debian-changes-1.8.0-1.1ubuntu1 the one you refer to? [07:55] slangasek: yes [07:55] right [07:55] slangasek: where did this file come from? [07:55] RAOF: Air traffic control systems have much less stringent requirements than the actual flight controls. [07:56] ScottK: Quite true. They're unlikely to be using a codebase as huge as X for that. [07:56] c2tarun: with dpkg 3.0 (quilt) format, changes to the upstream sources that aren't otherwise listed in the series file get automatically rolled up into a patch in debian/patches named "debian-changes-$version"; that's what you're seeing here [07:57] Which gets back to my "No X inside" request. [07:57] slangasek: hmm... so I should remove it and build the source package again? [07:58] c2tarun: the issue is that there were already "unlabeled" upstream changes in the previous version; somehow that patch is still present, plus a new patch for the new version. You should delete only the /old/ version (the one starting at line 259 of the diff, not the one at line 115) [08:16] doko_: https://launchpadlibrarian.net/71182201/buildlog_ubuntu-oneiric-armel.cmake_2.8.4%2Bdfsg.1-2ubuntu1_FAILEDTOBUILD.txt.gz looks very like the doxygen failure. Is there some thing that's changed in gcc 4.6 that's related to this? === dendrobates is now known as dendro-afk [08:24] ScottK: Nope. Natty amd64. === Guest832 is now known as lag === lag is now known as Guest57644 [08:30] armel building completely fixed now ? === hunger_ is now known as hunger [08:58] popey: whee, bounty. thanks. :) [09:01] RAOF: I happened to notice (while sponsoring it) that pbuilder in oneiric now claims support for linux-any, FYI [09:02] cjwatson: Funky. Less pointless diff from debian needed! [09:09] slangasek: maybe, in this case, just build without -flto [09:13] ScottK: https://bugs.launchpad.net/gcc-linaro/+bug/675347 looks bit same issue ? [09:13] Ubuntu bug 675347 in Linaro GCC Tracking "volatile int causes inline assembly build failure" [Undecided,Fix committed] [09:13] Can someone tell me if the linux sata driver for JMicron JMB362 PCIe to SATA bridge chip would support SATA TRIM commands for use with SSD's? [09:14] ntr0py: I would checkout the kernel for that :) [09:16] dupondje: well i have do admit I am not sure if i am able to read the kernel src accordingly to that... [09:17] doko_: ok. that's a bit more awkward than it ought to be, the upstream configure script enables -flto forcibly if supported and has no option to turn it off, hmph [09:17] doko_: but yeah, will patch 'n' such [09:17] slangasek: but please file a bug about it (gcc-4.5) [09:18] 4.6 I mean [09:18] doko_: yep, already filed :-) [09:19] james_w`: would it be possible to make lp:ubuntu/pkgbinarymangler an alias for lp:~ubuntu-core-dev/pkgbinarymangler/ubuntu instead of the autoimport/ [09:19] ? [09:28] slangasek: fun, I already ran through process-removals two days ago; there were still hundreds of packages for you? === doko_ is now known as doko [09:29] pitti: yes, because if you just run process-removals by itself, it only looks at removals done during the current calendar year [09:29] ah [09:29] so I think I'll extend it to give it a "last year" option or something, to grab the rotated removal logs too [09:30] ntr0py: the driver for it (ahci) has TRIM support [09:30] but don't know if its perfect yet :) [09:30] use at least natty's kernel [09:30] (we could just always use removals-full.txt, but that would be slow) [09:30] slangasek: yeah, and catch stuff like firefox over and over [09:31] well, anything that's in the sync blacklist is ignored by process-removals [09:32] slangasek: are you at some hands, or already adjusting for the new timezone? [09:32] dupondje: yes its claimed to support ahci 1.0 / ncq. Thank you for that information, i will give it a try :) [09:33] doko: neither, I'm just up late trying to catch up with y'all over there in Europe :) [09:35] ScottK: is this a new Qt version too? I didn't see doxygen ftbfs in the natty armel rebuild test === axp2_ is now known as axp2 [09:38] doko: https://launchpad.net/ubuntu/+source/doxygen/1.7.4-1/+buildjob/2521181/+files/buildlog_ubuntu-oneiric-armel.doxygen_1.7.4-1_FAILEDTOBUILD.txt.gz [09:39] dupondje: you did sync it manually, so can you fix it manually? ;p [09:40] doko: it looks alot like https://bugs.launchpad.net/gcc-linaro/+bug/675347 [09:40] Ubuntu bug 675347 in Linaro GCC Tracking "volatile int causes inline assembly build failure" [Undecided,Fix committed] [09:41] dupondje: gcc-4.6 currently is not build from linaro sources [09:56] uh, perl 5.12 changed the behaviour of split(), which broke pkgbinarymangler (fixing now); I hope it won't break too much other stuff [10:15] looks like there are some stray binaries in the archive [10:15] for example pool/universe/libi/libipoddevice/ipod_0.5.3-3.2ubuntu2_amd64.deb [10:15] which managed to go backward in version due to being deleted and reuploaded I guess: https://launchpad.net/ubuntu/+source/libipoddevice/+publishinghistory [10:16] srsly? blah [10:16] Laney: isn't that very explicitely forbidden? [10:16] apparently not by soyuz [10:17] I mean by policy [10:17] that was on the list of source packages I processed removals of this week as part of the cleanup; let me see why the binaries are still there [10:17] slangasek: that wasn't the version which was published in oneiric when you did the removal [10:17] yet it is nevertheless referenced by oneiric's packages file [10:18] yes, I see that - they're from a future version that was never in any release beyond lucid, ick [10:18] fun :) [10:18] Chipzz: yes [10:18] how did that get there at all?! [10:19] slangasek: someone needs a slap on the wrists? [10:19] pitti: to be fair, split in void context was already deprecate [10:19] *deprecated [10:19] I found out because it makes ben die [10:19] *wrist [10:19] only after we congratulate them on their magic trick [10:19] Laney: binaries shot [10:20] they should bleed to death over the next hour or so [10:20] slangasek: all affected or just libipoddevice? [10:20] Laney: all affected [10:20] nice, thanks [10:20] which is to say, ipod, libipoddevice0, libipoddevice-dev [10:20] oh, no — I think there were some from other sources [10:20] let me see [10:21] oh; how are you finding them? [10:21] running ben and seeing where it cries at me :-) [10:21] heh [10:21] what's ben? [10:21] debian's transition tracker [10:21] slangasek: MoM's son? ;) [10:21] release.d.o/transitions [10:21] jamespage: synced rhino from experimental, discarding your no-change changes [10:22] Laney: ah [10:22] figured it would be useful for us too [10:23] Fatal error: exception Failure("warning: Binary (libre2-dev,armel) without Source! [10:23] ") [10:23] hnngh [10:23] oh, those are out-of-date binaries at least, so that's easy enough to explain [10:24] * pitti wonders why the buildds suddenly stopped grabbing stuff [10:24] hmm, these should show up on the NBS page, shouldn't they [10:25] Laney: right, these are caught by http://people.canonical.com/~ubuntu-archive/NBS/, so I'm inclined to let nature take its course [10:25] which is to say: someone else will get to them, and I will go to bed before falling asleep in my chair [10:26] ok [10:26] thanks for your help [10:26] slangasek: already practicing for European tz? [10:27] pitti: something to that effect :) [10:28] slangasek: you really want http://people.canonical.com/~ubuntu-archive/nbs.html instead these days, BTW [10:28] oooh color [10:28] thanks :) [10:29] and automatic cluster detectino :) [10:30] yeah, I'd appreciate it if someone could clean those up :-) [10:30] maybe I should fix it to skip over these instead of bailing [10:31] the powerpc kernel looks like a false positive [10:31] I only just binary NEWed 2.6.39-1 [10:32] oh, it's not [10:32] cleaning up then [10:32] yeah, it's fine to clean up, we haven't done a d-i build against 2.6.39 yet anyway [10:32] will also make it easier to read [10:32] right [10:33] not that worried about this yet, not with half of the archive still being uninstallable anyway [10:37] FWIW, lp-remove-package.py vomits on ipod as well [10:38] pitti, slangasek: It's because libipoddevice was removed like 10 minutes after it was uploaded. [10:38] (and libipoddevice-dev) [10:38] The new upload hadn't been published yet, so the old one wasn't superseded. [10:38] ah, so it should become removable in a bit? [10:38] So lp-remove-package marked the new one as Deleted, so there was nothing to supersede the old one. [10:38] I'm not sure what's going on with the binaries. [10:38] Need to check how lp-remove-package determines binary candidates. [10:39] wgrant: did that break something else in soyuz by any chance? since the hour the buildds stopped grabbing stuff [10:39] seems they went on strike [10:39] pitti: There's an upgrade in progress that needed buildd-manager down for a while. It's not back yet. [10:40] Looks like the upgrade is pretty much done now, though. [10:40] ah [10:41] pitti: What happens if you try to do a binary-only removal? [10:41] They should basically be NBS. [10:41] wgrant: that's what I tried [10:42] wgrant: should I try a sourceful one? [10:42] lp-remove-package.py -u $SUDO_USER -m NBS -b -y libipoddevice0 [10:42] pitti: There's no source, so no. What's the error? [10:42] (is our standard command) [10:42] wgrant: http://paste.ubuntu.com/604024/ [10:43] perhaps it's already gone, and the publisher just needs to pick it up? [10:43] (and consequently nbs.html) [10:43] * wgrant checks [10:43] https://launchpad.net/ubuntu/oneiric/i386/libipoddevice0 [10:43] It's gone already. [10:43] slangasek: Did you explicitly remove the binaries, separately from the source? [10:44] ah, buildds back on business, nice [10:44] Yeah, sorry about that. Backwards-incompatible changes meant our nodowntime deployment had to take down buildd-manager for longer than usual. [10:45] wgrant: they were stray binaries which apparently didn't get removed in lucid (or something) [10:45] https://launchpad.net/ubuntu/+source/libipoddevice/+publishinghistory [10:45] see the version ordering [10:45] Laney: I know how they got there, and what's up with them, but I'm wondering how they were removed. [10:45] Because they're gone from oneiric now, and a source removal shouldn't have done it. [10:45] Or we have *another* bug. [10:45] Which is not unlikely, but still. [10:46] well, 06/05 10:19:59 Laney: binaries shot [10:46] Laney: I talked to wgrant in #launchpad about it: it was bad timing: pitti deleted libipoddevice (after his upload to lucid) before the publisher managed to supersede the previous version [10:46] Ah, missed that line. [10:47] Yeah, so please don't delete things 10 minutes after you upload them for now :) [10:47] Then everything should be happy. [10:47] heh [10:48] Still doesn't explain why the binaries got left around. [10:48] But that might just be because lp-remove-package is ancient and broken. [10:48] wgrant: is it preferred to use launchpadlib? [10:49] wgrant: I recently wrote some launchpadlib code to do SRU processing, should not be hard to write a client-side replacement for removal as well [10:49] (in fact, my "clean up langpack PPA" already does that) [10:49] pitti: lp-remove-package is best for the primary archive, unfortunately, since permissions aren't sorted out for deletion on primary archives. [10:49] Right, you own the PPA, so you have full control. [10:50] Although I guess you might own the Ubuntu primary archive too. [10:50] But in general we want to change it so any queue admin can use requestDeletion. [10:50] But we're not there yet. [10:50] And then, yes, that script can die. Rapidly. [10:50] doko:ack - any idea with 1.7R3 will actually hit release status? [10:59] jamespage: no idea :-/ but needed by openjdk-7 [11:00] doko: yeah - I saw. [11:00] wgrant: FWIW, the main stumbling block that I currently have are these forced timeouts [11:00] wgrant: that's what breaks half of my package copies, for which I have to resort to ssh cocoplum/copy-package.py [11:01] pitti: Copies from where to where? [11:01] same for the +queue page and qeue accept [11:01] pitti: I know that copies from private PPAs time out a lot now. [11:01] But normal syncSource calls to/from public archives should be fairly fast. [11:01] unfortunately lifeless etc. seem relucatant to disable or increase the timeout for +queue [11:01] wgrant: -proposed to -updates [11:01] pitti: Oh, you use the API for that? [11:01] wgrant: for some kinds of packages (could be the ones with lots of bug refs) it takes aaages [11:02]