[00:25] <dhillon-v10> hi everyone, I need some help with launchpad
[00:27] <Ampelbein> dhillon-v10: just ask, maybe someone knows the answer.
[00:31] <dhillon-v10>  Ampelbein: alright I want to test some features in a laubchpad team (that I will create) so can I delete it if 'i don't need it
[00:31] <hyperair> join #launchpad and poke them about it
[00:31] <Ampelbein> dhillon-v10: use staging.launchpad.net for such tests, it's a testing environment that gets reset every night.
[00:32] <Ampelbein> dhillon-v10: it doesn't send mails though so if you need that tested, do what hyperair says ;-)
[00:32] <dhillon-v10> thanks guys
[00:32] <Ampelbein> dhillon-v10: as far as i know, teams can only be deleted by asking a question on launchpad answers.
[00:33] <dhillon-v10> Ampelbein: I am going to create a team of my own.. :)
[01:37] <slangasek> StevenK: well currently gir-repository references the NBS libclutter-gtk-0.8, so it would be nice if /something/ were done here. :)
[01:38] <StevenK> slangasek: Argh, it does?
[01:38] <StevenK> slangasek: I'm about to upload casper since I suck, there's time for a UNR respin?
[01:38] <slangasek> http://people.canonical.com/~ubuntu-archive/NBS/libclutter-gtk-0.8-dev
[01:38] <slangasek> yes, there's time for a UNR respin
[01:39] <StevenK> Yeah, the clutter-gtk NBS list was making me cry, so I closed it before I reached for something sharp
[01:44] <StevenK> slangasek: The casper change is marking a working script as +x so UNR actually has the installer as a favourite.
[01:56] <Ampelbein> hi there... I'm trying to get diagnostics built on karmic but get a FTBFS pointing to a "invalid conversion from 'int (*)(const void*, const void*)' to 'int (*)(const dirent**, const dirent**)'" (http://paste.ubuntu.com/251684/) The strange thing is: ace have not had code changes for some time and I can't really figure out why this suddenly fails. It did not fail about 3 weeks ago... could this be related to glibc -> eglibc transition?
[01:56] <Ampelbein> full buildlog if anyone is interested: http://launchpadlibrarian.net/30197352/buildlog_ubuntu-karmic-i386.diagnostics_0.2.7-2ubuntu1_FAILEDTOBUILD.txt.gz
[02:04] <Ampelbein> ojwb: i digged some more into this, in the specified file ( /usr/include/ace/OS_NS_dirent.h) there is http://paste.ubuntu.com/251687/ . So it seems to check at buildtime how to call those functions.
[02:04] <Ampelbein> (i'm not a programmer, so forgive me if i make wrong assumptions)
[02:06] <ojwb> ah, it is wrapping scandir() (for portability I assume)
[02:09] <ojwb> it may be a change in g++
[02:10] <ojwb> something that was only a warning being an error now
[02:11] <Ampelbein> it doesn't show in the old buildlog (http://launchpadlibrarian.net/29636028/buildlog_ubuntu-karmic-i386.diagnostics_0.2.7-2_FAILEDTOBUILD.txt.gz) which failed because of wrong symbols file
[02:12] <Ampelbein> could it be that ace simply needs a rebuilt to perhaps pick up a change in behavior? i'll try this.
[02:13] <ojwb> well, warnings aren't turned on
[02:13] <ojwb> it's worth trying a rebuild for ace I'd say
[02:15] <Ampelbein> ojwb: thank you very much for your help.
[02:23] <jtimberman> hello, is there a document on how to patch a debian/rules file in a package for karmic?
[02:27] <Ampelbein> jtimberman: what do you want to do exactly? are you looking for the packaging guide?
[02:27] <Ampelbein> !packaging
[02:28] <jtimberman> Ampelbein: I think I found it, Preparing patches section of: https://wiki.ubuntu.com/MOTU/Contributing
[02:29] <StevenK> slangasek: It turns out the UNR daily hasn't built yet, I'll just wait for it
[02:30] <slangasek> StevenK: good thing you've said that, otherwise I might've disabled the cronjobs before then :)
[02:36] <jtimberman> and now there's a patch for the runit package, applicable to   Bug #406621
[02:58] <StevenK> Argh, and the UNR livefs breaks thanks to nvidia-common
[03:01] <StevenK> slangasek: &
[03:01] <StevenK> Er
[03:02] <StevenK> slangasek: ^ ; all livefses that pull in nvidia will fail, -185 is in source NEW, and nvidia-common wants it
[03:27] <superm1> hi tkamppeter_
[03:38] <Ushaib> Hi. Gedit is crashing everytime I'm opening a specific 800kb text file. There is no error message, it just closes immediately. How do I proceed if I want to alert the developers about this issue? What information should I gather, etc.
[03:38] <Ushaib> err, just read the topic and the link to ubuntu-bugs. Sorry.
[04:14] <Dyno> How do you sign packages? When I try to sign with my gpg, I keep getting "secret key not available
[04:16] <ojwb> debsign <.changes files>
[05:05] <StevenK> slangasek: The -180 -> -185 rename for nvidia looks gratatious to me, but I'm not sure how you want you to go in terms of cleaning up the mess
[05:16] <YokoZar> hmm apparently build-essential isn't an implied package build dep ;)
[05:16] <ScottK> slangasek: I have a proposed upload for konq-plugins that fixes a problem with file overwrites among packages within that source package.
[05:49] <dholbach> good morning
[05:54] <slangasek> StevenK: it's not a rename, the 180 package is still present?
[05:54] <slangasek> ScottK: which -proposed?
[05:55] <slangasek> oh, it is a rename; blah
[06:01] <StevenK> slangasek: We can scorched earth nvidia-common back to -180?
[06:02] <ScottK> slangasek: Proposed for karmic (not uploaded due to freeze, but I'd like to go ahead)
[06:02] <slangasek> StevenK: I don't see that this is warranted (although packages that Replace: themselves are a bit odd)
[06:02] <slangasek> ScottK: ah - go ahead, please
[06:04] <ScottK> OK.  It'll be up in a moment.  Once again less foo.changes saves me from a typo in the changelog.
[06:05] <slangasek> StevenK: hmm, I guess if I were to accept this -185 package, it would be just to get the milestone rolling, ignoring various packaging bugs; so yeah, let's revert -common
[06:06] <slangasek> StevenK: will you take care of this?  Otherwise, I'll get it when I'm back from the store
[06:11] <StevenK> slangasek: I'll start it now
[06:11] <ScottK> slangasek: qt4-x11 built on armel ....
[06:12] <emma> Hey I just wanted to tell you all that there is a meteor shower tonightin North America. If you are interested.
[06:12] <ScottK> mcasadevall: ^^^^
[06:12] <emma> It should be best around 2- 3 am local time no matter where you live.
[06:12] <ScottK> Cloudy here unfortunately.
[06:12] <mcasadevall> ScottK, yup, I'm aware
[06:12] <mcasadevall> ScottK, take a look at the build queue now
[06:13] <mcasadevall> def. an improvement, and once KDE builds, compiz can be built and make ubuntu-desktop installable on ARM
[06:13] <emma> KDE with compiz?
[06:13] <emma> I thought KDE had its own windows compositor
[06:13] <hyperair> kwin4?
[06:15] <ScottK> emma: It does, but compiz has a compiz-kde for people that just have to have compiz.
[06:15] <ScottK> mcasadevall: Congratulations.
[06:15] <ScottK> hyperair: Yes.  Kwin.
[06:15] <emma> compiz would be pretty neat on kde.
[06:15] <hyperair> compiz is neat. period
[06:16] <emma> ScottK: im concerned about gnome-shell. It will be gnome 3 and it throws out (1) compiz, (2) gnome pannel, and (3) python.
[06:16] <hyperair> it throws out python?
[06:16] <emma> ScottK: it's hard to believe that ubuntu would even want to use gnome-shell. So maybe Ubuntu will switch to KDE as default?
[06:16] <hyperair> i know it tosses 1 and 2, but 3 i've never heard of
[06:16] <emma> hyperair: yes it's written in javascript!
[06:16] <hyperair> ...what.
[06:16] <mcasadevall> ScottK, thanks infinity; the issue was the buildds were using lenny as the base OS from when they were first installed in DC.
[06:16] <mcasadevall> ScottK, reinstalling them to jaunty magically fixed things
[06:16] <mcasadevall> (I don't want to know why)
[06:16] <ScottK> mcasadevall: Lovely.  Glad it's resolved.
[06:17] <hyperair> emma: where did you get that from?
[06:17] <mcasadevall> ScottK, powerpc should also be (semi)fixed
[06:17] <emma> hyperair: their website.
[06:17] <ScottK> mcasadevall: Yes.  It's building fine.
[06:17] <hyperair> you sure you didn't catch on a bad april fools joke?
[06:17] <ScottK> emma: No idea about Gnome 3 myself.
[06:17] <emma> hyperair: no it's certainly true, gnome-shell is written in javascript.
[06:18] <hyperair> maybe gnome-shell, but definitely not the rest of gnome 3
[06:18] <emma> I believe the grandidea behind the whole thing is that it's an interface that will work nice on mobile apps. But in my opinion the interface makes no sense on the desktop. So many menus just to do simple tasks!
[06:18] <hyperair> i haven't taken a good look at gnome-shell's source code yet
[06:18] <hyperair> i dunno, i can live with gnome do and compiz
[06:19] <emma> How can they just throw out compiz! Compiz is one of the main things that draws people to linux. It's what people think of when they think of Ubuntu!
[06:19] <hyperair> er no, you're exaggerating
[06:20] <emma> Im talking about new people who get excited to try it out.
[06:20] <hyperair> compiz isn't everything, but it sure as hell is something which has features i can't live without
[06:20] <emma> They see that cube, they get excited, they want to know what that is, it's linux, so they get Ubuntu.
[06:20] <hyperair> i know many new ubuntu converts who aren't excited by compiz
[06:20] <hyperair> it's not so much of the cube, it's more of the virtual desktop
[06:20] <hyperair> aka workspaces
[06:20] <emma> Yeah
[06:21] <hyperair> all window managers have them
[06:37] <StevenK> slangasek: nvidia-common uploaded.
[06:44] <slangasek> StevenK: cheesr
[06:48] <StevenK> slangasek: So maybe we reject -185, and get Alberto to update -180 after Alpha 4. I'm not really fussed, but it does seem fairly gratuitous
[06:48] <slangasek> StevenK: I agree
[06:56] <dholbach> looking at http://people.canonical.com/~dholbach/sponsoring/ we should really make it the Ubuntu Sponsoring Week
[07:04] <nellery> that sounds like a good idea
[07:23] <tkamppeter> superm1, hi
[07:31] <ttx> slangasek: did you get my message about bug 385475 being fixed and needing to be dropped for alpha4 release notes known issues ?
[09:04] <didrocks> slangasek: no transition needed from what I saw gir-repository is still intended to be "temporary"
[09:05] <didrocks> slangasek: but well, it's a long "temporary" time, apparently :)
[09:05] <sarts_> what's 'gir'
[09:07] <directhex> my supybot on oftc!
[09:07] <dholbach> sarts_: I guess 'r' and 't' are pretty close together on didrocks' keyboard :)
[09:07] <didrocks> hey dholbach :)
[09:07] <dholbach> heya didrocks
[09:07] <dholbach> how's life in France?
[09:08] <didrocks> no, gir-repository is a collection of gobject-introspection :)
[09:08] <ogra> these french guys, tsk .... get better keyboards !
[09:08] <didrocks> dholbach: great. I'm in the Alpes, near my parents on holidays :)
[09:08] <ogra> ;)
[09:08] <dholbach> ah nice
[09:08] <didrocks> ogra: azerty keyboard for the win \o/
[09:08] <ogra> haha
[09:08] <sarts_> hehe
[09:08] <sarts_> didrocks: I doubt it
[09:08] <directhex> any time you need alt-gr to be useful, your layout sucks
[09:09] <didrocks> directhex: that's unfortunately correct :/
[09:10] <directhex> of course it is! /me knows all ;)
[09:10] <sarts_> directhex: is there any layout that does not require the use of Alt-Gr while still supporting the € sign?
[09:11] <Ng> sarts_: anything with a compose key \o/
[09:12] <directhex> sarts_, obviously € sucks!
[09:13]  * dholbach reminds everybody of http://people.ubuntu.com/~dholbach/sponsoring/ :-)
[09:14] <sarts_> currently, $ and £ suck more ;-)
[09:18] <slangasek> ttx: I guess that means you didn't see my request that you update the wiki page? :)
[09:18] <slangasek> didrocks: right, long enough that we have to deal with it for a release cycle :/
[09:20] <slangasek> asac: so, switching from bluez-gnome to gnome-bluetooth costs is half a MB on the CDs... does it bring half a MB of functionality?
[09:22] <ttx> slangasek: no :) could you resend the url ?
[09:22] <slangasek> ttx: https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview
[09:23] <ogra> meh, amrel+imx51 doesnt build its livefs
[09:23] <ttx> slangasek: ok, will do
[09:24] <slangasek> ttx: thanks!
[09:28] <didrocks> slangasek: the issue is that netbook-launcher and libclutk-0.2-0 depends on libclutter-gtk-0.10-0. If they still needs only 0.8, we can add an epoch to the source package, rebuild it to 0.8, and create clutter-gtk-0.10-0 source package in universe. Does this sound right?
[09:28] <directhex> slangasek, if you want to ubuntu1 mono, i can get you 200k. i'm still trying to convince meebey to do it, but i don't see it happening in a4 timeline
[09:29] <slangasek> directhex: I think we'll have to find the space elsewhere for alpha-4 (langpacks); I'm just poking at what looks like new bloat as it appears
[09:30] <slangasek> didrocks: that doesn't make any sense at all to me - why would we not be trying to get rid of the 0.8 stuff entirely?
[09:31] <directhex> slangasek, well if you become desperate, you know where to find me
[09:31] <didrocks> slangasek: it was to avoid having to MIR gir-repository and all depends (only 0.10 depends on it IIRC, have to check this)
[09:31] <seb128> slangasek, gnome-bluetooth is official part of GNOME now and maintained, will get frequent tarballs, new features, etc
[09:32] <slangasek> seb128: but why is it 5x the size of bluez-gnome?  It certainly doesn't look more functional to me
[09:33] <seb128> slangasek, 5x?
[09:33] <slangasek> seb128: will gvfsd-backends be switching to obexd-client, btw, now that bluetooth-gnome depends on it?
[09:33] <seb128> slangasek, I expect so
[09:34] <slangasek> seb128: yes; gnome-bluetooth+libgnome-bluetooth7+modemmanager+obexd-client = 680K, vs. 161K for bluez-gnome (ok, 4x, not 5x)
[09:35] <seb128> slangasek, to be fair in that you should not count modemmanager and obexd
[09:35] <seb128> since bluez-gnome also has a obex server and doesn't cover what modemmanager do
[09:35] <slangasek> if obex-data-server wasn't still on the CDs too, I wouldn't count obexd-client; but ok, that's still 3x. :)
[09:35] <seb128> but yeah there is some sort of overlap now until we do proper cleaning
[09:47] <StevenK> slangasek: I just did a build of UNR, I didn't step on your toes?
[09:47] <slangasek> StevenK: ah, well, we'll get another build soon then
[09:47] <slangasek> no big deal
[09:48]  * StevenK nods
[09:56] <directhex> according to my figures, f-spot/tomboy plus deps have shrunk by about 5 meg this cycle
[09:57] <dholbach> who would like to give a packaging training session at 12:00 UTC tomorrow? (nothing huge, 15-20 minutes of content + some time for questions is fine)
[10:05] <dholbach> james_w and I just had the idea to run a "on-call review" session instead of a "strict packaging training" session - who would like to participate as a reviewer?
[10:05] <dholbach> hey mok0
[10:06] <seb128> dholbach, "on-call"?
[10:06] <mok0> heya dholbach
[10:08] <dholbach> seb128: instead of a packaging training session, we wanted to be in #ubuntu-classroom and review stuff of people who show up there and explain problems, etc.
[10:08] <dholbach> like an online review
[10:08] <seb128> ah ok, I can be around I guess ;-)
[10:12]  * ogra is desparate 
[10:12] <ogra> seems my armel livefses dont build because gconf2 cant be found
[10:12] <ogra> but gconf surely built
[10:13] <cjwatson> dholbach: I can do that
[10:14] <ogra> http://paste.ubuntu.com/251824/ is what i get trying a manual livefs.sh run on armel+imx51
[10:14] <cjwatson> sometimes apt reports that package X is not installable when actually the problem is in one of X's dependencies
[10:15] <cjwatson> I usually use chdist to investigate
[10:15] <ogra> well, libgconf2-dev or gconf2-common replace gconf2
[10:16] <ogra> and apt-get install gconf2-common is no prob at all in the chroot
[10:16] <sebner> dholbach: aloha! Sry for the g-d-s sync. I accidently subscriped the archive admins too and the just know mono stuff is _not_ b0rken so they synced without leaving a note :)
[10:16] <cjwatson> you need to test installing them all at once, not just one at a time
[10:17] <cjwatson> the signs point to some kind of conflict
[10:17] <cjwatson> and BTW that message totally does not say that gconf2 can't be found
[10:17] <cjwatson> it says it's not installable, that's different
[10:18] <cjwatson> ogra: which flavour is this?
[10:18] <ogra> armel+imx51
[10:18] <dholbach> seb128, cjwatson: that'd be sweet - you guys are rockstars!
[10:18] <dholbach> I'll send out an announcement later today
[10:18] <cjwatson> that's not a flavour, that's a subarchitecture
[10:18] <cjwatson> kubuntu is a flavour, for example
[10:18] <ogra> ubuntu-desktop, sorry
[10:19] <cjwatson> ok, I get a different error when testing with chdist
[10:19] <cjwatson>   evolution: Depends: evolution-common (= 2.27.5-0ubuntu1) but it is not going to be installed
[10:19] <ogra> i'm just running livefs.sh -simx51 here
[10:19] <cjwatson>              Recommends: evolution-documentation (= 2.27.5-0ubuntu1) or
[10:19] <cjwatson>                          evolution-documentation-en (= 2.27.5-0ubuntu1) but it is not going to be installed
[10:19] <ogra> ugh, i missed the equal sign
[10:19] <ogra> sorry for the noise
[10:19] <cjwatson> (though I don't have universe enabled)
[10:19] <ogra> i do, but evo ftbfs
[10:20] <cjwatson> that'll need to be fixed then ...
[10:20] <ogra> yes, retrying it now
[10:21] <cjwatson> what good will retrying it do?
[10:22] <seb128> how did the build break?
[10:22] <cjwatson> the problem is that gtkhtml3.14 failed to build
[10:22] <ogra> it should fix it, normally the deps are delayed because openjdk or something builds
[10:22] <cjwatson> ogra: gah. no. stop. think.
[10:22] <cjwatson> gtkhtml3.14 failed to build because:;
[10:22] <cjwatson>   gnome-icon-theme: Depends: libgtk2.0-bin but it is not going to be installed
[10:22] <seb128> arch all any mismatch in gtk I guess
[10:22] <cjwatson> so let's check http://people.canonical.com/~ubuntu-archive/testing-ports/karmic_probs.html
[10:23] <seb128> ie the new version didn't build on the arch
[10:23] <cjwatson> so that's no longer showing any problems in that area
[10:23] <seb128> so retry gtkhtml?
[10:23] <cjwatson> which indicates that it's probably safe to retry gtkhtml3.14
[10:23] <cjwatson> wait for gtkhtml3.14 binaries to publish, *then* retry evolution
[10:24] <ogra> ok, i just wasted buildd time then, i was to fast
[10:24] <cjwatson> if people give-back without thinking then we may have to withdraw the ability for developers to retry builds
[10:24] <cjwatson> especially on slow architectures
[10:32] <seb128> slangasek, when would be a good time to upload a new gtk version?
[10:46] <asac> slangasek: there is room for improvement how gnome-bluetooth is linked (e.g. he links libcommon.a in binaries and lib)
[10:46] <asac> slangasek: modemmanager has nothing to do with the bluetooth thing. its factored out of NM rather
[11:02] <Riddell> evand1: timezone page in ubiquity-frontend-kde broken, anything that's changed there recently? http://paste.ubuntu.com/251852/
[11:07] <evand1> Riddell: yeah, mterry made changes to ubiquity to support translated timezones, and it looks like the kde timezone class hasn't been updated for those changes.  shtylman, can you take a look at this?
[11:20]  * Keybuk fails to understand why he shouldn't push with uncommitted changes
[11:23]  * ogra sighs about slowness of mirroring binaries to ports.u.c
[12:01] <shtylman> evand1: will do
[12:01] <evand1> shtylman: thanks, I appreciate it
[12:01] <shtylman> no prob
[12:07] <geser> soren: thanks for the new gnupg2 version, I can now play with my new shiny OpenPGP 2.0 card :)
[12:08] <soren> geser: No problem. That was my goal, too, as I'm sure you've gathered by now :)
[12:09] <cjwatson> Keybuk: '(echo "[ALIASES]"; echo "push = push --no-strict") >> ~/.bazaar/bazaar.conf' ? :-)
[12:10] <chrisccoulson> directhex - do you know if libipoddevice is still maintained anywhere, or used (or going to be used) by anything?
[12:10] <chrisccoulson> https://edge.launchpad.net/ubuntu/+source/libipoddevice
[12:10] <cjwatson> err, or for that matter 'bzr alias push="push --no-strict"'
[12:11] <ogra> The following packages have unmet dependencies:
[12:11] <ogra>   usb-creator-common: Depends: syslinux but it is not installable
[12:11] <ogra> mumble
[12:11] <directhex> chrisccoulson, i don't know!
[12:12] <chrisccoulson> the only reason i asked you is because the ~mono team is subscribed to the package ;)
[12:12] <chrisccoulson> that's ok if you don't know though
[12:12]  * YokoZar closed 10 ia32-libs bugs today
[12:12] <YokoZar> Multiarch is still vaporware right?
[12:12] <cjwatson> it's gradually congealing
[12:13] <YokoZar> ia32-libs is a 500 meg source package now ;)
[12:13] <chrisccoulson> urgh
[12:13] <chrisccoulson> you have the bandwidth for that?
[12:14] <YokoZar> chrisccoulson: sort of, dput kept stalling with 1 k left because of Comcast being horrible, so I had to sftp it to a datacenter server and then dput it from there
[12:15] <chrisccoulson> yeah, i think my ISP would start throwing heavy objects at me if i was uploading things of that size frequently ;)
[12:18] <directhex> chrisccoulson, perhaps libipoddevice was once an rdep for banshee?
[12:19] <directhex> chrisccoulson, yep, in dapper
[12:19] <Keybuk> cjwatson: I did that
[12:19] <Keybuk> I just wondered why it was the default now
[12:19] <chrisccoulson> directhex - that's what i'm thinking. the code doesn't seem to be hosted anywhere, and it currently depends on gnome-volume-manger, which i'm looking to have removed
[12:19] <chrisccoulson> ah, ok. so libipoddevice is probably not worth keeping around now then?
[12:19] <directhex> chrisccoulson, i would support its removal. who's maintainer in debian?
[12:20] <cjwatson> Keybuk: yeah, I don't know, seems an odd decision to me
[12:20] <chrisccoulson> directhex - not sure who maintains it in debian. i'll check this afternoon
[12:20] <chrisccoulson> thanks :)
[12:26]  * ogra ties seb128 to his chair and moves the chair 2m away from the keyboard
[12:28] <seb128> ogra, what?
[12:28] <ogra> i'm trying to get a working liveimage on armel ... you are uploading stuff all the time
[12:28] <seb128> sorry I should be done now
[12:29] <seb128> the thing is that if we don't get those now it will delay by 2 weeks at least
[12:29] <seb128> I'm not there next week neither is pitti
[12:29] <ogra> yeah, its fine as long as gtk doesnt take significantly longer than evo
[12:29] <seb128> and I don't want to upload a gtk on friday before holidays
[12:29] <ogra> right, but i'm also under pressure to have images, why isnt the qeue locked ?
[12:30] <seb128> because we have soft freeze for alphas
[12:30] <ogra> meh
[12:30] <seb128> it's always like this
[12:30] <ogra> at least the day we actually roll the images it would make sense, so people can upload and we are not affected with the images
[12:31] <seb128> usually uploads don't break images
[12:31] <seb128> gtk is a limit case I admit
[12:31] <seb128> but as said it was now or in 3 weeks
[12:31] <seb128> and the new version fixes annoying client side bugs
[12:31] <ogra> yeah, should be fine i luckily retried evo right before you uploaded so it builds now
[12:46] <Aks> is any1 home ?
[13:13] <ogra> shriek !
[13:14] <ogra> asac, why did the buttons get flipped on the "thats embarrassing" page in FF ???
[13:14]  * ogra curses, just lost his whole session 
[13:18] <seb128> ogra, what embarrassing page?
[13:20] <hyperair> seb128: session recovery
[13:20] <sarts_> seb128: http://1.bp.blogspot.com/_XITx9cKVWJU/SmpOfCSwHTI/AAAAAAAAABE/J-vCCXz3F-k/s1600-h/firefox_crash.jpg
[13:20] <sarts_> (just googled for firefox embarrassing)
[13:20] <hyperair> huh why is restore on the left O_o
[13:20] <hyperair> wasn't it always on the right?
[13:22] <seb128> restore should be on the right to follow GNOME
[13:23] <ogra> seb128, but it was on the other side this morning ... i just clicked blindly
[13:23] <seb128> seems a bug
[13:24] <ogra> well, restore is on the right now
[13:24] <ogra> it *was* on the left until we got the official package
[13:25] <seb128> bug fixed then ;-)
[13:25] <ogra> pfft
[13:26]  * ogra steals seb128's session info to have at least *something* :P
[13:26] <seb128> I don't use sessions
[13:26] <ogra> you use tabs, dont you ?
[13:26] <asac> ogra: which page?
[13:26] <seb128> yes, I close tabs before closing firefox
[13:26] <ogra> asac, the crash/session recovery
[13:27] <seb128> but having crash recovering is useful
[13:27] <asac> ogra: might be that they tried to be more gnome compliant ;)
[13:27] <asac> the right one is the one people are expected to hit if they dont read
[13:27] <asac> afaik
[13:27] <ogra> asac, yes, they should add a <blink> around the button then :P
[13:27] <asac> ogra: i think its a one time learning effect for folks like you that rely on it ;)
[13:27] <seb128> yes, right is safe choice
[13:28] <asac> you will probably not do it again ;)
[13:28] <chrisccoulson> heh, i always keep tabs open between sessions. i only start closing them when FF is using about 800MB of RAM
[13:28] <seb128> ie restore session should be there
[13:28] <asac> yep
[13:28] <asac> ogra: is that the case?
[13:28] <ogra> i will *for sure* not do it again :P
[13:28] <ogra> asac, yes, its the right button now
[13:28] <ogra> used to be the left one until i upgraded today
[13:30] <ogra> it would have been a perfect note to add to the "firefox restart required" window
[13:30] <hile> ogra, I asked about this earlier, see preferences windows: to me all firefox internal buttons were in 'windows order', but print etc of course coming from gnome in 'correct' order
[13:30] <asac> ogra: restart required window is going away
[13:31] <ogra> meh, that would have been a good place to warn me
[13:31] <asac> you should get a "start" thing in firefox
[13:31] <asac> restart
[13:31] <ogra> hile, well, i like that the buttons are in proper order now, i just dont like that i lost my session info with about 70 open tabs
[13:32] <ogra> i kind of abuse FF tabs as todo list and keep stuff open until i cared for it
[13:32] <hile> yes but if this still affects the internal preferences windowows (could not check) there are other windows now in wrong order for gnome
[13:33] <hile> one of them was the dialog to choose if you want to open or save a download, cancel is rightmost button - but mybe this was fixed after I last saw a karmic machine
[13:34] <hile> but, need to catch a train ->
[13:45] <Laney> can someone reject haskell-edison-api from NEW please?
[13:48] <Laney> alternatively, can I upload the same version again?
[13:49] <james_w> yes, you can
[13:51] <Laney> good news
[14:50] <cjwatson> ogra: restore's been on the right for some time. If you haven't closed firefox again then your old session might still be around in your profile directory
[14:50] <cjwatson> ogra: though you're not the first, mdz had the same problem at the sprint; I happened to be sitting beside him and walked him through the recovery
[15:34] <evand> Updating my karmic desktop results in all windows include the panel disappearing immediately after I enter the keyring password.  So I just have the background and a cursor.  Curiously, alt tab works (even drawing the switcher window and window outlines) and I can enter text into windows, they just don't ever become visible.
[15:34] <evand> Anyone else experiencing this?
[15:34] <seb128> evand, xsplash bug
[15:34] <seb128> evand, you can stop xsplash if you want
[15:35] <seb128> evand, bratsche is on it I think
[15:35] <evand> seb128: Awesome!  You're a lifesaver.
[15:35] <evand> thanks
[15:36] <seb128> that's a sideeffect of using the default background image
[15:36] <seb128> it's not obvious the session is loaded with xsplash over it
[15:37] <seb128> which is what you want when xsplash go away ;-)
[15:37] <evand> heh
[15:39] <seb128> cjwatson, slangasek:: I think that's an alpha4 blocker
[15:39] <seb128> it happens to quite some people today
[15:39] <seb128> the xsplash thing just discussed
[15:43] <jdstrand> seb128: hi! so I hope to add an apparmor profile to evince this week (bug #382913). What is the best way to coordinate with you? just upload? debdiff in the bug? bzr branch?
[15:43] <slangasek> seb128: ack; is there a bug open?
[15:43] <seb128> jdstrand, feel free to upload if you don't need a review
[15:44] <seb128> slangasek, bug #412455
[15:44] <jdstrand> seb128: cool, thanks. it'll likely be Friday
[15:44] <davmor2> slangasek: I just got hit by the same thing on unr too
[15:44] <seb128> jdstrand, don't forget to push your changes to bzr though ;-)
[15:44] <jdstrand> seb128: ack
[15:45] <slangasek> seb128: new gtk version> tomorrow, I suppose
[15:46] <seb128> slangasek, too late
[15:46] <seb128> slangasek, it's in karmic for some hours now
[15:46] <seb128> slangasek, sorry but I just uploaded since I wanted that before my holidays and didn't want to upload on friday to run away
[15:46] <seb128> especially that pitti and mvo are not around either
[15:46] <seb128> nor is robert_ancell
[15:47] <seb128> ie that was now or after holidays
[15:47]  * slangasek sighs
[15:47] <mneptok> slangasek: too late for the pebbels to vote.
[15:48] <mneptok> *pebbles
[15:56] <seb128> slangasek, would now be a good time to upload a gdm fixing gdmsetup crashing on new configs?
[15:57] <seb128> only change is to gdmsetup and that's not a lib so it should not confuse any cd build
[15:58] <slangasek> seb128: it's not a good time, no; please wait until the milestone freeze is up
[15:58] <seb128> ok
[15:59] <seb128> slangasek, just curious but what sort of issue random app uploads can cause?
[16:01] <slangasek> seb128: it screws up being able to see when we're done rerolling for critical issues because the set of packages on the ISO is constantly out of date, and if any package happens to get bigger on rebuild (which can happen from incidental toolchain changes, etc), then it may push an image oversized to where we'll have to respin it a second time
[16:08] <seb128> slangasek, hum, ok
[16:11] <ogra> cjwatson, hmm, i must have skipped a few upgrades then, i totally rely on update-manager nowadays, if it pops up i upgrade
[16:11] <slangasek> cody-somerville: xubuntu ISOs are oversized for alpha-4; could you have a look at pruning?
[16:12]  * cody-somerville nods.
[16:14] <superm1> slangasek, 20090812.1, should those be what i should ask folks to test on mythbuntu, or is there any other planned re-rolls?
[16:14]  * ogra sighs, so evo finished building 1h ago on armel ... still no trace of the binary on ports
[16:17]  * ogra wishesfor a "sync now" button on ports so he can start building images
[16:32] <slangasek> tkamppeter: we're in a milestone freeze.
[16:36] <slangasek> superm1: currently I'm aware of no reason to need to reroll mythbuntu, yes; posting it to the tracker now
[16:36] <superm1> slangasek, ok thx
[16:46] <tkamppeter> slangasek: Sorry
[16:46] <tkamppeter> superm1: The bluez changes are accepted upstream now.
[16:47] <slangasek> tkamppeter: are you subscribed to ubuntu-devel-announce?  A mail is sent there when the freeze starts, and it's added to the channel topic here
[16:47] <superm1> tkamppeter, great thanks.
[16:48] <tkamppeter> superm1: So the patch can be dropped as soon as the upstream bluez version with the fix comes out.
[16:50] <tkamppeter> superm1: The change in the debian/bluetooth.conf must stay as we replace the upstream file completely with ours.
[16:50] <superm1> okay
[16:58] <Riddell> mterry: you'll be able to fix the kde ubiquity frontend soon?
[16:58] <mterry> Riddell, already in bzr
[16:59] <mterry> Riddell, sorry man.  I only tested in non-English languages
[16:59] <Riddell> gosh
[17:02] <Riddell> mterry: rocking, works
[17:02] <mterry> Riddell, sweet
[17:03] <Riddell> evand: shall I upload?
[17:03] <evand> Riddell: I'll sort it out.  I'm just fixing one more bug in the kde frontend
[17:03] <evand> thanks though
[17:04] <Riddell> great
[17:20] <kenvandine> slangasek, can we upload a fix for that xsplash timeout fallback bug to main?
[17:20] <slangasek> kenvandine: not clear what you're asking - are you asking whether it's ok to upload during the milestone freeze?
[17:21] <kenvandine> yes... fixes that bug you tagged
[17:21] <seb128> slangasek, he saks if it's ok to fix the alpha blocker fix now
[17:21] <slangasek> kenvandine: yes, that's why it's tagged so that we get it fixed before the alpha. :)
[17:21] <kenvandine> slangasek, figured.. .:)  just checking
[17:22] <seb128> slangasek, well just asking if now is not the middle of a armel build or something which that would screw
[17:23] <slangasek> seb128: when it's a milestone blocker, the sooner the better
[17:23] <seb128> slangasek, ok thanks
[17:23] <ogra> seb128, well, NCommander was clever and gave back a ton of KDE stuff, the armel buildds will be stuck for a while
[17:24] <ogra> so upload whenever you want, we're screwed anyway
[17:24] <ogra> (beyond that gtk will still take at least another 1.5h to show up on ports
[17:24] <ogra> )
[17:24] <ogra> the mirroring is very slow
[17:25] <slangasek> ogra: have you talked to IS about this?  There's no reason, in principle, that ports mirroring should be any slower
[17:25] <ogra> slangasek, no, will do so after A4
[17:25]  * ogra makes note on TODO
[17:26] <ogra> it usually takes 2h after the build finished until it shows up in the archive, whats the proposed time for non-ports ? 30min ?
[17:27] <slangasek> ogra: oh, there's currently a problem that the publisher is running long (mentioned on #ubuntu-release)
[17:28] <slangasek> so what's happening is that it takes an average of 2h after the build is done before the publisher finishes
[17:28] <ogra> ah, so its not ports specific then
[18:53] <chrisccoulson> slangasek - just looking at bug 412455
[18:54] <slangasek> chrisccoulson: hi
[18:54] <chrisccoulson> gnome-session already signals on the session bus when the session is running
[18:54] <chrisccoulson> or at least that is the intention already ;)
[18:54] <slangasek> oh?  then why have people been hitting the timeout?
[18:54] <chrisccoulson> is it because xsplash doesn't listen to it?
[18:55] <chrisccoulson> my understanding is it waits for nautilus and gnome-panel to signal that they're ready
[18:57] <slangasek> chrisccoulson: ah
[18:57] <slangasek> so perhaps this is still a xsplash bug
[18:57] <slangasek> kenvandine: ^^ opinions?
[18:58] <kenvandine> slangasek, need to talk to bratsche... i know they discussed that last week
[18:58] <kenvandine> there was a reason they went with panel and nautilus
[18:58] <chrisccoulson> slangasek - possibly. i don't know how much it changed over the last few days, but won't it fail if a user isn't using either gnome-panel or nautilus (or isn't using nautilus to draw the desktop)?
[18:58] <kenvandine> chrisccoulson, it will timeout after 10s then
[18:58] <kenvandine> at least for now
[18:59] <kenvandine> they are trying to work out a better way
[18:59] <chrisccoulson> kenvandine - i'm just about to send an idea to d-d-l which would handle this situation
[18:59] <chrisccoulson> seeing as everybody took the e-mail from bratsche quite far off-topic
[18:59] <kenvandine> chrisccoulson, with 0.4 anyway... it will go away after 10s, which is a hack
[18:59] <kenvandine> yeah
[18:59] <chrisccoulson> yes, i agree
[19:00] <chrisccoulson> i've thought of a better long solution but i don't know what upstream will think about it yet
[19:00] <kenvandine> talk to bratsche about it
[19:00] <kenvandine> i am sure he would love to hear it
[19:00] <chrisccoulson> will do. he'll see the e-mail shortly anyway
[19:01] <chrisccoulson> my idea might be completely rubbish yet. i need to try and write it down though ;)
[19:04] <seb128> chrisccoulson, topic for #ubuntu-desktop I guess
[19:04] <seb128> bratsche is there
[19:04] <chrisccoulson> seb128 - yeah :)
[19:05] <chrisccoulson> i only came here because slangasek added the gnome-session task to the existing bug report, but i'm not sure there's anything that can be done there currently
[19:05] <slangasek> seb128: why does the desktop have a separate channel, instead of the desktop developers participating in #ubuntu-devel?
[19:06] <chrisccoulson> hibratsche
[19:06] <seb128> slangasek, because you don't want us to flood this channel all day long to know who claims what update
[19:06] <bratsche> Hi.
[19:06] <chrisccoulson> hi bratsche even
[19:06] <chrisccoulson> i should use my space bar ;)
[19:06] <bratsche> :)
[19:06] <slangasek> seb128: that's fair, but this is stuff it would be nice to have in the main channel :)
[19:06] <seb128> right, I guess we hit ETOOMANYCHANS there
[19:07] <seb128> is dxteam might not be interested so much by distro topics
[19:07] <seb128> ie they hang out on #ubuntu-desktop and not there
[19:09] <seb128> #ubuntu-desktop is quite chatty in fact
[19:09] <seb128> but yeah such discussion should happen there
[19:09] <slangasek> chrisccoulson, bratsche: in the near term, what do you think should be done with this bug?  Invalidate the gnome-session task and reopen the xsplash task?  Or move the gnome-session task to something else, if we want the signalling to come from "something else"?
[19:10] <seb128> the issue is that gnome-session knows when apps are registered
[19:10] <seb128> not when they are done rendering
[19:11] <bratsche> Right.. I posted on desktop-devel-list to get suggestions on where to fix it, but that thread got derailed quickly.
[19:11] <chrisccoulson> bratsche - i'm writing my response to the list now :)
[19:13] <bratsche> Nice
[19:52] <fta> bug 412631
[19:52] <fta> Keybuk, ^^
[19:53] <slangasek> solution: retroactively remove daemontools from the world ;)
[19:59] <Keybuk> fta: don't do that, then
[20:02] <fta> it's not mine
[20:02] <fta> but it should not fail to boot anyway
[20:06] <cody-somerville> cjwatson, You updated xubuntu-meta using a debootstrap version higher than whats available in Ubuntu.
[20:09] <cody-somerville> I hope deleting debootstrap-version is safe
[20:15] <jtimberman> slangasek: and use runit instead ;)
[20:25] <ScottK> cody-somerville: Just edit it to what you have works too.
[20:25]  * ScottK already pinged him on the topic.
[20:50] <chrisccoulson> hey directhex - do you know the procedure for requesting package removals in debian? i looked up the maintainer of libipoddevice in debian, and it is pkg-mono
[20:51] <slangasek> chrisccoulson: the maintainer should file a bug against the ftp.debian.org pseudopackage, requesting its removal
[20:52] <chrisccoulson> slangasek - thanks. so i contact the maintainer to do that right?
[20:52] <chrisccoulson> (that's a silly question actually) ;)
[20:54] <directhex> mail debian-cli@lists iirc]
[21:08] <chrisccoulson> directhex - thanks:)
[21:32] <Mez> how are key revocations done in ubuntu?
[21:33] <slangasek> key revocations are done at the PGP level
[21:33] <slangasek> publish your revocation cert to the proper keyservers, and that should be enough
[21:33] <slangasek> though you probably also want to drop the key from your LP profile
[21:36] <Mez> slangasek: cheers :D
[21:37] <slangasek> Mez: for completeness, you probably want to publish to keyserver.ubuntu.com, as I'm not sure how often (if at all) that one pulls from the public network
[21:37] <Mez> slangasek: publishing to debian first :D
[21:41] <elmo> slangasek: FTR, it's a part of the public network and so syncs  regularly
[21:41] <slangasek> elmo: ah, excellent
[21:55] <lemonade`> hey guys, why don't you have dev man pages installed by default?
[21:56] <ion> The same reason we don’t have a panorama creator or a MIDI sequencer installed by default.
[21:58] <lemonade`> well the reason I ask is that new programmers have the compiler, but time and time again, they don't know to get the documentation. don't you think the program and the documentation for the program should both be installed, if one is installed by default?
[21:59] <lemonade`> a lot of the time, they don't even know *to* get the documentation.
[22:01] <mneptok> lemonade`: an Ubuntu developer that does not know about manpages-dev is in very bad shape
[22:01] <mneptok> lemonade`: even more so if they don;t know how to find them
[22:03] <lemonade`> mneptok: yes, they typically are in bad shape if they're just starting. and it's magnified by ubuntu being the go-to distro for people who want to try linux, and have it "just work". I'm thinking this should be included in the same spirit of usability.
[22:03] <mneptok> lemonade`: you'll need to install build-essential to compile anything. at which point you know about package management.
[22:04] <maco> does build-essential pull in manpages-dev?
[22:04] <maco> maybe it should recommend or at least suggest?
[22:04] <lemonade`> maco: I think a message to the user might help.
[22:04] <maco> if its suggested, then when you install build-essential it'll mentioni t
[22:05] <maco> mention but not pull. if its recommended itll be pulled in
[22:05] <lemonade`> maybe hilight it, so people don't overlook it with the rest of the mostly irrelevant output.
[22:05] <maco> suggests are listed right above "are you sure?"
[22:06] <maco> itll say "the following are recommended and will be instaled: <list> the following are suggested but will NOT be installed: manpages-dev ... do you want to continue? [Y/n]"
[22:06] <lemonade`> it's actually been a while since I used kubuntu... I'm not sure how the details are of apt-get, unfortunately.
[22:07] <maco> but i dont believe build-essential suggests or recommends it ATM
[22:07] <lemonade`> maco: yes, I think a prompt would be very effective.
[22:08] <maco> well the prompt doesnt ask if you want to install manpages-dev, just tells you that its not gonna, but then at least you know it exists and has some relationship to development since youre getting build-essential
[22:08] <maco> i found out about manpages-dev from a classmate
[22:09] <lemonade`> maco: so you *wouldn't* be able to decide wether or not to install it at the time of prompting?
[22:09] <geofft> oh, right, build-essential serves the role of being the set of packages you don't need to include in Dependencies, so you can't actually put it higher than Suggests, if at all
[22:09] <maco> lemonade`: you could say "no" and add it to the list of what to install
[22:09] <geofft> you can say +manpages-dev if you're using aptitude cli. (do you also want manpages-posix-dev?)
[22:09] <lemonade`> maco: oh right, I remember how it worked. :)
[22:09] <maco> so hit n or ctrl+c and then up and change it from "apt-get install build-essential" to "apt-get install build-essential manpages-dev"
[22:10] <maco> geofft: cli or tui?
[22:10] <geofft> I don't use the TUI often enough to remember
[22:10] <maco> geofft: build-essential uses Depends for all its stuff. im wondering if Recommends or Suggests is better for manpages-dev
[22:11] <maco> + sounds like the tui...
[22:11] <maco> Recommends doesnt require it but pulls it if you use apt and its available. suggests just mentions it to the user
[22:11] <maco> hi matt
[22:12] <ScottK> maco: Recommends are installed by default
[22:13] <dtchen> it would be a pretty bad idea to have build-essential recommend manpages-dev
[22:13] <maco> ScottK: like i said "if its available"
[22:13] <dtchen> please see http://www.debian.org/doc/debian-policy/ch-source.html#s-pkg-relations
[22:13] <ScottK> OK
[22:13] <maco> ScottK: its still not required...like you can use dpkg to install everything in Depends but not Recommends and itll be happy
[22:14] <maco> looking at dtchen's link
[22:14] <maco> oh...i see because then the buildd's will want it
[22:14] <maco> so would Suggests be ok?
[22:15] <dtchen> i wouldn't add it at all
[22:16] <dtchen> as Policy states, it has nothing to do with building packages
[22:16] <maco> does it have anything to do with ubuntu-dev-tools?
[22:16] <dtchen> if anything, status quo is fine; aptitude install build-essential manpages-dev
[22:17] <lemonade`> dtchen: but people don't know about it, that's the problem.
[22:17] <maco> do the manpages-dev say anything that K&R doesnt?
[22:18] <dtchen> maco: / lemonade`: you do realize that libc6-dev already suggests manpages-dev...
[22:18] <dtchen> (it also suggests glibc-doc)
[22:18] <maco> nope didnt know that. i dont do mental dependency resolution. im not apt ;)
[22:19] <lemonade`> dtchen: no, I'm not aware of the structure of apt beneath the covers.
[22:19] <maco> but now i do wonder...is manpages-dev more useful than the index of my copy of The C Programming Language?
[22:20] <lemonade`> maco: I'd think so.
[22:20] <lemonade`> at the least, it provides system-specific information.
[22:21] <lemonade`> not to mention, some people don't have that book.
[22:22] <maco> that is a book any C programmer would do well to invest in
[22:22] <maco> its the bible
[22:22] <lemonade`> I don't have that book.
[22:22] <maco> well unless you dont speak english....in which case i dont think there are l10n manpages either anyway.....
[22:24] <jtimberman> hah, thats the only C book I have :)
[22:24] <lemonade`> I got kochan's book when I was starting C.
[22:25] <maco> i got the o'reilly book first because i didnt know any better
[22:32] <cjwatson> cody-somerville: yeah, I know, sorry - just nuke it. that wasn't an important bit of the update :)
[22:33] <cjwatson> none of this should be in build-essential, it should be in a separate package
[22:33] <cjwatson> as dtchen says, build-essential has one and only one purpose (policy-mandated) and this ain't it - though I do sort of agree it belongs somewhere
[22:34] <cjwatson> there's an ancient bug about it which has never been fixed because nobody wants to be the guy who owns the development metapackage, which is certain to get flooded by requests for my-favourite-dev-package to be installed :)
[22:34] <cjwatson> maybe if we named it appropriately ...
[22:35] <ion> Let’s name it manpages-dev, because the user wants development manpages. Oh, wait.
[22:36] <lemonade`> as I take it, build-essential is the minimal build environment for installing source packages?
[22:36] <geofft> I think I'd really prefer a setting in apt or something to say, if I have installed foopackage, also install foopackage-dev and foopackage-doc
[22:37] <geofft> or perhaps Dev-Recommends/Doc-Recommends, so gcc can Doc-Recommend manpages-dev, and I can configure my system to accept or reject those
[22:39] <cjwatson> build-essential is defined in policy as follows:
[22:39] <cjwatson>      It is not necessary to explicitly specify build-time relationships on
[22:39] <cjwatson>      a minimal set of packages that are always needed to compile, link and
[22:39] <cjwatson>      put in a Debian package a standard "Hello World!"  program written in
[22:39] <cjwatson>      C or C++.  The required packages are called _build-essential_, and an
[22:39] <cjwatson>      informational list can be found in
[22:39] <cjwatson>      `/usr/share/doc/build-essential/list' (which is contained in the
[22:39] <cjwatson>      `build-essential' package).[1]
[22:40] <cjwatson> and yes, together with "Priority: required" packages and apt, it constitutes the minimal build environment installed on the build servers
[22:40] <cjwatson> adding Recommends or Suggests wouldn't affect that, as it happens, but I still don't think it ought to be overloaded
[22:41] <maco> ubuntu-dev-tools exists...does that count as the dev metapackage you mentioned above, cjwatson?
[22:42] <lemonade`> cjwatson: ok thanks.
[22:42] <maco> oooo shiny! theres a kubuntu-dev-tools too
[22:42] <lool> cjwatson: Hey the armel image doesn't boot; /conf/uuid.conf has a normally long UUID but blkid and /dev/disk/by-uuid list a 8 chars UUID
[22:42] <lool> cjwatson: Does that sound familiar?
[22:42] <lool> Note that these are vfat
[22:43] <lool> I'm not sure where that can come from; kernel configs perhaps or udev
[22:43] <maco> maybe thats the vfat label?
[22:43] <maco> those are limited char[8] iirc
[22:44] <lool> the UUID I get is UUID="4A83-265C"
[22:45] <lool> Hmm I get the same UUID on my system
[22:45] <cjwatson> maco: mm. maybe. I'm not entirely convinced
[22:45] <lool> Oh sorry I'm mixing apples and oranges
[22:45] <cjwatson> but it could function as a grab-bag, I suppose
[22:45] <lool> it's not looking at the actual UUID but at a file .disk/casper-uuid
[22:47] <maco> cjwatson: kubuntu-dev-tools has a gui for bzr. i cant imagine this is less on-topic
[22:47] <cjwatson> lool: right, that isn't a filesystem uuid, just a uuidgen one
[22:47] <maco> (u-d-t just uses normal bzr)
[22:48] <lool> cjwatson: Ah the UUID is named casper-uuid-babbage
[22:48] <cjwatson> maco: I'm not really opposed, it's definitely a much better place than build-essential, though it might inspire a reverse gripe as it includes lots of stuff useful for developers of Ubuntu but not developers on Ubuntu
[22:48] <lool> But the casper code only seems to check for $path/.disk/casper-uuid
[22:48] <lool> Oh sorry, *
[22:48] <lool> I'm blind
[22:48] <cjwatson> ./scripts/casper:79:    for try_uuid_file in "$path/.disk/casper-uuid"*; do
[22:48] <cjwatson> exactly
[22:49] <maco> cjwatson: you mean itd get the "but what about my favourite lib's dev headers?!" thing you said above?
[22:49] <cjwatson> why are you looking at the uuid-matching code in particular?
[22:49] <lool> cjwatson: Just because the error was Unable to find a medium
[22:49] <cjwatson> maco: no, reverse, it'd get "but this installs a big pile of stuff that's useful for people developing Ubuntu itself - I just want to write software on Ubuntu"
[22:50] <cjwatson> but maybe I'm just being oversensitive
[22:50] <cjwatson> there's probably no way to please everyoone
[22:50] <cjwatson> -o
[22:50] <seb128_> hum, can't go back from the partitioning screen on ubiquity
[22:50] <lool> ogra: Didn't we set livemedia in the past?
[22:50] <maco> cjwatson: oh hey it does... wow u-d-t has a lot more dependencies thatn k-d-t
[22:50] <ogra> lool, i dont think so
[22:50] <geofft> cjwatson, wouldn't adding support for pulling in -doc or -dev stuff when you install the corresponding package work?
[22:51] <cjwatson> geofft: it's a heck of a lot harder
[22:52] <cjwatson> geofft: with ten years of experience in Debian I have learned to prefer approaches that work now ;-)
[22:52] <geofft> hah. good point
[22:52] <cjwatson> it would require independent UI implementation in umpteen different package management frontends
[22:59] <Quintasan> debuild -S -s -k$GPGKEY starts with clean and it fails because I didn't build it yet, how do I ommit clean?
[23:00] <cjwatson> Quintasan: -nc
[23:00] <cjwatson> Quintasan: but it's a bug in your package if clean fails there
[23:01] <cjwatson> oh, -nc probably doesn't work with -S actually, so you just have to fix the bug
[23:01] <lool> cjwatson: Ok; /lib/udev/path_id changed output with new drivers in .31
[23:02] <lool> Insead of platform-mmc something it returns platform-mxsdhci something
[23:02] <cjwatson> hah, lovely
[23:02] <Quintasan> cjwatson: how should I do it then? building creates a build dir in each dir with source, I added find . -name build -exec rm -r {} \; to clean
[23:02] <lool> Which is the name of the driver for MMC on FSL MXC
[23:02] <cjwatson> Quintasan: rm -rf
[23:02] <lool> cjwatson: I guess it's best to workaround it by passing livemedia in the cmdline than pushing casper at this point
[23:03] <cjwatson> lool: depends on the status of other images, I don't know right now
[23:03] <lool> Will poke slangasek
[23:03] <lool> slangasek: ^
[23:05] <cjwatson> Quintasan: though I can't see a case in which that command would actually fail, since it won't run rm if there are no such directories
[23:05] <lool> Pushed the casper fix
[23:05] <lool> to bzr
[23:05] <cjwatson> Quintasan: does the debian/rules clean output clearly show that that's the command that's failing?
[23:06] <slangasek> lool: the casper change only affects behavior or armel?
[23:06] <cjwatson> pretty certain it wouldn't affect anything else
[23:06] <lool> slangasek: It's in a common code path but I don't expect this match on any other arch
[23:06] <lool> It's a very specific device name
[23:06] <ogra> lool, ah, thats why editing /conf/uuid.conf doesnt work for me
[23:07] <slangasek> lool: upload if you think it's needed, then
[23:07]  * ogra just repackaed the initrd.lz
[23:07] <ogra> but doesnt get it mounting either
[23:08] <ogra> though i dont get why it doesnt work, casper only looks at /dev/disk/by-uuid, no ?
[23:10] <lool> slangasek: Actually not sure if we need to bother
[23:10] <lool> slangasek: Just get a nice oops in squashfs if I pass LIVEMEDIA on the kernel cmdline
[23:11] <lool> hmm might be just a warning
[23:11] <lool> I get input/output error though
[23:12] <cjwatson> usually not a good sign
[23:15] <ogra> well, stdin: error 0 isnt one either
[23:15] <ogra> additionally the kernel has features that arent suposed to be there
[23:19] <Quintasan> cjwatson: hmm, I made a simple mistake but I don't know how to fix it, archive untars to rbutil-1.2.2 but source is in rbutil-1.2.2/rbutil and rules try to compile it from rbutil-1.2.2. How do I specify the source tree?
[23:24] <lool> cjwatson, ogra, slangasek: So I want push casper and consider the A4 image failed
[23:24] <lool> Needs kernel fixes to boot
[23:25] <ogra> needs kernel renaming too
[23:25] <ogra> so we dont end up with -babbage and -imx51 in the same image
[23:25] <lool> ?
[23:26] <ogra> we get linux-headers-imx51 and whatnot indise the squashfs
[23:26] <lool> this is a separate discussion which seems to be moving to a resolution post A4
[23:26] <ogra> *inside
[23:26] <cjwatson> Quintasan: $(MAKE) -C <directory> in your build target, usually
[23:26] <lool> I don't know about linux-headers-imx51
[23:26] <cjwatson> Quintasan: debian/rules does precisely what you program it to do :-)
[23:26] <ogra> i told you hours ago in #mobile
[23:27] <Quintasan> cjwatson: I thought there is a DEB_<something> variable :<
[23:27] <slangasek> lool: and there's no kernel support for getting this fixed up in time for A4?
[23:27] <cjwatson> Quintasan: if you're using cdbs, on your own head be it, it's hard to customise
[23:27] <slangasek> s/kernel support/kernel team support/
[23:27] <ogra> lool, i'm not sure what else can be affected by that
[23:28] <ogra> slangasek, it would take half a day to build even if rtg managed to get a new package up
[23:28] <cjwatson> Quintasan: if you really think it's a good idea to use a system that often requires grepping through make rules in order to figure out how to customise it, that's your call :)
[23:28] <cjwatson> Quintasan: james_w gave a packaging training talk on debhelper 7 the other day, which is pretty much just as concise and much better-documented
[23:28] <slangasek> ogra: well, the milestone freeze doesn't prevent someone working on this, in any case
[23:29] <Quintasan> cjwatson: thanks, I will look into it
[23:29] <ogra> slangasek, they did a lot of effort to get at least the one with the broken naming out, i'd personally prefer to have their energy focused on getting it right without being in a rush
[23:29] <lool> slangasek: rtg is gone
[23:29] <ogra> slangasek, rtg already agreed on the neaming
[23:29] <cjwatson> Quintasan: as it happens I think DEB_BUILDDIR is the variable in question
[23:29] <ogra> *naming
[23:29] <slangasek> ogra: the naming isn't what's breaking alpha4
[23:29] <lool> slangasek: bjf is bjf-afk
[23:30] <cjwatson> in debhelper 7 you'd write an override_dh_auto_build: target
[23:30] <lool> and amitk isn't on IRC
[23:30] <slangasek> lool: ok then
[23:30] <ogra> slangasek, the naming made us apply various werid hacks to a formely working system
[23:31] <cjwatson> Quintasan: (BTW, this is just my opinion of cdbs, I realise other developers here have different opinions, but, hey, I'm the one who was answering ... ;-) )
[23:31] <Quintasan> I'm not using cdbs :P
[23:31] <cjwatson> cdbs is the thing that has DEB_* variables
[23:31] <Quintasan> oh :<
[23:31] <cjwatson> if you aren't using cdbs, there are no such variables
[23:32] <cjwatson> override_dh_auto_build:
[23:32] <cjwatson>         $(MAKE) -C src -f makefile_cptree TREE_TOP=$(CURDIR) \
[23:32] <cjwatson>                 CC=$(CC) DEBUG="$(DEBUG)" CirclePack
[23:32] <cjwatson> ^- example of this kind of thing in dh7
[23:32] <maco> you still use dh_make to do dh7 stuff? dtchen mentioned there being a way to buid up only what you need instead of using dh_make then going through and deleting 2/3 of what it generates
[23:32] <cjwatson> I don't see much point in dh_make with debhelper 7
[23:33] <cjwatson> given that the rules file starts with /usr/share/doc/debhelper/examples/rules.tiny and it's probably best not to create other files until you need them ...
[23:33] <Quintasan> urgh, I don't get most of the discussion -_- That's what you get from using cdbs and pkg-kde-tools all the time :S
[23:34] <maco> hrm i think we need to poke dholbach into replacing his "how to make a package" video with a non-dh_make version
[23:34] <cjwatson> the basic idea of dh7 is that standard packages that don't need to do anything surprising just have %: dh $@
[23:34] <cjwatson> and each override target on top of that represents an unusual thing
[23:34] <maco> in debian/rules?
[23:34] <cjwatson> but it's very familiar for debhelper users, because every single thing you can override is "override_" plus a dh_* command name
[23:34] <maco> is there a way to generate a skeleton debian/control without dh_make?
[23:34] <cjwatson> so it's really easy to work out general rules for customising
[23:34] <cjwatson> oh, don't know about that
[23:35] <cjwatson> maybe somebody should do dh_make -7 :)
[23:35] <cjwatson> I'm probably a bad example, I write debian/control by hand
[23:35] <maco> that just means youve been doing this too long
[23:35] <cjwatson> yes
[23:36] <maco> i know theres a line about Depends and one about Build-Depends and umm....Maintainer...and a Description
[23:36] <maco> and some other stuff
[23:36] <maco> variously named, starting with a capital letter :P
[23:36] <cjwatson> I was initially deeply sceptical about dh7 but am totally sold on it now, especially after discovering its plugin support
[23:36] <cjwatson> I'm in the middle of converting lots of d-i over to 'dh --with d-i $@'
[23:36] <ion> Yeah, dh7 and ‘--with’ ftw.
[23:37]  * Quintasan got lot to learn
[23:37] <cjwatson> well, debhelper's man pages are generally superb, you can follow it all through there
[23:38] <kklimonda> cjwatson: is it "easier" than using cdbs?
[23:38] <cjwatson> actually dh7 also has 'dh --sourcedirectory=build $@' and such, in very recent versions
[23:38] <seb128_> cdbs for the win ;-)
[23:38] <cjwatson> kklimonda: I certainly find it so
[23:38] <maco> so if i wanted to say it uses quit id do "dh --with-quilt $@"?
[23:38] <seb128_> is there somewhere in dh7 where we could add magic for langpacks etc?
[23:38] <slangasek> kklimonda: shorter debian/rules for the general case, and for the exceptions there are useful manpages
[23:38] <cjwatson> '--with quilt', but yes
[23:38] <seb128_> as we do with the gnome.mk in cdbs
[23:39] <cjwatson> seb128_: we could override its sequencing, in theory anyway
[23:39] <maco> is there a list of addons? man dh just says "--with <addon>" but doesnt say what those addons are or where to find the list of them
[23:39] <cjwatson> perhaps best to do it in a gnome plugin
[23:39] <cjwatson> so you'd have --with gnome, and that'd deal with langpacks
[23:39] <seb128_> we would have to get that plugin doing something in debian
[23:40] <seb128_> and convince people to use it
[23:40] <ion> maco: apt-file search /usr/share/perl5/Debian/Debhelper/Sequence
[23:40] <cjwatson> maco: I think it's probably a bug that there isn't an easier way, but ls /usr/share/perl5/Debian/Debhelper/Sequence/
[23:40] <seb128_> so we would just have to enhance the ubuntu version
[23:41] <maco> cjwatson: or the bug is that the manpage doesnt say to ls that :P
[23:41] <kklimonda> oh, it's written in perl - /me runs screaming like a girl.. ;)
[23:41] <cjwatson> the other approach would be some kind of vendor detection in debhelper
[23:41] <cjwatson> I talked with Joey very very briefly about that at DebConf, but haven't had a chance to follow through yet
[23:41] <cjwatson> actually for the purpose of erasing our last delta against debhelper
[23:42] <ion> /usr/share/doc/debhelper/PROGRAMMING.gz kind of points to that, and dh(1) points to PROGRAMMING. :-P
[23:42] <cjwatson> the other approach would be a dh_langpack that's in the default sequence but I'm a bit scared of Joey shouting at me for changing the default sequence :)
[23:42] <maco> little bit roundabout...
[23:43] <cjwatson> I think again I'd probably want to get that into debhelper upstream with vendor detection
[23:43] <cjwatson> dh_langpack would probably be useful anyway
[23:43] <seb128_> would be nice
[23:44] <cjwatson> BTW I don't know if people noticed amid the annoyance with my broken debootstrap version, but there's now a --with germinate to make generating metapackages from seeds trivial
[23:46] <cjwatson> http://paste.ubuntu.com/252198/ was my first cut at merging our dh_installudev diff but I still need to do some polishing
[23:47] <cjwatson> kklimonda: I generally find I only need to look into the internals when actually writing extensions; the documentation is normally very precise about what it does