=== slank is now known as slank_away
[00:25] <nuxusr> any news on a release date for ubuntu for android?
[00:34] <xnox> mfisch: I hope no hard-feeling about quilt & bzr-bd ;-) it is slightly long-winded, but we are yet to come up with a more universally better way of handling them.
[00:36] <mfisch> xnox: yeah I'm reading that now
[00:37] <mfisch> xnox: why build with bzr bd and not just dpkg-buildpackage?
[00:37] <xnox> mfisch: the developer guide /should/ be covering this. If it didn't, please point me to those pages & i'll try to fix them.
[00:37] <mfisch> xnox: I'll go check there, I haven't read through it in awhile
[00:38] <xnox> mfisch: (1) because that verifies that the branch matches, what the branch importer will expect in the future. (2) because it will allow "nesting" the packaging into e.g. upstream branch (3) because this makes sure recipes also work
[00:39] <xnox> mfisch: and with merge proposals, I tend to go UDD way and actually check bzr diff & push the branch to lp:ubuntu/$pkg. For you to get karma =)
[00:39] <mfisch> I was first doing debdiffs until that was suggested instead
[00:39] <xnox> mfisch: also since this is a new upstream release, bzr bd will generate .orig.tar.gz tarball from pristine tar delta, which dpkg-buildpackage will not.
[00:40] <xnox> i think the lack of .orig.tar.gz is the killing feature here. hard to include it with a debdiff, but easy with the bzr-bd style branch (thanks to pristine-tar delta).
[00:40]  * xnox preffers UDD branches, but they do have quirks with respect to quilt patches.
[00:42] <mfisch> xnox: why do the branches have the quilt patches pushed before checkin?
[00:44] <xnox> mfisch: if I understood that question correctly, dpkg-source has patches applied => same approach was taken in the package-importer to push the patches and commit .pc. This way regardless of which method used (apt-get or bzr branch) the directory layout is the same and ready to push/apply a new ubuntu patch on top.
[00:45] <xnox> apt-get source nano, will download source package, unpack & apply patches == $ bzr branch ubuntu:nano
[00:45] <mfisch> that makes sense
[00:45] <mfisch> xnox: and I never answered you but no hard feelings because I'm trying to learn
[00:47] <xnox> dpkg-source does clever tricks and tries to check if the patches have/haven't been pushed/popped and tries to clever stuff - which breaks if patches have fuzz =/
[00:47] <xnox> s/tries to/tries to do/
[01:00] <GunnarHj> xnox: ping?
[01:00] <xnox> GunnarHj: yeah?
[01:01] <xnox> =) what's up?
[01:01] <GunnarHj> xnox: It's about bug 1083605. I'm pretty sure it's a two step problem, and that the patch solves the first one.
[01:01] <ubottu> Launchpad bug 1083605 in accountsservice (Ubuntu) "accountsservice doesn't set locale choice if /home is on nfs" [Undecided,In progress] https://launchpad.net/bugs/1083605
[01:03] <GunnarHj> xnox: That would take care of the accountsservice issue. The rest of the problem lies elsewhere, possibly in pam.
[01:03] <xnox> GunnarHj: ok. So you want that patch for raring. But is that patch useful on it's own as an SRU? Or will the SRU wait for a more comprehensive fix, e.g. together with a pam fix?
[01:04] <GunnarHj> xnox: No, let's stick with raring for now.
[01:04] <xnox> GunnarHj: ack.
[01:05] <GunnarHj> xnox: Thanks in advance. :)
=== NCommander is now known as Guest11391
=== Tonio_ is now known as Tonio_aw
=== fisted_ is now known as fisted
[02:34] <mspencer_> Hi, I've started working on a program for Ubuntu called Contributor Console (https://launchpad.net/contributor-console). Would ubuntu-devel or ubuntu-devel-discuss be a good place to announce it?
[02:41] <hyperair> i like how phoronix always has some way of portraying canonical as some unreasonable evil company that has no interest in its users wishes: http://www.phoronix.com/scan.php?page=news_item&px=MTI1NTI
[02:41]  * hyperair sighs
[02:41] <hyperair> Laney: ^ you're featured.
[02:50] <sarnold> hyperair: probably any website that has a pop-up flash advert, an embedded flash advert, and uses those ridiculous double-underline unrelated ads can be ignored when they talk about "users' wishes" -- they obviously hate _their_ users...
[02:50] <hyperair> sarnold: heh. i had forgotten about those. i've got adblock in place.
[02:51] <sarnold> hyperair: not a bad approach, overall, but I do so little web browsing in places as offensive as phoronix that it's not really an issue.
[02:52] <hyperair> sarnold: well you'll be surprised how much difference it makes, actually.
[02:52] <hyperair> whenever i stare at someone else's screen browsing $website i keep wondering why it looks so much different from how it looks on mine
[02:52] <hyperair> and then i realize there are all these ads on the side of the page.
[02:52] <sarnold> hyperair: there's surprisingly little crap on your usual mail list archives, rfcs, and free-software wiki pages... :)
[02:53] <hyperair> eh well, that's true.
[02:55] <slangasek> you must be reading different rfcs that I am
[02:55] <slangasek> ;p
[02:57] <sarnold> slangasek: perhaps, I always go for the original .txt versions on ietf.org. Other goofballs might re-package the rfcs with flash ads and the like, but it's usually not too hard to avoid those :)
[02:59] <hyperair> sarnold: M-x rfcview-find-rfc
[02:59] <hyperair> ^_^
[03:00] <sarnold> hyperair: hahaha
[03:00] <sarnold> hyperair: I never got the hang of emacs. too complicated. but features like those sometimes make me wish I'd put in more effort to figure it out.
[03:00] <hyperair> sarnold: yeah that's what i told myself back when i used vim.
[03:01] <hyperair> and eventually i found enough time to put in the effort to figure it out
[03:01] <hyperair> if i have any regret, it's that emacs is pretty crap when you start exhibiting rsi symptoms.
[03:01] <sarnold> ouch
[03:01] <hyperair> but vim makes my left wrist start making clicking sounds from continuously hitting Esc, so it's not much better.
[03:02] <hyperair> i usually twist rotate my hand to get my middle finger on the esc key, see
[03:02] <sarnold> heh, ^[ still works for esc in vim.
[03:02] <hyperair> oh yeah that.
=== Ursinha is now known as Ursinha-afk
[03:02] <sarnold> two hands, of course, but maybe less ohrrible than esc
[03:02] <hyperair> i hadn't grasped the ^ things yet before switching to emacs.
[03:02] <sarnold> but now you grasp the C- things just fine? :)
[03:03] <hyperair> emacs is full of C- things ;-)
[03:03] <hyperair> after a while you know what almost every ^[[:alpha:]_-?] means.
[03:03] <hyperair> (there might be more)
[03:04] <hyperair> also emacs usually has longhand commands with intuitive names to them if you can't remember the keybindings.
[03:04] <hyperair> vim's commands are just.. weird.
[03:06] <sarnold> .. how's that old yarn go? vi's easy! if you know what dw de d0 d$ dj dk dap do, then you know what cw ce c0 c$ cj ck cap do...
[03:07] <ion> Vi(m) commands are mostly based on good mnemonics.
[03:08] <hyperair> i recall a few, and to this day i still use vi movement keys for moving around pdf's in evince, and less and screen's copy mode
[03:08] <sarnold> I've always wanted c% to work but it never seems to do what I want. I wonder if it groks ca% or ci%.
[03:08] <ion> You don’t really use the “vi movement keys” a lot in vi.
[03:09] <hyperair> but for the most part, they don't really make sense, and it's pretty hard to remember while you're starting out.
[03:09] <ion> Sure, there’s a learning curve.
[03:09] <hyperair> ion: for viewing files they're pretty useful, though
[03:09] <hyperair> w, e, b, hjkl
[03:09] <ion> But they do tend to make sense. :-P
[03:09] <sarnold> *sigh* no luck on ci% or ca%. :(
[03:09] <hyperair> and i have no idea what ci% or ca% means
[03:09] <sarnold> hyperair: % bounces between matched delimeters (){}[]<>
[03:09] <ion> word, end, back, the-four-letters-from-h-in-qwerty-that-move-one-char-to-some-direction
[03:09] <hyperair> ah
[03:10] <ion> ci: change inner, ca: change a
=== Ursinha-afk is now known as Ursinha
[03:10] <hyperair> er what does that mean?
[03:10] <ion> di: delete inner (something), da: delete a (something)
[03:10] <hyperair> oh inner as in everything between point and whatever else?
[03:10] <ion> dip: delete the paragraph without deleting the empty line after it
[03:10] <sarnold> hyperair: I often want to change the contents within () or [] or something, but the damned 'c' doesn't do what I want.. and just a few years ago I learned about ip iw ap aw for "inner paragraph", "inner word", "a paragraph", "a word" psuedo-range commands, but they don't apply to % :(
[03:11] <ion> dap: delete a paragraph and the empty line after it
[03:11] <hyperair> i never got the hang of those, but they're pretty cool
[03:11] <ion> di{: delete between {} without deleting the {}
[03:11] <ion> da{: delete between {} including the {}
[03:11] <sarnold> ion: oooh?
[03:11] <hyperair> hm
[03:11]  * sarnold hugs ion
[03:11] <ion> ya{: yank (copy) between {} including the {}
[03:11] <hyperair> in emacs i usually do something like C-SPC C-M-n C-w
[03:12]  * sarnold hugs ion again
[03:12] <hyperair> i.e. start highlighting from point, step over balanced braces, and delete
[03:12] <ion> ca{: change (delete and go to insert mode) between {} including the {}
[03:13] <ion> Va{: visual linewise selection; select “a” {} block
[03:13] <sarnold> hyperair: heh, ^W will always mean just "kill word" to me, the idea of using ^W to delete more than a word would never fit in my head. :)
[03:17] <hyperair> sarnold: i somehow manage to switch between modes when using the shell and emacs.
[03:20] <sarnold> hyperair: hehe, that's good :)
[03:21] <hyperair> sarnold: and somehow when browsing as well, or i'd end up trying to close a tab every time i wanted to C-w
[03:21] <hyperair> sarnold: or closign the thunderbird compose email window when trying to cut text
[03:22] <sarnold> hyperair: pentadactly for the win, ^W kills words in firefox too :)
[03:22] <hyperair> sarnold: it gets more hilarious when my mouse is accidentally left on chromium, using focus-follows-mouse, and i'm staring at the emacs window in the other monitor..
[03:22] <sarnold> hyperair: let the swearing commence...
[03:22] <hyperair> then i hold down ^N to try to move down
[03:23] <hyperair> and wheeee
[03:23] <hyperair> ^P is equivalently hilarious
[03:23] <hyperair> suddenly i get hundreds of print dialogs spawning
[03:23] <sarnold> hahaha
[03:23] <hyperair> if i don't end up swapping, it eventually stops
[03:23] <sarnold> I normally just killed tabs.
[03:23] <hyperair> and then thanks to my super+mouse2 binding to close windows in compiz, i can just hold down super and repeatedly middle click to close these windows
[03:25] <sarnold> off to dinner :) thanks again hyperair and ion :D
[03:25] <hyperair> :)
[03:25] <hyperair> happy eating
[03:33] <ion> “using focus-follows-mouse” That’s your problem right there. ;-)
[03:35] <hyperair> ion: heh. i find it speeds up some use cases significantly
[03:35] <hyperair> ion: for example, copy-pasting stuff between multiple windows
[03:36] <hyperair> move mouse, ^C, move mouse, ^V
=== cpg|away is now known as cpg
[03:49] <infinity> hyperair: Or, hilight, move mouse, middle-click.  No need for focus to follow, since the click both raises and pastes.  Done.
[04:05] <hyperair> infinity: middle click means you need to aim your mouse for the text box.
[04:05] <hyperair> infinity: also i've turned off raise-on-click and auto-raise.
[04:06] <hyperair> i often arrange my windows in an overlapping manner and don't want them rearranging the order when i interact with them
[04:06] <hyperair> so i have them raise only on alt+click
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[06:34] <sladen> morgen
[07:34] <pitti> Good morning
[08:00] <dholbach> good morning
=== schmidtm_ is now known as schmidtm
=== stan_ is now known as stan
=== yofel_ is now known as yofel
[09:09] <Laney> hyperair: hoho, I saw that
[09:10] <Laney> I must have Arrived™
[09:10] <hyperair> hahahaha
[09:10] <hyperair> yes you have
=== mcclurmc_away is now known as mcclurmc
[09:15] <Laney> surprised by the people I find reading that website ;-)
[09:37] <vila> hi all !
[09:37] <vila> after upgrading my precise desktop this morning (new kernel), I lost network connectivity :-/
[09:37] <vila> I restored eth0 with ifdown/ifup (!!) but still lack dns. Does that ring any bell ?
[09:38] <vila> kernel is 3.2.0-35
[09:39] <cjwatson> semiosis: We don't operate the PPA service here - report issues to #launchpad rather than here, please
[09:50] <xnox> vila: Support in in the #ubuntu channel. This channel is for developing ubuntu itself.
=== henrix_ is now known as henrix
[10:03] <hyperair> Laney: =O
[10:12] <pitti> cjwatson, infinity: can you please add a manual britney blocking of the next pygobject which I'm about to upload?
[10:13] <pitti> 3.7.3 is not very invasive, but still, I'd like to wait for all autopkgtests
[10:19] <Laney> pitti: I can do that, doing
[10:19] <pitti> Laney: thanks
[10:20] <pitti> I'm currently fighting with "undefined symbol: Py_InitModule4_64" in the python2.7-dbg build, so upload might still take a while
[10:21] <Laney> there we go
[10:21] <pitti> that worked with earlier python2.7 versions
[10:21]  * pitti yearns for the day when we do full autopkgtest runs for proposed→ release
=== _salem is now known as salem_
=== Tonio_aw is now known as Tonio_
[11:30] <pitti> jibel: FYI, it seems the dreaded "hash sum mismatch" also affects our buildds: https://launchpadlibrarian.net/126071308/buildlog_ubuntu-raring-armhf.pygobject_3.7.3-0ubuntu1_CHROOTWAIT.txt.gz
[11:30] <pitti> this is still a mystery to me; I would expect mirrors to do an atomic switch, i. e. sync dists.new, and then mv dists.new dists
[11:31]  * pitti retries the build
=== doko_ is now known as doko
[12:07] <pitti> Laney: ok, all reverse depends succeeded; can you please unblock pygobject again?
[12:07] <pitti> I think it's fine, the breakage with python2.7-dbg also happens with the current raring version, so that's not a regression in -proposed
[12:08] <Laney> righto
=== nenolod_ is now known as nenolod
[12:09] <Laney> done
[12:22] <xnox> pitti: atomic switch does not help. I download Release, atomic switch happens, I download Packages => I get checksum missmatch.
[12:23] <xnox> pitti: even like Release & Release.gpg are racy, if I catch "atomic switch" in between.
[12:24] <xnox> pitti: the current proposal is for mirrors to cache several versions of dists/ and redirect clients to the same one "throghout the apt-get update session" such that for all requests they get all files from related dinstall.
[12:24] <mvo> https://code.launchpad.net/~racb/ubuntu/quantal/apt/by_hash
[12:24] <xnox> that ^
[12:24] <xnox> ;-)
[12:25] <xnox> mvo: imho the "simple" work-around is for apt to actually tell me which repos/urls failed & redownload only those. But I don't see how I can run "apt-get update" on individual lines =(
[12:25] <xnox> mvo: e.g. trap hash-missmatch & retry that repo.
[12:26] <mvo> xnox: yeah, it can't just do based on deb-line
[12:26] <mvo> xnox: but it will if-modified-since so at least it won't redownload stuff that is fresh
[12:26] <xnox> mvo: architectural deficiency or consistency concerns?
[12:26] <mvo> xnox: retry-once is indeed a good idea
[12:26] <mvo> xnox: simply not-implemented
[12:27] <xnox> mvo: /me has a winter project of: apt-getget wrapper that dpkg-redirects apt-get, traps stderr, greps for hash-missmatch and has a configurable (timeout of couple of seconds & retry up-to 3 times)
[12:27] <Laney> O_O
[12:28] <mvo> xnox: *cough* I hope with wrapper you mean "c++" ;)
[12:28] <xnox> (e.g. you may catch a different repo missmatch, but not deadlock on really broken / mismatched repos)
[12:28] <Laney> weird hacks when you have the source already
[12:28] <xnox> mvo: /me likes wrapper cause then I can deploy it to precise on the cloud today.... but I guess we can cherry pick that.
[12:28] <xnox> mvo: but that means I need to learn C++ =/
[12:29] <mvo> apts c++ is not very fancy, its more c-with-classes, very few of the new stuff
[12:29]  * xnox 's is also boost uploader..... which may or may not be disturbing.
[12:30] <xnox> mvo: I see. Well I started poking it, noticed Joe Sixpack & no error codes.... (well just 100 on _any_ error)
[12:30] <xnox> it would be nice at least to report a different error code on hash-missmatch.
[12:30]  * mvo  nods
=== mitya57_ is now known as mitya57
[12:38] <xnox> mvo: you'd welcome such hacks? =) me thought retry would not be accepted upstream....
=== tkamppeter_ is now known as tkamppeter
[12:59] <hyperair> is there a proper way of disabling services in upstart yet?
[12:59] <hyperair> (i.e. without hacking into the init file to comment out the "start on" line)
=== NCommander is now known as Guest48175
[13:00] <Laney> I thought you create an override file or so
[13:00] <Laney> http://upstart.ubuntu.com/cookbook/#disabling-a-job-from-automatically-starting
[13:01] <hyperair> yeah i just read that
[13:01] <hyperair> nice.
[13:01] <hyperair> i didn't realize that method existed
[13:01] <hyperair> is that documented anywhere?
[13:01] <Laney> how isn't that documentation?
[13:02] <hyperair> er
[13:02] <hyperair> whoops
[13:02] <hyperair> i misread that as askubuntu.com
[13:02]  * hyperair was reading that
[13:13] <xnox> hyperair: the beauty of the override files is that you can override any portion of the job file. E.g. echo exec mydaemon -vvvvv --debug >> /etc/init/mydaemon.override; will override the exec stanza to use different command line args.
[13:22] <hyperair> yeah i noticed. nice.
=== Tonio_ is now known as Tonio_aw
=== Quintasan_ is now known as Quintasan
=== mitya57_ is now known as mitya57
=== mcclurmc is now known as mcclurmc_away
=== cpg is now known as cpg|away
[14:20] <pitti> xnox: ooh, so that's it, not a non-atomic /dist update; thanks for pointing out
[14:26] <zykes-> does python-debian contain helpers to read Packages files ?
=== Tonio_aw is now known as Tonio_
[14:31] <xnox> zykes-: one of python-debian or python-apt does.
[14:35] <zykes-> not much docs for that xnox
[14:35] <xnox> zykes-: look at reverse-depends code & use ipython. It seemed to be ok. Also unit-tests are descriptive.
=== mcclurmc_away is now known as mcclurmc
[14:40] <zykes-> xnox: where's the source code for the python-debian stuff ? Can't see the tests in the tarball
[14:41] <xnox> zykes-: hmm... i thought it was there. maybe it was in python-apt instead...
[14:41] <tumbleweed> I don't recall python-debain having unit tests
[14:42] <zykes-> shoot me now ;p
[14:44] <zykes-> looks like it does
[14:44] <zykes-> https://code.launchpad.net/python-debian
[14:45] <tumbleweed> oh, right
=== rsalveti_ is now known as rsalveti
=== Ursinha is now known as Ursinha-afk
=== slank_away is now known as slank
=== Ursinha-afk is now known as Ursinha
[15:29] <semiosis> cjwatson: thanks for the pointer to #launchpad :)
[16:43] <nuxusr> ubuntu for android -- any news on a release date? or a date for when they might give the release date :-)
[16:45] <nuxusr> in other words, is santa going to deliver the package in time?
[16:48] <xnox> nuxusr: this is not the right channel for general discussions around ubuntu. Please go to #ubuntu or even #ubuntu-offtopic or ubuntuforums.
[16:49] <nuxusr> ubuntu for android isn't even released yet. I'm a developer looking for developers working on the project. isn't this the right channel….
[16:49] <nuxusr> peeps in off topic don't even know the project exists ;-P
[16:50] <xnox> nuxusr: no, here are developers that work on simply plain ubuntu raring as seen on archive.ubuntu.com. And only technical discussions happen here around packaging & developing ubuntu itself.
[16:50] <xnox> nuxusr: no discussion of developer for / on Ubuntu Platform happens here.
[16:50] <xnox> s/developer/development/
[17:00] <marrusl> hi guys, does anyone happen to know if acroread will make its way back into partner?  if not, any idea why it was dropped?
[17:00] <marrusl> adobe dropped support?
=== Tonio_ is now known as Tonio_aw
=== Tonio_aw is now known as Tonio_
[17:06] <xnox> marrusl: you can file a bug on launchpad against acroread package, then developers of canonical partner repository will be notified.
[17:07] <marrusl> xnox, good call.
=== Tonio_ is now known as Tonio_aw
=== Tonio_aw is now known as Tonio_
=== Tonio_ is now known as Tonio_aw
=== mcclurmc is now known as mcclurmc_away
=== deryck is now known as deryck[lunch]
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
[18:30] <slangasek> Laney: ping
[18:34] <blackz> is there a rapid way to see sponsored packages for a user?
[18:42] <xnox> blackz: http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi
[18:44] <blackz> xnox: thank you!
=== NCommander is now known as Guest82944
=== deryck[lunch] is now known as deryck
=== Tonio_aw is now known as Tonio_
=== salem_ is now known as _salem
[21:04] <Laney> hi slangasek
[21:09] <slangasek> Laney: heya - how much do you understand about how valac works?
[21:09] <slangasek> Laney: I'm trying to make it cross-build-friendly
[21:09] <Laney> how in what sense?
[21:09] <Laney> oh, like that, very little :-(
[21:10] <micahg> slangasek: robert_ancell is a big vala fan
[21:10] <slangasek> Laney: hmm, ok.  so the problem I'm up against is that valac-0.18 depends on libglib2.0-dev, which pulls in the native version even when cross-building, and making libglib2.0-dev co-installable will be non-trivial.
[21:10] <slangasek> ah, robert_ancell is online now, he wasn't when I pung Laney ;)
[21:11] <juliank> slangasek: Shouldn't libglib2.0-dev be easily co-installable? All architecture-specific files are in architecture-specific subdirectories already, as far as I know
[21:12] <slangasek> juliank: no, it contains helper binaries in /usr/bin
[21:14] <juliank> Ah, OK. Then maybe move them out to a new libglib2.0-dev-bin package, I hope that the binaries do not create architecture specific files, but I could be wrong (and Vala code and many glib projects most probably do not need them to build)
[21:15] <slangasek> Laney, robert_ancell: so what I'm trying to figure out is why, when cross-building activity-log-manager with libglib2.0-dev:armhf installed and no special modifications, valac is perfectly happy; but if I then try to build some sample vala code I found, http://www.algonet.se/~afb/d/sample1.vala, it spits out pkg-config/gobject-2.0 errors
[21:15] <juliank> Most binaries should not care about architecture.
[21:16] <slangasek> juliank: in the longer term that's certainly something to be done, but right now I'm trying to sort out whether the valac dep is correct
[21:16] <slangasek> because if valac *is* using the native libglib2.0-dev for any reason in this context, it risks getting the wrong answer
[21:16] <juliank> OK, yes, then continue with this.
[21:18] <xnox> slangasek: to be honest, valac generates portable C code, so either build the shipped c code in the source package and ignore vala bits.
[21:19] <xnox> slangasek: or we need to teach valac to be cross-build friendly.
[21:19]  * xnox needs to dig into vala again, I stopped touching it @ around 0.10
[21:19] <slangasek> I'd prefer not to have to tell the world that they're doing vala wrong in their tarballs / source packages
[21:19] <juliank> You can even still build the vala code to C, that should be independent of which libglib2.0-dev is installed/used. Then the C compiler compiles the C code, using standard autotools mechanisms
[21:20] <juliank> In short: Vala should not care which glib2.0 is installed, as the C code it creates does not depend on the architecture.
[21:20] <xnox> slangasek: so valac should run as native, and then cross-compiler used to build it further.
[21:21]  * xnox ponders if that will require native libglib2.0-dev initially & :armhf later on.
[21:22] <juliank> You actually shouldn't really need a libglib2.0-dev to build .c files from .vala forom
[21:22] <robert_ancell> slangasek, hey. Is there an example I can do in raring?
[21:22] <xnox> awesome.
[21:22] <juliank> Vala still looks it up using pkg-config though, so it does not work.
[21:23] <juliank> That is, It does not need to perform a pkg-config lookup when only building .c code; but currently does (AFAIK)
[21:25] <slangasek> robert_ancell: well, I'm working with activity-log-manager; all its build-dependencies are cross-installable, *except* that valac-0.18 depends on libglib2.0-dev.  So it's hard to test this without first locally hacking the valac package
[21:25] <slangasek> robert_ancell: but, let me paste the output from valac for the sample:
[21:25] <slangasek> http://paste.ubuntu.com/1448544/
[21:25] <juliank> slangasek: Try to hack valac to not do pkg-config lookups when building .c files.
[21:26] <juliank> The pkg-config stuff is only needed when compiling the .c files to machine code anyway, so it should not be really required for building the .c files
=== sraue_ is now known as sraue
[21:27] <juliank> This should solve cross-building if the project uses autotools, as autotools will then use the correct libraries when compiling the C code to machine code.
[21:27] <robert_ancell> slangasek, does "valac -C sample1.vala" give the same error?
[21:27] <slangasek> robert_ancell: it does not
[21:27] <slangasek> robert_ancell: I just noticed that difference in the commandlines, myself
[21:27] <slangasek> do you think that justifies dropping the libglib2.0-dev dependency from valac?
[21:28] <slangasek> (possibly dropping it to a recommends?)
[21:28] <xnox> shouldn't valac call the correct arm-linux-gnueabihf-pkg-config instead then?
[21:29] <robert_ancell> slangasek, well, there's two ways of compiling, the compile to C option which is what everything uses, and the automatic compile which I guess is doing something weird
[21:29] <slangasek> xnox: that's not the question; the question is, can I drop the dep on libglib2.0-dev
[21:29] <slangasek> if it's dropped, there's not guaranteed to be *any* usable pkg-config present when valac is called
[21:30] <robert_ancell> slangasek, no, because in the "valac foo.vala" you can't compile a program
[21:30] <juliank> robert_ancell: There are still Recommends for that case, though
[21:30] <robert_ancell> because the generated C code uses glib functions and valac is going to have to compile it
[21:30] <slangasek> robert_ancell: right, but recommends are installed by default, so in the non-buildd case libglib2.0-dev will be installed anyway; wouldn't that be enough?
[21:31] <Laney> generating code without compiling it probably is a usecase worth supporting
[21:31] <slangasek> in the buildd case, I suspect packages have a separate build-dependency on glib2.0
[21:31] <robert_ancell> juliank, yeah, but it's going to be weird if valac fails to work (I haven't tried it)
[21:31] <juliank> slangasek: I'd verify that before dropping a Depends, though.
[21:31] <slangasek> yeah, I'm checking it now
[21:31] <juliank> robert_ancell: Well, I hope that valac prints a reasonable error message in such a case.
[21:31] <robert_ancell> slangasek, yes, I expect practically you can drop it as everything would depend on libglib2.0-dev directly or indirectly
[21:33] <juliank> Debian has multiple packages build-depending on vala, but not on libglib2.0-dev; I suspect the situation is the same in Ubuntu.
[21:34] <juliank> All of them seem to be GTK+ applications though, which means they indirectly pull libglib2.0-dev in.
=== henrix is now known as henrix_
[21:37] <slangasek> robert_ancell, juliank: in practice, there's only one package in Ubuntu that doesn't pull libglib2.0-dev by other means: radare2-bindings
[21:39] <slangasek> so given that for a cross-build, libglib2.0-dev:native is not the right package anyway, I think dropping this to a Recommends and adding a build-dep on radare2-bindings is reasonable.  Do you agree?
[21:40] <Laney> mbiebl: ^- do you have any opinion on the above? (lowering valac Depends on libglib2.0-dev to Recommends)
[21:43] <slangasek> valac-0.18 itself still invokes pkg-config directly, so if you're calling valac without -C it won't DTRT for cross builds
[21:43] <slangasek> but that's a secondary concern at the moment
[21:47] <robert_ancell> slangasek, is there a bug / solution for that problem?
[21:48] <slangasek> robert_ancell: sorry, which part?
[21:48] <slangasek> I haven't filed any bug reports anywhere yet
[21:48] <robert_ancell> slangasek, the DTRT for running without -V
[21:48] <robert_ancell> -C
[21:48] <robert_ancell> slangasek, I'd like to fix that if I can, but I don't know the solution
[21:49] <slangasek> robert_ancell: the solution is probably to honor $PKG_CONFIG in the environment and call it instead of pkg-config; I think that would be compatible with the autotools cross handling
[21:49] <robert_ancell> slangasek, is $PKG_CONFIG a standard or a new thing?
[21:50] <slangasek> robert_ancell: I'm not sure ;)  I know that it will be used as a make variable in the standard autotools setup, but I don't know if it will be exported to the valac process environment
[21:52] <slangasek> robert_ancell: basically, you get the same behavior for both $CC and $PKG_CONFIG; so if they're exported, then you're set, if they're not then we would have to fix that first
[21:53] <slangasek> robert_ancell: or, instead of using the exported variables, we could make this part of the valac automake rules
[21:54] <robert_ancell> slangasek, if you use automake you're going to be using the -C option anyway so it should work
[21:54] <slangasek> (valac --cc=$(CC) --pkg-config=$(PKG_CONFIG))
[21:54] <slangasek> ah
[21:54] <slangasek> in that case, I'd say just honor $PKG_CONFIG and if somebody's not using automake it's their problem to export it
[21:56] <robert_ancell> slangasek, ok, I'll write a patch and send you the link. I don't think it should be controversial but I might need you to note why pkg-config should be configurable
[21:56] <slangasek> robert_ancell: cheers :)
[22:05] <zykes-> anyone tell me what's in http://ubuntu.uib.no/archive/indices/ ?
[22:06] <robert_ancell> slangasek, does this look like what you need? http://paste.ubuntu.com/1448650/
[22:07] <robert_ancell> i.e. you can "valac --pkg-config=pkg-config-armhf foo.vala" or "PKG_CONFIG=pkg-config-armhf valac foo.vala"
[22:07] <slangasek> robert_ancell: yep, that looks about right to me
[22:10] <robert_ancell> slangasek, is arm-linux-gnueabihf-pkg-config the sort of name we'd expect for a cross-compiling pkg-config?
[22:10] <slangasek> robert_ancell: yes
[22:12] <robert_ancell> slangasek, https://bugzilla.gnome.org/show_bug.cgi?id=690456
[22:12] <ubottu> Gnome bug 690456 in general "Support configurable pkg-config so can cross-compile" [Normal,Unconfirmed]
=== schmidtm_ is now known as schmidtm
[23:05] <zykes-> is there a thing that can read the "content-<arch>" files ?
[23:07] <xnox> zykes-: apt-file ?
=== Tonio__ is now known as Tonio_aw
=== Tonio_aw is now known as Tonio__