[03:48] <pitti> Good morning
[03:50] <pitti> slangasek: I can remove 628104 from the dupe db, so that apport will take the next incoming bug as the new master bug
[03:56] <pitti> slangasek: done
[04:11] <Sarvatt> pitti: thats possible? could you do the same for 933504? its sucking up unrelated bugs and the retracer is deleting the good stacktrace info from the dupes that are unrelated. i filed 2 completely unrelated bugs that got duped to it and have been fixed in the meantime
[04:11] <pitti> Sarvatt: sure, removing
[04:17] <Sarvatt> pitti: thank you so much, i've been struggling to figure out why apport was duping in that sitation and doko's bug everything is getting duped to has been fixed for months, a new master bug with current issues will help
[04:19] <Sarvatt> it would be extremely nice if it didnt remove stacktraces btw when it decides its a duplicate :)
[04:19] <pitti> Sarvatt: that's a tradeoff we need to decide about
[04:19] <pitti> Sarvatt: making duplicate bugs public automatically, or keeping stack traces in dupes
[04:21] <Sarvatt> theres situations where stacktraces need to be private?
[04:21] <Sarvatt> i never see them so seems strange to me, deleting the core dump should be enough
[04:21] <pitti> yes, they can potentially contain passwords, credentials, or other private information
[04:22] <pitti> that might also be project names you are working on, etc.
[04:22] <pitti> apport anonymizes the initial information that it sends (home directory, wifi passwords, and the like)
[04:22] <pitti> but we don't anonymize stack traces
[04:23] <pitti> (because that's a hard and fuzzy problem)
[04:23] <lifeless> pitti: you need to make the master public
[04:23] <lifeless> pitti: we pay a continual cost due to it not being public.
[04:23] <lifeless> s/you/we/
[04:23] <pitti> with ev's whoopsie DB this will hopefully be better soon
[04:24] <pitti> as it can potentially offer more fine-grained control to data than a LP bug
[04:24] <pitti> so that we can keep the dupes private in LP as well, or not have them in the first place any more, etc.
[04:24] <pitti> but yes, there is also bug 764414
[04:25] <pitti> the second part there got mitigated by client-side dupe detection, but "confusing" still stands
[04:31] <pitti> jamespage: hey
[04:31] <pitti> jamespage: I just noticed that https://launchpad.net/ubuntu/oneiric/+queue?queue_state=0 has a 6 month old jonas-full-5.2 upload from you; is that still relevant?
[04:41] <pitti> Sarvatt: btw, there is one trick -- close the main master bug (fix released, invalid, etc.)
[04:41] <pitti> Sarvatt: then the next duplicate that comes in will become a new master bug, and apport just points out "this looks like that bug ---> over there, but that is already fixed"
[04:43] <RAOF> That's also super-confusing, though.
[04:44] <Sarvatt> pitti: i needed confirmation from the reporter that it was fixed to actually close it even though i know its fixed and he hasnt responded, doko was hitting the eglibc bug months ago :)
[04:46] <Sarvatt> i guess just closing it is appropriate at this point
[06:11] <slangasek> pitti: thanks!  Is there a way that this should be self-service, like bug patterns were before?
[06:12] <pitti> slangasek: it's a bit harder, as you need sudo -u ubuntu-archive -i on osageorange
[06:12] <pitti> slangasek: i. e. you can
[06:12] <pitti> slangasek: for the layman developer it's either "close the old master bug" or "ping seb128 or me"
[06:12] <slangasek> hmm, ok
[06:12] <slangasek> well, even when the master bug was closed, users were apparently being directed there
[06:14] <pitti> ah, I guess they would, yes
[06:16] <pitti> so in many case this is actually right, especially for bugs which got fixed recently and people are still running older versions (or older releases)
[06:16] <pitti> so for the "that master bug needs a new stack trace" case that doesn't work
[06:17] <pitti> slangasek: we could make it self-service with a tag like apport-nodup or apport-newtrace
[06:17] <slangasek> I think that might be best
[06:35] <dupondje> could someone check https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/952964
[06:35] <dupondje> thx :)
[07:55] <ev> Do we have a general approach for handling not being able to lock /etc/passwd in a postinst?
[08:14] <jamespage> pitti, I'd not realised that had not actually landed in oneiric...
[08:19] <diwic> jibel, ping
[08:19] <jibel> diwic, pong
[08:20] <diwic> jibel, in bug 981149 you claim that your headset shows a digital profile. Could you file a separate bug for your issue with "ubuntu-bug pulseaudio" and point me to it?
[08:20] <jibel> diwic, ack
[08:20] <diwic> jibel, if you do so the bug report will contain the name string needed to put in /usr/share/alsa/cards/USB-Audio.con
[08:20] <diwic> f
[08:23] <jibel> diwic, bug 987163
[08:25] <diwic> jibel, thanks! I will collect these and make an SRU out of them
[08:25] <jibel> diwic, is it the name I should but in USB-audio.conf "Logitech Logitech Wireless Headset at usb-0000:00:16.0-4, full speed" ?
[08:25] <diwic> jibel, the string is: "Logitech Wireless Headset" 999
[08:26] <jibel> s/but/put
[08:26] <jibel> diwic, ok, thanks!
[10:24] <jibel> doko, ping
[10:32] <doko> jibel, hi
[12:14] <jdstrand_> roaksoax: hi! I was reviewing the maas-provision changes and wonder why you install the apparmor profile disabled?
[12:16] <dupondje> Its so silent here today :)
[13:01] <hrw> hi
[13:02] <hrw> I know it is late but bug 890928 could get fixed by syncing newer version from debian.
[13:07] <ScottK> hrw: It will have to be uploaded to precise-proposed at this point.  Too late for a straight sync.
[13:09] <hrw> ScottK: 1.0.8-1 can be accepted in -proposed?
[13:13] <pitti> note that we can sync into -proposed, but that needs some extra bookkeeping as the changelog wouldn't have a LP bug ref
[13:13] <pitti> multiarchification doesn't need a new upstream release, though
[13:16] <ScottK> For proposed it should be the minimal change to solve the problem.
[13:18] <dupondje> could someone check https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/952964 ?
[13:20] <seb128> dupondje, that seems fine for a SRU, can you subscribe ubuntu-sponsors so it doesn't get lost?
[13:20] <seb128> oh, it's already done
[13:21] <dupondje> quite annoying bug :) seems like it affects quite some people also
[13:22] <hrw> ScottK: so debdiff from bug should be fine as it has only multiarch stuff in it
[13:22] <seb128> dupondje, yeah, as said SRU should be no problem for it
[13:22] <seb128> dupondje, it's too late for non SRU uploads
[13:23] <ScottK> hrw: Without looking, I'd say yes.  Please make sure ubuntu-sponsors is subscribed.
[13:23] <dupondje> as long it gets uploaded i'm happy :D
[13:25] <hrw> ScottK: they are
[13:26] <ScottK> OK.
[13:30] <StevenK> stgraber: Can I be unsubscribed from ISO testing? The website says the page is still in progress.
[13:33] <stgraber> StevenK: sure
[13:33] <stgraber> StevenK: done
[13:34] <dupondje> seb128: another small question, I see that clipboard doesn't work neither in Remmina. better to have 2 uploads or 1 with both fixed ?
[13:34] <seb128> dupondje, one with both fixed is fine if you are confident with the fixes
[13:35] <dupondje> well scrolling is fixed (and accepted upstream also). Need to check how to fix clipboard :)
[13:37] <StevenK> stgraber: Thanks!
[14:01] <mterry> Name for Q announced: http://www.markshuttleworth.com/?p=1121
[14:02] <jussi> yeah... we always knew it would be strange :P
[14:05] <kklimonda> QQ moar ;)
[14:06] <doko> jamespage, online?
[14:07] <jamespage> doko, yep
[14:07] <mterry> kklimonda, hah, never thought of the opportunity for QQ jokes
[14:33] <pitti> mterry: at last!
[14:34] <mterry> pitti, right up to the wire.  :)
[14:38] <pitti> after so many alliterations my head is smoking now :)
[14:39] <pitti> "quantal" as an adjective is barely in the dictionary..
[14:43] <barry> pitti: once again, my own suggestion isn't even mentioned: qwazy quahog
[14:52] <pitti> mhall119: could you jump into #ubuntu-desktop for a bit, please?
[15:59] <roaksoax> jdstrand: howdy!! TBH I used the changes in packaging of rsyslog for the apparmor installation in maas-provision. However, given tha aa-status showed that the profile was being enforced I didn't think it was really disabled
[15:59] <IntuitiveNipple> Is anyone looking at the grub2 regression where grub fails to function on mdraid devices (LP: #987354 Debian 668920) after an upgrade to Precise?
[16:00] <cjwatson> IntuitiveNipple: Usually that's due to incorrect installation location.  'dpkg-reconfigure grub-pc' and make sure all disks your system might boot from are selected.
[16:00] <cjwatson> Every time there's an ABI change between GRUB core and modules we get a flurry of this kind of question.
[16:01] <cjwatson> Which does indicate a problem somewhere, probably, but not where most people think it is :-)
[16:02] <IntuitiveNipple> cjwatson: Yes, I noticed your comment on the Debian bug. I'm trying to identify a way to recover at the grub rescue prompt right now since the server has no alternate boot means
[16:02] <IntuitiveNipple> cjwatson: I'm delving into the changes since -17 right now, I'll see what I can find
[16:02] <cjwatson> Like I say, there's an ABI change since -17.
[16:03] <cjwatson> So if your GRUB is improperly installed, you might have core image and modules that no longer know how to talk to each other.
[16:03] <cjwatson> http://www.gnu.org/software/grub/manual/grub.html#GRUB-only-offers-a-rescue-shell
[16:04] <cjwatson> There may not be a way to recover from there alone, although you might get lucky somehow.
[16:04] <IntuitiveNipple> cjwatson: It's annoying since about the only rescue command that works is "set" !
[16:06] <jdstrand> roaksoax: I think you didn't unload it or something in your testing-- aa-status didn't show it as loaded here. It couldn't get loaded by the packaging because you specified the wrong file to dh-apparmor
[16:07] <jdstrand> roaksoax: see my changes in https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=
[16:08] <jdstrand> roaksoax: also, please see bug #987374
[16:08] <jdstrand> roaksoax: I mentioned this to Daviey in #ubuntu-release already
[16:10] <IntuitiveNipple> cjwatson: I've just found a neat workaround to get booted... in BIOS I changed the order of the first two hard disks around on the premise that only the 2nd half of the mirror had been updated by grub-pc. It's allowed the server to boot so I can now at least sort it out
[16:12] <cjwatson> Makes sense
[16:12] <cjwatson> So now fix things in 'dpkg-reconfigure grub-pc' and that won't happen again
[16:12] <IntuitiveNipple> Saves having to open the system and put in a CD-ROM
[16:12] <IntuitiveNipple> Yeah. I'll look to see what precisely is wrong with the existing configuration now
[16:27] <jdstrand> @pilot in
[16:31] <Adri2000> cjwatson: out of curiosity, why did you add Pre-Depends: dpkg (>= 1.15.7.2) for dpkg-maintscript-helper in horizon? horizon is only in precise and dpkg-maintscript-helper has been available for the last few releases, so I don't see in what use cases it could be useful. except if we support a single apt operation which would do lucid->precise _and_ install horizon, in which case horizon could be configured with a too old dpkg
[16:32] <cjwatson> Adri2000: Because it's much easier to make sure every single package in the archive has that than to worry about exceptions.
[16:32] <cjwatson> Adri2000: This way I could just say "http://lintian.ubuntuwire.org/tags/preinst-uses-dpkg-maintscript-helper-without-predepends.html is empty, job done".
[16:33] <cjwatson> And it clearly does no harm.
[16:33] <cjwatson> And yes, in theory an upgrade with, say, dselect or aptitude might install horizon before upgrading dpkg.  It doesn't hurt to be more correct.
[16:34] <roaksoax> jdstrand: yeah i'm working on bug #987374
[16:34] <jdstrand> roaksoax: cool, thanks
[16:36] <Adri2000> cjwatson: ok. I missed the fact that lintian complains with an error about this; indeed it makes no harm to fix that everywhere
[17:25] <hallyn> cjwatson: hey, i'm installing from usb (first from the desktop installer, now the alternate) onto a lenovo x130e.  i keep booting into rescue mode and running'grub-install /dev/sda', but booting from hd i immediately get "Missing operating system".  Have you seen that before?
[17:27] <hallyn> (googling is not helping)
[17:27] <hallyn> i guess i can try the server iso (xferred to usb), and then pxe, but i'm getting the feeling this is some uefi thing
[17:27] <hallyn> i did turn off uefi in bios
[17:31] <cjwatson> hallyn: no.  make sure you have grub-pc installed not grub-efi* if you intend to boot from BIOS
[17:31] <cjwatson> otherwise don't know ...
[17:36] <hallyn> cjwatson: well first it had uefi enabled, same failure
[17:36] <hallyn> right now it's installing server iamge from pxe, will see how that goes
[17:36] <hallyn> then will look for grub-pc
[17:59] <roaksoax> jdstrand: so if cobblerd runs dnsmasq, do I also have to add all the permissions for dnsmasq in the cobbler apparmor profile?
[18:02] <slangasek> roaksoax: what do you mean by "permissions for dnsmasq"?
[18:02] <slangasek> cobblerd's profile needs to have access to run dnsmasq
[18:02] <slangasek> and dnsmasq may be confined, but doesn't inherit
[18:04] <roaksoax> slangasek: right, so this is what I'm adding to cobbler's appamor profile: http://pastebin.ubuntu.com/942885/
[18:04] <jdstrand> roaksoax: no. don't do that
[18:05] <slangasek> right.  cobbler needs permission to execute /usr/sbin/dnsmasq, it should *not* be given write access to dnsmasq's own config.
[18:05] <jdstrand> roaksoax: I mean, you *could*, but the mir doesn't require dnsmasq to be confined and you are adding additional privileges to cobbler
[18:06] <jdstrand> roaksoax: how is it starting dnsmasq? via its initscript?
[18:06] <roaksoax> jdstrand: ok then, it is starting it with service dnsmasq start
[18:06] <roaksoax> jdstrand: thought this will only be an issue when someone installs maas-dhcp
[18:09] <jdstrand> roaksoax: service uses the initscript?
[18:10] <hallyn> cjwatson: well i can't explain it.  installing from mini-iso through pxe worked fine.  That's after 4 installation attempts from usb.  Dunno what could be different.  Hope it was "just me" and not indicative of future bug reports
[18:10] <roaksoax> jdstrand: nope, dnsmasq is started with service dnsmasq start, but it also uses /etc/init.d/dnsamsq status
[18:12] <bdmurray> what more should happen with bug 985462?
[18:14] <jdstrand> roaksoax: I suggest starting with something like this: http://paste.ubuntu.com/942898/
[18:15] <jdstrand> roaksoax: that uses a child profile for service. You will probably have to add a few things to the dnsmasq_service child profile, but the idea is keep the cobbler profile confined and then just let dnsmasq do its thing
[18:21] <roaksoax> jdstrand: right, so, all the files that cobbler read/writes for dnsmasq should be added in the parent profile then
[18:23] <jdstrand> roaksoax: yes. if cobbler is writing out files for dnsmasq configuration, you need to let it do that in the parent
[18:23] <roaksoax> jdstrand: after adding the child profile, realoding apparmor and running cobbler sync, this is shown in syslog: http://pastebin.ubuntu.com/942914/
[18:24] <jdstrand> roaksoax: please paste the full profile
[18:25] <roaksoax> jdstrand: http://paste.ubuntu.com/942917/
[18:25] <jdstrand> roaksoax: you probably just need to add this to the child profile: #include <abstractions/base>
[18:26] <jdstrand> roaksoax: yes, please add that
[18:30] <roaksoax> jdstrand: now I get file_mprotect
[18:30] <roaksoax> err
[18:30] <roaksoax> apparmor="DENIED" operation="file_mprotect" parent=31733 profile="/usr/bin/cobblerd//dnsmasq_service" name="/bin/dash" pid=31734 comm="service" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[18:31] <jdstrand> roaksoax: yep, add #include <abstractions/bash>
[18:31] <jdstrand> roaksoax: and also "/bin/dash ixr,"
[18:33] <cjwatson> hallyn: PXE would be BIOS, but in the USB case the installer might be booted using UEFI, in which case it reasonably assumes that it should install that way too
[18:34] <roaksoax> jdstrand: ok had to add a couple more things: http://paste.ubuntu.com/942936/
[18:34] <jdstrand> roaksoax: can you use this instead:
[18:35] <jdstrand> /usr/sbin/service ixr,
[18:35] <jdstrand> /usr/bin/basename ixr,
[18:35] <hallyn> cjwatson: main other difference was that every time from usb i did manual partitioning with first 120G as ext4 /, from pxe i just said 'do what you want'
[18:35] <hallyn> cjwatson: like i say for most of the usb installs it was still the default (uefi)
[18:35] <roaksoax> jdstrand: cool! thanks for the help. I'll test this in a clean install
[18:35] <hallyn> so i'm afraid i can't be the only one who'll hit this.  but i don't understand it enough to file a bug, i think
[18:36] <jdstrand> roaksoax: I was hoping to limit cobbler use of 'service' to be only dnsmasq, and the Uxr on service would allow it to do anything I think
[18:36] <jdstrand> roaksoax: did the ixr for 'service' and 'basename' work for you?
[18:36] <roaksoax> jdstrand: they did
[18:36] <jdstrand> roaksoax: awesome :)
[18:37] <roaksoax> jdstrand: indeed!! thanks! I'll test it again to make sure i'm not missing anything
[18:37] <jdstrand> roaksoax: I'm betting you will want /usr/share/distro-info/ubuntu.csv r, to be /usr/share/distro-info/*csv r,
[18:38] <jdstrand> roaksoax: just in case going forward
[19:24] <roaksoax> jdstrand: ok so this should be it. Could you please also test it when you have the time? Thanks! http://paste.ubuntu.com/943031/
[19:25] <jdstrand> roaksoax: you need writes to /usr/lib/syslinux/** ?
[19:26] <jdstrand> roaksoax: I see /etc/xinetd.d/tftp rw as well-- aren't we using tftp-hpa?
[19:26] <jdstrand> roaksoax: (not to mention, we don't use xinet.d)
[19:26] <jdstrand> roaksoax: maybe for those use this instead:
[19:27] <jdstrand> deny /etc/xinetd.d/ rw,
[19:27] <jdstrand> deny /etc/xinetd.d/tftp rw,
[19:27] <roaksoax> jdstrand: 1. rw to syslink, in theory not really since it hardlinks from there to /var/lib/tftpboot, but for some reason if w is not there, then it fails to hardlink
[19:27] <jussi> bdrung: thats it, Im quoting you :P
[19:27] <jussi> (re: meeting just now :P )
[19:28] <bdrung> jussi: everything else are features ;)
[19:28] <roaksoax> jdstrand: xinitd, cobbler sync fails if it cannot create that dir, as, even though we are using tftp-hpa, cobbler code still creates the dir/file
[19:29] <jussi> "senior ubuntu developer claims ubuntu is bug free, world peace is near!"
[19:29] <jdstrand> roaksoax: hrm-- the xineted stuff should ideally be ripped out of maas-provision, but for this, can you just add a comment on why it is needed
[19:29] <jdstrand> roaksoax: re syslinux> is it hardlinking the directory or various stuff under it?
[19:31] <jdstrand> roaksoax: this is also scary: /boot/memtest* rwl,
[19:31] <roaksoax> jdstrand: syslinux --> various stuff under it
[19:32] <roaksoax> jdstrand: yeah!! same as syslinux though
[19:32] <roaksoax> jdstrand: it hardlinks from /boot/memtest* to /var/lib/tftpboot/images/
[19:33] <jdstrand> roaksoax: I guess the hardlink is needed because of /var/lib/tftpboot is a chroot. is that accurate?
[19:33] <roaksoax> jdstrand: yes
[19:33] <jdstrand> man
[19:34] <jdstrand> that stinks
[19:34] <roaksoax> jdstrand: indeed
[19:35] <jdstrand> roaksoax: not to mention it completely breaks if /boot or /var are on different partitions
[19:38] <jdstrand> roaksoax: while I don't like it, I think I could live with the writes for xinetd and /usr/lib/syslinux (yuck though!), but I find the /boot bit unacceptable. that could affect the host in significant ways. can you just changes those to shutil.copy from /boot into /var/lib/tftpboot/<wherever>
[19:39] <jdstrand> roaksoax: wherever it does the hard link, just change it to a copy. I think a bug in memtest* being out of date until a cobbler sync is better than an avenue for cobbler to trojan the host
[19:39] <roaksoax> jdstrand: alright! I'll do that ;)
[19:39] <jdstrand> roaksoax: with that change and a couple of comments for syslinux and xinetd, it looks great. thank you for all your work on this :)
[19:41] <bdmurray> slangasek: what is supposed to happen when you insert a 12.04 cd into an 11.10 system?
[19:42] <slangasek> bdmurray: a running system, or booting from it?
[19:42] <bdmurray> slangasek: a running system?
[19:42] <bdmurray> er s/?//
[19:42] <slangasek> if it's an alternate CD it should give you the option to upgrade
[19:42] <roaksoax> jdstrand: awesome! will do. Thank you for the review!
[19:42] <slangasek> if it's a desktop CD, probably not much
[19:42] <jdstrand> np
[19:42] <slangasek> bdmurray: I guess a desktop CD would be presented as an apt source
[19:43] <bdmurray> a desktop cd ended up launching synaptic for me
[19:43] <bdmurray> I had forgotten about the alternate / desktop distinction
[19:43] <slangasek> hmm
[19:43] <slangasek> I'm not sure why it would launch synaptic
[19:43] <bdmurray> well it looks like this is executed
[19:43] <bdmurray>  /usr/bin/python /usr/lib/update-notifier/backend_helper.py add_cdrom /media/Ubuntu\ 11.10\ i386
[19:44] <bdmurray> anyway I didn't run into bug 946718
[19:45] <slangasek> hmm, ok
[20:44] <roaksoax> jdstrand: http://paste.ubuntu.com/943148/ http://paste.ubuntu.com/943147/
[20:50] <jdstrand> roaksoax: looks good to me :) do you need someone to sponsor it?
[20:53] <roaksoax> jdstrand: nope :) thanks though!
[20:53] <jdstrand> np :)
[21:03] <slangasek> jdstrand, roaksoax: hrm, so is this maas-provision upload to -proposed expected to make it onto the CD?
[21:05] <slangasek> mmm and why does soyuz say maas-provision is now in both universe and main?
[21:09] <ScottK> slangasek: Because it's in universe in -release and main in -proposed.
[21:09] <slangasek> ScottK: no, I'm seeing it in -release...
[21:09] <slangasek> in both in -release
[21:10] <jdstrand> slangasek: roaksoax is uploading an ubuntu4 that should be on the CD aiui. the maas-provision in precise-proposed satisifies the mir requirements, so I put it in main. ubuntu2 in the archive does not, so I left it alone
[21:10] <ScottK> Hmm. different revisions?
[21:10] <ScottK> Maybe ubuntu2 just didn't get tossed out yet?
[21:10] <jdstrand> slangasek: so, I accidentally put the one in release in main, but later fixed that
[21:10] <jdstrand> and then put the one in -proposed in main
[21:11] <slangasek> jdstrand: ah.  Did you do that within a single publishing cycle?  That may be what's confused the world
[21:11] <slangasek> ok, so we weren't actually ready to respin server because the maas-provision we care about is the one in -proposed still
[21:11] <jdstrand> slangasek: I put ubuntu2 in -release in one cycle and -ubuntu3 in -proposed to main/-ubuntu2 -release to universe in another
[21:12] <jdstrand> slangasek: re respin> correct> but note that even though ubuntu3 in prposed satisifies the mir requirement, it does not satisfy the server team's quality requirement. roaksoax's ubuntu4 will do that
[21:12] <jdstrand> slangasek: (aiui)
[21:34] <jdstrand> @pilot out
[22:42] <kklimonda> jono: hey, are you around?