[09:59] <Chipaca> Mirv: I assume you're not really here
[10:40] <Mirv> Chipaca: depends :)
[10:41] <Chipaca> Mirv: i'm looking for a silo :)
[10:41] <Chipaca> so i'm a silo seeker
[10:41] <Mirv> Chipaca: for which one, it looks the last one has already?
[10:41]  * Chipaca looks
[10:42] <Chipaca> *gasp*!
[10:42] <Chipaca> Mirv: I hadn't even looked; assumed i needed to ask :)
[10:42] <Chipaca> \o/
[10:42] <Mirv> Chipaca: hehe. problem solved, then :)
[10:43] <Chipaca> man, the double / in the url gets on my nerves.
[10:43] <Mirv> that's terrible, yes
[10:45] <Chipaca> Mirv: where's the code that drives this, do you know?
[10:45] <Chipaca> this == the integration between the spreadsheet and the build farm
[10:47] <Mirv> Chipaca: it's in the spreadsheet's "Script editor..." but probably needs some extra permissions
[10:47]  * Chipaca looks
[10:51] <Chipaca> it's in the metadata tab
[10:51] <Chipaca> Mirv: if you can edit the metadata tab, removing the ending / in B2 should fix the links
[10:52] <Chipaca> it's entirely possible the other ones on that tab need a similar fix, but I haven't looked :)
[10:53] <Mirv> Chipaca: fixed! I hope it's not so that something else assumes it's there, which is entirely possible
[10:54] <Chipaca> Mirv: I'll tell everybody you broke on purpose it if they ask
[10:54] <Mirv> thanks, much appreciated
[10:54]  * Mirv goes back to spring cleaning and sun bathing activities
[11:57] <mandel> ogra_, when is landing being resumed?
[12:10] <ogra_> mandel, for 14.04 tomorrow ... for th rest once the new distro exists
[12:11] <mandel> ogra_, ok, so I have no change of landing udm today :(
[12:11] <ogra_> isnt it a public holiday in spain too ?
[12:21] <mandel> ogra_, AFAIK it is not
[12:21] <ogra_> ah
[12:21] <mandel> ogra_, I have triple checked hehe
[12:21] <ogra_> heh, here it is
[12:22] <mandel> ogra_, oh, then.. go and do something!
[12:22] <ogra_> i am !
[12:22] <ogra_> :)
[12:22]  * ogra_ plays with his ebook reader app :)
[12:23] <mandel> ogra_, ahhh ok.. do you mindif I ask you a question, I flashed my device as follows: ubuntu-device-flash --channel trusty-proposed --revision 290 --bootstrap
[12:23] <mandel> ogra_, yet, when I try to check for a system image update I get that I'm up to date.. yet the last image in 301, right?
[12:24] <ogra_> depends on the device last is 301 for all supported ones
[12:24] <ogra_> we stopped building for grouper and maguro at some point ... maguro is at 188 ... grouper was somewhere in the 200s
[12:25] <mandel> ogra_, this is a mako
[12:25] <ogra_> supported devices should see an update though
[12:25] <mandel> ogra_, it should not be a problem, and If I do a device-flash without the revision number I get the correct one
[12:25] <mandel> ogra_, and udm has nothing to do with that check :)
[12:27] <mandel> ogra_, play with you eboor reader, I'll try to fix it
[12:27] <mandel> ogra_, also, add support for kindel books ;)
[12:27] <ogra_> haha, its a super simple thing that converts pdfs into a click package
[12:28] <ogra_> (effectiverly converting the pdf into a html doc that the app embeds in a webview)
[12:29] <ogra_> nothing i plan to reelease actually ... (well, i'll make it public for others, but nothing for the store since you need to run the conversion tool to create the click for a specific book)
[12:30] <mandel> ogra_, oh, well ok, no kindle for me in ubuntu-touch then hehe
[12:30] <ogra_> i wrote it mainly to scratch my own itch
[12:30] <mandel> ogra_, have we change anything in the system dbus activation front?
[12:30] <ogra_> you could convert to pdf and then use it :)
[12:30] <mandel> ogra_, udm works on the desktop yet not on the phone
[12:30] <ogra_> not that i konw of
[12:30] <mandel> ogra_, I'm tempted to do a webapp for kindle..
[12:31] <ogra_> (though i still suspect there is something wonky in dbus on the phone)
[12:31] <Chipaca> robru, cyphermox, rsalveti, sil2100, Mirv, didrocks, if any of you happen to be around, silo 8 is ready for landing :)
[12:31] <mandel> ogra_, weird.. I'm getting dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name com.canonical.applications.Downloader was not provided by any .service files
[12:31] <Chipaca> in other news, I'm going to have lunch
[12:31] <ogra_> mandel, as phablet user ?
[12:31] <mandel> ogra_, with sudo
[12:32] <mandel> ogra_, and /etc/dbus-1/system-services has com.canonical.applications.Downloader.service
[12:32] <mandel> ogra_, but it the online one.. weird...
[12:32] <ogra_> hmm, system bus then
[12:33] <ogra_> are yu making sure you query the system and not the session bus ?
[12:33] <mandel> ogra_, correct
[12:33] <mandel> ogra_, 100%
[12:33] <mandel> ogra_, the session one does work..
[12:33] <ogra_> hmm, then thats really weird
[12:33] <mandel> ogra_, don't worry, get back to your ebooks, I'll eat and will think about it
[12:33] <ogra_> unless there is polkit blocking something
[12:34] <Chipaca> mandel: lunch is always the right answer
[12:34] <ogra_> but that should likely return a different error
[13:00] <Chipaca> pmcgowan: issue that was driving load on phones has been worked around on the server; work around for the client is in a silo
[13:00] <Chipaca> pmcgowan: (wrt ubuntu push, this is)
[13:00] <Chipaca> pmcgowan: and good morning :)
[13:00] <pmcgowan> Chipaca, morning
[13:00] <pmcgowan> good stuff
[13:42] <plars> rsalveti: you around today?
[13:42] <plars> rsalveti: I built one of those serial cables for my nexus and I'm experimenting with it
[13:43] <plars> rsalveti: I tried it with image 274, and as we sorta figured, when reproducing that stuck boot bug that we had on that image, it doesn't get far enough to get a console
[13:44] <plars> rsalveti: other than the init conf to launch getty on that line once it's started, did you have any other ideas for how the serial cable might be used to get more control over the device?
[13:54] <mandel> ogra_, no worries, I have some ideas after lunch hehe
[13:55] <mandel> Chipaca, as you said ^
[14:30] <fginther> balloons, I encountered an error when testing the music-app trunk on a device. It looks like org.nemomobile.grilo is not part of the package: http://s-jenkins.ubuntu-ci:8080/job/generic-click-autopilot-runner-mako/96/testReport/music_app.tests.test_music/TestMainWindow/test_next_previous_with_touch_/
[14:31] <balloons> fginther, grilo hasn't been integrated into the build yet.. I'm not sure of the exact status.. it's supposed to change at some point but hasn't yet
[14:31] <balloons> do you want to pick a different app?
[14:33] <fginther> balloons, yes, any recommendations? calendar appears to get a lot of traffic
[14:33] <balloons> calendar has been going through a lot :-)
[14:36] <sergiusens> fginther: look at the click view for music app for the 'hack'
[14:37] <fginther> sergiusens, thanks
[15:11] <mandel> ogra_, fixed the issue :)
[15:13] <sergiusens> ogra_: are you on holidays today?
[15:22] <mandel> sergiusens, yes he is
[15:22] <mandel> sergiusens, or he should
[15:23] <mandel> sergiusens, can you pass me the url of the build?
[15:23] <sergiusens> mandel: you should know how to get to that by now ;-)
[15:24] <mandel> sergiusens, meh.. you are right, but is easier asking you hehe
[15:24] <sergiusens> mandel: step one https://wiki.ubuntu.com/citrain
[15:24] <mandel> sergiusens, I know how to find it, I'm just being laz
[15:24] <mandel> y
[15:24] <sergiusens> mandel: step 2, select silo 11
[15:25] <sergiusens> mandel: then look at Status
[15:26] <sergiusens> mandel: I'm going to be giving you the pedantic explanation ;-)
[15:26] <mandel> sergiusens, nooooooooooooo don't be a parent!
[15:28] <mandel> sergiusens, there is a failure with the given msg => WARNING A version (0.1+14.04.20140417-0ubuntu1) is available at the destination archive for that component but is not in the destination branch which is still at 0.1+14.04.20140410.1-0ubuntu1. You need to ensure that your version contains the fix in the destination or you can force rebuild to bypass the check.
[15:28] <mandel> sergiusens, which is for the click scope because nothing changed, can that be ignored?
[15:30] <sergiusens> mandel: I can do that, but are you sure that what's in the archive matches current trunk?
[15:31] <mandel> sergiusens, yes, or did https://ci-train.ubuntu.com/job/landing-011-1-build/23/console fail due to another reason?
[15:35] <sergiusens> mandel: from what it says; 0.1+14.04.20140417-0ubuntu1 is in the archive but not in trunk; so if you force rebuild; you may lose stuff that's in the archive; so I'll ask again; are you sure you want to force rebuild?
[15:37] <mandel> sergiusens, I just want to force a rebuild for umd, not for click scope. But I'm 100% sure that there si no diff between the click scope trunk and the branch we have
[15:37] <mandel> sergiusens, I just triple checked, so, yes, I'm sure
[15:37] <mandel> :)
[15:37] <sergiusens> ok, let me just rebuild udm, you weren't specific in the orig request ;-)
[15:38] <sergiusens> deploying will also probably fail if this failed; so keep that in mind to tell the train people
[15:39] <mandel> sergiusens, ok, will let them know, for now I just want to test in mako to ensure that I fixed the dbus activation bug
[15:45] <sergiusens> mandel: you probably need to change the commit message for this: https://code.launchpad.net/~mandel/unity-scope-click/rebuild-with-udm/+merge/214935
[15:45] <mandel> sergiusens, very good point, doing
[15:46] <mandel> sergiusens, done
[15:48] <sergiusens> mandel: https://ci-train.ubuntu.com/job/landing-011-1-build/24/console
[15:48]  * sergiusens goes for lunch
[15:48] <mandel> sergiusens, thx
[17:55] <balloons> sergiusens, do you have some time this afternoon to have a look at file manager. I remmeber you commenting on the merge dpm did to put the plugin inside the click package. However, the resulting click doesn't run on the device and complains of missing the plugin. Is there something simple we're missing?
[17:56] <sergiusens> balloons: my whole click chroot setup is a mess and any attempt to recreate it fails though, so I'll need to sort that out first
[17:57] <balloons> sergiusens, I've been there.. :-) No worries. Nothing off the top of your head that would cause the click to fail? The contents show the plugin, and it's in the right place
[17:57] <balloons> ^^ afaict
[17:57] <sergiusens> balloons: how does it fail?
[17:58] <balloons> https://bugs.launchpad.net/ubuntu-filemanager-app/+bug/1294301
[17:58] <balloons> sergiusens, basically it fails to launch the app, giving the feedback that it cannot find the folderlistmodel plugin
[17:59] <sergiusens> balloons: is it installed into the right location? inside lib/$arch ?
[17:59] <balloons> sergiusens, click contents show ./lib/arm-linux-gnueabihf/org/nemomobile/folderlistmodel/libfolderlistmodel.so
[18:00] <sergiusens> balloons: is the paths casing correct?
[18:00] <sergiusens> let's move to #ubuntu-touch, this is not related to ci
[18:01] <balloons> true, sry guys :-)
[18:10] <mandel> sergiusens, everything fixed in silo 11 omer added a comment in the spreadsheet that is not longer valid, can you change it or should we wait for him?
[18:12] <sergiusens> mandel: he should change it
[18:12] <mandel> sergiusens, ok, no problem then
[18:34] <josharenson> fginther, re our discussion last week: I've written a 'performance test' that depends on the deb package glmark2-es2-mir. Now that that's done, how do I go about getting that package/PPA added to the script that sets up the testing environments (at least on tablets)?
[18:36] <fginther> josharenson, I'll need to do that step. What's the PPA?
[18:37] <josharenson> Currently, the ppa is ppa:mir-team/staging
[18:48] <fginther> josharenson, do you have an MP with your changes ready to test?
[18:48] <josharenson> Yes
[18:48] <josharenson> fginther: getting link
[18:49] <josharenson> https://code.launchpad.net/~josharenson/mir/install_glmark2/+merge/216504
[18:49] <fginther> josharenson, I've made an initial branch for the test runner scripts: lp:~canonical-ci-engineering/+junk/mir-performance-tests-runner-touch, but it's missing the correct command line to initiate the test
[18:54] <josharenson> fginther: where is the $test_suites variable set?
[18:54] <fginther> josharenson, it's set within the jenkins job
[18:55] <fginther> that part needs a little cleanup, working on it now
[18:55] <josharenson> fginther, so is that the part that needs to be modified? Chris made it seem that if I followed a certain naming convention, they would just run
[18:59] <fginther> josharenson, I hadn't considered doing it quite like that, but yes, that should work.
[19:00] <josharenson> fginther, ... alright, does that mean the functionality is already in place?
[19:00] <fginther> josharenson, I should just be able to add the PPA and update the test suite list to include "test_glmark2-es2-mir"
[19:01] <fginther> josharenson, let me give this a try with your MP
[19:02] <josharenson> fginther, can you clarify how it runs test_glmark2-es2-mir? The MP generates an executable "mir_performance_tests" that runs that test case..
[19:03] <fginther> the jenkins job will run mir_performance_tests via phablet-test-run
[19:04] <josharenson> fginther, awesome, _should_ work just fine
[19:04] <fginther> josharenson, I've got a test started here: http://s-jenkins.ubuntu-ci:8080/job/mir-performance-tests-trusty-touch/
[19:04] <fginther> josharenson, it'll take some time for the build, the tests should run immediately after
[19:06] <josharenson> ok, the test generates a json file
[19:07] <josharenson> fginther, will that be part of the jenkins artifacts?
[19:08] <fginther> josharenson, we'll have to add that. phablet-test-run can copy artifacts, but it will need to be told what to look for in this case
[19:09] <josharenson> fginther, sure, its a constant, sensical filename


