[03:56]  * StevenK stabs the error handling for spr.addFile()
[03:56] <StevenK> bpr.addFile() just checks filename.endswith(), spr.addFile() matches against a regex.
[04:05] <StevenK> Can I forbid buildout from downloading stuff that isn't in the local cache?
[04:05] <wgrant> It should be already
[04:06] <StevenK> Not for LP.
[04:06] <StevenK> https://pastebin.canonical.com/81106/
[04:06] <wgrant> install-from-cache = true
[04:06] <wgrant> Is set in buildout.cfg
[04:06] <wgrant> So it should already refuse to go to the Internet
[04:06] <wgrant> Oh
[04:06] <wgrant> That's not LP
[04:06] <wgrant> That's auditor, isn't it?
[04:07] <StevenK> [15:06] < StevenK> Not for LP.
[04:07] <wgrant> 15:05:50 < wgrant> It should be already
[04:07] <wgrant> 15:06:01 < StevenK> Not for LP.
[04:07] <wgrant> :)
[04:07] <StevenK> And yeah, it's auditor
[04:08] <cjohnston> Am I mistaking or is bug #517302 a dup of bug #496056
[04:08] <_mup_> Bug #517302: "1 branch dependent on this one." doesn't link to that branch or a list of them <code-review> <confusing-ui> <easy> <lp-code> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/517302 >
[04:08] <_mup_> Bug #496056: Dependent branch list is empty <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/496056 >
[04:09] <wgrant> Indeed
[04:09] <wgrant> Done
[04:10] <StevenK> wgrant: Then I'm confused, since Django is in our download-cache
[04:10] <cjohnston> :-)
[04:10] <StevenK> Indeed, 1.3.3 and 1.4
[04:11] <wgrant> StevenK: Is the flag set in order?
[04:11] <wgrant> In auditor?
[04:11] <StevenK> That flag was not set
[04:11] <StevenK> The order in buildout.cfg matters? :-/
[04:12] <wgrant> No, I just replaced 'auditor' with 'order' because I'm doing too many things at once :)
[04:12] <wgrant> As long as it's in the right section it should be fine
[04:12] <wgrant> AFAIK
[04:12] <StevenK> wgrant: I've set it locally
[04:14] <StevenK> Hm, it does indeed try and slurp Django from the net with that flag unset.
[04:14] <StevenK> It gets 1.4 from the download-cache with it set, and 1.4.3 from the net with it unset.
[04:15]  * StevenK stabs buildout for being silly.
[04:17] <wgrant> StevenK: You don't have it locked in versions.cfg?
[04:18] <StevenK> No versions.cfg
[04:18] <StevenK> Patches welcome? :-)
[04:18] <wgrant> Ah, that would be your mistake
[04:22] <StevenK> wgrant: So it should grow a versions.cfg too?
[04:22] <wgrant> Probably, or someone'll throw a new Django into download-cache and you'll die
[04:23] <StevenK> wgrant: So grabbing LP's versions.cfg and putting it on a large diet with head and grep would be fine?
[04:23] <wgrant> Nope
[04:24] <wgrant> Set allow-picked-versions = false
[04:24] <wgrant> Add stuff to versions.cfg until buildout unbreaks
[04:28] <StevenK> Hmm
[04:28] <StevenK> Why do we have two versions of setuptools in the cache?
[04:28] <wgrant> There's only one
[04:28] <wgrant> Different Python versions
[04:29] <StevenK> I have a 2.6 and a 2.7 for 0.6c11
[04:30] <wgrant> Yes
[04:30] <wgrant> One version
[04:30] <wgrant> Two Python versions
[04:30] <wgrant> They're built eggs, not source tarballs
[04:31] <StevenK> Oh
[04:31] <StevenK> I see what's happened
[04:31] <StevenK> My cache has been polluted
[04:31] <StevenK> -rw-rw-r-- 1 steven steven 326K Jan  4 15:13 setuptools-0.6c12dev_r88846-py2.7.egg
[04:31] <StevenK> The timestamp is a clue
[04:32] <wgrant> Ah, yes
[04:32] <wgrant> bzr st
[04:32] <StevenK> Yeah, removed them
[04:33]  * StevenK cleans, since buildout is still attached to the dev release
[04:33] <StevenK>   Getting distribution for 'setuptools'.
[04:33] <StevenK> Error: Picked: setuptools = 0.6c11
[04:33] <StevenK> But setuptools = 0.6c11 is in versions.cfg :-(
[04:34] <wgrant> Do you have versions.cfg registered in buildout.cfg?
[04:34] <StevenK> I do now
[04:35] <wgrant> Does it also work now?
[04:35] <StevenK> It moved onto zc.buildout, so yay progress?
[04:36] <wgrant> :)
[04:37] <StevenK> Generated interpreter '/home/steven/production-auditor/bin/py'.
[04:37] <StevenK> Fantastic.
[05:19] <nigelb> Just here to complain about the expiring notices from LP.
[05:19] <nigelb> I wish I could fix it.
[05:20] <StevenK> Patches welcome.
[05:22] <bigjools> lifeless: that android bug made me spit my lunch I laughed so hard
[05:31] <nigelb> bigjools: the giraffe thing?
[05:31] <bigjools> yes
[05:31] <nigelb> :D
[05:31] <nigelb> Is it a bug/
[05:31] <bigjools> I even recreated it
[05:32] <bigjools> well, I wonder
[05:32] <nigelb> Feels more like a easter egg.
[05:32] <bigjools> yeah
[05:46] <lifeless> bigjools: its pretty awesome isn't it :)
[05:48] <bigjools> ah it is a bug in TTS
[06:20] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/divorce-bfj-and-bfjo/+merge/141856
[06:22] <StevenK> 159"""See `IBuildFarmJobOld`."""
[06:23] <StevenK> Oh, you aren't disposing of BFJO yet?
[06:23] <StevenK> 286	+ # Classes deriving from PackageBuild must provide various
[06:23] <StevenK> 287	+ # methods.
[06:23] <StevenK> Does that fit on one line?
[06:23] <wgrant> Not quite
[06:24] <wgrant> On both counts
[06:24] <wgrant> BFJO still serves a purpose, and it won't be directly touched by this refactor
[06:24] <wgrant> Which is why I want the interfaces to not be arbitrarily interrelated without having any actual overlap :/
[06:25] <StevenK> wgrant: Minor niggle, but you didn't update the copyright in lib/lp/security.py
[06:25] <StevenK> Other than that, looks great to me.
[06:25] <wgrant> Fixed
[06:25] <wgrant> Thanks
[06:27] <StevenK> wgrant: To be clear, BFJO is marked for death and will be completly ripped out at some point?
[06:27] <wgrant> It's been marked for death for about 2.5 years, but it'll be easier after my current work
[06:27] <wgrant> So it might die within the next few months
[06:34] <bigjools> \o/
[09:01] <adeuring> good morning
[09:28] <dpm> good morning all. I was wondering if someone could help me: in preparation for the phone launch I created a private project to contain the code for the tutorials on developer.ubuntu.com. And then I managed to lock myself out of it, so I cannot access the project anymore. As it does not need to be private anymore after the announcement, could someone with admin superpowers set it as a public project for me? It's https://launchpad.net/ubuntu-app-dev-cook
[09:28] <dpm> book
[09:29] <dpm> https://launchpad.net/ubuntu-app-dev-cookbook
[09:29] <wgrant> dpm: You should be able to see it now
[09:29] <wgrant> It's still private, but you can make it public
[09:30] <dpm> wgrant, great, thanks! The same happened to the associated team: https://code.launchpad.net/~ubuntu-app-dev-cooks - can I regain access to it so that I can make it public as well?
[09:31] <wgrant> dpm: That team's public and you're the owner, a member, and an admin
[09:31] <wgrant> So I'm not sure what the issue is there
[09:31] <wgrant> Are you referring to some branches owned by that team, perhaps?
[09:32] <dpm> wgrant, not sure, either. Before you did the magic with the project, if I went to the team's main page I got a "not allowed here" page. But now I seem to access the team's page, so I guess it's all good
[09:34] <wgrant> Ah, Person.getAffiliatedPillars doesn't do privacy filtering
[09:34] <wgrant> So the "Related projects" was causing the 403
[09:35] <czajkowski> aloha
[09:36] <wgrant> Bug #1095982
[09:36] <_mup_> Bug #1095982: Person.getAffiliatedPillars doesn't filter out inaccessible private projects <403> <easy> <private-projects> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1095982 >
[09:37] <wgrant> Morning czajkowski
[09:37] <dpm> wgrant, ok, I managed to set the project as public, but I cannot figure out how to make https://code.launchpad.net/~ubuntu-app-dev-cooks/ubuntu-app-dev-cookbook/trunk public. If I click on the "This branch contains Proprietary information" link, the only choice I get on the popup that appears is "Proprietary". Any suggestions on how I can make the branch public?
[09:37] <wgrant> dpm: https://launchpad.net/ubuntu-app-dev-cookbook/+sharing
[09:37] <wgrant> You probably want to set bugs, branches and blueprints to public
[09:37] <wgrant> Then you can make the branch public
[09:39] <dpm> wgrant, excellent, thanks. I set everything to public now. Do the settings on the table under "Who it's shared with" look sensible for a public project?
[09:40] <wgrant> dpm: I'd revoke your direct access, but the rest looks sensible (apart from the "{policy_name}" bit, which is a bug that'll be fixed on Monday)
[09:41] <dpm> wgrant, ok, I'll remove my direct access. Two more questions:
[09:42] <dpm> 1) I still cannot set the branch to Public: on https://code.launchpad.net/~ubuntu-app-dev-cooks/ubuntu-app-dev-cookbook/trunk if I change it, the change does not get applied
[09:42] <dpm> i.e. the spinning thing keeps spinning forever
[09:43] <wgrant> Um, that's a bit odd. What if you click "Change details" and use the old non-AJAX form?
[09:44] <wgrant> Oh
[09:44] <dpm> then I only get a Proprietary option
[09:44] <wgrant> It's because it's stacked on another branch owned by you
[09:44] <wgrant> https://code.launchpad.net/~dpm/ubuntu-app-dev-cookbook/trunk
[09:44] <wgrant> I guess you probably want to unstack the team branch, and delete your old personal one?
[09:44] <dpm> actually, that was my second question. I'd like to delete that branch (https://code.launchpad.net/~dpm/ubuntu-app-dev-cookbook/trunk)
[09:44] <dpm> how do I unstack the branch?
[09:45] <wgrant> bzr reconfigure --unstacked lp:ubuntu-app-dev-cookbook
[09:45] <wgrant> Then wait a minute or so for it to work out it's done, and you'll be able to delete the old branch and make the new one public
[09:45] <dpm> cool, let me give it a go, thanks
[09:48] <wgrant> That looks more sensible :)
[09:54] <dpm> wgrant, that worked well, thanks. I still get two warnings, though: 1) on https://launchpad.net/ubuntu-app-dev-cookbook/+sharing I removed all direct subscriptions (yours and mine) and LP it's telling me "These information types are not shared with anyone: Proprietary". Is this something that can safely ignore? And 2) on the project's front page at (https://launchpad.net/ubuntu-app-dev-cookbook) I get "(Launchpad 30-day trial commercial license)" liste
[09:54] <dpm> d as a license. I chose it when I made the project private, but I'm no longer using a commercial license. Is there a way to remove it?
[09:55] <wgrant> dpm: The Proprietary warning should go away a day or so after there are no proprietary bugs or branches left, I think
[09:56] <wgrant> As for the licence, just edit the project's licence settings to no longer include Other/Proprietary
[09:56] <wgrant> The subscription will stay there until it expires, but nothing bad will happen when it does
[09:57] <wgrant> (if the subscription expires and your project is Other/Proprietary, your project will be disabled)
[09:58] <dpm> yeah, "Other/Proprietary" was already unmarked, but from what you're saying, I should just wait for the subscription to expire
[09:58] <dpm> thanks wgrant!
[09:59] <wgrant> I can probably make the subscription expire right now if you really want, but it'll just naturally expire soon enough
[09:59] <dpm> wgrant, no worries, that's fine if it expires naturally, no need to create extra work
[10:01] <wgrant> Great
[14:13] <czajkowski> rick_h_: you about
[14:14] <rick_h_> czajkowski: yep
[14:15] <czajkowski> if you are free for a few mins can you pop into #lp please
[14:15] <rick_h_> czajkowski: sure sec


