[08:06] <TJ-> is there a recommended dput workaround for uploading to Ubuntu PPAs from Debian, and hitting the "Unknown upload method: sftp" ? Looks like Debian hasn't added sftp support for 13 years!
[08:29] <Unit193> Worse yet, it doesn't have host argument support.  I use a forked version of dput that has a few extras.
[09:21] <mwhudson> is dput-ng better for this?
[09:31] <TJ-> mwhudson: not sure - I eventually figured it can be solved by scp-ing /usr/share/dput/dput/methods/sftp.py
[09:38] <TJ-> When I try to debug calls form apt to dpkg I only see the command-line but apt doesn't execute dpkg! "sudo apt -o=DPkg::Options=--force-all -o=Debug::pkgDPkgPM=true  -f install"  ... doing this because --force-all doesn't seem to be being passed to dpkg (man apt.conf says DPkg:: has an 'options' but other resources say it is 'Options')
[10:08] <xnox> to be fair i would love for the ftps support! https://salsa.debian.org/debian/dput/-/merge_requests/4/diffs
[10:08] <xnox> no idea why dput is not being maintained / merged =(
[10:13] <TJ-> xnox: does seem weird given the original Debian bug report was filed in 2008 :)
[12:35] <rbasak> Shouldn't https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20210805-impish-impish.html be updating? It was last generated two days ago.
[14:46] <doko> rbasak, update is running, the last one didn't finish
[14:47] <rbasak> Thanks
[17:15] <GunnarHj> Hi bdmurray, do you have time to look at the FFe request at bug #1940925?
[17:19] <bdmurray> GunnarHj: some desktop team sign off on this would be nice
[17:21] <GunnarHj> bdmurray: Problem is that l_aney is on vacation. I'm an ubuntu-desktop member, but indeed not a release team ditto.
[17:21] <GunnarHj> bdmurray: I'm ready to answer any questions you may have, though.
[17:24] <GunnarHj> bdmurray: I suppose that my comment on the bug can be seen as my sign off.
[17:24] <bdmurray> GunnarHj: I'm happy to approve it as an ubuntu-release team member but just want to know the rest of the desktop team is a +1 on this.
[17:28] <GunnarHj> bdmurray: Hmm.. It has been discussed back and forth, but mostly between me and Daniel. Maybe ask some desktop members to provide their +1 tomorrow.
[17:36] <GunnarHj> bdmurray: I added a comment to the bug with such a request. Let's await the desktop team members' explicit approval.
[17:36] <bdmurray> Okay, thanks I'll have a look at it tomorrow!
[17:37] <GunnarHj> thank you