[15:54] <lborda> cjwatson, guys, Hi I was wondering if there is a way of loading OEMDRV drivers through preseed without using the USB method. looking at the hw-detect specifically the driver-injection-disk.sh it does not seem to support such method.
[15:55] <cjwatson> doesn't seem so
[15:55] <cjwatson> well, I mean, you can do anything with preseeding, but it would involve writing a script that does the same kinds of things that driver-injection-disk does
[15:57] <lborda> cjwatson, where should the drivers go during the install ? /var/cache/firmware ? I am looking specifically to solve this question: https://answers.launchpad.net/ubuntu-certification/+question/214703
[15:57] <lborda> but not using a usb key
[15:58] <cjwatson> /var/cache/firmware/ is if you want the .debs in question to be copied to the target
[15:58] <cjwatson> udpkg --unpack  to install them into the installer environment
[15:58] <cjwatson> you'd basically want to mimic the install_driver_pkg function, which is simple enough
[15:59] <lborda> cjwatson, thanks I will take a look at it...
[16:00] <lborda> cjwatson, it looks like an interesting feature to be added to the hw-detect pkg
[16:00] <lborda> cjwatson,  and be able to specify through a d-i option
[16:12] <xnox> lborda: alternative to usb key, i thought one can build/fetch drop custom bits into a known location during d-i run, thus could be preseeded with early script to do wget the right udebs/debs into known location. OEMDRV doesn't do much, but copy the udebs & debs into known locations.
[16:16] <lborda> xnox, yeah that would be neat. actually according to the driver-injectin-disk code we could preseed in the early command and drop the files into $dir/*.deb $dir/*.udeb $dir/*.udeb into /var/cache/firmware
[16:17] <lborda> xnox, will this also make debian-installer aware of the drivers and load the modules ?
[16:17] <lborda> xnox, ie: disk drivers
[16:20] <xnox> lborda: it should, but check that it works, it may need another "anna" preseed to fetch/use driver-inject-disk udeb and depending on the release also will need a preseed to enable-use driver-inject-disk.
[16:21] <xnox> lborda: well there is no "disk", but to hit the codepath where udebs are enable drivers for the installer, and debs are installed into target to boot later.
[16:21] <xnox> s/are enable/are installed to enable/


 Don't know what you're talking about.
[13:17] <azend|vps> Fre3Bear: http://mashable.com/2014/02/20/wikibear
[13:17] <azend|vps> http://teamcoco.com/category/tags/wikibear
[13:19] <Fre3Bear> I am afraid.
[13:20] <azend|vps> the conan videos are what makes it funny


[02:16] <lump_> hello all
[02:47] <SonikkuAmerica> (Make sure "Xubuntu session" is selected, then) Log in.
[09:12] <mark___> hi , may i get some help here
[09:26] <mark___> helllllooooooo is anybody here ?
[15:17] <lumpy> hello all
[15:17] <lumpy> and merry christmas
[15:18] <lumpy> how have you all been?
[15:29] <SonikkuAmerica> funkyHat_: Fix your connection...
[15:29] <SonikkuAmerica> ?


 :-D
[07:12] <jml> dholbach, last week of January, right? I'll be in the UK that week.
[07:12] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the preliminary schedule
[07:12] <jml> dholbach, I was just about to ask :)
[07:12] <dholbach> jml: acpi-support is in debian too
[07:13] <jml> I'm trying to find the upstream vcs for it.
[07:13] <dholbach> let me see
[07:13] <jml> dholbach, I can do the Friday 1800 slot.
[07:13] <dholbach> wow, it's even in sync with debian in lucid
[07:14] <dholbach> jml: which topic? lplib? :)
[07:14] <jml> dholbach, I can do lplib. I could also do an "Ask Launchpad" session
[07:14] <jml> dholbach, whichever you think would be more interesting.
[07:14] <dholbach> jml: which one would you prefer?
[07:15] <jml> dholbach, I have no preference.
[07:15] <jml> wow, it's going to be exciting being able to actually attend some of these sessions :)
[07:16] <jml> dholbach, probably lplib is best.
[07:16] <jml> dholbach, keep it concrete & code-y
[07:16] <dholbach> hum, it could be that we're "upstream" for acpi-support
[07:17] <dholbach> it's a bit of a weird divergence
[07:17] <dholbach> slangasek might know more
[07:17] <dholbach> the debian/copyright of the debian source package says something like "It was downloaded from http://archive.ubuntu.com/....."
[07:18] <dholbach> jml: shall I pencil you in? session title? :)
[07:19]  * jml tries to think of a clever title that doesn't violate the CoC
[07:19] <dholbach> haha
[07:19]  * dholbach hugs jml
[07:20] <jml> I'm all out of clever. How about "Meet launchpadlib"?
[07:21] <StevenK> "launchpadlib and you: Making access to Launchpad easier" ?
[07:21] <dholbach> sounds good to me :)
[07:22] <jml> I'm just going to make lp:~ubuntu-core-dev/acpi-support/trunk the dev focus for acpi-support. slangasek can correct me if I'm wrong.
[07:22] <dholbach> jml: sounds good to me
[07:23] <dholbach> jml: thanks a bunch for helping out with UDW :)
[07:23] <jml> dholbach, my pleasure.
[07:23] <dholbach> we have a fantastic line-up this time
[07:23] <dholbach> I mean we always do :)
[07:24] <jml> dholbach, yeah. I'm looking forward to heckling at rockstar's talk :)
[07:24] <dholbach> haha
[07:25] <jml> Ng, hello.
[07:25] <jml> Ng, could I persuade you to set the development focus branch for https://code.edge.launchpad.net/evdev ?
[07:26] <dholbach> who can I interest in another UDW session? there's still 4 open slots!
[07:26] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep
[07:31] <slangasek> jml: that should work
[07:31] <jml> slangasek, thanks.
[07:32]  * jml is doing a little mindless data gardening
[07:35] <wgrant> Can I convince somebody to sync something like jack-tools? 3.0 support works now, and I'd like to see that syncing actually works.
[07:36] <wgrant> (jack-tools has all the things that are likely to trip Soyuz up, and it has no real changes, so it seems like a good test)
[07:38] <slangasek> wgrant: I synced one already
[07:38] <slangasek> (abraca, now in dep-wait)
[07:38] <wgrant> slangasek: But it at least hit the buildds? Good.
[07:39] <slangasek> yep
[07:40] <slangasek> thanks for all your help to get v3 happening :)
[07:40] <wgrant> np
[07:40] <wgrant> Sorry it took so long.
[08:08] <junjun> hi
[08:09] <junjun> i get the source of 9.10 kernel, and found that Ubuntu patches the vanilla kernel. where can i find the information on the patch?
[08:09] <junjun> i want to know which change Ubuntu made to the vanilla kernel
[08:09] <junjun> the patch to 2.6.31 is pretty big.
[08:10] <junjun> except AppArmor, and ndiswrapper, what else Ubuntu change to the kernel?
[08:13] <dholbach> junjun: try asking in #ubuntu-kernel (and maybe wait a bit, the folks might still be asleep :-))
[08:13] <junjun> dholbach: thanks!
[08:14] <pitti> Good morning
[08:16] <pitti> slangasek: right, I think there should be an extra field in the workitems table eventually; but oh well, kees already fixed it for now
[08:21] <junjun> from Ubuntu 9.10, we patch kernel with Non-Exec stack patch. Is that exactly the patch named Exec-Shield from Redhat?
[08:21] <junjun> if not, what is the difference with Redhat's Exec-shield??
[08:24] <junjun> oh well, it seems Ubuntu uses the patch from Redhat (Fedora)
[08:25] <kees> junjun: "execshield" is the entire unbrella project that Redhat put all their hardening features under.
[08:25] <kees> junjun: Ubuntu's kernel carries the last remaining piece of that which is not already upstream, the partial nx-emulation for i386
[08:25] <junjun> kees: so you mean we only port the kernel patch to Ubuntu, but not the rest?
[08:25] <kees> junjun: everything else already in the kernel, userspace, etc.
[08:26] <kees> junjun: some details here: https://wiki.ubuntu.com/Security/Features
[08:26] <junjun> it is interesting to know, thanks
[08:26] <kees> sure, np
[08:26] <junjun> so far, it seems only kernel of Fedora (and Redhat, CentOS) and Ubuntu uses this patch.
[08:27] <kees> junjun: afaik, SUSE uses it as well, but I haven't personally verified it.
[08:27] <junjun> the rest like OpenSuse, Debian, .... dont. is that correct?
[08:27] <kees> Debian does not use it, correct.  I'm unsure about SUSE
[08:27] <junjun> kees: ok, i will check that
[08:28] <kees> junjun: as linked from https://wiki.ubuntu.com/Security/Features#Non-Exec%20Memory I have a simple regression test that can help validate a given kernel.
[08:29] <kees> junjun: the patch itself is here: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commitdiff;h=eb56f42a4bc9c671a19dcf8fd36eb3f341de7dfa
[08:30] <kees> it's based on the bits from http://www.codemonkey.org.uk/projects/execshield/
[08:32] <junjun> kees: very clear, thanks!
[08:33] <junjun> kees: why this patch doesnt work for 64bit kernel??
[08:33] <kees> junjun: the cs-limit approach doesn't make sense for 64bit, and nearly all 64bit system already implement non-exec in hardware, so the emulation is unneeded.
[08:34] <junjun> what do you mean by "cs-limit approach doesn't make sense"??
[08:35] <kees> the partial nx-emulation patch uses the cs segment limit to split userspace into two region (one executable, the other not).  as I understand it, there's no reason to do this for 64bit, since 64bit is PAE, which implements the NX bit in the page table, so no artificial separation is needed.
[08:41] <tseliot> pitti: shall I make nvidia depend on acpid and acpi-support or would the former suffice?
[08:41] <pitti> tseliot: just acpid, please
[08:41] <pitti> acpi-support is unrelated to what nvidia does, and is still on the "to die" list
[08:42] <tseliot> pitti: ok, the latter seemed too much as a dependency to me but I wanted to be sure
[08:45] <fabbione> zul: ping? is there a bacula 3.0.X backport for hardy anywhere?
[09:02] <tkamppeter> pitti, can you upload Poppler for me, debdiff on bug 293832? Thanks.
[09:24] <pitti> tkamppeter: hi! sure
[09:25] <pitti> tkamppeter: should the other tasks be "invalid"ated then?
[09:26] <Ng> jml: hey, is that still required?
[09:26] <tkamppeter> pitti, I think so.
[09:26] <pitti> tkamppeter: uploaded
[09:26] <Ng> jml: well, I suppose I can see that there's no focus set, so I suppose a better question would be what would you like it set to? ;)
[09:28] <tkamppeter> pitti, the non-Poppler tasks are invalidated now, thanks for uploading.
[09:28] <pitti> ogra: bryce_ wrote a basic test plan for touch screens to check that the udevification didn't break anything (https://wiki.ubuntu.com/X/Testing/Touchscreen); does that look reasonable to you, or is there something important that should be added there?
[09:50] <mdz> Ng: re: the mkinitramfs error, 17-12-2009 11:30:21 <<EMAIL_ADDRESS>mdz: yes, Keybuk said he was going to fix that today
[09:51] <Ng> ah, sorry
[10:24] <StevenK> pitti: What was the magical gvfs-mount option again?
[10:24] <pitti> StevenK: for doing what?
[10:25] <StevenK> pitti: A USB key I just inserted is not automounting
[10:28] <pitti> StevenK: so you want to mount it manually? gvfs-mount -d /dev/foo
[10:28] <StevenK> steven@liquified:~% gvfs-mount -d /dev/sdb
[10:28] <StevenK> No volume for device file /dev/sdb
[10:30] <pitti> so gvfs-mount -li doesn't have /dev/sdb then?
[10:30] <pitti> does devkit-disks --mount /dev/sdb work?
[10:31] <StevenK> pitti: No, gvfs-mount -li does not have sdb
[10:31] <StevenK> devkit-disks ... does work, though
[10:34] <pitti> StevenK: does gvfs-mount -oi say anything when you plug this in?
[10:35] <StevenK> pitti: Yes, and it actually mounted it this time.
[10:35]  * StevenK curses heisenbugs
[10:50] <pitti> free: can you please make bug 455217 public, so that it can be SRU-processed?
[10:51] <free> pitti: oops, sorry, just made it pubblic, thanks
[10:51] <pitti> free: and please make sure that all the fixed bugs have proper ubuntu package tasks
[10:52] <free> pitti: I think I'm not entitled to create tasks? or how do I?
[10:52] <free> pitti: I couldn't figure out how to do it last time
[10:52] <pitti> free: "Also affects distribution" -> ubuntu/landscape-client
[10:52] <free> pitti: okay, on all the bugs related to the SRU?
[10:52] <pitti> right
[10:53] <pitti> we need to track their fixes/status in all releases
[10:53] <pitti> I started adding them
[10:54] <free> okay
[10:55] <pitti> all added now, I think
[10:55] <pitti> free: would you mind reviewing the bugs and closing the lucid tasks which are already fixed?
[10:56] <free> pitti: sure
[10:56] <pitti> thanks
[11:06] <free> pitti: I guess I can use "Fix released" for lucid tasks right?
[11:06] <pitti> free: if they are fixed in lucid, yes
[11:06] <free> pitti: okay, so that's done
[11:07] <pitti> cheers
[11:07] <free> pitti: there a now bugs that have the Lucid task with fix-released, and bugs that have a new Ubuntu task (no release-specifc tasks yet)
[11:08] <free> pitti: so, I don't think I can open release-specifc tasks, can I?
[11:08] <pitti> free: you can nominate
[11:08] <free> pitti: what does that mean exactly?
[11:09] <pitti> free: the tasks won't be created yet, but they will shown as "proposed for jaunty-update", etc.
[11:09] <pitti> I'll accept them while reviewing
[11:09] <free> okay
[11:12] <free> pitti: I can't figure out how to nominate, I can't see any "nominate" or similar button in the bug page UI..
[11:12] <pitti> free: "Target to release"
[11:12] <pitti> (with the ubuntu task selected, not the upstream task)
[11:17] <free> pitti: and how do you select the Ubuntu task? clicking on it just brings me to the landscape-client source page in the ubuntu LP project
[11:18] <pitti> free: hm; just change the URL to /ubuntu/+source/landscape-client/... ?
[11:19] <pitti> or change anything else in the ubuntu task
[11:19] <pitti> like priority, assignee, etc.
[11:22] <free> pitti: okay, manually entering the url like you suggest works, but changing something the ubuntu task doesn't, I couldn't find any way to do it except manually entering the url
[11:26] <free> pitti: okay, the bugs without specific release tasks should be all nominated now (for intrepid to lucid)
[12:00] <pitti> free: can bug 455217 be fixed in lucid, too?
[12:01] <free> pitti: yes
[12:02] <free> pitti: just marked it as Fix released
[12:02] <pitti> great
[13:16] <zul> fabbione: no there isnt a backport
[13:16] <fabbione> zul: thanks, I have done myself
[13:16] <zul> fabbione: cool
[13:16] <fabbione> zul: you might want to take care of Lucid release notes for upgrading tho
[13:17] <fabbione> zul: you need to have a director > 3.0 to talk to fd > 3.0
[13:17] <fabbione> zul: dir 3.0 can talk to fd in any version but not the other way around
[13:17] <zul> fabbione: thanks for the heads up
[13:17] <fabbione> zul: so basically, if you want LTS to LTS upgrade plan, the director machine needs to be done first
[13:18] <zul> gotcha
[13:46] <zul> james_w: did the import failed for samba i dont see it in launchpad?
[13:47] <james_w> zul: it was stuck in the queue, I've set it to run next
[13:48] <zul> james_w: thanks
[14:06] <Keybuk> mdz, Ng: it was stuck in NEW :p
[14:27] <Chipzz> http://www.advogato.org/person/robertc/diary.html?start=129
[14:27] <Chipzz> this gets a major ++ from me
[14:27] <Chipzz> I would hope this mentality would propagate to more debian and ubuntu developers
[14:31] <joaopinto_> I really don't see the relation between upstreams doing their own packaging, and including the debian/* in the upstream source
[14:32] <joaopinto_> I agree with the first, not with the second
[14:32] <james_w> why?
[14:33] <joaopinto_> because debian/* use dependencies or rules some times tweeaked for specific distros/releases
[14:33] <joaopinto_> there is no advantage on having them including on the source, there is the advantage that other packagers will need to patch or rm the upstream debian/*
[14:34] <joaopinto_> ops, disadvantage
[14:35] <joaopinto_> upstreams doing the packaging is a social subject, including debian/* in the source is a technical one
[14:36] <james_w> upstream sometimes has code that doesn't work on Ubuntu, so there is a disadvantage that we sometimes need to patch it, so upstream shouldn't ship any code
[14:38] <joaopinto_> james_w, source code is generic, as far as possible, debian/rules are not, and you failed ot mention what at the advantages of having it include on the source :)
[14:38] <joaopinto_> ops, I meant debian/*
[14:38] <james_w> debian/* are generally, otherwise we wouldn't be able to derive from Debian without making vastly more changes than we do
[14:40] <Ng> joaopinto_: I like it when I unpack a tarball of some new software and I can just build a package out of it immediately. That's why I include a debian/ in my projects :)
[14:40] <ScottK> Is Google Talk audio supposed to be working with Empathy in Karmic?
[14:40] <ScottK> Ng: The problem is most upstreams that attempt to do this, don't know a lot about Debian packaging.
[14:41] <james_w> ScottK: I don't see that as a reason to tell every single upstream that does it off, as seems to be the culture currently
[14:41] <joaopinto_> james_w, you are refering to the general case of Debian versus Ubuntu, the debian/* world does not stop there, and still, your sentence is not accurate when you need to backport
[14:41] <Ng> ScottK: I would absolutely fit in that pot, which is why I merge back in the correctness from nxvl's packaging :)
[14:42] <joaopinto_> Ng, if you want your projects just to build, provide a .dsc file
[14:43] <joaopinto_> Ng, you will help those which "just want to build" per your rules, without interfering with others that want to build in another way
[14:43] <Ng> joaopinto_: I don't follow, how does a .dsc help?
[14:43] <james_w> for a .dsc file to make any sense you have to have a debian directory, no?
[14:43] <joaopinto_> Ng, dget file.dsc && debuild
[14:44] <joaopinto_> no, you just need the .dsc, diff, and orig
[14:44] <joaopinto_> and everone is happy with a single dget command, versus a wget source
[14:44] <StevenK> joaopinto_: Which you can't build without a debian directory in the source
[14:45] <joaopinto_> StevenK, you can, because I am refering to a .dsc which points to both the orig.tar.gz and the debian diff
[14:46] <StevenK> joaopinto_: And what do you think is in the debian diff? The debian directory.
[14:46] <joaopinto_> StevenK, right, but provided as it should as a diff, not included on the original source
[14:47] <james_w> joaopinto_: so you refuse to let us re-use and collaborate on that debian/ directory in the most natural way, as we do the rest of the code?
[14:47] <james_w> no thanks
[14:48] <joaopinto_> james_w, no, but I don't agree that the proper place for packaging collaboration is the source, you do collaboration for a group at the cost of other group
[14:48] <ScottK> Another issue is that improvements to Debian packaging need a new upstream release if that's the canonical source for them.
[14:48] <james_w> it's not a cost that means much
[14:49] <james_w> it doesn't have to be the canonical source, or diff.gz can make modifications
[14:49] <Ng> how much variation is there in the packaging of debian derivatives? talk of costs without numbers seems a bit pointless
[14:49] <joaopinto_> james_w, ah ok, so you assume that your need for collaboration is more important than others needs for a clean source :)
[14:49] <james_w> improvements to the code don't need a new upstream release, we are generally happy to patch and feed the changes back for the next release
[14:49] <joaopinto_> that's something personal, nothing to argue about :)
[14:52] <joaopinto_> james_w,  upstreams should be able to collaborate if the debian/* dir is kept in any VCS
[14:55] <Keybuk> huh?
[14:55] <Keybuk> upstream should never put the debian/ directory into their VCS
[14:55] <Keybuk> that's just wrong
[14:56] <joaopinto_> the only good reason I see on this change would be, "Hey you cand build .debs from the source", when there is no one able to set up a PPA or get it into the repositories
[14:56] <Keybuk> anyone can have a PPA
[14:56] <joaopinto_> but again, that is not collaboration :)
[14:56] <joaopinto_> Keybuk, we are debating that http://www.advogato.org/person/robertc/diary.html?start=129
[14:57] <Keybuk> there's no loop or step to getting one, just create a Launchpad account
[14:57] <Keybuk> I disagree strongly with Robert ;)
[14:57] <Keybuk> one of the biggest problems I ever have, as a distribution maintainer, is upstreams who put the packaging into their tarball
[14:57] <Keybuk> because it's always wrong
[14:57] <Keybuk> and it makes it very hard for us to modify it
[14:58] <jcastro> it should just be another branch imo
[14:58] <Keybuk> in certain ways, for example removing a debhelper config file, it becomes impossible to modify without repackaging the software entirely
[14:58] <jcastro> like how we're doing for UDD
[14:58] <joaopinto_> Keybuk, that was the pointing I was making
[14:58] <Keybuk> (because our source package format doesn't permit removing files in the diff.gz)
[14:58] <james_w> Keybuk: to be fair, Rob says we should fix that.
[14:59] <Keybuk> you also end up the situation where it looks like it's got a package
[14:59] <Keybuk> but the package is wrong
[14:59] <Keybuk> so people think they can grab the upstream tarball
[14:59] <Keybuk> build it
[14:59] <Keybuk> and then install it on their distribution
[14:59] <Keybuk> that could go *badly* wrong
[15:00] <Keybuk> look at the .spec file issues between SuSE and RedHat for an example ;)
[15:02] <LaserJock> hmm, so what happens if upstream has a debian/ but Debian, Ubuntu, <any old .deb-based distro> wants to package in different ways?
[15:03] <LaserJock> does the upstream need to pick which distro to support? or do they use something like control.in?
[15:04] <Keybuk> LaserJock: it gets more fun
[15:04] <Keybuk> upstream might disagree with the way distributions change their packages
[15:04] <Keybuk> and deliberately make it hard for distributions
[15:04] <Keybuk> (this happens)
[15:11] <Ng> Keybuk: why are you packaging things in isolation from the upstream? if their debian/ is wrong they must care enough to have one, so presumably want a correct one?
[15:12] <Keybuk> Ng: it means they want one they *think* is correct
[15:12] <Keybuk> that's so far removed from "a correct one" that they may as well be in different universes
[15:13] <Ng> Keybuk: I think they want one that produces a working package
[15:13] <Keybuk> see, that's the problem
[15:13] <Keybuk> let me give you an example
[15:13] <ScottK> Ng: Which is a small subset of what it takes to be correct.
[15:13] <Keybuk> I have an upstream, who we'll call Ted
[15:13] <Keybuk> he maintains a piece of software, which we'll call e2fsprogs
[15:13] <Keybuk> and he also happens to put the entire debian/ directory in his package
[15:14] <Ng> Ted sounds like he cares about his users!
[15:14] <Keybuk> tricks that Ted has done in the past include adding code to his debian/rules to disable features on Ubuntu
[15:14] <Keybuk> because he thought that Ubuntu was doing things wrong
[15:14] <Keybuk> turned out that was a bug in his kernel code he was hiding
[15:14] <Keybuk> the only reason he was getting bug reports from Ubuntu users is because we have lots of users
[15:15] <Ng> so to avoid fixing a kernel bug we just take the packaging away from him?
[15:15] <Keybuk> Ted has deliberately blocked library transitions
[15:15] <Keybuk> etc.
[15:15] <Keybuk> no
[15:15] <Keybuk> I'm saying that in the released upstream tarball is the wrong place for packaging
[15:15] <Keybuk> for a start, what's right for Debian might not be right for Ubuntu
[15:15] <Keybuk> even though the packaging files are the same)
[15:15] <Keybuk> I think the right way is what we do on Upstart
[15:15] <Keybuk> we have a tarball we release without packaging
[15:16] <Keybuk> then an upstream branch which is the tarball + packaging
[15:16] <Keybuk> and we collaborate on that
[15:16] <Ng> I'd concede plumbing stuff, but I like being able to grab a tarball or vcs checkout of some application and have it be ready to build
[15:16] <Keybuk> if distros need their own tweaks, they branch off it
[15:16] <james_w> so one person spoils it for the rest of us?
[15:16] <Keybuk> Ng: build for Ubuntu or build for Debian?
[15:16] <Keybuk> or build for SuSE or build for RedHat?
[15:16] <Keybuk> if you build something for Ubuntu, it might not work on Debian
[15:16] <Keybuk> and vice-vera
[15:16] <james_w> plus, the same arguments can apply for code, though admittedly less often
[15:17] <Keybuk> james_w: one of the major portions of packaging is patches to the code
[15:17] <Keybuk> that's kinda the point
[15:17] <Keybuk> here's a better question for you
[15:17] <Keybuk> why do we have packaging at all?
[15:17] <Keybuk> if the upstream tarball is perfect as-is
[15:17] <Keybuk> why do we *need* a debian directory in it?
[15:17] <Keybuk> why can't we automate the process of taking an autoconfery tarball and turning it into debs?
[15:17] <Keybuk> packaging is all about hacks to the code
[15:18] <Keybuk> packaging is changing the code to fit the distribution
[15:18] <Keybuk> or changing the default configuration of the code or result
[15:18] <Keybuk> changing install paths
[15:18] <Keybuk> removing files we don't want
[15:18] <Keybuk> adding ones that aren't incldued
[15:18] <Keybuk> etc.
[15:18] <Keybuk> if the upstream tarball is correct
[15:18] <Keybuk> (which it often is in a large majority of the cases)
[15:18] <Keybuk> you don't need packaging
[15:19] <Keybuk> this is probably the primary reason I don't like packaging-in-upstream
[15:19] <james_w> aside from the issue of autoconf/setup.py/Makefile.PL etc., yes
[15:19] <Keybuk> you end up with a qmail-esque bizarre situation where you have "the upstream code", and "the upstream approved patches to the code"
[15:19] <james_w> it strikes me you should write all this in a blog post and propose your preferred way instead
[15:20] <Keybuk> we discussed this in autotools a while back
[15:20] <Keybuk> the only bit you're really missing is knowing which files are libraries, which are headers, which are data, which are docs, etc.
[15:20] <Keybuk> a lot of that can be guessed by path
[15:20] <Keybuk> but you kinda want a manifest-like file that hints to a packaging system
[15:21] <Keybuk> you also want a standard format file for things like source descriptions, licencing, etc.
[15:24] <LaserJock> hmm, maybe you would want all that in a directory, maybe you could call it debian/ or something ;-)
[15:25] <Keybuk> LaserJock: the idea is that it'd be useful for everyone
[15:25] <Keybuk> and the debian formats are ... bizarre
[15:25] <Keybuk> like, why the hell would an upstream want to have a separate changelog?
[15:25] <Keybuk> their version number is already in configure.ac
[15:25] <Keybuk> unfortunately the discussion kinda veered towards "looks a lot like a .spec file" <g>
[15:25] <LaserJock> heh
[15:26] <LaserJock> the problem I see mostly though is upstreams either 1) don't want to package at all or 2) don't want to package for several different distros
[15:27] <ScottK> Or don't want to deal with distros at all and just have their users get packages from them
[15:27] <LaserJock> yes
[15:29] <ScottK> One of my upstreams (who uses Fedora) didn't see the point of getting his stuff into distros.
[15:29] <ScottK> I got one of his packages into Debian/Ubuntu and he mentioned he'd gotten a lot of new users show up right after I did that on his mailing list.
[15:29] <ScottK> Suddenly he got it and he packages his stuff for Fedora now.
[15:30] <ion> Had he been tuomov, he’d have hated you for getting new users.
[15:30] <Ng> popcon numbers can sometimes make a good impression :)
[15:31] <LaserJock> must upstreams I know just don't have time to learn .specs and debian/ etc.
[15:31] <LaserJock> *most
[15:32] <ScottK> This guy was distributing rpms already, he just hadn't seen the point in going to the trouble to get it in a distro.
[15:33] <LaserJock> and then there are upstreams that fork dependencies in PPAs and call it good ;-)
[15:34] <jam> barry: ping
[15:34] <jam> you sent a mail as<EMAIL_ADDRESS>that got blocked going to udd
[15:34] <jam> did you want me to add that address?
[15:35] <barry> jam: dang.  yes please!
[15:36] <jam> hmm.. it says the sender is "now" a member of the list already
[15:36] <jam> so apparently it should just work now
[15:36] <jam> I know I have a few accounts that get a bit confused sometimes
[15:36] <barry> weird, maybe it got held for other reasons
[15:36] <Keybuk> if upstreams did their job properly, we wouldn't _need_ distros ;-)
[15:36] <jam> I'm pretty sure it thought you weren't a member for a bit
[15:37] <jam> barry: ahh, I see why now
[15:37] <jam> Reason:  SpamAssassin identified this message as possible spam (score 3.8)
[15:38] <barry> ouch.  i should use fewer ! and $
[15:38] <jam> barry: though the message that got through was: X-Spam-Status: No, score=-2.2 required=4.5 tests=ALL_TRUSTED,AWL,BAYES_00, 	DATE_IN_PAST_03_06,MIME_BASE64_NO_NAME,MIME_BASE64_TEXT autolearn=ham  	version=3.1.7
[15:38] <jam> had you posted to udd before?
[15:39] <jam> As it looks like SQLGrey may have also been involved
[15:39] <barry> jam: yep, lots
[15:39] <jam> (I'm pretty sure you have)
[15:39] <jam> oh, and that sqlgrey stuff may be my local machine, not canonicals
[15:40] <jam> yeah, it probably is
[15:40] <LaserJock> was barry trying to sell us on the "effects" bzr can have on our personal life? ;-)
[15:40] <jam> apparently my mail host likes you
[15:40] <jam> but canonical's doesn't :)
[15:41] <jam> barry: so my guess is that SA doesn't like "date in past"
[15:41] <jam> since it seems to think that it was sent at 4am
[15:41] <jam> and then the fact that your mail client encodes everything as base64
[15:41]  * barry restarts ntpd
[15:41] <jam> even though it is just text
[15:41]  * persia reads backscroll and yet again wishes that `gzcat foo.diff.gz | patch` was capable of deleting files
[15:41] <Keybuk> persia: it is
[15:42] <Keybuk> Ian Jackson just disagreed with being able to do it, so had dpkg refuse to do so
[15:42] <barry> jam: i'm posting from a vm and when the host sleeps, my time gets out of whack.  unfortunately, that also seems to kill the ntpd service for some reason :(
[15:43] <Keybuk> persia: I think the reason dpkg refuses is quite logical
[15:43] <Keybuk> people might think that patching a file out of the tarball is an acceptable way to solve DFSG issues
[15:43] <Keybuk> when, of course, it isn't
[15:44] <persia> That's all!
[15:44] <Keybuk> because Debian would still have been distributing the file in the tarball
[15:44] <maco> arent you sposed to do that in the orig?
[15:44] <Keybuk> of course, nobody believed people would ever put debian directories in the tarball ;)
[15:45] <persia> I agree that it's not an acceptable way to make something DFSG-free (the tarball is shipped anyway), but it would mean that suddenly it wouldn't *matter* if upstream ships packaging (debhelpers -i helps to some degree, but only to some degree)
[15:45] <Keybuk> it still makes your life hard
[15:45] <Keybuk> you'd have to review every new upstream version carefully
[15:45] <persia> Can we revisit that, or is that reviving horses that are best forgotten?
[15:45] <Keybuk> "grr, upstream added a debian/wibble.foo file that I missed, and now my package fails to install"
[15:46] <Keybuk> if we were to revisit anything basic like that, we should probably just invent a new source package format
[15:46] <persia> Yeah, but one should be at least reviewing the file listing and dpkg --contents listings anyway, at an absolute minimum.
[15:46] <Keybuk> put it in an ubuntu/ directory
[15:46] <Keybuk> and then be done ;)
[15:46] <persia> Hrm.  tempting....   but maybe not.
[15:47] <Keybuk> if Colin ever gets hit by a bus, it'll be one of my first jobs ;)
[15:47] <Keybuk> Mark's been wanting to do that since day one, so I know I'll be allowed <g>
[15:48]  * pitti tosses http://cdimage.ubuntu.com/daily-live/20091218.1/ Keybukwards
[15:48] <Keybuk> pitti: way ahead of you ;) already rsync'd down and updating TFTP and NFS roots
[15:49] <Keybuk> will be interesting to see how this works
[15:49] <Keybuk> I got good numbers on ratchet
[15:49] <Keybuk> and I'm getting increasingly convinced that ratchet is slightly slower than max
[15:49] <pitti> good luck!
[15:51] <james_w> what's new in this image?
[15:51] <pitti> james_w: Keybuk's speedup work from today
[15:51] <pitti> (initramfs-tools, etc.)
[15:51] <Keybuk> well, last night
[15:51] <Keybuk> mostly initramfs-tools
[15:52] <james_w> the tsort stuff?
[15:52] <ion> How about devtmpfs?
[15:52] <Keybuk> no, that was in 18
[15:52] <Keybuk> I replaced all of the scripts/local loop with a tiny binary
[15:52] <Keybuk> that uses libudev to do what all that shell was trying to do *properly*
[15:52] <james_w> cool
[15:52] <Keybuk> ie. if the device doesn't exist, use netlink to wait for udev to finish with it
[15:52] <Keybuk> if the device exists, and is in udev's queue, also use netlink
[15:53] <Keybuk> if the device exists, and is not in udev's queue, done
[15:53] <Keybuk> also obviously outputs the filesystem type as udev knows it, so we don't have to separately probe fstype/blkid in the initramfs
[15:54] <Keybuk> one major advantage speed-wise is that it never calls "settle"
[15:54] <Keybuk> which means you can mount the root fs in the initramfs while loading of irrelevant modules is still happening
[15:54] <pitti> update-initramfs: Generating /boot/initrd.img-2.6.32-8-generic
[15:54] <pitti> .: 4: Can't open /scripts/functions
[15:54] <pitti> Keybuk: ^ known?
[15:55] <Keybuk> pitti: no, can you check through scripts/*/* and see which sources /scripts/functions *before* checking for "prereqs"
[15:56] <pitti> ./local-top/cryptroot
[15:56] <pitti> so, from cryptsetup
[15:56] <Keybuk> pitti: fix is obvious, don't source /scripts/functions until after the prereqs case
[15:56] <Keybuk> can you do that one while you're there?
[15:57]  * Keybuk has an allergy to cryptsetup
[15:57] <pitti> hm, I moved it down, now it says
[15:57] <pitti> [: 22: Private: unexpected operator
[15:57]  * pitti sighs
[15:57] <Keybuk> pitti: pastebin the script?
[15:58] <pitti> Keybuk: I'll try to squeeze it in (release meeting now)
[15:58] <Keybuk> oh, cryptsetup has a *weird* prereqs!
[15:58] <pitti> Keybuk: http://people.canonical.com/~pitti/tmp/cryptroot
[15:58] <Keybuk> yeah that for just won't work ;)
[15:59] <Keybuk> probably should be $(dirname $0) rather than /scripts/local-top
[16:01] <Keybuk> pitti: a change I made the other day is that the prereqs bit of each script is run at mkinitramfs time
[16:01] <Keybuk> rather than inside the initramfs
[16:02] <Keybuk> so the generated initramfs already knows what order to run things in
[16:02] <pitti> Keybuk: updated script (same URL), it doesn't complain now
[16:02] <pitti> but I don't claim I really understood what I was doing
[16:03] <Keybuk> basically was just expecting /scripts to exist
[16:03] <Keybuk> when that's /usr/share/initramfs-tools/scripts
[16:04] <Keybuk> (because I'm running it from mkinitramfs now)
[16:04] <pitti> Keybuk: so, I'm fine to do that upload if you want me
[16:04] <Keybuk> yup, go for it
[16:04] <Keybuk> I imagine we'll hit a few of those
[16:08] <pitti> uploaded
[16:09] <pitti> nice, bzr bd now DTRT even without a .bzr-builddeb/ config
[16:09] <james_w> inferring --merge?
[16:09] <pitti> right
[16:09] <pitti> the cryptsetup tree is full source, but it downloaded the orig.tar.gz, etc.
[16:09] <james_w> yeah, that's (yet another) thing you can thanks jelmer for
[16:10] <pitti> so far we just copied the very same config into all of our desktop trees
[16:10] <pitti> jelmer: *hug*
[16:10] <jelmer> pitti: :-) Glad to hear
[16:10] <jelmer> we have similar itchjes
[16:38] <Keybuk> james_w: I still have issues getting the first tarball into bzr ;)
[16:38] <Keybuk> I do sick and evil things like make a pretend upstream-last-release tag
[16:38] <Keybuk> or remove debian/changelog and import-dsc the source package I just generated
[16:39] <Keybuk> I noticed that it seems to upset the auto-importer though ;-(
[16:40] <james_w> hmm
[16:40] <james_w> I thought merge-upstream was supposed to work, but I can believe that I broke it
[16:40] <Keybuk> it won't work if there isn't a previous upstream tarball
[16:40] <Keybuk> it will only make deltas I assume
[16:41] <Keybuk> never the initial tarball
[16:41] <Keybuk> you can trick it into doing so though
[16:41] <james_w> yeah
[16:41] <james_w> we should fix that :-)
[16:47] <Keybuk> I have been heavily using the bzr stuff though
[16:47] <Keybuk> my workflow this cycle is "bzr branch lp:..." ... doesn't exist? file bug; out of date? file bug (and apt-get source)
[16:47] <Keybuk> otherwise just use the bzr
[16:52] <pitti> ttx: what I meant is that e. g. bug 497455  -> we won't promote until it actually appears on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[16:53] <ttx> pitti: right. It's a eucalyptus runtime dep, so I guess it will show up once the package in built
[16:53] <jelmer> pitti: btw, I noticed the MIR for tdb - some of the issues there should be fixed in the version of tdb in sid
[16:53] <jelmer> pitti: Are you the right person to talk to about the MIR, or somebody else?
[16:53] <jelmer> pitti: (I'm the Debian maintainer)
[16:53] <pitti> jelmer: I'm one right person, yes
[16:54] <kees> pitti: for the SIGXCPU+apport thing, I saw that you merged it, but I just wanted to make sure you felt that was a valid approach.
[16:54] <pitti> jelmer: which "issues" do you mean?
[16:55] <pitti> kees: it looks fine to me
[16:55] <kees> pitti: ok, cool.  No other signals like those two jumped out.
[16:56] <jelmer> pitti: tdb-dev has been renamed to libtdb-dev, manpages will be included in the next upstream version
[17:21] <ScottK> slangasek: It'd be nice (although lower priority than powerpc) if you could look at qt4-x11 on ia64 too.  I'm lost in a twisty turny maze of ifdefs.
[17:24]  * slangasek gibbers
[17:25] <ScottK> slangasek: The upstream feedback was: You have a config.h, remove it.  the issue is that #include "config.h" is including the wrong file
[17:25] <ScottK> Since it works on other archs.
[17:26] <ScottK> I think it's an ifdef issue
[17:57] <Keybuk> mdz: are any of the videod sessions ever going to appear on blip.tv ?
[18:09] <machina> hi, I'm trying to update this copyright from this http://pastebin.com/d5200e964 to this http://pastebin.com/d1fafa456 but I don't know if it's right for me to put a copyright under the debian maintainer's name?
[18:10] <machina> this is about updating an Ubuntu/debian package btw..
[18:49] <ebroder> I don't suppose I could ask somebody to do a sync run so the new version of the packge I was just about to work on would hit the repos? :)
[18:55] <ScottK> slangasek: I think I found my way through the twisty/turny maze for qt4-x11 ifdefs and ia64.  Found a "-   || defined(__ia64__) \" between the last version and the current one.
[18:55] <slangasek> ah, cool
[18:55] <slangasek> ebroder: what package?
[19:00] <ebroder> slangasek: open-vm-tools
[19:00] <slangasek> ah, needs a sync run on contrib; looking
[19:05] <slangasek> ebroder: syncing
[19:07] <ebroder> Yay! Thanks, slangasek
[19:09] <Lutin> those days, who do I have to ask to get a give-back on the buildds ?
[19:28] <ScottK> slangasek: If I give you a debdiff for qt4-x11, could you testbuild it on a ia64 porter box?  It's a huge package for me just to blind upload.
[19:28] <slangasek> sure
[19:28] <ScottK> OK.  I'll have it in a few.
[19:29] <ScottK> .dff.gz for that package takes an eternity to generate on my laptop.
[19:29] <ScottK> dff/diff
[19:48] <ScottK> Right, so the good news is the emergency drop protection shutdown on my laptop works.  The bad news is the diff.gz wasn't done yet.
[19:48] <ScottK> It was kind of cool to see the laptop blink off in mid-air when I dropped it.
[19:54] <slangasek> heh
[19:57] <ion> Why power down the entire laptop? Why not just park the HDD heads?
[20:00] <Lutin> could someone with a lucid chroot try to install libeina-svn-05 (no matter what arch.)
[20:02] <slangasek> Lutin: could; but is the problem you're trying to solve related to the fact that this package needs a binary promotion to main?
[20:03]  * ScottK guesses yes.
[20:03] <ScottK> ion: I didn't design the hardware.
[20:04] <ion> Nobody blamed you for the hardware design.
[20:04] <ScottK> It just seemed odd to ask me why it worked the way it does.
[20:04] <ion> I asked the channel.
[20:04] <ScottK> ok
[20:05] <ion> sincerely willing to learn the technical reason for shutting down everything.
[20:07] <slangasek> perhaps because the hardware doesn't trust the OS to park the heads and leave them parked
[20:08] <ion> The hardware could force the heads to be parked for a period and the OS to wait.
[20:11] <ScottK> slangasek: http://pastebin.com/f3e99eaa3
[20:11] <ScottK> slangasek: On the off chance that builds, please just throw it at the archive.
[20:12] <slangasek> how do I extract a usable patch from pastebin?
[20:14] <arthur_> slangasek: see the textarea in the bottom
[20:14] <slangasek> I see it; cut-n-pasting from it didn't please patch, that's why I was asking
[20:14] <arthur_> right after "To highlight particular lines, prefix each line with @@"
[20:14] <arthur_> ah
[20:14] <slangasek> patch: **** Only garbage was found in the patch input.
[20:15] <slangasek> oh, haha
[20:15] <slangasek> because it eats @@ at the beginning of a line
[20:15] <arthur_> nice spot
[20:15] <slangasek> ok, got it
[20:16] <ScottK> Oops
[20:17] <ScottK> When I click on download it comes up correct.
[20:17] <slangasek> oh, there's a download button, ok
[20:17] <slangasek> :)
[20:22] <Lutin> slangasek: that's it, thanks
[20:22] <slangasek> Lutin: ok, should be fixed in the next pulse then
[20:22] <Lutin> alright, thanks a lot
[20:39] <Lutin> slangasek: in fact JamieBennett just pointed out that it's been promoted some times ago
[20:39] <slangasek> Lutin: not so; the binary was in universe until around the time I commented
[20:39] <JamieBennett> Jonathan Riddell wrote on 2009-08-24:#6 Package moved to main
[20:40] <JamieBennett> from the bug comments
[20:41]  * ScottK suspects a library transition
[20:41] <slangasek> that refers to a source package
[20:44] <Lutin> ah, true. the source package introduces a new binary package which wouldn't have been promoted automatically ?
[20:49] <JamieBennett> slangasek: Is there an active archive admin around which could kick the binary into main for us then?
[20:51] <slangasek> JamieBennett: already did, see above
[20:52] <JamieBennett> OK, thanks
[20:52] <slangasek> Lutin: it's a routine archive admin activity to reconcile http://people.canonical.com/~ubuntu-archive/component-mismatches.txt, so it /should/ be < 48h turnaround from accepting the package to making sure it's in main if it's supposed to be
[20:55] <Lutin> slangasek: ok, thanks for the explanation
[21:16] <wgrant> lamont: Are you planning to get the lp-buildd changes merged soonish?
[21:16] <lamont> bigjools was supposed to land them, I thought
[21:16] <wgrant> Ah, OK.
[21:16] <lamont> lp:~lamont/launchpad/lp-buildd/
[21:17] <lamont> is what I actually built
[21:17] <lamont> and actually has changes beyond 54
[21:17] <wgrant> Ah, I wondered what those extra three revs were for.
[21:18] <lamont> yeah, it was the lalalalalalala fix these too things that fell out of reviewing changes to the machines where I installed the package
[21:18] <lamont> some just landed after I'd cut 54, and/or were invasive enough that I want them to get more testing before I roll them.
[21:45] <HenriqueRocha> hi
[21:46] <lamont> slangasek: bug 498331
[21:46] <HenriqueRocha> i'm trying to install lucid alpha 1 but it doesn't install
[21:46] <slangasek> lamont: how precise :-)
[21:46] <lamont> slangasek: I decided to make sure it had a descriptive subject....
[21:47] <lamont> dear fellow buildd admins:  DO NOT give-back libgphoto2/armel.
[21:47] <hrocha> is it possible that it is not installing because i'm using the locale in portuguese?
[21:48] <slangasek> hrocha: #ubuntu+1 is the channel for lucid support; I'm not aware of any locale-specific issues in alpha-1
[21:48] <hrocha> ok, thanks
[23:31] <ebroder> Wait, what? Why can't I target bug #191776 for Hardy? The package has always been in multiverse - I should be able to
[23:42] <wgrant> ebroder: It doesn't exist in Hardy.
[23:42] <wgrant> It was removed just before release.
[23:42] <ebroder> Huh! How about that
[23:42] <wgrant> (and it was in universe then)
[23:43] <ebroder> Oh yeah - the bug was reported against Hardy a4
[23:45] <ebroder> It seems like it would be useful if I could deal with nominations for releases the package wasn't in at all. Oh well


