[02:44]  * micahg is catching up on backscroll
[05:00] <micahg> infinity: jbicha: Laney: I'm all for keeping 1.8 in quantal as that'll make us standardized on 1.8 in the stable releases for the time being
[05:00] <micahg> but I'll leave it to the desktop team to make the call on which version they think is best suited
[05:01] <micahg> but IMHO, staying on 1.9.2 isn't an option as if there's any breakage between 1.9.2 and 1.10.0, we'd have to deal with that in a security update which I'd like to avoid
=== astraljava1 is now known as astraljava
[08:01] <Laney> micahg: the problem is it's not "keeping", it's "reverting to"
=== henrix_ is now known as henrix
[08:25] <Laney> wow
[08:25] <Laney> looks like upstream ship a patched make to get around "Argument list too long"
[08:27] <Laney> ship as in with jhbuild, not in their tarballs :P
[08:32] <xnox> Laney: is the patch written in XSLT and XPATH to better integrate with jhbuild? =)
=== doko_ is now known as doko
=== henrix is now known as henrix_
=== mmrazik is now known as mmrazik|lunch
[10:30] <Laney> iulian: you still handling bug #1046461?
[10:30] <ubot2> Launchpad bug 1046461 in shotwell "[UIFe] [FFe] UOA integration needs to support multiple accounts" [Undecided,New] https://launchpad.net/bugs/1046461
=== henrix_ is now known as henrix
[10:40] <iulian> Laney: I am, yes. I'm waiting for a successful build.
[10:40] <Laney> sounds like there's a patch?
[10:42] <iulian> That patch is not working because of http://redmine.yorba.org/issues/5803.
[10:42] <Laney> that's what I am referring to
[10:42] <Laney> the "fix" to add --enable-deprecated
[10:43] <popey> skaet, were we not having another catchup meeting today?
[10:43] <Laney> popey: this afternoon
[10:44] <iulian> Laney: Right but the patch wasn't updated.
[10:45] <iulian> I mean, the attached patch in launchpad.
[10:45] <iulian> 06_uoa.patch
[10:47] <iulian> Laney: Having said that, I'm happy with the change, I just want to make sure that the changes do what they are meant to do.
[10:47] <Laney> well, if you want, you can very easily take it yourself to test
[10:49] <iulian> jbicha volunteered to test it. He was the one who spotted the build failure.
[10:50]  * Laney shrugs
[10:50] <Laney> I am just aware of the fact that B2 freeze is tomorrow
=== mmrazik|lunch is now known as mmrazik
=== henrix is now known as henrix_
[11:04] <iulian> Okey dokey. I shall test that myself later on today if jbicha doesn't beat me to it.
=== henrix_ is now known as henrix
=== mmrazik is now known as mmrazik|otp
=== mmrazik|otp is now known as mmrazik
[13:25] <hallyn> jdstrand: hi - so re bug 1040033 how do you feel putting that into q?
[13:25] <ubot2> Launchpad bug 1040033 in qemu-kvm "Fresh VM installs via preseeded oneiric isos sometimes fail with filesystem issues" [Critical,Triaged] https://launchpad.net/bugs/1040033
[13:25] <hallyn> (i'm queesy)
[13:34] <jbicha> hallyn: is that somewhere between quantal and wheezy?
[13:35] <highvoltage> nice catch, jbicha
[13:37] <hallyn> ouch
[13:38] <skaet> popey,  Double checked the invite and you weren't there.  Inadvertant mistake on my part.  fixed now.
[13:38] <xnox> hallyn: for what it's worth there were similar reports against ubiquity when installing quantal in the vm (as part of iso testing) with files disappearing.
[13:39] <xnox> hallyn: but I don't think I paid attention to them much, e.g. tag hardware-error & 'oh it works fine now' comments
[13:39] <popey> skaet, thanks
[13:39] <jdstrand> hallyn: well, upstream has released 1.2 and we have an 1.1rc with a major known bug? I would highly consider 1.2 for maintenance reasons alone. If it passes test-qemu.py and test-libvirt.py, seems like something we should pursue
[13:40] <hallyn> jdstrand: test-qemu.py had some failures for me - but i couldn't fgure out what they meant (or repruduce by hand)
[13:40] <hallyn> while we straighten that out, do i need a bug to request FFE for jumping to 1.2?
[13:41] <hallyn> or do i just ask here?
[13:41] <jdstrand> hallyn: is it actually adding features? or is 1.2 just a collection of bug fixes over 1.1rc?
[13:43] <hallyn> jdstrand: i dunno, i counted 6k commits and assumed there was a feature in there somewhere
[13:43] <jdstrand> that's a lot of commits. I think you need a bug
[13:44] <hallyn> ok
[13:45] <hallyn> jdstrand: it adds seccomp support, actually.  feature.
[13:46] <jdstrand> hallyn: ah yes, but a good one :)
[13:54] <hallyn> jdstrand: bug 1052932
[13:54] <ubot2> Launchpad bug 1052932 in qemu-kvm "[FFE] merge upstream v1.2.0" [Critical,New] https://launchpad.net/bugs/1052932
[13:54] <hallyn> I'll set up another laptop to do some heavy manual testing...
[13:59] <jdstrand> hallyn: ack. commented in the bug
[14:31] <plars> From what I understand, some recent changes may have made it so that we can no longer support upgrade from cdrom (no-network upgrades for example)
[14:32] <plars> Can someone confirm this is true?
[14:32] <cjwatson> Yes, since we no longer publish alternate CDs containing .debs
[14:32] <cjwatson> And you can't upgrade from the desktop CD
[14:32] <cjwatson> Well, not the same way
[14:33] <plars> cjwatson: ok, thanks
[14:33] <cjwatson> You can do an "upgrade" (mad handwave) which is actually an install over the top that attempts to preserve user data and some semblance of the extra packages you had installed
[14:33] <cjwatson> But not an upgrade by packages
[14:36] <skaet> cjwatson,  any way to translate that mad handwave into some written guidance (ask ubuntu question?)   I suspect this question will come up again.
[14:36] <xnox> skaet: it's actually called Re-install while preserving user data and configs
[14:37] <xnox> "In-place"
[14:37] <xnox> it is our answer to "you should have separate /home to support reinstalls without loosing your data" when you have a single partition only.
[14:38] <skaet> plars, balloons - do we have a QA test that tries this ^ ?
[14:38] <skaet> thanks xnox
[14:38] <xnox> skaet: I think we have a bug report that 12.10 doesn't offer it for 12.04 installed on disk =/
[14:39] <skaet> xnox,  if you can find the bug number for it,  that would be good.   Definitely something we'll want to document in beta 2 Technical Overview notes as a known issue.
[14:40] <xnox> skaet: bug 1050562
[14:40] <ubot2> Launchpad bug 1050562 in ubiquity "Upgrading Ubuntu 12.04.1 from iso isn't given as an option" [High,Confirmed] https://launchpad.net/bugs/1050562
[14:40] <cjwatson> skaet: probably ought to be documented somewhere, ideally as an alternative link on http://www.ubuntu.com/download/desktop/upgrade - not sure I have time at the moment though
[14:41] <plars> skaet: indeed, I don't think we do right now, but I think we should certainly test this in place of not having cdrom upgrades
[14:42] <plars> balloons: can we add this to the isotracker, even though we know it has a problem with it right now?
[14:42] <gema> micahg: o/
[14:42] <balloons> skaet, hmm.. I'm not sure we have a specific case for it
[14:42] <balloons> plars, yes, bugs or not if we have a valid testcase we can add it
[14:43] <skaet> balloons,  can you work with plars to get one written and added?
[14:43] <balloons> skaet, plars yes, give me a couple mins to finish up meeting
[14:45] <skaet> thanks.
[14:46] <micahg> skaet: so, the issue was brought up that QA shouldn't tag stuff that isn't supported with the rls tracking tag, so, I was thinking that RC items that aren't supported still need to be tracked somehow, this was previously done with targeting/milestoning I believe (usually someone committed to fixing it though)
[14:49] <micahg> now that I think about it, while we've had milestoning in the past, Ubuntu doesn't seem to have the same type of RC bug concept that Debian does (in that a package with an RC bug can't be released as stable), I don't think we should necessarily go that far, but I think it would be nice if have a way to flag any package with an RC bug so that people interested can work on those RC bugs before the release
[14:50] <micahg> (well, actually, it would be nice to remove RC buggy packages before release, but we've have to make sure the RC bugs are validly RC)
[14:51] <skaet> micahg, https://wiki.ubuntu.com/RCBugTargetting - has the  new tagging flow incorporated.   If a bug is part of the release but not release critical,  it can be handled by targetting to as series, but putting rls-q-notfixing tag on it.
[14:51] <gema> skaet: QA cannot tag a bug as rls-q-notfixing
[14:51] <gema> skaet: what do we know if it needs to be fixed?
[14:51] <micahg> skaet: we have different levels of RC those, we have RC with a team behind it, RC on an image, RC in the archive
[14:52] <skaet> gema,  agreed QA should be using the tag rls-q-incoming.    Development should either target to series and decide if rls-q-notfixing is appropriate or not.
[14:52] <micahg> skaet: the problem is for packages without a specific team behind them
[14:53] <micahg> which inherently won't use/review the rls-* tags
[14:53] <gema> didrocks: ^^ see skaet's answer?
[14:53] <gema> didrocks: are you happy with that?
[14:54] <didrocks> skaet: in that case, don't expect me to triage rls-q-incoming for now
[14:54] <skaet> micahg,  those actually do show up in the tracking report - in the "other" section.
[14:54] <didrocks> skaet: I have more than enough work with all the PS stuff + assignement to the team
[14:54] <didrocks> doing papework to reject components on universe is silly IMHO
[14:54] <micahg> skaet: how are the packages associated with teams?
[14:54] <didrocks> like I cleaned the -incoming one yesterday evening
[14:54] <skaet> didrocks,  you sholdn't be seeing universe packages,  only desktop ones.
[14:54] <didrocks> got 16 this morning
[14:55] <didrocks> skaet: there were and that was what I raised
[14:55] <didrocks> like indicator-weather
[14:55] <skaet> hmm...   we may need to review the list then of what's going to desktop, and what shouldn't be.
[14:55] <micahg> skaet: where's this list again?
[14:56] <skaet> micahg,  its a googledoc spreadsheet.
[14:58] <gema> skaet: can we see it?
[14:58] <skaet> gema,  its pulled into the arsenal project
[14:58] <gema> skaet: dunno what that project is
[14:59] <micahg> I'd like to bring up that "other" category in the MOTU meetings, ideally we can find some volunteers to wade through the list
[15:00] <skaet> micagh,  that would be great!   :)
[15:00] <micahg> but we have to be able to see the doc :)
[15:02] <skaet> gema, micahg:  https://launchpad.net/arsenal/2.x
[15:02] <micahg> this is run locally?
[15:02]  * gema -> meeting
[15:03] <skaet> http://bazaar.launchpad.net/~bryce/arsenal/2.x/files/head:/reports/package-team-mappings.csv is a copy
[15:03] <cjwatson> I used to be able to see that doc on docs.google.com (now drive) but I don't seem to be able to find it any more
[15:03] <cjwatson> as usual google docs is a great way of losing stuff :-(
[15:03]  * skaet grumbles about drive conversion as well.
[15:03] <cjwatson> well, it wasn't great before either
[15:03] <balloons> ok plars, so this testcase in question is specific to re-using my home partition.. really it's an extension of the manual partitioning testcase
[15:04] <balloons> we don't actually track what you do when you hit 'manually' partition, so the testcase is a bit wide open. We have some ambiguity in our testcases.. this is another case of that it sounds like
[15:22] <cjwatson> hmm
[15:22] <cjwatson> so the package-team-mapping spreadsheet I can find has coq mapped to universe
[15:22] <cjwatson> why is it showing up on foundations lists?
[15:23] <cjwatson> FWIW skaet's URL above should be https://bazaar.launchpad.net/~bryce/arsenal/2.x/view/head:/reports/package-team-mapping.csv (s/mappings/mapping/)
[15:23] <cjwatson> hm, stale cache maybe?
[15:25] <micahg> also has indicator-weather in desktop
[15:34] <doko> jibel, skaet, cjwatson: unsure about 1003910. I can't reproduce this, and don't understand jelmer's comment about python3.
[15:35] <cjwatson> well, it's true enough, follow the packages.* links
[15:35] <cjwatson> perhaps a dh_python[23] problem that mis-substituted shebangs?
[15:37] <cjwatson> although it only seems to be subunit-notify that's 3.2
[15:37] <cjwatson> so maybe he misread something
[15:48] <jibel> doko, I can't reproduce it either on a fresh installation of Quantal.
[15:55] <jibel> doko, the shebang line changed from "/usr/bin/python3.2" in subunit 0.0.7+bzr162-1 to "/usr/bin/env python" in 0.0.8+bzr176-1 which fixed the problem
[15:55] <doko> jibel, ahh, ok
[16:01] <cjwatson> plars: So, bug 1050595.  The 128MB install died before partitioning so this isn't relevant - but in the 256MB log I see that you have no swap configured.  Why's that?  With low-memory install tests we should definitely ensure that some swap is present; d-i only makes any effort to conserve memory before the point when swap is brought up.
[16:01] <ubot2> Launchpad bug 1050595 in lowmem "Ubuntu Server installation with 128M ram hangs" [Undecided,New] https://launchpad.net/bugs/1050595
[16:02] <plars> cjwatson: I was testing the bare minimum requirements, which was 1G of disk and 128M ram, and had already determined that the only way 1G was possible (even with a base system) was to manually partition and use all for /. I've already referred this to the server team and jamespage is looking into it
[16:03] <cjwatson> OK, but the bug here is only about memory
[16:03] <cjwatson> The disk requirements definitely need to include provision for sufficient swap space
[16:03] <plars> cjwatson: I'll give it a try with swap also
[16:04] <cjwatson> Anyway, it won't help the 128M case, but 256M with swap should work
[16:04] <cjwatson> Since the OOMs don't start until after when swap should have been configured
[16:04] <plars> cjwatson: at the time I opened it, it was still unclear as to whether 1G should just barely fit like that, but it could be that the disk space is the bigger issue
[16:05] <cjwatson> We should expand disk before skimping on memory, certainly
[16:14] <jbicha> um, I guess Design really wants bug 1049593 approved any way
[16:14] <ubot2> Launchpad bug 1049593 in unity "[FFE][UIFE]Dash - Finesse the placement, movement and behaviour of the 12.10 Dash " [Critical,Fix committed] https://launchpad.net/bugs/1049593
[16:24] <xnox> doko: and in the mean time dh_python3 dropped shebang rewritting "bug/feature"
[16:37] <doko> xnox, thanks for the pointer
[16:38] <doko> Laney, cjwatson: could somebody look at the libjpeg-turbo FFe (new version, but almost all changes are bug fixes). I'd like to get this in before the beta.
[17:31] <infinity> doko: Did someone get to your libjpeg-turbo FFe?
[17:33] <infinity> doko: Oh, I see, it's tied up with the SRU bug.
[17:34] <infinity> doko: FFe approved.
[17:38] <iulian> Laney: I've got to do more work than I expected with shotwell so I cannot fully test it today unfortunately. Vala 0.17.6 is also needed apparently.
[17:38] <iulian> It would be nice if we could get it in before the freeze.
[17:39] <iulian> jbicha: Fancy testing shotwell with that patch applied? It builds fine with --enable-deprecated.
[17:40]  * iulian -> gone.
[17:56] <skaet> jbicha, around?
[17:57] <jbicha> skaet: yes
=== henrix is now known as henrix_
[18:13] <xnox> skaet: just filed bug 1053030 not sure if I did everything right to cause attention for the release notes.
[18:13] <ubot2> Launchpad bug 1053030 in ubiquity "highly confusing UI on desktop panda when no external storage is attached" [High,Confirmed] https://launchpad.net/bugs/1053030
[18:19] <stgraber> xnox: I guess the same would apply to any system that doesn't have some kind of storage attached?
[18:19] <xnox> stgraber: true.
[18:20] <stgraber> though it's weird that it passes the prepare step
[18:20] <stgraber> it should get stuck on the prepare step as it doesn't have enough space for installation
[18:20] <xnox> stgraber: but there is =) because it's a 8GB sd-card
[18:20] <xnox> and the first two partitions are only ~1GB
[18:20] <skaet> thanks xnox.   something's not working properly with milestoning release notes project to quantal.   Will look into it later.
[18:20] <stgraber> ah, that's the problem then ;) we shouldn't consider the install media when evaluating if there's enough space on the system
[18:21] <xnox> stgraber: apperantly not, as cjwatson pointed out there are OEM systems that install that way from USB back on to USB.
[18:22] <xnox> so we should "support it"
[18:23] <jbicha> it used to be easily possible to boot from an ISO on the hard drive (say if you had grub already installed) & use that to install to the same hard drive
[18:23] <jbicha> for the last few releases, that use case has been broken without hacking it to work
[18:24] <jbicha> I used to do that since Startup Disk Creator hasn't been very reliable in development cycles
[18:25] <stgraber> xnox: ?? surely you can't install to your install media, there's no way that'd work.
[18:26] <stgraber> I'm not saying we should blacklist all non-local devices, I'm saying we need to blacklist the device that's mounted to /cdrom as that one can't possibly be used to install the system
[18:27] <xnox> stgraber: sure you can, if it's pre-partitioned =)
[18:27] <stgraber> xnox: yes, and then the check would succeed
[18:28] <stgraber> xnox: In the case of a partitioned media, you'd only blacklist the partition on which /cdrom sits
[18:28] <xnox> stgraber: somehow it succeeds even though I don't have remaining space partitioned. And d-i locks only the /cdrom
[18:28] <xnox> but then lets me modify it anyway....
[18:29] <stgraber> I can't remember exactly what the check looks at. I know it's not looking at available partitioned space, otherwise you couldn't install on a new disk (which would be kind of bad).
[18:29] <xnox> stgraber: let me partition it correctly and see how ubiquity behaves
[18:29] <stgraber> one trick would be to take device size - size of /cdrom parittion
[18:30] <stgraber> so if the /cdrom partition takes the whole device, you would have 0 bytes left so the check would fail, but if you pre-partitioned and gave /cdrom 1GB, then you'd have enough space and ubiquity would let you continue
[18:32] <xnox> cause currently it flat out does not expect that d-i will not ask 'autopartitioning' question and start with 'manual choose partition' question. Breaks the state machine =)
[19:21] <cjwatson> stgraber,xnox: intended behaviour is that you should be able to partition anything after the installation-medium partition; it doesn't have to be pre-partitioned
[19:22] <cjwatson> I don't consider it important for it to provide autopartitioning in such a case, though - I think it would be OK for that to be manual-only
[19:22] <cjwatson> perhaps that was broken by the installer redesign in maverick, which started deriving more complex UI from the partman state machine
[19:29] <xnox> cjwatson: but surely biggest_free should be doable in this case
=== yofel_ is now known as yofel
[19:38] <ogra_> cjwatson, well, it still tries to update the partition table while the install medium is mounted and usually fails
[19:38] <ogra_> (if you try to create a partition behind the install media one)
[19:40] <xnox> ogra_: and if it fails it tells you to reboot, which is fine.
[19:41] <ogra_> fine apart from the fact that it made me first think this was a possible procedure
[19:41] <cjwatson> xnox: in principle yes; but I don't remember whether that's how it behaves, and it wouldn't be a big deal if it weren't
[19:41] <ogra_> it doesnt iirc, you get and error and apport
[19:42] <xnox> =(
[19:43] <ogra_> (try it, since you seem to have such a setup running atm)
[19:43] <xnox> can somebody please explain why is it not possible sometimes to update partition table of the install media when it is mounted?
[19:43]  * xnox  is probably missing some fundamental point here, but it's 2012 and linux kernel at 3.5, why can we still not do this ?!
[19:43] <ogra_> well, theoretically it should be ...
[19:44] <ogra_> (i know i used blockdev's rereadpt option on mounted devices in the past and that worked flawless)
[19:45] <cjwatson> ogra_: as described, that's a bug I'm not familiar with.  libparted is supposed to disregard remove/add failures when the new partition is unchanged
[19:45] <cjwatson> libparted/arch/linux.c:_disk_sync_part_table if you want to look into it
[19:46] <ogra_> well, its a while ago that i tried it last actually, i might misremember the error popping up
[19:46] <ogra_> though i think one of the balloons community army filed such a bug
[19:46] <cjwatson> ok, so do check facts first before going on a debugging expedition :)
[19:46] <ogra_> heh, indeed
[19:53] <ogra_> xnox, bug 1042930
[19:53] <ubot2> Launchpad bug 1042930 in ubiquity "partition size error during install of Quantal on Panda board" [Undecided,Confirmed] https://launchpad.net/bugs/1042930
[19:53] <stgraber> skaet: just figured out what was broken with product owners on the tracker. Next roll out will be working again with edubuntu-release being the only team setup for now
[19:54] <skaet> stgraber,  glad its figured out.  :)
[19:55] <stgraber> it was a pretty weird bug in the ACL checking, kind of surprised we didn't have other problems because of it... anyway, the fix is also making the ACL checks twice as fast (not that they were particularly slow)
[20:25] <phillw> skaet: do you have a couple of minutes?
[20:26] <skaet> phillw, am otp right now,  will ping when I get off.
[20:26] <phillw> ta
=== chrisccoulson_ is now known as chrisccoulson
[20:49] <xnox> skaet: Fedora releases alpha 18 with "redesigned installer" and a following release note "The Anaconda installer for Fedora 18 Alpha will format the entire disk unless custom partitioning is selected."
[20:49] <xnox> if only we did releases like that....
[21:11] <doko> infinity, thanks
[21:28] <jbicha> xnox: epic release note, and they pushed back the release date 3 weeks
[21:34] <skaet> jbicha,  https://wiki.ubuntu.com/DocumentationTeam/ReleaseSchedule,  do you want me to update it with the latest?
[21:47] <Laney> doko: that is for you
[22:45] <doko> however cares about nvidia packages ... https://launchpad.net/ubuntu/+source/nvidia-texture-tools/2.0.8-1+dfsg-2build1/+build/3762795
[22:45] <doko> whoever even