[00:02] <psusi> cjwatson, per my discussion with smoser at UDS about the cloud images needing to online extend the root fs while booting without an initrd, I have some patches to parted and the kernel to do this.  Any chance of getting parted 3.0 merged for precise?
[00:09] <slangasek> patching the kernel for it? eew? :)
[00:13] <cjwatson> psusi: I think it's unlikely given the amount of installer work that has to be done first
[00:14] <cjwatson> psusi: specifically removal of everything that relies on libparted's filesystem code, which is going to involve writing a wrapper that knows how to transform various tools' progress output into debconf progress; I made a start on this a while back but there's quite a bit to do
[00:23] <psusi> cjwatson, ohh.. I thought the installer hadn't been relying on the parted filesystem code for a long time, seeing as how it has been basically broken for ages
[00:24] <psusi> slangasek, needed to add the missing BLKPG ioctl command to change the length of an in use partition... online expand and shrink of a btrfs partition is a beautiful thing ;)
[00:24] <broder> ...how can that ever be remotely safe?
[00:24]  * slangasek does not get warm fuzzies
[00:24] <slangasek> :)
[00:25] <psusi> broder, lvm has been doing it for years
[00:26] <psusi> ext4 can only grow online, but btrfs can shrink too
[00:27] <cjwatson> psusi: it still does in some places where it hasn't been broken
[00:27] <cjwatson> psusi: yes, it needs to move away from that anyway; but there are places where the practical effect of that would be a regression for users in terms of what progress bars we manage to provide, and I want to avoid that
[00:28] <psusi> cjwatson, so it relies on libparted to handle resize of fat filesystems and provide feedback?  anything else?
[00:29] <cjwatson> I forget, sorry, you'll have to hunt through partman
[00:29] <cjwatson> pretty certain it's a good deal more than that though
[00:29] <psusi> k.. just afaik, fat and bare bones ext2 were the only filesystems it could actually deal with
[00:29] <cjwatson> RTFS :-)
[00:31] <cjwatson> start with parted_server, look for use of removed ped_* functions, then look for use of the corresponding parted_server commands in the rest of partman
[00:32] <psusi> parted_server is a custom front end to libparted right?
[00:32] <cjwatson> yes
[00:32] <cjwatson> it's in the partman-base source package
[00:32] <psusi> kk
[00:32] <cjwatson> it's probably most concisely described as shell bindings for libparted
[00:32] <cjwatson> ish
[00:33] <psusi> right
[00:33] <psusi> and the rest of partman is written in shell right?
[00:33] <cjwatson> yes
[00:33] <cjwatson> apart from a couple of tiny C helpers
[00:59] <fetova> Here, bothering again.
[00:59] <fetova> I've done again the push of the bug 886680, this time taking the code of lp:~ubuntu-core-dev/app-install-data-ubuntu/ubuntu and i get a really big diff...
[00:59] <fetova> What i've done wrong? :(
[00:59] <fetova> The merge proposal: https://code.launchpad.net/~fetova/ubuntu/precise/app-install-data-ubuntu/fix-for-886680/+merge/84347
[01:09] <cjwatson> fetova: again, you need to propose it for merging into the same branch that you branched from
[01:10] <cjwatson> fetova: you should call your branch lp:~fetova/app-install-data-ubuntu/fix-for-886680 (tedious namespace differences that I won't go into) and propose it for merging into lp:~ubuntu-core-dev/app-install-data-ubuntu/ubuntu
[01:13] <psusi> can you not search the source package list with apt-cache?
[01:14] <cjwatson> I doubt it
[01:14] <psusi> trying to find all the bloody assorted partman packages ;)
[01:14] <cjwatson> apt has a fairly weak internal representation of source packages
[01:14] <fetova> ok... i want to get this fully, so, another question:
[01:14] <fetova> Why should I name my branch lp:~fetova/app-install-data-ubuntu/fix-for-886680  instead of lp:~fetova/app-install-data-ubuntu/ubuntu/fix-for-886680 ?
[01:15] <cjwatson> fetova: drat, now I have to go into the grotty details :)
[01:15] <cjwatson> branches of the form lp:~OWNER/PROJECT/BRANCHNAME are upstream branches; branches of the form lp:~OWNER/DISTRO/SERIES/PACKAGE/BRANCHNAME are source package branches
[01:16] <cjwatson> source package branches are a newer invention, and a fair number of relatively old packages still use the upstream form, although we'd like to get everything over to source package branches eventually
[01:17] <cjwatson> in general if you find two branches of the same thing in the two different namespaces you can't assume that it's possible to freely merge between them; you need to figure out which one the developer of the package is using and match that
[01:18] <cjwatson> so, this package declares which it's using in the Vcs-Bzr field in debian/control (also shown by 'apt-cache showsrc' etc.)
[01:18] <cjwatson> that tells you where you should branch from
[01:18] <cjwatson> and you should ALWAYS propose a merge into the same branch that you branched from
[01:18] <cjwatson> (unless you know exactly what you're doing and know better, in which case you don't need my advice)
[01:19] <fetova> true :P
[01:20] <fetova> ok, so i need to explain the debugging i've made so far, to ask for advice for what i exactly should do in this case
[01:20] <cjwatson> the final piece is that it's normally best to use the same namespace as the branch you branched from, to reduce confusion in the Launchpad UI
[01:20] <cjwatson> so if it's three-level, use a three-level name; if it's five-level, use a five-level name
[01:21] <cjwatson> (it's unfortunate that quite this much complexity is on the surface)
[01:21] <fetova> yeah... a bit...
[01:22] <psusi> it's not bad once you understand it... just needs written down somewhere for people to read ;)
[01:23] <fetova> well, as i investigate on the sources, there is a script (update-menu-data.sh) that get from http://rookery.canonical.com/~mvo/gnome-app-install/ the .desktop
[01:23] <fetova> accordly by the date "today"
[01:23] <fetova> the last taken on the launchpad code has the bug
[01:23] <fetova> the most recent on that url, not
[01:24] <fetova> http://rookery.canonical.com/~mvo/gnome-app-install/menu-data-20110802.tar.gz
[01:24] <fetova> so... the bug is fixed on that code just getting this last .tar.gz
[01:25] <smoser> psusi, still around ?
[01:25] <psusi> smoser, yo
[01:26] <smoser> so forgive me for beign gravely ignorant.
[01:26] <psusi> bless you my son ;)
[01:26] <smoser> but given a kernel patch, we basically will just have to rewite the partition table (which I do already using sfdisk) and then amke a IOCTL , right ?
[01:27] <smoser> assuming you can get the stuff into kernel, the rest seems easy for me. i dont see the need for parted.
[01:27] <smoser> again, i'm sure i'm making an idiot of myself and missing something obvious :)
[01:27] <psusi> smoser, yea... and I have parted doing that nicely now... problem seems to be that ubuntu is still using an old parted because d-i still depends on some of the crappy filesystem code that has since been removed from parted ;)
[01:27] <psusi> well, if you want to patch sfdisk to do it, go for it
[01:28] <smoser> but its not even necessary to patch sfdisk.
[01:28] <fetova> so... i'm not sure how i should get the bug fixed, if geting this .tar and doing all the import stuff it on the lp:~ubuntu-core-dev/app-install-data-ubuntu/ubuntu code... or on the source package branch
[01:28] <smoser> i can just rewrite the partition table with sfdisk and tell it either not to call BLKKRRPART, or call it, it wont do anything.
[01:28] <psusi> well... it really should be done in the partition table writing tool... this isn't just a "hey, read the partition table", it is an "move the end of this partition to sector x"
[01:28] <smoser> and then i have a little program that makes the right call.
[01:28] <fetova> what do you think, cjwatson? :)
[01:29] <smoser> psusi, fair enough, but even then, that isn't *too* bad. i can have sfdisk tell me what that new sector is.
[01:29] <psusi> you *could* write a quick and dirty tool to do it and pass the sector and partition number from your script, but that feels a little kludgy to me
[01:30] <smoser> i agree, that better for sfdisk to do it. or parted, but if that is goign to require installer chagnes and possibly regressions... i'd do without.
[01:30] <smoser> if it saves me 2 seconds or something every boot in a cloud image, thats a big win.
[01:31] <psusi> sounds reasonable
[01:31] <smoser> and i don't really see the possible fallout.
[01:33]  * psusi needs to take HDIO_GETGEO out back and bury it behind the tool shed
[01:36] <cjwatson> psusi: surely it's easily enough backportable in parted anyway.
[01:37] <cjwatson> fetova: don't know, sorry, I've never attempted to do a full update of a-i-d-u from a new data dump; you want mvo
[01:37] <psusi> cjwatson, I'm not sure... because old parted has a resize command that also resizes the filesystem.. that was removed, and I have replaced it with one that just resizes the partition
[01:38] <fetova> I see, i'm mailing him
[01:38] <fetova> Thanks a lot for the guiding!, cjwatson :D
[01:40] <cjwatson> psusi: I meant the underlying libparted bit
[01:40] <cjwatson> psusi: as far as the parted command-line program goes, repurposing an old command is bad style, even if it was removed.  Give it a new name instead
[01:40] <psusi> cjwatson, sure, that's easy.. but you need a user interface for it ;)
[01:41] <cjwatson> psusi: people with scripts that use 'resize' should get an error message with parted 3.0, not have the script do some random other thing instead
[01:42] <psusi> cjwatson, they will get an error as the arguments are different.... old one took start pos, new one does not... only moves the end
[01:46] <cjwatson> psusi: that's a pretty fragile way to do it; a new command would be easier to understand
[01:46] <cjwatson> what if somebody adds another optional argument in future, say
[01:47] <cjwatson> design for people coming along and modifying your code later without full context :)
[01:47] <cjwatson> and that will make the backport trivial, so it should be a no-brainer to do it that way?
[01:47] <psusi> well, what should you call it?  this one should be called resize, and the original one should have been named resizefs, but it was't...
[01:47] <cjwatson> resizepart?
[01:48] <psusi> that's the reverse naming convention of all of the other commands
[01:48]  * cjwatson shrugs
[01:48] <psusi> hrm...
[01:48] <cjwatson> or use a different verb
[01:48] <cjwatson> I can't do naming after local midnight
[01:49] <infinity> alternatelysize
[01:49] <infinity> makebiggerorsmaller
[01:49] <infinity> SO MANY OPTIONS.
[01:50] <psusi> I guess resizepart could work... I just hate introducing things that make people go "why the hell was it given THAT name? oh, because there was an older broken misnamed command that was removed, but had the logical name for this one"
[01:53] <infinity> You could just name it britney.
[01:53] <psusi> lol... actually, if I did name if resizepart, because you can use short prefixes and the old resize command is gone, "resize" would still be recognized as resizepart
[01:54] <infinity> D'oh.
[01:54] <infinity> rpart?  rsizepart?
[01:55] <cjwatson> changesize, changeextents
[01:56] <cjwatson> extents
[01:56] <cjwatson> why was it given that name> sometimes compatibility is painful but that doesn't make it less valuable ...
[01:57]  * infinity grumbles about people using dh_autoreconf in their clean targets..
[01:58] <cjwatson> infinity: debuild -S -nc  IYF
[01:59] <cjwatson> (with care)
[01:59] <psusi> hrm...
[01:59] <infinity> cjwatson: IYF?
[01:59] <cjwatson> is your friend
[01:59] <psusi> maybe I could name it changesize, and require that name to be used in batch mode for clarity, but going forward, alias resize for interactive users...
[02:00] <infinity> Huh.  dpkg-buildpackage was supported -nc forever.  No idea how I missed that.
[02:01] <cjwatson> it's only been allowed with -S since dpkg 1.15.1 (May 2009)
[02:01] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304404
[02:02] <psusi> then drop the requirement and accept either in batch mode in say, 2-3 years
[02:02] <psusi> yea... I like that...
[02:02] <infinity> cjwatson: Ahh, could be why I never used it.  Maybe I once tried and failed. ;)
[02:40] <broder> did clutter-gst just get promoted? (trying to figure out if my lintian lab is on crack or just out of date)
[02:41] <broder> (i see it's in main now - trying to figure out if it was just moved recently)
[02:42] <broder> hmm..no, looks like it was a few days ago
[04:34] <broder> since the sponsorship queue isn't picking it up, could i get some kind soul to sponsor bug #897383 for me?
[05:09] <hallyn> If there is any MOTU or coredev around in the mood to upload a (well 3) one-line change to ii, bug 899494 is here to spice up your friday night...
[05:10] <broder> hallyn: i can take a look as long as it's quick
[05:11] <broder> wow. this is a special package
[05:13] <hallyn> broder: that'd be great, thanks!
[05:13] <hallyn> yes, it is :)
[05:16] <hallyn> ugh, just opened my (precise-changes-subscribed) mbox :)
[05:18] <infinity> hallyn: *cough*
[05:18] <infinity> hallyn: Sorry. :P
[05:18] <hallyn> :)  np, delete is quick :)
[05:21] <infinity> micahg: You still around?
[05:23] <broder> hallyn: test building now, but a few points of feedback
[05:24] <broder> (which i'm just cleaning up in my build)
[05:24] <broder> (a) ii in lucid is a source format 1.0 package, which means that it doesn't apply quilt packages by default
[05:24] <hallyn> jinkeys
[05:25] <hallyn> (sbuild did apply it, though)
[05:25] <broder> no, your debdiff has the patch applied
[05:25] <hallyn> oh.  i see. that explains why .pc was in the debdiff
[05:25] <hallyn> right
[05:25] <broder> we don't usually add a patch system to a package in an SRU
[05:25] <broder> or as an ubuntu diff in general
[05:25] <hallyn> i should've paid more attention to that, thanks
[05:25] <broder> so for packages that aren't already either using quilt or source format 3.0 (quilt), the general convention is to just patch the source directly
[05:25] <infinity> Oh, how I'm glad that best practice reversed on that.
[05:26] <hallyn> oh?
[05:26] <infinity> I used to tear my hair out merging packages where some helpful Ubuntu dev had added a patch system that wasn't there upstream.
[05:26] <broder> hmm...in fairness, this may be an ubuntu-motu-land best practice and not a general ubuntu one
[05:26] <broder> but i'm doing the review so you get to play by my rules :-P
[05:26] <hallyn> broder: not even using dpatch?
[05:26] <infinity> broder: No, it was MOTU that used to be guilty of the above insanity.
[05:26] <infinity> broder: And I smacked many for it.
[05:26] <infinity> broder: It seems that things went my way. ;)
[05:27] <infinity> hallyn: Adding a patch system just plain shouldn't be done for an SRU or for a Debian->Ubuntu merge.
[05:27] <hallyn> broder: put another way - in oneiric it uses quilt, does that change anything?
[05:27] <infinity> hallyn: Just view an SRU as an Ubuntu->Ubuntu merge.  Adding extra code just makes it confusing.
[05:27] <broder> hallyn: yeah, you'd use their quilt hooks
[05:27] <broder> use the patch system that's there, but don't add a new one
[05:27] <infinity> (And yeah, if it already has a patch system, use it)
[05:27] <hallyn> right, but not in lucid, even though oneiric has it?
[05:28] <infinity> Yeah, not in lucid.
[05:28] <hallyn> ok (oneiric already has the fix :)
[05:28] <infinity> Your delta is from lucid->lucid, not from oneiric.
[05:28] <hallyn> i'll post a new debdiff, but you had more?
[05:28] <broder> actually, i think my point 1 managed to expand to cover everything :-P
[05:28] <broder> don't worry about a new debdiff, though
[05:28] <broder> i've already got it taken care of
[05:29] <hallyn> broder: thanks!
[05:29] <infinity> rm -rf .pc debian/patches && done? :)
[05:29] <broder> infinity: pretty much
[05:29] <broder> and tweak the changelog to not mention a file in debian/patches that's not there :)
[05:29] <infinity> Heh.
[05:29] <hallyn> (this bug was driving me nuts, very mysterious :)
[05:30] <broder> i can't believe you use this thing
[05:30] <broder> ok, uploaded
[05:30] <broder> and -> battery dead
[05:30] <broder> i'll be back later if there's any fallout :)
[05:30] <hallyn> good night - thanks again
[05:31] <infinity> It sounds handy for event-driven shell<>IRC scripting.
[05:31] <infinity> Also, knowing anyone uses such a gateway, I'm not inclined to try injecting code into it.
[05:31] <infinity> s/not/now/
[05:32] <hallyn> infinity: it makes interacton with xmpp (i.e. google chat) trivial
[05:33] <hallyn> and, it becomes very usable with pcw or multitail+vim
[05:33] <infinity> I'll concede the first point.  The rest just sounds perverse.
[05:34] <hallyn> :)
[05:34] <infinity> But hey, I haven't really changed my UI over nearly two decades of irc->ircII->BitchX->irssi, so who am I to talk?
[05:35] <infinity> If IRC doesn't have a blue bar at the bottom, I don't know it's IRC....
[05:35] <hallyn> haha, the right byobu theme could do that for you i'm sure :)
[05:35] <infinity> *shudder*
[16:14] <quadrispro> hi all
[16:21] <apw> infinity, i've uploaded those hf fixes ... fingers crossed
[16:21] <ogra_> \o/
[16:23] <apw> ogra_, its on a buildd, so i guess 3-4 hours till we know, but i hacked (literally) one of cross build chroots to test it properly, so its as good as i can make it without building it in the real chroot
[16:24] <apw> so there seemed no point to hold it off any longer
[16:24] <ogra_> yeah, lets see
[16:24] <ogra_> right, its not like we are short on buildd power :P
[16:24] <ogra_> if it fails it fails
[16:24] <apw> for arm thats a nice position to be in
[16:25] <ogra_> heh
[16:25] <ogra_> well, currely hf owns most of them i think
[16:25] <ogra_> el is indeed a bit short
[18:59] <bdrung> tumbleweed: http://paste.debian.net/147955/
[19:00] <bdrung> tumbleweed: shouln't we do another upload
[19:00] <bdrung> ?
[19:02] <bdrung> besides that: some "Missing docstring"
[19:02] <bdrung> tumbleweed: man pages are missing
[19:03] <bdrung> tumbleweed: test cases are missung
[19:03] <bdrung> s/missung/missing
[19:03] <bdrung> can we get rid of "E: 80:main: Class 'PersonTeam' has no 'me' member"
[19:03] <bdrung> ?
[19:04] <bdrung> besides that both branches seems to be fine
[19:19] <tumbleweed> bdrung: yes, due for one soon, but (as you can see) I have some new things I've been playing with that need a little polish, first :)
[19:19] <bdrung> k
[19:20] <bdrung> tumbleweed: RL keeps me busy. therefore i have only little time to review (no time for developing new things)
[19:20]  * tumbleweed probably shouldn't be writing new things either :)
[19:21] <bdrung> tumbleweed: but now you have to finish them! :p
[19:21] <tumbleweed> yeah :/
[20:27] <bdrung> tumbleweed: let me know if i should review something
[20:28] <tumbleweed> bdrung: you can tell me how useful those tools in braches attached to bug 876554 are (and give UI review)
[20:29] <bdrung> tumbleweed: they are useful
[20:30] <tumbleweed> great, must clean them up then :/
[21:30] <apw_> infinity: ogra_ ..armhf is pending binary new ... :)
[21:37] <tumbleweed> bdrung: there, first branch is reviewable
[21:37] <bdrung> tumbleweed: which?
[21:38] <tumbleweed> who-can-upload-876554
[21:42] <bdrung> tumbleweed: "R: 25:main: Too many statements (54/50)"
[21:43] <bdrung> tumbleweed: split it into more functions
[21:44] <bdrung> tumbleweed: maybe split command line parsing
[21:44] <tumbleweed> yup, the only logical split
[21:45] <bdrung> tumbleweed: main has no comment
[21:46] <bdrung> tumbleweed: can we get rid of E: 93:main: Class 'PersonTeam' has no 'me' member
[21:46] <tumbleweed> bdrung: no, pylint doesn't unterstand metaclasses
[21:46] <tumbleweed> our pylint configuration file already whitelists PersonTeam
[21:51] <tumbleweed> bdrung: pushed r1252
[21:54] <bdrung> tumbleweed: ./upload-permission audacity  -r lucid-proposed
[21:55] <bdrung> tumbleweed: i can't upload to lucid :( and lucid-proposed is unknown
[21:55] <tumbleweed> permissions are the same across pockets
[21:55] <bdrung> tumbleweed: "You can not upload this package, yourself." -> name the package
[21:56] <bdrung> You can upload this package. -> name it
[21:56] <bdrung> tumbleweed: then why $ ./upload-permission audacity -r lucid
[21:56] <bdrung> You can not upload this package, yourself.
[21:57] <tumbleweed> ah, the bit that answers that does check the pocket
[22:14] <bdrung> tumbleweed: "You can upload audacity." -> "You can upload audacity to oneiric." maybe?
[22:16] <bdrung> tumbleweed: http://paste.debian.net/147975/ -> shouldn't line 5 and 6 removed?
[22:20] <tumbleweed> bdrung: yeah, fixed
[22:21] <bdrung> tumbleweed: You can upload audacity to None.
[22:22] <bdrung> tumbleweed: i would kill the last line too: http://paste.debian.net/147976/
[22:24] <bdrung> tumbleweed: http://paste.debian.net/147977/ -> packagesets VS component?
[22:27] <tumbleweed> got all that
[22:28] <tumbleweed> actually, no
[22:31] <tumbleweed> right
[22:31] <bdrung> tumbleweed: it looks good now. last point: the name of the script
[22:32] <bdrung> tumbleweed: is it precise enough?
[22:32] <bdrung> tumbleweed: maybe ubuntu-upload-permission?
[22:32] <tumbleweed> s/^/ubuntu-/ ?
[22:33] <bdrung> then it's not short, but the tab-completion will help
[22:35] <tumbleweed> renamed
[22:39] <bdrung> tumbleweed: debian/control -> sort it
[22:40] <bdrung> tumbleweed: ups, no. update-maintainer is twice there
[22:41] <tumbleweed> ah, I thought it was missing
[22:43] <bdrung> tumbleweed: backportpackage is missing there
[22:45] <bdrung> tumbleweed: you can merge your branch now
[22:45] <psusi> yay!  online partition resize patches successfully backported to precise
[22:46] <tumbleweed> bdrung: next branch
[22:46] <bdrung> tumbleweed: i will go to bed in the near future
[22:53] <bdrung> tumbleweed: will you merge the approved branch first?
[22:54] <tumbleweed> bdrung: done. (took a while, suffering temporary network problems 50% packetloss somewhere between ZA and UK) :/
[22:55] <tumbleweed> cjwatson: this is something I did this morning, as a result of a conversation we had a while back about a tool to show if a package is "seeded" inimages. I'm rsyncing the manifests & lists from cdimage and building an index of packages
[22:57] <tumbleweed> if we find this useful, it'd probably be preferable if I didn't have to generate the index separately, and we could do it somewhere in the publication pipleines (it's tiny, so fast to do)
[23:02] <bdrung> tumbleweed: good night
[23:02] <tumbleweed> night, thanks for dusting out all the corners :)
[23:03] <bdrung> you're welcome


