[06:26] <sammy> brand new package with no existing version in Ubuntu's repositories (will be uploaded with the .orig.tar.gz file): debuild -S -sa <- that means no existing version of this package of this version, right? if bob1.2 is in ubuntu, and i'm making a package for bob1.4 (not in ubuntu), I should be using -S -sa, not -S -sd, right?
[06:28] <RAOF> -sa means "include .orig.tar.gz in the _source.changes file", which means "I'm going to upload an .orig.tar.gz for this", which is what you need to do when that version is not in the archive yet, yes.
[06:29] <sammy> RAOF: huzzah, thank you. and to be clear, when I set the version number, I only need to do it in the changelog? debuild will pull the -ubuntu1ppa1 from there? I couldn't figure out where else to define the version.
[06:29] <RAOF> The changelog entry is what defines the version.
[06:30] <sammy> fantastic. yay for my first package from sid built for ubuntu
[06:31] <sammy> now if only my mail admin would fire up courier-authdaemond which didn't start at reboot so I can check my email, confirm my new pgp key and upload it...
[06:38] <didrocks> good morning
[06:41] <nigelb> Morning didrocks!
[06:41] <didrocks> hey nigelb
[06:41] <nigelb> Exciting week :)
[06:44] <pitti> Good morning
[06:46] <sammy> oh I knew I had one more: it says if this can be used in any version I dont have to append natty... I'm assuming thats not the case for most things? if it should be obvious to me, its not. I'm guessing that only stands true for some things like low-level libraries with few if any dependencies
[06:47] <sammy> (sorry I'd ask in ubuntu-packaging but theyre all asleep)
[06:47] <RAOF> Or if it builds against stable-ABI; many things which build against GNOME would qualify there.
[06:51] <sammy> this is an erlang program, ejabberd. hm. well a quick search on launchpad shows every ppa version lists the distribution. I assumed as such.
[07:10] <dholbach> good morning
[07:52] <YokoZar> does ticking the ubuntu-restricted-extras tickbox at install time enable s3tc?
[07:55] <RAOF> No.
[07:55] <RAOF> Bah, too slow.
[07:55] <RAOF> Hm, thinking of which...
[08:09] <infinity> dholbach: That Pilot day won't work for me, I'm on vacation.  Want to swap me a week later or something?
[08:12] <dholbach> infinity, sure - just move it somewhere else in the calendar
[08:12] <dholbach> I can do it too if you like
[08:12] <infinity> dholbach: Go ahead.  I don't want to much with your scheduling mojo.
[08:13] <rbasak> Can someone look at bug 862129 please - I've found tons of duplicates and there are more coming in daily. I think it's going to break a significant number of upgrades to oneiric, though I'm not clear under what circumstances it occurs.
[08:14] <dholbach> infinity, I'd love if it was just everybody's scheduling mojo and not mine :)
[08:14] <dholbach> anyway
[08:15] <dholbach> moved it a week later :)
[08:15] <dholbach> err, two weeks later
[08:15] <dholbach> there might be more important things than patch piloting at UDS
[08:15] <dholbach> alright - time to go and walk the dog - see you in a bit
[09:26] <Riddell> pitti: how can I test jockey driver install on a system where no non free divers are needed?
[09:31] <pitti> Riddell: copy http://bazaar.launchpad.net/~jockey-hackers/jockey/trunk/view/head:/examples/fake.modaliases to /usr/share/jockey/modaliases/fake
[09:39] <jussi>  /access
[09:39] <jussi> cjwatson: ping
[09:40] <Riddell> pitti: hmm, it still doesn't list any
[09:40] <cjwatson> jussi: yes?  (please include content with pings)
[09:41] <pitti> Riddell: you might need a "sudo killall jockey-backend" after installing the file, the backend keeps running for a while
[09:41] <Riddell> oh aye
[09:41] <jussi> cjwatson: sorry. Scott has deactivated himself from the ops team for here, just wanted to double check that its ok to remove him from the access list?
[09:41] <pitti> Riddell: if it still doesn't work, does "apt-cache show fglrx" work? is this a live system with no restricted package indexes perhaps?
[09:44] <cjwatson> jussi: yes
[09:44] <cjwatson> if he deactivated himself then that's fine
[09:56] <rbasak> Can someone look at bug 862129 please? I've found many duplicates and a new one comes in about once a day. I think it's going to break a significant number of upgrades to oneiric given how many bug reports we're getting from testers.
[10:01] <slangasek> tseliot: hey there - why is the /usr/share/grub-gfxpayload-lists/blacklist/00_header not sufficient to explain how to blacklist cards?
[10:02] <slangasek> tseliot: I don't understand why you want to re-add a slave link to an empty blacklist file; if you actually need it, you could add it back to the packaging then?
[10:03] <tseliot> slangasek: because this is a feature OEM should be able to use without my involvement. If they want to blacklist a card, they simply put the id in that file and that's it
[10:05] <slangasek> tseliot: ah.  Well, I'm not sure I agree this is the way to do it, but ok :)
[10:07] <tseliot> slangasek: ok, I'll make sure to change all proprietary drivers (8 packages) so that they have our changes
[10:09] <slangasek> tseliot: ok.  Note that CD mastering is already in progress, and I don't think reverting this warrants restarting that process, so nvidia-current (the one I converted already) should be done to oneiric-proposed or held until precise
[10:10] <tseliot> slangasek: I don't think the drivers are on the cd. Are you referring to the dvd image?
[10:11] <slangasek> tseliot: they're on mythbuntu, ubuntustudio, and DVDs (maybe only on the Kubuntu DVD?)
[10:11] <slangasek> maybe that change could still be accepted... should be coordinated with #ubuntu-release, anyway
[10:11] <OdyX> pitti, tkamppeter: would it make sense (aka "would you have time") to discuss http://wiki.debian.org/Teams/Printing/RethinkingTheStack before oneiric's release?
[10:12] <slangasek> but even so, it's not a critical fix so I don't think it warrants a final freeze exception
[10:13] <tseliot> slangasek: ok. It's not a critical fix as only nvidia-current will get the bootsplash, the other 7 driver still won't (unless there are other regressions that my previous changes caused, that is)
[10:15] <slangasek> tseliot: setting FRAMEBUFFER=n in the initramfs also breaks initramfs prompting for anyone with a crypted root filesystem
[10:16] <slangasek> so I think the other packages ought to be fixed for that as well
[10:17] <tseliot> slangasek: no doubt they should be fixed, the only question is when the fix should land
[10:17] <slangasek> tseliot: if they're not on the images, there's still time to fix them before release
[10:18] <slangasek> fglrx-installer seems to also affect the kubuntu DVD
[10:19] <tseliot> slangasek: I can do it today. I expect the -updates flavours not to be on any image but the non -updates flavours should affect the images, as you said
[10:19] <tseliot> as in fglrx-updates vs fglrx
[10:23] <slangasek> tseliot: right, only fglrx and nvidia-current are on any images, the other variants (-updates, and the older nvidia flavors) are not
[10:24] <tseliot> slangasek: so, shall I upload only fglrx and nvidia-current to oneiric-proposed and the rest to oneiric?
[10:24] <slangasek> tseliot: I think that's best, yes
[10:25] <tseliot> slangasek: ok, thanks for your help
[10:26] <slangasek> tseliot: thank you :)
[10:29] <akgraner> Hi all!
[10:30] <akgraner> So open week is next week - if anyone can add a session you think new users or end users would like to know about and you all would like to share as it relates to Ubuntu or more specifically the 11.10 release please let me or jcastro know or please add your session to the open week schedule
[10:31] <akgraner> I know it's a busy week for everyone, but Open Week is really popular and the community loves it...
[10:47] <spy6> hi there
[10:48] <spy6> are there already 11.10 pre-release images available?
[10:48] <pitti> spy6: we are just rebuilding everything; but you can subscribe to images on http://iso.qa.ubuntu.com/qatracker/build/ to help out with testing
[10:49] <pitti> spy6: note that these are not the official images until they are announced
[10:49] <pitti> and they might change, be broken, etc.
[10:49] <spy6> pitti: thats okay ... in most cases an upgrade after the release might help
[11:09] <spy6> pitti: hmm ... if subscribed, the link for the image is published via mail?
[11:10] <pitti> spy6: you'll get notifications about new images, yes
[12:31] <fishor> hallo all, i investing some time to make vp8 work better. there are some patches upstream now (gstreamer), but there are also some not. In current ubuntu beta, gstreamer webm and matroska muxer has one bug. If you create high quality vp8 stream it will be partially brocken. I have a patch to fix it. This patch will not go to upstream becouse i need to make it per stream choice, not per file (as long term solution). my question do will actual
[12:31] <fishor> ly accept this patch?
[12:43] <brendand> i'm wondering is there a known bug in Gtk where if a child dialog hides itself when it's already hidden then the parent gets hidden as well/instead?
[12:44] <seb128> bah, interaction with kernel bugs is ridiculous, it's an incomplete-new pingpong with a robot on every kernel upload :-(
[12:45] <ogra_> not only with uploads :/
[13:04] <didrocks> seb128: yeah +1 for me, and I still have my wifi driver randomly not loading correctly for the sprint
[13:05] <didrocks> since*
[14:27] <doko> soren, \o/
[14:27] <herton> broder: hi, can you confirm bug 848687 is fixed with natty -proposed (2.6.38-12.51) kernel, and set the verification tag there?
[14:37] <mvo> if there is anyone here speaking hebrews, could you please have a look at https://launchpadlibrarian.net/82484100/update-notifier-he.png and tell me if that string is correct ? and correctly line broken too?
[14:42] <dholbach> mvo, I don't, but shouldn't they all be justified to the right side?
[14:43] <dholbach> mvo, you could try asking in #ubuntu-il
[14:44] <mvo> thanks dholbach
[14:44] <mvo> dholbach: that is a excellent idea
[14:46] <soren> doko: Yeah :)
[14:50] <Laney> doko: your temporary patch to drop the darcs test suite on ppc, can I get rid of it now?
[14:50] <Laney> doing an upload to work around the test failures
[14:52] <doko> Laney, yes, I think so. ftbfs on armel too
[14:52] <Laney> yep, should fix that
[14:52] <Laney> also I am no longer convinced tests-use-bash does anything meaningful
[14:52] <Laney> the test harness forces bash anyway
[16:56] <bdmurray> Should bug 870214 be assigned to a package?
[17:08] <cjwatson> bdmurray: open-iscsi would be a decent start
[17:11] <broder> herton: let me see if any of my coworkers actually tested it like they said they would. if not, it was easy to reproduce - i can get you an answer in about 15 minutes or so
[17:11] <herton> broder: ok, thanks
[17:13] <broder> herton: yep, coworkers forgot :). hunting down the machine with the problem now
[17:34] <bambee> pitti: ping, language-selector-0.54 breaks language-selector-kde
[17:34] <ScottK> There we go.
[17:34] <bambee> "* LanguageSelector/LangCache.py [change not affecting KDE]:" -> it breaks language-selector-kde
[17:34] <ScottK> bambee: Did you file the bug yet?
[17:34] <ScottK> pitti was asking me how to test it.
[17:35] <bambee> just type "kcmshell4 language-selector"  (reproducible : always) , let me open a bug first.
[17:36] <pitti> bambee: ah, I tried to click on Region etc, and nowhere there it offers to install languages
[17:39] <bambee> systemsetting -> locale-> system language (something like that)
[17:39] <pitti> ok, ETA 12 mins for downloading
[17:48] <broder> herton: i'm updating the bug now, but the fix is good. thanks for pinging me
[17:49] <herton> broder: cool, thanks for checking it
[17:55] <pitti> bambee, ScottK: I get: The service 'System Languages' does not provide an interface 'KCModule' with keyword language-selector/language-selector.py'.. is that what you see as well?
[17:57] <pitti> ah, get it -- no sys.argv, hmm
[17:58] <pitti> bambee: is there a bug report for this already?
[18:02] <bambee> pitti, ScottK : bug 871922
[18:04] <pitti> ScottK, bambee, debfx: thanks, fix uploaded
[18:06] <jdstrand> pitti: hey, I noticed that /run/motd is getting created with group read permissions via /etc/init/mounted-run.conf. I'm thinking this is because of the default umask of 0002, but was wondering where mounted-run.conf is getting its umask. do you know off-hand?
[18:06] <jdstrand> pitti: asking you cause it seems you were driving the bp. feel free to tell me to go away if desired
[18:07] <pitti> jdstrand: not off-hand, no; but apparently through pam then
[18:07] <jdstrand> hmm
[18:07] <pitti> jdstrand: perhaps upstart launches all services through PAM?
[18:07] <jdstrand> wonders why that upstart script is getting run through pam
[18:07] <jdstrand> maybe
[18:07] <pitti> would make sense for some kinds, such as having locale settings
[18:07] <jdstrand> jhunt: ^ can you comment?
[18:08] <jdstrand> that file could conceivably be localized
[18:08] <jdstrand> pitti: thanks
[18:09] <jdstrand> run-parts' man page says it defaults to 022. I wonder if that is still accurate
[18:13] <pitti> jdstrand: oh, you think it's from run-parts or within udev?
[18:13] <pitti> I had assumed that the entire udev process runs under 002, and just passes that to its children
[18:13] <jdstrand> pitti: well, mounted-run.conf does this: [ -d "/etc/update-motd.d" ] && run-parts --lsbsysinit /etc/update-motd.d > /run/motd &
[18:13]  * pitti wonders if one can determine the umask from /proc
[18:14]  * jdstrand was wondering the same
[18:14] <jdstrand> if remove the file then do 'sudo start mounted-run', it is created 0022
[18:15] <jdstrand> so it might be update manager that is doing it... (guessing, and trying)
[18:15] <pitti> jdstrand: attaching gdb to a process and "call umask()" seems to do the trick
[18:15] <jdstrand> cool, thanks
[18:16] <pitti> hmm, no
[18:16] <pitti> udevd runs with umask 022
[18:17] <jdstrand> granted, this isn't a problem in and of itself; I just find it curious
[18:20] <jdstrand> aha
[18:20] <jdstrand> if I ssh 127.0.0.1, then it gets changed
[18:22] <jdstrand> so, pam_motd
[18:25] <jdstrand> (where pam_umask is called easlier in the stack)
[18:26] <pitti> tseliot: nvidia-graphics-drivers is an SRU without a bug link, can you please reupload with a bug link?
[18:26] <pitti> tseliot: or to oneiric final? (we need to respin anyway)
[18:27] <pitti> tseliot: but even then a bug would be appreciated, it's quite a complex change
[18:28] <tseliot> pitti: ah, if you need to respin, I'd prefer oneiric final. I'll also add a reference to bug #854967
[18:28] <pitti> tseliot: thanks
[18:28] <tseliot> pitti: please reject both fglrx-installer and nvidia-graphics-drivers
[18:28] <pitti> tseliot: want to reupload fglrx-installer to final as well?
[18:28] <pitti> tseliot: ack, done
[18:29] <tseliot> pitti: yes, sure
[18:29] <pitti> tseliot: fglrx-updates has a copy-paste error in changelog ("nouveau"), but the actual debian/rules seems fine
[18:29] <pitti> tseliot: in case you want to fix on reupload
[18:29] <pitti> (of fglrx)
[18:30] <tseliot> pitti: sure, I can fix that one too if you reject it
[18:30] <pitti> tseliot: nah, accepted
[18:30] <tseliot> pitti: ok
[18:36] <tseliot> pitti: I've just re-uploaded both nvidia-graphics-drivers and fglrx-installer
[18:36] <pitti> tseliot: cheers
[18:36] <tseliot> pitti: thanks for your help
[18:37] <pitti> tseliot: hm, bug 854967 has tasks for all the other versions, too
[18:38] <tseliot> pitti: there were two bug reports which overlapped a bit. I fixed both
[18:38] <pitti> tseliot: ah, so you need to manually close out the other tasks
[18:39] <tseliot> pitti: right
[18:46] <jdstrand> pitti: fyi, filed bug #871943 in case you are curious
[18:47] <jdstrand> pitti: I should have said 'fyi (in case you're curious): file bug 871943'
[18:47] <jdstrand> meh
[18:47] <jdstrand> filed
[18:47] <jdstrand> I can't type. Hopefully the bug is worded better :)
[19:01] <jhunt> jdstrand: upstart isn't pam-aware (yet :)
[19:02] <jdstrand> jhunt: yeah, took me a bit, but I got to the bottom of it (bug 871943). thanks!
[19:08] <bdmurray> stgraber: should bug 813065 not be set to Fix Released based on comment #9?
[19:20] <sivang> hi all
[19:31] <sivang> i know this is not a devel question, but perhaps there are ubuntu devs who know me who could let me surf their couches around the dates of Nokia world (22oct 24, 27 to 31st oct) ? :)
[19:31] <sivang> in London or area
[19:33] <jdstrand> pitti: sorry to bother you again, but I added a comment to https://blueprints.launchpad.net/ubuntu/+spec/umask-to-0002. I feel like there is a bug here, but I'm not sure where
[19:35] <jdstrand> pitti: I noticed that /etc/dpkg/origins/* were group writable with 6.4ubuntu4, but not 6.4ubuntu5. I tracked this down to dpkg-source -x applying a umask, which is different for various developers. eg, mvo apparently is using 0002, but cjwatson 0022
[19:35] <micahg> natty vs oneiric dev machine?
[19:36] <jdstrand> of course dpkg-source clearly says it will do that, but the changed default umask in the distro is changing permissions for installed packages
[19:36] <jdstrand> micahg: doubtful-- I would think cjwatson is using oneiric
[19:39] <jdstrand> one could argue it is a packaging bug if it doesn't set the permissions correctly, and that is true, but I worry that this could result in security issues (eg, something that should have group read only, but all of a sudden gets group write)
[19:42] <cjwatson> I'm using oneiric but I have an explicit umask 022 in .bash_profile for some reason
[19:42] <cjwatson> base-files is probably unusual here since it doesn't use debhelper - it should set the right perms explicitly
[19:42] <cjwatson> practically everything else uses dh_fixperems
[19:42] <cjwatson> -e
[19:43] <pitti> jdstrand: I guess dh_fixperms might not change the permissions of conffiles?
[19:43] <cjwatson> irrelevant since base-files doesn't use it
[19:43] <pitti> ah
[19:43] <jdstrand> tbh, I forgot about dh_fixperms in my worrying
[19:43] <jdstrand> :)
[19:43] <cjwatson> bootstrapping reasons I think
[19:43] <pitti> jdstrand: this particular case shoudl be harmless as it's group root, right?
[19:43] <jdstrand> pitti: so far, yes
[19:43] <cjwatson> and the current state is what we want too
[19:44] <jdstrand> cjwatson: 'current state' -- you mean whatever we have in the directory?
[19:45] <jdstrand> oh, current state of ubuntu5?
[19:45] <cjwatson> I mean 6.4ubuntu5 is the current version and has mode 0644 which is what we want, so it's not RC
[19:45] <jdstrand> yes, agreed
[19:45] <cjwatson> but we should definitely fix debian/rules to be explicit here
[19:45] <jdstrand> ok, I'll file a bug
[19:45] <cjwatson> I suggest filing a precise alpha-1 bug?
[19:45] <cjwatson> yeah
[19:46] <cjwatson> um, how are you getting non-group-writable in 6.4ubuntu5?
[19:46] <cjwatson> lp_archive@cocoplum:~$ dpkg -c ubuntu/pool/main/b/base-files/base-files_6.4ubuntu5_i386.deb | grep origins/u
[19:46] <cjwatson> -rw-rw-r-- root/root       114 2011-07-08 17:13 ./etc/dpkg/origins/ubuntu
[19:46] <cjwatson> (still, not RC since it's group root, as pitti says)
[19:46] <jdstrand> I looked at my own system compared to a VM with ubuntu4
[19:47] <jdstrand> then I looked at the tar.gz of each and noticed the disparity
[19:47] <cjwatson> perhaps the permissions aren't changed on upgrade; that wouldn't surprise me
[19:49] <jdstrand> no
[19:49] <jdstrand> ar x ... ; tar -ztvf ./data.tar.gz shows they are group writable
[19:50] <jdstrand> so I guess it is happening on the buildd
[19:56] <jdstrand> fyi, filed 871977
[20:00] <jdstrand> ok, I updated my comment in the bp
[20:27] <Laney> stgraber: ping to publish package set script somewhere
[20:29] <stgraber> Laney: yep, just read the backlog of the DMB meeting
[20:31] <Laney> just getting my actions out of the way :P
[20:31] <stgraber> Laney: I pushed it at https://code.launchpad.net/~developer-membership-board/+junk/packageset-report/ last week
[20:31] <Laney> awesome!
[20:59] <jdstrand> while most use dh_fixperms, some subset will use 'dh_fixperms -Xfoo' resulting in bug #872000
[20:59] <jdstrand> still not security relevant, but not desirable either
[21:42] <SpamapS> is there an easy way to have sbuild add extra deps to a chroot before resolving build deps?
[21:43] <broder> SpamapS: i've done it with --chroot-setup-commands "dpkg --force-depends -i /path/to/*.deb" --chroot-setup-commands "apt-get install -f -y"
[21:43] <broder> it wasn't pretty
[21:43] <broder> i think RAOF said he had a script to do it also
[21:43] <broder> the better approach would probably be to use apt-ftparchive to build a temporary repo and use --chroot-setup-commands to add it to the sources.list
[21:43] <SpamapS> its a pain when trying to prepare an upload to a PPA with a lot of extra build deps
[21:47] <broder> SpamapS: i went and checked debbugs to see if someone had requested this already, but was too irresponsible to actually file a bug about it, so that might be a good thing to do
[21:47] <broder> rleigh is generally awesome and responsive, though wishlist bugs probably get less love
[21:48] <RAOF> SpamapS: You mean add an extra, possibly local, repository of build-deps?
[21:49] <bdrung> Laney: http://anonscm.debian.org/gitweb/?p=collab-maint/distro-info.git
[21:49] <bdrung> tumbleweed, Laney: i pushed the haskell rewrite
[21:50] <Laney> what brought this about?
[21:50] <bdrung> tumbleweed: the short and long description needs to be updated
[21:50] <Laney> night
[21:51] <bdrung> Laney: it's faster than the python version (~ six times)
[21:51] <RAOF> SpamapS: http://paste.ubuntu.com/705623/ is what I use, along with /etc/schroot/local-packages/fstab: http://paste.ubuntu.com/705622/ and /etc/schroot/local-packages/config: http://paste.ubuntu.com/705621/
[21:52] <SpamapS> RAOF: thanks, that at least confirms for me that this is really hard. ;)
[21:53] <RAOF> Heh.
[21:54] <RAOF> Once you've dumped those in, though, it's easy to create a chroot conf like http://paste.ubuntu.com/705628/ :)
[22:13] <bdrung> tumbleweed: besides the description update, is there something that needs to be done before release d-i 0.3?
[22:16] <slangasek> SpamapS: "covered by clouds" - hah!
[22:20] <SpamapS> slangasek: I qualified it. :)
[22:21] <slangasek> SpamapS: oh, that was a "hah" of amusement at the analogy, if that wasn't clear :)
[22:29] <SpamapS> slangasek: right, I was thinking it was a hah! of "fat chance".. ty either way, for reading.
[23:50] <ScottK> zul: I think your xen upload needs to go to -proposed and not -release.
[23:51]  * ScottK rejects.   Please reupload.
[23:51] <zul> ScottK: how come?
[23:51] <ScottK> Because everything is pretty locked down for the release right now.
[23:51] <ScottK> In Main I don't think we're accepting anything not worth holding the release for.
[23:53] <zul> ScottK: k