[15:00] <pitti> o/
[15:00] <infinity> \o
[15:00] <sil2100> o/
[15:01] <caribou> \o/
[15:01] <infinity> slangasek: Do you mind if I s/pitti/cyphermox/ for the release sprint?
[15:01] <infinity> cyphermox: And do you? :P
[15:01] <pitti> great! now infinity broke the nice wave pattern
[15:02] <infinity> I'm a terrible person.
[15:02] <tdaitx> o/
[15:02] <sil2100> You want them to... change nicknames for the sprint?
[15:02] <sil2100> wow
[15:02] <barry> ~o~
[15:02] <slangasek> infinity: hmm, give me a bit to think about it and we'll talk about it after the meeting?
[15:02] <pitti> ça va ! je suis un Canadien maintenant !
[15:02] <doko> first budapest, then canada ...
[15:02] <slangasek> #startmeeting
[15:02] <meetingology> Meeting started Thu Oct  8 15:02:58 2015 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:02] <meetingology> Available commands: action commands idea info link nick
[15:03] <doko> I'll go last ...
[15:03] <slangasek> [TOPIC] Lightning round
[15:03] <slangasek> $ echo $(shuf -e barry doko bdmurray slangasek caribou infinity sil2100 robru cyphermox pitti tdaitx)
[15:03] <slangasek> robru pitti infinity sil2100 barry doko caribou tdaitx bdmurray slangasek cyphermox
[15:04] <robru> I win!
[15:04] <robru> lp:cupstream2distro
[15:04] <robru> - sometimes lp doesn't respond to a copyPackage even if it copies successfully. Catch & warn the resulting exception rather than exploding
[15:04] <robru> - fix (again) the performance regression when marking silos dirty.
[15:04] <robru> - support manual sources in dual silos properly.
[15:04] <robru> - discover ppa source names so users no longer need to type them by hand
[15:04] <robru> - fix race condition in publisher that was causing duplicate statuses in the audit log
[15:04] <robru> - clarify error when releasing wily trunk for vivid.
[15:04] <robru> - stop considering duplicate assignment attempts as an error, tell the user the silo is already assigned, and set bileto status correctly
[15:04] <robru> - force all dual silos to publish wily+vivid into overlay.
[15:04] <robru> lp:bileto
[15:04] <robru> - Auto-linkify bug numbers in description
[15:04] <robru> - Stop letting long lines overflow cards.
[15:04] <robru> - fix bug with comment box losing contents during page refresh
[15:04] <robru> - discover and display artifacts URL to user.
[15:04] <robru> - totally redesign web frontend, fixing many UX issues
[15:04] <robru> - allow people to limit searches to only active requests
[15:04] <robru> - increase audit logging to include when users edit requests
[15:04] <robru> - streamline some redundant logic between a couple db model classes
[15:04] <robru> (done)
[15:05] <slangasek> pitti:
[15:05] <pitti> autopkgtest:
[15:05] <pitti>  - Correctly install main linux kernel for DKMS tests in LXC
[15:05] <pitti>  - Don't clobber already passed tests with failures from new uploads (#1501697)
[15:05] <pitti>  - Fine-tune tests triggered by gcc packages
[15:05] <pitti>  - Make linux* depend on linux-meta* (#1498807)
[15:05] <pitti>  - Discuss better/earlier autopkgtest coverage for silos with robru, slangasek, and jibel
[15:05] <pitti> misc:
[15:05] <pitti>  - langpack-o-matic: Fix erroneously discarded languages, rebuild wily packs
[15:05] <pitti>  - various bug fixes in networkd (#1500992), open-iscsi (#1501033), python-dbusmock, systemd (#1492546), udev (#795494 and others)
[15:05] <pitti>  - postgresql: Prepare new upstream security/bug fix releases for all supported Ubuntu releases (#1504132)
[15:05] <pitti>  - tons of tiny requests, mails, bug triage, and other catch-up after sprint week
[15:05] <pitti> END
[15:05] <infinity> - Kernel SRUs
[15:05] <infinity> - Emergency kernel security update
[15:05] <infinity> - s390x bootstrapping
[15:05] <infinity> - Release prep
[15:05] <infinity> - Finalizing release sprint details
[15:05] <infinity> - Lots of queue reviews
[15:06] <infinity> (done)
[15:06] <sil2100> - Landing team work, silo coordination, preparing landing e-mails
[15:06] <sil2100> - RTM Status meetings
[15:06] <sil2100> - OTA-7 preparations
[15:06] <sil2100>   * Preparing the snapshot, coordinating translations, announcements
[15:06] <sil2100> - +1 maintenance, working through the list of FTBFS from the wily test-rebuild:
[15:06] <sil2100>   * Fixed unity-voice build failure
[15:06] <sil2100>   * Poked barry for syncing wheel to fix its FTBFS
[15:06] <sil2100>   * Requested sync of python-traceback2
[15:06] <sil2100>   * Preparation of changes for ubuntuone-client-data
[15:06] <sil2100>   * Work on python-pysaml2 FTBFS - still a few failures left
[15:06] <sil2100>   * Check sponsor request for sflphone
[15:06] <sil2100> - Refreshed touch seeds, removing friends from the seeds
[15:06] <sil2100> - Play around with a new UI mockup for requests
[15:06] <sil2100> - Looking into possible solutions of displaying OTA tags on images
[15:06] <sil2100>   * Investigated the idea of an OTA map
[15:06] <sil2100>   * Looked into appending tags in system-image server json files
[15:06] <sil2100> (done)
[15:06] <barry> debuntu: LP: #1501805; wheel 0.26.0-1; git transition in dpmt (it is happening!); research for LP: #1500768; pex 1.0.3-2 and 1.0.3-2ubuntu1 to unblock wheel promotion in wily-proposed.
[15:06] <barry> system-image: discussion, research, etc. around LP: #1475568
[15:06] <barry> recovered from a server crash, including landscape breakages (issue reported, diagnosed, resolved)
[15:06] <barry> --done--
[15:09] <caribou> doko ?
[15:09] <caribou> or should I go next ?
[15:09] <caribou> Bugfix :
[15:09] <caribou> - Bug #1496317 Wily failed kdump crash smb reviewed it. Minor fixes. Will need to be SRUed
[15:09] <caribou> - sosreport autopkgtests
[15:09] <caribou> - Memory leak analysis
[15:09] <caribou> - mpt2sas firmware version for Trusty
[15:09] <caribou> - 70-persistent-rule bug SRU
[15:09] <caribou> Booked flights for sprint
[15:09] <caribou> Done
[15:09] <tdaitx> Short week:
[15:09] <tdaitx> 1. US biometrics collection on last Thursday afternoon
[15:09] <tdaitx> 2. US visa interview on Monday, flight to and back from São Paulo
[15:09] <tdaitx> Current/Past
[15:09] <tdaitx> - Squid bugs squash^W triage; was checking if my 3.3.14 update fixed any (no such luck), so I decided to spend a few more minutes in each to triage them
[15:09] <tdaitx> - Updated Squid3 from 3.3.8-1ubuntu16 to 3.3.14-0ubuntu1 (LP: #1502178)
[15:09] <tdaitx> - Fix mesa FTBFS; missing mirclient dependency on either mir-client-platform-mesa or on mesa's configure.ac (LP: #1503450)
[15:09] <tdaitx> - Investigated fix for LP: #1073478; needs SRU
[15:09] <tdaitx> - Trying to get JDK-8073139 reviews up and running again
[15:09] <tdaitx> - Finished my Core Dev application wiki (https://wiki.ubuntu.com/TiagoDaitx/CoreDeveloperApplication)
[15:09] <tdaitx> Next steps
[15:10] <tdaitx> - get icedtea 2.7-preXX packaged and building
[15:10] <tdaitx> - triage openjdk 7 to check which bugs have been fixed by icedtea 2.7
[15:10] <tdaitx> - get some comments and endorsements for my core dev application
[15:10] <tdaitx> - verify OpenJDK 6 TLS patch (LP: #1482924)
[15:10] <tdaitx> Waiting/On hold
[15:10] <tdaitx> - waiting OCA to submit webrevs for 7093640 backport (set TLS 1.1 as default for JDK 6 and TLS 1.2 as default for JDK 7); not blocking anything for now, just waiting
[15:10] <tdaitx> (done)
[15:10] <bdmurray> submitted RT regarding updating apport on staging, prod retracers x 2
[15:10] <bdmurray> discovered and fixed Traceback with apport on production retracers
[15:10] <bdmurray> fixed different apport traceback with -dbgsym packages
[15:10] <bdmurray> rewrite of cql async query for failed to retrace bucketing
[15:10] <bdmurray> confirmed that we are retracing less foreign origin packages on 12.04
[15:10] <bdmurray> fixed privacy issue with LP: #1494361
[15:10] <bdmurray> update meta-release-proposed file for LP: #1497024
[15:10] <bdmurray> updated meta-release files for the ubuntu-release-upgrader in vivid-updates
[15:10] <bdmurray> T, V SRU verification of LP: #1497024
[15:10] <bdmurray> T, V SRU verification of LP: #1498193
[15:10] <bdmurray> irc discussion re fix for LP: #1498697 (rejected upload in the queue)
[15:10] <bdmurray> rls-w bug review
[15:10] <bdmurray> uploaded update-manager fix for LP: #1215114
[15:10] <bdmurray> uploaded ubuntu-release-upgrader fix for LP: #1313514
[15:10] <bdmurray> tested and uploaded a fix for whoopsie bug LP: #1389357
[15:10] <bdmurray> retrace of autofs crash bug LP: #1503034
[15:10] <bdmurray> reported ubiquity LP: #1503441 regarding installer crashing with a 8GB install
[15:11] <bdmurray> research into and uploaded ubuntu-release-upgrader fix for LP: #1502529
[15:11] <bdmurray> ✔ done
[15:11] <pitti> bdmurray: thanks for the -dbgsym fix, that also was the one breaking the tests
[15:11] <bdmurray> pitti: Ah, I didn't see that test failure.
[15:11] <doko> tdaitx, wait, is 2.7-preXX meant to be the next release, not 2.6.2?
[15:11] <pitti> bdmurray: I didn't get it locally either, but during the CI autopkgtest run
[15:12] <bdmurray> pitti: Is there a way to subscribe to emails about those?
[15:12] <pitti> bdmurray: not email, just XSS for now (http://autopkgtest.ubuntu.com/data/feeds/a/apport.xml)
[15:12] <pitti> email notifications are coming
[15:13] <slangasek>  * still working on recruiting for the open positions
[15:13] <slangasek>  * discussions about improving the autopkgtest system use with silos and generally
[15:13] <doko> - finish libav/ffmpeg transition, remove libav from wily
[15:13] <doko> - finish libept transition
[15:13] <doko> - backported ppc64el and s390 support for libseccomp
[15:13] <doko> - hdf5 transition
[15:13] <doko> - looking at a python3.4 regression in trusty-updates
[15:13] <slangasek>  * meetings: POWER, s390x
[15:13] <doko> - report a GCC memory hog upstream, found in insighttoolkit4
[15:13] <doko> - fixing build failures
[15:13] <slangasek>  * looking at juju on s390x to figure out if we will have performance problems there like we did on POWER due to memory pressure
[15:13] <doko> - prepared and started the test rebuild, buildd give backs
[15:13] <slangasek>  * trying to figure out the system-image key rotation, it looks like we won't have quorum at the sprint so this will need to be done in London
[15:13] <doko> - one more GCC update
[15:13] <doko> - openjdk-7 and openjdk-8 updates
[15:13] <slangasek>  * reviewed and tested the patches to bug #1439769, to land in wily
[15:13] <doko> - still trying to build gcc-snapshot on all archs
[15:13] <slangasek>  * sprint travel planning
[15:13] <doko> - prepare python-greenlet and valgrind SRU's, validate them
[15:13] <slangasek> (done)
[15:13] <doko> (done)
[15:13] <slangasek> hmm :)
[15:13] <doko> oops
[15:13] <slangasek> cyphermox:
[15:13] <tdaitx> doko, I'm trying to check that with andrew, but he is out this week, anyway I only saw 2.7-pre tags being added
[15:14] <cyphermox> eep, I wasn't quite ready
[15:14] <cyphermox> so;
[15:14] <cyphermox>  - firmware update stuff
[15:14] <cyphermox>  - upload ubiquity-slideshow
[15:14] <cyphermox>  - fixed usb-modeswitch
[15:14] <cyphermox>  - discussions/review for upstart-watchdog fixes
[15:14] <cyphermox> and multipath bugfixes
[15:14] <tdaitx> doko, anyway, he has released both micro and minor releases together in the past
[15:14] <cyphermox> along with random other things, I forget :/
[15:14] <cyphermox> (done)
[15:15] <doko> see above: ^ ^
[15:15] <doko> (done)
[15:16] <slangasek> ok
[15:16] <slangasek> any questions?
[15:16] <slangasek> infinity: maybe you want to discuss the python3.4 SRU
[15:16] <barry> slangasek: key rotation!
[15:16] <caribou> Can someone sponsor LP: #1273462
[15:16] <caribou> that's the bug we discussed extensively a while back
[15:16] <infinity> doko: You missed the conversation barry and I just had on mumble, but I think the sane way forward is to back out that one commit in python3.4 itself, rather than try to fix all the rdeps to cope with it.
[15:17] <infinity> doko: Interface/defaults changes like that aren't particularly SRU-friendly (and there's no guarantee we won't break third-party code, even if we fixed everything we ship in the distro).
[15:17] <barry> infinity, doko i'm going to bring this up as a general point of discussion on the new<EMAIL_ADDRESS>[15:17] <bdmurray> Please have a look at the rls-w-tracking bugs - http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-w-tracking-bug-tasks.html
[15:17] <doko> wait, which commit?
[15:18] <infinity> doko: The bit that changes the behaviour incompatibly. :P
[15:18] <pitti> bdmurray: wow, what happened with the kernel bugs? > 1.500
[15:18] <doko> I'm lost ...
[15:19] <barry> doko: this is for LP: #1500768 and it's related to 3.4.3 changes for PEP 476.
[15:19] <bdmurray> pitti: Its all those CVEs I guess
[15:20] <barry> doko: you might want to join linux-sig if you're not already, or read it via gmane
[15:20] <slangasek> caribou: I'm willing to sponsor bug #1273462 but then I wonder if anyone else will approve the SRU :)
[15:20] <caribou> slangasek: I can ping arges about it
[15:21] <pitti> how about I sponsor, you approve? :-)
[15:22] <doko> barry, there's nothing about this on the ml ... https://mail.python.org/pipermail/linux-sig/2015-October/thread.html
[15:23] <barry> doko: not yet :)
[15:23] <slangasek> doko: are you ok with infinity's suggestion, to back out the behavior change?
[15:24] <pitti> https://xkcd.com/1172/
[15:24] <doko> slangasek, I didn't nail it down to a single commit yet. so if he has the commit, that's fine. however reverting the whole pep commit is probably not the right solution
[15:25] <barry> i don't know which commit it is
[15:25] <infinity> doko: Oh, I was using "commit" in the abstract sense, I don't have a pointer, sorry.
[15:26] <infinity> doko: But if it's just a default flag being inverted, as barry suggests, it should be a 1-liner to revert the behaviour, I'd hope.
[15:26]  * doko goes back to work on that
[15:26] <infinity> (But, y'know, python, so who knows)
[15:26] <slangasek> doko: ok.  as various folks have pointed out, rolling back the package from -updates doesn't help the users that have already upgraded over the two weeks that the package was in -updates; so if we're all agreed that reverting this change is a sensible path forward, and if you can prioritize working on it, that would be excellent
[15:26] <doko> sure
[15:26] <slangasek> thanks
[15:26] <barry> thanks
[15:27] <doko> one more thing, ftbfs ...
[15:27] <doko> there are still plenty ...
[15:27] <infinity> barry, doko: I don't think identifying "the commit" is all that important, if you can find the magic 1-liner required to invert the default and that fixes the problem, yay.
[15:27] <slangasek> [TOPIC] Releees
[15:28] <barry> pep 476 has more information in the Implementation section
[15:28] <slangasek> doko: current pointer for the ftbfs list?
[15:28] <cyphermox> we have a scary werewolf in the slideshow since today.
[15:28] <slangasek> there's http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20151001-wily.html
[15:29] <slangasek> which doesn't have many interesting packages on it; there's some GL package I've never heard of failing to build on two architectures? glibc, anyone heard of it?
[15:29] <bdmurray> cyphermox: do you have a link to the scariness?
[15:29] <infinity> cyphermox: Oh, did you do my usual gimping?  Should I review it? :P
[15:29] <cyphermox> bdmurray: just a sec; fetching the werevervet.
[15:30] <cyphermox> ftbfs are more important though ;)
[15:30] <infinity> slangasek: The glibc failures are probably just some racy tests, but I'll look.
[15:30] <pitti> slangasek: yes, I think the other day the kernel warned me while it saw a double-free that it detected a glibc; that glibc thingy is likely the culprit!
[15:30] <cyphermox> bdmurray: http://bazaar.launchpad.net/~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html/revision/719
[15:30] <slangasek> doko: fwiw shim is on that list and will be fixed the next time we need to upload shim for other reasons and not before
[15:31] <slangasek> pitti: these people and their newfangled GL extensions
[15:31] <doko> slangasek, ok, I'll make a note
[15:31] <doko> and there are packages stuck in -proposed ... http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[15:31] <slangasek> yaboot ftbfs, solution: remove it from main
[15:31] <infinity> Ahh, yeah, both those glibc tests are known-flaky.  Need to fix those upstream once and for all.
[15:32] <infinity> yaboot it on my hitlist, but I failed to find time to switch ppc to grub this cycle.  Maybe I can do it before release for kicks. :P
[15:32] <cyphermox> doko: I'll look at shim when I get to upload it next, I guess. the bug is already assigned to me.
[15:33] <pitti> doko: did all of these build just once, or twice? i. e. is it still likely to find a lot of flakiness there, or are these more or less "stable" failures?
[15:33] <pitti> I've seen a lot of "please retry foo" requests on IRC recently
[15:33] <pitti> not that they wouldn't be important to fix, but I guess they are a bit less urgent than the stable FTBFS
[15:33] <doko> pitti, look at the build date. main finished around Oct 3
[15:34] <slangasek> pitti: if they've built at all they're considered good for these purposes.  Given the number of consistently-failing builds, getting flaky builds to be non-flaky isn't the priority
[15:34] <doko> I can give back the amd64 and i386 builds, sure
[15:34] <barry> that's part of the problem, and i saw it repeatedly in the py35asdefault ppa.  one fix can cascade a bunch of other fixes if you do a mass retry
[15:34] <pitti> right; I wonder about e. g. https://launchpadlibrarian.net/219449079/buildlog_ubuntu-wily-i386.gnutls28_3.3.15-5ubuntu2_BUILDING.txt.gz
[15:34] <infinity> slangasek: Oh, ouch, that yaboot explosion is actual work to fix.  e2fslibs forced a sad.
[15:34] <pitti> such things (failure of one test case named "mini-loss-time") certainly smell flaky-ish
[15:35] <slangasek> infinity: grub!
[15:35] <infinity> slangasek: On the flip side, yaboot has never had a CVE in the history of ever, so still low prio to care if it builds. :P
[15:35] <slangasek> more important question, why are there ruby packages in the core packageset
[15:35] <infinity> slangasek: grub2 is definitely the right answer, though.  I need to sidegrade my PowerStation to grub from yaboot and make sure that's working before I try to flip the installers/ISOs/world.
[15:36] <infinity> (Also need to hunt down community people with Macs, since Apple's OF is far more likely to break than the SLOF on my machine)
[15:37] <doko> next time I'll do the test rebuild as a group, so that more people can give back build
[15:37] <doko> s
[15:37] <slangasek> barry: looking at http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20151001-wily.html#core there's really not a whole lot of cascading to be done fwiw
[15:37] <slangasek> doko: you just need to rope the TB members into doing the give-backs for you, apparently
[15:38] <doko> heh
[15:38] <pitti> slangasek: wow, ruby-flexmock is in the extra seed
[15:39] <pitti> oh, gem2deb is in main
[15:39] <pitti> that probably pulls in tons of stuff
[15:39] <slangasek> pitti: "in main" != "in the core packageset"
[15:39] <doko> I already remove a lot of deps from gem2deb
[15:40] <infinity> slangasek: "in the core packageset" just means it's an intersection of more than one flavour.  Which is likely, if ruby is being trasitively pulled in by something lowish in the stack.
[15:40] <slangasek> infinity: gem2deb isn't low in the stack, ruby has only ever been in main because of server
[15:40] <slangasek> and chef+puppet
[15:40] <doko> yes, still need write that email ...
[15:41] <slangasek> :)
[15:41] <pitti> those, and xapian-bindings
[15:41] <pitti> and subversion
[15:42] <doko> I don't think we can remove the whole ruby from main, even if we demote chef+puppet
[15:42] <slangasek> I'm not sure why subversion is in main either
[15:42] <slangasek> anyway
[15:42] <slangasek> ftbfs bugs
[15:43] <slangasek> people will work on them yes?
[15:43] <doko> pitti, gnutls ftbfs persists
[15:43] <barry> yes
[15:43] <infinity> All popular version control systems were in main pretty much since Ubuntu's inception.
[15:43] <doko> just mention on #ubuntu-devel which one you are starting to work on ...
[15:43] <infinity> Might be worth revisiting now that the world has (mostly) settled on git as the winner.
[15:43] <pitti> slangasek: that finally is something which we can change -- it's still in supported-development seed, probably for hysterical raisins?
[15:43] <barry> +1
[15:43] <pitti> slangasek: it might have made sense in 2005, but probably not any more
[15:44]  * pitti sighs reading/tracking germinate output
[15:44] <pitti> and it's not like it'd go very far if we demote it
[15:44] <pitti> oh dear, we still have *cvs* in main
[15:44] <slangasek> yes, I think I suggested culling subversion already a while back; though I guess one of the git bridges might care about it
[15:45] <pitti> (seeded)
[15:45] <pitti> but not tla -- outrageous!
[15:45] <infinity> pitti: Right, CVS was there for the same reason.
[15:45] <infinity> pitti: tla was dropped like a hot potato when bazaar happened, because reasons.
[15:45] <barry> infinity: can you add RCS support please?
[15:46] <infinity> barry: If you have CVS, you have RCS.  Oh, except not, it's only a suggests.
[15:46] <pitti> ah yes, git build-deps on cvs argh
[15:46] <infinity> barry: But, really, CVS is just a "user-friendly" RCS. :P
[15:46] <pitti> so even unseeding it wouldn't help
[15:46] <infinity> For some definition of "friendly".
[15:46] <barry> probably "less user-antagonistic"
[15:47] <infinity> pitti: We waste exactly zero effort on "maintaining" CVS, so it doesn't really matter.
[15:47] <infinity> SVN is a bit more of a time suck, but then there's the discussion of "would we really stop maintaining it just because it's in universe?"
[15:47] <slangasek> I don't think we need to loop over the germinate output in realtime here
[15:47] <slangasek> [TOPIC] AOB
[15:47] <slangasek> anything else today?
[15:47] <barry> monday is a usa holiday but i will probably swapday it
[15:48] <cyphermox> yeah. monday holiday in Canada too.
[15:48] <slangasek> ah, I'm taking my holiday, don't want to miss out on that Canadian cranberry sauce
[15:48] <cyphermox> I don't think Catou will want me to swap it
[15:48] <infinity> slangasek: Just want to resolve the cyphermox/sprint thing before we forget.  Should we take that to mumble?
[15:48] <cyphermox> slangasek: make your own!
[15:49] <infinity> And I'll probably take Monday off to go cast a few dozen votes against Harper.
[15:49] <cyphermox> cranberry sauce is so easy and delicious to make :)
[15:49] <slangasek> infinity: we should take it to post-meeting, at least
[15:49] <infinity> Yay, advanced polls.
[15:49] <cyphermox> infinity: oh, good plan.
[15:49] <infinity> cyphermox: Yeah, if you're sprinting, you'll miss the election, so do vote this weekend. :)
[15:50] <cyphermox> too bad I was planning to go up north this weekend :/
[15:51] <cyphermox> I don't have any OB.
[15:52] <slangasek> #endmeeting
[15:52] <meetingology> Meeting ended Thu Oct  8 15:52:12 2015 UTC.
[15:52] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2015/ubuntu-meeting.2015-10-08-15.02.moin.txt
[15:52] <slangasek> thanks, all!
[15:52] <caribou> thanks slangasek !
[15:52] <barry> thanks!
[15:52] <pitti> thanks everyone


[23:07] <stgraber> cjwatson: I'm going to bed now but I had a quick look at my bugmail and spotted bug 986806, not sure if it's a regression caused by the recent changes in that area or just an old bug I only heard about now.
[23:07] <ubot2> Launchpad bug 986806 in ubiquity "swap not activated after choosing 'use whole disk'" [Undecided,New] https://launchpad.net/bugs/986806
[23:11] <cjwatson> ugh, quite possibly
[23:11] <cjwatson> too tired to look tonight really and I'm still looking into LP distroseries initialisation - I'll have a look tomorrow
[23:12] <stgraber> sure, good night


[01:52] <slangasek> ^^ this gets the cross-compiler in sync with gcc-4.7-source for release, which is probably a good idea; I actually want them in sync to try to pin down an issue where gcc-4.7 is reportedly behaving differently for certain code for native vs. cross building
[01:53] <slangasek> (and the native compilation is giving buggy results, but that's beside the point... we don't know that the compiler itself is at fault)
[01:54] <slangasek> oh, is the final freeze still advisory for universe? ok then
[03:03] <darkxst> Is there some reason that there arent yet Ubuntu GNOME RC builds?
[03:05] <infinity> darkxst: We created the milestone, and are just letting them cron in at their usual time.
[03:06] <infinity> darkxst: Which for ubuntu-gnome, appears to be 15:32 UTC...  A bit of a wait.
[03:06] <infinity> darkxst: I can do a manual spin for you, if you have confused testers.
[03:08] <infinity> darkxst: Spinning you a set now.
[04:40] <darkxst> infinity, thanks ;)
[04:51] <ScottK> infinity: Thanks.
[06:04] <infinity> Can someone do a quick review of that gdb upload I just made?
[06:33] <slangasek> infinity: doh - right, I forgot about the efi binary new, didn't I
[06:33] <slangasek> infinity: gdb> looking
[06:33] <slangasek> or not
[06:49] <infinity> slangasek: Does anything read /lib/init/fstab other than mountall, and ever before /etc/groups is available?
[06:50] <slangasek> infinity: well, I had a conversation with stgraber and hallyn about possibly making lxc read it, but no.  Also, how can /etc/group ever not be available?  /etc must be on the rootfs
[06:50] <infinity> slangasek: Well, it could be unavailable if something pulled that file and mountall into an initrd, for instance.
[06:51] <infinity> slangasek: (Which doesn't ever happen currently, I assume?)
[06:51] <infinity> slangasek: Anyhow, was just asking because of the "gid=tty" instead of "gid=5" in there, which would go awry if one couldn't resolve "tty" to anything useful.
[07:03] <slangasek> infinity: yes, no mountall in initramfs
[07:04] <infinity> I'm beggining to think maybe I should revert the pt_chown change for now.
[07:04] <infinity> And maybe fix mount to add gid=5,mode=0620 to the "defaults" set.
[07:05] <infinity> There's this curious feature where, even if your base system is booted and mounted correctly, if you "mount -t devpts devpts-foo foo/", all instanced of devpts (including the base system) pick up the new defaults.
[07:05] <infinity> And lose the gid/mode bits.
[07:05] <infinity> Which has always been true, but then pt_chown picked up the slack for this misconfiguration in the past.
[07:09] <infinity> slangasek: On the other hand, Fedora already pushed this out as a security update a couple of months ago, and basically said "if stuff breaks, mount /dev/pts correctly, derp" in their announcement. :P
[08:27] <didrocks> infinity: if you are still around, the mir one is for this touch image ^ (it's just a build-dep of xorg, but the fix is for touch only), not seeded anyway
[08:28] <shadeslayer> stgraber: poke poke
[08:28] <infinity> didrocks: I'm not here, and you can't prove it.
[08:29] <infinity> didrocks: Oh, also: congrats.  Where was my invite? :)
[08:29] <didrocks> infinity: ahah, thanks a lot! :-)
[09:29] <ogra_> hey, i accidentially triggered an ubuntu-gnome build, hope i didnt cause havoc with this
[09:32] <cjwatson> slangasek: Probably ought to be changed, yes.  Can you file a bug and I'll do it next cycle?  I don't think I should mess with it now for 13.10
[09:35] <infinity> ogra_: They'll probably live.  There's going to be a cronned one today too, anyway.
[09:39] <xnox> infinity: well i have two installer bugs fixed now, and if/when ubiquity upload will happen today. I'd love to respin all ubiquity images and test them before departing for the weekend.
[09:39] <xnox> unless too late.
[09:40] <infinity> xnox: Not too late.  I'm sure this won't be the last installed upload of the cycle (though one can always hope).
[09:40] <infinity> s/installed/installer/
[09:40] <infinity> xnox: The freeze pretty much explicitly doesn't apply to installers, since this is when we get all the good/juicy bugs.
[09:42] <xnox> infinity: oh and base-files are not in yet, so yeah we will be respining =)
[09:42] <infinity> Indeed, I'll upload that on the weekend, probably.
[09:43] <infinity> Or maybe today sometime.
[09:43] <infinity> Since I lost a bunch of my weekend to flying in the wrong direction.
[09:43] <infinity> Silly timezones.
[10:19] <Mirv> ↑ and ↓ indicators + unity stacks, fully tested on desktop, best autopilot results ever so seems pretty nice. indicators also tested on touch (manually) for the parts that are affected.
[10:20] <Mirv> of course the best AP tests comes down to unity7 team fixing AP false alarms, but still, makes for nicer numbers
[10:21] <mhr3> Mirv, so are there any issues with landing it?
[10:22] <Mirv> mhr3: not that I know of, as mentioned good AP results, manual testing on touch fine.
[10:23] <mhr3> Mirv, cool, pls ping me if there's any problem with it
[10:23] <Mirv> mhr3: sure. if release team has any worries, they'll tell us here.
[10:30] <asac> cjwatson: http://paste.ubuntu.com/6221814/
[10:31] <asac> those are components that didnt make it it seems.
[10:31] <asac> cjwatson: what are the options? what do you need from us?
[10:34] <cjwatson> It was only 15 minutes ago :)  I'll review
[10:34] <asac> cjwatson: ok cool. let me know. especially if we need to divert one of those to -updates or wait much longer
[10:34] <asac> thanks
[10:35] <cjwatson> (I'm mostly fixing a problem with the publisher right now, so if anyone else can help ...)
[10:35] <asac> cjwatson: what kind of help? I assume that is "anyone from release team"?
[10:35] <cjwatson> Yes
[10:35] <cjwatson> asac: Is ido one of yours as well?
[10:35] <asac> cjwatson: so thats all that is comnig from CI
[10:35] <asac> we unfortunately have still desktop stuff in CI
[10:35] <asac> fortunately actually, but in this case a bit awkward
[10:36] <asac> asking didrocks
[10:36] <seb128> ido has a desktop bug fix
[10:36] <seb128> it doesn't impact touch
[10:36] <asac> cjwatson: ido is also coming from CI, but its pure desktop only
[10:36] <cjwatson> seb128: Do you know if the fix in ido affects anything in screenshots?
[10:37] <cjwatson> It's fine otherwise
[10:37] <seb128> cjwatson, it means the indicator-session avatar icon being properly aligned if you use a non default font size
[10:37] <seb128> I doubt we have any screenshot of the bug
[10:37] <cjwatson> Ah, so not screenshots
[10:37] <asac> so yeah we missed ido
[10:37] <seb128> means->makes
[10:37] <seb128> asac, I'm glad you uploaded it :p
[10:37] <seb128> that bugs annoys me ;-)
[10:38] <seb128> asac, btw "unfortunately have still desktop stuff in CI" ... does it mean you plan to drop CI for desktop components?
[10:38] <seb128> cjwatson, thanks
[10:41] <Daviey>  /37
[10:57] <cjwatson> asac,didrocks: all accepted now
[10:57] <didrocks> cjwatson: thanks a lot :) one worrying things less :)
[10:57] <asac> cjwatson: awesome!
[10:57] <asac> what an amazing day
[10:57] <asac> i will have to buy flowers for my wife still :P
[10:58]  * asac puts that on his "nice to have TODO list" :)
[10:58] <didrocks> asac: "nice to have" only?
[10:58] <didrocks> I think qtdeclarative-opensource-src is unseeded, right?
[10:58]  * didrocks checks
[10:59] <cjwatson> can't be unseeded if it's in those packagesets
[10:59] <cjwatson> but it looks fine, is it OK from the touch POV?
[10:59] <didrocks> cjwatson: yeah, it's fixing the "unity8 is taking 100% of GPU" :)
[10:59] <didrocks> CPU*
[11:00] <didrocks> thanks colin!
[11:00] <didrocks> ok, now touch-only uploads, all tested, fine, let's publish them
[11:01] <asac> didrocks: yeah i should prioritze that more appropriately :)
[11:03] <didrocks> heh
[11:12] <cjwatson> infinity: Did you retry the failures due to lp-buildd vs. pt_chown?
[11:13] <infinity> cjwatson: The one or two I knew about.  Were there many?
[11:13] <cjwatson> I only knew of the ones you told me about :-)
[11:14] <infinity> Fair.  I did those. :P
[11:44] <Mirv> thanks seb128 cjwatson asac didrocks :)
[11:45] <Mirv> I even got to eat proper food today, so I'm even more happy
[11:46] <didrocks> Mirv: lucky you! :)
[11:48] <seb128> Mirv, yw ;-)
[13:16] <jamespage> openstack just pushed out a second rc for glance with a number of critical and high bug fixes - zul preparing and reviewing now
[14:07] <zul> glance
[14:07] <zul> oops
[14:43] <didrocks> I think platform-api is what is freezing location-service ^
[14:45] <xnox> ubiquity ^ diff will be large, but it's really one bugfix per commit on lp:ubiquity. Also note that majority of the diff is debconf-updatepo, which means unfortunately that many strings were not possible to translate up to now.
[14:48] <shadeslayer> cjwatson: any reason why kubuntu-active ISO's aren't built?
[14:51] <didrocks> (thanks to whoever accepted location-service ;))
[14:51] <infinity> shadeslayer: I believe kubuntu-active was marked disabled in the ISO tracker, because someone didn't want them to be in milestones/release.  Has that position changed?
[14:53] <infinity> shadeslayer: Active wasn't in any of the alphas or betas, only dailies.
[14:53] <cjwatson> shadeslayer: check the build failures
[14:53] <cjwatson> shadeslayer: it's been failing for a while
[14:53] <shadeslayer> I don't know where :(
[14:53] <cjwatson> I hadn't had a chance to look
[14:53] <infinity> Oh, did you literally mean "not built" rather than "not posted to the tracker"?
[14:53] <cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/ somewhere
[14:54] <shadeslayer> infinity: yes
[14:54] <shadeslayer> ahhh
[14:54] <shadeslayer> contour
[14:54] <shadeslayer> cjwatson: infinity could you trigger a build now?
[14:54] <shadeslayer> should be fixed
[14:55] <cjwatson> as of when?  today?
[14:55] <shadeslayer> I pushed fixes early today
[14:55] <shadeslayer> https://launchpad.net/ubuntu/+source/plasma-mobile/1:0.5-0ubuntu2
[14:55] <cjwatson> doing
[14:55] <shadeslayer> thx
[14:56] <infinity> I don't see how that would fix it.
[14:57] <infinity> shadeslayer: If both contour and plasma-active are being installed, you've not improved the situation by adding an unversioned Breaks.
[14:57] <shadeslayer> infinity: contour is no more
[14:57] <shadeslayer> dropped it from the seed
[14:57] <shadeslayer> removed from archive
[14:57] <shadeslayer> https://launchpad.net/ubuntu/+source/kubuntu-meta/1.291
[14:58] <shadeslayer> https://launchpad.net/ubuntu/+source/contour/+publishinghistory
[14:58] <cjwatson> I guess we'll find out
[14:58] <infinity> shadeslayer: Ahh, that was a bit more informative than the plasma-mobile link. ;)
[14:58] <shadeslayer> :)
[14:59] <shadeslayer> sorry about only providing half the info
[15:18] <lool> Hey, I've added a block ubuntuone-credentials hint to test it while it's in -proposed (it's not under cu2d CI)
[15:18] <lool> (dobey is the uploader and has tested it "upstream" / in trunk)
[15:18] <lool> (it's only seeded in touch)
[15:19] <cjwatson> thanks
[15:33] <xnox> stgraber: updating ubuntu-meta does "* Added shotwell to desktop-recommends [powerpc]" yet i was just removed "* Removed shotwell from desktop-recommends [powerpc]" by your last upload. is that correct?
[15:36] <cjwatson> xnox: Looks like it was removed from powerpc at one point and then restored
[15:36] <xnox> cjwatson: ok. uploaded.
[15:36] <cjwatson> maybe?
[15:37] <xnox> it's recommends and powerpc.... maybe it was removed/FTBFS at the time of last upload?!
[15:37] <cjwatson> Yeah, https://launchpad.net/ubuntu/saucy/powerpc/shotwell, deleted from release entry #7
[15:38] <xnox> cjwatson: otherwise it's a FTBFS fix.
[15:38] <dbarth> hi
[15:38] <lool> 17:36 -queuebot:#ubuntu-release- Unapproved: ubuntuone-credentials (saucy-proposed/universe) [13.10-0ubuntu1 => 13.10-0ubuntu2] (ubuntuone)
[15:38] <lool> what does the ubuntuone package set mean?
[15:38] <lool> does it have special rules for reviews or something?
[15:38] <cjwatson> I think it's for upload perms
[15:38] <dbarth> can i bring the case of bug #1206268 to your attention again
[15:38] <ubot2> Launchpad bug 1206268 in webbrowser-app (Ubuntu) "[MIR] unity-webapps-qml" [Undecided,Fix committed] https://launchpad.net/bugs/1206268
[15:39] <xnox> don't think so, just uploads perms & release-bug tracking / owners.
[15:39] <mterry> Heyo folks!  There is a change that dbarth and folks would like to make to the ubuntu-sdk package.  ^ This would involve dropping a Recommends from that seed, and then changing qtmultimedia to stop building a certain package only referenced by the sdk metapackage.  How doable is that (we have branches, just looking for approval) at this stage?
[15:40] <xnox> mterry: are all changes required reviewable somewhere? is it all the branches attached on the bug report?
[15:40] <xnox> mterry: can you comment links with merge proposals against seeds and/or all packages involved?
[15:40] <xnox> (comment on the bug that is)
[15:41] <lool> stgraber: There might be some possible improvements to the autoaccept script if you like to: ubuntuone-credentials is only seeded in touch, but is stuck in queue because it's in a special upload packageset (ubuntuone)
[15:41] <xnox> cause it's hard to see what the scope of changes is....
[15:41] <mterry> xnox, sure.  let me link
[15:41] <stgraber> lool: I'll whitelist that one
[15:42] <dbarth> mterry: should Mirv also comment on the bug directly, with the plan he proposed earlier in the thread?
[15:42] <lool> stgraber: thanks
[15:43] <stgraber> lool: added to whitelist now
[15:43] <ogra_> can someone please let livecd-rootfs through ?
[15:44] <ogra_> (first is adding click packages to the manifest, second is a fix for a serious touch bug)
[15:45] <mterry> dbarth, the plan is basically "land these three branches"
[15:45] <stgraber> looking
[15:45] <mterry> xnox, three branches added to bug in comments
[15:47] <mterry> robru, ^ btw
[15:47] <stgraber> ogra_: I'm a bit concerned by that manifest change, won't that break Ursinha's script and anything that expects packages listed in the manifest to be avaiable from the archive?
[15:47] <ogra_> stgraber, it wont break my script, Ursinha's is still not merged afaik
[15:47] <ogra_> stgraber, and jibel picks his data from my location
[15:48] <ogra_> stgraber, in any case we need that info in the manifest
[15:48] <stgraber> well, I'd argue we should have a separate manifest file for click
[15:48] <ogra_> sure, we can do that later
[15:48] <stgraber> cjwatson: I'd like your opinion on this if you have a minute?
[15:49] <ogra_> stgraber, this is the quick variant to get it in before release
[15:49] <ogra_> stgraber, i'l happily teach cdimage about a new file and how to publish it in T
[15:49] <cjwatson> stgraber: I recommended the approach ogra_'s taken - I think manifest consumers should be prepared for the packages to be either .deb or .click
[15:50] <dbarth> mterry: right
[15:50] <cjwatson> If it breaks anything then surely it'll be straightforward to fix
[15:50] <cjwatson> try: except:
[15:50] <ogra_> the format is the exact same too
[15:50] <stgraber> cjwatson: is there an easy way for something reading the manifest to determine whether it's a .deb or .click?
 <version>
[15:50] <cjwatson> stgraber: "does it exist in the archive as a .deb"
[15:51] <cjwatson> I mean, it has to go looking for the changelog anyway, it can just check, no?
[15:51] <ogra_> stgraber, most likely the namespace will be com.ubuntu.foo.bar.*
[15:51] <cjwatson> ogra_: that's definitely not a reasonable thing to check for in the consumer
[15:51] <cjwatson> if it would be helpful to prefix the package name with "click:" or something, that would be possible
[15:51] <stgraber> sure, it's just going to be tricky to know whether something is a click package or a package coming from a PPA (even though we're not supposed to ever use PPA, the past as showed that we sometimes do)
[15:52] <cjwatson> I dunno, I guess a separate file would be possible, I'd just like to avoid a proliferation of output files
[15:52] <cjwatson> I think it's confusing
[15:52] <ogra_> in any case a separate file is nothing for the week before release imho
[15:52] <stgraber> I think I'd be fine with a click: prefix as it shouldn't break ogra_'s script and will let other parsers easily detect click and either act on it or ignore them
[15:52] <ogra_> i dont want to do big plumbings in cdimage that close to release
[15:56] <stgraber> xnox: do we really have to introduce a new string in ubiquity that close to release?
[15:57] <stgraber> xnox: hmm, well, it doesn't really matter since none of the ubuntuone strings were translated anyway... I guess it's going to be one of those releases...
[15:57] <xnox> stgraber: note that none of the other strings introduced this cycle in ubiquity didn't make it into .pot and were not translated due to not running debconf-updatepo this cycle at all. So in fact I am introducing new strings anyhow in that plugin.
[15:58] <ogra_> stgraber, so do you let it in ? i urgently need the second fix
[15:58] <ogra_> oh
[15:58] <xnox> stgraber: it only affects ubuntu images, as nobody else seeded ubiquity-ubuntuone plugin.
[15:58]  * ogra_ notes the mail
[15:58] <ogra_> sigh
[15:58] <stgraber> ogra_: I'll accept your /system/bin/sh change and reject the other
[15:58] <ogra_> k, thanks :)
[15:58] <xnox> stgraber: yeah, it is shame that translations will be bad..... (note U1 api only returns back errors in english =/ )
[15:59] <stgraber> ogra_: hmm, actually I can't since you stacked the /bin/sh one on top of the manifest one... (I was hoping it was the other way around and I could simply pull the old one from the reject queue)
[15:59] <stgraber> ogra_: if you re-upload adding a click: prefix to the manifest entries, I'll accept it. Alternatively, just upload the /bin/sh fix and I'll accept that.
[16:00] <ogra_> ok that has to wait 1h then ...
[16:00] <stgraber> ogra_: why?
[16:00]  * ogra_ has meetings now
[16:00] <stgraber> ah ok
[16:00] <ogra_> i'll re-work the click part ...
[16:00] <ogra_> since we need that
[16:00] <stgraber> thanks
[16:01] <ogra_> (i doubt any of the scripts can handle columns in the package name though)
[16:01] <stgraber> ogra_: ping me once it's back in the queue if I don't notice and I'll make sure it's reviewed quickly
[16:01] <stgraber> ogra_: well, either they really care about the source name existing and they'll fail either way or they don't and a click: prefix won't make any difference
[16:07] <cyphermox> ^ didrocks: signon-ui as requested
[16:07] <stgraber> I'm reviewing it now
[16:07] <cyphermox> stgraber: thanks
[16:09] <ogra_> stgraber, cjwatson http://paste.ubuntu.com/6223092/ does that look ok to you ?
[16:10] <alex-abreu> cyphermox, is the ball rolling for webbrowser-app ?
[16:10] <stgraber> ogra_: did you mean "while read line"?
[16:11] <cyphermox> alex-abreu: best I can tell you is it *did* for image 94, I don't know more
[16:11] <ogra_> stgraber, not really, i tested that variant locally
[16:11] <stgraber> ogra_: hmm, actually, both do the same, ignore me ;)
[16:11] <ogra_> but i can tiurn it into a while loop :)
[16:11] <stgraber> it's just the first time I see it done with for I believe ;)
[16:11] <ogra_> stgraber, heh, now that i think about it, me too :P
[16:12] <stgraber> ogra_: anyway, yes, that looks good to me
[16:12] <ogra_> great, committing and uploading 2.194 then
[16:13] <stgraber> ogra_: you know that you can just squash all the changes and upload 2.192 right? as none of those got accepted into the archive
[16:13] <stgraber> cyphermox: are you familiar with the actual changes in that upload?
[16:13] <ogra_> stgraber, i'm to lazy to roll back the bzr branch
[16:13] <stgraber> ogra_: ok :)
[16:13] <ogra_> its upstream committed
[16:13] <ogra_> :)
[16:14] <cyphermox> stgraber: I tested that you could still create accounts and such, and ran the autopilot tests
[16:14] <stgraber> cyphermox: I'm not entirely confident that this is a bugfix only upload based on the wording of the changelog and the number of qml changes, does that upload cause any kind of user visible change?
[16:15] <didrocks> thanks cyphermox!
[16:15] <cyphermox> stgraber: not that I noticed
[16:16] <cyphermox> didrocks: do you know more? ^
[16:17] <stgraber> it's a bit hard to figure it out from the diff with all of those qml files being renamed/split/merged...
[16:18] <stgraber> ogra_: just to confirm, that click change is in a touch specific section of auto/build, right?
[16:18] <ogra_> stgraber, yep. ubuntu-touch and armhf even
[16:19] <stgraber> ok, thanks
[16:20] <stgraber> ogra_: there you go ^
[16:20]  * ogra_ hugs stgraber
[16:20] <ogra_> thanks :)
[16:21] <cjwatson> ogra_: "for line in read" runs the loop body once with $line set to "read"
[16:21] <cjwatson> ogra_: that needs to be a while loop instead
[16:21] <cjwatson> (I tested this ...)
[16:21] <ogra_> cjwatson, eeek
[16:21] <ogra_> will fix in a minute
[16:21] <cjwatson> $ (echo foo; echo bar; echo baz) | for line in read; do echo $line; done
[16:21] <cjwatson> read
[16:22] <cjwatson> I would be very surprised if any POSIX shell did otherwise
[16:22] <ogra_> http://paste.ubuntu.com/6223144/
[16:23] <didrocks> stgraber: only on touch AFAIK
[16:23] <didrocks> cyphermox: ^
[16:23] <stgraber> ogra_: those don't look prefixed to me
[16:24] <cjwatson> ogra_: that only works at all by sheer coincidence
[16:24] <cjwatson> And indeed will never be prefixed
[16:24] <ogra_> http://paste.ubuntu.com/6223153/
[16:25] <cjwatson> ogra_: What that does is cause the shell to evaluate the output of "click list" as a file name, attempt to redirect stdin from it, and then emit an error message saying that that (ridiculous) file name doesn't exist
[16:25] <cjwatson> ogra_: still broken
[16:25] <cjwatson> ogra_: you need:
[16:25] <stgraber> ogra_: FWIW I tend to prefer: Chroot chroot "click list | while read line; do ...; done
[16:25] <cjwatson> Chroot chroot "click list" | while read line; do ...; done
[16:25] <ogra_> ok
[16:26] <cjwatson> And indeed your second version is broken for the same reason - <"$(...)" is basically nonsensical shell :)
[16:26] <stgraber> right and cjwatson's will actually work since he didn't forget a " :)
[16:26] <shadeslayer> cjwatson: ISO seems to have built \o/
[16:26] <cjwatson> shadeslayer: cool
[16:26] <ogra_> ok, final attempt http://paste.ubuntu.com/6223157/
[16:27] <cjwatson> should work yes
[16:37] <didrocks> thanks stgraber
[17:06] <thostr_> we got a test failure on ppc https://launchpadlibrarian.net/153485520/buildlog_ubuntu-saucy-powerpc.mediascanner_0.3.93%2B13.10.20131011-0ubuntu1_FAILEDTOBUILD.txt.gz
[17:06] <thostr_> however, mediascanner is currently not utilized by any desktop, it's only used for phone where it works
[17:07] <thostr_> so, could we ignore the test error under those circumstances?
[17:07] <cjwatson> We can remove the binaries on powerpc
[17:07] <cjwatson> Sorting that out now
[17:08] <cjwatson> It just needs unity-scope-mediascanner removed too
[17:09] <thostr_> cjwatson: thanks
[17:09] <cjwatson> done now pending the next publisher cycle
[17:13] <stgraber> hmm, interesting, pre-release freeze isn't considered as development by Launchpad?
[17:13] <stgraber> >>> list(lp.distributions['ubuntu'].getDevelopmentSeries())
[17:13] <stgraber> []
[17:14] <stgraber> (I noticed because I had to pass -s saucy to a few of our tools recently and finally got around to checking why)
[17:14] <slangasek> stgraber: correct
[17:18] <cjwatson> stgraber: .current_series
[17:18] <cjwatson> stgraber: I fixed ubuntu-archive-tools for that fairly recently - you may want to update
[17:18] <cjwatson> (r775 last week)
[17:22] <stgraber> cjwatson: haha, I was indeed a bit behind on ubuntu-archive-tools! thanks for the fix
[17:24] <xnox> looks like ubiquity 2.15.23 has landed, can we respin all ubiquity images?
[17:25] <stgraber> we're still on cronned run
[17:25] <xnox> stgraber: i know, but it has so many fixes and duplicate bugs are kept being filed.
[17:26] <xnox> stgraber: can ubiquity images that have already been build today be respun? e.g. ubuntu-desktop at least?
[17:26] <stgraber> xnox: ok, I'll trigger a rebuild of all images listed on the manifest
[17:26] <xnox> stgraber: thanks.
[17:27] <stgraber> done (selected all the desktop images listed under the Final milestone)
[18:04] <rtg> infinity, re: bug #1236666 - should I request a sync ? get the source deb and upload manually, or go away and never mention it again ?
[18:04] <ubot2> Launchpad bug 1236666 in msr-tools (Ubuntu) "[Feature] update msr-tools package to revision 1.3" [Low,New] https://launchpad.net/bugs/1236666
[18:31] <mdeslaur> can I upload a fix for python-xlib? (LP: #1231453, and LP: #1221514). Looks like it's seeded on the edubuntu dvd.
[18:31] <ubot2> Launchpad bug 1231453 in python-xlib (Ubuntu) "get_full_property() throws exceptions" [Undecided,Confirmed] https://launchpad.net/bugs/1231453
[18:31] <ubot2> Launchpad bug 1231453 in python-xlib (Ubuntu) "duplicate for #1221514 get_full_property() throws exceptions" [Undecided,Confirmed] https://launchpad.net/bugs/1231453
[18:34] <mdeslaur> stgraber: ^
[18:35] <infinity> rtg: Sell me on why we want a new version 6 days before release, and what it won't break.
[18:40] <stgraber> mdeslaur: sounds reasonable
[18:40] <mdeslaur> stgraber: thanks, uploaded
[19:34] <rtg> infinity, why is msr-tools in main ? the new 1.3 version doesn't look like it has any compelling new features to warrant uploading right now. 14.04 ought to be soon enough.
[19:35] <infinity> rtg: It's in main for cpu-checker
[19:35] <infinity> rtg: Which, in turn, is in main for qemu.
[19:36] <infinity> rtg: Which is in main because we hate our users and refuse to support Xen.
[19:36] <infinity> QED.
[19:36] <rtg> infinity, ok, I'll take option 3 (i.e., go away)
[19:36] <infinity> rtg: Sure.  It's not modified in Ubuntu, so it'll autosync when we open 14.04.
[19:36] <rtg> yep
[21:05] <jdstrand> infinity: fyi, got approval from #ubuntu-ci-eng for the apparmor upload
[21:05] <jdstrand> infinity: http://paste.ubuntu.com/6224151/
[21:06] <jdstrand> $ apt-cache depends apparmor|grep python
[21:06] <jdstrand>   Depends: python3
[21:06] <jdstrand> before:
[21:06] <jdstrand> $ apt-cache depends apparmor|grep python
[21:06] <jdstrand>   Depends: python
[21:06] <jdstrand> infinity: so, does your comment in #ubuntu-devel mean I can upload?
[21:10]  * jdstrand uploads
[21:11] <jdstrand> if there is a problem, reject it
[21:12] <knome> hmph, apparently ubiquity slideshow translations weren't uploaded since a few weeks.
[21:27] <stgraber> knome: hmm, that's unfortunate... let me do that quickly now
[21:27] <knome> stgraber, cheers :)
[21:42] <ScottK> jdstrand: Seems fine.
[21:42] <stgraber> knome: uploaded
[21:43] <ScottK> Oh, someone got it already.
[21:43] <stgraber> yeah, I did
[21:43] <jdstrand> stgraber, ScottK: thanks! :)
[21:44] <stgraber> ^ that diff will likely be quite massive, it's a translation update from LP, so I'd recommend just checking that I'm not doing anything else :)
[21:45] <knome> stgraber, thanks again! :)
[21:48] <lool> hint-unblocked ubuntuone-credentials (touch only)
[22:11] <slangasek> stgraber: diff looks fine, but is kind of late?  Why didn't the translation updates get done before final freeze?
[22:11] <slangasek> and do we know for sure that we're having another set of images rolled, so that we should definitely accept this now?
[22:19] <slangasek> lool: what unblocking is needed?  the fact that it's touch only means it should go through automatically, and anyway I don't see it uploaded
[22:19] <lool> slangasek: just a followup to: 17:18 < lool> Hey, I've added a block ubuntuone-credentials hint to test it while it's in -proposed (it's not under cu2d CI)
[22:20] <slangasek> lool: ah
[22:20] <lool> slangasek: I did my own blocking and unblocking basically, but wanted to keep the RT in the loop for hints
[22:20] <slangasek> ack :)
[22:28] <stgraber> slangasek: right, we apparently dropped the ball on that one and nobody updated the translations in weeks... knome noticed a bit earlier today
[22:28] <slangasek> stgraber: so we're planning full ISO respins to pick this up?
[22:29] <stgraber> slangasek: we're still running on cron at the moment and infinity is planning to turn off cron probably tomorrow/sunday
[22:29] <slangasek> ok
[22:29] <slangasek> accepting, then
[22:29] <stgraber> thanks
[22:30] <knome> slangasek, ta


