[00:02] <bdrung_> ttx: what does tomcat have to do with eclipse ( https://blueprints.launchpad.net/ubuntu/+spec/server-o-tomcat7-packaging )?
[00:15] <ohsix> bdrung_: the jdt has project types that start, add modules & run tomcat instances in the project, iirc
[00:16] <bdrung_> aha
[00:23] <SpamapS> everything in Java is connected like that
[00:23] <SpamapS> its like the borg that way
[00:33] <TheMuso> Do the launchpad buildds support linux-any in any form yet?
[00:34] <RAOF> TheMuso: I thought that was purely a pbuilder problem; I've been happily building and uploading linux-any packages.
[00:34] <RAOF> (And they seem to build on launchpad, too ☺)
[00:36] <TheMuso> Ok thanks, will just use it and see how things go.
[00:36]  * TheMuso uses sbuild anyway, so...
[00:36] <RAOF> 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] <TheMuso> Right.
[03:02] <phungvantu> hi all
[03:45] <ohsix> is felix geyer here on irc?
[03:46] <ohsix> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/753370 the root of their problem was using an informational string as api
[03:47] <ohsix> Sarvatt: you're the best :]
[03:49] <RAOF> ohsix: There was a nice big mesa-dev thread about not parsing GL_VENDOR for blacklists.
[03:49] <ohsix> ok cool
[03:49] <ohsix> i saw anholt commented on the blag where the guy was raging about it
[03:50] <ohsix> 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] <ohsix> (if you can gmane me to that thread i'd appreciate it)
[03:53] <ohsix> martin (the loud guy) was pretty off base calling it the only solution, to restore some past badness he was already doing
[03:53] <RAOF> ohsix: http://article.gmane.org/gmane.comp.video.mesa3d.devel/25597
[03:53] <ohsix> thanks
[03:54] <RAOF> There's a bit before that which was in another thread.
[03:55] <ohsix> the more the better, i wanna confirm my own prejudices! :D
[03:58] <ohsix> eugh even on the bug they suggest changes that include strstr, which is another VERBOTEN thing, prefixes aren't unique
[04:07] <ScottK> ohsix: So you think this was appropriate for a point release to drop?
[04:08] <ohsix> yes
[04:08] <ScottK> 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] <ohsix> it's akin to internal debug message strings that aren't translated being changed
[04:08] <ohsix> the problem is they were relying on it, not that it changed; it's an opengl thing they should know
[04:09] <ScottK> 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] <ohsix> 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] <ScottK> Separate issue.
[04:09] <ohsix> oh i don't minimize that they have a problem they'll have to deal with
[04:09] <ScottK> They are reworking it for KDE 4.7.
[04:10] <ScottK> But for 4.6 they are stuck.
[04:10] <ohsix> but the problem existed before they knew it was a problem
[04:10] <ScottK> That doesn't parse.
[04:10] <ohsix> 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] <ScottK> We shouldn't have to regression test point releases for stuff upstreams removed on purpose.
[04:10] <ohsix> the problem = relying on the _RENDERER and _VENDOR string for stuff
[04:11] <ohsix> they have other problems with using strstr on _EXTENSIONS too
[04:11] <ScottK> Fine, so drop it in a proper development release.
[04:11] <ohsix> haha
[04:11] <ScottK> It's like mesa is going out of it's way to break stuff.
[04:11] <ohsix> 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] <ScottK> I understand that breaking already released software is poor form.
[04:12] <ohsix> it isn't ambiguous at all, but it seems martin went and did exactly the wrong thing
[04:12] <ohsix> 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] <ohsix> with their use of strstr you can break their software by introducing support for an extension
[04:12] <ohsix> it's a non sequitor
[04:13] <ohsix> 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] <ohsix> it's easier on platforms with a dynamic linker but you generally can't take advantage of that
[04:14] <ScottK> Felix IRCs as debfx, btw.
[04:14] <ohsix> ok thank you
[04:15] <ScottK> 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] <ScottK> No reason it couldn't have waited for the next development cycle, even if it was technically internal.
[04:15] <ohsix> 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] <ohsix> those strings can change with the weather
[04:16] <ScottK> Apparently.
[04:16] <ohsix> generally stuff is only appended, like with "SSE2/MMX" and stuff
[04:16] <ohsix> but at best they're for telling an operator about something, it's devoid of information useful for a program
[04:16] <ScottK> Generally I think stuff should be removed during development, not in maintenance releases.
[04:17] <ohsix> i agree
[04:17] <ScottK> 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] <ScottK> defact/defacto
[04:17] <ohsix> 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] <ScottK> If it'd been in a new development release, I think there would have been no reason to bitch.
[04:18] <ohsix> 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] <ScottK> 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] <ohsix> i'd probably be right with martin if that was the point he was making, the one you are
[04:19] <ScottK> I've discussed it with him.
[04:19] <ohsix> 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] <ScottK> This is no doubt not the only point he had, but it was surely one of them.
[04:19] <ScottK> To draw a parallel from the real world, just because it's legal, doesn't make it a good idea.
[04:20] <ScottK> This may not have been technically an ABI break, but that doesn't make it just fine either.
[04:20] <ScottK> We patched it back in with AFAIK zero bad effect.
[04:20] <ohsix> i would do it in spite of the people that use it
[04:20] <ohsix> because the spec says i'm ok :]
[04:21] <ScottK> Which is not a very accommodating way to develop the joint FOSS ecosystem.
[04:21] <ohsix> well it's devoid of informational content
[04:21] <ScottK> It doesn't excuse gratuitous changes.
[04:21] <ohsix> 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] <ScottK> I'm not saying he was right to rely on it, but he did.
[04:22] <ohsix> yea, ad-hoc
[04:22] <ohsix> nbd
[04:24] <ScottK> If there was more reason for doing it than "because we can" I might be more sympathetic.
[04:25] <ohsix> 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] <ohsix> but it still didn't mean what he took it to mean
[04:26] <ohsix> 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] <ScottK> Sometimes one is forced to do things one would rather not do.
[04:29] <ScottK> I'm not sure why he latched onto that.
[04:29] <ohsix> me either
[04:30] <ScottK> I'm glad the ubuntu-x people were willing to patch it back in or Kubuntu would have been screwed.
[04:30] <ScottK> Here at the distro level we were pretty much stuck between a rock and a hard place.
[04:31] <ohsix> yea
[04:31] <ohsix> it makes sense to argue for having it temporarily added back
[04:32] <ScottK> My only bitch was that it was removed in a maintenance update.
[04:32] <ohsix> but not to shore it up by defending the silly thing you did
[04:32] <ScottK> From what I know the removal was reasonable, just the timing could have been better.
[04:32] <ScottK> People are like that.
[04:32] <ohsix> 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] <ohsix> their rules might be too rigid if they can't fix something like bad opengl version checking in a minor series, too
[04:36] <ohsix> theres always exceptions, this one might not meet the standard but there will be stuff that will
[04:36] <ScottK> It depends on how invasive the change would have been and what other regression risk it brought.
[04:36] <ScottK> I'm not a kwin developer, so I can't judge.
[04:37] <ohsix> 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:38] <ScottK> Agreed. That's a pretty recent release to be relying on.
[04:39] <ScottK> ohsix: When he says "Unfortunately version, vendor and renderer are the only information queryable just with OpenGL API." is that accurate?
[04:39] <ohsix> he's not wrong, but that doesn't speak to what information you actually get
[04:40] <ohsix> all those strings can be "HURF DURF" and not be wrong
[04:40] <ScottK> 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] <ohsix> 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] <ScottK> Sounds substantially more complex.
[04:42] <ohsix> 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] <ohsix> 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] <ScottK> I have a $work project I need to get back to.
[04:43] <ohsix> :]
[04:50] <ohsix> "users of working drivers (e.g. NVIDIA)" gag
[05:43] <pitti> Good morning
[05:43] <pitti> SpamapS: uh, we ship with that since lucid, don't we?
[05:52] <abhinav-> 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] <cdbs> 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] <abhinav-> Those methods were removed from gtk3
[05:53] <ScottK> cdbs: If people don't like what Ubuntu is providing, I'd like them to be aware of the alternatives.
[05:53] <ScottK> I think it's better for the project if such people don't leave.
[05:53] <ScottK> OTOH, more users == more work, so it's not like it particularly helps me personally.
[05:54] <cdbs> 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] <pitti> 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] <ScottK> The problem is that many experienced computer users simply aren't in the Gnome 3/Unity target market.
[05:55] <cdbs> 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] <TheMuso> 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] <ohsix> pitti: linux isn't about choice :D
[05:55] <cdbs> they forget the fact that GNOME Shell, KDE, XFCE, LXDE are all alternatives, and can run perfectly on their beloved Ubuntu stack
[05:55] <ScottK> 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] <ohsix> cdbs: is that list tracked on gmane? url?
[05:56] <ScottK> TheMuso: It would be nice if the terminology matched this perspective.
[05:56] <TheMuso> ScottK: I am enclined to agree.
[05:57] <cdbs> ohsix: Its a recent discussion on -devel-discuss, and there were many similar ones in april as well
[05:57] <ohsix> cdbs: ok thanks
[05:59] <TheMuso> Is it possible to run 3D acceleration in KVM yet?
[05:59] <ScottK> 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] <cdbs> 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] <ScottK> cdbs: See my earlier comment about "not in the target market".
[06:00] <cdbs> hmm
[06:01] <ScottK> 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] <ohsix> 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] <TheMuso> Hrm I wonder if a temperature indicator is the solution to that, and not just for HD, but for everything. :)
[06:04] <TheMuso> As to how one would implement that however, is another story.
[06:05] <cdbs> Looks like Mark is having trouble with his net connection at Budapest :/
[06:05] <ScottK> 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] <ohsix> 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] <TheMuso> Ah ok.
[06:06] <ohsix> i'm very very very flexible on any other changes :]
[06:32] <TheMuso> Hrm ok seems not yet.
[06:44] <cdbs> Apparently the new kernel built packages are stuck up in NEW
[06:51] <TheMuso> Yeah, binary new, always the case for new kernel versions/ABI.
[06:51] <slangasek> 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] <cdbs> someone ask sa-bdfl to fix his connection :/
[06:54] <ohsix> he might not be able to
[06:54] <ohsix> what's going on in hungary anyways?
[07:09] <TheMuso> cdbs: design sprint I believe.
[07:09] <cdbs> TheMuso: you probably wanted to say that to ohsix . ohsix ^^
[07:10] <cdbs> ohsix: Design sprint, and monday onwards will be UDS
[07:10] <ohsix> ah
[07:10] <TheMuso> WHoops yes I did too.
[07:12] <cdbs> TheMuso: I guess you're also at the sprint(s)?
[07:12] <TheMuso> cdbs: No, I am still at home. I fly out to UDS tomorrow.
[07:12] <cdbs> niche
[07:23] <RAOF> Stupid planes.
[07:23] <StevenK> Haha
[07:24] <StevenK> RAOF: Perhaps the airline is partly to blame, too?
[07:24] <RAOF> StevenK: No, I think not.
[07:24] <RAOF> I think that planes are inherently evil devices projected from a far-future where machines rule over us.
[07:25] <RAOF> As such, the airlines are just as much a victim as the rest of us :)
[07:25] <bryceh> heh
[07:25] <bryceh> RAOF, trouble?
[07:25] <RAOF> bryceh: No more than the anticipation of 34 hours worth of travel provides :)
[07:25] <TheMuso> I have often wondered whether video teleconferencing with sufficiently large pipes will ever replaces sprints/UDS...
[07:25] <bryceh> ah
[07:26] <bryceh> TheMuso, me too
[07:26] <RAOF> Planes are either not fast enough or not comfortable enough.  We should totally be doing international travel with huge dirigibles.
[07:26] <TheMuso> 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] <bryceh> Ubuntu Cruise Lines
[07:27] <bryceh> sabdfl1 appears to be on a hotel's wireless ;-)
[07:27] <RAOF> I'm sure you could fly Hobart→Budapest in a couple of days in a sufficiently awesome dirigible.
[07:28] <RAOF> Plus!  Room!
[07:28] <StevenK> And you can get the chance to be the next Hindenberg!
[07:28] <RAOF> TheMuso: Yeah.  I really like the meeting-up-with-people parts of sprints/UDS.  :)
[07:28] <bryceh> hey, 747's have room if you take out every 2-3 rows
[07:29] <RAOF> StevenK: Nah.  I wouldn't make the airframe out of rust and aluminium :)
[07:29] <TheMuso> lol
[07:29] <StevenK> RAOF: I think the hydrogen may have helped ...
[07:29] <RAOF> There's an obvious solution for that, too :)
[07:30] <bryceh> StevenK, actually I heard that probably immediately rose straight up, it was mostly the doping on the skin
[07:30] <pitti> StevenK: "Hindenburg" :)
[07:30] <StevenK> pitti: Bah :-)
[07:33] <TheMuso> Speaking of travel...
[07:33]  * TheMuso starts collating data to transfer to notebook.
[07:33] <sabdfl> hey bryceh, informed guess :-)
[07:39] <slangasek> RAOF: didn't I see somebody recently prototyping commercial dirigible flight for the first time in a long time?
[07:42] <slangasek> http://en.wikipedia.org/wiki/P-791, maybe
[07:45]  * ScottK wants suborbital space planes.
[07:46] <ScottK> Anywhere on earth in ~30 minutes flight time or less.
[07:46] <TheMuso> That would be very nice.
[07:46]  * bryceh wants subterranean high speed intercontinental mega-trains
[07:47] <ScottK> Mind you I'd want them to not use X windows anywhere in them.
[07:47] <bryceh> hey
[07:47] <TheMuso> lol
[07:47] <bryceh> ScottK, as long as you're using gtk and metacity you'd be fine
[07:47] <ScottK> Oh dear.  No.
[07:48] <c2tarun> 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.
[07:50] <RAOF> 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] <RAOF> It was neat!
[07:51]  * RAOF wants evacuated point-to-point tunnels dug through the Earth.  43 minutes to anywhere!
[07:51] <TheMuso> That concerns me, what about the earth's inner stability?
[07:51] <bryceh> pneumatics people movers. hello 19th's century's 21st century!
[07:53] <c2tarun> can anyone please look at my query? :( I just posted few minutes ago.
[07:53] <slangasek> ScottK: well, if companies are using EC2 for remote in-home monitoring of patient's heartbeats, why not :)
[07:54] <slangasek> c2tarun: the debdiff there is old debian->old ubuntu?
[07:54] <slangasek> ah, no, that's a NEWS at the top, not a changelog
[07:54] <c2tarun> slangasek: oh no not the top, please look at line 115 and then the series file in the end
[07:54] <slangasek> c2tarun: is conky-1.8.0/debian/patches/debian-changes-1.8.0-1.1ubuntu1 the one you refer to?
[07:55] <c2tarun> slangasek: yes
[07:55] <slangasek> right
[07:55] <c2tarun> slangasek: where did this file come from?
[07:55] <ScottK> RAOF: Air traffic control systems have much less stringent requirements than the actual flight controls.
[07:56] <RAOF> ScottK: Quite true.  They're unlikely to be using a codebase as huge as X for that.
[07:56] <slangasek> 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] <ScottK> Which gets back to my "No X inside" request.
[07:57] <c2tarun> slangasek: hmm... so I should remove it and build the source package again?
[07:58] <slangasek> 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] <ScottK> 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?
[08:24] <soren> ScottK: Nope. Natty amd64.
[08:30] <dupondje> armel building completely fixed now ?
[08:58] <cjwatson> popey: whee, bounty.  thanks. :)
[09:01] <cjwatson> RAOF: I happened to notice (while sponsoring it) that pbuilder in oneiric now claims support for linux-any, FYI
[09:02] <RAOF> cjwatson: Funky.  Less pointless diff from debian needed!
[09:09] <doko_> slangasek: maybe, in this case, just build without -flto
[09:13] <dupondje> ScottK: https://bugs.launchpad.net/gcc-linaro/+bug/675347 looks bit same issue ?
[09:13] <ntr0py>  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] <dupondje> ntr0py: I would checkout the kernel for that :)
[09:16] <ntr0py> dupondje: well i have do admit I am not sure if i am able to read the kernel src accordingly to that...
[09:17] <slangasek> 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] <slangasek> doko_: but yeah, will patch 'n' such
[09:17] <doko_> slangasek: but please file a bug about it (gcc-4.5)
[09:18] <doko_> 4.6 I mean
[09:18] <slangasek> doko_: yep, already filed :-)
[09:19] <pitti> 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] <pitti> ?
[09:28] <pitti> slangasek: fun, I already ran through process-removals two days ago; there were still hundreds of packages for you?
[09:29] <slangasek> pitti: yes, because if you just run process-removals by itself, it only looks at removals done during the current calendar year
[09:29] <pitti> ah
[09:29] <slangasek> 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] <dupondje> ntr0py: the driver for it (ahci) has TRIM support
[09:30] <dupondje> but don't know if its perfect yet :)
[09:30] <dupondje> use at least natty's kernel
[09:30] <slangasek> (we could just always use removals-full.txt, but that would be slow)
[09:30] <pitti> slangasek: yeah, and catch stuff like firefox over and over
[09:31] <slangasek> well, anything that's in the sync blacklist is ignored by process-removals
[09:32] <doko> slangasek: are you at some hands, or already adjusting for the new timezone?
[09:32] <ntr0py> dupondje: yes its claimed to support ahci 1.0 / ncq. Thank you for that information, i will give it a try :)
[09:33] <slangasek> doko: neither, I'm just up late trying to catch up with y'all over there in Europe :)
[09:35] <doko> ScottK: is this a new Qt version too? I didn't see doxygen ftbfs in the natty armel rebuild test
[09:38] <dupondje> 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] <doko> dupondje: you did sync it manually, so can you fix it manually? ;p
[09:40] <dupondje> doko: it looks alot like https://bugs.launchpad.net/gcc-linaro/+bug/675347
[09:41] <doko> dupondje: gcc-4.6 currently is not build from linaro sources
[09:56] <pitti> 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] <Laney> looks like there are some stray binaries in the archive
[10:15] <Laney> for example pool/universe/libi/libipoddevice/ipod_0.5.3-3.2ubuntu2_amd64.deb
[10:15] <Laney> which managed to go backward in version due to being deleted and reuploaded I guess: https://launchpad.net/ubuntu/+source/libipoddevice/+publishinghistory
[10:16] <slangasek> srsly?  blah
[10:16] <Chipzz> Laney: isn't that very explicitely forbidden?
[10:16] <Laney> apparently not by soyuz
[10:17] <Chipzz> I mean by policy
[10:17] <slangasek> 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] <Laney> slangasek: that wasn't the version which was published in oneiric when you did the removal
[10:17] <Laney> yet it is nevertheless referenced by oneiric's packages file
[10:18] <slangasek> yes, I see that - they're from a future version that was never in any release beyond lucid, ick
[10:18] <Laney> fun :)
[10:18] <cjwatson> Chipzz: yes
[10:18] <slangasek> how did that get there at all?!
[10:19] <Chipzz> slangasek: someone needs a slap on the wrists?
[10:19] <cjwatson> pitti: to be fair, split in void context was already deprecate
[10:19] <cjwatson> *deprecated
[10:19] <Laney> I found out because it makes ben die
[10:19] <Chipzz> *wrist
[10:19] <slangasek> only after we congratulate them on their magic trick
[10:19] <slangasek> Laney: binaries shot
[10:20] <slangasek> they should bleed to death over the next hour or so
[10:20] <Laney> slangasek: all affected or just libipoddevice?
[10:20] <slangasek> Laney: all affected
[10:20] <Laney> nice, thanks
[10:20] <slangasek> which is to say, ipod, libipoddevice0, libipoddevice-dev
[10:20] <Laney> oh, no — I think there were some from other sources
[10:20] <Laney> let me see
[10:21] <slangasek> oh; how are you finding them?
[10:21] <Laney> running ben and seeing where it cries at me :-)
[10:21] <slangasek> heh
[10:21] <slangasek> what's ben?
[10:21] <Laney> debian's transition tracker
[10:21] <Chipzz> slangasek: MoM's son? ;)
[10:21] <Laney> release.d.o/transitions
[10:21] <doko> jamespage: synced rhino from experimental, discarding your no-change changes
[10:22] <slangasek> Laney: ah
[10:22] <Laney> figured it would be useful for us too
[10:23] <Laney> Fatal error: exception Failure("warning: Binary (libre2-dev,armel) without Source!
[10:23] <Laney> ")
[10:23] <slangasek> hnngh
[10:23] <slangasek> 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] <slangasek> hmm, these should show up on the NBS page, shouldn't they
[10:25] <slangasek> 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] <slangasek> which is to say: someone else will get to them, and I will go to bed before falling asleep in my chair
[10:26] <Laney> ok
[10:26] <Laney> thanks for your help
[10:26] <pitti> slangasek: already practicing for European tz?
[10:27] <slangasek> pitti: something to that effect :)
[10:28] <cjwatson> slangasek: you really want http://people.canonical.com/~ubuntu-archive/nbs.html instead these days, BTW
[10:28] <slangasek> oooh color
[10:28] <slangasek> thanks :)
[10:29] <pitti> and automatic cluster detectino :)
[10:30] <Laney> yeah, I'd appreciate it if someone could clean those up :-)
[10:30] <Laney> maybe I should fix it to skip over these instead of bailing
[10:31] <pitti> the powerpc kernel looks like a false positive
[10:31] <cjwatson> I only just binary NEWed 2.6.39-1
[10:32] <pitti> oh, it's not
[10:32] <pitti> cleaning up then
[10:32] <cjwatson> yeah, it's fine to clean up, we haven't done a d-i build against 2.6.39 yet anyway
[10:32] <pitti> will also make it easier to read
[10:32] <pitti> right
[10:33] <pitti> not that worried about this yet, not with half of the archive still being uninstallable anyway
[10:37] <pitti> FWIW, lp-remove-package.py vomits on ipod as well
[10:38] <wgrant> pitti, slangasek: It's because libipoddevice was removed like 10 minutes after it was uploaded.
[10:38] <pitti> (and libipoddevice-dev)
[10:38] <wgrant> The new upload hadn't been published yet, so the old one wasn't superseded.
[10:38] <pitti> ah, so it should become removable in a bit?
[10:38] <wgrant> So lp-remove-package marked the new one as Deleted, so there was nothing to supersede the old one.
[10:38] <wgrant> I'm not sure what's going on with the binaries.
[10:38] <wgrant> Need to check how lp-remove-package determines binary candidates.
[10:39] <pitti> wgrant: did that break something else in soyuz by any chance? since the hour the buildds stopped grabbing stuff
[10:39] <pitti> seems they went on strike
[10:39] <wgrant> pitti: There's an upgrade in progress that needed buildd-manager down for a while. It's not back yet.
[10:40] <wgrant> Looks like the upgrade is pretty much done now, though.
[10:40] <pitti> ah
[10:41] <wgrant> pitti: What happens if you try to do a binary-only removal?
[10:41] <wgrant> They should basically be NBS.
[10:41] <pitti> wgrant: that's what I tried
[10:42] <pitti> wgrant: should I try a sourceful one?
[10:42] <pitti> lp-remove-package.py -u $SUDO_USER -m NBS -b -y libipoddevice0
[10:42] <wgrant> pitti: There's no source, so no. What's the error?
[10:42] <pitti> (is our standard command)
[10:42] <pitti> wgrant: http://paste.ubuntu.com/604024/
[10:43] <pitti> perhaps it's already gone, and the publisher just needs to pick it up?
[10:43] <pitti> (and consequently nbs.html)
[10:43]  * wgrant checks
[10:43] <wgrant> https://launchpad.net/ubuntu/oneiric/i386/libipoddevice0
[10:43] <wgrant> It's gone already.
[10:43] <wgrant> slangasek: Did you explicitly remove the binaries, separately from the source?
[10:44] <pitti> ah, buildds back on business, nice
[10:44] <wgrant> Yeah, sorry about that. Backwards-incompatible changes meant our nodowntime deployment had to take down buildd-manager for longer than usual.
[10:45] <Laney> wgrant: they were stray binaries which apparently didn't get removed in lucid (or something)
[10:45] <Laney> https://launchpad.net/ubuntu/+source/libipoddevice/+publishinghistory
[10:45] <Laney> see the version ordering
[10:45] <wgrant> Laney: I know how they got there, and what's up with them, but I'm wondering how they were removed.
[10:45] <wgrant> Because they're gone from oneiric now, and a source removal shouldn't have done it.
[10:45] <wgrant> Or we have *another* bug.
[10:45] <wgrant> Which is not unlikely, but still.
[10:46] <Laney> well, 06/05 10:19:59 <slangasek> Laney: binaries shot
[10:46] <geser> 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] <wgrant> Ah, missed that line.
[10:47] <wgrant> Yeah, so please don't delete things 10 minutes after you upload them for now :)
[10:47] <wgrant> Then everything should be happy.
[10:47] <Laney> heh
[10:48] <wgrant> Still doesn't explain why the binaries got left around.
[10:48] <wgrant> But that might just be because lp-remove-package is ancient and broken.
[10:48] <pitti> wgrant: is it preferred to use launchpadlib?
[10:49] <pitti> 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] <pitti> (in fact, my "clean up langpack PPA" already does that)
[10:49] <wgrant> pitti: lp-remove-package is best for the primary archive, unfortunately, since permissions aren't sorted out for deletion on primary archives.
[10:49] <wgrant> Right, you own the PPA, so you have full control.
[10:50] <wgrant> Although I guess you might own the Ubuntu primary archive too.
[10:50] <wgrant> But in general we want to change it so any queue admin can use requestDeletion.
[10:50] <wgrant> But we're not there yet.
[10:50] <wgrant> And then, yes, that script can die. Rapidly.
[10:50] <jamespage> doko:ack - any idea with 1.7R3 will actually hit release status?
[10:59] <doko> jamespage: no idea :-/  but needed by openjdk-7
[11:00] <jamespage> doko: yeah - I saw.
[11:00] <pitti> wgrant: FWIW, the main stumbling block that I currently have are these forced timeouts
[11:00] <pitti> wgrant: that's what breaks half of my package copies, for which I have to resort to ssh cocoplum/copy-package.py
[11:01] <wgrant> pitti: Copies from where to where?
[11:01] <pitti> same for the +queue page and qeue accept
[11:01] <wgrant> pitti: I know that copies from private PPAs time out a lot now.
[11:01] <wgrant> But normal syncSource calls to/from public archives should be fairly fast.
[11:01] <pitti> unfortunately lifeless etc. seem relucatant to disable or increase the timeout for +queue
[11:01] <pitti> wgrant: -proposed to -updates
[11:01] <wgrant> pitti: Oh, you use the API for that?
[11:01] <pitti> wgrant: for some kinds of packages (could be the ones with lots of bug refs) it takes aaages
[11:02] <pitti> wgrant: yes
[11:02] <wgrant> pitti: Bugs are the big problem in queue accepts at the moment. Not sure about copies.
[11:02] <pitti> wgrant: and +queue page for accepting/NEWing stuff
[11:02] <pitti> wgrant: copying to -updates autocloses bugs, I suspect that's it
[11:02] <wgrant> If you can get me an OOPS ID for a copy I can have a look. But most of them are the known private->public copy issue.
[11:02] <wgrant> Yeah.
[11:03] <pitti> wgrant: next time I publish an SRU
[11:03] <wgrant> pitti: I'll look through the reports and see if I can find one.
[11:03] <wgrant> pitti: What day did you see them?
[11:03] <pitti> wgrant: throughout the last two weeks
[11:03]  * wgrant syncs the lot.
[11:04] <pitti> wgrant: unity was one package where it happened, eclipse another
[11:04] <pitti> (in case that helps)
[11:04] <pitti> openoffice.org was one from yesterday
[11:05] <pitti> (natty-proposed -> -updates)
[11:05] <wgrant> pitti: That helps a lot, thanks.
[11:05] <wgrant> pitti: I'd been ignoring the syncSource issue since they mostly seemed to be the known issue.
[11:06] <pitti> wgrant: I once had a linux -updates copy take about an hour (on cocoplum) due to bug refs; back then lifeless said it was due to iterating through _all_ bugs (not just the ones since the previous version)
[11:06] <pitti> I haven't seen this again, so perhaps that part got fixed
[11:06] <wgrant> pitti: That particular bug is fixed.
[11:07] <wgrant> It was a terrible bug heat update thing.
[11:07] <pitti> but as the time to autoclose bugs necessarily scales with their number, a fixed timeout might never work there, as long as it's synchronous?
[11:07] <pitti> wgrant: right, that one
[11:08] <wgrant> pitti: We will hopefully soonish be able to send a request to our as-yet non-existent message queue to close the bugs.
[11:08] <pitti> wgrant: ah, async FTW!
[11:09] <wgrant> pitti: The timeout has always been fixed. It was just 20s instead of the 9s it is now.
[11:09] <pitti> wgrant: right, it just made the +queue page a lot less useful :(
[11:09] <wgrant> pitti: Yeah. Maybe we can convince lifeless to bump it for a while.
[11:09] <wgrant> Since we can't do too much until bugs are async.
[11:15] <dupondje> doko: the patch from https://bugs.launchpad.net/gcc-linaro/+bug/675347 seems not to be in gcc-4.6
[11:16] <wgrant> pitti: I found one of your syncSource OOPSes from yesterday... one second to do the copy, 8 to close the bugs.
[11:16] <pitti> ah, so it just barely failed
[11:17] <wgrant> No.
[11:17] <wgrant> 8 seconds of bug closing before it was killed.
[11:17] <wgrant> Could have gone on for ages if it wasn't killed.
[11:17] <pitti> ah, right
[11:17] <pitti> it took about 10 on cocoplum
[11:17] <wgrant> :(
[11:17] <pitti> and it definitively takes a lot longer than 9 seconds on the client side until it fails, more like 30
[11:18] <wgrant> Huh.
[11:18] <wgrant> There are a total of three pages that are allowed to take longer than 9 seconds.
[11:18] <wgrant> This is not one of them :(
[11:51] <micahg> jfi: I have to run, but you can make those changes I suggested and subscribe ubuntu-sponsors, if you have more questions feel free to ask them here
[11:52] <jfi> micahg, ok thanks for your help!
[11:58] <doko> seb128, pitti: please could identify packages to rescore to fix build failures like: https://launchpadlibrarian.net/71177129/buildlog_ubuntu-oneiric-armel.librsvg_2.32.1-1ubuntu1_FAILEDTOBUILD.txt.gz
[11:59] <ScottK> doko: No.  Same Qt as we had in Natty.
[12:03] <cjwatson> doko: git would help there.  I've scored it up
[12:03] <cjwatson> hm, that needs perl work though
[12:04] <doko> perl should work now
[12:04] <cjwatson> more modules
[12:04] <doko> ahh
[12:04] <cjwatson> doko: how about I chase this down today?  I'm at a bit of a loose end anyway
[12:04] <doko> cjwatson: cool, thanks!
[12:06] <cjwatson> doko: I can't promise to work in the exact order of the Perl transition page, though I'll make sure dependencies are satisfied at each step
[12:06] <cjwatson> doko: were you working on doxygen?
[12:06] <cjwatson> ah, yes, I see that now
[12:07] <doko> cjwatson: I did set the armel buildds to manual, to get the uploaded binutils in the archive. please rescore/build/reset to manual for the perl builds
[12:07] <doko> yes, disabled doxygen-gui for now
[12:07] <doko> after binutils is built, I'll update gcc-4.6 again to build from the linaro branch
[12:15] <cjwatson> doko: the other remaining non-trivial problem here is:
[12:15] <cjwatson>  default-jdk : Depends: default-jre (= 1:1.6-40ubuntu1) but it is not going to be installed
[12:15] <cjwatson>                Depends: openjdk-6-jdk (>= 6b14) but it is not going to be installed
[12:15] <cjwatson>  openjdk-6-jre : Depends: libaccess-bridge-java-jni but it is not going to be installed
[12:15] <cjwatson>                  Recommends: icedtea-netx but it is not going to be installed
[12:16] <cjwatson> doko: what's the right answer there?
[12:16] <doko> hmm ...
[12:17] <cjwatson> oh, bugger, that's blocked on libgtk2.0-0
[12:17] <cjwatson> I think I'll have to disable Subversion's Java bindings temporarily
[12:17] <doko> gtk is built, but not atk1.0, which depends on gnome-common
[12:18] <cjwatson> yes, which depends on autopoint, which depends on git, which build-depends on libsvn-perl, which build-depends on default-jdkd
[12:18] <cjwatson> *jdk
[12:18] <doko> which depends on autopoint, which depends on git
[12:18] <doko> heh
[12:19] <cjwatson> Subversion is the easiest point to unpick this temporarily, I think
[12:19] <doko> hurray for unversioned b-d's
[12:19] <doko> cjwatson: please disable the subversion tests then for this temporary upload
[12:21] <cjwatson> OK
[12:21] <cjwatson> I'll just disable Java and the tests on armel
[12:26] <pitti> thanks cjwatson
[12:30] <cjwatson> Laney: how often does the perl transition tracker page update?
[12:41] <cjwatson> readline5 was just demoted to universe.  This breaks ruby1.8, which is in main and still depends on it, so I'm re-promoting it
[12:42] <cjwatson> (will need to wait another hour for that before being able to build subversion)
[12:59] <Laney> cjwatson: I haven't cronned it yet
[13:01] <cjwatson> Laney: ok, thanks
[13:01] <Laney> but I did update it earlier
[13:01] <Laney> it requires manual intervention currently due to these NBS binaries
[13:05] <james_w`> pitti, I think that LP would allow it at least
[13:05] <james_w`> pitti, would you drop me a mail about it?
[13:06] <pitti> james_w`: sure, thanks!
[13:10] <RicardoPerez> Hi! Can anybody tell me how can I submit a bugreport if I find a bug in the geoip.ubuntu.com database?
[13:11] <RicardoPerez> geoip.ubuntu.com/lookup tells me that my timezone is Africa/Ceuta, but the right timezone should be Europe/Madrid
[13:17] <p0s> hi. i made a fresh install of natty (amd64, setup over PXE) yesterday. the machine randomly does not boot (with a failure rate of >90%), instead it drops into a purple screen. after adding "nosplash" and removing "quiet" from the kernel command line i was able to see that it drops into an initramfs shell, the purple splashscreen probably hides this. i would like to trace the problem down if someone is here who can help me with it & then file the
[13:18] <p0s> bugtracker entries.
[13:19] <p0s> further, adding the "nosplash" option to the kernel command line via the grub menu is also difficult, because grub randomly dies with "alloc magic is broken at 0x3fdb7230" then (failure rate also >90%)
[13:20] <p0s> the value of 0x3fdb7230 is always the same.
[13:33] <SpamapS> pitti: re erlang +compressed and +slim .. yes, however, the build seems to fail unless +slim is removed. Upstream was also confused why we'd use +compressed since we also compress the binaries in the .deb
[13:33] <Laney> cjwatson: doko: right, hourly cronned it at http://orangesquash.org.uk/~laney/transitions/perl.html
[13:35] <cjwatson> Laney: great, thanks
[13:35] <Laney> I ought to make it show components too, will do that soon
[13:37] <cjwatson> doko: I'm about to start subversion and libdbd-sqlite3-perl armel builds, if you're not already
[13:37] <cjwatson> (I noticed you'd already scored up subversion)
[13:38] <doko> cjwatson: please go ahead
[13:38] <cjwatson> ta
[14:02] <pitti> there, usb-creator using pygi
[14:03] <cjwatson> subversion/armel failed to find KWallet in configure
[14:18] <cjwatson> hmm, it succeeds in kakadu's oneiric chroot
[14:19] <cjwatson> doko: I'm tempted to just disable kwallet support in subversion/armel temporarily - what do you think
[14:19] <cjwatson> ?
[14:24] <ScottK> cjwatson: I'd do it.
[14:25] <ScottK> Qt is somewhat broken on armel due to gcc issues, so it'll burn you sooner or later until that's resolved.
[14:25] <cjwatson> I figure it'll be easier to debug once oneiric/armel is in better shape generally
[14:25]  * cjwatson nods
[14:25] <ScottK> Yep.
[14:25] <cjwatson> uploaded (and test-building in parallel)
[14:26] <cjwatson> oh, excellent, apt/armel built
[14:37] <Pretto> is here the right place to make questions about unity?
[14:42] <ScottK> Pretto: #ayatana is better.
[14:43] <Pretto> ScottK:  thank you
[14:43] <ScottK> You're welcome.
[14:44] <SpamapS> Hrm.. how do I run this filter as part of my sbuild process? http://wiki.debian.org/ImplicitPointerConversions
[14:45] <SpamapS> jhunt_: oh joy https://launchpadlibrarian.net/71181279/buildlog_ubuntu-oneiric-armel.upstart_0.9.7-2_FAILEDTOBUILD.txt.gz
[14:58] <siretart> is there a particular reason for not processing libav from binary NEW? is there some clarification on the package needed or something?
[15:01] <ScottK> siretart: I don't think anyone has done binary New for Ubuntu local packages since oneiric opened.
[15:02] <ScottK> So that doesn't mean the answer is no, but I don't think it still being there is necessarily meaningful.
[15:03] <siretart> ScottK: err, why do you consider it a 'local' package? it is a merge from debian/experimental
[15:04] <ScottK> siretart: The only thing that's been processed was stuff that was in New after sync.
[15:04] <siretart> I see. ok
[15:04] <ScottK> Local as in not directly sync'ed from Debian.
[15:04] <siretart> ok
[15:04] <cjwatson> (Specifically, we have scripts that largely take care of the it-was-synced case.)
[15:05]  * Laney starts a ghc test build
[15:08] <p0s> i filed a bug for my boot problems which i described some minutes ago in case anyone wants to comment: https://bugs.launchpad.net/ubuntu/+bug/778520
[15:10] <SpamapS> p0s: I did some testing and patching for RAID1 near the end of 11.04's release cycle. that is very troubling.
[15:11] <SpamapS> p0s: sounds like there's a race condition in there somewhere though
[15:11] <p0s> SpamapS: well, if you want me to investigate what the issue is, now i am here. i'm also a developer kind of person so you can ask me to do complex stuff.
[15:11] <SpamapS> p0s: maybe XFS is taking longer thus causing the race to appear
[15:12] <p0s> SpamapS: also, the machine has successfully booted now, so i can actually read logs etc
[15:12] <p0s> SpamapS: notice that the fact that BusyBox clears the screen is very bad, because the system DOES print some stuff to the screen before, and i cannot tell what it is because it is cleared away too fast :(
[15:13] <SpamapS> p0s: yeah not sure why it does that
[15:13] <p0s> SpamapS: i will be here for the next 3-4 hours at least
[15:14] <evfool> hi, can anyone help me with a bit of PYGI porting: I'm getting AttributeError: type object 'Widget' has no attribute '__info__'  all the time
[15:14] <SpamapS> p0s: great.. I'm looking through my notes from the testing.. I do recall being dropped to initramfs once unexpectedly even though the root partition was clean.. and noting "race condition?" but 30 or so boots after that I chalked it up to something I did wrong...
[15:15] <p0s> SpamapS: well it obviously is some kind of race condition because it DOES boot in 5% of the attempts or so :|
[15:15] <SpamapS> Ah I found the log I copied. It said md0 was "not ready"
[15:16] <p0s> SpamapS: i guess the first step would be to figure out whether there is any way to gain a logfile from what happens before initramfs shell drop?
[15:16] <SpamapS> IIRC, the way it supposed to work, mdadm should be run, "starting" all arrays, and then mounts happen. I wonder if somehow we've accidentally parallelized that.
[15:17] <SpamapS> p0s: that would definitely be useful.
[15:17] <p0s> SpamapS: well please figure it out for me, i have no clue how your boot process works :( i can obtain the log files if you tell me how to do it
[15:18] <SpamapS> p0s: Unfortunately for you, we only do our release testing on the default configurations... XFS isn't in that category. :-P
[15:18] <ScottK> Maybe you do it that way.  I tested btrfs installs last cycle.
[15:18] <p0s> SpamapS: well, how likely is it that it is a xfs problem? if it doesnt wait for the mount to succeed that will also happen with other FS
[15:18] <ScottK> Because doing it the same way every time gets boring.
[15:19] <p0s> SpamapS: i mean there is nothing special about xfs, you call mount, mount takes some time, then the fs works.
[15:20] <p0s> SpamapS: also the initramdisk is stored on / which is XFS, so it does seem to be able to pull some data from it
[15:20] <SpamapS> p0s: can you try booting with the 'debug' option ?
[15:20] <p0s> SpamapS: kernel option?
[15:20] <SpamapS> p0s: yes in grub
[15:20] <p0s> SpamapS: add to kernel command line or to list of grub commands?
[15:22] <p0s> SpamapS: nevermind, grub doesnt support debug command, so its a kernel option i guess
[15:22] <SpamapS>     if command -v chvt >/dev/null 2>&1; then
[15:22] <SpamapS>         chvt 1
[15:22] <SpamapS>     fi
[15:22] <SpamapS> I wonder if that is what "resets" the terminal
[15:23] <p0s> SpamapS: debug added. now it seemed to print even less stuff to screen before it dropped to BusyBox.
[15:23] <p0s> SpamapS: what now?
[15:24] <SpamapS> p0s: I'm looking into how we can not clear the screen, can you try alt-f7 though?
[15:24] <p0s> SpamapS: chvt manpage http://linux.die.net/man/1/chvt
[15:24] <p0s> SpamapS: ha, alt+f7 shows the terminal which the kernel used before dropping to busybox! nice catch
[15:25] <p0s> SpamapS: now the only thing which it shows is "Loading, please wait...". without debug it showed more i think, so i guess i shall try what i see there without debug....
[15:25] <SpamapS> thats interesting too tho
[15:26] <p0s> SpamapS: ok it shows some errors, hold on, i'll photograph it
[15:27] <SpamapS> p0s: you get the "best user of the day" award btw. :)
[15:28] <p0s> SpamapS:  :D thanks. i plan to get one when i file my debian bug report on sambafs, i have a full documentation of EVERY config setting which i changed on the machine. usually do this for reducing cost of OS re-installation. unfortunately this ubuntu machine wasnt reconfigured at all...
[15:29]  * p0s searches the camera usb cable, hold on
[15:36] <SpamapS> p0s: I need to get the wife and kids out the door for the day.. will be non-responsive for the next hour mostly.. do not dispair. ;)
[15:36] <p0s> SpamapS: hold on a second, im uploading the shot right now
[15:37] <p0s> SpamapS: attachement added: https://bugs.launchpad.net/ubuntu/+bug/778520
[15:38] <p0s> SpamapS: thanks for your help already. if i'm not in this channel i am still likely to be on this irc server with the same nick, just privmsg me.
[15:38] <p0s> SpamapS: and of course i'll monitor the bugtracker entry.
[15:52] <doko> cjwatson: binutils is in the archive, can I re-enable the buildds, or would you like to wait until gnome-common is installable?
[15:53] <cjwatson> doko: how about we re-enable them but not do a mass retry yet?
[15:53] <cjwatson> then once the uninstallable count is down to normal we can retry everything
[15:54] <doko> well the mass-retry did already happen yesterday
[15:54] <cjwatson> oh.  um, that's interesting. :-(
[15:54] <doko> I asked lamont for it
[15:54] <cjwatson> in that case I'd prefer to continue with targeted builds for a while - the buildds are so behind that it would be nice not to waste them
[15:55] <cjwatson> do we have the new chroots in place yet?
[15:55] <doko> I didn't hear back from lamont
[15:55] <lamont> new as in without apt held?
[15:55] <cjwatson> right
[15:55] <cjwatson> and preferably refreshed
[15:56] <lamont> original is back, I'm building a fresh one now
[16:01] <cjwatson> doko: should cmake build now?
[16:02] <doko> cjwatson: no, preparing a gcc-4.6 update with linaro enabled on armel for that
[16:02] <cjwatson> ok
[16:03] <lamont> cjwatson: how come PPC is the fastest chroot tarball creator?
[16:04] <cjwatson> haven't the foggiest :)
[16:04] <lamont> it comes as no surprise that arm is the slowest
[16:05] <slangasek> wgrant: 10 minutes> how does that explain the binaries being from a later version than the source?
[16:06] <barry> lamont: got any spare powermac g5 power supplies laying around? :)
[16:08] <ScottK> First thing Monday it ought to be easy enough to find one 'laying around'.
[16:09] <wgrant> slangasek: I'm not entirely sure, but it's because ubuntu2 was deleted after its builds had finished but before process-accepted had run. So when process-accepted ran, it published the binaries even though the source was no longer there. Then publish-distro ran, and the new binaries superseded the old ones.
[16:09] <wgrant> Leaving us with the new binaries and the old source.
[16:10] <lamont> wgrant: brilliant!
[16:10] <wgrant> Yes,.
[16:13] <lamont> cjwatson: your non-arm are fresh
[16:13] <lamont> arm is still bzip2ing
[16:14] <lamont> it occurs to me I could bzip2 it on cesium and it'd be faster
[16:18] <lamont> cjwatson: and arm is now fresh
[16:18] <ogra_> mmmmm
[16:41] <SpamapS> p0s: back..
[16:41] <p0s> SpamapS: ok great... check the picture of the error messages which i attached to the bugtracker entry
[16:41] <p0s> SpamapS: https://launchpadlibrarian.net/71202020/100_4642.jpg
[16:41] <SpamapS> yeah.. device or resource busy
[16:41] <SpamapS> thats exactly what I saw once ...
[16:41] <SpamapS> so marking it as confirmed
[16:42] <p0s> sounds like it is trying to mount it twice?
[16:42] <cnd> where is the natty archive for armel?
[16:42] <cnd> I've looked at ports.ubuntu.com, but there's nothing there
[16:43] <cjwatson> http://ports.ubuntu.com/ubuntu-ports/
[16:43] <SpamapS> p0s: what makes you think twice?
[16:44] <p0s> SpamapS: well the "device or blah busy" message is what you usually get when you try to unmount something on which there are still open files... thats what i know... so either it tries to unmount it while something is still open... or (just guessing!) it tries to mount it twice
[16:44] <SpamapS> p0s: its also possible that the RAID isn't actually "started" yet
[16:45] <cnd> cjwatson, I've looked in http://ports.ubuntu.com/ubuntu-ports/dists/natty/
[16:45] <cnd> there's no Release file, nor are there any packages in any of the pockets
[16:45] <p0s> SpamapS: well the initramdisk is stored on the raid, how does grub obtain it, through regular mounting or does it ignore the raid and read it directly from disk by offset?
[16:45] <SpamapS> p0s: mdadm was updated to a new major revision in natty, so the behavior may be different and we may just need to wait until the md's are actually started.
[16:46] <SpamapS> p0s: its r/o .. much simpler. :)
[16:46] <p0s> SpamapS: ok.... notice that i tried "rootdelay=100" and "rootwait" which had no effect
[16:47] <p0s> SpamapS: it didnt even try to wait it seemed... but i havent checked whether there are different error messages with those, i will do that now
[16:47] <SpamapS> p0s: what might be interesting would be the output of /proc/mdstat right before mountroot ...
[16:50] <p0s> SpamapS: rootdelay=100  => same messages as without it
[16:50] <hallyn> SpamapS: bug 719448, any reason why the lucid-proposed qemu-kvm shouldn't be pushed to lucid-updates ?
[16:50] <hallyn> SpamapS: it has been verified for lucid, but not for maverick
[16:50] <SpamapS> hallyn: 7 days from verification-done, it should move to -updates ..
[16:51] <cjwatson> cnd: err, all I can say is that you must be getting different results from me for some reason
[16:51] <hallyn> SpamapS: ah, i see, thanks
[16:51] <hallyn> SpamapS: i hadn't realized there was that 7 day period :)
[16:51] <cjwatson> cnd: all the things you mention are present from here
[16:51] <p0s> SpamapS: rootwait also yields the same errors.
[16:52] <p0s> SpamapS: well yea the output of mdstat would reveal whether it is running... now how can we make the init scripts output it?
[16:52] <doko> cjwatson: gcc-4.6 now building on armel
[16:52] <alexbligh1> When an interface is added/removed, brought up/down, init() does a clone and an exec of ifup/ifdown to try and run the networking scripts. What (exactly) is triggering init to do this, and how can I stop it? I am creating 1,000 odd interfaces, it's taking a huge % of CPU, and am configuring them manually (in fact as they are in a contianer, init & its children can't even see them). Is it udev?
[16:53] <cjwatson> doko: at some point subversion may even finish.  My test build worked ...
[16:53] <cjwatson> doko: I'm uploading a load of stuff from the first layer of the Perl transition page now
[16:53] <SpamapS> p0s: you can add a script to /usr/share/initramfs-tools/scripts/init-premount that does 'cat /proc/mdstat'
[16:53] <cjwatson> that transition page is awesome
[16:53] <SpamapS> p0s: you'll need to do "sudo update-initramfs -u" after that
[16:54] <p0s> SpamapS: and then run update-initramfs i suppose
[16:54] <doko> cjwatson: is this specific for oneiric?
[16:54] <p0s> SpamapS: ok. now give me some twenty minutes for an insaneous amount of boot attempts till i get into the system...
[16:54] <SpamapS> p0s: :(
[16:54] <cjwatson> doko: YM as opposed to Debian?
[16:54] <SpamapS> p0s: if you're brave you can probably kick the boot off from the initramfs> prompt
[16:55] <p0s> SpamapS: (i suppose update-initramfs does need /dev /proc? if it does not i can boot the system w/ usb stick and use chroot)
[16:55] <doko> cjwatson: yes
[16:56] <cjwatson> doko: it is, yes.  http://orangesquash.org.uk/~laney/transitions/perl.html
[16:56] <p0s> SpamapS: i can of course type the commands to boot it into the initramfs shell if someone tells me what they are ;)
[16:56] <p0s> SpamapS: nevermind, it has just succeeded booting
[16:57] <SpamapS> p0s: I think you can just try 'exec /sbin/init' .. might be just /init ..
[16:57] <SpamapS> p0s: \o/
[16:57] <doko> cjwatson: not tracking powerpc?
[16:58] <cjwatson> Laney: ^- you seem to have figured out how to get it to track armel from ports - can it look at powerpc too?
[16:58] <Laney> oh, yes
[16:58] <SpamapS> p0s: I think I've got it reproducing reliably now here.
[16:58] <Laney> let's see if that works
[16:58] <p0s> SpamapS: oh!
[16:58]  * Laney adds a .txt output too
[16:59] <p0s> SpamapS: why /ush/share/initramfs-tools/scripts and not /etc/... ?
[16:59] <cnd> cjwatson, hmmm....
[16:59] <SpamapS> p0s: by live-degrading the array it seems to happen about 50/50 on the next reboot.
[16:59] <SpamapS> p0s: good question. /etc may be a better choice :)
[16:59] <p0s> SpamapS: doh. my array IS degraded.
[16:59] <p0s> SpamapS: i was planning to tell you about that soon but was ashamed that i didnt do it yet :)
[17:00] <cnd> cjwatson, could it be some uds domain hijacking or something?
[17:00] <cnd> I'll have to look into it
[17:00] <p0s> SpamapS: i HAVE answered the "boot when array is degraded?" question with YES during setup though
[17:00] <cjwatson> cnd: that's possible, I know there's some archive-level oddness on UDS networks.  Talk to IS
[17:00] <p0s> SpamapS: also i didnt consider it as a blocker since it is not fatally degraded, its a raid1 with 1 of 2 disks...
[17:01] <SpamapS> p0s: right.. this doesn't seem to be a problem when both disks are present
[17:01] <p0s> SpamapS: can you still fix it? i consider installing on incomplete raidsets as something to be likely to be done by someone who uses raid... typically you dont want the resync to be running during setup...
[17:01] <SpamapS> p0s: no it should definitely work
[17:02] <p0s> SpamapS: also, the setup UI allows creating incomplete raidsets, which is a nice feature IMHO
[17:02] <p0s> SpamapS: sorry for not reporting this right from the start.
[17:02] <SpamapS> p0s: if nothing else, it should be whining about being degraded, not dropping to busybox
[17:03] <SpamapS> I think the problem is that the mountroot_fail that mdadm registers is not being called
[17:03] <SpamapS> p0s: no problem, its still very bad
[17:07] <p0s> SpamapS: if you also responsible for the grub stuff.. i have figured out another possible bug maybe: my grub command list contains "set gfxpayload=$linux_gfx_mode" ... is it supposed to contain a $-variable? /etc/default/grub does NOT set the gfx mode so i wonder whether the grub command list should contain the "set gfxpayload="
[17:08] <SpamapS> p0s: cjwatson is your best bet for that one.
[17:08] <Laney> cjwatson: there, added. also s/html/txt/ might be amenable to scripting
[17:08] <p0s> SpamapS: ok thanks
[17:08] <p0s> cjwatson: i have figured out another possible bug maybe: my grub command list contains "set gfxpayload=$linux_gfx_mode" ... is it supposed to contain a $-variable? /etc/default/grub does NOT set the gfx mode so i wonder whether the grub command list should contain the "set gfxpayload="
[17:08] <cjwatson> I am, but not right now - about an hour to end-of-week, and then it's UDS
[17:09] <cjwatson> yes it is supposed to contain such a variable
[17:09] <p0s> cjwatson: (talking about a fresh natty install)
[17:09] <cjwatson> 'echo $linux_gfx_mode' will tell you its value
[17:09] <cjwatson> it's a little involved, see /etc/grub.d/10_linux for the full logic
[17:10] <cjwatson> if the default is a problem, there's a PCI-id blacklist facility available
[17:10] <p0s> SpamapS: the cat /proc/mdstat shows: devices is NOT active!
[17:10] <p0s> SpamapS: doesnt even list the device.
[17:10] <cnd> cjwatson, sounds like it's the uds mirror
[17:10] <cnd> thanks :)
[17:11] <p0s> cjwatson: "ep" ... is that valid?
[17:11] <cjwatson> Laney: thanks
[17:11] <cjwatson> p0s: sounds like a corrupted version of 'keep'
[17:11] <p0s> cjwatson: argh wait, my monitor is not adjusted, the first part is cut off :)
[17:11] <cjwatson> should be either 'keep' or 'text', normally
[17:12] <p0s> cjwatson: yes, it is keep.
[17:12] <cjwatson> if one breaks for you, GRUB_GFXPAYLOAD_LINUX=text in /etc/default/grub
[17:12] <SpamapS> p0s: the issue seems to be that on failing to mount, the failure hook is either not being run, or failing silently
[17:12] <p0s> cjwatson: now the question is: why do i get a purple empty screen instead of proper output if i do not remove the gfx-payload?
[17:12] <cjwatson> bug
[17:12] <p0s> cjwatson: grmbl :(
[17:12] <cjwatson> something's failing to chvt on error
[17:13] <cjwatson> any VT change should clear the screen contents
[17:13] <cjwatson> I thought mountroot_fail did a chvt ...
[17:14] <p0s> cjwatson: two more cents from me: i've set up debian6 a month ago and tried to get a proper terminal resolution with the gfxpayload stuff and the kernel seems to ignore all of it... i AM happy that the ubuntu team seems to be trying to get this to work... 80x25 seems a shame for 2011... so please fix it if you investigate this issue, dont just remove the ability for highres-terminal :)
[17:14] <cjwatson> I have generally been working with the kernel team to make this work better, and it works on some hardware but not others
[17:15] <cjwatson> in particular if you're using a binary driver it's quite possible you'll lose
[17:15] <p0s> cjwatson: SpamapS has just figured out for me some minutes ago that busybox DOES chvt! i
[17:15] <cjwatson> if chvt isn't clearing the contents, then that's a kernel bug :)
[17:15] <cjwatson> it's definitely meant to, per what apw told me when he implemented KD_TRANSPARENT
[17:16] <p0s> cjwatson: (after removing the gfx-payload i get some kernel boot messages and then busybox... busybox clears the screen and SpamapS figured out that the reason is that it does chvt)
[17:16] <cjwatson> well, there you go, busybox clears the screen, isn't that what you wanted?
[17:16] <p0s> cjwatson: i only get to see the screen if i remove the gfxpayload!
[17:17] <p0s> cjwatson: if i dont remove it it stays purple..
[17:17] <SpamapS> what p0s means is, it switches from tty7 to tty1 ...
[17:17] <SpamapS> if you alt-f7 it shows what was on tty7 again
[17:17] <SpamapS> I'm lacking context but that, to me, isn't clearing the screen but rather just switching to another vt.
[17:18] <cjwatson> I'm failing to understand the exact nature of the problem.  the general design is that you get a purple screen after grub which transitions smoothly to plymouth.  if you want to disable that for debugging, remove 'splash vt.handoff=7' from the kernel command line (and you may wewll want to remove 'quiet' then too)
[17:18] <cjwatson> *well
[17:18] <p0s> cjwatson: the debian machine where it doesnt work has intel onboard graphics, the ubuntu machine with the purple screen has a nvidia pciE card w/ nvidia binary drivers installed, but it also didnt work before i installed them....
[17:19] <p0s> cjwatson: i changed "splash" to "nosplash" and removed "quiet", i did not remove "vt.handoff=7" ... screen is purple with that setting
[17:19] <cjwatson> remove vt.handoff=7
[17:19] <p0s> cjwatson: ok will try, hold on
[17:19] <cjwatson> and remove nosplash since nothing understands that anyway
[17:19] <cjwatson> https://wiki.ubuntu.com/FoundationsTeam/Grub2BootFramebuffer may be helpful for background, BTW
[17:20] <SpamapS> cjwatson: seems that memo needs to be printed in a bigger font. ;)
[17:20] <p0s> SpamapS: now the screen isnt purple anymore... now i get random white boxes instead of letters :)
[17:21] <p0s> SpamapS: sorry, wasnt for you
[17:21] <p0s> cjwatson: now the screen isnt purple anymore... now i get random white boxes instead of letters :)
[17:21] <slangasek> SpamapS: the problem is finding the circulation list for the original memo, since our documentation has never referred to 'nosplash'
[17:21] <p0s> cjwatson: i'll just blame that on the nvidia card and say thanks to you ;)
[17:21] <cjwatson> slangasek: usplash used to recognise it
[17:21] <slangasek> oh, did it?
[17:22] <slangasek> ancient history ;P
[17:22] <cjwatson> I think it circulated by osmosis from theere
[17:22] <cjwatson> *there
[17:22] <cjwatson> it's harmless though, I just like to dispel myths when possible
[17:22] <slangasek> does plymouth still parse 'nosplash' as 'splash'? ;)
[17:23] <cjwatson> hah, actually it isn't harmless for the reason you just gave
[17:23] <cjwatson> will be easier to fix in the next upstream of plymouth, which has less stupid command-line parsing
[17:23] <p0s> geez :)
[17:23] <p0s> SpamapS: do you need further info from me w.r.t. to my raid issue?
[17:24] <cjwatson> p0s: I do have a test nvidia system on which I've been on-and-off working to try to make things better there
[17:24] <p0s> cjwatson: what i've also noticed about grub: it seeks my floppy drive and complains about no floppy present even though no floppy was involved in the setup at all
[17:24] <cjwatson> it's been hard to find the time
[17:24] <SpamapS> p0s: I can reproduce it reliably now, so I *think* I can get to a fix w/o further input. Please just watch for questions on the bug report, and THANKS!
[17:24] <cjwatson> hm, if only I had a system that actually has floppy drives on which to work on that ...
[17:25] <p0s> cjwatson: you got my karma for that :) what i would prefer to have working is the intel onboard graphics on my debian6 though :|
[17:25] <SpamapS> floppy.. how quaint. :)
[17:25] <p0s> cjwatson: my debian machine has no xserver and is stuck in 80x25 due to the gfxpayload not working... yay!
[17:25] <cjwatson> p0s: what does /boot/grub/device.map say?
[17:25] <cjwatson> this is in fact very odd since we say --no-floppy everywhere in the postinst
[17:25] <cjwatson> unless you ran grub-install by hand
[17:25] <p0s> did not do that
[17:26] <p0s> SpamapS: i installed the floppy drive merely as a closer for the hole in the atx case :)
[17:26] <cjwatson> hm, drat, we do iterate over floppies at boot time
[17:27] <cjwatson> I should try to arrange for --no-floppy to be remembered somehow
[17:27] <SpamapS> The sound of a 3.5" floppy seeking is locked in my head tho.. "Click.. fffvvvrrrrfvvvrrrffvvvvrrrmmp"
[17:28] <p0s> cjwatson: there is no /boot/grub/device.map
[17:28] <p0s> SpamapS: during the old days i was able to HEAR when a floppy disk had bad sectors.
[17:28] <cjwatson> p0s: yeah, that question was based on a misconception, never mind
[17:30] <cjwatson> bug 560596 I guess
[17:31] <p0s> cjwatson: ok thanks i will report my grub version to that bug
[17:31] <cjwatson> no please don't
[17:31] <cjwatson> it's not needed
[17:31] <p0s> cjwatson: ok
[17:31] <cjwatson> I've dropped a quick note in that bug with what I think needs to be done
[17:31] <p0s> cjwatson: great, thanks!
[17:31] <cjwatson> (and marked it Triaged etc.)
[17:32] <p0s> cjwatson: last grub bug i observed today is this: https://bugs.launchpad.net/bugs/498882
[17:32] <p0s> cjwatson: comment #9
[17:32] <cjwatson> generally it's best not to tag onto existing bugs with general symptoms
[17:33] <cjwatson> that symptom is "something went wrong with memory management" somewhere, and your problem is very likely not the same as that of the original reporter
[17:33] <cjwatson> better to file a new bug report
[17:33] <p0s> cjwatson: ok thanks. our freenet project bugtracker feels like a trash dump so i usually think twice before creating new entries
[17:34] <cjwatson> I appreciate the sentiment, but the thing is that it's easier to mark bugs as duplicate than to split them
[17:35] <cjwatson> we have bugs that have been dogpiled by lots of different people and are now impossible to ever fix
[17:35] <p0s> ok
[17:35] <cjwatson> so the other problem is that this is nearly impossible to debug remotely
[17:35] <cjwatson> if you can make it happen in a virtual machine and give me a recipe for it, that might help
[17:36] <cjwatson> or if you can make it happen with 'set debug=all' and take a photo of the last screenful of output (there'll be lots and lots though)
[17:36] <p0s> ok thanks
[17:36] <p0s> it doesnt seem to happen right now anymore though :|
[17:36] <cjwatson> I'm working on updating an old patch with a gdb stub for grub, but it's not there yet
[17:36] <p0s> maybe the error message it prints should be changed to be more useful to developers?
[17:36] <cjwatson> it's about as useful as it can be given the information available at that point
[17:37] <p0s> :(
[17:37] <cjwatson> because what has happened is that some previous piece of code has corrupted grub's equivalent of the malloc arena
[17:37] <p0s> it is quite random, it probably depends on the size of the input of the boot-entry editor..
[17:38] <cjwatson> i.e. a buffer overflow into the bookkeeping area for memory management
[17:38] <cjwatson> by the time we notice the failure, the offending code has been and code
[17:38] <cjwatson> *been and gone
[17:38] <p0s> i remember that stuff from when i was still doing c++ it was such an ultra pain to debug even with an IDE
[17:38] <cjwatson> what we actually need is valgrind for grub, but, err, slightly not this side of feasible
[17:38] <SpamapS> Hrm, so it looks like mountroot isn't running the failure hooks
[17:39] <p0s> cjwatson: i will remember the set debug=all when it happens again
[17:39] <cjwatson> of course that may perturb the problem into nonexistence
[17:39] <cjwatson> it's possible 1.99~rc2 will fix it - I'm partway through packaging that
[17:39] <p0s> nice! :)
[17:39] <cjwatson> (well, I have it packaged, but I'm working on other changes I'm making at the same time)
[17:39] <broder> cjwatson: are there any plans to sru updates for the blacklists?
[17:40] <cjwatson> broder: not from my end, but I wasn't expecting to be the one doing that work - graphics people should, I think
[17:40] <broder> ok
[17:41] <p0s> cjwatson: are you also working for debian boot stuff? i could help with debugging why the gfx-payload isnt working on debian w/ intel graphics for me...
[17:42] <cjwatson> I'm the main person packaging GRUB for Debian, but I don't work with the kernel team there on it
[17:42] <cjwatson> by and large, if gfxpayload doesn't work, it's a kernel bug
[17:43] <cjwatson> or sometimes X
[17:43] <p0s> cjwatson: i dont remember whether it was an issue with grub not passing it to the kernel or the kernel ignoring it actually. if it happens to be a grub problem i will annoy you again :) thanks
[17:43] <p0s> cjwatson: the machine does not HAVE x, thats why i care about it :)
[17:43] <cjwatson> I doubt it was the former
[17:44] <cjwatson> if you set gfxpayload=keep, GRUB just leaves the video mode in whatever state it was in during GRUB rather than switching back to text mode before starting the kernel
[17:44] <cjwatson> it's mostly a matter of not doing something rather than a matter of actively doing something
[17:44] <p0s> cjwatson: what could be improved is the documentation or even better /etc/default/grub... it is quite difficult to find usable google results about what the proper way of obtaining a highres terminal is... they are still cluttered with vga=...
[17:45] <cjwatson> the problem is that it's mostly not grub's responsibility
[17:45] <cjwatson> there is some text in 'info grub' about it, but it has to defer to other parts of the system
[17:45] <p0s> cjwatson: i suggest adding a commented out # GFX_PAYLOAD_BLAH to the /etc/default/grub
[17:45] <cjwatson> I'm not going to add more options there
[17:45] <cjwatson> the proper place for documentation is 'info grub'
[17:45] <cjwatson> in current versions of grub, there's a comment at the top of that file linking to the documentation
[17:45] <p0s> cjwatson: so the manpage is deferred?
[17:46] <p0s> cjwatson: didnt know that i have to use info :)
[17:46] <cjwatson> while I love man pages, they aren't really a great place for longer discursive tutorial-type documentation
[17:47] <p0s> cjwatson: good to know. i thought the "info" stuff was legacy and never looked into it... but i think this is a problem on my personal side, the manpages usually tell you to read the info
[17:47] <cjwatson> # For full documentation of the options in this file, see:
[17:47] <cjwatson> #   info -f grub -n 'Simple configuration'
[17:47] <SpamapS> info: for when you want confused users to forget about their original problem for a while.
[17:47] <cjwatson> note that I'm also the man-db maintainer, so you can perhaps infer my personal stance on the matter
[17:47] <cjwatson> but I work in the context of whatever project I'm working on
[17:47] <p0s> cjwatson: i think the problem which i had back then was finding a full list of all available /etc/default/grub options
[17:48] <cjwatson> that is what  info -f grub -n 'Simple configuration'  gives you
[17:48] <cjwatson> (now)
[17:48] <p0s> cjwatson: ok great.
[17:48] <p0s> cjwatson: unfortunately i cannot reboot now to check what the gfx payload problem is since this would pull the NFS root of my workstation away, which i am running this irc client from :)
[17:50] <p0s> anyway, thanks guys, you made me very happy today. i love being able to talk to the responsible developers directly instead of through a bugtracker :)
[17:50] <cjwatson> heh
[17:52] <SpamapS> so I think whats happening is that initramfs assumes the root device is *ready* because udev has created it, but in the case of md .. its not ready, its just known..
[17:52] <SpamapS> specifically wait-for-root seems to return before we can actually monkey w/ the device
[17:55] <p0s> SpamapS: you're shoveling your own grave... now that i know your name i will come back at you when i try to set up NFSv4 PXE boot :)
[17:56] <p0s> i've been using pxe boot kubuntu on my workstation for >1 year, i love it. its totally amazing that you only have to change < 10 lines of config for the machine to boot from pxe instead of harddisk...
[17:57] <p0s> but it only works with obsolete nfs... v2 or v3 i think cannot remember which one
[17:59] <SpamapS> p0s: I think you'll see it the other way if we start /ignoring you ;-)
[17:59] <p0s> :)
[18:01] <SpamapS> p0s: btw I forgot that if you say "debug" it puts all the output in /dev/.initramfs/initramfs.debug
[18:01] <SpamapS> which is why the output wasn't on the screen. ;)
[18:02] <p0s> SpamapS: ah... i suppose you dont need it now since you've reproduce it?
[18:02] <SpamapS> p0s: it would certainly be useful if you could get that and somehow get it off the system and into a file that you could upload
[18:02] <SpamapS> comparing two affected systems helps quite a bit actually
[18:03] <p0s> SpamapS: ok
[18:06] <p0s> SpamapS: the kernel has messaged me "usb 1-8: new USB device blah blah using ehic_hcd and address 2"... but there is no /dev/sdb ...
[18:06] <p0s> SpamapS: i mean i stuck in an USB stick
[18:06] <p0s> SpamapS: to save the debug log
[18:06] <SpamapS> p0s: hmm... did you, by any chance.. fail to apply updates?
[18:06] <p0s> SpamapS: any idea how i could get the name of the device?
[18:07] <p0s> SpamapS: the system was installed via PXE setup... netboot.tar.gz is 16mb, so i suppose it pulls ALL packages off the internet... therefore, all packages are up to date as of yesterday
[18:07] <SpamapS> p0s: can you dpkg -l mdadm ?
[18:07] <p0s> SpamapS: also i checked yesterday and it said all packages are up to date...
[18:07] <SpamapS> p0s: ok just checking
[18:08] <p0s> SpamapS: mdadm --version on the initramfs says: v3.1.4 - 31st August 2010
[18:08] <SpamapS> thats not what I need
[18:08] <SpamapS> the package version
[18:08] <SpamapS> and btw, no, I don't know how to mount the usb thing
[18:09] <p0s> SpamapS: well i can either try to obtain the debug log now or do the 20 boot attempts required to get the dpkg info
[18:09] <SpamapS> ok so wait-for-root seems to be the problem.. its returning before the md is actually available.
[18:09] <p0s> SpamapS: however i suggest you just check whether a new mdadm package was released yesterday or today... if it wasnt, then i have the version which was up-to-date yesterday...
[18:10] <SpamapS> p0s: I did the last update to it, about a week ago.
[18:10] <p0s> SpamapS: because as i said the system was installed yesterday with net-setup
[18:10] <SpamapS> p0s: just making sure
[18:10] <p0s> SpamapS: well i definitely installed it yesterday
[18:10] <SpamapS> p0s: that means nothing
[18:10] <SpamapS> your mirror could be out of date
[18:10] <SpamapS> or whatever.. dpkg -l is at least definitive
[18:10] <p0s> SpamapS: ok
[18:13] <cjwatson> doko: could you look at the lasso build failure at some point when you have a chance?  it's essentially that configure isn't finding jni.h (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624777), and I don't know what the proper way to fix that is
[18:13] <SpamapS> So interestingly enough.. slowing things down just a little bit by taking 'quiet' off the kernel cmdline makes it a lot harder to reproduce
[18:13] <p0s> SpamapS: found a way to obtain the debug log, hold on
[18:14] <SpamapS> ugh but the degraded array is not detected
[18:14] <SpamapS> seems like we need to check for degraded arrays explicitly, rather than have the kernel inform us by failing wait-for-root
[18:22] <p0s> SpamapS: http://pos.dyndns.ws/temp/initramfs.debug
[18:27] <p0s> SpamapS: please be patient while i try to boot the machine for obtaining the package version of mdadm.. i have to stand up and walk to it each time the booting fails....
[18:36] <tkamppeter> pitti, hi
[18:37] <SpamapS> p0s: no worries, mine is a VM and I have to re-sync the arrays every time I want to change something. :-P
[18:37] <p0s> SpamapS: hmm? you can change stuff on degraded arrays, whats the issue?
[18:38] <SpamapS> p0s: but it won't boot at all until its not-degraded
[18:38] <doko> cjwatson: mismatch between gcc & gcj version
[18:38] <p0s> SpamapS: ok fair point
[18:39]  * p0s is slowly being driven insane from the grub floppy seeking during the zillions of reboots
[18:40] <p0s> TRTRTRTRTRRTRR
[18:40] <SpamapS> p0s: reach behind the floppy and unplug it
[18:40] <SpamapS> ;)
[18:42] <psusi> someone still has a floppy drive?  I thought I killed all of those in 2004 when I wrote a Floppy driver for ReactOS...
[18:43] <psusi> shred with extreme predjudice
[18:43] <doko> cjwatson: lasso uploaded
[18:43]  * SpamapS recalls when an engineer showed him how to write a program that turned a floppy drive into a floppy degausser
[18:45] <psusi> hrm.. that shouldn't be possible... it implicitly degauses and then writes as once operation...
[18:47] <psusi> SpamapS: are you using /dev/md0 or the UUID?  If the UUID, then the uuid link won't be created by udev until the device is ready
[19:00] <p0s> SpamapS: i think i have reset the damn machine like 30 times now...
[19:00] <p0s> SpamapS: i will now boot it from usb and check /var/log for mdadm installation log...
[19:05] <p0s> SpamapS: there you go: mdadm 3.1.4-1+8efb9d1ubuntu4.1
[19:05] <p0s> SpamapS: if you need any other package versions you can ask now
[19:11] <Tapis> anybody have some clue about the steps to follow in order to build our own Ubuntu iso FROM an existing  installation, with basic tools, not with a script/GUI/whatever like remastersys :)
[19:11] <Tapis> ( FROM an existing installation guys, not from an iso, or whatever )
[19:14] <p0s> Tapis: do you really need an ISO? if you just want to clone the machine then insert the harddisk somewhere else (or boot the machine from usb stick / live cd / whatever) and use dd to copy the harddisk
[19:15] <doko> SpamapS, stgraber: please give back git on armel in about 30min, then if this is in the archive, autopoint (if cjwatson isn't back then)
[19:17] <Tapis> p0s: yes... i really need an iso, if it was that easy, i wont ask it ;p
[19:17] <Tapis> p0s: so, do you have any solution/clue about this ?
[19:18] <p0s> Tapis: ISO with shiny graphical setup? if you dont need a shiny graphical setup then just customize an existing boot distribution to have a script which writes your disk image to disk..
[19:21] <stgraber> doko: ok, will do
[19:22] <Tapis> p0s: i just need, at least, debian-installer ( well... ubuntu-installer, but it's the same :p ), no need to have ubiquity
[19:22] <Tapis> p0s: and i need to create from an existing installation, what do you mean by "customize an existing  boot distribution to have a script which writes your disk image to disk
[19:22] <Tapis> ?
[19:22] <p0s> Tapis: quick google yield: https://help.ubuntu.com/community/InstallCDCustomization/Scripts
[19:23] <Tapis> ...
[19:23] <Tapis> are you reading me ?
[19:23] <Tapis> from an EXISTING installation, not from an iso...
[19:23] <p0s> Tapis: i meant that you create a disk image of the installation which you want to duplicate, then you create your own linux live cd with a simplicistic wizard for writing the disk-image to the local harddisk
[19:23] <Tapis> ( i've already give a loog at this link, long time ago... )
[19:24] <p0s> Tapis: well you asked for the debian-installer, how is the debian installer supposed to install an existing system? the purpose of it is to set up a NEW system...
[19:25] <p0s> Tapis: you can either go for duplicating an existing system by image OR for customizing the new-system installation process with scripting so you dont have to manually interact with setup...
[19:25] <Tapis> hell... you don't understand what i want to do :)
[19:26] <p0s> Tapis: elaborate it
[19:27] <Tapis> first, you need to know, this is for an "exotic" system, i mean, i run Ubuntu on ps3
[19:27] <Tapis> then, you need to know, ( again ) that Ubuntu devel team, stop to build iso for the ps3 hardware
[19:28] <Tapis> so, i have to build my own iso, with an existing installation i run from an external device
[19:29] <Tapis> ( here the very latest Ubuntu iso image for ps3 : http://hr.archive.ubuntu.com/ubuntu-cdimage/daily/ as you can see, the latest build if from December 2010... )
[19:29] <Tapis> ok... the guy say "elaborate it" and then, he leave :p
[19:37] <p0s> SpamapS: sorry, left accidentially.
[19:40] <SpamapS> p0s: np
[19:40] <p0s> SpamapS: i suppose you got the mdadm version when i posted it here... need anything else?
[19:41] <SpamapS> p0s: yes, ty for all the help. I'm starting to understand the issue, though its still quite confusing
[19:46] <SpamapS> p0s: also for me, booting w/o quiet makes it far less likely to fail
[19:46] <p0s> SpamapS: thanks for the info, will use that when the issue is fixed and i have to update the packages
[20:06] <cjwatson> doko: lasso> ah, thanks
[20:08]  * cjwatson scores up git
[20:08] <cjwatson> and building
[20:09] <cjwatson> doko: I don't think autopoint needs to be given-back - it's just a straight unsatisfied dependency
[20:20] <sconklin> getting the missing audio in pieces, It will all have to be sorted and put in order
[20:36] <ttx> bdrung_: not sure, apparently tomcat7 grew a dep to eclipse jdt.jar.
[20:51] <psusi> cjwatson: would you endorse my application for universe-contrib?  https://wiki.ubuntu.com/PhillipSusi/DeveloperApplication
[20:56] <cjwatson> psusi: sure, what's the deadline?
[23:09] <cjwatson> pitti: gnome-pkg-tools depending on python-rsvg> argh, you couldn't have waited until we got armel rebootstrapped?
[23:10] <cjwatson> pitti: now gnome-pkg-tools Depends: python-rsvg Depends: librsvg2-common Depends: libgtk2.0-0 Depends: libatk1.0-0 Build-Depends: gnome-pkg-tools ...
[23:10] <cjwatson> pitti: where do you suggest we resolve this?  back out the gnome-pkg-tools change for a while, maybe/
[23:10] <cjwatson> ?
[23:13] <cjwatson> pitti: or is there any other way to avoid the loop?  it's bad for bootstrapping new architectures, too
[23:13] <cjwatson> though I guess I appreciate the requirement
[23:27] <cjwatson> pitti: maybe we can just drop python-rsvg and python-cairo for now?  from your changelog, it looks like those are only for the correctness test, and we still get the size reductions without them
[23:27] <cjwatson> that would let us get armel working again
[23:37] <infinity> cjwatson: I'd just drop the dep for the purpose of bootstrapping, yeah.
[23:37] <infinity> cjwatson: If you haven't already.
[23:46] <cjwatson> yeah, on reflection I'm going to - it makes atk1.0 unbuildable any time it's uploaded and isn't built by all architectures in the same publisher cycle
[23:46] <cjwatson> because of its tight dependency on libatk1.0-data, and this lop
[23:46] <cjwatson> loop
[23:55] <cjwatson> done