[19:44] <MrChrisDruif> desrt; if you're around, can you give me a ping?
[23:35] <lifeless> RAOF: around ?
[23:35] <lifeless> RAOF: I need a pointer, to whomever deals with touchpads :) - I just realised something that has been bugging me for a while; my middle button has a nearly-2 second delay between clicking and the paste happening
[23:36] <lifeless> RAOF: I suspect that this is related to the middle-click-then-drag to scroll the window feature
[23:36] <lifeless> I don't use that feature, I do use paste; how do I remove that feature...


[00:53] <ubptgbot> pinkmothra was added by: pinkmothra
 @pinkmothra, Hello Daniele, … You can find out more about UBports here … https://ubports.com/page/telegram-welcome
 @Stereofont Why is Anbox no priority as everywhere on the internet you can read Anbox is comming to UT from last year?
 @Xray2000 Anbox is still on the list, but anbox only works on xenial. We must finish the transition first, then we can work on the rest of the things.  … We're taking efforts to release OTA-4 next month :)
 @Xray2000, As a developer with time to spare, maybe you can help out in some way? Your Sailbook app is working great!
 @Xray2000, In addition, the conflict with Qualcomm processors is odd and was unexpected. At the moment, the only success has been with Ekynos and Mediatek
 @UniversalSuperBox when will the Albanian language be integrated, I translated everything except ubports documentations.
 @ixavier, Ok thanks it was just a general quiestion now we know ;)
 @Stereofont, Aren't they closed source?
 @TomasOqvist, Tomas, this is a bit to mutch for me....
 @ixavier, [Edit] Ok thanks it was just a general question now we know ;)
 @rezybleezx, Actually Mediatek is more closed but there is some feature of the architecture of Qualcomm which messes up the graphics
 @Stereofont, I hope you guy's can solve this...
 @JeffiG, The difficulty is with Ubuntu itself I think. We can only use the templates already provided. Swiss French, Turkish and Bulgarian have just been implemented
 @Xray2000, Difficult to search for something when you don't know what it is…
 @Stereofont that means wasting time for me 👍
 @JeffiG, I understand the frustration. For some infrastructure things we have to wait for work to be done by other groups, such as KDE or Debian. We are not self-sufficient
 @JeffiG, I have forwarded your concerns to the language group
 @Stereofont, Well i think with some time you will found it, i was not able anymore to buy here a PRO 5 so not many choice i have to go to the oneplus one....
 @Stereofont Thanks for the explanation, but I worked really hard, but it was worth it
 @JeffiG, We are of course always open to creating an Albanian group, when there are enough users
 @Stereofont, Not entirely, but we will solve the language packs issue after ota 4
 @Stereofont, Well, there are at least two I guess. I would join that group
 @JeffiG, No, the translation work is appreciated. 👍
 @Stereofont, Thanks
 (Video, 0s) https://irc.ubports.com/LQbLDge1.mp4
 There is a difference between video and audio. I captured it with OPO and 15.04
 I have this on both OPOs here.
 (Video, 8s) https://irc.ubports.com/VrBlJazw.mp4 Lagged
 Perhaps your table is made with echo-logical wood? 😆
 Have you checked if it's a known issue? https://github.com/ubports/ubuntu-touch/issues
 Wow, there are now a lot of xenial apps in Openstore. I've got every needed app now working. However still no working Camera in N4..
 It is so close to move daily with it..
 https://github.com/ubports/ubuntu-touch/issues/662
 @samitormanen, http://blog.bhdouglass.com/openstore/ubuntu-touch/2018/06/08/openstore-xenial-support-phase-3.html
 👍
 Does anyone have working gps in N4 xenial?
 Mine is kind of working, except it shows my location 20km off..
 How long has it been since you got the lock?
 5minutes
 It can take up to 20 to get a precise location
 Oh, ok.
 Maybe i wait then a bit more 😆
 @UniversalSuperBox now it got real location. You were right. 😁👍
 Yay!
 It's like fine wine.... you must let it sit in the open air for a few minutes before enjoying.
 😹😹😹
 😁
 Now, the camera app is only thing what doesnt work. Is here anyone who has N4 xenial and Camera working?
 I don't think so the same happens with hammerhead
 @dohbee, can you reproduce this bug? https://github.com/ubports/ubuntu-touch/issues/514
 @ixavier, How do I get anbox on xenial?
 the elephant in the room...
 flash from the past! welcome back nick ;)
 To actually answer your question, https://docs.ubports.com/en/latest/userguide/dailyuse/anbox.html
 @lastdon82, https://docs.ubports.com/en/latest/userguide/dailyuse/anbox.html
 your service is top shelf, Dalton. … Except.... you didn't answer it.  You gave him a link and were there not 'massive issues' with 'qualcomm' or something?  My understanding of much is limitied but it sounded like Anbox was having notable challenges?
 or... can we actually install it with xenial on all these UT supported devices?
 @UniversalSuperBox, I have pro5 with xenial installed.
 Yep, that'll do it!
 But mobile data might not work
 throws shade at @mariogrip
 👨👨👦