[02:53] <dougg3> I reported a crashing bug in caja on bugs.launchpad.net, and it got marked as a duplicate by apport retracing service. But the bug it's a duplicate of is private...how can I provide more info about the bug and check on its fix status if the original report is private?
[03:02] <dougg3> FWIW, my report is here: https://bugs.launchpad.net/ubuntu/+source/caja/+bug/1645944
[04:02] <australopithecus> Hello so I installed ubuntu 16.1 I have a gefore 1070 installed graphics driver 370, and a 6600k intel cpu, my computer is unable to adjust brightness
[04:03] <australopithecus> which is a huge deal breaker for me because I have a laptop
[04:03] <australopithecus> I am unable to find a fix online for this issue I was wondering if one of you would be able to help me
[04:03] <australopithecus> my screen feels like it is frying my eyes
[04:22] <ali1234> dougg3: bug reports are automatically marked private if they contain backtraces because they can reveal private information
[04:24] <ali1234> if it is still private at this point then nobody is working on it, if they were the first thing they'd do is remove the core file and mark it public
[04:40] <dougg3> ali1234: thanks, that makes sense -- is there anything I can do on my end to try to help with the bug then? my particular report contained a description on how to reproduce it, and I feel there's a good chance the original private report may not have been as useful...
[04:40] <ali1234> dougg3: you can remove the core dump and mark it public
[04:41] <ali1234> and maybe unmark it as a duplicate, and write a better title
[04:41] <dougg3> I already marked my bug as public and apport already stripped the core dump
[04:42] <dougg3> I have no idea what the private report's title even is though. :-/
[04:42] <ali1234> next thing to do is probably to forward the bug to upstream developers
[04:42] <dougg3> like create a github issue on the caja github?
[04:43] <ali1234> it was fixed in nautilus?
[04:43] <dougg3> yeah, I helped them track it down in nautilus last year. then I switched to MATE this year after someone made me aware of it, and I'm dealing with the bug again. heh
[04:44] <ali1234> go here and ask them to port over the fix: https://github.com/mate-desktop/caja/issues
[04:44] <dougg3> that's what I was thinking. thanks! is there a way I can prod the ubuntu people to pull the fix back into 16.04 after that? or will it just happen automagically?
[04:45] <ali1234> you can link your launchpad bug report to the upstream bug, and then mark it "fix available" when upstream fixes it
[04:45] <ali1234> but it probably won't speed up getting the fix into ubuntu any
[04:46] <dougg3> ah, got it. well, thanks for the info ali1234. that was very helpful information!
[04:46] <dougg3> I guess I'll just start with the upstream folks and see what happens from there.
[06:55] <zzp> z
[07:57] <baap> crosoft office on ubuntu how to do that
[12:49] <matej_> hi all
[12:51] <matej_> who have raspberyy pi 2
[12:51] <matej_> exit
[13:41] <kly> miaaa
[15:10] <timo_> Someone who uses German Keyboard Layout here/QWERTZ
[16:55] <mate|35298> hi
[18:28] <TwoNotes> I need to get libcursesw.so.6 on my 16.4 RPi3.  apt does not list it.  Is there a way to get it?
[21:19] <slim> why the flag button doesn't work in ubuntu mate like shortcut for search bar
[22:57] <DarkPsydeLord> becaue ctrl + space is usual combo for search bar


