[00:19] <vsingh165> anyone here know why I can't branch or checkout the lp:df-libreoffice branch?  it always seems to get stuck at 10639 kB
[00:24] <vsingh165> when I bzr branch lp:df-libreoffice in terminal, I get "Write failed: broken pipe" errors
[01:12] <sladen> vsingh165: report a bug
[06:56] <infinity> doko_: Why do crossbuild-essential-* depend on pkgbinarymangler?  That's pretty buildd-specific, and regular build-essential doesn't depend on it.
[06:58] <infinity> doko_: (And, sure, you need pkgbinarymangler if your non-cross arches also use it, but conversely, if not, you need to not have it, so it should be something installed/enabled in the chroots by end users, not forced by dependencies, no?)
[07:29] <tkamppeter> infinity, did you see my answer about CUPS?
[07:30] <infinity> tkamppeter: Yeahp, thanks.  Noticed the upgrade removed the obsolete file here, and cron should shut up now, thanks.
[07:33] <pitti> Good morning
[08:05] <doko> infinity, just did take that from wookey. didn't know if cjwatson's test build adds it explicitly
[08:05] <doko> xnox:
[08:05] <doko> checking for pkg-config... /usr/bin/pkg-config
[08:05] <doko> checking pkg-config is at least version 0.22... yes
[08:05] <doko> checking for DBUS... no
[08:05] <doko> configure: error: Package requirements (dbus-1 >= 1.2.16) were not met:
[08:05] <doko> No package 'dbus-1' found
[08:05] <doko> looks like libnih still uses the wrong pkg-config binary
[08:06] <infinity> $crossbuild_core_depends = { armhf => ['build-essential', 'gcc-arm-linux-gnueabihf', 'g++-arm-linux-gnueabihf', 'pkg-config-arm-linux-gnueabihf', 'dpkg-cross']
[08:07] <infinity> doko: ^-- What Colin and I use (and, I assume, his testbuilds)
[08:08] <StevenK> 'gnueabihf' sounds like the noise you can make while sneezing.
[08:09] <infinity> doko: The extra interesting thing there is that your crossbuild-essential has a cross-arch libc6-dev:crossarch dep, while we're just relying on gcc-arm-linux-gnueabihf to get it right, I guess?
[08:12] <doko> infinity, yes, you have to install the runtime target libs "twice", or else the shlibs files won't be found
[08:13] <infinity> doko: That's... Special.
[08:14] <infinity> doko: Anyhow, I have no opinion on the libc6-dev:armhf thing (and just caught up on the discussion in the Debian bug), but we should drop the pkgbinarymangler bit and leave that to the discretion of people building/managing their chroots.
[08:15] <infinity> (As in, mk-sbuild will do it for you by default with --distro=ubuntu, but it shouldn't be a hard dep, for people who prefer not to mangle)
[08:54] <cody-somerville> seb128: Hey. I run into LP #930563 in case you need help debugging the issue.
[08:55] <seb128> cody-somerville, hey, it would rather be something for larsu/charles/cyphermox
[08:55] <cody-somerville> kk.
[08:57] <cody-somerville> cyphermox: I'm quite certain that LP #985028, LP #933300, and LP #930563 are the same.
[08:59] <cody-somerville> cyphermox: https://bugs.launchpad.net/ubuntu/+source/libdbusmenu/+bug/930563/comments/8 is the key I think.
[09:28] <didrocks> @pilot in
[09:51] <cjwatson> doko: My chroots are made with mk-sbuild, which adds pkgbinarymangler by default, so I don't need crossbuild-essential-* to add it as well
[09:52] <doko> ok, will remove it with the next upload
[10:07] <xnox> doko: well when doing cross it does two builds: native and then cross. Do you have full log? (my cross-chroot is not very minimal, maybe I should reset it up)
[10:09] <xnox> doko: and did that build install both native&cross build-deps? (I didn't add :native build-deps since that is not supported just yet by sbuild)
[10:09] <cjwatson> I'm surprised that it works to do one build in a subdirectory and another in the source tree itself
[10:09] <cjwatson> I thought automake complained about that
[10:09] <cjwatson> usually when I need to do one build in a subdirectory I convert all the builds to do that
[10:10] <doko> xnox, http://people.canonical.com/~cjwatson/cross/armhf/raring/
[10:11] <cjwatson> doko: that's the native build pass
[10:11] <cjwatson> doko: so it's correct for it to use /usr/bin/pkg-config
[10:12] <xnox> cjwatson: hm. I was dubious about how the configure cache is handled. I think native build cache leaks into cross =/ but didn't look deeper into it.
[10:12] <cjwatson> doko: the problem is the known one that we don't yet have a way to declare the native build-dependency
[10:12] <doko> ahh, ok
[10:12] <xnox> (unless it's not leaking but using the preload)
[10:12] <cjwatson> xnox: config.cache is in the build directory, so shouldn't leak; but the one preset by dpkg-cross might
[10:13] <cjwatson> xnox: you could unset CONFIG_SITE for the native build pass, perhaps, although that seems like quite a big hammer
[10:22] <doko> well, isn't CONFIG_SITE plain wrong for the native build?
[10:23] <cjwatson> when it's been set by dpkg-cross, yes
[10:23] <cjwatson> or rather to the dpkg-cross config
[10:23] <cjwatson> I can imagine somebody using it for other purposes, although we don't
[10:23] <cjwatson> but that's probably not worth worrying about - sounds best to unset it
[10:25]  * cjwatson applies http://paste.ubuntu.com/1512288/ to groff, for comparison
[10:31] <doko> https://wiki.ubuntu.com/CrossBuilding/BuilddChroot looks pretty complete now, besides perl and linux
[10:32] <xnox> doko: I just uploaded DEB_STAGE=stage1 build variant for libsemanage. So we should be mostly done now =)))))
[10:33] <didrocks> pitti: mind rejecting https://code.launchpad.net/~jelmer/ubuntu/raring/etckeeper/merge-debian/+merge/141431?
[10:33] <pitti> didrocks: done
[10:34]  * cjwatson looks at kmod
[10:34] <didrocks> thanks pitti :)
[10:35] <cjwatson> oh, sorry jelmer, I didn't notice that MP
[10:35] <cjwatson> I kept the change of default to bzr in my merge
[10:35] <cjwatson> so if you still want to revert that, then propose another MP with just that, I think
[11:14] <doko> barry`, maybe ask the debian maintainer before starting packaging the pil fork. I already have it packaged
[11:17] <bdrung> Laney: re bug #954352, do you have the prepared package at hand? i haven't prepared anything yet. so it could take more time for me than for you.
[11:27] <Laney> bdrung: yeah, let me get the debdiff
[11:29] <Laney> bdrung: http://paste.debian.net/223087
[11:31] <didrocks> doko: hey, I'm wondering why https://launchpadlibrarian.net/127995793/buildlog_ubuntu-raring-i386.efilinux_1.0-3ubuntu1_FAILEDTOBUILD.txt.gz is only failing on i386 and amd64. I'm not really motivated to add -fno-stack-protector. Any help?
[11:31] <didrocks> and *not* on amd64
[11:31] <bdrung> Laney: shouldn't have the symbols version a trailing ~ (for backport reasons)?
[11:32] <Laney> yep
[11:32] <Laney> i didn't upload it yet :-)
[11:34] <bdrung> Laney: as you wrote, we need to get a MIR for libxkbcommon first
[11:34] <cjwatson> didrocks: the other question is why you uploaded a merge from somebody who didn't touch it last and hadn't talked to the previous uploader, who might have had a merge in progress ...
[11:35] <doko> didrocks, well, should be clear if build with -nostdlib
[11:35] <Laney> bdrung: I'm not massively interested in working on it, so feel free to check with #ubuntu-x
[11:35] <Laney> I get the feeling that it's experimental so won't be allowed in
[11:35] <didrocks> cjwatson: I was just doing my patch pilot sponsoring and waiting to help clean the queue. The merger from debian seemed straightforward enough to be handle and builds fine on my amd64
[11:36] <cjwatson> didrocks: that doesn't answer my complaint, at all
[11:36] <cjwatson> sponsoring is not an excuse for doing it wrong
[11:36] <bdrung> Laney: it's relatively new. there were no release, when the ubuntu package was created, but now there is a 0.2.0 tarball:  http://cgit.freedesktop.org/xorg/lib/libxkbcommon/log/
[11:36] <didrocks> ok, I'll keep that in mind for the next sponsoring shift and only touch my area
[11:36] <cjwatson> no, that isn't what I said
[11:36] <didrocks> doko: let me have a look
[11:37] <cjwatson> People being sponsored need to be educated how not to step on people's toes
[11:37] <cjwatson> That doesn't mean exaggerating to "only touch my area"
[11:37] <didrocks> cjwatson: well, in that case, it's easier to wait that the other people is doing his shift (if they do it…)
[11:37] <bdrung> Laney: i will ask in #ubuntu-x . can you attach your debdiff to the bug report?
[11:38] <cjwatson> didrocks: sure, because those other people are off relaxing on the beach rather than doing other useful work, I'm sure
[11:38] <cjwatson> (I'm quite tired of the insinuations about sponsoring)
[11:38] <didrocks> for things that seems easy people directly uploads them, like when people multiarched the unity stack, and didn't use the right branches, I didn't scream at "you are stepping on my toes"
[11:39] <cjwatson> didrocks: We've had a notice on merges.ubuntu.com for eight years that people should check with the previous uploader before merging
[11:39] <cjwatson> It's not like it's news
[11:39] <didrocks> cjwatson: oh, it's not about you, TBH, I even don't know who is doing their shift and who doesn't, I just see a lot of complain from dholbach that a lot are not doing
[11:39] <cjwatson> Yes, dholbach isn't fixing cross-builds either
[11:39] <cjwatson> We all do things
[11:39] <didrocks> I agree, that's why I didn't complain and try to help getting things clean
[11:40] <didrocks> for things that seemed straightforward and builds fine, I didn't think about that would bother others, sorry for that
[11:40] <cjwatson> (Actually, Logan did say to me in private mail that he was going to do better about contacting the previous uploader in future - so that's OK until the next person :-) )
[11:40] <cjwatson> What I want is for this to be a check in the sponsorship process; I agree that in this case it was fairly untroublesome, but in other cases it has caused me problems
[11:40] <cjwatson> I don't know how to achieve this efficiently
[11:41] <didrocks> the issue is that we have too many ways to get things in, but that's just IMHO
[11:41] <cjwatson> (For instance something that's deliberately not being merged for one reason or another)
[11:41] <didrocks> but I agree with your remark
[11:41] <cjwatson> didrocks: And very few efficient ways to say "no" in a way that sticks :-/
[11:41] <didrocks> right
[11:42] <cjwatson> didrocks: So sorry, I was too harsh on you, I need coffee :-)
[11:42] <didrocks> cjwatson: no worry, I can understand the feeling, I hope I didn't sponsor anything you didn't want in :)
[11:42] <Laney> bdrung: done
[11:42] <bdrung> thanks
[11:43] <cjwatson> I guess what I'd really like is a more reliable way to notify interested people about things pending sponsorship
[11:43] <cjwatson> Right now, if somebody proposes a merge to a package I touched recently, I only find out if they explicitly ask for my review, or if I watch the whole sponsorship queue
[11:43] <bdrung> cjwatson: good ideas are welcome. maybe we could add some information the the sponsoring queue?
[11:43] <infinity> cjwatson: Yeah, if I could more easily subscribe to these things, I wouldn't care about losing TIL on all my merges (which happens all the time)
[11:44] <cjwatson> bdrung: The problem with approaches that involve more information on the sponsoring queue is that you still have to watch the queue to see them
[11:44] <cjwatson> bdrung: I think I want LP's default who-gets-asked-for-review to be smarter
[11:44] <infinity> It really irks me to lose TIL on merges (which reminds me, I need to steal dpkg back from you), cause then they go off my radar.
[11:45] <cjwatson> infinity: And for some reason we advertise merges as a good thing for people to do when they're learning
[11:45] <cjwatson> I've *never* understood that
[11:46] <infinity> Probably because many of them (like the eflinux one above) are really trivial.  But the knock-on effects of "stealing" trivial merges from other people are pretty irritating.
[11:46] <cjwatson> Merges tend to be either trivial or REALLY REALLY HARD
[11:46] <infinity> Yup.
[11:46] <cjwatson> And if you aren't experienced you can't tell which in advance
[11:47] <cjwatson> didrocks: So, I can solve the losing-TIL problem for efilinux by fixing up that build failure for you, if you like ;-)
[11:48] <didrocks> cjwatson: indeed, that's a way to do it. I don't like cleaning what broke under me, but if there is a benefit for you, sure, please do :)
[11:48] <didrocks> grrr
[11:48] <didrocks> I don't like *not* cleaning
[11:49] <didrocks> 2 *not* missing in less than 30 minutes, need coffee as well :)
[11:50] <cjwatson> doko: Shouldn't -ffreestanding inhibit use of the stack-protector?  I'm sure it used to
[11:50] <cjwatson> Oh, wait, the problem might be in gnu-efi
[11:51] <cjwatson> Hah, and slangasek dropped the -fno-stack-protector bit there saying that it was no longer needed
[11:52] <cjwatson> LIES
[11:54] <didrocks> :)
[11:55] <didrocks> @pilot out
[12:00] <cjwatson> didrocks: OK, fix on its way now, although it won't involve reuploading efilinux
[12:00] <cjwatson> Them's the breaks
[12:01] <didrocks> cjwatson: just a rebuild once gnu-efi rebuilt from what I saw. Well, if someone contacts me for this package, I'll redirect it to you
[12:02] <cjwatson> Yeah, no worries
[12:02] <cjwatson> xnox: I've sorted out the gluegen2/armhf horribleness, I think
[12:03] <cjwatson> So we should be able to crawl up that stack shortly and get opencv promoted
[12:05] <xnox> \o/
[13:00] <pitti> didrocks: nice progress on the sponsoring queue!
[13:01] <didrocks> pitti: thanks :)
[13:02] <pitti> hm, ubuntu-drivers-common just started failing, bcmwl doesn't compile any more
[13:02] <pitti> and testing locally confirms it
[13:03] <pitti> tseliot: ^ seems the "support 3.8" broke 3.7?
[13:03] <pitti> Fehler: »struct cfg80211_ibss_params« hat kein Element namens »chandef«
[13:07] <pitti> tseliot: filed as bug 1097729; should we revert the change for now, or do you think it could be made to work with both kernels/
[13:07] <pitti> ?
[13:11] <wookey> where do I go to ask questions when apt is apparently doing daft things?
[13:12] <wookey> Currently in a raring chroot if I try to install libgcc1:arm64 apt wants to remove all of essential. I don;t understand why...
[13:13] <wookey> is there an apt irc channel or debugging info somewhere?
[13:16] <cjwatson> wookey: #debian-apt on OFTC
[13:16] <cjwatson> wookey: Also -oDebug::pkgProblemResolver=true
[13:28] <infinity> wookey: Is that the same version of libgcc1 that you have on your other arch (or is it otherwise causing a version skew that would break the world)?
[13:28] <infinity> wookey: That's the only obvious thing I can think of.
[13:37] <wookey> aha. 4.7.2-17ubuntu2 vs 1:4.7.2-17ubuntu2. I bet that's bloody it!
[13:37] <wookey> mutter
[13:39] <wookey> the annoying hting is that the error message you get from apt about this is 'libc6:arm64 depends on debconf:arm64' which is just wrong, and thoroughly misdirectful
[13:39] <wookey> I guess multiarch is going to produce more of this sort of mysteriousness
[13:40] <cjwatson> that's particularly curious since debconf is M-A: foreign
[13:40] <wookey> exactly
[13:40] <wookey> I was thoroughly nonplussed
[13:41] <barry> doko: where is it?  i looked didn't find it.  it's a different source package
[13:42] <wookey> I'm not sure what to do with this sort of problem. take it to the deity list?
[13:42] <cjwatson> perhaps, yeah
[13:42] <infinity> wookey: Which problem?  The unhelpful error message, or you asking apt to do something you shouldn't?
[13:42] <wookey> analysis with libdose can be helpful but that said everything was OK.
[13:42] <wookey> apt giving unhelpful meessages when I ask it to do womthing it shouldn't :-)
[13:42] <infinity> Heh.
[13:43] <cjwatson> the problem with analysing with some other tool is that half the time you find yourself analysing why they differ
[13:43] <cjwatson> hello, yak-shaving
[13:43] <tseliot> pitti: let me check. I'm pretty sure there's a check which applies only to 3.8
[13:43] <wookey> cjwatson: indeed. but I don't know how to get more detailed info out of apt about why it thinks what it things. I recall there is some, but I failed to find info on it yesterday
[13:44] <cjwatson> generally you get more detailed info by adding more of the packages it complains about to your apt-get install line until it gives you a real error
[13:44] <cjwatson> and as I say -oDebug::pkgProblemResolver=true can be helpful although it takes practice to read
[13:44] <wookey> searching for apt debug on google gets you some astronomical windows tool apt.exe
[13:44] <cjwatson> between them those two strategies are usually enough
[13:45] <pitti> tseliot: a mere "sudo apt-get install bcmwl-kernel-source" on current raring reproduces it
[13:45] <wookey> right. I knew the 1st but not the second.
[13:47] <tseliot> pitti: true, I can reproduce it here. I'll fix it
[13:48] <pitti> tseliot: thank you!
[13:48] <Chipzz> wookey: while U agree that apt's error messages could sometimes be improved upon, I'm not sure how simple that would be
[13:49] <Chipzz> *I
[13:49] <wookey> Chipzz: Yes. That may well be the b3est that it can do, but I'd like to be assured of that by someone :-)
[13:49] <Chipzz> the solver probably is quite complex
[13:49] <cjwatson> wookey: BTW have you seen https://wiki.ubuntu.com/CrossBuilding/BuildChroot?
[13:49] <wookey> Really I thinbk we just need some easy-to-find docs on how to debug
[13:50] <wookey> no such page?
[13:50] <cjwatson> wookey: Sorry, https://wiki.ubuntu.com/CrossBuilding/BuilddChroot
[13:51] <bdrung> mdeslaur: see bug #1084054
[13:51] <wookey> nice
[13:51] <barry> didrocks: any chance you could take a look at https://code.launchpad.net/~barry/oneconf/py2py3/+merge/141001 ?
[13:52] <didrocks> barry: not today, but it's on my list :)
[13:52] <wookey> we need to agree on our DEB_STAGE/BUILD_PROFILE bootstrap/stage1 terminology before we do too much more of this...
[13:52] <mdeslaur> bdrung: sarnold is on community this week, he should be picking it up. thanks!
[13:52] <barry> didrocks: okay, thanks!
[13:54] <bdrung> mdeslaur: i saw your comments on bug #1095434 and bug #1096193
[13:54] <bdrung> sarnold: time to sponsor vlc?
[14:08] <micahg> didrocks: thanks for working on the sponsorship queue, could you please try to remember to check the .changes file for the appropriate changelog entries when sponsoring merges (I know UDD makes this more difficult than grab-merge)
[14:11] <wookey> OK. fixing the epoch on libgcc1 means it gives a much more sensible message:  libgcc1:arm64 : Conflicts: libgcc1 but 1:4.7.2-17ubuntu2 is to be installed
[14:13] <wookey> aha. yes. I've failed to push my equivs patch to enable Multi-Arch: foo upstream
[14:17] <wookey> yee-ha. only taken 3 days to get that package installed :-) Now I should be able to do sbuild raring arm64 cross-builds
[14:21] <tumbleweed> didrocks: looks like you forget to use -v a few times when sponsoring merges today. And I'm noticing too late to make any difference...
[14:25] <micahg> tumbleweed: and I mentioned it 13 minutes ago :)
[14:25] <micahg> err...13 minutes previous to you
[14:25] <tumbleweed> ah, I lastlogged for -v, you didn't match :)
[14:26] <micahg> yeah, I figured people keep asking what it is (which I guess is a problem in and of itself, but, meh)
[14:26] <micahg> and syncpackage seems to not be doing it properly either ATM...
[14:27] <micahg> ah, maybe that's for the first sync into the series
[14:27] <tumbleweed> syncpackage is only responsible for the changes it shows you and closes bugs with
[14:27] <micahg> it does that part properly ;)
[14:28] <micahg> it's the LP side that seems broke
[14:28] <micahg> I"ll have to make sure a bug is logged later
[14:39] <zul> mterry:  ping
[14:41] <mterry> zul, heyo
[14:42] <mterry> zul, I'm mostly back up and running, I can take a look at the mirs again
[14:42] <zul> mterry: cool they should be ok now
[14:45] <stokachu> chrisccoulson: Was there a email or any documentation relating to acroread not being built after Precise?
[14:46] <cjwatson> The partner maintainers asked for packages in partner not to be automatically carried over to the next release
[14:46] <cjwatson> So if it hasn't been published in later series then that's because none of the partner maintainers saw fit / remembered to reupload it
[14:46] <stokachu> should i ping one of them about it?
[14:46] <cjwatson> I gather this was something to do with contracts not necessarily covering all series
[14:46] <cjwatson> Yes
[14:46] <stokachu> ok
[14:46] <stokachu> thanks :)
[15:06] <mterry> zul, your testrepository upload ftbfs
[15:07] <zul> mterry:  ubuntu3?
[15:07] <mterry> zul, yeah
[15:07] <zul> mterry: i just uploaded ubuntu4
[15:10] <didrocks> tumbleweed: micahg: sorry not enough sleep and yeah, I noticed it once I sent my report :/
[15:11] <mterry> zul, ah cool
[15:37] <zul> mterry:  when i run it locally it runs fine
[15:38] <mterry> zul, this was in a pbuilder
[15:38] <mterry> zul, maybe a missing depend?
[15:38] <zul> mterry: ubuntu4?
[15:38] <mterry> zul, yeah
[15:38] <zul> dont think so
[15:39] <mterry> zul, it finishes the build.  And I didn't test it actually running
[15:39] <mterry> zul, this is just output from the build
[15:39] <mterry> zul, looks like it tried to run some tests, failed, but didn't fail the build
[15:39] <zul> mterry: it runs just fine when its used in the nova build
[15:39] <doko> cjwatson, infinity, pitti: udev b-d's on usbutils. should this be m-a foreign?
[15:40] <pitti> doko: usbutils M-A: foreign sounds right to me
[15:41] <cjwatson> Yeah, agreed
[15:41] <doko> ok
[15:43] <psusi> cjwatson: I'm going to apply to become a debian maintainer and was wondering if you would mind signing my gpg key? A70FB705
[15:44] <cjwatson> psusi: We'd need to exchange key material in person
[15:44] <cjwatson> I would hope that nobody here would sign a key on the strength of an IRC conversation :-)
[15:45] <psusi> really?  years of irc conversations, being registered with lp, used to sign many emails, my ppa, all not enough? ;)
[15:46] <cjwatson> Sorry, pretty standard practice
[15:46] <psusi> wish I had remembered that last time uds was here
[15:46] <cjwatson> I'm happy to sign a key at the next conference when we meet
[15:47] <psusi> heh, when will UDS be back in Orlando? ;)
[15:48] <cjwatson> Well, it's been twice now so presumably the odds aren't awful
[15:48] <xnox> look up on db.debian.org for DDs near you & meet in person.
[15:48] <psusi> hrm...
[15:49] <Laney> argh
[15:49] <Laney> I got a keysigning request ages ago and forgot to set up a meeting
[15:51] <psusi> xnox: doesn't seem to show where they live...
[15:52] <xnox> there is also a keysigning page on debian wiki
[15:52] <xnox> that has locations.
[15:52] <Laney> http://wiki.debian.org/Keysigning/Offers
[15:56] <hrw> psusi: conferences are one of best ways to get key signed.
[15:57] <hrw> at last Linaro Connect I hunted down Linaro kernel hackers for example
[15:59] <psusi> yea.. damnit, I should have done that.. seems signatures just aren't needed in the Ubuntu community though so I guess I was a bit lazy
[15:59] <hrw> psusi: fosdem in 3 weeks?
[15:59] <hrw> probably too soon
[16:05] <psusi> yea, I can't fly half way around the world ;)
[16:06] <psusi> ahh, damn.. next uds is in copenhagen
[16:06] <Laney> what makes you think that?
[16:06] <cjwatson> uh, wasn't that the last one?
[16:06] <Laney> the /previous/ one was
[16:06] <roadmr> psusi: hmm I don't think so, that was in November and I doubt it would repeat
[16:07] <roadmr> psusi: probably an outdated page
[16:07] <pitti> psusi: I heard rumours about Oakland
[16:07] <psusi> ohh, you're right.. guess the page hasn't been update
[16:09] <pitti> psusi: FWIW, you could have spent five years as "psusi" and your name could still be Eduard Frankenstein -- IRC personality vs. official authority document :)
[16:09] <psusi> when you sign the key in person do you authenticate my birth certificate? ;)
[16:10] <pitti> (and it is totally okay to call yourself anything you like in the interwebs, that's not uncommon)
[16:10] <pitti> psusi: well, passport, ID card, something like that
[16:10] <pitti> at least you need to meet someone in person, preferrably more than once
[16:11] <psusi> ohh... so this is... what's it now... that high level of trust type signature they talk about in the manual, not just normal?
[16:12] <pitti> it is certainly conceivable to generate a GPG key with an identification of "https://launchpad.net/~psusi"
[16:12] <pitti> but ordinarily you create GPG keys with your real name/email
[16:12] <pitti> I don't need to sign your key to trust that lp.net/~psusi can control /~psusi/+gpgkeys
[16:13] <pitti> but if I want to ensure that those key bits are controlled by a person called "Phillip Susi", I need to see an official ID with your photo and your name
[16:14] <cjwatson> I *have* signed the odd person's key in the past based on an IRC conversation, but only people I know very well so that I can e.g. have some way to satisfy myself that they're the same person that I know offline
[16:15] <cjwatson> And sometimes I do say that if somebody is impersonating so-and-so then they've been doing a good enough job of it for long enough that they deserve to win
[16:15] <pitti> if I have met someone personally once, I would be comfortable having her/him read out the fingerprint over the phone, and tell me how/when we met if I can't recognize the voice reliably
[16:15] <psusi> sure.. but sending an encrypted email and verifying I can read it verifies the pairing of email address and key... and the fact that I've been signing email with that key for years is pretty good indication that someone didn't just make it up and hack my email.. about the only possibility is that I've been lieing about my real name all these years, and well... that just seems a little paranoid
[16:15] <cjwatson> But I have to know them personally for that; I don't have a good enough social brain to convince myself that a person I'm talking to on IRC now is the same person I've been talking to before
[16:16] <cjwatson> Basically, diverging from the standard safe procedure means that I have to think really hard about whether this might be a social-engineering attack
[16:16] <pitti> psusi: there are quite a number of community members who prefer working under a pseudonym
[16:16] <cjwatson> And that's difficut
[16:16] <cjwatson> +l
[16:16] <pitti> psusi: i. e. you can trust the work of someone with a pseudonym without having to trust his real name
[16:16] <cjwatson> Ubuntu is quite plausibly a high-value target of attack; I don't think it's paranoid to be careful
[16:16] <psusi> right, so would it even matter if I had been using a false name this whole time?
[16:17] <cjwatson> as is Debian
[16:17] <pitti> tseliot: thanks!
[16:17] <cjwatson> I don't think it would matter if you'd been using a false name, but I'm not willing to give up the "exchange key material in person" step
[16:17] <pitti> psusi: not in terms of how other people regard your work
[16:17] <cjwatson> Other people might feel it matters
[16:18] <pitti> psusi: I would sign a key ID saying "https://launchpad.net/~psusi is an Ubuntu community member", if that would make any sense; but I couldn't sign an ID saying "Philip Susi", as I cannot verify that
[16:19] <tseliot> pitti: thanks for reporting
[16:19] <Daviey> pitti: So, you have seen my online identify of Dave Walker (Daviey) for a number of years now.. Would you consider that enough to sign my key, remotely.. without seeing supporting ID?
[16:20] <Daviey> identity*
[16:20] <pitti> Daviey: I know you in person and would trust myself to recognize your voice; so if I were to sign a key for you, I'd be content with calling your phone number and you reading me your fingerprint
[16:20] <cjwatson> Likewise.  But if I *only* knew you online then I wouldn't sign a key base on that
[16:21] <cjwatson> *based
[16:21] <sabdfl> cjwatson, Daviey: I'm doubling your salary
[16:21] <sabdfl> that's the problem with IRC identities :)
[16:21] <cjwatson> rawk
[16:21] <ogra_> LOL
[16:21] <chrisccoulson> hah
[16:21]  * xnox doesn't sign people's keys with documents I don't recognise. e.g. us driving license is meaningless to me. I've signed on us driving license only once, but that person was already in my web of trust.
[16:21] <Daviey> hah.  Works for me.
[16:21] <psusi> Daviey: depends on the type of signature... gpg defines different levels and one of them is to signify that yes, you are attesting that the persons' name is correct... but there are others that just mean you are sure that someone else is not impersonating the person you know
[16:22] <maxb> Unfortunately those levels of signature aren't nearly well defined or publicised enough
[16:22] <Daviey> Well, people use them very differently
[16:22] <cjwatson> psusi: the uses of the web of trust in Debian generally consider any signature to be sufficient,
[16:23] <cjwatson> in any case, this is all very long-established stuff; you're swimming upstream by trying to persuade people to make exceptions for you, and it might well be easier to just arrange a meeting in person
[16:24] <psusi> I guess what I'm saying is that the bar of "verified identity with gov't documents" is the highest level of trust, and seems a tad much for getting recognized as a dm
[16:24] <psusi> I fired off an email to the one dd listed as living in FL, see what happens
[16:24] <xnox> psusi: levels of trust != attestation. You attest for everyone, levels of trust are set locally. E.g. i might attest somebody, but mark in my keyring to not trust that persons attestations cause said person publically tried to get a key signed without checking ID.
[16:24] <maco> i dont think i'd need my mom's drivers license to believe she's my mom
[16:24] <cjwatson> a DM very likely has root on lots of people's machines
[16:25] <cjwatson> it's worth fairly carefully establishing that they are who you think they are
[16:25] <maco> well any more than i already have trouble believing we're related ;)
[16:25] <cjwatson> if nothing else so that you have some chance of having some recoure
[16:25] <cjwatson> *recourse
[16:26] <Daviey> well, a key parties you tend to look and validate a whole chunk of people.  If i validate someone called "John Smith", i'm not going to remember the contact details to support recourse.  I just know that it is *A* John Smith.
[16:27] <psusi> that's the thing... trusting someone, and verifying their identity are different things entirely... how does verifying my legal name help with the trust part?  it doesn't seem to...
[16:27] <pitti> psusi: that's right, these are totally different concepts
[16:27] <maxb> It does seem a bit incongruous that a decision on whether to give uploader privileges is pretty much wholly based on behaviour of an online persona, yet there's no agreed on way to set up cryptographic trust based on that. But that's the situation that seems to have evolved.
[16:28] <cjwatson> if you thought you trusted somebody and then they screwed you over (actionably), then if you can't verify they were who they said they were you have absolutely no recourse
[16:28] <pitti> maxb: actually, that's pretty much how LP's upload privileges work
[16:28] <psusi> if you trust the guy who has been going by the name Phillip Susi and using the email address<EMAIL_ADDRESS>and submitting patches for a while enough to give him a ppu status, what difference does it make whether that's the name that's on his birth certificate?
[16:28] <cjwatson> if you've verified a binding with real-world identity then you at least have *some* chance
[16:28] <Daviey> 2 people on my team go by different names to what their legal name was.  When i turned up to a hotel and asked if they had checked in, i was told nobody with those names were staying at the hotel.  I then got worried i was at the wrong hotel :)
[16:29] <cjwatson> it's not likely to be sufficient, but it seems necessary
[16:29] <pitti> psusi: we hand out developer/upload privileges based on that "online identity" indeed
[16:29] <pitti> I'm not actually sure whether we require someone's GPG key to be in the WoT still; we did in the past
[16:30] <pitti> does anybody know?
[16:30] <maco> we do have one developer who went by an alias because he was under 18 and his parents wouldn't let his birth-certificate-name be used online. the key he has under the alias was signed by several ubuntu an debian folks
[16:30] <maco> pitti: debian does, dont think ubuntu does
[16:30] <pitti> maco: that's what I thought, too
[16:33] <stgraber> pitti: I can't remember the DMB ever checking that before granting upload rights to Ubuntu, but maybe it's some part of the procedure that got forgotten over time
[16:33] <pitti> stgraber: I think it makes sense that way
[16:33] <ogra_> we used to have an awful process that involved an attoney and a fax machine in the beginning
[16:34] <pitti> stgraber: we started with WoT before Launchpad
[16:34] <psusi> that reminds me, there was someone working for canonical that lived around here and wanted to meet, and darnit I forgot who
[16:35] <cjwatson> gah, fantasy on the brain, I keep reading that as "Wheel of Time"
[16:35] <psusi> lol, me too ;)
[16:35] <ogra_> better than Wheel of Fortune at least ...
[16:35] <ogra_> (in the light of granting upload rights)
[16:40]  * Laney glares
[16:43] <psusi> is there a list of canonical employees with where they live?
[16:43] <xnox> ogra_: ppu/motu/core-dev should be in the web of trust (the set of debian & ubuntu devs)
[16:44] <xnox> psusi: you want a Debian Developer if you want to become a Debian Maintainer.
[16:44] <xnox> and employment information is private & sensitive information pretty much everywhere in the world.
[16:44] <psusi> yea, I know... I'm just bothered now because I had a convo with a canonical developer a while back and he lived nearby and wanted to meet for a beer some time, and I can't recall who it was now and we never did
[16:57] <arges> tseliot: hi i noticed an ftbfs for nvidia-graphics-drivers. looks like a missing common in the control file. should I create a patch or is somebody else looking at this already?
[17:00] <tseliot> arges: which revision?
[17:00] <arges> tseliot: looks like nvidia-graphics-drivers-310
[17:00] <tseliot> arges: I can see the log now. Weird, let me check
[17:22] <rbasak> Is there an example of dep3 as applied to dpatch somewhere?
[17:26] <xnox> rbasak: dpatch uses it's op DP: description fields and predates dep3 by a long time.
[17:27] <cjwatson> Yeah, I usually just stick them in DP: and don't worry too much about it
[17:27] <xnox> convert to quilt & use dep3, or stay with dpatch + write a bit of text in the description.
[17:27] <xnox> s/op/own/
[17:27] <cjwatson> dpatch is deprecated anyway so the problem should go away over time
[17:28] <rbasak> OK so it's vague and if I just make it human readable it'll be sufficient?
[17:28] <rbasak> I guess I'll just prepend dep3 stuff with ## DP: then
[17:28] <rbasak> Thanks!
[17:31] <cjwatson> rbasak: I normally find prepending DEP-3 headers with DP: is too awkward - I just do free-form text
[17:31] <cjwatson> But whatever
[18:54] <kenvandine> @pilot in
[22:29] <kenvandine> @pilot out
[23:16] <bdrung> sarnold: re bug #1084054 - vlc has a preliminary MRE. the SRU still needs to get build through -security
[23:21] <sarnold> bdrung: hrm, that does sound familiar but now I can't find the documentation that would explain it further
[23:23] <bdrung> sarnold: -proposed will build with -updates, which is not allowed for packages going to -security
[23:29] <sarnold> bdrung: oh, I overlooked the "preliminary MRE" the first read-through, do you have a link handy?
[23:29] <sarnold> (I didn't see it on https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions )
[23:29] <bdrung> that's how i got 2.0.3 in. let me digt out the TB meeting
[23:32] <bdrung> sarnold: http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-07-23-21.14.html
[23:33] <sarnold> bdrung: thanks
[23:54] <xnox> pitti: your @debian.org email doesn't work =(


[08:36] <mup> PR operator#496 closed: Make add_layer()'s "combine" a keyword-only parameter <Created by benhoyt> <Merged by benhoyt> <https://github.com/canonical/operator/pull/496>
[10:37] <mup> Issue operator#498 opened: CharmMeta class needs to be updated for Metadata v2 <Created by jnsgruk> <https://github.com/canonical/operator/issues/498>
[19:49] <mup> PR operator#497 closed: Update service config's "environment" to plain dict <Created by benhoyt> <Merged by benhoyt> <https://github.com/canonical/operator/pull/497>


[00:59] <meoblast001> hi
[03:41] <LaserJock> bryce: around?
[03:42] <bryce> indeed
[06:00] <pitti> Good morning
[07:20] <TheMuso> pitti: I see there are currently no studio alpha images on the tracker to test. Has the tracker even been updated for ubuntu/kubuntu etc images yet, or is it just studio that hasn't been updated?
[07:22] <pitti> TheMuso: I think I just missed it, hang on
[07:23] <pitti> TheMuso: http://cdimage.ubuntu.com/ubuntustudio/daily/20090722.1/ should hopefully work
[07:23] <pitti> TheMuso: added to tracker, thanks
[07:23] <TheMuso> pitti: np thanks.
[07:26] <superm1> pitti, i may have some livecd-rootfs changes that will fix one of serious bugs for mythbuntu ISOs. i'm verifying right now that it actually fixes things with a local run of livecd-rootfs
[07:33] <pitti> superm1: thanks; infinity, would a livecd-rootfs upload need any manual treatment for the buildds, or does it "just happen"?
[07:34] <StevenK> pitti: The buildds will upgrade once a day for livecd-rootfs, but it's at like 1:15am DC time
[07:34] <pitti> StevenK: ah, thanks
[07:43] <pitti> superm1: bug 403289, that wasn't due to gdm then? gdm was recently fixed to not pull in gnome-session any more
[07:44] <superm1> pitti, i think it's because somehow a recommends is pulling in a whole bunch of gnome because of the order of dependency resolution for live disk builds
[07:45] <superm1> because mythbuntu doesn't use the tasks for LIST and LIVELIST (some problems earlier this year with doing so)
[07:45] <pitti> superm1: you're using custom.conf in bug 403290 now?
[07:45] <pitti> superm1: (sorry, gdm.conf and gdm-cdd.conf have gone entirely)
[07:45] <superm1> as for bug 403290, yeah i've adjusted the code to use custom.conf
[07:45] <superm1> didn't realize gdm-cdd.conf was gone entirely, will be uploading to fix that bug shortly
[07:46] <superm1> with gdm-cdd.conf being gone, i'm not sure how to fix or even address bug 403291 though
[07:47] <StevenK> pitti: Autologin is completly broken for UNR too
[07:47] <StevenK> pitti: But I suspect you knew that already :-)
[07:48]  * ogra hugs pitti
[07:48] <pitti> StevenK: just trawling through the bugs
[07:48] <ogra> pitti, thanks for moving udhcpc
[07:49] <StevenK> superm1: Hmm, perhaps your seeds need some clean up to stop metacity and co getting installed?
[07:49] <pitti> no prob, got approved recently
[07:50] <ogra> it will indeed bloat the alternate CD ... with 23k more :)
[07:51] <superm1> StevenK, any easy way to do such things?
[07:51] <StevenK> superm1: Easiest way is to check the germinate output, since it contains a "Why" column
[07:52] <StevenK> superm1: http://people.canonical.com/~ubuntu-archive//germinate-output/mythbuntu.karmic/all
[07:52] <pitti> StevenK: autologin> you mean bug 403309 ?
[07:52] <superm1> but since we install with metapackages rather than tasks, is that valid?
[07:52] <pitti> StevenK: (just asked for custom.conf there)
[07:52] <ogra> mvo, !
[07:52] <ogra> the man i wanted to talk to !
[07:52] <mvo> hey og
[07:53] <mvo> ra
[07:53] <superm1> StevenK, but i suppose if we can rid them from there we can switch to tasks for livecd-rootfs
[07:53] <ogra> mvo, i want to make it impossible to upgrade from jaunty to karmic for certain armel machines, can you point me to the right place to put a script that checks /proc/cpuinfo ?
[07:54] <superm1> StevenK, so in looking through that, it claims that metacity comes in from gnome-control-center which comes from gnome-panel, which comes from gnome-panel-dbg, but it doesn't go any further up the chain, so how do I rid that out of there?
[07:55] <StevenK> superm1: Yeah, I sort of fell over there too
[07:56] <mvo> ogra: upate-manager and there DistUpgrade/DistUpgradeQuirks.py - if you give me the details (what to look for in cpuinfo)  I can add it quickly for you if oyu want
[07:56] <superm1> StevenK, so perhaps is there a way I can just blacklist gnome-panel from the seed and hope for the best then?
[07:58] <ogra> mvo, i'll work out a patch for you, essentially it should block if the "Processor" line of /proc/cpuinfo contains anything thats smaller than ARMv6 or ARMv7, thanks for the pointer
[07:58] <mvo> ogra: ok, thanks
[08:00] <pitti> superm1: my feeling is that it's not worth re-rolling the isos just for bug 403290, since a mere upgrade will fix it as well; WDYT?
[08:00] <pitti> StevenK: UNR uses autologin by default, which would make bug 403309 kind of a showstopper?
[08:01] <superm1> pitti, agree, not just for bug 403290.  bug 403289 and bug 403291 however if a solution can be came up with would be worth a reroll
[08:01] <pitti> StevenK: I'm trying to understand where the autologin configuration happens (gdm itself works just fine with autologin, but behaves that way if you specify an invalid user)
[08:01] <StevenK> pitti: The livecd does, but doesn't desktop also do that?
[08:01] <pitti> superm1: right; bug 403291 might need gdm changes, let me check the code about the default session
[08:02] <pitti> StevenK: it works there (we don't default to it, too)
[08:02] <pitti> StevenK: I recently fixed that in user-setup (which wrote "AutomaticLogin=ubuntu" instead of $USER)
[08:02] <StevenK> Ahh
[08:02] <StevenK> pitti: Right, so it sounds good to get a re-roll for this
[08:03] <pitti> StevenK: might it be that this bug somehow crept into the UNR image builder as well?
[08:03] <pitti> StevenK: I don't really know how the .img is put together, I'm afraid; is that a standard live system with ubiquity?
[08:03] <pitti> StevenK: oh argh, http://cdimage.ubuntu.com/ubuntu-netbook-remix/daily-live/20090722/karmic-netbook-remix-i386.manifest
[08:03] <pitti> indeed, it has the old ubiquity
[08:04] <StevenK> pitti: Karmic UNR is now an .iso
[08:04] <pitti> StevenK: so, if I re-roll them now, can someone test the new images soon?
[08:04] <StevenK> pitti: Sure
[08:04] <pitti> started
[08:05] <pitti> I'll fiddle the bugs now
[08:05] <superm1> StevenK, is there a nice command I can run to generate that germinate output myself so I can tweak with adding packages to blacklist in mythbuntu.karmic and seeing if that improves things?
[08:06] <StevenK> superm1: That bit I'm not sure about, sorry
[08:16] <pitti> superm1: I followed up to bug 403291 with the gdm analysis, FYI
[08:16] <pitti> superm1: however, I don't think we'll manage to fix this in the next couple of hours, TBH
[08:17] <pitti> superm1: so perhaps mythbuntu A3 could/should be released later? or you just skip A3 entirely?
[08:17] <superm1> pitti, if 403289 can be sorted out, we can go out a little later, otherwise we'll have to skip A3
[08:18] <superm1> based on your analysis, i agree that bug 403291 would likely be a moot point if 403289 is solved
[08:18] <pitti> superm1: I'm just on holiday from tomorrow until Tuesday, so we'd have to defer it for a bit
[08:19] <superm1> pitti, ah i see.  well i'll spend a little more tonight playing more with germinate.  if no luck then we'll plan to evaluate options after the weekend then
[08:19] <superm1> and i'll discuss it with my team and see what they think is the best
[08:19] <pitti> superm1: I'm sorry for that :/
[08:31] <pitti> lol, I just got two spam mails from facebook which want to become friends with "Apport"
[08:32] <ttx> pitti: we should start a LP group first. 'Apport facebook friends'
[08:32] <pitti> neither Apport nor me personally have ever come close to Facebook, so I wonder why I get these now :/
[08:33] <ttx> beh
[08:35] <pitti> StevenK: http://cdimage.ubuntu.com/ubuntu-netbook-remix/daily-live/20090723/ (also added to tracker)
[08:36] <StevenK> pitti: Thanks!
[08:36] <pitti> would be cool if you could give them a quick test
[08:58] <pitti> TheMuso: hm, I don't see ubuntustudio in earlier alpha announcements, how is that usually handled? do you send our your own announcement?
[08:59] <pitti> TheMuso: then again, there's no karmic/ on http://cdimage.ubuntu.com/ubuntustudio/releases/
[09:10] <superm1> pitti, okay it appears that the livecd-rootfs change i made got rid of most of the gnome stuff and kept what mattered
[09:11] <pitti> superm1: nice
[09:11] <superm1> so if you can reroll with the newer livecd-rootfs, I can grab in the morning and verify
[09:11] <pitti> superm1: as StevenK said, the buildds will only upgrade in about 15 hours :/
[09:12] <pitti> so, plenty of time to get it tested and uploaded
[09:12] <pitti> superm1: but that way you could annouce mythbuntu alpha-3 on Monday or so
[09:12] <superm1> pitti, okay that should be fine.  gives extra time to mirror and what not too after testing
[09:12] <pitti> superm1: I won't be there, but I'm sure Riddell or someone else will push the publish-release button for you
[09:13] <StevenK> pitti: But it can be done manually
[09:13] <pitti> StevenK: right, but both lamont and infinity are asleep right now
[09:15] <TheMuso> pitti: we didn't release previous alphas due to problems that hadn't been addressed by the time those alphas came out
[09:15] <TheMuso> related to the realtime kernel
[09:15] <pitti> TheMuso: ah, so want me to release this one now?
[09:46] <tseliot> pitti: if I wanted to add the support for collecting data from touchpads to apport, what part of apport should I work on?
[09:46] <pitti> tseliot: package hook for xserver-xorg-input-synaptic?
[09:46] <tseliot> pitti: yes, exactly
[09:47] <pitti> tseliot: it probably should be added to the generic xorg package hook
[09:47] <pitti> /usr/share/apport/package-hooks/source_xorg.py
[09:47] <pitti> tseliot: all other X packages symlink to that
[09:47] <pitti> tseliot: it's in x11-common I think
[09:47] <pitti> (dpkg -S)
[09:48] <tseliot> pitti: also, could I add a small C program (with no external dependencies) that I wrote?
[09:49] <tseliot> it simply uses a system call to extract data from the touchpad
[09:49] <pitti> tseliot: you can't do that in Python?
[09:49] <pitti> tseliot: the package is currently arch:all
[09:49] <pitti> tseliot: but of course you could add that helper to the -synaptics package, and call it from the hook
[09:50] <tseliot> pitti: no, it can't be done from Python
[09:50] <tseliot> pitti: but yes, I can add it to -synaptics as you say
[09:51] <pitti> tseliot: what does it need to do?
[09:52] <tseliot> pitti: the C program lists input devices and extracts their ids, names, etc.
[09:53] <tseliot> this would be useful for quirks
[09:53] <tseliot> furthermore I would like to collect the output of xinput too
[09:53] <pitti> tseliot: isn't that pretty much what udevadm gives you arleady?
[09:54] <tseliot> pitti: it's what lsinputs does but I stripped it down and changed a few things
[10:02] <tseliot> pitti: I've just tried udevadm but it doesn't give me what I need
[10:08] <pitti> TheMuso: did anyone test the current studio images? iso tracker says 0/4
[10:20] <pitti> StevenK: does the current UNR image now do what it should?
[10:20]  * ccheney is so tired
[10:20] <ccheney> been up since Jul 22 13:00 UTC
[10:21] <StevenK> pitti: I'm still having a look
[10:21] <ccheney> another 9-10 hour before i can go to sleep too :-\
[10:22] <pitti> ccheney: jetlag?
[10:22] <ccheney> pitti: i can't sleep on planes and flew to madrid then have a 6 hour layover before the train to caceres
[10:24] <ccheney> really its more  i can't sleep sitting up
[10:24] <pitti> ccheney: ah, debconf?
[10:24] <ccheney> yea
[10:32] <ogra> ccheney, july 22 ? which year ?
[10:34] <ccheney> ogra: er yesterday ;-P
[10:34] <ccheney> so about 30 hour or so when i finally get to the hotel
[10:36] <StevenK> ccheney: Not even things like Melatonin help?
[10:37] <glatzor> servus mvo
[10:37] <pitti> hey glatzor
[10:38] <glatzor> mvo, I reimplemented the twisted deferreds using the gobject main loop
[10:38] <ccheney> StevenK: i didn't try it this time but in the past it didn't seem to
[10:39] <Keybuk> pitti: why is there a udev task on bug #403381 ?
[10:39] <pitti> udev? that's wrong
[10:39] <ccheney> StevenK: of course my flight wasn't that long just managed to lose the night in the process, the main flight started at the equivalent of ~ 4pm for me and was only 7-8 hr long
[10:39] <Keybuk> pitti: you added it ;-)
[10:39] <pitti> argh
[10:40] <pitti> Keybuk: accidentally clicked on a canned response, sorry
[10:40] <pitti> fixed
[10:40] <pitti> but I'm sure that we could have fixed it in udev as well :-P
[10:40] <mvo> hey glatzor
[10:40] <mvo> glatzor: you rock!
[10:40] <ccheney> StevenK: melatonin seems to help reset my internal clock though when i finally do go to bed after travelling
[10:40]  * mvo hugs g'magic'tzor
[10:40] <glatzor> servus pitti
[11:05] <dpm> morning pitti, I'm having a look at the translations imports queue for karmic, and I've noticed a few debian/po-up/patches.pot (for e.g. gnome-panel) and similar templates. Without having had a closer look at it before, I always assumed that patches were first applied and then a single template was produced (when the package had only one). Is this something new or am I missing the point?
[11:05] <dpm> what are those templates?
[11:07] <seb128> dpm, those are a debian thing to do translations for debian changes
[11:10] <dpm> seb128: is this a common practice? Could we somehow track the Ubuntu/Debian translation changes due to patches with those?
[11:10] <seb128> dpm, no it's marginal I think we should not bother and just use launchpad
[11:16] <dpm> seb128: ok, thanks. I was just wondering, because (without having thought oo much on the implementation) perhaps it could be used to mark in Rosetts those strings which are only specific to Ubuntu. But then again, it might also introduce a special case in Launchpad which would not be desirable.
[11:17] <seb128> dpm, all debian changes are not marked this way though
[11:19] <dpm> ok, but within a single package which produces a separate .pot for patches, are generally all changes which affect strings collected in a single separate template?
[11:22] <seb128> dpm, it seems so
[11:24] <StevenK> pitti: Autologin looks great with the new spin
[11:24] <pitti> \o/
[11:25] <dpm> seb128: is it trivial to produce those separate templates for patches? I'm just wondering whether it would be useful to try to generalise that practice
[11:26] <seb128> dpm, should be trivial, it's a one line cdbs rules
[11:27] <seb128> dpm, I've not been looking to much into that I don't want po in the source package since that means you need upload to change translations
[11:27] <seb128> dpm, debian do that because they have no language packs they can use
[11:31] <pitti> StevenK, lool: http://cdimage.ubuntu.com/releases/karmic/alpha-3/ currently talks about the UNR "CD"
[11:31] <pitti> given that it's way over 700 MB, what should it say instead? Are people expected to use usb-creator to write an image?
[11:32] <dpm> seb128: but this would just introduce a change in which we have the same situation as now (package produces a pot on build) plus a second template for the patches also generated on build, wouldn't it? Is it not how it is done in gnome-session? That's one of the packages where I first spotted this additional template.
[11:33] <seb128> dpm, I don't know the specific, I never used the system, it just add lot of cruft in the source package since it build template and po for all of those in the debian directory
[11:33] <seb128> dpm, look the gnome-session source for details
[11:34] <dpm> seb128: I'll do, thanks
[11:34] <seb128> dpm, in fact I was cleaning that cruft out in some packages when I resynced on debian, I think it doesn't bring us anything and is noisy
[11:35] <pitti> Riddell: is there an equivalent for usb-creator in Kubuntu?
[11:35] <pitti> i. e. something that people can use to put an .iso to an USB stick?
[11:36] <seb128> pitti, the bzr version of usb-creator has a kde variant now
[11:37] <seb128> pitti, I'm waiting for that to land in karmic for some weeks now to switch it to gtkbuilder dunno why they don't upload to karmic
[11:37] <seb128> evand, ^
[11:37] <pitti> so how do KDE folks test these images then?
[11:38] <dpm> seb128: by cleaning that cruft you mean getting the package to build one single pot as usual? I think this might be the best approach for now, as otherwise I don't know what to do with those extra templates in the import queue. I think it might be worth considering if they might be useful in the future as I was saying earlier, but for now it think it might be best to stick to the more general practice of building one single template
[11:38] <evand> seb128: I'll do it now.  I've been hoping to finish the devicekit backend first, but that's not going to happen quickly
[11:38] <pitti> StevenK, lool: please cross-check http://cdimage.ubuntu.com/releases/karmic/alpha-3/, I updated the desdcription
[11:39] <seb128> evand, thanks, will you port the gnomevfs code to gvfs? or patches are welcome for that? same for gtkbuilder
[11:39] <evand> patches are welcome, but if no one else steps up, I'll surely fix those problems before UI freeze
[11:39] <pitti> evand: you are actually using dk-disks, or libgdu? (the latter should be much nicer)
[11:39]  * Riddell just tests netbook images from DVDs currently
[11:39] <evand> pitti: dbus to devicekit
[11:40] <pitti> evand: devicekit-disks, I assume
[11:40] <evand> err devicekit-disks
[11:40] <pitti> ok
[11:40] <evand> yes
[11:40] <seb128> evand, ok, I will rank it low on my list, I would prefer to focus on things which will not get done otherwise ;-)
[11:40] <evand> seb128: sure thing :)
[11:40] <pitti> Riddell: ok, I'm fine with changing the text to "DVD", if that's fine with you for alpha-3?
[11:40] <ogra> pitti, does devicekit-power still have APM support or did it completely switch to ACPI only ?
[11:40] <seb128> evand, in fact I did the gtkbuilder conversion locally but you have a very weird hack which I blocked on
[11:40] <evand> oh?
[11:41] <seb128> evand, some
[11:41] <seb128>         for widget in self.builder.get_objects():
[11:41] <seb128>             if isinstance(widget, gtk.Label):
[11:41] <seb128>                 widget.set_property('can-focus', False)
[11:41] <seb128> evand, that's the non working gtkbuilder version
[11:41] <evand> ahh, that can probably go away
[11:41] <Riddell> pitti: have the UNR guys expressed an opinion?
[11:41] <pitti> ogra: well, neither really; it just uses /sysfs
[11:41] <evand> it was there to address a bug in ubiquity, if memory serves
[11:42] <evand> and it somehow got copied over
[11:42] <pitti> Riddell: I pinged them above, but no response yet; I changed it to usb-creator for now
[11:42] <seb128> evand, well it seems it's to make text not being selected when using tab
[11:42] <ogra> pitti, oh, i thought it inly looked in the acpi subpaths
[11:42] <seb128> evand, but if gtk does it that's for a reason, ie no need to try to change it by weird hacks in your software, better to be consistent with other applications
[11:42] <pitti> ogra: sysfs_get_string (native_path, "status") for battery status, etc.
[11:43] <evand> seb128: indeed
[11:43] <pitti> ogra: and pm-utils for the suspend/resume stuff
[11:43] <evand> I'll tear it out in trunk
[11:43] <pitti> (which also uses sysfs)
[11:43] <ogra> ah, ok so it doesnt restrict itself to /sys/bus/acpi/
[11:43] <ogra> (i'll likely need to look into APM support for armel)
[11:44] <pitti> i. e. whatever is behind (APM/ACPI) should export proper sysfs attributes, then it should just work
[11:44] <mat_t> Keybuk: hi
[11:44] <ogra> yep
[11:44] <ogra> so its a kernel thing then, thanks
[11:44] <Keybuk> mat_t: hi
[11:44] <mat_t> Keybuk: is there a maximum number of legacy OSs that can be installed at the time?
[11:44] <ogra> (or udev FWIW)
[11:44] <pitti> ogra: udev can't change /sys
[11:45] <ogra> ok
[11:45] <mat_t> Keybuk: I'm asking primarily in the context of the OS switcher
[11:49] <Keybuk> mat_t: is there a maximum length to a piece of string?
[11:49] <lool> pitti: Looks good
[11:50] <lool> pitti: "Choose this if you are at all unsure." in the only UNR image is a bit too much
[11:50] <Keybuk> mat_t: any limit I tell you today will almost certainly be wrong in a year's time ;-)
[11:50] <mat_t> Keybuk: I see
[11:50] <pitti> lool: heh, ok
[11:50] <Keybuk> mat_t: so design and code for no limit
[11:50] <lool> Otherwise ok
[11:50] <pitti> lool: removed
[11:50] <lool> (I wonder where the up to 10" comes from though)
[11:51] <mat_t> Keybuk: perfect, thanks :)
[11:51] <lool> I've seen people run UNR on regular laptops :)
[11:53] <StevenK> lool: It's probably hysterical raisins now
[11:54] <sebner> pitti: seems there is now also a workaround for me :) (regarding the external harddrive problem - you are debugging it with someone else again)
[11:55] <pitti> sebner: bug 387161? what is it?
[11:56] <sebner> pitti: yep, just discovered that my bug was marked as duplicated of this bug, /me is going to uninstall devicekit-disks later to see if this also fixes the issue for me
[11:57] <pitti> it's just a short-term workaround, though
[11:59] <sebner> pitti: of course but better than nothing. /me is just wondering why this is working because I thought devicekit-disks is *needed* to deal with hardware
[12:03] <pitti> sebner: right, gnome is using it now
[12:04] <sebner> pitti: why is a external drive then working when it is needed for hardware and gnome using it? ^^
[12:05] <pitti> sebner: that's a miracle
[12:06] <sebner> lol
[12:07] <sebner> pitti: the magic of open source? *cough*   might it have any negative effects if I remove it, besides that it might fix my external harddrive?
[12:07] <pitti> sebner: did you reboot after removal? or sudo killall devkit-disks-daemon?
[12:07] <pitti> gvfs doesn't build the hal monitor any more
[12:07] <sebner> pitti: didn't remove it yet
[12:07] <pitti> so it shouldn't be able to detect usb sticks and the like any more
[12:07] <pitti> oh
[12:11] <sebner> pitti: so downgrading gfvs as well?
[12:12] <pitti> sebner: you probably need to
[12:12] <sebner> pitti: argh, removing devicekit-disks will remove half of my system
[12:12] <pitti> sebner: well, you can't remove dk-disks without removing gvfs, it's a dependency
[12:12] <pitti> and GNOME depends on gvfs
[12:12] <pitti> anyway, food time
[12:12] <sebner> pitti: it seemed possible though ?!
[12:12] <sebner> hf
[12:21] <tseliot> pitti: my program requires root privileges. Can it still be used by an apport hook?
[13:28] <maxb> The postgresql-common upload to karmic today - why is that 100.1 instead of 100ubuntu1 ?
[13:29] <mok0> maxb, probably a nmu
[13:29] <maxb> mok0: I don't understand
[13:30] <maxb> It was a direct upload to Ubuntu, not a sync
[13:31] <mok0> maxb: merged nmu?
[13:32] <maxb> A merge would normally still have "ubuntu" in its version string
[13:32] <geser> maxb: probably a glitch from pitti as he's also the debian maintainer for it
[13:32] <mok0> maxb, it's an nmu synced from debian afacs
[13:33] <maxb> mok0: The changesfile lists the distribution as karmic, so I prefer geser's explanation
[13:34] <maxb> Also, "100.1" isn't a nmu version string
[13:34] <mok0> maxb. yeah
[13:34] <mok0> maxb: 100 is latest debian release
[13:35] <maxb> yup. A nmu would be labelled as 100+nmu1
[13:36] <mok0> maxb, I assumed you were quoting a version string before checking
[13:36] <maxb> I was quoting a version string?
[13:36] <mok0> maxb: no :-)
[13:37] <maxb> Sorry, I mean: I *was* quoting a version string, are you suggesting I wasn't?
[13:37] <mok0> maxb I thought you were quoting the release part of the version string
[13:38] <maxb> aha :-)
[13:38] <mok0> maxb, I was wondering about the huge number
[13:38] <maxb> mm, 100 debian revisions for a single upstream would be impressive
[13:39] <maxb> though sysvinit is more than half way there
[13:40] <geser> cron is at -106 already
[13:41] <mok0> implies very low upstream activity
[13:42] <mok0> the postgresql-common problem is discussed  in bug 403381
[13:43] <mok0> looks like it could be a temporary fix
[13:43] <mok0> and that pitti wants it to go away automatically at next sync
[13:43] <geser> very low activity indeed: -35 was uploaded in Dec 1996 (the Debian changelog doesn't reach further back)
[13:44] <mok0> geser: cron is a legacy package now, right?
[13:44] <hyperair> it is? why would it be?
[13:45] <mok0> Because anacron is being installed by default
[13:45] <mok0> And aren't there discussions about moving to Apple's launchd ?
[13:46] <hyperair> don't they do separate things?
[13:46] <mok0> hyperair: afaik launchd is a reimplementation of cron
[13:47] <hyperair> is it?
[13:47] <hyperair> hmm
[13:47] <hyperair> (i was referring to anacron vs cron)
[13:47] <mok0> but with better security and flexibility
[13:47] <ion> launchd is more than crond.
[13:47] <mok0> hyperair: ah
[13:47] <hyperair> what's wrong with crond?
[13:47] <hyperair> and we don't have a launchd package around, do we?
[13:48] <mok0> hyperair: I imagine it has something to do with the /etc/cron.d/ directories
[13:48] <hyperair> hmm
[13:48] <hyperair> oh yeah, that.
[13:48] <mok0> hyperair: so packages can drop files in there
[13:48] <hyperair> so how would you secure something of that sort?
[13:48] <hyperair> without losing the said functionality
[13:49]  * mok0 googles crond vs launchd
[13:49] <pitti> tseliot: no, I'm afraid not
[13:49] <ion> Upstart will implement the cron/at/anacron/whatever functionality in the future. Upstart’s design is better than launchd’s IMO.
[13:49] <pitti> geser:, maxb, mok0: it was a bzr head snapshot
[13:50] <pitti> no reason to upload to debian for just that
[13:50] <pitti> and the next time it will autosync, right
[13:50] <tseliot> pitti: ok, thanks
[13:50] <mok0> http://arstechnica.com/apple/reviews/2005/04/macosx-10-4.ars/5
[13:51] <ogra> mvo, mind to take a look at http://paste.ubuntu.com/227208/ ?
[13:52] <ion> mok0, hyperair: http://www.netsplit.com/2006/08/26/upstart-in-universe/ heading “How does it differ from launchd?”
[13:54] <glatzor> mvo,  You can take a look at the new code: lp:~aptdaemon-developers/aptdaemon/gdefer
[13:54] <glatzor> mvo, I've only converted the GetTrustedVendorKeys method to the new gobject based deferreds
[13:55] <glatzor> mvo, yet. I am away now for some days! See you.
[13:55] <mok0> ion, ah, so it's upstart rather than launchd
[13:56] <ttx> doko: about doublechecking if a MIR is really needed: I was thinking on reviewing package bug history, is there any better way, like some official list of MIR-ed packages ?
[13:56] <ion> http://upstart.ubuntu.com/faq.html#replace-cron
[13:58] <mok0> ion, oh crond (launchd) capability is _planned_ but not currently in upstart
[13:58] <doko> ttx: I would just look at Sources from jaunty if the package was in main
[13:59] <ion> crond is still not equal to launchd.
[13:59] <ion> In some areas, Upstart is far beyond launchd in functionality.
[13:59] <ttx> doko: ok, thx
[14:00] <mok0> ion, apple uses launchd to replace crond
[14:00] <ion> Yes
[14:01] <ion> As well as inetd and initd.
[14:01] <mok0> ion, didn't know that
[14:01] <mok0> ion, although I am typing this from my Powerbook G4 :-)
[14:07] <hyperair> hmm the article said that upstart was to have reached stage #6 by edgy+2, which was gutsy.
[14:07] <hyperair> that's so long ago, and we're not even there yet! =O
[14:07] <mok0> From upstart webpage "Events may be received from any other process on the system" -- I hope there's a decent authorization system in place
[14:10] <hyperair> what kind of events do you want to limit access to?
[14:12] <ion> The usual. If you have write access to init’s UNIX socket or the system bus, you can talk to init.
[14:13] <ion> /etc/dbus-1/system.d/Upstart.conf
[14:14] <mok0> If a single process controls almost everything, it also gives blackhats more options for making trouble
[14:15] <mok0> Just sayin'
[14:15]  * ogra wonders if mok0 is aware of the PID init had since it existed
[14:15] <hyperair> i wouldn't say that.
[14:16] <hyperair> i think it's more of giving blackhats something to focus on attacking.
[14:16] <hyperair> rather than giving them more options
[14:16] <mok0> ok
[14:16] <ion> Instead of D-Bus handling the access policy, so you have a single chunk of code to audit, every piece of software should NIH its own, so you have to audit all of them?
[14:16] <mvo> ogra: looks good, just commit
[14:16] <ogra> mvo, thanks :) not hard to understand the code :)
[14:18] <mok0> ion, good point
[14:19] <mok0> ion, but the fundamental design better be right
[14:19] <ion> Feel free to inspect the fundamental design.
[14:19] <hyperair> NIH = ?
[14:19] <mok0> ion, I'm not qualified for that
[14:20] <ogra> hyperair, Not Invented Here
[14:20] <Chipzz> ion: I think the fundamental design is broken
[14:20] <Chipzz> but that's just my opinion
[14:20] <hyperair> ah.
[14:20] <hyperair> broken how?
[14:21] <mok0> ion, just slightly concerned when several very well tested systems get replaced by a single piece of software
[14:21] <mok0> ion, NEW software
[14:21] <Chipzz> one central daemon that is needed and when breaks, would call huge amounts of havoc
[14:21] <mok0> Chipzz: exactly
[14:21] <hyperair> that's the entire purpose of init isn't it?
[14:22] <hyperair> if init breaks, you get huge amounts of havoc
[14:22] <mok0> hyperair: yes, but will it work?
[14:22] <Chipzz> hyperair: and the dbus developers have, IIRC, always had a "Distro's go fuck yourself, dbus isn't designed to be restarted" attitude
[14:22] <Chipzz> hyperair: init is a LOT less complex than dbus
[14:22] <mok0> hyperair: init has been tested on? hundreds of mililons of systems?
[14:22] <Chipzz> and now you need dbus and god knows what just to log in
[14:22] <hyperair> mok0: upstart has been ubuntu's init for some time already.
[14:23] <ion> Upstart runs just fine without D-Bus. Even handles D-Bus restarts. Also, Upstart has been running on – how many Ubuntu users are there again? – for many releases by now. Oh, and i bet Upstart has a more comprehensive test suite than sysvinit. :-P
[14:23] <Chipzz> sounds like looking for things to break
[14:23] <Chipzz> ion: I'm not criticizing upstart
[14:23] <mok0> neither am I
[14:23] <Chipzz> my critique is wrt dbus and the whole santa-boutique of *kits
[14:24] <hyperair> upstart isn't about to engulf dbus.
[14:24] <hyperair> i don't see the point of comparing upstart with dbug
[14:24] <hyperair> dbus*
[14:24] <ion> I’m not saying D-Bus doesn’t suck. I’m still quite confident D-Bus won’t let $randomuser get root access from Upstart, which seemed to be the original doubt.
[14:24] <mok0> hyperair: ok
[14:24] <Chipzz> I think yesterdays breakage cjwatsons, and who elses? don't recall desktop proved my point very nicely
[14:25] <hyperair> what breakage?
[14:25] <Chipzz> part of ecrypt breaks, and sudo/login get broken
[14:25] <Chipzz> bad
[14:25] <Chipzz> BAD
[14:25] <Chipzz> BAD DESIGN
[14:25] <hyperair> sudo got broken?
[14:25] <hyperair> and i have no interest in ecrypt, so i don't really bother with that
[14:25] <Chipzz> which is why I don't like the whole idea of dbus and the whole bunch of *kits
[14:26] <hyperair> i'm more interested to know what went wrong that caused sudo to break.
[14:26] <Chipzz> read the backlog or ask someone who can give more detail
[14:26] <hyperair> and break in what way
[14:26] <Chipzz> segfault
[14:26] <hyperair> O_o
[14:26] <Chipzz> no logins possible, sudo segfaults
[14:26] <hyperair> i had nothing of that sort.
[14:27] <hyperair> at least, my sudo never segfaulted, and i didn't log out for a very long time
[14:27]  * ogra wouldnt call that an encfs design flaw
[14:27] <ogra> rather a pam one
[14:27] <hyperair> oh it's pam eh.
[14:28] <hyperair> that reminds me. someone was complaining about kdesu breaking in #ubuntu-kernel, claiming it to be the fault of the kernel.
[14:28] <pitti> hyperair: well, a major point of ecryptfs is to hook into the login process, i. e. PAM
[14:28] <ogra> but if you can confuse the login process with a broken third party hook thats a flaw in the login system imho
[14:29] <Chipzz> pitti: reading the backlog pam wasn't involved in that?
[14:29] <pitti> Chipzz: sure, ecryptfs ships a pam module which segfaulted
[14:29]  * hyperair uses cryptsetup-on-lvm
[14:29] <pitti> it wasn't the pam package itself, of course
[14:29] <Chipzz> pitti: then I misunderstood the whole debacle
[14:58] <ttx> pitti: congrats !
[14:58] <pitti> thanks to all involved!
[15:01]  * ogra applauds
[15:03] <DktrKranz> pitti: now that Alpha 3 is out, mind giving a look at bug 401953 when you have some time?
[15:05] <pitti> DktrKranz: oh, that makes a lot of sense
[15:05] <pitti> dpkg apport | grep -- -packages
[15:07] <sebner> pitti: workaround is working now (after downgrading gvfs and uninstalling gvfs), I have mount the harddrive/usb-stick manuall and the sticks are only usable as root but at least it's working :D
[15:07] <pitti> ah
[15:07] <sebner> pitti: uninstalling devicekit-disks of course, sry
[15:08] <pitti> I figured :)
[15:09] <sebner> pitti: I'm curious how long this workaround will be working though
[15:10] <sebner> pitti: or even more when devicekit-disks is fixed :P
[15:11] <Laney> what is the problem?
[15:11] <sebner> Laney: external harddrive not usable. Downgrading gvfs and uninstalling devicekit-disks is the only workaround so far
[15:12] <Laney> interesting
[15:14] <sebner> Laney: annoying might be a better word :P
[15:16] <pitti> sebner: hm, for me it takes some 30 seconds until nautilus can open them, but otherwise they seem to work
[15:16] <pitti> it almost feels like the old gutsy bug where we had to set a special mount option to speed up vfat dir reading from 5 minutes to 2 seconds ("usefree" option)
[15:17] <sebner> pitti: I have to mount them manually so dunno
[15:17] <ion> I wan’t (wannot) getdeb.net indeed.
[15:18] <sebner> pitti: waha! just discovered that they are automounted now (reboot after uninstalling devicekit-disks)
[15:18] <pitti> sebner: sure, by hal
[15:18] <sebner> hal \o/
[15:18] <pitti> or, by gvfs/nautilus through hal
[15:19] <sebner> pitti: /media contains now usb (symlink) and usb0 - usb7 though. dunno why
[15:21] <pitti> sebner: just added some more requests for debug output to bug 387161; perhaps you can do that on a karmic live CD?
[15:22] <ogra> pitti, you mean its not because i'm remotely logged in to his desktop and mounted it ? :)
[15:22] <pitti> ogra: sorry, context?
 or, by gvfs/nautilus through hal
[15:23] <ogra> sorry, bad joke
[15:23] <pitti> ah
[15:23] <sebner> pitti: nah, posting instructions *before* I downgraded :P heh, but of course when I have time I'll try it with a karmic live cd
[15:24] <pitti> sebner: just downgrading gvfs shold be enough, you could leave dk-disks instlaled even
[15:24] <pitti> sebner: and try devkit-disks --mount /dev/sd...
[15:24] <pitti> gvfs/gnome will still use hal
[15:25] <sebner> sounds reasonable
[15:26] <dupondje> gvfs & samba also broken :(
[15:31] <pitti> DktrKranz: hm, after building apport with that patched cdbs, the apport package still has empty ./usr/lib/python2.6/dist-packages/ and ./usr/lib/python2.5/site-packages/ dirs..
[15:32] <pitti> aah, ?.?
[15:50] <cjwatson> apw: just in case any of you guys were thinking about it, please don't turn on CONFIG_X86_PAT :-)
[15:50] <cjwatson> apw: joeyh and I just spent several hours debugging why Debian's d-i wouldn't boot in qemu and Ubuntu's would, and it turned out to be because Debian had enabled CONFIG_X86_PAT
[15:52] <apw> cjwatson, heh thanks for the warning ... on my scarey list
[15:54] <DktrKranz> pitti: yeah, it creates /usr/lib/python?.?/site-packages
[15:54] <ogra> cjwatson, but its more modern than MTRR :P
[16:16] <superm1> pitti, once livecd-rootfs updates on the build machine, will doing the new mythbuntu iso with the updated livecd-rootfs need a manual prod, or is the cron still activated?
[16:22] <Riddell> 19 6 * * *      buildlive mythbuntu; for-project mythbuntu cron.daily-live
[16:23] <Riddell> superm1: so if you wait until 6 tomorrow morning it'll get made
[16:23] <Riddell> or you can just ask me
[16:24] <superm1> Riddell, well if livecd-rootfs updates on the build machine sooner than that, doing it sooner would be better so that we can get testing and mirroring done sooner
[16:25] <superm1> StevenK said it updated at 1:15am DC time
[16:27] <Riddell> superm1: do you want me to do anything?
[16:28] <superm1> Riddell, if you can update livecd-rootfs sooner and kick off a build, that would be good. if you can't update it, then after it updates, kicking a build then would be good
[16:29] <Riddell> after what updates?
[16:29] <superm1> i uploaded a newer livecd-rootfs that is needed to fix bug 403289
[16:29] <superm1> StevenK said that the process to update on the build machine is automatic, but it only happens once a day normally
[16:31] <Riddell> oh hmm, maybe
[16:32] <Riddell> superm1: sounds like a job for a sysadmin, try asking in #canonical-sysadmin ?
[16:32] <superm1> Riddell, okay.  will do
[16:33] <birthdaylogger> james_w: hey, can the gtk-module.so be moved out of the packagekit main package? kpackagekit deps packagkit and packagekit (due to the gtk-module) deps gtk, so gtk ends up in a Kubuntu installation while it should indeed not
[16:41] <rickspencer3> in terms of pythonic design ... is it proper to have a property that gets a different value than it sets
[16:42] <rickspencer3> in this case,  list_of_dicts = couchwidget.selected_rows
[16:42] <rickspencer3> but
[16:42] <rickspencer3> couchwidget.selected_rows = list_if_ints
[16:42] <rickspencer3> ?
[16:42] <rickspencer3> pitti: lool: ^ thoughts?
[16:43] <rickspencer3> oops, I said "value", but meant "type"
[16:51] <lool> rickspencer3: Hmm I think I'd need more context but that's probably ok as long as it's clear from the comments/inline doc
[16:53] <rickspencer3> perhaps selected_rows should be read only ... and select_rows(list_of_ints) would go with it?
[16:55] <dvestal> rickspencer3: The logic of doing that makes sense, but I would probably lean more toward using an "indexes" property to set the selection with a list of indexes. that way you have list_of_dicts = couchwidget.selected_rows and couchwidget.selected_row_indexes = list_of_ints. otherwise something like you just mentioned regarding the read-only property and a setter method.
[16:56] <rickspencer3> dvestal: hmm
[16:56] <dvestal> although, doing it with the indexes property would actually require a setter method anyway to be able to modify the other property.
[16:56] <rickspencer3> in fact, perhaps couchwidget.selected_indexes could be a read/write property?
[16:57] <dvestal> the read-only property and a setter method may be the best way to do it.
[16:57]  * rickspencer3 nods
[16:58] <rickspencer3> or perhaps the whole list_of_ints for indexes is too implementation specific
[16:58] <rickspencer3> the developer should rather provide a list of records to select ... the fact that they are displayed in a treeview with a listmodel shouldn't be exposed in the widget api?
[17:03] <dvestal> rickspencer3: i don't know that a list of indexes is too specific for a list of items, but that's more dependant on how it's being used. i come from more of a web application background; so i tend to lean toward an index + lightweight textual value for lists and that may not be the most appropriate in all circumstances.
[17:27] <kirkland> bryce: hi
[17:28] <kirkland> bryce: what should and shouldn't work, as i insert and remove my thinkpad x200 to/from the docking station with an external monitor
[17:28] <kirkland> (intel video, karmic)
[17:28]  * kirkland misses ctrl-alt-backspace for the first time in a while
[17:45] <maco> hey guys, im trying to do the thing with bzr & debian/changelog & debcommit and then pushing to lp and merge request...what do i put for the release in debian/changelog? "UNRELEASED" or -proposed?
[17:48] <tjaalton> kirkland: c-a-b should work just fine in your session, if you just enable it from the kbd capplet
[18:12] <ogra> jdstrand, why doesnt gufw have a simple "internet connection sharing" checkbox anywhere ? it already makes firewalling a breeze, but NAT seems to be missing
[18:12]  * kirkland is less productive when his sound is broken
[18:13]  * ogra sings a bit for kirkland
[18:13] <kirkland> :-)
[18:13]  * kirkland hugs ogra
[18:13] <ogra> :)
[18:14] <kirkland> anyone else having sound issues?
[18:14] <ogra> worked this morning when i watched the news in flashplayer
[18:15] <ogra> RB works
[18:15] <kirkland> ogra: yeah, that's funny, flash sound is working, but rhythmbox, xmms are not
[18:16] <ogra> just fired up RB
[18:16] <ogra> plays fine
[18:16] <ogra> kirkland, did you check the sound profile ?
[18:16] <ogra> probably these apps are muted
[18:16] <ogra> (we have per app settings now)
[18:17] <kirkland> ogra: where is this magik?
[18:17] <kirkland> sound preferences -> output ?
[18:17] <kirkland> i only have stereo audio
[18:17] <ogra> right click the new volume control
[18:17] <kirkland> right
[18:17] <kirkland> applications
[18:17] <kirkland> "No application is currently playing or recording audio"
[18:17] <ogra> last tab, "applications"
[18:17] <kirkland> which is wrong
[18:17] <ogra> oh
[18:17] <kirkland> firefox/pandora is playing music
[18:18] <ogra> i have firefox-3.5 and RB ... both with volume controls
[18:18]  * kirkland frowns
[18:18] <ogra> probably ask TheMuso
[18:19] <ogra> though its a very bad time for him
[18:23] <kirkland> ogra: okay, thanks
[18:24] <jdstrand> ogra: re gufw> a) I don't develop gufw and b) ufw doesn't support NAT via the cli command yet
[18:25] <ogra> oh, i thought it did
[18:25] <ogra> well, it would be a cool feature to have
[18:25] <jdstrand> ogra: it is planned, but only after all the host-based stuff is there
[18:25] <ogra> ok
[18:26] <ogra> its just something i have to deal often with in #ltsp ... so i was wondering
[18:26] <jdstrand> ogra: specifically filtering by interface (which will be in 0.28) and egress filtering (which will be sometime after that)
[18:26] <ogra> sweet
[18:27] <jdstrand> ogra: there is an example of doing NAT in /usr/share/doc/ufw/README.gz under 'Advanced Configuration', and I'm pretty sure help.ubuntu.com also has a recipe
[18:28] <jdstrand> ogra: ufw can do it (it can do anything iptables-restore can do), it just isn't exposed via the cli command yet
[18:28] <jdstrand> ogra: and therefore gufw doesn't support it yet
[18:29] <ogra> right, but after all users currently seem more comfortable with iptables-save and editing /e/n/i
[18:31] <jdstrand> ogra: whatever someone wants to use to get their work done is fine be me. :) the point I was trying to make is that if you want to use ufw generally, but just want a NAT rule, then you can do that
[18:32] <ogra> well, i would prefer to tell users to do "ufw enable nat" "ufw save" :)
[18:32] <ogra> or something along that
[18:32] <jdstrand> ogra: ack, but not this cycle :)
[18:33] <ogra> understood :)
[18:57] <mathiaz> does anyone has an example of a python package that uses cdbs+distutils?
[18:57] <mathiaz> *have*
[18:57] <pitti> mathiaz: apport, jockey
[18:57] <mathiaz> pitti: thank you :)
[19:02] <mathiaz> pitti: IIUC lp:apport/ is the upstream branch, while lp:~lp:~ubuntu-core-dev/ubuntu/karmic/apport/ubuntu is the packaging branch?
[19:03] <pitti> right
[19:15] <pitti> mbiebl: hm, CK 0.3.1 released, also with PK 1.0; seems we can't hold it back much longer in Debian ..
[19:16] <pitti> just uploaded to ubuntu, but can't commit it to pkg-utopia yet (no polkit-1)
[19:29] <maco> is it normal for changes to exist in -security that dont exist in -proposed
[19:30] <pitti> maco: rare, but happens
[19:30] <pitti> maco: if a package in -proposed doesn't get verified for a while, and a security update comes in between and "shadows" it
[19:30] <kees> maco: if by "changes" you mean non-security-changes, it's like pitti says.
[19:30] <kees> maco: what are you specifically examining?
[19:31] <maco> i just made a change to sudo for hardy-proposed and did a merge request for ubuntu/hardy/sudo/hardy-proposed and found that the diff between what i put and what's in hardy-proposed right now includes your last change in -security, kees
[19:32] <kees> maco: ah, then, yes, -security skips -proposed.  only very rarely will a security update go through -proposed.
[19:32] <maco> oh ok
[19:32] <kees> you need to always base uploads to -proposed on the most recent version in either -updates or -security.
[19:33] <maco> i did it against hardy-updates. its the same as hardy-security though
[19:34] <kees> maco: right, so a diff between the old -proposed version and the new -proposed version will contain the changes between old -proposed and -updates/-security and your new changes.
[19:35] <maco> ok
[19:35] <maco> just didnt expect that
[20:02] <CardinalFang> Hi all.  I have a packaging question.  I have package "foo".  I want to split it into "foo" and "foo-ui".  I want upgraders to get "foo-ui" (which depends on "foo"), but I don't want to require "foo-ui" to be installed for new users or after the upgrade.  What package relationships should I use?
[20:10] <geser> CardinalFang: that seems not to be possible. what might work is renaming "foo" to "foo-backend" (or whatever) and introducing a transitional package "foo" which depends on "foo-ui".
[20:14] <sebner> geser: sebner bot is now a sponsoring bot, already ACKed ~15 sync requests \o/
[20:18] <geser> \o/
[20:19] <geser> sebner: now you also need a sponsoring module for merges :)
[20:20] <sebner> geser: I'll leave soon so I just want to finish until I have 20 ACKs. merges are my victims for tomorrow \o/
[20:20] <kirkland> can someone point me to a step-by-step guide for i18n-ing a package?
[20:20] <geser> does something magical happen at 20 ACKs?
[20:21] <kirkland> i know there's a bunch of gettext calls to add to the shell, python and C
[20:21] <kirkland> there's some po work
[20:21] <kirkland> a fair amount of build and packaging
[20:21] <sebner> geser: well, 20 sounds so much nicer and cleaner than 17 does ;)
[20:21] <kirkland> as well as launchpad setup, etc.
[20:21] <kirkland> i'm hoping someone has written up a best practices guide on making this happen
[20:24] <dpm> kirkland: there's http://live.gnome.org/TranslationProject/DevGuidelines and http://developer.gnome.org/projects/gtp/l10n-guide/, although the latter is really outdated. I'd like to write such a guide for Ubuntu, but this hasn't happened yet.
[20:24] <kirkland> dpm: thanks for the pointers
[20:24] <kirkland> dpm: i'm going to email the list asking for such things; perhaps you can respond there?
[20:26] <dpm> kirkland: sure. We've also already started this with dholbach here -> https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation, but it is really crude at the moment, that's why we haven't announced it yet
[20:27] <kirkland> dpm: i'm happy to be a guinea pig in your development of that documentation
[20:28] <dpm> kirkland: ;) just feel free to ping me or ask anything as well, maybe this will be a good way to see which are the most important sections to cover there
[20:36] <wizztjh> hi , i am a python programmer , how can i help to develop ubuntu?
[20:47] <jjohansen> wizztjh: look around find a project that interests you and start fixing bugs/adding features
[20:47] <jjohansen> wizztjh: the best way really is just finding something interesting and jumping in
[20:48] <wizztjh> i now browsing MOTU , where can i join the project
[20:49] <jjohansen> which project?
[20:50] <jjohansen> if you mean MOTU https://wiki.ubuntu.com/MOTU/GettingStarted
[21:39] <bryce> anyone know if there is a test bugzilla up running anywhere?  I'm doing a script to upstream bugs from lp but don't want to irritate freedesktop.org with a bunch of test posts


[00:51] <lool> Is MIC in a bzr branch on our side?  I couldn't find one and would like to do some changes
[13:58] <bspencer> Mithrandir, ping
[13:59] <bspencer> Mithrandir, who should I talk to about getting a GL-enabled xephyr for the target?
[14:00] <bspencer> (   http://dodji.blogspot.com/2007/10/xephyr-xvideo-and-gl-has-landed.html   )
[14:01] <Mithrandir> bspencer: bryce, probably
[17:09] <lool> Mithrandir: Can you please pull from http://bazaar.launchpad.net/~lool/ubuntu-seeds/ubuntu.hardy ?
[17:09] <lool> Mithrandir: Or add moblin-applets to the mobile seed
[17:39] <Mithrandir> lool: sure
[17:41] <lool> Mithrandir: Thanks
[17:43] <Mithrandir> I just... need to get my gpg setup working here.
[19:15] <HappyCamp_2> agoliveira: ping
[19:17] <lool> HappyCamp_2: He's speaking!


[03:05] <sadleder> hi all, what happened to upstart lately
[03:46] <Keybuk> oddly enough, I'm writing a mail to the list right now about that ;)
[03:46] <ion_> :-)
[03:54] <Keybuk> though, since it has a lot to say, it may be a few hours off yet


[05:17] <mborzecki> morning
[05:35] <mardy> hi!
[05:45] <mborzecki> mardy: heya
[07:09] <pstolowski> morning
[07:15] <zyga> good morning
[07:19] <mvo> good morning pstolowski and zyga
[07:19] <zyga> mvo, I've sent some fixes for spread
[07:19] <zyga> mvo, mainly go vet stuff for now
[07:19] <mvo> zyga: yeah, just vaw it
[07:19] <mvo> saw
[07:20] <zyga> mvo, https://github.com/snapcore/spread/pull/117 is a real tiny bug
[07:20] <zyga> mvo, some more in humbox
[07:20] <zyga> mvo, all of this is from go vet reporting things
[07:21] <mvo> zyga: looking
[07:21] <zyga> mvo, I've also started looking at what it takes to fix https://github.com/snapcore/spread/issues/119
[07:22] <zyga> mvo, I'll try to enable travis-ci.com on my fork first
[07:22] <mvo> zyga: we have https://github.com/snapcore/spread/pull/107 that would also work, yes?
[07:23] <mvo> zyga: or is there a reason to stay with travis?
[07:23] <zyga> ah, I missed that, yes
[07:24] <zyga> mvo, older but relevant fix is also here https://github.com/snapcore/spread/pull/111
[07:24] <mvo> zyga: looking
[07:25] <mborzecki> mvo: zyga: pstolowski: morning guys
[07:25] <zyga> mborzecki, hey :)
[07:26]  * zyga is still sick, so so-so morning ;)
[07:27] <mvo> mborzecki: good morning
[07:27] <mvo> zyga: uh, get well!
[07:27] <mardy> mvo: I added a new section with some ideas in the mount-control document, it would be nice if you had a look
[07:28] <mardy> oh, and hi mvo, zyga, pstolowski :-)
[07:29] <zyga> hey mardy
[07:34] <mvo> good morning mardy ! let me check
[07:35] <mvo> zyga: I think I will mark a bunch of yours as "ready" and see if I can have another review meeting with gustavo
[07:35] <mvo> mardy: this is the "Suggestion for generating mount units" section ?
[07:38] <mardy> mvo: yes
[07:40] <zyga> mvo, thank you!
[07:46] <mardy> mvo: BTW, I think that the failures in https://github.com/snapcore/snapd/pull/10375 are not due to my changes (maybe you can double-check), so please consider whether you should use your magic powers on it
[07:47] <mvo> mardy: sure, looking
[07:48] <mardy> mvo: but if you merge, please squash :-)
[07:49] <mvo> mardy: the 14.04 test failure is real, there is no systemd-run on 14.04 so the fake store setup will not work, I think it's okay to exclude 14.04
[07:50] <mvo> mardy: i.e. just something like "systems: [-ubuntu-14.04-*]
[07:50] <mvo> mardy: but let me look at the others too
[07:51] <mvo> mardy: I can also do this if you want
[07:54] <mvo> mardy: the debian-10 failure also looks real, I don't remember the detail here though, i.e. where/why we check for the right libseccomp
[07:55] <mvo> mardy: and on all of the cores I think theere is a failure in "userdel -f snap_microk8s" - I think "userdel --extrausers -f snap_microk8s" is needed here
[07:56] <mardy> mvo: let me have a look
[08:06] <mborzecki> mvo: can you take a look at https://github.com/snapcore/snapd/pull/10481 ?
[08:15] <mvo> mborzecki: added it to my list :)
[08:15] <mvo> mborzecki: not sure if I manage before lunch though :/
[08:19] <mborzecki> mvo: sure
[08:19] <mborzecki> thanks!
[09:41] <mborzecki> mvo: pstolowski: also a very simple PR https://github.com/snapcore/snapd/pull/10489
[09:43] <pstolowski> sure
[10:21] <mardy_2nd> sorry if I missed this, but are the spread failures on tests/main/refresh-delta known issues?
[10:32] <mvo> mardy: I don't think they are
[10:32] <mvo> mardy: but the 14.04 test is still unhappy :)
[10:35] <mvo> mardy: it looks like deltas were pruned this morning by the store
[10:35] <mvo> mardy: let's see if they come back
[10:41] <mvo> mardy: maybe you can push the fix for ubuntu-14.04 (just exclude it)
[10:41] <mvo> mardy: and then we will see if the store auto-regenerates the relevant deltas
[10:47] <mvo> mardy: just talked to the store and the failure to get the deltas is being investigated (and it seems also understood)
[12:28] <mborzecki> mardy: i think you reviewed the other s-c PR, can you take a look at https://github.com/snapcore/snapd/pull/10492 ?
[12:57] <mardy> mborzecki: will continue right after the standup
[13:54] <mborzecki> deltas aren't available? i see a bunch of refresh-delta tests failing across all systems
[13:57] <mvo> mborzecki: they should be back
[14:24] <pedronis> ijohnson[m]: I reviewed https://github.com/snapcore/snapd/pull/10488 it needs some more work I think
[15:02] <mborzecki> pedronis: pushed a tweak to https://github.com/snapcore/snapd/pull/10469
[15:02] <mborzecki> and thanks for the review!
[15:07] <pedronis> mborzecki: are there real failures in https://github.com/snapcore/snapd/pull/10481 ?
[15:09] <mborzecki> pedronis: you mean the cloud config tests? they all seem to fail on acking the snap declarations signed by developer 1
[15:11] <pedronis> mborzecki: are you saying they fail on master too?
[15:12] <mborzecki> hm let's see if i can find a branch that fails that way too
[15:13] <mborzecki> if not i'll investigate, but it's unclear how snap ack can be influenced by those changes in boot
[15:22] <mardy> how do the files /var/lib/snapd/apparmor/profiles/snap-update-ns.* contribute to the apparmor profile? In other words, when are these rules loaded?
[15:26] <pstolowski> mardy: snap-confine runs snap-update-ns before running snap app, see also the description at the top of every snap-update-ns.* profile (Description: Allows snap-update-ns ....)
[15:29] <pstolowski> mardy: also look at the comments about snap-update-ns in snap-confine.c
[15:29] <mardy> pstolowski: mmm... so, this is the profile under which snap-update-ns will be run for the specific snap, and has little (if not nothing) to do with the profile of the snap itself?
[15:39] <pstolowski> mardy: yes i think so, its only use is to set up mount namespaces, maybe mborzecki can confirm
[16:03] <mvo> zyga: can you please review spread#116? would love to mark it "ready" for gustavo but for that it needs at least one +1
[16:06] <zyga> mvo, looking
[16:06] <zyga> mvo, and *thank you* for asking :)
[16:14] <zyga> done
[16:15] <zyga> mvo, thank you for pushing tests on some of the refactors and fixes
[16:16] <zyga> mvo, I have some tests lined up but mainly for the all-new exporter logic
[16:16] <zyga> mvo, make sure to review https://github.com/snapcore/spread/pulls as it's one of the more serious problems reported by vet
[16:28]  * cachio lunch
[17:13] <pstolowski> cachio: i've addressed your comments https://github.com/snapcore/snapd/pull/10476, please take another look
[17:15] <cachio> pstolowski, sure
[17:15] <cachio> thanks
[17:19] <cachio> pstolowski, hey
[17:19] <cachio> why are you locating tests/lib/snaps/store/test-snapd-refresh-control-provider.v1/build-aux/snap/snapcraft.yaml there?
[17:19] <cachio> and not in the base directory of the snap?
[17:21] <pstolowski> cachio: i think build-aux is a newer approach
[17:21] <pstolowski> cachio: not strictly necessary
[17:21] <cachio> I use to locate it in tests/lib/snaps/store/test-snapd-refresh-control-provider.v1/snapcraft.yaml
[17:22] <cachio> if it works it is ok
[17:22] <pstolowski> yes it works
[17:22] <pstolowski> cachio: see https://snapcraft.io/docs/release-notes-snapcraft-3-3
[17:22] <pstolowski> i've re-built all 4 snaps with snapcraft and re-uploaded them to the store
[17:23] <cachio> nice, so you can choose among the baswe dir and build-aux
[17:23] <cachio> makes sense
[17:24] <pstolowski> cachio: it's useful to keep main directory cleaner, of course not a problem here
[17:24] <cachio> pstolowski, right
[17:26] <cachio> pstolowski, just remember to ask store team to move the snaps to test-snaps-canonical user
[17:26] <pstolowski> cachio: ah, can they do this?
[17:26] <cachio> yes
[17:26] <pstolowski> nice
[17:26] <cachio> all the test snaps need to be reasigned
[17:27] <cachio> you will remain as a collaborator of the snap
[17:30] <pstolowski> cachio: cool. i'll talk to them tomorrow
[17:30] <pstolowski> thanks
[17:31] <cachio> pstolowski, also you need to set them as unlisted
[17:39] <pstolowski> cachio: can i do this myself?
[17:41] <cachio> in the store page, you go to edit -> settingd
[17:41] <cachio> settings
[17:41] <cachio> there you can set it as unlister
[17:41] <cachio> but I see there are tons of snaps not properly configured
[17:41] <pstolowski> cachio: ah, nice, thanks
[17:43] <pstolowski> ok, done
[17:43] <pstolowski> and eod, cu
[17:49] <cachio> ijohnson[m], hey, when you have a bit of time, could you please check https://github.com/snapcore/snapd/pull/10409
[17:49] <cachio> I need to validate the idea because I changed a lot the PR
[17:52] <ijohnson[m]> cachio sure I've got it on my queue now
[17:55] <cachio> tx
[18:57] <mborzecki> ah pedronis is gone already
[18:58] <mborzecki> ijohnson: fyi: https://paste.ubuntu.com/p/Dcfqhy2vwK/ something is broken in nested tests on master
[18:58] <ijohnson[m]> bboozzoo: hmm
[18:58] <ijohnson[m]> I'll take a look, thanks for the pointer
[19:03] <mborzecki> ijohnson: if you don't find anything obvious, i'll try to poke at it tomorrow morning
[19:03] <ijohnson[m]> bboozzoo: ack, I seem to recall seeing some changes to the fakestore stuff recently, perhaps we broke it without running the nested tests
[19:03] <mborzecki> ijohnson: possible, we don't run them too often, not sure if they even get run when merging to master
[19:04] <mborzecki> anyways, i'm off 😉 shouldn't even be at the keyboard right now
[19:04] <ijohnson[m]> 🙂 ttyl
[19:29] <cachio> mborzecki, hey
[19:29] <cachio> https://paste.ubuntu.com/p/9phCDkgqMM/
[19:29] <cachio> it is related to refresh-delta test which fails currently
[19:30] <cachio> it says not updates available but the snap is refreshed
[19:30] <cachio> is anyone takins a look to that one currently?
[19:31] <cachio> ijohnson[m], ~
[19:32] <ijohnson[m]> cachio: that's from the refresh-delta test ?
[19:32] <cachio> from refresh-delta-from-core
[19:33] <cachio> both are failing
[19:33] <cachio> same error I think
[19:34] <cachio> ijohnson[m], i have an instance open now
[19:36] <ijohnson[m]> cachio: what is the full failure output  from spread ?
[19:37] <cachio> ijohnson[m], https://paste.ubuntu.com/p/KVHFY74dTT/
[19:39] <ijohnson[m]> cachio: is the `journalctl: unrecognized option '--sync'` error relevant at all ? or is that harmless
[19:40] <cachio> it is harmless
[19:40] <cachio> ijohnson[m], it should be
[19:42] <cachio> it is weird because the log says it cannot refresh the snap
[19:42] <ijohnson[m]> hmm
[19:43] <cachio> ijohnson[m], https://paste.ubuntu.com/p/wpqgRCN2ZM/
[19:44] <cachio> this is the part of the journal log which is doing the refresh
[19:44] <ijohnson[m]> cachio: can you run on this instance `journalctl --no-pager -u snapd` ? the output you pasted is cut off
[19:45] <cachio> ijohnson[m], https://paste.ubuntu.com/p/9gJ5PwHN9G/
[19:49] <ijohnson[m]> cachio: yeah the store is still not returning deltas correctly, can you ping someone in the store channel about this?
[19:49] <ijohnson[m]> mvo pinged them this morning and they said it was fixed, but it seems it is still not fixed
[19:49] <cachio> sure
[19:49] <cachio> ijohnson[m], thanks
[19:51] <ijohnson[m]> np


[00:00] <synthmesc> thanks
[15:08] <fairuz> I have a weird issue. Downloaded the kernel source code using apt-get source $(uname -r). Copy the config from /boot and use it to compile the kernel. But then, it asks me questions. Do I need to use other config file?
[15:09] <fairuz> I suppose I can directly use the config file with the matching kernel source
[18:03] <fairuz_> Someone in here? :)
[18:43] <fairuz_> Why when I download my kernel source, the one untar'ed different from the one in the linux***.orig.tar.gz?