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