[03:21] <tkup> how do you create a /proc/sys entry in a kernel module. proc_register(&proc_root, &my_proc_entry) creates one in /proc
[04:39] <mjg59> BenC: prism54usb is supposed to be moving to softmac
[04:39] <mjg59> BenC: So if we can get that in, it would be great
[04:41] <mjg59> Oh, and prism54softmac seems to drive full prism54 hardware as well
[04:45] <BenC> ah, nice
[04:50] <mjg59> Possibly best to contact Jean-Baptiste to find out what's going on there
[04:51] <mjg59> There's almost no publically available information
[05:04] <mjg59> BenC: Checking Jean Tourrilhes's list, it looks like we have every currently available wireless driver (with the possible exception of the prism54usb stuff)
[05:05] <mjg59> Oh, and the Realtek stuff
[05:05] <mjg59> (Which you pulled because it was broken)
[05:08] <mjg59> Nngh. The Realtek stuff is still some weird other ieee80211 stack derived thing
[05:21] <BenC> great, latest bcm43xx driver seems to be using stuff that isn't available in softmac/ieee80211
[05:21] <mjg59> You're pulling the git tree for that now?
[05:21] <mjg59> (They moved away from mercurial)
[05:22] <BenC> oh, did they?
[05:22] <mjg59> Yeah
[05:22] <mjg59> Might explain it :)
[05:22] <BenC> yeah, definitely
[05:22] <BenC> thanks
[05:25] <BenC> gonna have to go with their daily snapshots...they are following linus tree now
[05:25] <mjg59> Nnngh. The rtl8180 stuff /still/ looks like pain
[05:25] <mjg59> Would probably be easy to port to softmac
[05:29] <mjg59> Gah, fuck, yes.
[05:29] <mjg59> It conflicts with the in-kernel stuff
[05:29] <mjg59> Stupid, stupid thing
[05:53] <mjg59> BenC: Still around?
[05:55] <BenC> yeah
[05:56] <BenC> just updated bcm43xx/softmac drivers on pb to test it
[05:56] <BenC> seems to be ok, but still only stable at 11M
[05:56] <mjg59> BenC: I've figured out a way to deal with rtl8180
[05:56] <mjg59> But I'm not sure you're going to like it
[05:56] <mjg59> Grab the newstack and their custom ieee80211 code
[05:56] <mjg59> Then (and this is the tricky bit)
[05:56] <BenC> sed?
[05:57] <mjg59> sed -i s/ieee80211/rtl_ieee80211/g *.c *.h
[05:57] <mjg59> Indeed
[05:57] <mjg59> It seems to work - their 80211 stack is entirely independent from the kernel one
[05:57] <BenC> well, I could just remove all the EXPORT_SYMBOLS and compile the ieee80211 stack into the module
[05:57] <mjg59> Nnf. Yeah, I guess.
[05:57] <mjg59> I'm not sure if that's any cleaner.
[05:58] <mjg59> Fucking insane.
[05:58] <BenC> so how hacked up is their ieee80211 stack?
[05:58] <mjg59> Not /very/, but it's based on a fairly ancient checkout
[05:58] <BenC> softmac has some hacking in the stock ieee80211 stack now
[05:59] <BenC> but it doesn't appear to break things
[05:59] <mjg59> Nowadays it should just be ported to softmac instead, but that's going to take a little while to look at the driver
[05:59] <mjg59> BenC: Actually, keeping it modular is probably more sensible
[05:59] <mjg59> That way we can get the 8187 (USB) driver as well
[05:59] <BenC> true
[06:01] <mjg59> Now all we need is an Inprocomm driver
[06:36] <mjg59> BenC: Hmm, no. prism54usb still seems to need its own madwifi-based stack.
[06:45] <kozz> BenC: and then in the directory debian/patches? the thing is that that directory do not exist
[06:46] <BenC> kozz: that's because there are no patches, everything is applied in the tree
[06:50] <kozz> right, can I find them somewhere?
[06:51] <BenC> sure, download linux-<IP_ADDRESS>.tar.bz2 and diff it
[06:52] <BenC> there are no seperate patches
[06:52] <BenC> it's all in the tree
[06:56] <kozz> seems like a strange solution, but ok, thanks
[07:21] <mjg59> BenC: Another one for you - http://www.saillard.org/linux/mrv8k/files/
[07:21] <mjg59> (Marvell lala driver, seems to be used on some Asus boards)
[03:16] <zul> heylo
[04:51] <zul> heylo...again
[05:59] <Mithrandir> BenC: *sigh*, my nvidia problem seems to have gone away, magically. :-/
[06:00] <BenC> sweet :)
[06:01] <Mithrandir> I'll see if I can make it come back somehow.
[06:47] <lamont> hrm.. first a word from our sponsors
[06:48] <BenC> lamont: do builds logs for *-security still go to your buildLogs url?
[06:48] <lamont> BenC: no
[06:48] <lamont> never have
[06:48] <BenC> where can I find them?
[06:48] <lamont> ask me or infinity nicely
[06:48] <lamont> the issue is that the -security builds are (generally) embargoed fixes
[06:48] <lamont> hence we don't publish them
[06:49] <BenC> just need to watch linux-source-2.6.{8,10,12} builds I just uploaded
[06:49] <lamont> well, watching never works anyway... - the log only shows up once the build is finished...
[06:49] <lamont> but I can certainly take a gander for you
[06:49] <BenC> well, that's what I meant :)
[06:49] <BenC> probably too soon to see anything
[06:50] <BenC> unless they failed really early
[06:53] <zul> BenC: i have some new crack for you
[06:53] <zul> ill put it in my tree tonight
[06:53] <BenC> ok
[06:54] <zul> just the rt2600 dirver and other bits
[07:30] <lamont> module ipv6 relocation of symbol in6_dev_finish_destroy is out of range (0x3ffeff7c in 17 bits)
[07:30] <lamont> ew
[08:00] <lamont> hppa report: 2.6.15-12.17 + klibc_1.1.16-1ubuntu1 booted.
[08:01] <lamont> BenC: does the ipv6 module get built with a massive (or series of) ld -r commands?
[08:01] <BenC> not sure
[08:01] <lamont> if so, that would explain the problem.
[08:02] <lamont> (binutils borkage for hppa)
[08:02] <BenC> is klibc working for ia64 yet?
[08:03] <lamont> BenC: that's the next test...
[08:16] <lamont> dist-upgrading my ia64 box to dapper is going to work,right???
[08:30] <zul> hehe..
[10:55] <lamont> hrm... ia64 runs elilo at upgrade time, but asks the user (outside of debconf) whether or not to run it.. --> bug
[11:10] <BenC> lamont: elilo needs to be run for update-initramfs too, which is something that doesn't happen right now (probably doesn't for lilo either)
[11:11] <lamont> BenC: it's more that it needs to not ask.
[11:11] <BenC> yeah
[11:11] <BenC> yaboot doesn't ask, it just does
[11:11] <BenC> same with grub