[00:42] <tertitten> This may be the wrong channel to ask in, but if anyone have any tips I would appreciate it. I've recently built a distro/respin of openSUSE which I've been working on for a long time now, i'm now starting to regret using suse as base, so for building a distro based on ubuntu what tools is recommended ? UCK, Remastersys?
[00:44] <directhex> ubuntu doesn't have any tool remotely as elegant as suse studio
[00:46] <tertitten> directhex, no, maybe not, but I'm willing to dig in :)
[02:00] <sladen> tertitten: probably UCK
[02:01] <tertitten> sladen, OK, I'll look into that one then, there a few to chose by it seems :)
[02:01] <tertitten> thanks
[07:41] <xnox> Good Morning!
[07:44] <RAOF> Hey, ho!
[07:49] <jodh> Is the binary package control file "Tag" field documented somewhere?
[07:50] <RAOF> jodh: What are you seeing with a Tag field?
[07:51] <jodh> RAOF: an example would be "apt-cache show casper|grep ^Tag:"
[07:51] <RAOF> Ah, debtags!
[07:51] <RAOF> That should be the magical google juice.
[07:52] <jodh> RAOF: thanks! Wondering why they aren't mentioned in the Debian Policy manual if they are official though?
[07:54] <RAOF> Possibly because they're not quite that official, possibly because they don't need to be - AFAIK debtags are completely confined to their own universe, don't affect maintainers, and don't affect apt.
[07:56] <geser> cjwatson: even if the check for pre-depends on dpkg is going away, packages which failed to upload because of it need to get it added anyways, right?
[08:04] <jodh> RAOF: since "Tag:" is optional like some other binary source control fields and since it is used in packages in stable Debian releases, it sounds pretty official to me, so should atleast be referred to in the Policy Manual imho.
[08:04] <jodh> RAOF: thanks for the pointer though - I have now found some docs :)
[08:18] <cjwatson> geser: no - the LP change to make that no longer required should be deploying RSN (today/tomorrow, haven't checked yet this morning)
[08:19] <cjwatson> jodh: the reason Tag isn't documented in policy is that policy chiefly documents things that package maintainers need to do to ensure interoperability, and Tag is applied at the archive level as an override - package maintainers don't set it
[08:23] <jodh> cjwatson: I don't fully understand - in the case of casper, the tag is specified in debian/control.
[08:25] <cjwatson> jodh: casper is foolish
[08:27] <cjwatson> we don't have debtags working at the archive level for Ubuntu yet, but when we do, it isn't going to involve laboriously pushing tags into source packages
[08:30] <jodh> cjwatson: ok, thanks.
[08:31] <enrico> RAOF: and possibly because people think like you do, then don't get used as much as they could
[10:04] <geser> could someone please give-back "libpam-mount"? thx
[10:17] <Traumflug> Hello all :-)
[10:19] <Traumflug> Well, I've found a bug in one of the packages (surprise!) shortly before 12.04 was released and fixed it.
[10:19] <Traumflug> Now the merge request is apparently stuck: https://code.launchpad.net/~mah-jump-ing/ubuntu/precise/pcb/fix-for-988503-2/+merge/103767
[10:20] <Traumflug> What could I do about this, after all it's just a click from a member of the Ubuntu-Bugs group missing.
[10:22] <geser> Traumflug: as it's listed on http://reports.qa.ubuntu.com/reports/sponsoring/index.html someone should review it in the next days
[10:22] <cjwatson> geser: libpam-mount> done
[10:23] <Traumflug> Thanks, geser
[10:56] <hyperair> hmm weird. how does ubuntu go about rebooting?
[10:56] <hyperair> it looks like /etc/rc6.d has S90reboot
[10:56] <hyperair> which implies that reboot should be called with a start argument
[10:56] <hyperair> but the script itself only responds to a stop argument
[10:56] <hyperair> so clearly that's broken
[10:56] <hyperair> and kexec-load which follows the same logic is broken in the same way
[11:02] <geser> hyperair: is perhaps rc6 special-cased somewhere as the other S-scripts have only a working stop argument too
[11:02] <hyperair> geser: but kexec-load doesn't seem to work.
[11:03] <hyperair> sorry, i meant kexec itself
[11:03] <hyperair> hmmm
[11:04] <geser> hyperair: just took a look in /etc/init.d/rc and runlevel 6 (and 0) hardcodes the action to stop
[11:05] <hyperair> i see.
[11:05] <hyperair> thanks, i guess it's failing elsewehre
[11:05] <hyperair> i'll try poking at this later
[11:15] <cjwatson> geser,micahg: data.tar.xz is now safe to use in quantal without a Pre-Depends.  I've given back all the (four) upload failures resulting from the previous situation.
[11:17] <geser> thanks
[11:19] <geser> bdrung: do you plan to upload a devscripts where dch defaults to quantal soon?
[11:38] <jalcine> Which audio system is better to develop with?
[11:38] <jalcine> alsa or pulse?
[11:39] <jalcine> or should I let gstreamer handle all that jazz?
[11:39] <jalcine> err
[11:53] <apw> @pilot in
[12:05] <vipin> can any one tell me the process how to configure oracle instant client with php on linux machine
[12:06] <ion> Please see the topic.
[12:06] <vipin> i dont know about the topic i want solution please
[12:07] <Pici> vipin: this isn't a support channel.
[12:08] <vipin> where i can fins the solutiob
[12:09] <apw> are we expecting to need new explicit build depends for flex in quantal ?
[12:10] <cjwatson> apw: flex always required a build-dependency
[12:10] <cjwatson> maybe the kernel just wasn't using it before?
[12:10] <apw> cjwatson, i guess htats possible, or something we used to depend on used to fluke it in for us ...
[12:10] <cjwatson> possible
[12:11] <cjwatson> looks like you need pkg-config and bison too
[12:14] <apw> cjwatson, yeah, adding now ... shame all our builders are in a heap ... sigh
[12:14] <apw> (our kernel team ones)
[12:38] <bdrung> geser: you can go ahead and do this ubuntu upload
[12:38] <bdrung> geser: it's time to merge the dch changes to debian and query distro-info
[12:40]  * cjwatson considers the interaction of absolute_import and update-manager
[12:40] <cjwatson> this is actually one of the few cases I've seen where it's not obvious, due to the umpteen ways its modules are shipped
[12:41] <cjwatson> I guess I need to use the new relative import syntax
[12:45] <geser> bdrung: will take a look what I can accomplish with short free time
[12:46] <phillw> Hi good people, I hve no idea how to help on this one. on boot up the system halts with error [ 8.980960] pcmcia_socket pcmcia_socket1: cs: IO port probe 0x3000-0x7ffff: excluding 0x3000-ox30ff 0x3400-0x34ff 0x380-0x38ff 0x3c00-0x3cff
[12:46] <phillw> Do any of you have an idea what it is complaining about / how to fix it?
[13:08] <bdrung> geser: can you code perl?
[13:08] <bdrung> geser: there are some requests around this part of dch.
[13:11] <geser> bdrung: not really, it's enough to read some perl (as long it doesn't use it's magic $ variables) and to patch simple things
[13:12] <bdrung> me too.
[13:42] <sconklin> @pilot in
[13:44] <infinity> That's quite the pilot party going on in the topic.
[13:44] <geser> redundancy :)
[13:45] <geser> two pilots can crash and we still have on pilot left flying
[13:45]  * infinity doesn't think he could call apw a "hot spare" with a straight face.
[13:46] <mdeslaur> hehe
[14:03] <ketan_> .
[14:18] <hyperair> jbicha_: ping. will clutter 1.10.4 be sru'd to precise?
[14:36] <vibhav> Can somebody nominate https://bugs.launchpad.net/ubuntu/+source/wxmaxima/+bug/887806 for oneiric and precise?
[14:37] <vibhav> (Reproducable in both)
[14:38] <tumbleweed> you think that's important enough to SRU?
[14:38] <apw> infinity, i am spare
[14:41] <infinity> apw: That's not the half of the term I was debating. ;)
[14:41] <apw> infinity, you were debating that ... seems unlikely :)
[14:42] <vibhav> tumbleweed: Then how will the bug get fixed in precise?
[14:43] <tumbleweed> vibhav: it wouldn't :)
[14:43] <tumbleweed> vibhav: I'll nominate for precise
[14:43] <tumbleweed> done
[14:44] <vibhav> tumbleweed: I meant oneiric
[14:45] <vibhav> Does this mean that the user will never get the bug fixed?
[14:45] <vibhav> (in onerirc)
[14:46] <tumbleweed> vibhav: https://wiki.ubuntu.com/StableReleaseUpdates#When
[14:46] <tumbleweed> I wouldn't consider that a high-impact bug. But if you do, I suggest worrying about precise first. If the SRU team agrees with you, do another SRU for oneiric
[14:46] <vibhav> ah
[14:47] <vibhav> And where can I contact the SRU team
[14:47] <tumbleweed> they'll see it when there's a pending upload in precise-proposed
[14:48] <vibhav> ah, thanks
[14:51] <dupondje> damn alot of people are complaining about Remmina missing copy/paste :p
[15:01] <cyphermox> dupondje: point them to how to enable -proposed ;)
[15:07] <jbicha_> hyperair: are there particular bugs you're following that are fixed by clutter 1.10.4?
[15:10] <hyperair> jbicha_: scrolling
[15:10] <hyperair> jbicha_: i've filed a bug on launchpad with a patch.
[15:10] <hyperair> jbicha_: scrolling in gnome-sushi is broken.
[15:12] <dupondje> cyphermox: copy/paste fix not in proposed yet :)
[15:12] <cyphermox> dupondje: oh, right
[15:12] <cyphermox> I keep mixing both
[15:13] <cyphermox> dupondje: was copy-paste working before in remmina? otherwise it may be hard to justify it being a SRU fix ;)
[15:13] <Laney> is it fixed upstream / in quantal?
[15:14] <cyphermox> Laney: not yet either
[15:14] <dupondje> cyphermox: it never worked in remmina
[15:14] <cyphermox> aye
[15:14] <dupondje> BUT, its only since 12.04 that remmina is default
[15:14] <dupondje> it worked in Vinage/rdesktop ...
[15:14] <dupondje> so its bit tricky :)
[15:14] <cyphermox> dupondje: you said your fix was ready right? can we upload this to quantal now?
[15:15] <Laney> depending on how severe the fix is, it could probably go
[15:15] <Laney> i suggest you get upstream review
[15:15] <cyphermox> Laney: it's copy-paste support in remmina
[15:15] <dupondje> https://github.com/FreeRDP/Remmina/commit/263ae6c3971f442ca5a8cfc1b5a5cde6736a062f
[15:15] <Laney> yeah, I Got that
[15:15] <Laney> nice
[15:15] <cyphermox> nice, so it's upstream too
[15:16] <vibhav> What version do I use for SRU which are mergers from Debian?
[15:16] <Laney> well, that patch is pretty large
[15:16] <dupondje> true ...
[15:16] <Laney> I don't know if the SRU team would have it
[15:16] <vibhav> merges*
[15:16] <Laney> but regardless the first step is to get it fixed in quantal
[15:17] <vibhav> (The previous version is 11.08.0-1 )
[15:17] <cyphermox> dupondje: then we can have it reviewed by the sru team too
[15:19] <tumbleweed> vibhav: we don't merge for SRUs. But rather apply a minimal targetted patch
[15:22] <vibhav> tumbleweed: ah, So what version do I use?
[15:23] <vibhav> tumbleweed: 11.08.0-1ubuntu1 ?
[15:23] <Laney> is it an SRU into precise?
[15:24] <vibhav> yeah
[15:27] <Laney> there are some version guidelines https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Packaging here
[15:28] <Laney> most important is that precise <= precise-proposed <= precise-updates <= quantal
[15:39]  * dupondje is going to look if all Remmina patches in Ubuntu are upstream
[15:39] <dupondje> then we could get 1.0.1 out ^^
[15:42] <cyphermox> dupondje: cool
[15:47] <jbicha_> hyperair: I believe scrolling is still broken in gnome-sushi and gnome-documents
[15:47] <vibhav> tumbleweed: Done, could you please review https://bugs.launchpad.net/ubuntu/+source/wxmaxima/+bug/887806 ?
[15:48] <hyperair> jbicha_: no it's not, not in git master.
[15:48] <hyperair> jbicha_: the commit i isolated, when cherry-picked, solves the issue. it's running happily on my laptop right now
[15:49] <jbicha_> hyperair: but I'm using clutter 1.11.2 which is basically git master
[15:49] <hyperair> jbicha_: it isn't.
[15:49] <jbicha_> http://git.gnome.org/browse/clutter/log
[15:50] <hyperair> oh hey there wasn't a 1.11.2 on my tree
[15:50] <hyperair> nor was there a 1.10.4
[15:50] <tumbleweed> vibhav: seems reasnoable
[15:50] <hyperair> jbicha_: are you sure it still doesn't work in gnome sushi? =\ it works here.
[15:51] <hyperair> just the cherry-picked commit
[15:51] <vibhav> tumbleweed: What did you mean?
[15:51] <hyperair> b746044415ba8eb2d4c4263aeec038257f1bf2f3
[15:51] <tumbleweed> vibhav: I mean it looks good
[15:51] <vibhav> ah, thanks
[15:54] <jbicha_> hyperair: yes, I've rebooted and scrolling isn't working in sushi in Unity, there aren't any scrollbars and keyboard navigation doesn't work
[15:54] <hyperair> jbicha_: if keyboard navigation doesn't work, it's probably a different issue.
[15:54] <vibhav> tumbleweed: Could you sponser it?
[15:54] <vibhav> sponsor*
[15:55] <hyperair> jbicha_: keyboard navigation works for me even without the patch, but scrolling didn't, and the scrollbars are nonexistent
[15:55] <jbicha_> hyperair: yeah, maybe some stuff is improved but things still aren't working right
[15:56] <hyperair> jbicha_: which filetype are you testing with?
[15:56] <hyperair> jbicha_: i'm using pdf, which uses libevince
[15:57] <geser> could someone please give-back "tipa"? thx
[15:58] <jbicha_> hyperair: .txt, keyboard navigation seems to work for PDFs like you said
[16:10] <tumbleweed> vibhav: you were the last uploader for mercurial. Are you going to request a sync?
[16:12] <vibhav> tumbleweed: sync for?
[16:13] <tumbleweed> there's a newer version in Debian. It's your responsibility to see if the changes we applied in Ubuntu are still relevant
[16:14] <vibhav> ah, let me see
[16:20] <vibhav> tumbleweed: I can see http://selenic.com/repo/hg/rev/80f3ae36f908 in the debian version
[16:21] <tumbleweed> vibhav: yup, that's why I suggested a sync :)
[16:21] <Darxus> What does "Toolchain Uploaded" on https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule mean?  Quantal repos will be created two days from now?
[16:21] <vibhav> tumbleweed: So should I sync?
[16:22] <tumbleweed> vibhav: well, if you merged, there wouldn't be anything left that's ubuntu specific. So yes, I think so
[16:24] <cjwatson> Darxus: that's a deadline, it's actually done already
[16:25] <Darxus> cjwatson: Okay, so changes that will only be permitted in quantal can be made now?
[16:26] <cjwatson> Darxus: sure
[16:26] <Darxus> Cool, thanks.
[16:27] <Darxus> When does packages.ubuntu.com start showing quantal packages?
[16:28] <jdstrand> cjohnston: hi! I am the track lead for the security team and have some questions surrounding setting up roundtable meetings in summit. do you have a moment to help me?
[16:29] <vibhav> tumbleweed: done: https://bugs.launchpad.net/ubuntu/+source/mercurial/+bug/992696
[16:55] <hyperair> jbicha_: does scrolling work for pdfs with the new clutter?
[16:59] <geser> Darxus: ask Rhonda (e.g. in #ubuntu-motu) about her plans when this will be done
[17:00] <Darxus> geser: Getting quantal packages in packages.ubuntu.com?
[17:00] <lynxman> silly question, how can I create a quantal machine in pbuilder-dist (precise) or shall I still test my packages for quantal against precise for the moment?
[17:00] <geser> Darxus: yes
[17:00] <Darxus> Thanks.
[17:01] <geser> lynxman: install debootstrap from precise-backports (or create the missing symlink yourself)
[17:01] <lynxman> geser: cool, ty :)
[17:05] <jbicha_> hyperair: yes, except for the lack of scrollbars
[17:05] <hyperair> jbicha_: were the scrollbars there to begin with?
[17:06] <hyperair> jbicha_: they're not there in oneiric either.
[17:06] <jbicha_> hyperair: probably not
[17:06] <hyperair> jbicha_: so could we have 1.10.4 or otherwise cherry-pick the commit for precise-proposed?
[17:07] <hyperair> not being able to scroll a pdf makes gnome-sushi pretty useless in that arena
[17:09] <jbicha_> hyperair: you could upload 1.10.4 to p-proposed if you want, I was just curious if we already had LP bugs that it fixed
[17:09] <hyperair> jbicha_: yes, i filed a bug, and uploaded a debdiff.
[17:10] <hyperair> bug #990302
[17:10] <hyperair> jbicha_: ^
[17:10] <hyperair> i don't have upload access to main
[17:11] <jbicha_> hyperair: ah ok
[17:11] <hyperair> jbicha_: i was wondering if 1.10.4 was giong to be uploaded into precise-proposed, though. that would make the cherry-picking pointless.
[17:12] <jbicha_> I think I'll just upload 1.10.4, thanks
[17:18] <hyperair> jbicha_: thanks.
[17:22] <jbicha_> hyperair: can you convert your bug into an SRU bug for 1.10.4?
[17:25] <hyperair> jbicha_: sure, but i don't really have the time for it right now. i have an exam tomorrow that i should have been studying for this afternoon but ended up bisecting that clutter bug instead. ;-)
[19:44] <cjohnston> jdstrand: pong
[19:47] <jdstrand> cjohnston: hi! I saw your email and watched the video. I'm fine with how to create meetings/sessions for the most part, but I have questions on how to approve them. I know about +settopics and used that for approving things that were in launchpad
[19:47] <cjohnston> yup
[19:47] <jdstrand> cjohnston: however, it is customary for my team to have roundtables as the first session of each day
[19:47] <cjohnston> yup
[19:48] <jdstrand> cjohnston: I created those in summit, but don't know how to approve them or how to make them be the first session of the day
[19:48] <jdstrand> ie, if I click 'Admin', I'm simply told I don't have privileges to change anything
[19:48] <cjohnston> if you are assigned as a track lead, and have the "Create a meeting" vs the "Propose a meeting" your meetings are auto scheduled
[19:48] <cjohnston> jdstrand: hangout?
[19:49] <jdstrand> cjohnston: ok. (fyi, I don't have 'create a meeting')
[19:49] <cjohnston> jdstrand: you have propose a meeting?
[19:49] <jdstrand> yes
[19:49] <cjohnston> hrm
[19:49] <cjohnston> one sec
[19:49] <jdstrand> which is what I used (and I am the security track lead)
[19:50] <cjohnston> can you do a hangout?
[19:50] <cjohnston> or phone if your US
[19:50] <jdstrand> sure
[19:54] <cjohnston> grr
[20:51] <nigelb> sabdfl: mind joining classroom channels? :)
[20:51] <sabdfl> nigelb, will do, on the hour
[20:52] <nigelb> sabdfl: Thanks!
[20:52] <Laney> my, these patch pilots sure are dedicated
[21:42] <sconklin> @pilot out
[21:44] <Laney> :P
[21:44] <infinity> ev, apw: Do you two plan to patch pilot for the next week? ;)
[21:45] <apw> @pilot out
[21:47] <Monotoko> hey, why are users homes not set, by default, to 600 any more?
[21:48] <Monotoko> (12.04)
[21:50] <mdeslaur> Monotoko: they've never been set to 600 on ubuntu
[21:51] <Monotoko> mdeslaur, really? I could never access another users files unless I was root/had sudo permissions on 10.04
[21:52] <mdeslaur> Monotoko: see https://wiki.ubuntu.com/SecurityTeam/Policies#Permissive_Home_Directory_Access
[21:53] <Monotoko> mdeslaur, thank you... would it not be a good idea to have this as an option in Ubiquity when you install?
[21:54] <mdeslaur> Monotoko: I don't think adding an install option for that would be useful for most users. If you're technical enough that you know what you want, you can easily change it after installation.
[21:55] <Monotoko> mdeslaur, most users will assume by default that their directories are protected, even Windows asks up front if you want protection
[21:56] <mdeslaur> Monotoko: most users want to share files. Even OS X has permissive home directories by default. This has been discussed to death already.
[21:57] <Monotoko> mdeslaur, which is why I'm suggesting adding it as an option during the install process, just a tickbox... I've just had my mother going through all my files thinking she had her own account and I was the sudo user... I was never informed otherwise
[22:00] <Monotoko> generally... if I add another account on my PC, it's because I don't want the person using it inside my account
[22:01] <infinity> Monotoko: As mdeslaur says, it's been discussed to death.  You're probably not going to argue any points that haven't already been argued.
[22:02] <infinity> Monotoko: We don't tend to add questions to the installer (in fact, we prefer to remove them), and this isn't something that matters to most people.  To the people it does matter to, they have very polarised opinions, and we decided to go with permissive homes.  It's simple to change the default.
[22:03] <Monotoko> infinity, so I don't understand why it's still not an option... or at the very least given on the screen as information during install, you have to actually go looking for the information (which most home users don't do) or find out the hard way when someone can access your files
[22:03] <mdeslaur> Monotoko: you can also check the "Encrypt my home directory" checkbox during install, which is a lot better than simply changing permissions on your home directory
[22:03] <infinity> (And, if I recall, this is the same default Windows has and, no, I don't recall it ever asking during install if I cared, so "they do it better/different" is a straw man)
[22:04] <infinity> Monotoko: Surely, you realize that if we asked/informed about every feature/option that everyone thought was important, the installer would be a mess, right?
[22:04] <maco> one more tickbox = twice as many code paths (exponential increases)
[22:04] <Monotoko> infinity, it was just an example, in Windows setting a password is optional (bad) but if you set one, it then also asks if you want to make it private
[22:04] <infinity> Monotoko: Just because this one's important to you, doesn't mean it's the same one that's important to everyone.
[22:04] <maco> +1 to encrypting your home dir
[22:06] <Monotoko> infinity, okay... maybe not during install, but at least when you're adding a user? It can't be too hard to write some text saying that user will be able to access others homes if you don't do "this" (hell, I would do it if you'll accept the patch?)
[22:06] <Monotoko> if it's been discussed to death... it's probably because people get burned by this, just like I have
[22:07] <infinity> It's been discussed in both directions.
[22:07] <maco> Monotoko: i believe the option to encrypt your dir so that it is really-for-reals not going to be seen by others is in the add-a-new-user dialog, but if it's not, that's a bug
[22:07] <infinity> Permissive homes are somewhat of a UNIX tradition.  I tend to find it a bit shocking when people expect otherwise, and don't check.
[22:07] <maco> changing the permissions just means i reboot your box into single user mode to see your data
[22:08] <maco> encrypting it prevents tht
[22:08] <Monotoko> infinity, as I say... I come from a Windows background (sadly) ;)
[22:08] <infinity> Permissive homes are also the Windows status quo.
[22:08] <infinity> Unless that changed in 7 or 8 when I wasn't looking.
[22:08] <infinity> But it certainly was in all previous NT releases.
[22:08] <infinity> Just sayin'.
[22:09] <infinity> And it never "asked".
[22:09] <maco> i recall being able to see others' files in xp, but maybe they changed it in vista when they tried to bolt security onto a broken window?
[22:09] <Monotoko> infinity, Windows XP does ask when you set a password on your account
[22:09] <Monotoko> it brings up a dialog with some text that tells you that other users can still see your files, and would you like to make them private
[22:10] <Monotoko> *asks if you would
[22:12] <infinity> I'm pretty sure I've never seen this dialog.  But alright.  It's somewhat unrelated to the discussion anyway.
[22:13] <Monotoko> infinity, http://i.techrepublic.com.com/gallery/94185-500-363.png
[22:14] <Monotoko> I know I'm side tracking, and I know Windows isn't the best example of good security, but surely you see my point?
[22:15] <infinity> My never seeing this probably has to do with never having installed a system without a password.
[22:16] <infinity> Anyhow.  Like I said.  Unrelated.  We offer an "encrypt your home directory" option in the installer.
[22:16] <infinity> I'm failing to see how that's not enough.
[22:16] <infinity> Relying on UNIX file permissions to save you from people with physical access to a machine is a losing battle.
[22:16] <infinity> And on server with many users, I'd expect people to know how to change the default, if they want to.
[22:17] <infinity> (Most multi-user systems tend to prefer permissive, though, cause man, it's a pain to share things otherwise)
[22:18] <Monotoko> infinity, do you really think a user migrating from Windows is going to hit the encrypt button? It has some negative connotations for whatever reason amongst most users, a real life analogy would be your neighbour walking into your home uninvited, now if you invited them (laxed the permissions or shared something with them) then it's different
[22:20] <Monotoko> if I want someone to access my home, I add them to my user group... the point is that the default should usually be the safest option, or at least warn you that your door is unlocked and anyone on the system can walk in
[22:29] <Monotoko> it just... doesn't sit right, I mean the root user is disabled because that's the safest way and stops users getting into trouble or screwing it up and it's secure, then you completely take a turn around and lax permissions around users
[22:31] <infinity> Dude, it's a simple thing to change.  I think when several people say "It's been discussed to death" what we mean is "your opinion won't change how it's been for the last 8 years", but we're trying to avoid coming off like jerks.
[22:32] <infinity> There's nothing "lax" about permissive homes as they are.  We take great pains to make sure that we store private data in less permissive directories (see ~/.ssh, ~/.config, etc)
[22:33] <larsduesing> aehm, short question - how to get rid of bug attachments in launchpad, which are not sent by me?
[22:33] <larsduesing> (there are login-data in an attachment...)
[22:33] <infinity> larsduesing: Oh dear.  I can hide that and escalate for more permanent removal.  /msg me a number?
[22:34] <larsduesing> done
[22:34] <Monotoko> infinity, sorry... I've had a bit of a day today with the default.. just thought I'd come talk to you guys, but if I'm hitting a brick wall it's fine, il remember it in future ._.
[23:03] <infinity> nixternal: For instance, "apt-cache show coreutils | grep ^Task" will show you that it's in minimal.
[23:03] <infinity> nixternal: If you're not generating those headers (via extra overrides fed to apt-ftparchive, or some other hackish method), you have no tasks.
[23:04] <nixternal> and let me guess, seeing as i am using a ppa right now for testing, something tells me that I can't get/set task headers
[23:07] <infinity> nixternal: Uhm, yeah, you're going to have to do that sort of thing locally.
[23:08] <infinity> nixternal: Of course, you can build in the PPAs, download the debs, and then do the local apt-ftparchive scanning.
[23:08] <infinity> nixternal: So, all is not lost. :P
[23:08] <nixternal> fun fun, thanks dude for pointing me in some sort of direction. at least it is closer than the direction i was heading :)
[23:08] <nixternal> even better, i have a local buildd with local apt-ftparchive
[23:19] <infinity> doko: Erm, you traded broken multilibs on armel for broken multilibs on armhf?
[23:21] <doko> infinity, the armhf gcc-multilib should be installable. do you think it's not?
[23:32] <doko> infinity, I thought the tex mess was fixed? https://launchpadlibrarian.net/103804133/buildlog_ubuntu-quantal-i386.gcc-snapshot_20120501-1ubuntu1_FAILEDTOBUILD.txt.gz
[23:37] <infinity> doko: It needs a publisher run still.
[23:37] <infinity> doko: I'll do a mass give-back when it's happy on all arches.
[23:37] <doko> thanks, afk now
[23:38] <infinity> doko: As for the gcc-4.7 multilib thing, it's FTBFS on armhf...
[23:38] <infinity> doko: Same way as it was previously on armel.
[23:38] <infinity> doko: Didn't you notice that in your PPA?
[23:38] <doko> infinity, sure, but the current binaries are installable
[23:38] <infinity> Well, yes.  I was just referring to the part where it's obviously still broken. ;)
[23:38] <infinity> The old ones should still work for now, yes.
[23:40] <doko> it's in a state that I can upload to quantal directly. this improvement was worth the binary copy
[23:41] <infinity> Heh, fair enough.