[17:07] <ubptgbot> lolmanlol was added by: lolmanlol
 Hello. Does Ubuntu touch on the Galaxy tab4 (sm-t331)?
 It touches everyone who uses it. But sadly it is not available for that device.
 @lolmanlol, This is the supported devices list https://devices.ubuntu-touch.io/
 @lolmanlol, Marvell chipset. I don't think that has been considered by anyone
 ok . bye
 👋
 Is there a doc somewhere on tethering UT? Not reverse-tethering.
 So you're looking to...
 ?
 probably tether net from phone to pc
 @amolith, i have no idea what you're asking. "tethering" is the "normal" thing one asks how to do on phone. mentioning "reverse-tethering" makes for a very confusing question
 @UniversalSuperBox, hmm, indeed my phone rebooted when i opened camera, after a few seconds
 Can you get `/proc/last_kmsg`?
 yep
 @UniversalSuperBox, Connect my laptop to the internet through UT. I'm at SELF and I can't connect from my laptop but my phone is connected fine lol.
 @dohbee, Alright, that would be useful on that ticket
 @amolith, are you using the wifi hotspot?
 @dohbee, There is a doc on reverse-tethering and that's not what I want so I added that to avoid confusion.
 really?
 where?
 https://docs.ubports.com/en/latest/userguide/advanceduse/reverse-tethering.html
 reverse-tethering is using your computer's Internet connection for your phone
 the other one is just to configure a hotspot, no?
 @UniversalSuperBox, i presumed as much
 but the wifi in my nexus 5 is fried, so i kind of need that to test stuff on it
 i didn't realize you could tether as such over usb back via the PC
 @dohbee, I thought the hotspot was only for data?
 your laptop doesn't have wifi?
 you have to enable `rndis` gadget service on the phone, to get usb tethering
 are you using networkmanager?
 @dohbee, It does but I can't connect to their WiFi for some reason
 @dohbee, Yes
 then when you enable rndis on the phone, it should show up as a network device for networkmanager, but maybe you need an additonal back end bit for it, i don't recall
 it "just works" in ubuntu anyway
 @dohbee, I'll just use data for now. I only need it for a few minutes
 How would I enable it for later?
 `android-gadget-service enable rndis` on the phone
 @UniversalSuperBox, well, i copied the log to my home dir on the phone, and then mtpd crashed or something, and i can't use adb/ssh any more, even after a reboot :-/
 @dohbee, Where can I find the rest of this information so I don't bug you with questions?
 i don't know
 last time i used that (been a couple years now i guess), all i had to do was enable rndis on my nexus 5 and bam it just worked
 What do you mean it just worked?
 i mean on ubuntu, with the phone plugged in, i ran that command on the phone, it appeared as a network device in networkmanager, and it automatically connected to it
 @amolith, You can take a look to that old guide gurucubano did https://gurucubano.gitbooks.io/bq-aquaris-e-4-5-ubuntu-phone/content/en/chapter4.html
 @UniversalSuperBox hmm, i wonder if it's a bug in the camera app itself?
 ok, managed to get the log attached finally
 What have we here
 (Photo, 1280x720) https://irc.ubports.com/XpLW0av8.png
 using real ssh instead of usb
 Of course "about" doesn't actually work when you aren't using system-image to install
 (Photo, 720x1280) https://irc.ubports.com/Oh9z05y8.png
 There.
 @advocatux, Does this work with every phone/kernel or are there special requirements (driver etc)
 @unknown, the phone has to support rndis, i guess
 Okay thank you
 @dohbee, Seems likely
 Thanks for that info, @dohbee. We'll have to check again in a few days once camera-app is a click rather than a deb
 Hi, can someone give me a link to the german ubports group?
 https://t.me/UBports_Deutsch
 Thank you
