[07:28] <sil2100> Mirv: uh oh qt 5.4.2!
[07:28] <sil2100> Mirv: oh, and you assigned line 51?
[07:29] <Mirv> sil2100: well I thought it might be a good idea for wily, before GCC5 and Qt 5.5 and all that uncertain crazinesss...
[07:29] <sil2100> Ah!
[07:29] <Mirv> sil2100: yes, I assigned
[07:29] <sil2100> Ok, good that you assigned, I mis-read the comment actually
[07:29] <Mirv> sil2100: I mean, there are so many uncertainty factors in my mind regarding wily that I'm not 100% sure we will ship 5.5... but if we get once again bugs fixed, it can be done.
[07:30] <sil2100> Since this sync is indeed needed *before* silo 4, because they couldn't dual land it due to address-book-app differences
[07:30] <Mirv> I won't eg ship without the qml cache patch and that's unfortunately in limbo since people have so many other priorities
[07:30] <sil2100> Ah, right, ricmm is working on different things now
[07:30]  * Mirv has shiny XPS 13 in use, migrated during weekend!
[07:30] <sil2100> \o/
[07:30] <Mirv> sil2100: yes :( it was supposed to be both adapted for 5.5 and submitted upstream, now...
[07:31] <Mirv> sil2100: \o/ indeed. working screen! fast! fast fast!
[07:31] <Mirv> like 3 generations newer fast.
[07:31] <sil2100> Let's have a chat with ricmm later on, maybe we can somehow convince management to get this done
[07:31] <Mirv> even though nowadays it's not that huge as it sounds regarding CPU speed.
[07:31] <sil2100> hoo
[07:31] <sil2100> Nice!
[07:32]  * sil2100 sticks with his old laptop for now
[07:32] <Mirv> sil2100: I fired one e-mail at pat + ricardo as ricmm suggested but as I didn't get a reply (from pat) I assume it's not a priority
[07:32] <Mirv> but we can try...
[07:32] <sil2100> I have certain requirements for laptop hardware and currently there's nothing that could interest me
[07:34] <Mirv> finally the dashboard and spreadsheet do not annoy me anymore too :) because they're no longer as laggy.
[07:35] <Mirv> but they're both quite overheavy pieces
[07:35] <Mirv> requiring the latest 2015 machine to work fluently
[07:35] <Mirv> oh, I read _wily_, not wily vivid
[07:36] <Mirv> sil2100: how's the status with landing gates...
[07:36] <Mirv> argh, I need to revert that anyway since the QA field was empty
[07:36] <Mirv> train should really just abort on such case
[07:37] <Mirv> that's luckily easy as there was no earlier mediascanner2 in the overlay PPA
[07:39] <Mirv> robru: sil2100: could we perhaps switch to "dual" string in the dashboard instead of "wily vivid"? I've found myself also earlier parsing that as "oh, wily" and dual would make it explicitly "not just wily"
[07:41] <sil2100> Mirv: hm, that might be an option
[07:42] <sil2100> Mirv: the landing gates are closed *but* we wanted to open them today anyway
[07:42] <sil2100> So probably no harm ndone ;)
[07:42] <sil2100> Mirv: do not remove it from the PPA yet
[07:42] <Mirv> sil2100: yes there is, as noted above it was not QA sign-off:d
[07:42] <sil2100> Ah, ok
[07:42] <sil2100> Ouch
[07:43] <Mirv> but this is pretty easy one, I deleted it from the PPA, there was no earlier version in the PPA, wily got released. if QA signs off, just publish the vivid one again.
[07:43] <Mirv> (or copy-package if train doesn't like the fact that wily already has it)
[07:49] <sil2100> It might be a bit troublesome since PPAs don't like to re-copy the same package version
[07:49] <sil2100> Not sure how long this info stays in the PPA after a deletion
[07:49] <sil2100> Anyway, we can do a manual version bump if anyuthing
[07:55] <Mirv> sil2100: ah, darn, that's a problem indeed. it is possible to copy just-deleted same package back to the same PPA, restoring it, but I'm not sure if I've ever tried copying from another PPA later on.
[07:56] <jibel> sil2100, Hey, we'd need a new image with latest mir that landed on Friday
[07:56] <Mirv> sil2100: it's safe to say the info stays there indefinitely
[07:57] <sil2100> Mirv: as said, we can just take the package, change the version to ubuntu2 and push it manually in the worst case :)
[07:57] <sil2100> jibel: ok, let me kick a new build the
[07:57] <sil2100> *then
[07:58] <sil2100> jibel: it's building
[08:00] <jibel> sil2100, we'll probalbly need another to update translations
[08:00] <sil2100> Right, but I think translations are auto-uploaded on Tuesdays... maybe we could ask pitti to run the update job earlier though
[08:01] <sil2100> He's doing the german translations now
[08:01] <jibel> sil2100, once the missing translations are completed, which is what seb128 and pitti are doing
[08:03] <seb128> jibel, we need to find a spanish translators to validate the translations from vrruiz
[08:04] <seb128> https://translations.launchpad.net/dialer-app/trunk/+pots/dialer-app/es/+translate?show=untranslated
[08:04] <seb128> same on messaging as well
[08:05] <seb128> or seems like messaging got done
[08:05] <jibel> seb128, ok, i'll see with victor if he knows someone.
[08:06] <jibel> otherwise it'll be leo or sergio this afternoon
[08:32] <sil2100> ogra_: pong
[08:32] <ogra_> ping ?
[08:32] <ogra_> oh
[08:32] <ogra_> no harps !!!
[08:59] <sil2100> jibel: we have 1.5h for verifying the spanish translations ;p
[08:59] <jibel> sil2100, I know :)
[08:59] <jibel> sil2100, I found someone for the verification but need someone to actually approve them
[09:02] <seb128> dpm can do that I guess
[09:03] <jibel> dpm, ping
[09:05] <dpm> seb128, jibel, what's the context?
[09:06] <jibel> dpm, we need someone to approve https://translations.launchpad.net/dialer-app/trunk/+pots/dialer-app/es/+translate?show=untranslated
[09:07] <jibel> dpm, can you decide which translation is correct for the 1st sentence, fgimenez and victor have different suggestions
[09:07] <jibel> dpm, the 3 others are ook
[09:07] <jibel> -o
[09:08] <seb128> "Listo" is what got used in the messaging-app, if you change it in dialer you probably want to change messaging as well for consistency
[09:08] <seb128> https://translations.launchpad.net/messaging-app/trunk/+pots/messaging-app/es/32/+translate
[09:08] <dpm> jibel, I'm not a member of the Spanish translation team, but FWIW, Victor's suggestions are the correct ones
[09:10] <jibel> dpm, ah, maybe you should apply :) Unless you know a member we'll have to wait for victor then
[09:10] <jibel> dpm, thanks
[09:11] <dpm> jibel, moving forward, I think to avoid this, the best thing would be to send an e-mail to the translators mailing list
[09:11] <seb128> dpm, you should be able to approve them anyway no?
[09:12] <dpm> not sure I can commit to do translations for yet another theam
[09:12] <dpm> seb128, I can approve them as a Launchpad admin, but not as a team member, not sure I want to bypass the team mechanisms
[09:15] <seb128> dpm, k, I'm pondering doing it :p I don't know spanish but it's basically approving the translations that got used in the dialer-app trunk
[09:15] <seb128> it doesn't feel like approving new work
[09:15] <seb128> just copying over things done
[09:23] <sil2100> dpm: can you contact the spanish translator team admins somehow to get these translations approved? We need them ASAP since otherwise we'll miss the export and will have to ask for a manual one ;)
[09:23] <sil2100> And we cannot release OTA-4 with missing key translations
[09:25] <dpm> sil2100, in the future, could we send an e-mail to ubuntu-translators to avoid this situation? I've just come back from vacation, so apologies if that's already been done and I haven't seen it yet
[09:25] <rvr> dpm: Can you approve them? There is no one in #ubuntu-l10n-es, and I usually ping elopio por urgent  translations.
[09:26] <rvr> But elopio lives in Costa Rica, will be late if we wait for him
[09:26] <seb128> dpm, there is this proposal, which  you commented on, to have a string freeze and that includes emailing translators
[09:26] <ogra_> sil2100, seb128, dpm, sounds like a good topic to start a snappy discussion about ... "handle translations in snaps" ... once the system-image setup for images got replaced by snaps we could probably unbundle translations from the core image
[09:27] <seb128> ogra_, yeah, I guess we could do that
[09:28] <dpm> rvr, I'll approve them as a one off to unblock this situation, but I'd rather not do this in the future and bypass the team. As an aside, I myself would translate "Got it" as "De acuerdo" instead of "Listo", but I'm not familiar with the guidelines
[09:29] <rvr> dpm: I agree with you, I can suggest that translation
[09:29] <dpm> and please, even if the string freeze policy is not yet in place, an e-mail to ubuntu-translators does not take more than 2 mins to send. The Spanish team are responsive enough and generally get translations done in a matter of hours
[09:29] <rvr> dpm: Done
[09:30] <dpm> translations approved
[09:30] <rvr> dpm: Thanks
[09:35] <seb128> dpm, rvr, you probably want to change https://translations.launchpad.net/messaging-app/trunk/+pots/messaging-app/es/32/+translate as well then, for consistency
[09:35] <rvr> seb128: dpm: Done
[09:37] <rvr> seb128: dpm: Needs approval, though
[09:39] <dpm> rvr, I'd rather the Spanish team does this, as it's a discussion about nomenclature and it's not blocking any release
[09:54] <sil2100> jibel, rvr: so do we now have all the required translations in place?
[09:54]  * ogra_ wonders what happened to the image
[09:55] <sil2100> Which one?
[09:55] <ogra_> the one from 10:00
[09:55] <ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch/+build/29104
[09:55] <sil2100> ogra_: it seems to have built, not sure if the importer finished it up already
[09:56] <ogra_> well, the rootfs finished 1h ago
[09:56] <sil2100> Yeah, the importer is still running since 30 minutes
[09:56] <ogra_> ah, k
[09:56] <sil2100> At least
[09:56] <ogra_> slow thing :P
[09:56] <sil2100> Damn, this is getting really slow due to all the additions lately ;p
[09:56] <ogra_> yep
[09:57] <ogra_> more devices ... more imports
[09:57] <ogra_> by end of the year it will run 2h :P
[09:57] <sil2100> I think the 'building images doesn't cost us much' statement is less and less accurate as we're losing time ;)
[09:58] <rvr> sil2100: No untranslated items in messaging app and dialer app (trunk)
[09:58] <rvr> sil2100: So I think it's ready
[10:00] <ogra_> there it is !
[11:47]  * sil2100 prepares lunch
[12:11] <sil2100> jibel: kicking the new image
[12:11] <sil2100> As per changes e-mail, langpacks have been uploaded
[12:14] <jibel> sil2100, ok
[13:11] <kgunn> trainguards so are we thawed on vivid+ ?
[13:11] <sil2100> kgunn: hey! What do you mean?
[13:11]  * Mirv searches dictionary :D
[13:11] <kgunn> meaing can stuff land in vivid+ now?
[13:12] <kgunn> thaw!=frozen
[13:12] <Mirv> non-freeze, ah
[13:12] <sil2100> We're opening the landing gates basically in a minute, just finished lunch - we had to re-roll an image with the new mir and translations
[13:12] <kgunn> \o/
[13:12] <sil2100> kgunn: but QA already looked into your silos not to waste time :)
[13:12] <sil2100> Not sure if they were able to validate silo 8 or not, but that was the plan
[13:12] <sil2100> So that once we're open, stuff can land
[13:12] <kgunn> oh man...dreams do come true
[13:13] <sil2100> We'll still have to rebuild silo 4 then ;/
[13:13] <sil2100> jibel: do you know if you guys checked out silo 8 already?
[13:14] <sil2100> jibel: I think now that the rootfs is basically done, well, I suppose we could open the gates, right? Any objections?
[13:14] <jibel> sil2100, is it ready for QA?
[13:14] <jibel> if it is then someone mark it so and we'll start
[13:14] <sil2100> Uh, no, not sure if there was anyone around to take care of it, I thought you guys wanted to start once it built anyway
[13:16] <sil2100> Nevermind then
[13:16] <sil2100> Let me open the gates
[14:01]  * sil2100 sighs
[14:01] <sil2100> So much rewriting
[14:01] <sil2100> mzanetti: ping! Could you test silo 8 and mark it as ready for testing?
[14:18] <jibel> rvr, image 27 is out, can you confirm that translations are fine?
[14:20] <sil2100> If it's fine, I'll copy it to the RC channel
[14:21] <sil2100> Will wait for your confirmation
[14:36] <rvr> jibel: Flashing
[15:03] <kenvandine> davmor2, you moved silo 45 to testing passed but didn't mark the spreadsheet, intentional?
[15:09] <rvr> sil2100: jibel: Wizard appear in English
[15:09] <sil2100> ?
[15:09] <rvr> sil2100: jibel: In /usr/share/locale-langpack/es/LC_MESSAGES/messaging-app.mo I don't see any "Got it" or "Swipe to reveal actions"
[15:11] <rvr> language-pack-touch-es 1:15.04+20150608
[15:11] <sil2100> Something went wrong then
[15:12] <sil2100> My knowledge of translations is a bit too small... we'll probably have to poke pitti about those
[15:14] <bfiller> sil2100, pmcgowan: need a silo for line 54 to fix https://bugs.launchpad.net/barajas/+bug/1462416
[15:14] <rvr> sil2100: Talking to him
[15:14] <sil2100> bfiller: looking
[15:19] <seb128> sil2100, rvr, why is that discussion with pitti not happening there or a channel where others can participate?
[15:19] <seb128> sil2100, rvr, anyway, you are probably going to come to the same conclusion but the issue is
[15:19] <seb128> https://launchpadlibrarian.net/208568312/language-pack-touch-es_1%3A15.04%2B20150601_1%3A15.04%2B20150608.diff.gz
[15:19] <rvr> seb128: I didn't find pitti here
[15:19] <seb128> +"X-Launchpad-Export-Date: 2015-06-08 11:12+0000\n"
[15:19] <seb128> hum
[15:19] <seb128> oh, +0
[15:19] <seb128> that was after you approved the translations?
[15:20] <seb128> rvr, I guess those langpacks are built from the vivid translations set
[15:20] <seb128> e.g https://translations.launchpad.net/ubuntu/vivid/+source/dialer-app
[15:20] <rvr> seb128: Yes
[15:20] <seb128> not from wily/trunk
[15:20] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/vivid/20150608.1.changes
[15:21] <seb128> well, vivid doesn't have those strings
[15:21] <ogra_> FYI
[15:21] <rvr> Hi pitti
[15:21] <seb128> ogra_, yeah, it's just that the langpacks come from vivid serie
[15:21] <pitti> hello
[15:21] <ogra_> (thats the most recent image)
[15:21] <seb128> I think
[15:21] <rvr> <seb128> rvr, I guess those langpacks are built from the vivid translations set
[15:21] <rvr> pitti: ^
[15:21] <rvr> :)
[15:21] <seb128> and the new strings are in trunk/wily only
[15:21] <ogra_> ah
[15:21] <pitti> ah, I just pinged about that in #ubuntu-touch
[15:21] <ogra_> wily ... the source of all evil :P
[15:22] <seb128> pitti, ah, -touch works for me as well
[15:22] <pitti> pitti | sil2100: our overlay PPA doesn't have any support for translations/message sharing
[15:22] <seb128> or here
[15:22] <pitti> pitti | as it's neither vivid nor wily
[15:22] <pitti> pitti | so while e. g. trunk has a new message "Got it": https://translations.launchpad.net/dialer-app/trunk/+pots/dialer-app/es/+translate?search=Got
[15:22] <pitti> pitti | the same message isn't in https://translations.launchpad.net/ubuntu/vivid/+source/dialer-app/+pots/dialer-app/es/+translate?search=Got
[15:22] <pitti> Launchpad translations only supports distros, not PPAs
[15:22] <pitti> so while we had translation support for RTM, we don't for a "random PPA"
[15:23] <seb128> pitti, any idea how to workaround that?
[15:23] <seb128> yeah, RTM was a distro
[15:23] <pitti> not really
[15:23] <seb128> pmcgowan, ^ more fun
[15:23] <pitti> we can crowbar the wily translations into the overlay
[15:23] <pitti> but that would break again if wily has packages/versions which aren't in the overlay PPA
[15:23] <seb128> well, that's assuming that wily and vivid+overlay branches don't diverge
[15:23] <seb128> which you can't assume
[15:23] <pitti> exactly
[15:23] <pitti> the overlay PPA is neither wily nor vivid
[15:24] <seb128> ogra_, see, that's for that sort of reason that I think that we should keep wily and vivid+overlay sources in sync
[15:24] <ogra_> pitti, it is amphibian ;)
[15:25] <ogra_> seb128, yeah, i thought thats what the double landing does
[15:25] <seb128> ogra_, well, double landing is an option, not an enforced rules
[15:25] <seb128> so nothing block $randomcomponent to diverge
[15:25] <ogra_> make it a rule then ?
[15:25] <sil2100> I think this wasn't considered during the decision-making
[15:25] <ogra_> not sure that works either
[15:26] <sil2100> ogra_: well, that wouldn't work, as wily can have different strings as it can have development features
[15:26] <sil2100> So even though we enforce anything that's in vivid-overlay to be in wily, we can't do the same other way around...
[15:26] <ogra_> yeah, feared that
[15:27] <pmcgowan> sil2100, pitti so how do we update the translation in the PPA?
[15:27] <sil2100> pitti: we'll probably have to poke the launchpad team about that
[15:27] <sil2100> They would know if they can make a quick workaround for us
[15:27] <pitti> seb128: erk, it's not enforced?
[15:27] <sil2100> Since the milk has been spilled, not much we can do - but I'm feeling more and more that the PPA idea wasn't so nice in the end
[15:27] <pitti> we fell into that trap once already
[15:28] <sil2100> pitti: it's enforced only in one direction, not the other
[15:28] <pitti> not sure that there's a quick workaround -- the PPA doesn't build translation tarballs, they don't get imported anywhere, so we don't have correct PO templates for the PPA anywher
[15:28] <pitti> e
[15:28] <sil2100> pitti: since the reason we have the overlay and wily is that wily can be for development, non-stable work as well
[15:29] <pmcgowan> sil2100, does this mean we have not gotten translations since making the PPA? I am confused
[15:29] <ogra_> pmcgowan, we only got vivid translations
[15:29] <pitti> pmcgowan: correct
[15:29] <ogra_> pmcgowan, which didnt actually change since release
[15:29] <sil2100> pmcgowan: it seems we didn't get any updated ones, but only now it seems to have been made visible
[15:29] <pitti> well, we did get updates
[15:30] <pitti> but only for strings that are already in vivid
[15:30] <sil2100> Right
[15:30] <pitti> which hid the fact that there weren't new strings
[15:30] <pmcgowan> I see
[15:30] <pmcgowan> dang
[15:31] <sil2100> Things are getting better and better
[15:31] <pmcgowan> sil2100, pitti can we for now just get the wily version and push it in?
[15:31] <ogra_> the proper solution is obviously PPA support in the langpack importer ...
[15:31] <ogra_> but that might take quite some effort
[15:31] <pitti> or moving the PPA into RTM/15.04 or something such
[15:31] <sil2100> pitti: ^ ? What do you think? The strings in wily and overlay should be the same right now
[15:32] <ogra_> sil2100, are you sure ?
[15:32] <pitti> sil2100: didn't you say that wily could have newer versions than the overlay?
[15:32] <pitti> if these dropped any string, we lose those
[15:32] <sil2100> pitti: it *can*, but not sure if it does
[15:32] <ogra_> yeah, i'd be careful with such claims
[15:32] <pitti> (or "changed", which is the same basically)
[15:32] <sil2100> pitti: I'm just saying it would be better than what we have right now anyway
[15:32] <pitti> and we know how often we did pointless changes in strings :)
[15:32] <pitti> so, the crux is, we don't have *.pot files for the overlay
[15:33] <seb128> pmcgowan, sil2100, pitti, I would be careful to use the wily one, for what we know some strings might just have been modified and the vivid-overlay version droped from wily that would regress the vivid users translations
[15:33] <pitti> if we do, the packs can be pieced together (in principle) from the vivid and wily translations, assuming that everything that's in the PPA is in either vivid or wily
[15:33] <pitti> if the PPA has a newer version than in wily, we lose
[15:34] <sil2100> slangasek: ping
[15:34] <sil2100> pitti: I'm starting to consider the idea of using an ubuntu-rtm series instead of the overlay
[15:34] <pitti> sil2100: oh -- we actually did generate translation tarballs, e. g. in https://launchpadlibrarian.net/205869413/buildlog_ubuntu-vivid-amd64.dialer-app_0.1%2B15.04.20150507.1-0ubuntu1_BUILDING.txt.gz
[15:35] <pitti> but they didn't get imported anywhere
[15:35] <pitti> so we'd need to iterate over all builds, find the _translations.tar in the librarian, download all of them, download vivid+wily+trunk translations, and do a big msgmerge over them
[15:36] <pitti> i. e. the whole thing that LP usually does
[15:36] <sil2100> pitti: since we already got bit many times by some of the PPA short-comings which we had to work-around, like bug-autoclosing, lack of proposed migration, lack of changes-emails
[15:36] <pitti> sil2100: yeah, TBH I was quite surprised that we moved back to a PPA once we spent months making ubuntu-rtm actually work
[15:36] <sil2100> I'd like slangasek joining this discussion, maybe he'll have some ideas
[15:36] <pitti> is ubuntu-rtm worse than a PPA?
[15:37] <seb128> sil2100, the rtm distro seemed to work fine to me, why did we decide on a ppa instead?
[15:37] <pitti> it's certainly a lot more duplication as ubuntu-rtm has to be a complete distro
[15:37] <pitti> as opposed to just an overlay
[15:37] <pitti> that might have been a key reason
[15:37] <seb128> well, that was a bootstrap issue
[15:37] <seb128> copy enough to get it to work
[15:37] <seb128> then it was similar to the overlay
[15:37] <seb128> just upload what is needed
[15:37] <sil2100> seb128: I wasn't on the final meeting where the decision has been made, I guess one of the arguments was that with the overlay PPA we're actually basing on top of a released series and can get updates/security from them
[15:38] <pmcgowan> we avoided the distro in order to make use of security and udates
[15:38] <pmcgowan> sil2100, yeah that
[15:38] <seb128> we could easily auto pocket those to another distro no?
[15:38] <sil2100> It's a solid reason to be fair, but I don't think it's important enough to cope with so many issues
[15:38] <ogra_> pitti, ubuntu-rtm means a super limited archive
[15:39] <seb128> having a cron copy would be less work that all the workaround you have for -changes/translations/etc
[15:39] <sil2100> I proposed making a script that would report every change happening in vivid-updates and propose a sync
[15:39] <pitti> ogra_: sure, just the expansion of build/binary deps of ubuntu-touch, so it's muuuch smaller
[15:39] <ogra_> pitti, it isnt a whole archive mirror, only the seed subset
[15:39] <pitti> ogra_: I was just trying to come up with reasons why rtm is worse than PPA
[15:39] <ogra_> well, this is one :)
[15:39] <sil2100> Yeah, but I think we shouldn't put LP resources as a priority here
[15:40] <pitti> right, duplication and re-using of -security/-updates
[15:40] <ogra_> the other is SRUs and security
[15:40] <pitti> but the latter can just be copied
[15:40] <pitti> I think conceptually an entire new distro is too much (requires too much duplication of packages, cron jobs, building, testing, etc.)
[15:40] <pitti> and a PPA is too little (no translation/bug closing/bug tracking. etc.)
[15:41] <ogra_> one big advantage of RTM is that publisher runs only take a fraction of the time they take with the full archive
[15:41] <pitti> conceptually the right thign would be a distro release
[15:41] <ogra_> so the turnaround time for a package is significantly fster
[15:41] <pitti> but that doesn't work well with wily and vivid+touch being open in parallel
[15:41] <pitti> ogra_: that's the same for a PPA, though?
[15:42] <ogra_> not sure
[15:42]  * ogra_ moved to snappy before having to wait for PPA packages to land on the phone :)
[15:42] <oSoMoN> trainguards: hey ho, can I have a silo for line 55 please?
[15:42] <pitti> anyway, coming back to the translation thing: it seems we have most of the data (except for things where the overlay went ahead of wily), but implementing all this piecing together sounds like two days work or so
[15:43] <sil2100> Yeah
[15:43] <sil2100> oSoMoN: on it in a minute
[15:43] <pitti> packages in overlay which are newer than in wily need to be landed in wily, so that we get their translations *somewhere* in ubuntu
[15:43] <sil2100> pitti, ogra_: in Austin I got convinced to the PPA idea, but now I'm not convinced anymore
[15:44] <sil2100> Since it feels like we're just duct-taping more and more things
[15:44] <sil2100> The worst thing is that for now, like this instant, we don't have a solution that we could just use
[15:44] <ogra_> a little late now though :)
[15:45] <pitti> sil2100: couldn't we open rtm/15.04, copy the touch parts of vivid into it, and then copy the PPA contents into it?
[15:45] <sil2100> Switching to ubuntu-rtm does require rather a lot of work from both the landing team, LP team and archive admins
[15:45] <pitti> ah, ok
[15:46] <sil2100> pitti: we could, but then it would mean we need to modify the CI Train again to not use the overlay, there's also some fun with versioning that we'd have to implement etc.
[15:46] <sil2100> The archive parts seem the easiest ;p
[15:46] <pitti> do we have auto-committing of LP translations into trunks?
[15:46] <pitti> i. e. does everythign that gets translated in LP get into lp:project?
[15:47] <sil2100> It was working fine in the past, so I think yes
[15:47] <pitti> if so, then another option (not necessarily the best, but for completeness) would be to rebuild all ppa packages without pkgbinarymangler
[15:47] <pitti> we'd lose the possibility to update translations through langpacks, but it seems we didn't have that for new strings in the first place
[15:48] <pitti> (technically: upload pkgbinarymangler to the PPA which disables pkgstriptranslations and do no-change rebuilds)
[15:48] <sil2100> uhh, hm
[15:48] <sil2100> Personally I would prefer to avoid that ;)
[15:49] <pitti> so the process for updating a translation would then be to do that in LP, and land the project
[15:49] <pitti> (no cron or automated updats)
[15:49] <pitti> sil2100: yeah, I was just bringing it up to get all options on the table
[15:49] <sil2100> pitti: I guess we could do that as a last resort, but I would rather prefer doing all the troublesome work and migrate to ubuntu-rtm instead ;p
[15:51] <seb128> sil2100, pitti, if the only issue for that ota is those 4 new strings in messaging/dialer, we can probably manually patch the langpacks in the overlay ppa for the languages we care about as a workaround
[15:52] <seb128> not a solution, but to unblock the ota update
[15:52] <cjwatson> seb128: rtm had some pretty serious lurking problems, notably some terrible issues with version conflicts with Ubuntu
[15:52] <pitti> seb128: ... and disable the auto-update cronjob
[15:53] <sil2100> seb128: hm, ok, that makes sense, I don't know enough about translations to have considered that as an option, but if that could be done then great
[15:53] <cjwatson> but the translations problem is an issue too, and hard to fix with a PPA; I admit I don't think we considered this
[15:53] <sil2100> Since a short-term solution is what we need right now
[15:53] <sil2100> The long-term one will have to be discussed and decided
[15:53] <ogra_> sigh
[15:53] <pitti> hm, given how liberal we've been with string changes in the past, did we really only add these 4?
[15:54] <ogra_> my krillin is not happy at all with the last image
[15:54] <pitti> (in the overlay PPA)
[15:54] <ogra_> apparmor kicks in ... not sure why
[15:54] <ogra_> (given only langpacks changed)
[15:54] <sil2100> pitti: those were at least the only ones that QA saw, but I'm pretty sure they don't test all core apps for translations...
[15:54] <sil2100> ogra_: uh
[15:54] <rvr> ogra_: What do you mean?
[15:54] <ogra_> ah, but not the full 15min
[15:55] <cjwatson> can this wait until we get a chance to talk about it in the next LP team meeting tomorrow?
[15:55] <ogra_> rvr, the boot after upgrade took long
[15:55] <rvr> ogra_: Ah, ok
[15:55] <sil2100> cjwatson: I'm pretty sure it can, we can't decide on something that big in just an hour anyway :)
[15:55] <ogra_> rvr, usually that means apparmor rules get upgraded ... my switch from RTM to OTA4 on the weekend got me a 25min boot
[15:55] <sil2100> I mean, at least the long-term solution
[15:56] <sil2100> Since we'd probably like to fix the translations short-term as soon as possible
[15:56] <sil2100> pitti: could you anyway disable the auto-updater cronjob for overlay? I guess it won't be needed for now
[15:56] <cjwatson> Bringing up ubuntu-rtm/15.04 can't really be a very short-term thing
[15:56] <ogra_> rvr, and there is not much we can do ... on this upgrade people will have to get their apparmor rules for all apps they installed themselves regenerated ...
[15:56] <ogra_> rvr, that will cause really long boots after the upgrade
[15:57] <pitti> sil2100: as you wish; note that it still updates untranslated strings which were already in vivid
[15:57] <ogra_> pmcgowan, ^^^ we need to mention that in the release announcement for OTA4
[15:57] <sil2100> cjwatson: no no, I don't consider ubuntu-rtm/15.04 as the short-term solution, that's like the long-term one
[15:57] <pitti> sil2100: but if you want to go with the "hand-patch these four strings" route for now, we should disable it indeed
[15:57] <pitti> sil2100: just confirming that this is what you want
[15:57] <cjwatson> sil2100: phew
[15:57] <ogra_> pmcgowan, if you installed 100 apps from the store the first boot after upgrade will take quite a while
[15:57] <ogra_> when going to OTA4
[15:57] <sil2100> pitti: yeah... that's what I think of right now - we already fetched the latest vivid strings today anyway
[15:58] <cjwatson> ogra_: just like Android updates then :)
[15:58] <ogra_> cjwatson, well, no UI feedback
[15:58] <cjwatson> ah well yes
[15:58] <ogra_> but yeah, beyond that pretty similar :)
[15:58] <pitti> sil2100: disabled
[15:58] <sil2100> pitti: thanks
[15:58] <pmcgowan> ogra_, is that due to apparmor running?
[15:58] <ogra_> pmcgowan, yes
[15:58] <seb128> sil2100, pitti: I can handle the patching, but that's probably going to be for tomorrow now
[15:59] <seb128> need to go in less than an hour and still working on something
[15:59] <pitti> yeah, same here :/
[15:59] <pitti> but then again, this is not rocket science -- get the source package, patch the .po files, reupload
[15:59] <ogra_> pmcgowan, we can only pre-generate for preinstalled packages ... due to the fact that there is a new kernel *and* new apparmor all manually installed clicks will have to re-generate
[15:59] <sil2100> seb128: ok, no worries, thanks - I'll check on it briefly myself but I suppose tomorrow sounds fine
[15:59] <sil2100> Indeed
[15:59] <ogra_> pmcgowan, if you have really many clicks installed that takes quite a while
[16:00] <sil2100> I suppose patching the most important languages makes the most sense in this case
[16:00] <seb128> sil2100, right, pmcgowan gave a list on the bug, but I would do at least es/de/fr
[16:00] <sil2100> I wonder if we have good chinese translations as well
[16:01] <seb128> is the bq sold at all in china?
[16:01] <pmcgowan> chinese less imortant for now, will be soon though
[16:01] <seb128> right
[16:01] <pmcgowan> it is sold there but as a developer thing
[16:01] <pmcgowan> so english supposed to be ok
[16:01] <seb128> right, and it's only a few strings in a tutorial
[16:02] <seb128> devs should be able to get over it
[16:05] <bfiller> sil2100: need a reconfigure on silo 8 please, removed one package to sync and added an MR in it's place
[16:11] <pmcgowan> sil2100, who else can do that patch today if seb128  is not able to get to it
[16:17] <sil2100> bfiller: will do that in a moment
[16:17] <sil2100> pmcgowan: I can try doing it after the meeting
[16:17] <bfiller> sil2100: thanks
[16:21] <sil2100> bfiller: reconfigured
[16:22] <bfiller> sil2100: ty
[16:23] <davmor2> kenvandine: sorry just had to have our bird put down, yeah were not landing stuff till gates are open ie ota 4 is out of the door
[16:24] <davmor2> kenvandine: I'm going to check what more we need to do now but I had to rush off
[16:24] <bfiller> sil2100: getting this error https://ci-train.ubuntu.com/job/ubuntu-landing-008-1-build/230/console
[16:24] <bfiller> sil2100: maybe address-book needs to be deleted from the silo first?
[16:25] <sil2100> bfiller: hmm, no, it doesn't seem to be related... I think what happened is that you're trying to release a vivid package from a trunk that's wily based
[16:25] <kenvandine> davmor2, no worries, just checking on it
[16:25] <sil2100> So, it seems the MR you created was against the main devel trunk from which you were releasing wily packages
[16:26] <sil2100> bfiller: you would need to branch it off to another trunk
[16:26] <bfiller> sil2100: want it to be off main trunk
[16:27] <bfiller> sil2100: want wily and vivid to be in sync, both with trunk + this MR
[16:27] <kenvandine> bfiller, trunk has 15.10 version numbers though
[16:27] <sil2100> https://wiki.ubuntu.com/citrain/LandingProcess#My_project_had_only_stable_features_but_now_it_will_diverge <- this seems to be the case here
[16:27] <sil2100> bfiller: give me a moment
[16:28] <kenvandine> imo if we aren't diverging, we should be landing with 15.04 version numbers
[16:28] <kenvandine> but too late now
[16:32] <rvr> rsalveti: ping
[16:32] <rsalveti> rvr: pong
[16:32] <rvr> rsalveti: Hey. I'm trying to test silo 3, lxc config
[16:33] <rvr> rsalveti: After installing the package using adb shell in recovery, I still see an apparmor denial to Cut the Rope
[16:33] <rvr> rsalveti: How can check that the config was correctly installed?
[16:33] <rsalveti> rvr: which one are you getting?
[16:34] <rvr> rsalveti: proc/ged
[16:34] <ogra_> i thought jdstrand uploaded a fix for that
[16:35] <rsalveti> the fix is in lxc-android-config
[16:35] <rsalveti> for arale
[16:36] <rvr> rsalveti: Jun  8 16:34:50 ubuntu-phablet kernel: [ 9063.511382] type=1400 audit(1433781290.430:170): apparmor="DENIED" operation="open" profile="com.zeptolab.cuttherope.free_cuttherope_0.5.3" name="/proc/ged" pid=7678 comm="qmlscene" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0
[16:36] <rsalveti> http://paste.ubuntu.com/11651958/
[16:36] <rsalveti> rvr: is this on arale?
[16:36] <rvr> rsalveti: So I'm trying to verify whether the config was correctly installed or not
[16:36] <rvr> rsalveti: Of course
[16:36] <rsalveti> also, can you check if you have the package installed?
[16:36] <rsalveti> cat /usr/share/apparmor/hardware/graphics.d/apparmor-easyprof-ubuntu_k95v2 should tell you that
[16:37] <rvr> /proc/mtk_mira r,
[16:37] <rvr>   /proc/ged r,
[16:37] <davmor2> kenvandine: there you go marked now that I know too :)
[16:37] <kenvandine> davmor2, cool, thx
[16:38] <rsalveti> hm, wonder if the cache was generated again
[16:38] <rsalveti> rvr: did you reboot after installing it?
[16:38] <rvr> rsalveti: I had too, I was in recovery mode. Let me reboot again.
[16:39] <ogra_> phablet@ubuntu-phablet:~$ grep /proc/ged /var/log/syslog
[16:39] <ogra_> phablet@ubuntu-phablet:~$
[16:39] <ogra_> my arale seems fine
[16:39] <rsalveti> ogra_: this is only with cuttherope
[16:39] <ogra_> oh ? how can that be
[16:39] <ogra_> if access to /proc/ged is allowed systemwide
[16:40] <ogra_> aha !
[16:40] <ogra_> i just had not any apps started since last boot :P
[16:40] <ogra_> phablet@ubuntu-phablet:~$ grep /proc/ged /var/log/syslog
[16:40] <ogra_> Jun  8 18:40:10 ubuntu-phablet kernel: [ 2831.794509] type=1400 audit(1433781610.610:289): apparmor="DENIED" operation="open" profile="google-plus.ogra_google-plus_0.2.1" name="/proc/ged" pid=8714 comm="qmlscene" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0
[16:42] <rvr> rsalveti: Jun  8 16:41:59 ubuntu-phablet kernel: [  170.538965] type=1400 audit(1433781719.710:162): apparmor="DENIED" operation="open" profile="com.zeptolab.cuttherope.free_cuttherope_0.5.3" name="/proc/ged" pid=4327 comm="qmlscene" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0
[16:43] <rvr> rsalveti: After reboot :-/
[16:43] <ogra_> rvr, start some other (web)app
[16:43] <rsalveti> unless something else broke, let me check with mine
[16:43] <ogra_> phablet@ubuntu-phablet:~$ grep ged /usr/share/apparmor/hardware/graphics.d/apparmor-easyprof-ubuntu_k95v2
[16:43] <ogra_> phablet@ubuntu-phablet:~$
[16:43] <ogra_> not even in my file here
[16:44] <rvr> Jun  8 16:43:47 ubuntu-phablet kernel: [  278.749758] type=1400 audit(1433781827.920:168): apparmor="DENIED" operation="open" profile="com.ubuntu.developer.webapps.webapp-amazon-int_webapp-amazon_1.0.10" name="/proc/ged" pid=4583 comm="webapp-containe" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0
[16:44] <ogra_> rvr, right
[16:44] <ogra_> it isnt app sepcific
[16:44] <ogra_> *specific
[16:46] <rsalveti> ogra_: right, the fix is in silo 3
[16:46] <rsalveti> which is what rvr is trying to validate
[16:46] <rvr> Exactly
[16:47] <rvr> ii  lxc-android-config     0.225            all
[16:47] <ogra_> rsalveti, ah, well, i guess he needs to manually re-gen the rules then
[16:47] <rsalveti> yeah, wonder why that not happened
[16:47] <sil2100> ATTENTION! Please don't publish anything to the overlay PPA temporarily!
[16:47] <rsalveti> was able to reproduce it here, let me remove my cache
[16:49] <sil2100> bfiller: ok, I'm back for your service - so, basically, you want to release that one MR to both vivid and wily, yes?
[16:49] <rsalveti> Jun  8 13:49:29 ubuntu-phablet kernel: [   57.317567] type=1400 audit(1433782169.518:187): apparmor="DENIED" operation="open" profile="com.zeptolab.cuttherope.free_cuttherope_0.5.3" name="/proc/ged" pid=3658 comm="qmlscene" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0
[16:49] <rsalveti> hm, even after a cache rebuild
[16:50] <rsalveti> wonder if this is because it's coming from custom
[16:50] <rsalveti> jdstrand: might need your help here
[16:50] <ogra_> rsalveti, the writability of /proc/ged isnt comiong from custom
[16:50] <ogra_> it should just allow access system wide
[16:50] <rsalveti> cuttherope and possible the cache for it, is coming from custom right?
[16:51] <ogra_> sure, but cuttheope should have any rules for /proc/ged
[16:51] <ogra_> and should just inherit from the device rule which should allow systemwide access
[16:51] <sil2100> robru, kenvandine, Mirv: please don't land anything to overlay for now
[16:51] <rsalveti> sure, but I mean, if the cache is newer than the file, it will not be updated
[16:51] <rsalveti> and the denial will still happen
[16:51] <kenvandine> sil2100, ok... did i screw something up?
[16:51] <kenvandine> sil2100, or closing landing gates again?
[16:52] <rsalveti> man, it's super fast to update the apparmor cache on arale
[16:52] <ogra_> rsalveti, didnt you just say you manually regenerated the cache ?
[16:52] <rsalveti> ogra_: yup, but just for the system/rootfs
[16:52] <sil2100> kenvandine: well, no, we need to close them for a moment since we need to do a snapshot of the overlay, seems like the overlay wasn't snapshotted
[16:52] <rsalveti> I just remembered we also have the same for custom
[16:52] <kenvandine> sil2100, ok, i just published that security fix :/
[16:52] <sil2100> kenvandine: so we need the archive to have the exact same state as the last image - the content-hub upload was bad timing, but well, you didn't know so no harm done ;p
[16:53]  * ogra_ thinks this is likely pointless to test out of context of an image build
[16:53] <sil2100> We can live with that additional fix I suppose
[16:53] <rsalveti> rvr: ogra_: yeah, that's it
[16:53] <ogra_> rsalveti, so if built into the image it should "theoretically" just work :)
[16:53] <kenvandine> sil2100, it's safe... and fixes a cve :)
[16:53] <rsalveti> after rebuilding custom
[16:53] <ogra_> well
[16:54] <ogra_> bumping the build id
[16:54] <rsalveti> rvr: sudo rm -rf /custom/cache/apparmor/* /var/cache/apparmor/*
[16:54] <rsalveti> rvr: then reboot
[16:54] <ogra_> you dont even need to rebuild it
[16:54] <ogra_> just making sure the id is bumped so the image build will pick it up, no ?
[16:56] <rvr> rsalveti: Checking
[17:01] <seb128> hum
[17:01] <seb128> kenvandine, do you know if issues from https://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-wily-armhf/79/console are know by ci?
[17:01] <seb128> "/tmp/hooks/A20bump_version_autopilot: line 18: dch: command not found"
[17:01] <seb128> cihelp ^
[17:01] <seb128> that's the CI output on https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/wifi_activate_on_click/+merge/261425
[17:03] <kenvandine> seb128, that doesn't look good
[17:03] <seb128> indeed not...
[17:03] <kenvandine> CI was working for wily branches friday
[17:04] <rvr> rsalveti: Gone after removing that
[17:04] <rsalveti> rvr: great
[17:04] <rvr> Even with amazon
[17:05] <rvr> rsalveti: Does it mean the silo is good?
[17:05] <rsalveti> so once we upload it, someone will need to regenerate the custom tarball to include the new cached files
[17:05] <rsalveti> rvr: yes
[17:18] <boiko> sil2100: hi, I will change the target of silo 6 (row 28) to be wily. Is it mandatory that QA verifies landings on wily, or is it optional?
[17:19] <rvr> sil2100: silo 3 looks good, let me know when it is a good time to approve it
[17:33] <boiko> robru:  hi, I will change the target of silo 6 (row 28) to be wily. Is it mandatory that QA verifies landings on wily, or is it optional?
[17:34] <robru> boiko: qa only necessary for vivid currently
[17:35] <boiko> robru: ok, I changed the silo target to wily, would you mind reassigning/updating it?
[17:36] <robru> boiko: sure
[17:37] <sil2100> rvr: not yet, give us some time still
[17:37] <jgdx> cihelp: halp, there's something wrong with the ubuntu-system-settings ci. "dch: command not found" https://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-wily-armhf/79/console
[17:37] <jgdx> kenvandine, ^^
[17:38] <psivaa> jgdx: taking a look
[17:38] <jgdx> psivaa, thanks!
[17:38] <kenvandine> jgdx: yeah, seb128 asked cihelp about that earlier
[17:38] <kenvandine> psivaa, thx!
[17:38] <jgdx> kenvandine, you know what happened with that inquiry? (lack of a better word)
[17:39] <kenvandine> none
[17:39] <kenvandine> so glad psivaa responded this time :)
[17:39] <sil2100> robru: hey, do you know if slangasek will be around today?
[17:39] <boiko> robru: thanks a lot!
[17:40] <robru> boiko: you're welcome
[17:40] <robru> sil2100: haven't heard anything
[17:41] <slangasek> sil2100: hi there
[18:05] <sil2100> slangasek, robru: no meeting today? Not that I'm not busy with firefighting ;)
[18:05] <bfiller> sil2100: yes that's right
[18:05] <robru> sil2100: oh I forgot.
[18:05] <slangasek> sil2100: oh, it is that time, isn't it
[18:05] <sil2100> I'm the only one there :)
[18:35] <sil2100> cjwatson, slangasek: I'm copying the binaries from overlay to the snapshot PPA now, so far so good
[18:35] <sil2100> Will take a while though
[19:15] <sil2100> seb128, pmcgowan: ok, I'm way past my EOD now so I just want to finish up and go rest up a bit - the snapshotting took some time... but I checked the langpack things and it seems fairly easy to do, I'll fix that up tomorrow
[19:15] <sil2100> robru, Mirv, kenvandine: I copied the packages to the snapshot PPA, you can land things to the overlay PPA again
[19:15] <robru> sil2100: thanks!
[19:22] <sil2100> o/
[19:26] <boiko> cjwatson: hi, would it be possible to trigger a rebuild of this failed build: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-006/+build/7521819
[19:27] <boiko> cjwatson: I would prefer that over rebuilding everything just because of one flaky test
[19:28] <boiko> robru: maybe you have permissions to do that too ^
[19:32] <robru> boiko: cjwatson: on it
[19:34] <boiko> robru: thanks!
[19:36] <robru> boiko: you're welcome
[19:36] <tedg> trainguards, can I get a wily silo for line 57 please?
[19:45] <robru> tedg: got you 36
[19:45] <tedg> robru, Great, thanks!
[19:46] <robru> tedg: you're welcome
[20:17] <jgdx> psivaa, any luck?
[20:19] <psivaa> jgdx: was being looked at by fginther
[20:19] <psivaa> i couldn't figure out what that was due to
[20:19] <psivaa> let me check
[20:20] <psivaa> jgdx: that should be fixed now, let me try the job
[20:23] <jgdx> psivaa, nice. Do you know what was up?
[20:23] <jgdx> Can I re-start all failed jobs?
[20:23] <psivaa> jgdx: the slave nodes were missing 'devscripts'
[20:23] <fginther> jgdx, psivaa, I think I already restarted all of the impacted jobs
[20:24] <fginther> was just waiting for them to complete
[20:24] <psivaa> fginther: thanks a lot for fixing them
[20:24] <jgdx> ahayzen, great. Thank you guys. Wonderschön
[20:25] <alecu> dobey: any ideas? ^
[20:25] <fginther> jgdx, psivaa, I restarted jobs for https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/apn-prototype/+merge/258992, https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/wifi_activate_on_click/+merge/261425, and https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/fix-1441192/+merge/255402
[20:26] <dobey> alecu: it seems armhf and powrpc builders are having some issues
[20:26] <psivaa> fginther: thanks, i have again started https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/wifi_activate_on_click/+merge/261425
[20:26] <alecu> ack
[20:27] <dobey> alecu: at least, everything builds, but segfault happens when it tries to run the test binaries
[20:29] <jgdx> fginther, great stuff. Thanks
[20:34] <fginther> jgdx, looks like the amd64 builds for ubuntu-system-settings are failing because the jobs were configured to collect test results that aren't there. I'm also fixing this.
[20:40] <jgdx> fginther, oh, okay. I haven't seen that before.
[22:12] <robru> jamesh_: i don't understand what you did in silo 17. Did you upload it to wily yourself?
[22:14] <cjwatson> dobey: I doubt that's a builder issue; there's been no relevant maintenance on them
[22:19] <cjwatson> https://code.launchpad.net/~cjwatson/launchpad/do-not-expire-phone-overlay/+merge/261438  possibly relevant to the interests of some here
[22:20] <veebers> Hi robru o/ How's things? Might be a silly question, how do I get the autopilot silo/package moved from proposed pocket? I had the impression that I had done the needed sru things.
[22:21] <robru> veebers: there's lots of steps. Did you verify the bugs are fixed and mark the bug as verification passed?
[22:23] <robru> veebers: looks like one bug is tagged verification-needed still.
[22:23] <veebers> robru: aye, set the tag as verification-done . .  Oh? Rats, seems I missed that one :-P
[22:24] <veebers> robru: right, sorting that out now
[22:25] <robru> veebers: then you need to poke somebody from Ubuntu-sru with a pointy stick.
[22:26] <veebers> robru: ack, will figure out who to poke (and leave you alone ;-) ). Thanks again for the help
[22:26] <robru> veebers: you're welcome! SRU's are notoriously slow, if you get it accepted in under 2 months i think you're doing well
[22:27] <veebers> robru: ^_^ cheers
[22:28] <cjwatson> veebers: https://bugs.launchpad.net/autopilot/+bug/1425721 is listed on http://people.canonical.com/~ubuntu-archive/pending-sru.html as v-needed too
[22:28] <cjwatson> (not that I'm effectively ubuntu-sru any more, I'm just still in that team so that I could do some code fixes, should probably leave it again)
[22:41] <veebers> cjwatson: ah I see, ack thanks for clarifying :-)
[22:53] <boiko> robru: hey, the dashboard says address-book-app is in the proposed pocket for silo 31, but I can't see it in the excuses page
[22:55] <robru> boiko: Hmmmmmmm that is strange considering i published it 3 hours ago
[22:58] <slangasek> kenvandine: hi, bdmurray has brought it to my attention that there are two different "systemd-shim 9-1bzr3" packages now that were built in different silos - one in silo 035 for vivid and copied to the stable-phone-overlay ppa, one in silo 001 for wily and published to wily
[22:58] <robru> cjwatson: infinity: Hmmmmmmm, excuses page seems to be 6hrs stale, can somebody check on that?
[22:58] <slangasek> kenvandine: can you help us understand how this happened?


[00:00] <satellit> mjrosenb: http://support.google.com/chromeos/bin/answer.py?hl=en&answer=1080595   how to recover chromebook
[00:02] <mjrosenb> satellit: as I said earlier, I can recover it
[00:02] <mjrosenb> also, I suspect that won't work on my laptop
[07:55] <dholbach> good morning
[08:24] <mjrosenb> morning.
[08:24] <mjrosenb> http://pastebin.mozilla.org/2001455
[08:24] <mjrosenb> that is from my pandaboard, I just tried to upgrade a fresh install to 12.10, and got a black screen.
[08:25] <mjrosenb> I also got this in dmesg
[08:25] <mjrosenb> [    7.703308] init: Failed to spawn hybrid-gfx main process: unable to execute: No such file or directory
[08:31] <mjrosenb> ok, I have the sd card plugged into my laptop, and I want to enable the ssh server... is there an easy way to do this?
[09:01] <infinity> mjrosenb: You're missing libdrm-omap1, looks like.
[09:02] <infinity> mjrosenb: Also, it's not so much "enabling" the ssh server as installing the package, which you'd need to do either on an ARM machine, or with emulation.
[09:02] <mjrosenb> qemu-system-arm does not have an omap4 option from what i can tell
[09:03] <mjrosenb> i'm actually kind of surprised there isn't a pandaboard option
[09:03] <infinity> I'm not.
[09:04] <infinity> Emulating a Panda isn't something qemu upstream would care to do, and TI didn't see the value in writing a board-specific emulator (most vendors don't)
[09:04] <infinity> Anyhow, I didn't mean full system emulation.
[09:04] <infinity> qemu-user-static would be fine.
[09:05] <infinity> Mount your SD card to somewhere (we'll say /mnt), apt-get install qemu-user-static && cp /usr/bin/qemu-arm-static /mnt/usr/bin && chroot /mnt su -
[09:06] <infinity> Presto, you're in your ARM system as a chroot.
[09:06] <infinity> apt-get install ssh libdrm-omap1
[09:07] <infinity> apt-get install pvr-omap4 # if you wanted some non-free 3D action.
[09:08] <infinity> Which is probably necessary, if you're running Ubuntu/Unity.
[09:11] <mjrosenb> for whatever reason, ssh seems to already be installed
[09:11] <mjrosenb> but it isn't starting
[09:11] <mjrosenb> and it isn't bringing up the network
[10:10] <hrw> infinity: can you share /var/log/Xorg.0.log from panda with opengles support?
[10:12] <infinity> mjrosenb: If your network is wireless-only, that could explain it.
[10:12] <infinity> hrw: My Panda has no X right now.
[10:14] <mjrosenb> infinity: nope, eth0 is the pandaboard's onboard connection
[10:15] <infinity> mjrosenb: Oh, curious.  Maybe it hates you/
[10:16] <hrw> infinity: ok
[11:25] <mjrosenb> sweet, I can ssh into my pandaboard again
[12:26] <mjrosenb> ok, I know I did this on my last install; what do I need to run in order to get a non-hf library installed?
[12:27] <mjrosenb> or better yet, what on earth is it called?
[12:27] <mjrosenb> i'm searching for multilib
[12:27] <mjrosenb> but that is giving man irrelevant results
[12:45] <infinity> mjrosenb: Depends on which non-hf library you need.
[12:46] <infinity> mjrosenb: If it's just libc6 (and a gcc that can build sf binaries), there are multilib versions.
[12:46] <mjrosenb> looks like the answer was
[12:46] <mjrosenb> dpkg --add-architecture armel
[12:46] <mjrosenb> which is surprisingly hard to find via google
[12:46] <infinity> mjrosenb: If it's more comprehensive, you want multiarch (dpkg --add-architecture armel && apt-get update && apt-get install libfoo1:armel)
[12:47] <infinity> That said, I wouldn't rely on armhf/armel multiarch going forward, since we've dropped armel in raring...
[12:47] <infinity> What are you doing that *needs* soft-float libraries?
[12:47] <mjrosenb> y'all are making my life really hard, you know that?
[12:48] <mjrosenb> i'm testing fennec, which is supposed to run on android which is armel.
[12:48] <infinity> .. unless it's newer Android, then it's not. :P
[12:49] <mjrosenb> how does that work from a packages' point of view?
[12:49] <infinity> That said, fennec could be rebuilt...
[12:49] <mjrosenb> do they need to upload two .apks, one for armel, one for armhf?
[12:49] <infinity> I have no idea how Android is handling the sf/hf transition.
[12:50] <infinity> Then again, most apps aren't C binaries, so the point is moot for them.
[12:50] <mjrosenb> you know what version they made the transition in?
[12:50] <infinity> It could also be that this is all a bit different with bionic, I have no idea.
[12:51] <infinity> I just know they were doing the transition (or maybe had done so).
[12:51] <sveinse> Does anyone know if Network Manager regularely scans for a list of available networks in precise? We're having some problems with communication locking up for 2-3 seconds and wondering if this could be related to nm scanning the networks
[12:51] <infinity> mjrosenb: It's possible they haven't actually made the switch yet for bionic-based systems (ie: Android), though they definitely did for ChromeOS.
[12:52] <infinity> Confusing world.
[12:52] <infinity> mjrosenb: Still, for an open-source project like fennec, surely you'd want to build it for Ubuntu to run it on Ubuntu anyway?
[12:52] <infinity> mjrosenb: Since an Android build wants bionic, which means running shims and other horrors.
[12:52] <mjrosenb> infinity: we don't build for ubuntu, ubuntu does :-p
[12:53] <infinity> s/Ubuntu/glibc/? :P
[12:53] <mjrosenb> bionic?
[12:53]  * mjrosenb googles
[12:53] <infinity> bionic is Android's libc.
[12:53] <infinity> It's not even remotely compatible with glibc.
[12:53] <mjrosenb> FUN.
[12:53] <infinity> There is a project that produces a disturbing translation shim that allows glibc systems to run bionic binaries with an LD_PRELOAD.
[12:53] <infinity> It's not pleasant.
[12:54] <infinity> I don't recommend it for a project you actually have the source to.
[12:54] <mjrosenb> we already have NSPR
[12:55] <infinity> mjrosenb: Err, NSPR doens't give you portability at runtime, but at build-time.
[12:55] <infinity> A bionic-using nspr won't do you a lick of good on a glibc system.
[12:56] <mjrosenb> yeah, but I don't think it has ever been our goal to have a single executable that runs on all arches.
[12:56] <infinity> (bionic is vaguely BSD-derived, think about how well it wouldn't work to take a binary from FreeBSD and run it on Linux, even if you had the kernel syscalls emulated)
[12:56] <infinity> No, it shouldn't be your goal to run a binary on multiple arches.  I agree.
[12:56] <infinity> Hence why I'm suggesting you might just want to rebuild it.
[12:56] <infinity> Cause libc6:armel still won't be bionic, so multiarch isn't going to help you here.
[12:57] <mjrosenb> http://pastebin.mozilla.org/2001793
[12:58] <mjrosenb> ahh. yes, but I like testing in an environment that is as close to what we'll be seeing in a shipping product as possible
[12:58] <mjrosenb> the js engine doesn't really have to deal with libc that much
[12:58] <mjrosenb> but it does need to deal with the likes of math.sin math.atan2
[12:58] <infinity> The wrapper lies, it's linux-ti-omap4-tools-3.5.0-215
[12:58] <mjrosenb> where the armel/armhf distinction comes into play
[12:59] <infinity> Oh, wait.  You're doing this to test for Android?
[12:59] <mjrosenb> yup.
[12:59] <infinity> Then you should build an Android chroot.
[12:59] <mjrosenb> that sounds neat.
[12:59] <infinity> Testing against glibc won't really tell you anything.
[12:59] <mjrosenb> as previously stated, I have basically 0 interaction with glibc.
[13:00] <mjrosenb> but I *am* intrigued by the concept of an android chroot.
[13:00] <infinity> Well, you must have some, or would wouldn't care about ABI.
[13:00] <infinity> Since if you were talking to the kernel directly, it's meaningless.
[13:00] <mjrosenb>   Error: sys_perf_event_open() syscall returned with 19 (No such device).  /bin/dmesg may provide additional information.
[13:00] <mjrosenb> :(
[13:01] <infinity> I didn't say perf would work, just pointed at the package that ships it!
[13:01] <infinity> (Sorry, I haven't slept in a while, that's about as helpful as I can be right now)
[13:01] <mjrosenb> as previously stated, there are math functions that are called that I need to be able to call correctly.
[13:01] <infinity> I should probably nap instead of being flip on IRC.
[13:01] <mjrosenb> not a problem, I may have to build my own kernel, wouldn't be the first time
[13:02] <infinity> Well, you'll also want an Android kernel for your test environment, so yeah.
[13:02] <infinity> Though, Linaro provides Panda Android builds that might be up your alley.
[13:02] <mjrosenb> well, I like using linux because it has a sane debugging strategy
[13:03] <suihkulokki> the disturbing shim thing is called libhybris: https://github.com/stskeeps/libhybris
[13:03] <suihkulokki> currently does libgles and stuff, but should be adabtible for any libraries
[13:05] <mjrosenb> right now, getting perf to work is a higher priority.
[13:46] <mjrosenb> was the source for linux-image-3.5.0-215-omap4 provided by linaro?
[15:16] <Jef91> Morning folks sfeole are you around?
[15:16] <sfeole> Jef91: i am
[15:17] <Jef91> sfeole: I was told you are the one to speak to about finding current docs on how the Ubuntu fastboot image is created for flashing to the nexus 7
[15:21] <sfeole> Jef91: hm, give me a few
[15:21] <Jef91> Sure sfeole - I'll be lurking for the better part of today.
[17:53] <mjrosenb> huh, was CONFIG_PERF_COUNTERS removed from the kernel?
[18:47] <mjrosenb> unrelatedly, is there a way to un-brick a chromebook that does not involve re-initializing all of chrome's state?
[19:57] <mjrosenb> ok, I have built my own kernel, but I am not sure how to get a bootable uimage out of it
[19:58] <mjrosenb> oh, make uImage, evidently
[20:03] <vanhoof> mjrosenb: https://code.launchpad.net/~ubuntu-nexus7/ubuntu-nexus7/build_script
[20:03] <vanhoof> look at the abootimg bits
[20:04] <vanhoof> line 71
[20:06] <vanhoof> mjrosenb: http://paste.ubuntu.com/1445967/
[20:06] <mjrosenb> make uimage sounds much easier
[20:07] <vanhoof> mjrosenb: likely, but just givin' ya whats easiest for me :)
[20:07] <mjrosenb> well, thank you for that
[20:08] <mjrosenb> hopefully, i'll remember that if i'm ever in a situation where that is more aprpriate than make uImage.
[20:19] <mjrosenb> tar -xzvf $TARBALL $packaged_path/initrd.img-$kver $packaged_path/vmlinuz-$kver
[20:19] <mjrosenb> that makes it look like the initrd is a tarball?
[20:19] <mjrosenb> oh no
[20:19] <mjrosenb> i am a fool $TARBALL is a tarball.  it has two files in it
[20:20] <mjrosenb> vanhoof: you happen to know anything about perf?
[20:28] <Tassadar> did password/user in raring for nexus 7 changed? It says "Login incorrect" when I try ubuntu/ubuntu
[20:31] <vanhoof> Tassadar: should boot to oem-config
[20:31] <vanhoof> Tassadar: choose your own user/pass
[20:31] <Tassadar> yeah, it does not start GUI, it just stays in tty1, so I am trying to find out what is wrong
[20:32] <vanhoof> first boot is a bit slow
[20:32] <Tassadar> yeah, I know, but not 5-10 minutes slow
[20:32] <vanhoof> i sometimes see a few sec delay from tty1 to oem-config on vt7 (i assume)
[20:32] <vanhoof> yeah not that slow
[20:32] <vanhoof> oem/oem should get you in
[20:32] <vanhoof> but it should launch oem-config
[20:34] <Tassadar> well, it does not, so I am trying to log in to tty1 to find what went wrong
[20:34] <Tassadar> (it might not be [probably is not] ubuntu issue though)
[20:39] <Tassadar> well, I guess I'll just chroot into it from recovery and change the password/create my own user
[20:42] <mjrosenb> ok, different approach, does anyone have perf working on an omap4 running 12.10?
[20:44] <Tassadar> oh, yeah, I guess that read-only root is not such a great idea :)
[20:46] <mjrosenb> relatedly, I followed the directions at http://seabright.co.nz/2011/03/29/building-the-ubuntu-pandaboard-kernel/ -- how do I build an initrd now?
[20:54] <vanhoof> Tassadar: how did you flash the device
[20:55] <vanhoof> Tassadar: make sure cmdline is tty0 if you came from quantal
[20:55] <Tassadar> it's okay now
[20:55] <vanhoof> ah ok
[20:55] <Tassadar> onboard still does not show up in oem-config for me, though
[20:55] <vanhoof> fresh flash?
[20:55] <Tassadar> yeah, basically
[20:55] <vanhoof> i flashed friday on 8gb model, no issues w/ onboard
[20:58] <vanhoof> mjrosenb: played w/ perf on x86 not on arm, but should be in linux-tools binary wise
[20:58] <vanhoof> linux-tools-nexus7 iirc
[21:09] <Tassadar> all the ext4 partitions on my nexus7 has the same UUID, what the hell Oo
[21:09] <mjrosenb> vanhoof: http://pastebin.mozilla.org/2002447
[21:10] <vanhoof> mjrosenb: looks like we need
[21:10] <vanhoof>   Fatal: No CONFIG_PERF_EVENTS=y kernel support configured?
[21:10] <vanhoof> mjrosenb: mind opening a bug against lp/ubuntu-nexus7 ?
[21:12] <mjrosenb> vanhoof: this is on a pandaboard.
[21:13] <mjrosenb> and;
[21:13] <mjrosenb> mrosenberg@panda:~$ grep CONFIG_PERF_EVENTS /boot/config-3.5.0-215-omap4
[21:13] <mjrosenb> CONFIG_PERF_EVENTS=y
[21:14] <mjrosenb> so unless /boot/config-`uname -r` is out of sync with the kernel, I should have that.
[21:14] <vanhoof> ah i thought you were talking n7
[21:15] <vanhoof> will have to look at omap4
[21:15] <mjrosenb> I realize that the perf event system is basically totally hosed on omap4
[21:16] <mjrosenb> but I just need the timer-based perf working
[21:27] <Tassadar> vanhoof: could you please check which version of onboard is installed on your n7?
[21:28] <mjrosenb> so nobody uses a pandaboard in here/
[21:29] <SailorMoon> lol
[21:29] <SailorMoon> How do i install the nightlies?
[21:30] <SailorMoon> i downloaded them in .gz format or whatever and every tool i have to open a .gz shows a .raw file
[21:30] <SailorMoon> i dunno how to get an .img from them
[21:43] <vanhoof> SailorMoon: https://launchpad.net/~ubuntu-nexus7/+archive/ubuntu-nexus7-installer
[21:43] <vanhoof> Tassadar: gimme a sec, charging atm
[21:45] <Tassadar> it looks like something crashes, because a while after I tap into the textfield, the windows lose the decorations (the title bar)
[21:47] <vanhoof> Tassadar: want an older nightly?
[21:48] <Tassadar> hmm, yeah, I suppose I could try that
[21:48] <vanhoof> i need to let this guy charge up for a bit
[21:48] <mjrosenb> speaking of which, does the upgrade process know how to upgrade the kernel on a chromebook
[21:49] <vanhoof> mjrosenb: doubtful
[21:49] <vanhoof> at least I dont think so
[21:49] <mjrosenb> and if not, I assume that I need to do it myself
[21:49] <vanhoof> i could be wrong
[22:03] <mjrosenb> is there a time of the week when people knowledgable about the pandaboard or chromebook would be online/
[22:03] <vanhoof> mjrosenb: january 2nd? ;)
[22:03] <vanhoof> mjrosenb: not sure, no cb experience here myself
[22:07] <vanhoof> Tassadar: http://people.canonical.com/~vanhoof/tassadar/UbuntuNexus7.tar.gz
[22:07] <vanhoof> Tassadar: from thursday'ish last week
[22:07] <Tassadar> thanks
[22:32] <Tassadar> nah, does the exact same thing :(
[22:32] <vanhoof> :\
[22:33] <vanhoof> i get through just fine
[22:33]  * vanhoof wtfs
[22:33] <Tassadar> it is probably my fault, I am dual-booting it and probably got something wrong
[22:36] <Tassadar> seems kinda weird though, it is doing exactly the same thing as it did when it didn't work for anyone
[23:01] <inph^> are there any nexus 7 ubuntu forums?
[23:19] <mjrosenb> checking whether the chosen combination of compiler flags (-march=armv6 -mfpu=vfp -mfloat-abi=hard) works... configure: error: no
[23:19] <mjrosenb> :-/
[23:26] <infinity> mjrosenb: Do I want to know why you're targetting v6?
[23:28] <mjrosenb> infinity: because i have a raspberry pi.
[23:28] <infinity> (Though, that combination should work, in theory, it's what Raspbian uses)
[23:28] <infinity> I'd assume the configure test itself is doing something silly.
[23:28] <infinity> Like possibly tacking on a -mfpu=neon or something? :P
[23:29] <mjrosenb> configure:5745:1: sorry, unimplemented: Thumb-1 hard-float VFP ABI
[23:30] <infinity> mjrosenb: Give it a -marm
[23:32] <mjrosenb> i already tried that, it produced executables that don't run :/
[23:32] <infinity> mjrosenb: Though, if you're cross-compiling from Ubuntu, you may find that you'll also end up compiling in static bits from our toolchain, which are v7/thumb-2, and it will all fail to run on the Pi anyway.
[23:32] <infinity> mjrosenb: Jinx. :P
[23:33] <mjrosenb> ugh.. -march=armv6 should mean 'don't do that'
[23:33] <infinity> "Don't link the static bits that you need to run the binary" is a tall order.
[23:33] <infinity> libgcc_s, crt*.o, etc.
[23:34] <mjrosenb> i mean, how does a gcc that can target both x86 and x64 handle that?
[23:34] <infinity> Well, crt*.o should be pure ARMv5 or so, but you get my point.
[23:34] <infinity> biarch GCC relies on having two copies of everything.
[23:34] <infinity> As does our biarch armel/armhf GCC.
[23:34] <infinity> But ours was never designed to target older CPUs.
[23:34] <infinity> Just as a biarch Ubuntu x86 GCC can
[23:34] <infinity> 't actually build binaries for i386.
[23:35] <infinity> Well, probably not.  Again, it depends on if any of the static bits use [456]86 instructions.
[23:35] <infinity> Which, in the ARM case, they do use v7 bits.
[23:36] <mjrosenb> this is a toolchain acquired from emdebian from well before ubuntu properly supported cross compilation
[23:36] <infinity> An armhf one though, right?
[23:36] <infinity> Debian's armhf has always been armv7-a/thumb-2
[23:37] <mjrosenb> armel, with -mfloat-abi=hard
[23:37] <infinity> As has nearly everyone's, to be fair.  Raspbian is one of the only strange attempts to do armhf on v6.
[23:37] <infinity> mjrosenb: Err, what?  "armel with -mfloat-abi=hard" *is* armhf.
[23:38] <mjrosenb> what is the difference/
[23:38] <mjrosenb> *difference?
[23:38] <infinity> Or do you mean this is an ancient compiler that was only armel?  If so, you're producing binaries that don't run for other reasons.
[23:38] <infinity> Either because the static bits aren't armhf or because you're cooking in the wrong path to the PI.
[23:39] <infinity> What's the failure mode when you try to run the binaries?
[23:39] <mjrosenb> this compiler has been producing binaries that have worked on armv7el and armv7hf systems for quite some time.
[23:39] <mjrosenb> sigill
[23:39] <mjrosenb> looks like it is getting confused about thumb mode.
[23:39] <infinity> Or that it's compiling in some v7 bits.
[23:39] <mjrosenb> oh hey
[23:39] <mjrosenb> i am using the armhf compiler
[23:40] <infinity> This is a well-known problem among Pi people trying to cross from Ubuntu.
[23:40] <mjrosenb> sounds reasonable
[23:40] <infinity> You can manually copy various static bits like libgcc from your Raspbian system to your cross environment.
[23:41] <infinity> There's also a Raspbian cross toolchain.
[23:42] <infinity> That targets the right thing by default.
[23:42] <mjrosenb> yeah, as hacked as this system is, i don't like having programs installed that aren't managed by my package manager
[23:43] <mjrosenb> i'll have to find some way of making a .deb out of the cross toolchain
[23:58] <ubuntubhoy> does anyone here have any input on the Nexus 7 install wiki page ?


[06:43] <xelister> wtf
[06:43] <xelister> I tried just installing kate  on my 10.10
[06:44] <xelister> and in response aptitude proceeded to remove  kmail, konversation and dozen other k-apps.. wtf
[06:46] <micahg> aptitude was removed from the default install in maverick :)
[06:47] <micahg> xelister: but seriously, did you check what the conflict was?  you can examine and at the bottom it'll tell you how it can resolve the conflict
[06:49] <xelister> micahg: http://pastebin.com/raw.php?i=jy40iYg5
[06:54] <micahg> xelister: sounds like some stuff got dropped in the maverick SRU of KDE
[06:54] <xelister> so....?
[06:54] <micahg> let's see if I can find someone
[06:56] <micahg> xelister: BTW, using -y unless you don't care what it does is a bad idea
[06:56] <xelister> in god I trust
[06:56]  * micahg guesses he decided you don't need those packages:D
[06:57]  * xelister :-O  Shuttleworth take the wheal!
[06:57]  * xelister *boom*         :-E
[06:57] <xelister> anyway... so this is some bug that ubuntu tries to murder half my KDE system when I merly want to use konsole, and it will get fixxed? soon?
[06:59] <micahg> xelister: it's not a bug in aptitude, it seems something was missing during the last SRU, could you please file a bug against konsole with that pastebin in the bug?  I'll try to get someone to look at it later today
[06:59] <xelister> bbl.   But this loks like a serious bug imo.
[07:00] <xelister> micahg: got to run...  will be back evening in ~+15 hours
[07:00] <micahg> xelister: k, I'll try to get someone to look at it in any case
[14:01] <nic___> there any news on the power-consumption bug?
[14:02] <JoshuaL> nic___, https://bugs.launchpad.net/ubuntu/natty/+source/linux/+bug/760131
[14:03] <ubot4> Launchpad bug 760131 in linux (Ubuntu Oneiric) (and 3 other projects) "Power consumption raised significantly in natty (affects: 201) (heat: 1356)" [High,Confirmed]
[14:03] <nic___> anybody know if they've figured out yet, just need to fix it. or is it stilla mystery what causing?
[14:05] <nic___> where does it say it affects "3 other projects"? the launchpad only shows natty and oneiric. But i think lucid and mav affected as well.
[14:11] <hggdh> nic___: Release Notes for Ubuntu, and the Natty and Oneiric kernels
[14:13] <Tetsuo55_2> nic___: i dont see any updates about it on the phorix forum
[14:22] <nic___> release notes?
[14:23] <nic___> lots and lots of stuff ont he web about how Linux runs hotter than windows. possible it's all releated to the bug?
[14:23] <nic___> I see reports even going back to like 8.10 ubuntu
[14:38] <hggdh> nic___: yes -- an entry had to be made in the RN for this bug
[14:39] <hggdh> nic___: and, no, it is not probable all 'running hotter' reports relate to this bug
[14:39] <JoshuaL> those love handles, are they part of compiz or unity when reporting a bug?
[15:38] <hggdh> jibel: thank you for the validation on bug 663925, I could not do it since I proposed the change
[15:38] <ubot4> Launchpad bug 663925 in ncmpcpp (Ubuntu Natty) (and 3 other projects) "ncmpcpp (version < 0. 5.4) can cause unexpected deletion of files (affects: 1) (heat: 270)" [Undecided,Fix released] https://launchpad.net/bugs/663925
[15:40] <jibel> hggdh, you're welcome, it wiped out half of the drive of my test system :-)
[15:40] <hggdh> jibel: heh. Real nice bug, is it not?
[15:42] <jibel> hggdh, indeed, random cleaning is great to save disk space!
[15:43] <roadmr> yay :)
[15:47] <roadmr> "real men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" - Linus
[21:03] <brendand> i'm going over some bugs in update-manager
[21:03] <brendand> can someone in bug control set this to low for me:
[21:03] <brendand> https://bugs.launchpad.net/update-manager/+bug/778555
[21:03] <ubot4> Launchpad bug 778555 in update-manager (and 1 other project) "Unnecessary technical information in distro upgrade dialogue (affects: 1) (heat: 85)" [Undecided,Confirmed]
[21:04] <roadmr> yay!
[21:06] <bcurtiswx> is Ubuntu the upstream for update-manager?
[21:07] <trinikrono> doesnt look so
[21:07] <trinikrono> https://launchpad.net/update-manager
[21:07] <trinikrono> says its a gnome project
[21:17] <braiam> I have a bug against the locales, but I doesn't know to what package assign it. It's about the time format.
[21:18] <braiam> It only affects the es-* locales
[22:59] <micahg> bcurtiswx: yes, Ubuntu is upstream for update-manager
[23:00] <bcurtiswx> thjx
[23:00] <bcurtiswx> thx*


[00:30] <dumpchama> hi... i have a problem where i am unable to shut down the system after resuming from suspend... the computer will just logout..
[00:30] <dumpchama> how can i fix this?
[00:56] <Lonel> hey
[00:56] <Lonel> does anyone know how to permanently disable cd-rom
[01:05] <ouroumov_> hi Lonel
[01:06] <ouroumov_> Lonel, some BIOS have options to selectively kill off hardware such as webcams, wifi adaptors and so on
[01:06] <ouroumov_> Lonel, you can also blacklist whatever driver's used by the drive, I think
[01:07] <ouroumov_> dumpchama, hi
[01:07] <dumpchama> hi
[01:07] <ouroumov_> dumpchama, is this when shutting down from the graphical interface?
[01:07] <dumpchama> yes
[01:07] <dumpchama> this is my log when i try doing from terminal: http://paste.ubuntu.com/23305769/
[01:09] <Lonel> ouroumov_: could you please guide me through it? there is a CD that is suck in the cd-rom and I can't get it out. I want to make it so it never turns on again (even after restart)
[01:11] <Lonel> I'll go check the BIOS options brb
[01:18] <Lonel> Anyone here know how to disable cd-rom permanently?
[01:18] <Lonel> I want to kill it off for good.
[01:19] <Lonel> There are no options in the BIOS for me to do so
[01:20] <dumpchama> if it's a desktop pc you can always unplug it from the inside?
[01:24] <pta> hi
[01:24] <pta> i need help
[01:25] <pta> how to install samba on ubuntu mate
[01:25] <Lonel> dumpchama: its a laptop
[01:26] <pta> no
[01:26] <pta> pi 3
[01:39] <pta> hello
[01:39] <pta> anyone at here
[01:49] <ouroumov_> Damn I missed hom
[01:49] <ouroumov_> That may be a use case for the "eject" command
[09:07] <ouroumov> flexiondotorg: good morning. Have you given any more though about that idea you floated a while back regarding bug bounties?
[09:07] <flexiondotorg> ouroumov, Yes. We're going to do a sort of bounty programme during the 17.04 cycle.
[09:08] <ouroumov> flexiondotorg, that's great. Funding from Patreon?
[09:09] <flexiondotorg> Funding from all the Ubuntu MATE crowd-funding.
[09:09] <ouroumov> Nice.
[09:09] <flexiondotorg> I'm not sure if we will use Boutysource or sort out something more direct.
[09:14] <ouroumov> So in case you're putting a shortlist together, I think https://github.com/mate-desktop/mate-screensaver/issues/92 should be in it
[15:55] <ubuntu-mate> helo
[20:36] <brian_> mate seems so much faster with the xanmod 4.8 kernel.
[20:37] <brian_> Though, i have to use the open source drivers, because the nivida ones dont work with Xanmod for some reason.


[22:16] <tsimonq2> Hah, I completely forgot I have the access to directly commit the testcase changes...
[22:26] <tsimonq2> flocculant: Just a thought -- would it break something if we switched to Git for lp:ubuntu-manual-tests? Do you have any objections?


[09:26] <kaisers2> Hi! I'm looking for help in finding out which email address is used by a jujucharmstore. Anybody with 2mins? :)
[09:33] <kaisers2> Correction: "... a jujucharmstore namespace."
[09:33] <kaisers2> There's a namespace defined for our company but i cannot find a way how to access it for updating charms...
[09:42] <kaisers2> uh,oh nevermind any longer, i just found my answer. :)
[20:21] <arosales> Hi
[20:21] <arosales> Any body else seeing 404 @ jujucharms.com/<charm-name>
[20:21] <arosales> https://jujucharms.com/canonical-kubernetes
[20:21] <arosales> 404 for me as well as others I have  tried
[20:25] <arosales> note I am logged in or the beta program
[20:27] <arosales> sorry itsa 400, not a 404
[20:27] <arosales> and now anything @ https://jujucharms.com/
[20:38] <rick_h> arosales: no, not here
[20:38] <hatch> arosales looks good here as well
[20:39] <arosales> ok, tried on a different machine and it works there. Only difference it I went through the full auth cycle on the alternate machine
[20:39] <arosales> on the problem machine I guess it picked up my browser cookie for SSO
[20:39] <arosales> but seems to just be me
[20:39] <arosales> rick_h: hatch thanks
[20:41] <rick_h> arosales: hmm, k. If you dupe/see it more let us know and we'll see if there's something we can do
[20:41] <arosales> rick_h: will do
[20:42] <arosales> jujucharms.com is totally 400 on one machine. I guess I should look for a cookie/maroon in chrome and try to force a better response
[20:43] <arosales> *macaroon
[20:43] <hatch> arosales if you can reproduce it then I believe we can find the problem
[20:43] <hatch> arosales can you open the chrome devtools and then refresh the page
[20:44] <hatch> a 400 is quite an odd response code for the main landing page
[20:44]  * arosales already started removing cookies and site data for *jujucharms*
[20:44] <hatch> oh
[20:44] <hatch> darn
[20:44] <arosales> but ack if I can reproduce I'll report @ github
[20:44] <hatch> well a report won't help much if we can't reproduce it :)
[20:45] <arosales> ah, home page is back
[20:45] <arosales> I'll see if I can reproduce
[20:45] <hatch> ok we'll have to pull up the logs and see if we can deduce the issue from there
[20:45] <hatch> you probably won't be able to reproduce now
[20:46] <hatch> I have an idea what the issue is but will have to confirm with the logs
[20:47] <hatch> arosales when was the last time you visited jujucharms.com with this machine?
[20:47] <arosales> hatch: sorry I got heavy handed there with removing cookies before you pinged :-/
[20:47] <hatch> no problem
[20:47] <arosales> hatch: this morning
[20:47] <hatch> hmm ok, an update did roll out since then
[20:47] <arosales> but I wasn't logged in
[20:47] <arosales> I only saw the issue after I logged in
[20:47] <arosales> but now seems ok
[20:48] <hatch> hmm ok that's a little more confusing :D
[20:48] <hatch> but glad it's back up and running :)
[20:51] <arosales> hatch: thanks for the replies here
[20:52] <hatch> no problem, glad to help