[00:13] <knome> pleia2, hai
[00:13] <pleia2> hello knome
[00:13] <knome> pleia2, what do you think of a xubuntu users group in linkedin?
[00:14] <knome> pleia2, there is already a group, and the creator asked if he could make it "official"
[00:14] <pleia2> if we have someone with linkedin-fu to run it, I think it'd be fine
[00:14] <pleia2> oh great
[00:14] <knome> but...
[00:14] <knome> meh, isn't linkedin for some kind of work-networking stuff
[00:14] <knome> who cares if you *use* xubuntu?
[00:15] <pleia2> I used to run one for the philly lug, but I was really bad at it (I don't log on often and they don't send many email alerts)
[00:15] <pleia2> there is an ubuntu users one, and one for ubuntu members
[00:15] <knome> actually, now the group says "official", but has the old logo too
[00:15] <knome> i'd be more comfortable if somebody from the team was (also) an administrator, like in g+
[00:15] <pleia2> yeah
[00:16]  * knome is not on linkedin, and not joining because of this
[00:16] <pleia2> I can do it if you want, I at least know how
[00:16] <knome> okay, that would be much appreciated
[00:16]  * Unit193 is not on linkedin, and not joining
[00:16]  * pleia2 joins
[00:16] <knome> pleia2, can you be in contact with the admin, and work that out?
[00:17] <pleia2> knome: how did they ask?
[00:17] <knome> pleia2, sec
[00:17] <knome> pleia2, that : https://lists.ubuntu.com/archives/xubuntu-devel/2011-September/007970.html
[00:18] <pleia2> oh, gosh
[00:18] <knome> i know it's way too long since it's sent but...
[00:18] <knome> :|
[00:18] <pleia2> thanks, I'll follow-up
[00:19] <knome> pleia2, ok, thanks
[00:20] <knome> pleia2, if you need help with new logos and so, just send me email with the dimensions you need
[00:22] <pleia2> ok :)
[00:24] <knome> trying to get the mail folders empty and everything documented as work items or just done...
[00:24] <pleia2> you rock <3
[00:25]  * knome blushes
[00:25] <knome> thanks ;)
[00:26] <knome> i'm wondering if there is a way to make the "in the press" -subpages look better
[00:26] <knome> there aren't so many things there anyway
[00:27] <knome> i'm wondering if it was the newest release on the "main page" and the rest in "archive"
[00:28] <pleia2> we did play with that idea
[00:29] <knome> most of the subpages have like 4 items
[00:30] <knome> http://www.webupd8.org/2011/02/gmusicbrowser-to-replace-exaile-in.html <- also, not sure how much sense it makes to archive things like this
[00:30] <knome> especially from both OMG!U! and webupd8
[00:30] <pleia2> it's history, I like it :)
[00:31] <ochosi> :)
[00:32] <knome> so, should i combine the old releases to one page?
[00:32] <knome> i could do that now
[00:33] <pleia2> I dunno
[00:33] <knome> http://xubuntu.org/press/lucid/
[00:33] <knome> that's sad :(
[00:33] <ochosi> but also a long time ago...
[00:33] <pleia2> maybe if we also clean up empty "screenshots" and "screencasts" section
[00:33] <pleia2> s
[00:33] <knome> pleia2, of course.
[00:33] <knome> pleia2, i was thinking of just adding one header per release
[00:33] <knome> (just the release name)
[00:34] <ochosi> http://www.google.at/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CFQQtwIwAA&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3Do7bYs3BN85g&ei=-A3IT5bqF-zT4QTu-YAg&usg=AFQjCNGMCaOqiYXThM_-s4FRPke99c9FVQ
[00:34] <ochosi> sry for that
[00:34] <ochosi> gah
[00:34] <knome> heh. :)
[00:34] <pleia2> knome: like "10.04" ?
[00:34] <ochosi> you could add this screencast: http://www.youtube.com/watch?v=o7bYs3BN85g
[00:34] <knome> pleia2, or "10.04 Lucid Lynx", whichever
[00:34] <pleia2> yeah, 10.04 (Lucid Lynx) is good
[00:35] <knome> k
[00:35] <pleia2> Xubuntu certainly is redundant :)
[00:35]  * knome goes working
[00:35] <pleia2> ochosi: ah, good!
[00:35] <pleia2> knome: ^^ add that one
[00:35] <pleia2> for lucid
[00:35] <ochosi> pleia2: and part 2 of the same screencast: http://www.youtube.com/watch?v=85ElbqlGex0
[00:36] <knome> pleia2, ochosi, will do
[00:36] <ochosi> should we also add this review? :) http://gvxdev.wordpress.com/2010/03/24/xubuntu-lucid-is-disappointing/
[00:36] <knome> lol
[00:36] <ochosi> screenshot tour: http://www.webupd8.org/2010/03/xubuntu-1004-lucid-beta-1-screenshots.html
[00:37] <ochosi> guys, have you even googled before adding the /press pages? :D
[00:37] <knome> ochosi, no.
[00:37] <ochosi> guys _and_ gals, sry
[00:37] <knome> ochosi, that's just migrated from the old website
[00:37] <pleia2> I wasn't around during lucid :P
[00:37] <knome> i'm sure there is loads of pages around the web
[00:37] <pleia2> that "disappointing" review doesn't seem to understand what LTSs are about
[00:37] <knome> the thing why i pasted the wepupd8 link...
[00:38] <ochosi> another video-review: http://www.youtube.com/watch?v=PLDnsDftzMg
[00:38] <knome> is that i don't think we should serve a "google results" page :P
[00:38] <ochosi> and another one: http://www.youtube.com/watch?v=4LnitFybRL0
[00:38] <knome> just gather some meaningful and insightful (even if negative) reviews
[00:38] <ochosi> of old releases??
[00:38] <ochosi> :}
[00:38] <knome> ochosi, of any releases
[00:39] <knome> ochosi, i suppose something like 4-5 articles *is* actually quite fine
[00:39] <knome> ochosi, http://hurr-durr.com/
[00:39] <knome> ochosi, that's for you
[00:39] <knome> that's the best review ever.
[00:40] <pleia2> hah
[00:41] <knome> pleia2, see my point with only linking to a few high-class articles?
[00:41] <Unit193> Ahahaha! Loves it:D :D :D
[00:41] <pleia2> yeah
[00:41] <knome> there's probably a few things we could drop from the current list, but
[00:41] <knome> let's see
[00:41] <pleia2> but I don't think we exclude the more tabloidy ones out of hand, some of their articles aren't horrible :)
[00:42] <knome> yup. but just telling the news isn't something i think we should make people go through on archives ;)
[00:42] <ochosi> knome: did you just want to rickroll/hurrdurr me? :p
[00:42] <ochosi> btw, for 9.10: http://www.dedoimedo.com/computers/xubuntu-9-10.html
[00:43] <knome> ochosi, no, i think; BLEH.
[00:43] <knome> :D
[00:43] <pleia2> knome: fair enough
[00:44] <ochosi> anyway, g2g to sleep
[00:44] <ochosi> night everyone!
[00:44] <knome> ochosi, night!
[00:45] <knome> pleia2, i'll combine the pages first, then if i'm not too tired, quickly check the lists for babble ;)
[00:45] <pleia2> ok :)
[00:46] <knome> eg for hardy, there are two reviews from the same site; pre and final
[00:46] <pleia2> if they have differing content I don't think that's bad
[00:47] <knome> have to see :)
[01:03]  * knome cleans up some dead links too :/
[01:15] <knome> http://xubuntu.org/press/archive/
[01:18] <drc> While perusing the press section, I noticed that http://xubuntu.org/press/precise/ did not have http://www.dedoimedo.com/computers/xubuntu-pangolin.html
[01:18] <pleia2> knome: ok
[01:18] <knome> drc, it did today when i checkeed
[01:19] <pleia2> yeah, I checked when someone sent a mail to the list about it
[01:19] <drc> dud
[01:19] <drc> It does.
[01:20] <pleia2> yeah, it does
[01:20]  * drc need to up the font size again :(
[01:21] <pleia2> looks like I added it when Unit193 mentioned it in -offtopic on May 17
[01:21] <drc> Eyes are too tired to see what is clearly there...time for bed
[01:21] <pleia2> :)
[01:21] <pleia2> good night
[01:29] <knome> pleia2, http://xubuntu.org/press/,
[01:30] <knome> -,
[01:30] <pleia2> knome: hey, looks good!
[01:30] <knome> yeah!
[01:31] <knome> the "Articles about..." header could be more imaginative
[01:31] <knome> like "What are they saying about us?" or sth
[01:31] <knome> doesn't need to say 12.04 at this point
[01:32] <knome> actually, refresh
[01:33] <pleia2> that's good
[01:36] <GridCube> page , not found
[01:36] <GridCube> :P
[02:58] <pleia2> bah, that qa pad isn't loading
[03:00] <Unit193> http://typewith.me/p/xubuntu-qa-20120601 ?  Not really working here either.
[03:00] <pleia2> yeah
[03:01] <Unit193> Secondary browser also fails.
[03:57] <Unit193> Is there a chance that "Midweight" can be put on the website to clearify a little?
[03:59] <Unit193> pleia2: See above when yous get backs?
[04:00] <pleia2> maybe
[08:46] <knome> pleia2, Unit193; weird (pad not working)
[08:46] <knome> works fine for me
[08:46] <knome> but generally, no need for it to work for you ;)
[08:46] <Unit193> Now it's working.
[08:46] <knome> it's just a todo list for me and astraljava
[08:47] <knome> oh bleh, invoies
[08:47] <knome> +c
[08:47] <knome> ;)
[08:47]  * knome pays
[08:47] <knome> it's thee internet
[08:49] <knome> happy june
[09:10] <ochosi> gtk3.6 will really be quite powerful in terms of native theming: http://www.youtube.com/watch?v=gTYUn72Wjyk&feature=player_embedded
[09:10] <ochosi> (or for those of you who prefer to read: http://blogs.gnome.org/cosimoc/2012/05/31/gtk-and-css-updates/ )
[10:27] <knome> looks good, but i agree with the first commenter
[10:27] <knome> i'm afraid many many people will create some really wacky stuff which then breaks and people are crying for help or thinking their pc is bricked or so
[10:42] <ochosi> yup
[10:52] <ochosi> btw, i'm not so afraid of that, people are already doing whacky stuff with the pixmap engine...
[10:57] <knome> ;)
[14:28] <GridCube> ochosi, ping
[14:28] <ochosi> GridCube: pong
[14:28] <ochosi> (don't have much time though)
[14:28] <GridCube> :| im stuck in the same place as yesterday
[14:28] <ochosi> what place is that?
[14:28] <GridCube> ihave to rule out some media players
[14:29] <ochosi> right
[14:29] <GridCube> wich ones should i pick to start the comparisons?
[14:29] <ochosi> what's your current list?
[14:29] <GridCube> listen, exaile, rhytmbox, quodlibet
[14:30] <ochosi> rhythmbox is rather heavyweight
[14:30] <ochosi> what's exaile's current status?
[14:30] <GridCube> i ruled out audacious and decibel because the mediatheque abilities come from plugins and are not preseted
[14:30] <ochosi> last time i checked it was utterly broken
[14:30] <GridCube> i have no idea ochosi :/
[14:30] <ochosi> what about beatbox instead?
[14:31] <GridCube> !info beatbox
[14:31] <GridCube> ^
[14:31] <ochosi> you need to get it from a ppa atm
[14:31] <ochosi> https://www.google.at/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CFYQFjAA&url=https%3A%2F%2Flaunchpad.net%2F~sgringwe%2F%2Barchive%2Fbeatbox&ei=PdLIT9DILseV-wbAu7Vg&usg=AFQjCNFU8ZwI1iGRkFPgoorDKBNnKI-IMw&cad=rja
[14:31] <GridCube> its not in the repos so its not on my list, and no one told me about it before :/
[14:31] <ochosi> gah
[14:31] <ochosi> no problem
[14:31] <ochosi> ppa:sgringwe/beatbox
[14:32] <GridCube> ah, old google's incrediblelongurl.php
[14:32] <drc> ochosi: how was/is exaile broken?
[14:32] <ochosi> also there's xnoise
[14:32] <GridCube> never heard of those
[14:32] <ochosi> sorry guys, i need to run now
[14:32] <GridCube> :)
[14:32] <GridCube> ok thanks you give me more to think
[14:32] <GridCube> :P
[14:32] <GridCube> drc i have no idea
[14:32] <ochosi> GridCube: maybe good to do some more research on potential players ;) (clementine, guayadeque etc...)
[14:33] <ochosi> see y'all
[14:33] <GridCube> i did some
[14:33] <GridCube> :)
[14:37] <drc> Has the decision been made whether the team wants a player or a player/manager?
[14:38] <GridCube> drc i have no idea, im doing what i think i should be doing, but for what i understand nothing will change
[14:39] <GridCube> i dont understand this wiki :/
[14:39] <drc> plus ça change, plus c'est  la même chose:(
[14:40] <GridCube> mmhm
[16:05] <pleia2> linkedin group secured
[16:35] <astraljava> Whee!
[16:59] <knome> pleia2, hallo
[16:59] <pleia2> hi knome
[16:59] <knome> pleia2, https://wiki.ubuntu.com/Xubuntu/Testing/Short
[17:00] <knome> pleia2, we updated that with astraljava
[17:00] <pleia2> great
[17:00] <pleia2> shall we move to qa wiki?
[17:00] <knome> pleia2, yeah, once we know what the structure is
[17:00]  * pleia2 nods
[17:01] <pleia2> so for Ubuntu: http://testcases.qa.ubuntu.com/Install/DesktopPostInstallation
[17:02] <pleia2> but I guess  /Short is a bit more than that
[17:02] <knome> pleia2, those should be run too