[22:22] <ubptgbot> joshim was added by: joshim
 Is the calendar app working under xenial? The app starts and crash.
 @Waldbursche, You have an all day event. It's failing to load those
 Memory violation... That's all we know
 okay
 It's better so. This gives me more free time without calendar 😅
 @Waldbursche, The app works, but can't sync with gmail account.
 No, it just doesn't work when you have all-day eventd. Online accounts are a separate issue
 @UniversalSuperBox, Agree. And i have only my nextcloud-account to synchronize.


[21:08] <hakermania> Hello guys, can anyone tell me what is the name of the remove-script in a deb package and where do I place it ?(I hope the name to be postrm and place it in the DEBIAN folder)
[23:24] <Tempus_Fugit> hello all


[00:17] <snap-l> evening
[00:22] <gamerchick02> howdy i was about to switch to the other computer.
[01:15] <jrwren> https://www.youtube.com/watch?v=vboGDSUGCyY
[13:17] <rick_h> morning
[13:34] <snap-l> Good morning
[16:02] <rick_h> snap-l: whatever do you mean :P
[16:03] <rick_h> snap-l: just because my coffee is half milk doesn't mean anything
[16:06] <snap-l> Heh. :)
[16:07] <snap-l> I consider it a gateway drug to the real pure black-tar of good coffee. ;)
[16:07] <rick_h> loll
[16:07] <rick_h> well, the big thing the frother does is heat the milk
[16:08] <rick_h> having lukewarm coffee out of the moka pot the last few days has been :(
[16:08] <snap-l> We'll have to bring over the Turkish coffee set sometime
[16:08] <rick_h> and I wasn't sure about just nuking the milk before putting it in the coffee
[16:08] <rick_h> yea, that's what jodee keeps saying
[16:08] <snap-l> since our stove goes from 0 to nuclear winter and very little inbetween