[00:06] <YokoZar> cjwatson: I would really appreciate the new upstream icoutils in Debian (and working its way to Ubuntu), since I need the new version to show Vista-era embedded icons with gnome-exe-thumbnailer
[00:26] <Riddell> RAOF: is mesa-demos for main or universe?
[00:26] <RAOF> Universe.
[00:52] <SpamapS> mathiaz: you were asking before about the drizzle stuff...
[00:52] <mathiaz> SpamapS: yeah - I've read your update on teh bug
[00:52] <mathiaz> SpamapS: IIUC we'll wait for debian
[00:53] <SpamapS> mathiaz: right.. going through licenses now
[00:54] <SpamapS> mathiaz: there are a few bash scripts and such in drizzle that have unclear licensing.. I'm contacting authors asking them to send in patches adding license headers ... is that overkill?
[00:55] <mathiaz> SpamapS: not necessarly
[00:55] <mathiaz> SpamapS: how critical are the scripts?
[00:55] <mathiaz> SpamapS: would it be easier to just replace the scripts?
[00:55] <mathiaz> SpamapS: rather than chasing down proper licensing?
[00:55] <SpamapS> most are examples or config/contrib helper bits
[00:55] <SpamapS> mathiaz: some yes thats already been done.. a few of them are super tedious scripts.. the kind you're super thankful somebody did so you don't have to. ;)
[00:56] <ebroder> tseliot: ping?
[00:56] <mathiaz> SpamapS: agreed - contact the author then
[00:56] <mathiaz> SpamapS: and get in touch with the drizzle team to make sure it doesn't happen again ;)
[00:59] <SpamapS> mathiaz: they're discussing a hudson trigger to flag file adds that don't have the word 'copyright' or 'license' in them
[01:00] <mathiaz> SpamapS: nice :)
[01:10] <SpamapS> mathiaz: I'm a little confused as to how to get started submitting blueprints for uds-n
[01:11] <SpamapS> mathiaz: do I just create one, fill in the blurb, and pray? ;)
[01:11] <mathiaz> SpamapS: let me check my email
[01:11] <mathiaz> SpamapS: there was a message that outlines the process
[07:01] <pitti> Good morning
[08:21] <pitti> Riddell: FYI, if the current images are oversized, please just remove a langpack; we'll get fresh ones right after RC and can then put them back
[08:25] <Riddell> pitti: done
[08:30] <Riddell> "ask MartinPitt to disable apport via update-notifier (for RC)"
[08:31] <Riddell> pitti: how's that doing? ^^
[08:31] <pitti> oh, good call
[08:31] <pitti> Riddell: I'll upload it right now, together with kerneloops
[08:32] <pitti> Riddell: there's an additional script change to debian/local/ubuntu-fat-chroot which I had in bzr; it's not used on clients at all, but just for generating chroots for the retracers
[08:33] <Riddell> fine with me
[08:35] <pitti> both uploaded
[08:36] <pitti> I added kerneloops to the checklist
[08:36] <pitti> Riddell: traditionally we disabled them right after the RC, so they could stay in the queue until Thursday
[08:37] <pitti> but if you prefer getting them in now, no objections from my side
[08:43] <Riddell> if that's what tradition dictates that's what we should do
[08:56] <cjwatson> YokoZar: somebody was supposed to be adopting icoutils from me, but then went quiet :-/
[08:56] <YokoZar> cjwatson: mind if I do it then?
[09:06] <cjwatson> YokoZar: go ahead
[11:04] <jibel> can somebody moderate my email to ubuntu-devel ?
[11:10] <cjwatson> jibel: done
[11:10] <jibel> cjwatson, thank you.
[11:22] <maxb> With release more and more impending, who can I ask to find out whether someone is planning to handle sun-java6 upload to the partner archive before release?
[11:22] <maxb> NB that this is an odd package, because it is synced from Debian non-free to the partner archive
[11:28] <cjwatson> if it's just a sync, file an archive bug for it and we'll figure it out
[11:28] <cjwatson> I seem to remember syncing into partner was fiddly, but nevertheless
[11:29] <cjwatson> (I have an e-mail trail somewhere which I can dig out)
[12:08] <\sh> maxb: doko is on it, i think, as I was asking the same yesterday
[12:08] <maxb> Ah. Provided someone's visual that it really needs to happen in time for release, that's good
[12:16] <apw> pitti, i was wondering about natty work items (again :) and wondered if that is something i could help with, looks like the automation is per series at the cron level
[12:26] <pitti> apw: in principle, it shoudl be sufficient to add a config/natty.cfg to the WI tracker
[12:26] <pitti> the rest should Just Work (tm)
[12:26] <apw> pitti, won't that put them under maverick though?
[12:28] <apw> pitti, ahh no perhaps not i thought lenaro etc was mixed in there but perhaps not
[12:28] <apw> pitti, shall i put one together ?
[12:28] <pitti> apw: not if it says release = 'natty'
[12:28] <pitti> apw: but there is no natty release in LP yet, so it wouldn't work
[12:29] <apw> (i assume you are snowed under right now0
[12:29] <pitti> and likewise, there can't be natty-targetted specs in LP
[12:29] <apw> doh ... i'll shut up then
[12:40] <Chipzz> dapal: why do you think bringing up a *debian* bug full of ad hominem attacks on #ubuntu-devel is appropriate? especially during final freeze?
[12:51] <mr_pouit> Chipzz: and why do you care? especially during final freeze? (they can probably handle that themselves without you)
[13:06] <dapal> Chipzz: apologies for bringing that here.
[13:08] <Chipzz> dapal: maybe my reaction was a bit harsh, but I just don't think #ubuntu-devel is the right place to talk about contraversial issues (dare I say flamewars?) concerning only the debian project
[13:09] <Chipzz> anyway no need to apologize to me; I'm not an ops or whatever here; I just thought it didn't belong here and there are other avenues of resolving it
[13:10] <dapal> Chipzz: I don't want to continue it here; but seeing a person ignoring all pings from one side, and being very active on the other one is.. sad.
[13:10] <dapal> just IMVHO
[13:10] <dapal> anyways, I'm off, bbl
[13:25] <zul> pitti: hi when you get a chance can you let the landscape-client SRU to go into proposed?
[13:28] <smb> pitti, And if you have a little more time, there are rebases for the current lucid master of fsl-imx51 and mvl-dove. Can we get them into proposed as well? ec2 will hopefully follow shortly.
[13:42] <pitti> zul: ah, thanks for the reupload; will do
[13:42] <zul> pitti: thanks
[13:46] <pitti> smb: yup
[13:46] <smb> pitti, cool
[14:04] <YokoZar> what is the correct way to give a file in a package a linux capability?  setcap requires root but packages don't build as root, and I'm hesitant to add setcap to the maintainer script...
[14:05] <pitti> YokoZar: there's no packaging mechanism for that
[14:06] <YokoZar> pitti: for some reason I thought ping had cap_net_raw rather than run suid 0
[14:06] <pitti> YokoZar: usually you'd start the program as root and then call capset()
[14:06] <pitti> and then setuid()
[14:07] <YokoZar> pitti: so I'd need some sort of wrapper?
[14:08] <pitti> YokoZar: not really, just some startup code (prctrl, setcap, and setuid), and making the program suid root
[14:08] <persia> pitti, Presume that upstream didn't provide any of that :)
[14:10] <pitti> YokoZar, persia: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/dapper/dhcp3/dapper/annotate/head%3A/debian/patches/droppriv.dpatch
[14:11] <persia> Oh, cool!
[14:11] <persia> Thanks.
[14:11] <pitti> that's a convenience function that I wrote about a million years ago
[14:11] <pitti> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/dapper/dhcp3/dapper/annotate/head%3A/debian/patches/deroot-client.dpatch shows how to use it
[14:11] <pitti> but it boils down to
[14:11] <pitti> cap_value_t capsneeded[] = { CAP_NET_RAW, CAP_NET_BIND_SERVICE };
[14:11] <pitti> drop_privileges( "dhcp", "dhcp", 2, capsneeded, -1 );
[14:12] <pitti> the first two are user and group name
[14:12]  * pitti yays at bzr archeology
[14:17] <YokoZar> pitti: thanks, that seems useful
[14:17]  * YokoZar thinks a debhelper extension for filesystem capabilities support at the packaging layer would be best...
[14:18] <pitti> YokoZar: are we really talking about the same thing here?
[14:18] <pitti> fs capabilities != kernel capabilities
[14:18] <pitti> I suppose you mean capabilities(7), since Linux has fs ACLs, not capabilities
[14:19] <YokoZar> pitti: kernel caps can be made permanent with extended attributes on a file, yes?
[14:19] <pitti> YokoZar: alternatively you can ship an apparmor profile
[14:19] <YokoZar> (ie, what setcap from libcap-bin does)
[14:19] <pitti> YokoZar: I don't know; I just know extended ACLs, which are unrelated to kernel caps
[14:20] <YokoZar> pitti: I think when you wrote the linked code the kernel didn't support file-based capabilities lists and it all had to be done at runtime, so dropping them was the only option
[14:20] <pitti> YokoZar: right, but I still wouldn't bet on fs support
[14:21] <pitti> not as long as we still get bugs with /usr on NFS, or using about five different file systems
[14:21] <pitti> I'd rather prefer apparmor profiles then; they can specify caps, too
[14:21] <YokoZar> pitti: fair enough...I take it NFS doesn't support extended attributes at all then?
[14:22] <pitti> I can't say for sure -- just that I wouldn't bet on it :)
[14:22] <pitti> it might do
[14:25]  * YokoZar wonders if one of the columns on http://en.wikipedia.org/wiki/Comparison_of_file_systems#Metadata  is helpful here
[16:29] <hyperair> http://apachelog.wordpress.com/2010/09/21/an-inconvenient-truth/ <-- this sure says something about the GNOME environment in ubuntu, doesn't it?
[16:30] <cjwatson> page not found
[16:31] <cjwatson> s/21/28/ apparently
[16:45] <hyperair> cjwatson: i dunno, i picked it out of my rss feed.
[17:07] <shadeslayer> hyperair: :>
[17:08]  * shadeslayer has secret link to that page
[17:08] <hyperair> lol
[17:08] <shadeslayer> it works only in Kubuntu :P
[17:08] <hyperair> bull. i read it on liferea
[17:08] <hyperair> ;-)
[17:08] <shadeslayer> http://apachelog.wordpress.com/2010/09/28/an-inconvenient-truth/
[17:08] <shadeslayer> :D
[17:09] <shadeslayer> but i seriously had super secret link to that post :P
[17:43] <jcastro> skaet, when you ping people for the TechnicalOverview can you remind them that linking to upstream project webpages and changelogs is very useful!
[17:43] <jcastro> I just went in there and linked a bunch up
[17:44] <jcastro> It's an opportunity for us to get attention to whatever upstream project we're talking about
[17:45] <skaet> jcastro,  cool.
[17:46] <skaet> jcastro,   sounds like a good idea.   Thanks for adding the links, and I'll add the reminder to the process checklist.
[18:31] <james_w> jibel: hi, are you able to help debug the policykit/software-center bug you reported?
[18:31] <james_w> unfortunately I have forgotten what I wanted to know next from someone that could see it
[18:33] <jibel> james_w, of course, let me have dinner and deal with the kids and I can help in approximately 1 hour
[18:34] <james_w> jibel: great, tomorrow if fine by me if it is your evening
[18:36] <jibel> james_w, okay.
[18:44] <SpamapS> apw: bump.. WI tracker looks a bit broken
[18:49] <apw> SpamapS, hrm, how so
[18:49] <SpamapS> apw: http://people.canonical.com/~platform/workitems/maverick/canonical-server-ubuntu-10.10.html
[18:50] <apw> hrm, i wonder how i managed that
[18:50] <apw> thanks for the heads up
[18:52] <SpamapS> apw: I see the 'assignee' added to info, but never used.
[18:52] <SpamapS> maybe you forgot a commit?
[18:53] <apw> SpamapS, it gets used elsewhere, but that shouldn't matter as its a []
[18:54] <SpamapS> Maybe something does a foreach on that hash
[18:54] <apw> SpamapS, no, think i see it, a miss merge
[18:54] <apw> just regen it here to confirm
[18:54] <SpamapS> actually the DB might be borked
[18:55] <apw> now that isn't meant to happen, its meant to protect that
[18:55] <SpamapS> or not.. hrm
[18:55] <apw> i think its the reporting thats bust
[18:56] <SpamapS> yeah
[18:56] <SpamapS> I had a cached local svg that confused me. ;)
[18:56] <apw> ok i've pushed what i hope is the fix, but will have to wait till it re-gens to be sure
[18:57] <SpamapS> I'm regenning locally now
[18:57] <apw> SpamapS, cool ... let me know if it looks ok to you
[18:58] <SpamapS> so far no, it looks very broken still
[18:58] <apw> SpamapS, the error is gone yes ?
[18:58] <SpamapS> ./burndown-chart -d ../maverick.db -t canonical-server -m ubuntu-10.10
[18:58] <SpamapS> produces a flat chart
[19:00] <apw> SpamapS, looks ok here to me
[19:00] <apw> did you update ?
[19:00] <SpamapS> apw: yeah I did a bzr pull
[19:01] <apw> SpamapS, what version do you have
[19:01] <SpamapS> 231
[19:01] <apw> hrm
[19:01] <SpamapS> and the latest maverick.db
[19:02] <SpamapS> damnit
[19:02] <apw> ?
[19:02] <SpamapS> the bash completion on sqlite3 is *useless*
[19:02]  * apw regets the DB to check
[19:02] <apw> its still LARGE
[19:03] <SpamapS> apw: we're looking at it over here, btw. ;)
[19:03] <SpamapS> err
[19:03] <SpamapS> ttx: ^^ we're looking at it over here
[19:03] <SpamapS> sorry My brain is a little off right now.. :-P
[19:03] <apw> if my internet connection was faster i'd have tested it by now
[19:05] <apw> SpamapS, its possible the DB is sick then
[19:05] <apw> not sure how that would be affected though
[19:05] <SpamapS> it doesn't look sick.. hmm
[19:06] <apw> i used an older DB i have here and get a sensible shaped output
[19:06] <apw> trying yesterdays now to get a control
[19:07] <apw> (by which i mean wiating for it to download
[19:08] <apw> SpamapS, looks ok on yesterdays DB
[19:08] <apw> SpamapS, could you confirm same for you?
[19:11]  * apw pokes SpamapS 
[19:12] <SpamapS> apw: in a meeting now.. but I'm downloading yesterday's db
[19:12] <apw> SpamapS, i am at a loss to understand how yesterday can be broken
[19:13] <apw> pitti, you about ?
[19:19] <apw> SpamapS, if you find that db is ok ... then i suspect we'll want that copied over the current.  things ought to sort self out from there ... do you have acess to ~platform ?
[19:20] <SpamapS> ok, so definitely the current .db is broken somehow
[19:20] <SpamapS> no I've never logged into the box
[19:20] <apw> it is beyond me to understand how anything other than todays data could be wrong, and it should get cleaned up by a respin
[19:20] <apw> we'll see if that occurs i guess at the end of this run, but is suspect not
[19:21] <SpamapS> I'm wondering if maybe the schema is munged
[19:22] <apw> SpamapS, that would be even more unexpected
[19:22] <SpamapS> no, schema is the same
[19:23] <apw> it appears to run around the :05 mark, but i don't see a run at 19 yes
[19:23] <apw> yet
[19:25]  * apw runs the collector here to confirm its now ok
[19:47] <apw> SpamapS, ok i took the broken DB from today, and ran the collector against it, and it seems to have sorted out that server report again
[19:47] <apw> so i presume when the collector runs again it will clean up the db and fix the reports
[19:47] <SpamapS> apw: interesting!
[19:47] <SpamapS> apw: I'll keep an eye on it. You're definitely off the hook for your commits though. ;) thanks for taking a look.
[19:48] <SpamapS> apw: its possible somethign on lillypilly was changed that broke the collector too.. lets hope not though
[19:48] <apw> SpamapS, the only possibility that makes any sense is the breakage made 'today' empty and that broke the reports, but till we hit the collector cron again its hard to kwno if its ok now
[19:49] <SpamapS> apw: it broke all of them.. I ran alpha-3 and it was flat
[19:49] <SpamapS> probably a null somewhere confusing things
[19:49] <apw> SpamapS, whats your line from that one
[19:50] <SpamapS> ./burndown-chart -t canonical-server -m maverick-alpha-3 -o bork.svg
[19:50] <SpamapS> -d maverick.db
[19:50] <SpamapS> I should say
[19:50] <apw> on my ./collect'ed update on the current borked one, i get a reasonable graph on that one too
[19:53] <apw> SpamapS, i think we are good, but i wish i knew when the thing is mean to run
[19:59] <pitti> hey apw
[19:59] <SpamapS> I wonder if there's something wrong on lillypilly.. the collector just ran 1 hour ago.. and the graphs have been regenerated, and are still borked
[20:00] <SpamapS> pitti: something's wonk with maverick.db
[20:01] <pitti> SpamapS: oh, what's wrong?
[20:03] <apw> SpamapS, i am not sure they did run actually
[20:04] <apw> pitti, the run time is nearly two hours ago and wondering what happened to the 19:00 run
[20:04] <apw> pitti, from my testing the fix i pushed should fix up the db
[20:04] <pitti> it should start in 1 min
[20:04] <apw> pitti, is there a logfile when it does i can watch ?
[20:05] <pitti> no log; stderr gets sent to work-items-tracker-hackers@lists.launchpad.net, though
[20:05] <pitti> running now
[20:06] <pitti> we also have daily backups, in case we need to restore
[20:06]  * SpamapS is confused by timezones I guess
[20:06] <SpamapS> it runs in +0100 ?
[20:06] <apw> pitti, cool ... i think it should recover .... i copied the db here and ran collect and it seemed to sort out the db
[20:06] <pitti> 05 */2
[20:07] <apw> pitti, oh its bi-hourly how is it?  thats my confusion
[20:07] <pitti> it used to run every hour, but since the per-user charts it regularly overran
[20:07] <pitti> so I bumped it to bi-hourly
[20:07] <apw> now it makes sense
[20:10] <apw> pitti, any idea how long it normally runs for on average these days ?
[20:12] <pitti> apw: not really, I haven't looked since SpamapS's "don't process past milestones" change
[20:12] <pitti> since most milestones are in the past now, it ought to be pretty quick
[20:13] <SpamapS> pitti: the collect step just takes a few minutes, right?
[20:13] <pitti> maybe 15
[20:13] <lifeless> hi
[20:13] <lifeless> I would love to know what API calls you spend lots of time on / call a lot
[20:14] <pitti> lifeless: urlopen() :)
[20:14] <lifeless> hah
[20:14] <SpamapS> lifeless: you're like a junkie who needs his fix ;)
[20:14] <pitti> there is no blueprint API
[20:14] <pitti> SpamapS: don't stop him! don't stop him!
[20:14] <lifeless> pitti: oh yeah, blocked on security in the model.
[20:14] <lifeless> pitti: so, you're screen scraping ?
[20:14] <SpamapS> pitti: wild horses couldn't keep him away!
[20:14] <pitti> lifeless: we do use launchpadlib for WIs as bugs, but screenscraping for blueprints
[20:15] <lifeless> pitti: We've been adding batching into some LP pages, I hope that didn't impact you.
[20:15] <lifeless> SpamapS: Nick Kershaw +1
[20:15] <pitti> lifeless: I think the lists have always been batched
[20:15] <pitti> lifeless: it copes by calling with &batch=200 (or so)
[20:15] <lifeless> pitti: some weren't. e.g. ubuntu/+assigments
[20:16] <SpamapS> pitti: https://lists.launchpad.net/work-items-tracker-hackers/ is empty.. is archiving turned off?
[20:16] <pitti> lifeless: we are just parsing ubuntu/$release/+specs
[20:17] <pitti> SpamapS: I didn't know there was an archive
[20:17] <pitti> I don't see how to turn it on
[20:17] <lifeless> there's always an archive.
[20:17] <lifeless> its populated a little slowly and lazily.
[20:18] <jibel> james_w, ping
[20:18] <james_w> hi
[20:19] <SpamapS> pitti: I don't recall getting a message .. so maybe it hasn't received any yet?
[20:19] <pitti> I didn't get any from the list either
[20:20] <jibel> james_w, what do you want me to debug/test with the policykit/s-c bug ?
[20:20] <SpamapS> pitti: I suppose that means its working and not spitting out errors. :)
[20:23] <pitti> SpamapS: I just sent a test mail to the lst
[20:24] <pitti> SpamapS: I just got it back, did you?
[20:25] <lifeless> pitti: a small request
[20:25] <lifeless> pitti: could you change the work item stuff to not claim to be noreply@launchpad.net ?
[20:25] <pitti> I could actually set it to the ML now, I suppose
[20:26] <lifeless> Two angles: firstly, approximately noone in the lp dev group knows about it :P, and secondly its horrible to get mail that you cannot contact the sender.
[20:26] <pitti> lifeless: done
[20:27] <lifeless> thanks!
[20:56] <james_w> jibel: sorry, the phone rang
[20:57] <jibel> james_w, np
[20:59] <james_w> jibel: I'm just grepping my logs to find the last time I looked at this, so that I can find the commands to run
[21:00] <apw> SpamapS, that looks a lot better to me  ... think we are good
[21:04] <james_w> jibel: so, I have a patch which may fix it, but it was last built in karmic, I'm just going to update it
[21:05] <jibel> james_w, attach the patch to the report when it's ready. I'll give it a try.
[21:34] <james_w> jibel: I just uploaded a patched package to https://edge.launchpad.net/~james-w/+archive/polkit/+packages
[21:35] <james_w> jibel: if you could test that it would be great. After installing it you need to kill polkit-gnome-authentication-agent-1
[21:35] <james_w> jibel: if you can still reproduce then killing polkit-gnome-authentication-agent-1 again, and stracing it would be valuable
[21:35] <james_w> jibel: in order to strace it properly you will temporarily make strace setuid
[21:53] <SpamapS> apw: agreed.. :)
[21:55] <jibel> james_w, there's no version for maverick, the version to test is policykit-1 - 0.96-2ubuntu1 for lucid  ?
[21:56] <james_w> jibel: oh, uploaded to the wrong distroseries
[21:56] <james_w> jibel: yes, that's the version
[22:58] <highvoltage> is it just me, or should the "i386" architecture as we call it in Ubuntu actually be called "i686" these days?
[23:00] <azeem> where "these days" == "since warty" or so
[23:00] <highvoltage> heh :)
[23:07] <cjwatson> highvoltage: the architecture name is an identifier assumed constant all over the place, and excruciatingly painful to change
[23:08] <cjwatson> there are so many other useful things that could be done with the effort involved in a rename
[23:08] <cjwatson> so, let's not
[23:08] <elmo> (see also 'amd64')
[23:09] <lifeless> 'emt64'
[23:09] <lifeless> :P
[23:09] <cjwatson> it's EM64T actually
[23:10] <cjwatson> ("Extended Memory 64 Technology".  Catchy Intel names 'r' us)
[23:11] <elmo> they don't have enough  money for a very big marketing dept is the problem
[23:11] <lifeless> cjwatson: hah, woops.
[23:15] <Keybuk> err
[23:15] <Keybuk> I'm pretty sure Intel dropped EM64t
[23:15] <Keybuk> and now just call it Intel 64
[23:15] <cjwatson> renamed to ia-32e, renamed to intel 64
[23:15] <cjwatson> oh, ia-32e was before em64t according to wp
[23:16] <cjwatson> though their cpu reference manual still says ia-32e
[23:16] <azeem> ia32 2.0
[23:16] <Keybuk> ia33
[23:17] <cjwatson> (in places; it describes the architecture as a whole as Intel 64, but for instance there's "IA-32e paging"
[23:17] <cjwatson> )
[23:17] <Keybuk> heh, different parts written by different engineers at different times
[23:17] <Keybuk> some parts could have been written by people who hadn't been told about the change of name
[23:18] <Keybuk> I mean, it's not like companies haven't changed platform names when the CEO has dicked around with the slides 10 minutes before going on stage for his Keynote
[23:30]  * ogra_cmpc wonders what will happen if he pins udev at 0.125 and upgrades
[23:31] <ogra_cmpc> s/upgrades/cross grades from lenny to ubuntu/