[20:21] <rooik> Melp
[20:28] <tomreyn> rooik would like to be removed from the various channels, once again.
[20:29] <tomreyn> please call his parents so he doesn't need to go home alone
[20:29] <rooik> Hey
[20:34] <rooik> Tomreyn: problems?
[20:35] <tomreyn> get a life, kid
[20:35] <rooik> Why all this hate against me?
[20:37] <rooik> Flannel you doo doo
[20:37] <Flannel> rooik: Due to you joking around while asking for support, we have to assume you don't actually need help.  Unfortunately, there's not much you can do to convince us otherwise.
[20:37] <rooik> I need help
[20:37] <rooik> I cant even login
[20:38] <Flannel> rooik: That's too bad.  You should've considered the consequences of your rickrolling beforehand.
[20:38] <rooik> Rickrolling?! It's not me
[20:39] <Flannel> rooik: Yeah, it is.    We're not idiots and this isn't our first day on the internet.
[20:39] <rooik> If you dont want me to ask for help there, at least help me in this channel
[20:40] <Flannel> If you actually have linux issues, I'm sorry.  At least you might learn a lesson about being polite and the value of honesty.
[20:40] <Flannel> tomreyn: Is there anything else we can help you with today?  Just trying to cut back on spectators.
[20:40] <rooik> Help me here please
[20:40] <Flannel> rooik: This is not a support channel.
[20:41] <tomreyn> Flannel: you can kick me here any time.
[20:41] <rooik> You should offer support to your customers
[20:41] <Flannel> tomreyn: Don't play that game.  Please part if there's nothing else.
[20:41] <tomreyn> i dont consider it solved, but ymmv, see you around
[20:42] <Flannel> tomreyn: He's not in #u, so, solved?
[20:42] <rooik> If i post the x config and you know whats wrong can you help me?
[20:42] <Flannel> rooik: No, this is not a support channel.
[20:42] <rooik> Come on, just a try
[20:42] <Flannel> rooik: You had you chance.  You even had people asking for more information to help you.  Instead, you decided to rickroll them.
[20:42] <rooik> If you cant, amen
[20:43] <rooik> I post it, if you mind to help me, ill appreciate it
[20:43] <Flannel> rooik: Nope.  Not a support channel.    You should come back here when you've grown up a bit if you ever want to get back into #ubuntu.
[20:44] <rooik> Here it is: goo.gl/t4muBi . it's up to you to help a linux user or make him uninstall ubuntu for lack of support
[20:44] <Flannel> rooik: Have a nice day.
[20:45] <rooik> Pff, from what ive seen normal users are more helpful than admins
[20:45] <rooik> Blame on you
[20:46] <Flannel> rooik: I think you're mistaken.  Admins would never give you up, nor let you down.
[20:46] <Flannel> rooik: But, we're done here.
[20:47] <rooik> No you're running away and deserting me
[20:48] <rooik> And you're making an ubuntu customer saying goodbye to your product