[00:00] <ebroder> Yeah, I saw that, too
[00:01] <ion> Loading all the stuff needed for a graphical plymouth before ureadahead does its thing would defeat the purpose of ureadahead, but printing a line of text wouldn’t.
[00:01] <jdong> "Loading loading screen...."
[00:01] <jdong> :)
[00:01] <jdong> is that like Windows 7's "calculating time remaining"?
[00:01] <ebroder> If I'm basically trying to create a livecd rootfs with the nvidia drivers baked in, what do I need to do? Install nvidia-current, drop in an xorg.conf, anything else?
[00:02] <ion> Plymouth’s purpose is not a loading screen. It’s multiplexing interaction between the user and startup programs.
[00:03] <cjwatson> well, plymouth yes, plymouth-splash not necessarily
[00:03] <cjwatson> I suspect we are in agreement from different directions, though
[00:09] <jdong> ion: sure, but given that it also functions as a loading screen, it looks a little bit confusing
[00:09] <jdong> ion: especially on machines with poor IO performance
[00:10] <ion> Yes, a dozen seconds of black screen isn’t optimal.
[00:11] <lilmonsta> hello all , apolagies for asking but is the 10.04.1 release still due today?   would it be the daily iso listed as 16.1?
[00:12] <ion> We should do what Windows™ does: drop the readahead stuff, generate (and keep updating) a model of disk usage patterns and use idle time to reorder disk blocks for optimal startup times. :-P
[00:13] <jdong> ion: theirs also includes a readaheader
[00:14] <ion> ok
[00:14] <jdong> it does some interesting throttling stuff though to minimize the devastation if the readahead info is really wrong (tm)
[00:14] <jdong> like for us, if you put 5000 random files in the readahead pack, your boot performance will really tank :)
[00:14] <jdong> (on HDD)
[00:15] <penguin42> (I was thinking Maverick is currently feeling slower at boot than lucid - but I haven't timed it)
[00:15] <jdong> my two Maverick machines at work here are reiser4 and btrfs
[00:15] <jdong> one doesn't support readahead, the other is slower than NFS to asia.
[00:15] <ebroder> Oww. You must not like your data
[00:15] <jdong> thanks to 2.6.35
[00:16] <jdong> haha experimental setup :)
[00:16]  * ajmitch thought all your setups were experimental
[00:16] <jdong> it is kind of a shame that it takes 7 hours 30 minutes to install from the alternate CD on btrfs in Maverick
[00:16] <jdong> wonder if we want to roll back that commit for ubuntu-maverick.git
[00:17] <RAOF> It's more of a shame that installing 80 updates takes 2 hours on btrfs.
[00:17] <jdong> (or cross our fingers and hope Oracle has a patch)
[00:17] <jdong> RAOF: I got pissed enough to locally revert that
[00:17] <ajmitch> RAOF: that sounds worse than my laptop :)
[00:17] <jdong> http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.git;a=commit;h=5da9d01b66458b180a6bee0e637a1d0a3effc622
[00:17] <jdong> that thing
[00:17] <RAOF> jdong: I got pissed enough to take an image (as it seems by btrfs partition is interestingly broken) and reformat to ext4
[00:18] <jdong> HAHAHA
[00:18] <jdong> ok that works too!
[00:18] <ion> Meh. I’m counting days until Oracle drops the btrfs project and instantly starts suing everyone using/developing/distributing it for infringing on their Imaginary Property. :-P
[00:18] <jdong> ion: well brtfs probably does violate the crap out of the ZFS patent portfolio
[00:20] <RAOF> chrisccoulson: Isn't it a bit late for you to be joining #ubuntu-devel? :)
[00:29] <chrisccoulson> RAOF, oh, i must have got disconnected for a bit ;)
[00:33] <RAOF> Aaah, ext4.  < 10 minutes to download and install 300 packages.
[00:34] <slangasek> wait, are you extolling ext4 because of how fast dpkg runs on it?
[00:35] <jdong> haha.
[00:36] <RAOF> slangasek: In comparison to how dpkg runs on *btrfs*, that's practically negative time :)
[00:37] <slangasek> interesting
[00:37] <RAOF> (at least in maverick)
[00:37] <lifeless> RAOF: good or bad on btrsfs?
[00:37] <RAOF> lifeless: Terrible on btrfs.
[00:37] <lifeless> let me guess
[00:37] <lifeless> fsync?
[00:37] <RAOF> On the order of 2 hours to install 80 already downloaded updates
[00:38] <RAOF> I'm not sure that it is fsync, actually, although my libeatmydata testing wasn't particularly rigourous.
[00:38] <lifeless> ok
[00:38] <lifeless> any ideas?
[00:38] <lifeless> and does eatmydata take care of the fsync variants ?
[00:38] <RAOF> jdong's already posted a link to the patch (series?) which causes a ~10x regression in write-heavy loads that's in Maverick
[00:39] <lifeless> (sync, fsyncdir)
[00:39] <RAOF> I think libeatmydata does, yes.
[00:39] <RAOF> There's an LP bug about this, too.
[00:42] <jdong> lifeless: and no, eatmydata doesn't take care of the btrfs thing. It has to do with delayed allocation not truly delaying allocation, forcing way more tree operations than needed
[00:42] <lifeless> jdong: thanks
[00:43] <jdong> Chris Mason had triaged the bug though and says he's working on a patch
[00:43] <RAOF> bug #601299 , if you're interested.
[00:43] <jdong> (two weeks ago)
[00:43] <jdong> wow, 12 hours to set up on a SSD
[00:43] <jdong> impressive!
[00:44] <jdong> oh nvm it's an Asus SDHC-on-a-card "SSD"
[00:45] <chrisccoulson> eatmydata is such a cool name. it almost makes me feel compelled to use it all the time
[00:46] <jdong> oh just patch eglibc if you're gonna do that ;-)
[01:20] <djzn> folks, 10.04.1 --- any hopes for tonight still ? or probably another 7 days...?
[01:36] <skat_> djzn, looking likely.   #ubuntu-release is fairly active ;)
[02:22] <djzn> so we don't get 10.04.1 tonight.....
[02:23] <ScottK> djzn: I wouldn't assume that.
[02:23] <ScottK> I guess it depends on when tonight ends for you.
[02:23] <djzn> ScottK: it ends in 1:30 hour.... -3.00 GMT
[02:23] <djzn> lol
[02:24] <ScottK> You might yet then.
[02:25] <djzn> ScottK: how can you be so sure... this has been postponed for a few days... yet, no sign of isos....
[02:27] <ScottK> I'm somewhat involved in the effort.
[02:29] <djzn> ScottK: I could notice that...
[02:31] <djzn> ScottK: I feel a hint.... that everything is already done... ISOs are ready... the thing is... there are several types of ISOs and each of them had to be produced.. the netbook one, the alternate one, even the DVD had to be made....
[02:32] <djzn> ScottK: But I am not sure... still a Fix Commited bug laying....
[03:21]  * ScottK was going to tell him it's out.
[03:21] <ajmitch> oh well, just a little late :)
[03:22]  * ajmitch wonders when the NZ mirrors will have it
[03:23] <ScottK> At least natty will be less typing than maverick.
[03:24] <ajmitch> but getting people to spell narwhal properly will be fun
[03:24] <ajmitch> At least it's not drapper :)
[03:32] <ajmitch> great, looks like one of the nz mirrors just has a recursive symlink
[03:58]  * huntz0r is away: I'm busy
[03:58] <ion> Thanks for the information!
[04:02] <huntz0r> bloody xchat...
[05:43] <pitti> Good morning
[05:44] <pitti> kirkland: pong
[05:44] <pitti> smoser: yup, will do ASAP
[07:32] <dholbach> good morning
[07:38]  * mneptok looks left
[07:38]  * mneptok looks right
[07:38]  * mneptok junps up and down on dholbach 
[07:38] <mneptok> MOIN!
[07:38] <dholbach> hi mneptok
[07:38] <mneptok> *tacklehug*
[07:40] <ajmitch> that's a nice enthusiastic greeting
[07:42] <TheMuso> Brutally so.
[07:42] <TheMuso> :)
[07:43] <dholbach> :-)
[08:46] <Sarvatt> were the non-LTS ports archives before jaunty moved to another server or were they wiped out completely?
[08:52] <tjaalton> Sarvatt: try http://old-releases.ubuntu.com
[08:54] <Sarvatt> phew, thanks tjaalton!
[08:57] <tjaalton> this is weird, mounting Maple14 cdrom doesn't work otherwise but manually
[08:57] <tjaalton> both on lucid & maverick
[09:11] <soren> tjaalton: The maple cdroms are rather special, irrc.
[09:11] <soren> iirc, even.
[09:11] <soren> tjaalton: I believe it will look different depending on whether you mount it from linux, windows or mac.
[09:12] <soren> tjaalton: ...and it'll look different depending on whether you mount the iso like you normally would or if you look at it through one of the userspace tools to inspect iso's.
[09:13] <soren> tjaalton: In short, I'm not surprised some things act up. They shouldn't, but I'm not surprised :)
[09:15] <tjaalton> soren: ah, could be like that yes
[09:16] <tjaalton> well, whatever tries to automount them should be fixed to support those I suppose :)
[09:24] <tjaalton> soren: worked on jaunty though, so sounds like a regression to me ;)
[09:24] <tjaalton> (just tested it)
[09:27] <soren> tjaalton: I remember having problems in... err...
[09:27]  * soren rewinds his brain a couple of years
[09:27] <soren> err.. edgy, it must have been.
[09:29] <tjaalton> soren: ok.. now it seems to be udev handling the mounts?
[09:31] <soren> tjaalton: No idea.
[09:33] <cjwatson> udev won't be mounting things itself.  perhaps udisks.
[09:34] <tjaalton> right
[09:34] <sivang> hi all
[09:36] <sivang> What are the tools commonly used to allow participants not in physical presence to be part of a developer's summit? http://gobby.0x539.de/trac/ comes to mind, but what other tools have past summits used?
[09:51] <bilalakhtar> bdrung: there?
[09:51] <bdrung> bilalakhtar: yes
[09:52] <bilalakhtar> bdrung: a main patch, ready?
[09:52] <bilalakhtar> bdrung: patch has been accepted in MeeGo
[09:52] <bilalakhtar> package: gnome-disj-utility
[09:52] <bilalakhtar> K
[09:52] <bdrung> bilalakhtar: i will put it on my list. i will have time for it in the evening
[09:53] <bdrung> bilalakhtar: can you give me the lp?
[09:53] <bilalakhtar> bdrung: Thanks a lot! https://code.edge.launchpad.net/~bilalakhtar/ubuntu/maverick/gnome-disk-utility/fix-414107/+merge/32966
[09:53] <bilalakhtar> bug #414107 bdrung
[09:54] <bilalakhtar> its a branch merge, hence bug is in-progress
[09:54] <bdrung> bilalakhtar: if your branch is ready, unassign yourself
[09:54] <bilalakhtar> bdrung: and, status of bug?
[09:55] <bdrung> bilalakhtar: sponsor don't care about the status
[09:56] <bdrung> bilalakhtar: i saw statuses of (new, confirmed, triaged, in progress, fix committed)
[09:56] <bilalakhtar> huh?
[09:56] <bilalakhtar> bdrung: what does that mean?
[09:57] <bilalakhtar> bdrung: I don;t need to subscribe sponsors to the bug, right?
[09:58] <bdrung> bilalakhtar: the merge request will appear on the sponsors list. so no need to subsrcribe the team.
[09:58] <bilalakhtar> bdrung: what do you mean by 'I saw statuses of .....'
[10:00] <bilalakhtar> ah well leave it. I know bdrung is busy. Bye!
[10:01] <bdrung> bilalakhtar: the bugs that i sponsored had a status of one of the mentioned above. we have no rule which status the bug should have.
[10:02] <bilalakhtar> aha bdrung thanks
[10:03] <bdrung> bilalakhtar: it could be everything except a 'fixed' status or Incomplete
[10:03] <bilalakhtar> thanks bdrung
[10:06] <bilalakhtar> bdrung: I just ran update-maintainer over it, so if you have already downloaded the branch, please pul
[10:06] <bilalakhtar> *pull
[10:07] <bdrung> bilalakhtar: i haven't pulled it yet. sponsor-patch will run update-maintainer (and therefore catch those mistakes) ;)
[10:07] <bilalakhtar> thanks bdrung :)
[10:42] <ricotz> seb128, hello
[10:42] <seb128> hi ricotz
[10:42] <ricotz> seb128, looks like i have a working gtk+3 package :)
[10:43] <seb128> ricotz, can you talk about it on #debian-gnome?
[10:43] <ricotz> ok
[10:43] <seb128> ricotz, ideally we would get it in debian, they started work there
[11:17] <theclaw> hi
[11:18] <theclaw> how do I have to mark config files so that when installing the package, I will get asked whether I want to overwrite the config?
[11:19] <theclaw> I already tried putting the configs in 'conffiles'
[11:21] <cjwatson> just install them somewhere under /etc, and use debhelper compat level 3 or above (usually 7 these days)
[11:21] <cjwatson> with even remotely modern debhelper you don't need to fiddle with conffiles by hand
[11:21] <cjwatson> it will only prompt you if there are some local changes versus the distributed copy
[11:22] <theclaw> yes, I have local changes. Maybe I'm using an outdated debhelper
[11:22] <cjwatson> astonishingly unlikely
[11:23] <cjwatson> well, you might be using an outdated debhelper compat level
[11:23] <theclaw> cjwatson: I have '5' in debian/compat, so this shouldn't be the problem?
[11:23] <cjwatson> but debhelper 3 dates back to 2001
[11:23] <cjwatson> then there is something else wrong and we would need detailed information (e.g. an example) to debug it
[11:23] <seb128> hum, "vesamenu.c32: not a COM32R image"
[11:24] <seb128> I wonder what went wrong with that lucid usb stick I just did
[11:24] <cjwatson> the installed version of syslinux tends to need to match
[11:24] <theclaw> cjwatson: I can't distribute anything of the package, sorry
[11:24] <seb128> cjwatson, you mean I can't do a lucid usb key with maverick usb creator?
[11:25] <theclaw> cjwatson: but thanks for the hints
[11:25] <seb128> or on maverick rather
[11:25] <cjwatson> seb128: only if you downgrade to lucid's syslinux
[11:25] <cjwatson> (at the moment)
[11:25] <seb128> cjwatson, ok thanks
[11:25] <cjwatson> theclaw: can't help if you can't share
[11:25] <seb128> I did the keys 3 times and rsync the iso again to be sure
[11:25] <seb128> it's a non obvious issue ;-)
[11:25] <cjwatson> there's an open bug for it
[11:26] <cjwatson> ev and I have talked about it, but it's mostly been conference/holiday season since then
[11:26] <seb128> ok, thanks
[11:26] <seb128> at least I know what's going on now ;-)
[11:27] <cjwatson> I'm not sure what the right answer is given that syslinux isn't actually on the CD, only isolinux
[11:42] <bilalakhtar> bdrung: I actually need to get it SRUed into Lucid at the same time. How to do this with a branch? since lp:ubuntu/lucid-proposed/gnome-disk-utility does not exist.
[11:46] <tumbleweed> bilalakhtar: propose merging into lucid instead of lucid-proposed?
[11:47] <bilalakhtar> tumbleweed: is that acceptable?
[11:47] <bilalakhtar> tumbleweed: ok, I will follow the good-old debdiff method
[11:47] <tumbleweed> other people seem to do that, the problem is that the merge request will never be marked Merged automatically...
[11:48] <tumbleweed> (and the reviewer can't mark it merged / WIP)
[11:48] <bilalakhtar> tumbleweed: well, since it is my first SRU, I don;t want to experiment with it
[11:48] <bilalakhtar> so I am debdiffing
[11:48] <tumbleweed> bilalakhtar: :)
[11:55] <bilalakhtar> tumbleweed: if you are free, bug #619738
[11:56] <bilalakhtar> tumbleweed: you were the one who got the ubuntu patches there
[11:56] <tumbleweed> bilalakhtar: hah, sure
[11:57] <geser> bilalakhtar: what's the benefit of syncing it now?
[11:57] <bilalakhtar> geser: why?
[11:57] <tumbleweed> bilalakhtar: that wasn't an ubuntu patch
[11:57] <bilalakhtar> geser: so that in N release they get synced automatically
[11:57] <bilalakhtar> tumbleweed: I know, but the reason is the same
[11:58] <bilalakhtar> geser: people say: Drop the ubuntu changes whenever possible
[11:58] <bilalakhtar> tumbleweed: the current ubuntu changes and the debian accepted changes are somewhat different, but they have the same goal: move away from python2.5
[11:59] <geser> bilalakhtar: yes, but we are currently past FF and should start focusing towards release. That also excludes syncs which no benefit right now.
[12:00] <bilalakhtar> geser: ok, I will take care about it next time onwards.
[12:01] <geser> being able to autosync for N isn't IMHO a valid reason for syncing (at least if it's the only reason)
[12:02] <bilalakhtar> geser: ah, ok, please allow this one, I will take care from the next time onwards
[12:07] <geser> bilalakhtar: sure (it's up to your sponsors to ACK it or not) but please consider if syncing a package gains us anything for the release for next syncs/merges
[12:07] <geser> we shouldn't sync/merge because we can
[12:07] <bilalakhtar> ok, I will take care from the next time onwards, geser
[12:08] <cjwatson> geser++
[12:48] <sabdfl> seb128: did you get a chance to look into gnome-terminal tabs?
[12:50] <seb128> sabdfl, not yet, still busy with feature freeze exception from dx and other teams
[12:52] <sabdfl> okdokey
[12:52] <sabdfl> i saw the version bump this morning and got all hopeful ;-)
[12:54] <seb128> sabdfl, no, that was just standard GNOME 2.31 update ;-)
[13:53] <pitti> slangasek, robbiew: \o/ 10.04.1
[13:54] <ricotz> jcastro, hello
[13:55] <pitti> robbiew: hm, https://wiki.ubuntu.com/LucidLynx/ReleaseNotes/ChangeSummary/10.04.1 looks a bit thin?
[13:56] <pitti> is there a non-boilerplate version of this?
[14:16] <cjwatson> pitti: we were stuck on a silly UTF-8 decoding error in the script that generates it - I gave a fixed version to robbiew a couple of hours ago, so he should be able to fill that out once he's up
[14:16] <cjwatson> the error was ultimately down to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593442, if you care ...
[14:17] <pitti> cjwatson: oh nice, it's autogenerated now?
[14:18] <cjwatson> pitti: more or less always was partially; it requires manual editing to do categorisation and get it into a consistent editorial voice
[14:34] <\sh> cjwatson: I just stumbled upon a bug discussion for openssh + the ldap patch...do you still support your argument, or would it be a good idea to re-check the quality of the openssh LPK  patch (bts: #319244)
[14:34] <cjwatson> I still support my argument - get it upstream first, I'm not going to carry it in a distro
[14:34] <cjwatson> sorry
[14:35] <cjwatson> I haven't made any argument either way about the quality of the patch, so that is a red herring
[14:36] <\sh> cjwatson: I just trying to find now any reference from upstream about this issue...but looks like I'm too tired to read all google hits
[14:38] <\sh> ah there
[14:41] <pitti> hm, we recently started to pull in openjdk into the images, leading to massive oversizedness
[14:44] <ahasenack> pitti: hi, is 10.04.1 out yet?
[14:44] <pitti> ahasenack: yes
[14:44] <ahasenack> pitti: cool, so -proposed is unfrozen?
[14:45] <pitti> ahasenack: right; I'll get to SRUs ASAP
[14:45] <ahasenack> pitti: thanks
[14:46] <\sh> cjwatson: when you are interested in this topic: http://marc.info/?l=openssh-unix-dev&m=127607159208207&w=2 -> the whole thread :)
[14:51] <jcastro> ricotz: hi
[14:52] <ricotz> jcastro, hi, how is the progress with the gome3 (gnome-shell) ppa?
[15:01] <jcastro> ricotz: I am not sure, I've been gone for a bit, seb128 might know
[15:01] <ricotz> jcastro, there are still plans to provide a ppa with a gnome3 preview?
[15:02] <ricotz> jcastro, ah, ok, then i am up2date
[15:02] <seb128> ricotz, not really
[15:02] <seb128> ricotz, we need to get gtk3 in with all those libraries changes first but everybody is busy
[15:03] <ricotz> seb128, ok
[15:03] <seb128> with GNOME3 delayed from one cycle and gtk3 delayed until end of year we almost have extra time
[15:04] <ricotz> seb128, ok, but the goal is still to get gtk3 into maverick?
[15:04] <seb128> would be nice to get it in universe yes
[15:05] <ricotz> my package still has some file collisions with gtk2, i am not sure about the right way to solve them
[15:06] <ricotz> but gnome-shell can be built again with it
[15:06] <cjwatson> \sh: thanks.  they seem to be going about things the right way, at last; there is probably some hope
[15:09] <robbiew> pitti: fyi, starting on the change summary now...assuming python holds up :)
[15:12] <pitti_> ahasenack: I followed up to bug 610744, there's still some bug cleanup to do
[15:13] <seb128> ricotz, I would appreciate if you didn't have your own gtk3 version in a ppa
[15:13] <seb128> ricotz, it has potential to create trouble for users who want to try it and don't know it might conflict with the official builds when we will have those
[15:14] <ricotz> seb128, yes, that is why i want someone of you to review it
[15:15] <ricotz> i still have it in my staging ppa which shouldnt be used
[15:21] <free> pitti_: hey, didn't we agree on opening SRU tasks only for the main SRU bug (which references the other ones)? for sake of convenience
[15:22] <pitti> free: we did? I can't remember
[15:22] <free> pitti: also I think that internally we were marking bugs as "Fix released" only when the packages actually hit -updates
[15:22] <pitti> free: but anyway, if the 1.5.4 changelog claims to fix a bug which is still open upstream and targetted at 1.5.5, there's something wrong?
[15:22] <pitti> free: that's what the Ubuntu task should be for then
[15:22] <pitti> free: but ok, I can accept the "fix committed" upstream state, even if it's slightly weird
[15:23] <free> pitti: right, I'm fine whatever, I just didn't open tasks because of the above
[15:23] <pitti> ok, I can't remember the discussion where we agreed to not add SRU tasks
[15:25] <free> pitti: about the wrong milestone, sorry about that, the bug should have been marked "Fix committed" quite a bit ago, but we forgot, so it was automatically shifted to 1.5.5 by a script we use at the end of the milestone
[15:25] <free> pitti: so do you prefer to have tasks for all bugs or only for the main one?
[15:25] <ScottK> Is http://people.canonical.com/~ubuntu-archive/NBS/ updating correctly?  I uploaded most of the rebuild targets for http://people.canonical.com/~ubuntu-archive/NBS/libkrb5-25-heimdal last night and even the ones that built ~12 hours ago still show there.
[15:25] <pitti> ScottK: hm, usually it does
[15:26] <pitti> cronjob is working, anyway, but only every 8 hours
[15:26]  * ScottK checks another one.
[15:27] <ScottK> pitti: Probably just got caught in the window where we don't get a publisher run for a few hours + the 8 hour cron job cycle.
[15:27] <ScottK> I'll check it again tonight then.
[15:27] <ScottK> Thanks for looking.
[15:27] <pitti> np; I have used it a few days ago, and it was working fine
[15:28] <pitti> but please let me know if the next update (at 1900 UTC) is still bad
[15:28] <ScottK> Will do.
[15:40] <cjwatson> slangasek: could you review https://code.launchpad.net/~csurbhi/ubuntu/maverick/samba/samba-fix.276472/+merge/32753 ?
[15:50] <slangasek> cjwatson: my review is not worth much there; it looks syntactically correct, but should be reviewed by somebody who understands the protocol better
[15:50] <slangasek> (i.e., upstream)
[15:51] <slangasek> cjwatson: (do you want me to follow up with an actual merge review saying this?)
[16:04] <cjwatson> slangasek: sure, just looking for somebody to claim it really
[16:53] <cnd> Hi all, are MIR reports processed on a set schedule?
[16:53] <cnd> seb128, pitti ^^?
[16:53] <pitti> cnd: not sure, asac is driving it these days
[16:53] <pitti> but I expect not
[16:54] <cnd> asac, in case you missed my question due to your ping timeout :), are MIR reports processed on a set schedule?
[17:19] <bilalakhtar> Can anyone accept the nominations at bug #414107 ?
[17:23] <achiang> slangasek: this bug has a patch and looks like Keybuk even reviewed it; any chance of taking a look? https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/537133
[17:57] <bilalakhtar> bdrung: about the bug I told you, there is an SRU also needed for it, so when you look at the maverick branch, could you please look at the debdiff attached to the bug report also (sponsors subscribed there)? That debdiff is for getting the package into lucid-proposed
[18:11] <jibel> cjwatson, hello, bug 619135, do you think that's really a packaging issue or dpkg becoming suddenly overly verbose due to the changes in 1.15.8.4 ?
[18:11] <jibel> cjwatson, the relevant changelog entry "* Always print a massage on warning when parsing control files."
[18:39] <akheron> I did do-release-upgrade on a karmic server today, everything was fine until libc-i686 was upgraded
[18:40] <akheron> right after that everything started to fail, failing about missing version GLIBC_2.11
[18:41] <akheron> *complaining
[18:41] <akheron> what could be wrong?
[18:42] <penguin42> akheron: Can you get an ldd /bin/ls out of it?
[18:42] <akheron> I can reproduce this easily, as I have a backup disk image of the server
[18:42] <akheron> penguin42: after the upgrade has failed?
[18:43] <penguin42> akheron: Yeh depending just how failed it is
[18:43] <akheron> I don't think so, as at least ls just segfaults
[18:43] <sebner> JontheEchidna: hola :) , if you are bored you could update k3b and make another backport maybe? :)
[18:43] <akheron> I cannot access the machine right now, and before trying again I would have to restore the backups
[18:55] <djzn> ScottK: Just dropped by to say THANK YOU for the point release
[18:56] <ScottK> djzn: It was very little to do with me, but you're welcome.  You left just slightly too soon last night.
[18:56] <djzn> yeah, i had to sleep, but doesn't matter now, it's there...
[19:18] <JontheEchidna> sebner: ooh, turns out I can merge from debian. :)
[19:21] <highvoltage> JontheEchidna: nice :)
[19:45] <SpamapS> pitti: Don't know if you noticed, but I proposed merging a change to the WI tracker that will allow you to stop regenerating all the html/burndown/json for closed out milestones.
[19:45] <SpamapS> pitti: and currently looking at speeding up the select statements a lot
[20:18] <mycae> Hello. I think I was asked in a bug to request an FFE for a  package sync (minor package that was new to debian), but I cannot seem to find any documentation on how one does this. In fact, i thought this was what I was doing. Does anyone know what I am supposed to do? (bug #617787)
[20:21] <micahg> mycae: looks like you're fine on this
[20:21] <micahg> archive admins are subscribed and FFe was approved
[20:21] <mycae> ok. good. was not clear if I had to "get" an FFE from someone/where
[20:22] <mycae> thankyou.
[21:05] <maco> i just got an email from lp saying a package i uploaded failed to build on itanic but the FAILEDTOBUILD.txt.gz says "Built  successfully" partway down...
[21:05] <maco> like, right at that end bit before the chroot cleans up and uninstalls all the stuff it installed as build deps
[21:06] <maco> i am confused by this definition of fail
[21:06] <SpamapS> maco: it detected that ia64 was a failure and noted it for you.
[21:07] <SpamapS> they've added fuzzy logic now.. if processor_architecture.value == 0: send fail email
[21:08] <SpamapS> ia: can you paste a link to the build?
[21:09] <maco> http://launchpadlibrarian.net/53949323/buildlog_ubuntu-lucid-ia64.skyeye_1.2.5-2ubuntu1.10.04.1_FAILEDTOBUILD.txt.gz
[21:18] <geser> maco: the failure is "Function `get_sym' implicitly converted to pointer at utils/main/skyeye.c:200
[21:18] <geser> "
[21:18] <geser> the source file is missing the prototype for the function
[21:19] <maco> why is that so far after the "build successful" message?
[21:19] <geser> the buildd scans the output for this and fails if it's found
[21:19] <maco> and that's a bit odd
[21:19] <geser> amd64 should fail the same way
[21:19] <maco> since its a no-change rebuild
[21:20] <maco> and the package it didnt change from /did/ build on ia64
[21:20] <geser> but a lib might have changed between the time it got build last and now
[21:21] <maco> well i dont know about ia64, but amd64 does not fail in pbuilder
[21:22] <maco> ...and actually on lp it did complete on amd64
[21:22] <maco> hmm ...
[21:22]  * maco goes back to calling it itanic
[21:22] <geser> yeah, hmm
[21:23] <geser> perhaps a header which doesn't get included on ia64 for some reason
[21:23] <maco> im glad amd64 won the 64bit market
[21:25] <ScottK> maco: You can ignore ia64 anyway, it's about to be killed.
[21:25] <ajmitch> the TB have spoken
[21:25] <ScottK> Yep.
[21:26]  * ScottK isn't sure why ia64 went along with sparc since it was still functional, but oh well.
[21:26] <maco> which was still functional?
[21:26] <ajmitch> I think it wa sfunctional but noone was caring for it
[21:26] <ScottK> ia64
[21:26] <ajmitch> but it at least booted afaik
[21:26]  * ScottK saw ia64 specific bugs reported by users as recently as Karmic.
[21:27] <ScottK> So I think it even has a non-zero number of users.
[21:27] <maco> im surprised by that
[21:27] <ScottK> But it's decided now anyway.
[21:27] <maco> do they even sell itanium hardware anymore?
[21:27] <maco> i saw it for like 6 months then people realised they couldnt use 32bit windows on it, then it went away
[21:27] <achiang> hp sells quite a bit of ia64
[21:28] <maco> is that servers?
[21:28] <achiang> it only makes $10B / year for them
[21:28] <ScottK> Yes
[21:28] <maco> ah
[21:28] <achiang> actually, that number seems wrong, please ignore it
[21:28]  * ScottK has a server running Hardy that has a motherboard/CPU that dates from 1999.
[21:28] <mdke> slangasek: around?
[21:29] <ajmitch> perhaps the port can be revived if someone steps up to look after it
[21:29]  * ScottK has another running Lucid from 2000.
[21:29] <ScottK> Perhaps, but restarting a port is hard.  Ask lamont about restarting hppa.
[21:29]  * maco would use debian if the year starts with a 1
[21:29] <penguin42> there are probably quite a few Ia64 workstations/small servers that geeks have managed to hang on to when the places they work were about to throw them out
[21:30] <ScottK> Since it's in Lucid, they'll be able to do it for another 3 - 5 years.
[21:30] <penguin42> or actually after they through them out :-)
[21:31] <ScottK> The last Sparc installer that worked was Gutsy.  The last working system was, I think, Jaunty.  So it's in a very different situation.
[21:32] <ajmitch> maco: what's wrong with using debian? :)
[21:32] <ajmitch> penguin42: especially if they have shares in power companies
[21:32] <maco> ajmitch: it's more about what's wrong with using ubuntu
[21:32] <penguin42> ajmitch: They make great heaters
[21:33] <ajmitch> maco: if you have an ia64, the answer would be obvious :)
[21:33] <maco> ajmitch: i was referring to ScottK's old machines
[21:33] <maco> i tried feisty on a c1998 machine. that was...on the edge of bearable
[21:34] <ajmitch> I had breezy on an old laptop with 128MB of RAM
[21:34] <maco> i doubt it could boot lucid..if i could find it
[21:34] <ajmitch> it was interesting
[21:35] <maco> etch + e17 was the fanciest thing i could run on it and still have enough ram available to run 1 app at a time
[21:35] <ScottK> Up through Hardy I have a laptop with 256MB of RAM I ran Kubuntu on (and even built packages)
[21:35] <ScottK> have/had
[21:35]  * ajmitch would just like little things like suspend/resume to work on hardware from last year, let alone having an ancient laptop boot
[21:35] <maco> (er, ram+swap)
[21:35] <maco> ajmitch: ancient things are more likely to work i think
[21:36] <maco> nice old stable drivers
[21:36] <ajmitch> rather than using things like fglrx
[21:36] <maco> if it predates this wifi and bluetooth dohickeys, itll probably be happy :P
[21:36] <maco> ScottK: did you have to install your own ethernet cards on those machines, or did they come with them?
[21:37] <ScottK> One came with the other is home built, so I had to add it.
[21:38] <ScottK> The laptop needed a PCMCIA ethernet card.
[21:38] <ScottK> Err wifi card.
[21:38] <ScottK> Ethernet was built in.
[21:38] <maco> i think the WinME machine was the first we had that could do ethernet
[21:52] <cjwatson> jibel: I think it might be dpkg breakage - I noticed it myself on different packages, but at the time put it down to the fact that I only restored this system from backup recently
[23:57] <jdong> hmmmmm
[23:57] <jdong> any way to debug when APT tells me "Hash Sum Mismatch" but I don't believe it?
[23:57] <jdong> the Release file's md5sum and sha1sum listed for a Packages.bz2 matches what I get when I manually fetch the URL
[23:59] <penguin42> jdong: I've seen that type of thing happen with dodgy ram or other faults