[07:17] <cpaelzer> hi, the current bionic apache2 upload https://launchpad.net/ubuntu/+source/apache2/2.4.29-1ubuntu2 is blocked in proposed for a component mismatch to libnghttp2-14 - the MIR for that is complete in bug 1687454
[07:19] <cpaelzer> OTOH I do not see it in https://people.canonical.com/~ubuntu-archive/component-mismatches.txt , so maybe I fail to see something else missing in this case
[07:20] <cpaelzer> So I either need an AA to promote that through the mismatch or some guidance on what I overlook in this case
[07:21] <cpaelzer> I'd have expected the autopkgtests to run and then be a component mismatch, but the tests block on "unsatisfiable Depends: libnghttp2-14"
[07:22] <cpaelzer> But other than being in universe it is there as far as I can see
[07:36] <infinity> cpaelzer: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt is what you're after.  Fixing.
[07:41] <cpaelzer> infinity: thanks for the link but I'm puzzled
[07:41] <infinity> cpaelzer: By?
[07:41] <cpaelzer> is that telling me something else than the expected component mismatch?
[07:41] <infinity> cpaelzer: It's telling you what you thought you wanted to see on the other page.
[07:41] <cpaelzer> lol
[07:42] <infinity> cpaelzer: The other page, of course, won't list the mismatch because it doesn't include -proposed, and thus nothing is pulling nghttp2 into main there.
[07:42] <infinity> cpaelzer: Anyhow, it's promoted now.
[07:42] <cpaelzer> thank you
[07:42] <cpaelzer> I had the link from https://wiki.ubuntu.com/MainInclusionProcess
[07:42] <cpaelzer> would it be reasonable if I added the one you gave me there as well?
[07:43] <infinity> cpaelzer: Sure.  Maybe s/show up in the component-mismatches list/show up in the component-mismatches list, or if the dependency is only in proposed, the component-mismatches-proposed list/
[07:45] <cpaelzer> done
[07:45] <cpaelzer> checking the autopkgtests in a few hours then ...
[08:01] <cpaelzer> Can someone cancel https://launchpad.net/ubuntu/+source/iproute2/4.14.1-0ubuntu1 from bionic-proposed
[08:01] <cpaelzer> other than tests before upload suggested this needs a bigger cleanup for ubuntu-fan
[08:01] <cpaelzer> I want to prepare a proper ..ubuntu2 for that, but that needs some time
[08:01] <cpaelzer> so cancelling the current one would be kind to interfer less with others
[08:02] <infinity> cpaelzer: Is it interfering in some way?
[08:02] <infinity> It builds no libraries, so the only way it could be causing issues if it it's actually broken somehow.
[08:03] <cpaelzer> infinity: it works in general but not with ubuntu fan
[08:03] <infinity> Mmkay.  I can delete it.
[08:03] <cpaelzer> thank you
[08:04] <infinity> cpaelzer: Gone.
[11:32] <doko> $ fgrep gvfs *
[11:32] <doko> vorlon:force-badtest gvfs/1.34.1-1ubuntu3/s390x
[11:32] <doko> please add ppc64el, tired about giving that back for every package multiple times ...
[11:33] <doko> or better disable the flaky tests, but that should be a task for the package owners ...
[11:37] <Laney> doko: done
[12:25] <acheronuk> Could someone please 'force-badtest kdepim-runtime/all/ppc64el kdepim-runtime/all/s390x' ?
[12:27] <acheronuk> that is another that seems to want to run tests on those architectures against itself, despite no binaries building
[12:30] <doko> infinity, slangasek, apw, Laney: please don't work on python-gobject-dev in NBS, using that as an example package mentoring Lucasz
[12:32] <apw> doko, ack
[12:43] <LocutusOfBorg> apw, hinting systemd/amd64 badtest will make a lot of stuff migrate, e.g. curl with security fixes inside...
[12:44] <apw> LocutusOfBorg, that on the face of it is a terrifying idea ... letting a systemd which is not passing its tests out
[12:45] <LocutusOfBorg> I'm running systemd against itself right now
[12:46] <LocutusOfBorg> apw, I know, but we are stuck with curl because of that, I pinged xnox above, I don't really know what to do
[12:46] <apw> LocutusOfBorg, oh but that looks like the reboot issue ... bah
[12:46] <LocutusOfBorg> we discussed this above already yesterday with cpaelzer and somebody else
[12:46] <LocutusOfBorg> I would like to upload the curl merge with new release and http2 support :)
[12:47] <LocutusOfBorg> somebody mentioned a race condition on the bug, but retrying the test is not helping too much
[12:47] <Laney> yet there are 4 more retries running right now
[12:48] <apw> Laney, did you make things smarter that we now see the dmesg bits in the logs ?
[12:48] <Laney> if it errors
[12:48] <apw> Laney, ahhh only if it is _your_ reboot which triggers it i assume
[12:48] <Laney> doesn't appear to be happening there
[12:49] <Laney> the test carries on, if that bug happens the machine dies forever
[12:49] <apw> oh yeah, so that specific instance isn't it, though the one on lsb _is_
[12:49] <apw> Laney, ^5 for adding that info, that is awsome
[12:50] <Laney> lsb is the same bug, right
[12:50] <Laney> but the others aren't AFAICS
[12:51] <LocutusOfBorg> I did run it against itself, lets see what happens
[12:52] <LocutusOfBorg> cpaelzer, libvirt merge ping? :)
[12:53] <Laney> right, but the 4 other retries aren't very helpful I don't think
[12:58] <coreycb> bdmurray: we have a few stable uploads that could use a review. nova for xenial and neutron for zesty. would you or someone else on the team be able to take a look?
[14:31] <LocutusOfBorg> can we have systemd forced bad then? curl is still waiting his cve fixes :(
[14:50] <bdmurray> coreycb: Its slangasek's day but if he can't I will.
[14:59] <jbicha> please consider badtesting pinentry/s390x, it's always-failed on most architectures (holding up gtk+2.0 and others today)
[15:02] <coreycb> bdmurray: thanks, much appreciated
[15:11] <LocutusOfBorg> apw, you ignored linux block, but I think there is a little NBS in proposed cleanup needed
[15:11] <LocutusOfBorg> old binaries left on arm64: linux-headers-4.4.0-1080-snapdragon, linux-image-4.4.0-1080-snapdragon, linux-snapdragon-headers-4.4.0-1080, linux-snapdragon-tools-4.4.0-1080, linux-tools-4.4.0-1080-snapdragon (from 4.4.0-1080.85)
[15:11] <apw> LocutusOfBorg, indeed, they would have appeared in the last hour or so, i'll sort them out
[15:12] <LocutusOfBorg> also raspi2 needs it :)
[15:13] <LocutusOfBorg> btw the new mainline vboxvideo seems to work great
[15:32] -queuebot:#ubuntu-release- Unapproved: sysstat (artful-proposed/main) [11.5.7-1ubuntu1 => 11.5.7-1ubuntu2] (kubuntu, ubuntu-server)
[15:33] -queuebot:#ubuntu-release- Unapproved: sysstat (zesty-proposed/main) [11.4.3-1 => 11.4.3-1ubuntu1] (kubuntu, ubuntu-server)
[15:37] -queuebot:#ubuntu-release- Unapproved: sysstat (xenial-proposed/main) [11.2.0-1ubuntu0.1 => 11.2.0-1ubuntu0.2] (kubuntu, ubuntu-server)
[15:37] <slashd> dgadomski, ^
[16:43] <LocutusOfBorg> cpaelzer, uploading curl, the current one won't easily migrate soon
[16:56] <cpaelzer> really
[16:56] <cpaelzer> ok LocutusOfBorg
[16:56] <cpaelzer> I decoupled apache anyway so it is not dpeending on each other
[16:57] <cpaelzer> the tests no more need the enabled curl
[16:57] <cpaelzer> and the MIR is done, so you won't hit the component mismatch
[16:57] <LocutusOfBorg> I see apache is good yes
[16:57] <cpaelzer> LocutusOfBorg: and btw fro libvirt - target is 3.11 wihch released mid Jan
[16:58] <cpaelzer> I'll play with 3.10 which released like a few days ago, but just to work with qemu 2.11 which releases next week
[16:58] <cpaelzer> this is all intertwined and none works well without the other
[16:58] <cpaelzer> but TL;DR it is under control :-)
[17:11] -queuebot:#ubuntu-release- New binary: libical3 [ppc64el] (bionic-proposed/none) [3.0.1-1] (no packageset)
[17:12] <LocutusOfBorg> thanks, the python binding is dep-waiting on it, this is why I care
[17:12] <LocutusOfBorg> btw, speaking on qemu, let me ask a question
[17:12] -queuebot:#ubuntu-release- New binary: libical3 [amd64] (bionic-proposed/none) [3.0.1-1] (no packageset)
[17:13] <LocutusOfBorg> long short story: pbuilder-dist bionic arm64 create fails since artful or so
[17:13] <LocutusOfBorg> somewhat it can't install bash, and fails there
[17:13] <LocutusOfBorg> same command, works with sid
[17:14] <LocutusOfBorg> cpaelzer, did you ever experienced that?
[17:14] -queuebot:#ubuntu-release- New binary: libical3 [i386] (bionic-proposed/none) [3.0.1-1] (no packageset)
[17:14] -queuebot:#ubuntu-release- New binary: libical3 [s390x] (bionic-proposed/none) [3.0.1-1] (no packageset)
[17:15] -queuebot:#ubuntu-release- New binary: libical3 [arm64] (bionic-proposed/none) [3.0.1-1] (no packageset)
[17:15] -queuebot:#ubuntu-release- New binary: libical3 [armhf] (bionic-proposed/none) [3.0.1-1] (no packageset)
[17:20] <LocutusOfBorg> W: Failure while unpacking required packages.  This will be attempted up to five times.
[17:20] <LocutusOfBorg> W: See //debootstrap/debootstrap.log for details (possibly the package /var/cache/apt/archives/bash_4.4-5ubuntu1_arm64.deb is at fault)
[17:23] <LocutusOfBorg> this is a paste http://paste.ubuntu.com/26140607/ of the file
[18:44] -queuebot:#ubuntu-release- New: accepted libical3 [amd64] (bionic-proposed) [3.0.1-1]
[18:44] -queuebot:#ubuntu-release- New: accepted libical3 [armhf] (bionic-proposed) [3.0.1-1]
[18:44] -queuebot:#ubuntu-release- New: accepted libical3 [ppc64el] (bionic-proposed) [3.0.1-1]
[18:44] -queuebot:#ubuntu-release- New: accepted libical3 [arm64] (bionic-proposed) [3.0.1-1]
[18:44] -queuebot:#ubuntu-release- New: accepted libical3 [s390x] (bionic-proposed) [3.0.1-1]
[18:44] -queuebot:#ubuntu-release- New: accepted libical3 [i386] (bionic-proposed) [3.0.1-1]
[18:51] <doko> please could somebody override the falcon/s390x autopkg test? it's always-failed on the other archs, not sure why it succeeded on s390x. or maybe better mark it as always-failed for s390x
[19:01] <jbicha> similar for pinentry/s390x
[19:10] <doko> now disabled the test in falcon, was disabled in the package build as well
[19:18] <slangasek> jbicha: the pinentry/s390x test regression does not appear to have happened as part of the move from lxd to kvm; I don't think this looks appropriate to override
[19:18] <jbicha> it's not appropriate for it to block gtk2 either, right?
[19:19] <slangasek> jbicha: you can trigger a baseline re-test of pinentry against the release pocket to show that it's not a regression in -proposed
[19:20] <jbicha> it feels odd for a test that doesn't pass on amd64 to block migration…
[19:20] <slangasek> ah
[19:20] <slangasek> pinentry fails on all kvm archs and only passes on lxd archs?
[19:21] <slangasek> ok, I overlooked that specialness
[19:22] <jbicha> oh, that's a neat trick :|
[19:22] <slangasek> spectacularly lame that a tty-related test would work in a container and fail on a host
[19:22] <slangasek> ok, overriding
[19:22] <jbicha> thanks
[20:04] -queuebot:#ubuntu-release- Unapproved: resolvconf (zesty-proposed/main) [1.79ubuntu4 => 1.79ubuntu4.1] (core)
[20:18] <acheronuk> slangasek:  Could you please 'force-badtest kdepim-runtime/all/ppc64el kdepim-runtime/all/s390x' ?
[20:19] <acheronuk> another that wants to run tests on those architectures against itself despite no binaries building
[20:19] <acheronuk> ^^^^ that should make the last of PIM migrate
[20:31] <slangasek> acheronuk: done
[20:31] <slangasek> coreycb: this neutron SRU is missing paperwork on LP: #1731595; test case, regression potential
[20:32] <slangasek> bdmurray: ^^ though I see you accepted it into artful-proposed without?
[20:33] <coreycb> slangasek: filling that in now
[20:34] <bdmurray> Oh, I thought I'd added a comment about accepting it but needing that info
[20:39] <coreycb> slangasek: bdmurray: updated with SRU details. thanks.
[20:39] <slangasek> bdmurray: "never read the comments" ;-)
[20:42] <slangasek> coreycb: nova is uploaded with the wrong -v option, -0ubuntu4.2 is not accepted into the archive but -0ubuntu4.3 doesn't include the link to LP: #1692397 in its .changes file; rejecting, this will need a reupload
[20:42] <slangasek> coreycb: also, it's unclear why this wasn't simply uploaded as 4.2, there is no 4.2 anywhere in LP's history
[20:42] <coreycb> slangasek: yeah that was a mistake. the old version was in the queue for a while and forgotten.
[20:43] <coreycb> slangasek: i'll fix that up
[20:43] <slangasek> ok
[20:44] -queuebot:#ubuntu-release- Unapproved: rejected nova [source] (xenial-proposed) [2:13.1.4-0ubuntu4.3]
[20:52] -queuebot:#ubuntu-release- Unapproved: nova (xenial-proposed/main) [2:13.1.4-0ubuntu4.1 => 2:13.1.4-0ubuntu4.2] (openstack, ubuntu-server)
[20:54] <coreycb> slangasek: i've uploaded a new nova to xenial
[20:55] <slangasek> thanks, will re-review shortly
[20:55] <coreycb> slangasek: thanks much
[21:09] <acheronuk> slangasek: thank you
[21:25] <slangasek> coreycb: ah; and what about LP: #1736149? seems there is already an openstack in zesty-proposed, awaiting verification
[21:34] <coreycb> slangasek: i'm on a roll here :/
[21:34] <slangasek> coreycb: sorry, I blindly paged through that warning message when I reviewed it earlier, I should've flagged it to you the first time around
[21:34] <coreycb> slangasek: could we replace the version in proposed with the new one?
[21:36] <coreycb> slangasek: probably not, they'd need to have the bugs referenced in the same version of the changelog
[21:37] <slangasek> coreycb: you could upload /nova/ with -v, and then do the SRU verification of 1736149 and the new bug at the same time
[21:37] <slangasek> coreycb: but that only makes us happy if the SRU verification actually takes place
[21:40] <coreycb> slangasek: i think i'll just verify the one that is in proposed and that will be 7 days in proposed on monday at which point we could promote it to updates and accept the new one
[21:42] <slangasek> ok
[23:13] -queuebot:#ubuntu-release- New binary: polyml [i386] (bionic-proposed/universe) [5.7.1-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: polyml [s390x] (bionic-proposed/universe) [5.7.1-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New binary: polyml [ppc64el] (bionic-proposed/universe) [5.7.1-1] (no packageset)
[23:14] -queuebot:#ubuntu-release- New binary: polyml [amd64] (bionic-proposed/universe) [5.7.1-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: polyml [arm64] (bionic-proposed/universe) [5.7.1-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: polyml [armhf] (bionic-proposed/universe) [5.7.1-1] (no packageset)


[04:55] <hikiko> hi
[06:49] <willcooke> o/
[06:53] <pitti> Good morning!
[07:06] <didrocks> hey guys
[07:11] <didrocks> pitti: hey! I have a very stupid question about the resolved email thread, you wrote:
[07:11] <didrocks> "That's the reason why the dnsmasq instance we spawn
[07:11] <didrocks>     with Network Manager doesn't have caching enabled"
[07:12] <didrocks> what is the use of dnsmasq without cache?
[07:12] <didrocks> for me, that was the only reason we had it
[07:16] <pitti> didrocks: yeah, that's my worry as well
[07:17] <pitti> didrocks: that's what I'm currently discussing with stgraber
[07:17] <pitti> I'm not convinced that cache poisoning actually works that way
[07:17]  * pitti is typing another reply
[07:17] <pitti> didrocks: and indeed I don't like this at all (neither does awe)
[07:18] <didrocks> pitti: ok, so if I get it right, there is no use of resolved or dnsmasq without cache, it's just a process in the middle forwarding requests?
[07:19] <didrocks> well, it does local DHCP I guess…
[07:19] <didrocks> in case you connect through ethernet another device
[07:19] <didrocks> but that's it
[07:20] <pitti> didrocks: there still is
[07:20] <pitti> didrocks: better failure handling with multiple DNS servers
[07:20] <sarnold> perhaps directing specific domain or reverses to specific recursors?
[07:20] <pitti> didrocks: and resolved does DNSSEC
[07:20] <pitti> but indeed, the main point is moot
[07:21] <didrocks> pitti: oh right, you mentioned the multiple DNS servers fallback
[07:21] <didrocks> pitti: got it, thanks :-)
[07:36] <willcooke> is it easy to flush the cache?  Just restarting the daemon?
[07:37] <pitti> needs root
[07:37] <willcooke> fair enough
[07:37] <pitti> ok, I sent two more replies
[07:58] <seb128> good morning desktopers
[07:58] <willcooke> hey seb128
[07:58] <seb128> hey willcooke
[08:01] <pitti> bonjour seb128
[08:01] <seb128> salut pitti, ça va ?
[08:02] <pitti> ça va bien, merci !
[08:02]  * seb128 is reading the dns resolver discussion, interesting one
[08:03] <Laney> why hello
[08:03] <seb128> hoi Laney!
[08:03] <pitti> seb128: indeed
[08:03] <pitti> hey Laney, good morning
[08:03] <Laney> what's up!
[08:04] <didrocks> Laney: because hey
[08:07] <Laney> I dropped my phone on the concrete floor at climbing last night and broke it :|
[08:07] <willcooke> :((
[08:07] <willcooke> Laney, I've replaced a couple of screens on my phone - it's fiddly but do-able.
[08:07] <Laney> it's not a smashed screen actually
[08:07] <willcooke> oh
[08:07] <willcooke> that's bad then
[08:08] <Laney> already had that replaced out of warranty on this one, so no insurance for me!
[08:08] <alexarnaud> Hello all!
[08:08] <Laney> it's some cable/connector inside it
[08:08] <Laney> it does actually work until it's moved
[08:09] <Laney> so can get the data off hopefully
[08:10] <didrocks> argh Laney :/
[08:10] <didrocks> hey alexarnaud
[08:10] <Laney> didrocks: I was trying to wait for the Oneplus 3!
[08:11] <didrocks> when is it going to be out?
[08:11] <alexarnaud> hey didrocks, how are you today? Are you still sick?
[08:12] <Laney> rumours say june 14
[08:12] <didrocks> alexarnaud: yeah, still…
[08:13] <didrocks> Laney: you can do it! wait wait wait :)
[08:13] <seb128> Laney, time to get an ubuntu phone! ;-)
[08:13] <Laney> /part
[08:13] <didrocks> a snapcraft part?
[08:14] <seb128> :-(
[08:14] <Laney> :P
[08:14]  * Laney looks up when he got this phone
[08:15] <Laney> 13 July 2014
[08:15] <Laney> this is poor
[08:18] <alexarnaud> seb128: it seems that Ubuntu Phone is good :) ! Unfortunately, it seems not accessible with a screenreader. I don't know if the work on Android and Firefox OS about this subject could event. I read that Mir use event manager of Android. Talkback aad Android accessibility stack change the way to interact with the phone ^^.
[08:19] <seb128> alexarnaud, yeah, it's improving but it still has feature gaps compared to main OSes
[08:26] <didrocks> oh btw, on the LTS, I have gnome-terminal with weird tabs layout since yesterday's upgrade, is that known?
[08:27] <Laney> what does weird tabs layout mean?
[08:27] <didrocks> let me do a screenshot
[08:27] <Laney> did you check what got upgraded? :)
[08:27]  * Laney suggests you do that first
[08:29] <seb128> blame willcooke!
[08:29]  * seb128 ducks
[08:29] <didrocks> Laney: I did and there was light-themes :p
[08:29]  * Laney is leading didrocks down the path
[08:30] <didrocks> http://people.canonical.com/~didrocks/tmp/terminal_tabs.png
[08:30] <willcooke> ruh row
[08:30] <didrocks> the tab colors changed and it's a little bit (IMHO) ;)
[08:30] <didrocks> ugly*
[08:30] <didrocks> :p
[08:30] <Laney> open the gate marked /usr/share/doc/light-themes/changelog.Debian.gz
[08:31] <didrocks> who is this guy?
[08:31] <didrocks> Will Cooke?
[08:31] <sarnold> .. what, no screenshot from yesterday too? :)
[08:31] <willcooke> didrocks, that's how it's supposed to look.
[08:31] <didrocks> new devs? :)
[08:31] <didrocks> new design ;)
[08:31] <willcooke> It's a feature, not a bug \o/
[08:31] <didrocks> willcooke: ok, it's weird to notice them now when I didn't before :)
[08:31] <didrocks> (but I guess that was the point of the change)
[08:32] <willcooke> didrocks, https://bugs.launchpad.net/ubuntu/+source/ubuntu-themes/+bug/762349
[08:32] <didrocks> 2 tabs are ok and great, it's when you have more (but I'm guilty of that)
[08:32] <didrocks> willcooke: yeah, I'm looking now
[08:32] <didrocks> at least, it's not my eyes which have derailed
[08:32] <didrocks> and I can notice changes!
[08:33] <didrocks> ok, this is when I should paste this: https://xkcd.com/1172/ :)
[08:33] <willcooke> :D
[08:34] <didrocks> at least, not a regression, but weird (and nice in some way) to have a visual change in a LTS for once!
[08:34] <didrocks> I just wasn't expecting it, hence the "something should have broke"
[08:34] <willcooke> :)  I agree, it's a tad on the ugly side, but it does the job.
[08:34] <didrocks> thx for answering about it guys! :)
[08:34] <didrocks> yep
[08:35] <willcooke> Laney, can you remind me what to add to the search providers in my browser so I can search LP bugs from the URL bar again?  The URL was something like bugs.launchpad.com/+bug/%s  but I can't get it to work
[08:37] <sarnold> http://launchpad.net/bugs/%s
[08:37] <Laney> I use pad.lv/%s
[08:37] <sarnold> https://wiki.canonical.com/UbuntuEngineering/Security/Tips
[08:37] <Laney> then you can use the other pad.lv patterns too
[08:37] <seb128> willcooke, what browser do you use?
[08:37] <willcooke> seb128 *cough* Chrome *cough*
[08:37] <willcooke> I HAVE A REASON TO USE IT!!
[08:37] <willcooke> thanks Laney sarnold
[08:40] <davmor2> willcooke: what was that it was hard to hear over the coughing it didn't sound like the default browser installed on the system though
[08:42] <seb128> willcooke, right click on the url bar -> edit search engine and you can add custom entries
[08:42] <willcooke> seb128, yeah all done, thx
[08:42] <seb128> it's less specific that pad.lv
[08:42] <seb128> and less to type :p
[08:43] <seb128> like I've "bts %s" which sends me to the bts page for the package
[08:43] <Laney> shortcut wars
[08:43] <willcooke> I do "lbp 123456"
[08:43] <seb128> or bzg for the gnome bugzilla
[08:43] <willcooke> *lpb
[08:43] <seb128> that's my "lp" ;-)
[08:43] <seb128> "lps" for the bugs list "lpc" for the component page :p
[08:44] <seb128> but yeah, seems like everyone has their own custom tricks
[08:50] <seb128> ok, after days of rain we have some sun, going to use the opportunity to get some pre-lunch exercice
[08:50] <willcooke> seb128, enjoy!  It's raining here still :(
[08:50]  * willcooke considers building an ark
[08:51]  * Laney whines "MIR please" at tedg
[08:52] <seb128> thanks!
[08:54] <Laney> pitti: is "rm pending.json" not enough to get britney to fix its knowledge of pending tests?
[08:54] <Laney> kcalcore -> ktnef is falsely in progress
[08:55] <pitti> Laney: ah, did you do that?
[08:56] <Laney> yesterday
[08:56] <pitti> Laney: I'm currently investigating what happened to the lost armhf requests
[08:56] <pitti> Laney: so either you did that while britney was running, or it lost them again
[08:56] <Laney> I checked britney wasn't running at the time
[08:56] <Laney> or it was running but not for yakkety
[08:56] <pitti> Laney: let me look at the runners; test requests are not supposed to get simply lost
[08:56] <Laney> it's been in progress for some days now
[08:57] <pitti> e. g. gvfs/armhf for systemd 230-2 is still "in progress", but https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety?format=plain&prefix=yakkety/armhf/g/gvfs has no result
[08:57] <Laney> first I re-requested them but that didn't clear it
[08:57] <pitti> but it's also not in the AMQP queues any more
[08:57] <pitti> so they just get eaten somehow, which Should Not Happen™
[08:58] <pitti> Laney: might still be a leftover swift glitch of course
[08:59] <pitti> Feb 12 04:13:16 cyclops-node23 worker[495]: 2016-02-12 04:13:16,425 INFO:worker Received request for package gvfs on yakkety/armhf; params: {u'triggers': [u'systemd/230-2']}
[08:59] <pitti> Feb 12 04:17:07 cyclops-node23 worker[495]: 2016-02-12 04:17:07,030 INFO:worker Putting results into swift autopkgtest-yakkety yakkety/armhf/g/gvfs/20160212_041707@
[08:59] <pitti> Feb 12 04:17:09 cyclops-node23 worker[495]: 2016-02-12 04:17:09,778 INFO:worker Acknowledging request gvfs
[08:59] <pitti> that looks fine
[09:00] <davmor2> willcooke: Go find Rhod Gilbert ask the audience how old they were when they realised they could take a kagool off ;)
[09:00] <pitti> Laney: err, wait -- that's a completely bogus timestamp
[09:00] <willcooke> davmor2, :D:D:D
[09:00] <Laney> pitti: errrm, quite
[09:00] <pitti> Laney: indeed, one of the runners has date == Fri Feb 12 11:21:48 UTC 2016
[09:01] <Laney> I guess something expects the timestamps to be monotonic
[09:01] <pitti> Laney: yes, in britney we remember the last timestamp and query for results newer than that
[09:01] <davmor2> willcooke: followed up with "In the bible it rained for 40 days and forty nights, that's still the best summer I ever remember"
[09:01] <pitti> Laney: ok, let me fix the date on this, then I'll mass re-run all the RUNNING ones
[09:01] <Laney> merci
[09:01] <pitti> Laney: btw, you don't need to wait for britney and rm pending any more
[09:02] <Laney> I did try re-running first
[09:02] <Laney> that was<EMAIL_ADDRESS>[09:02] <Laney> but it's still RUNNING on britney
[09:02] <Laney> no, lies, it was<EMAIL_ADDRESS>- but still
[09:02] <pitti> Laney: hm, that sounds like something else then
[09:03] <Laney> I think there were still some swift problems at that time
[09:03] <pitti> ah, could be
[09:03] <Laney> it took debci ages to catch up with the results being put into swift
[09:03] <pitti> Laney: ah, that arm box has ntpd installed
[09:03] <pitti> so timesyncd disables itself
[09:03] <pitti> and apparently ntpd doesn't work so well
[09:03] <Laney> "oops"
[09:04] <pitti> kwality
[09:05] <pitti> ok, ntp purged, timesyncd started, date is correct
[09:05] <pitti> time for retry-autopkgtest-regressions -s yakkety --state RUNNING |grep armhf
[09:06] <pitti> (done)
[09:07]  * Laney runs ktnef locally
[09:07] <Laney><EMAIL_ADDRESS>unhelpful
[09:07] <pitti> Laney: oh, I was looking at<EMAIL_ADDRESS>which is similar
[09:08] <pitti> Laney: thanks for that, investigating this on amd64 is much easier
[09:08] <Laney> it means 'uninstallable' right?
[09:08] <pitti> Laney: no, this means that apt-get source ktnef somehow failed
[09:10] <Laney> pitti: oh right, and apt's stdout/err isn't saved anywhere?
[09:10] <pitti> Laney: but I see why it might fail for linux-raspi2 (version mismatch wit NBS binaries), but not the same case for ktnef
[09:12] <pitti> Laney: it's actually suposed to print the apt stdout/err on failure
[09:12] <pitti> .. or not, hang on
[09:12] <pitti> yeah, I think it doesn't
[09:12] <pitti> Laney: does that reproduce locally?
[09:13] <Laney> not with schroot anyway
[09:13] <Laney> probably not minimal enough
[09:14] <pitti> Laney: does reproduce here
[09:14] <pitti> runner/adt-run ktnef --- schroot yakkety
[09:16] <pitti> Laney: right, bug in the heuristics for determining which source package to download
[09:16] <pitti> *throws hands into air*, /me really wants an apt-get source foo=version
[09:16] <pitti> this is excruciatingly difficult
[09:16] <pitti> err, apt-get source foo/yakkety-proposed
[09:17] <pitti> (=version works)
[09:21] <Laney> pitti: /me screams
[09:21] <Laney> just saw this code
[09:23] <pitti> Laney: it's pure joy, isn't it
[09:54] <Laney> pitti: https://paste.debian.net/713146
[09:54] <pitti> Laney: argh, that trap again
[09:56] <pitti> Laney: I'm a moron: http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=7c1a251a4
[09:56] <Laney> pitti: haha
[09:56] <pitti> Laney: so we need to not specify it for precise, but everywhere else
[09:56] <Laney> we have autopkgtest for 12.04?
[09:56] <pitti> yes
[09:56] <pitti> kernel mostly
[09:57] <alexarnaud> TheMuso: Hello! I'm visual impaired and I would like to know if you have some type of experience about computer with EFI and Windows dual-boot. Is it possible from a new computer buy in the market with Windows to boot on a Ubuntu USB stick without sighted help that will disable fast boot or something like that ?
[09:57] <Laney> there's another showsrc in lib/adt_testbed.py
[09:57] <pitti> E: Command line option --only-source is not understood
[09:57] <pitti> yep, need to conditionalize that
[09:57] <pitti> runner/adt-run -d pmount --- schroot precise
[09:58] <pitti> ^
[09:58] <pitti> Laney: thanks, will clean this up too
[10:00] <Laney> pitti: you can call "apt-cache showsrc --only-source" and look at the exit code
[10:00] <Laney> you get 0 if it accepts the argument and 100 otherwise
[10:00] <pitti> $(grep -q 12.04 /etc/os-release || echo --only-source)
[10:00] <pitti> Laney: oh, and it helpfully exits with 0 if you specify a nonexisting source package
[10:00] <pitti> *#)$#(*$#
[10:07] <pitti> Laney: http://paste.ubuntu.com/16886653/ seems to work
[10:08] <pitti> this fixes ktnef and linux-raspi2
[10:09] <pitti> there's still something wrong with this logic for precise, though, but later on
[10:09] <pitti> --apt-pocket self-tests still succeed
[10:10] <pitti> precise> ah, it fails because it still behaves like in xenial without --only-source, it just doesn't have an option for thsi
[10:11] <pitti> apt-cache showsrc ^linux$
[10:11] <pitti> and that doesn't work either
[10:13] <Laney> I suppose you have to look for Package:
[10:14] <Laney> grep-dctrl would be easier for that
[10:15] <Laney> apt-cache showsrc ktnef | grep-dctrl -S -sPackage-List -n ktnef
[10:17] <pitti> Laney: I pushed http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=56ac53b for now and will re-retry stuff
[10:18] <Laney> ok, thanks!
[10:18] <pitti> to unblock promotions; but this indeed is in dire need for cleaning up
[10:18] <Laney> I wonder why this became a problem right now
[10:18] <Laney> ktnef last succeeded not long ago
[10:18] <pitti> maybe with the new KDE upload two weeks ago binaries got shuffled
[10:19] <Laney> looks the same on xenial too
[10:19] <Laney> ah well
[10:20] <pitti> libgmpada too
[10:21] <pitti> and http://autopkgtest.ubuntu.com/packages/k/kactivities/yakkety/amd64/
[10:21] <pitti> all retriggered
[10:40] <Laney> Mirv: I'll upload goldencheetah to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-035/+packages to test your theory, ok?
[10:42] <Laney> (done)
[11:02] <Mirv> Laney: thank you
[11:02] <Mirv> still building on arm64
[11:07] <Laney> Mirv: failed
[11:08] <Mirv> Laney: I see. do you know how to get a list of packages that don't have armhf build at all (like goldencheetah)? I could cross-check that to my list of packages depending on libqt5core5a to find other candidates that need some action
[11:08] <Mirv> goldencheetah was indeed on this second list, but not on my first list (armhf ftbfs)
[11:17] <Laney> Mirv: In [13]: yakketyarmhf = lp.load('https://api.launchpad.net/devel/ubuntu/yakkety/armhf/')
[11:17] <Laney> In [14]: ftbfs = yakketyarmhf.getBuildRecords(build_state='Failed to build')
[11:17] <Laney> In [15]: len(ftbfs)
[11:17] <Laney> Out[15]: 472
[11:18] <Laney> hmm
[11:18] <Laney> not sure that is right
[11:18] <Laney> I suppose you need to filter it for published records only
[11:19] <Mirv> ok that copy-paste should be enough to get me forward with lplib
[11:24] <Laney> Mirv: seems "current_ftbfs = [f for f in ftbfs if f.current_source_publication is not None]" filters it to the current ones
[11:24] <Laney> can there really only be 198?
[11:24] <Laney> I'm a bit suspicious
[11:25] <Mirv> Laney: so ftbfs would list also those without package like build dep missing, for example goldencheetah? my ftbfs (really failed to build) was 181
[11:26] <Laney> you want to add build_state='Dependency wait' too for those
[11:26] <Mirv> ok
[11:26] <Mirv> Laney: and what about if package is built only for selected architectures?
[11:27] <Laney> I wonder if this is only showing packages which have been uploaded to y
[11:28] <Laney> http://qa.ubuntuwire.org/ftbfs/
[11:28] <Laney> this agrees with my number
[11:31] <Mirv> ah right I was on xenial, I maybe lost a few when translating the list of binary packages to source package with apt-cache. I can see from my bash history that I did filter for armhf (F)
[11:33] <Mirv> hmm, no, since those are source packages, I used apt-cache for the libqt5core5a reverse deps. ok, going over again.
[11:35] <Laney> this is the only one I care about right now since it is blocking libical :)
[11:52] <andyrock> Morning all
[11:52] <seb128> hey andyrock, how are you?
[11:53] <andyrock> Hey seb128 not bad you?
[11:53] <Mirv> ok I reproduced the ftbfs list and also got three more candidate packages from the depwait list, and goldencheetah too. checking in 035 and updating the bug report. I think I could subscribe ubuntu-archive now too, even if I'd still find a package or two in my remaining re-re-checks.
[12:24] <desrt> good morning
[12:26] <willcooke> hi desrt
[12:27] <seb128> hey desrt
[12:34] <seb128> willcooke, omw for that call, having some wifi issues though
[12:35] <willcooke> seb128, ha!  Thought exactly that :)
[12:36] <seb128> willcooke, can you hear me when I talk?
[12:36] <willcooke> seb128, nope!
[12:37] <seb128> fail :-/
[12:55] <seb128> attente, sorry I saw the bug but still unsure what you are trying to solve
[12:57] <attente> seb128: if you build the galculator snap without that, the snap looks for resources in the parts directory of the build dir instead of inside the final snap itself
[12:57] <seb128> desrt, attente, sorry audio was not good in that hangout and I didn't really understand if we had more specific issues than the ones we are filing/tagging since Prague
[12:57] <seb128> attente, so basically https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1583250 ?
[12:58] <attente> seb128: yep, exactly that
[12:58] <attente> seb128: so that workaround is to modify the autotools snapcraft plugin locally and add it to the repo
[12:58] <attente> but there we hard code the destination of the mounted snap
[12:59] <attente> /snap/<name>/current
[12:59] <seb128> right
[12:59] <seb128> change the app to use gresources :p
[12:59] <attente> but they don't like this because it's hard-coded, and removes any future possibility of relocating the snap
[13:00] <seb128> what do they suggest doing?
[13:00] <seb128> what is flatpak doing? do they make the archive content being seen as /?
[13:01] <attente> i don't know what flatpak is doing, but our workaround right now with the hacked autotools plugin seems to be the only thing we have
[13:01] <seb128> yeah, Trevinho made a quilt plugin to patch the source before building
[13:02] <Trevinho> not that is the cleanest solution eh :)
[13:02] <seb128> hey Trevinho!
[13:02] <Trevinho> but... ti seems that there some discussion if we want that part of snapcraft or not
[13:02] <Trevinho> hey seb128
[13:02] <attente> that's about the same as just fixing all upstreams to be relocatable though
[13:02] <Trevinho> seb128, attente: relevant bug is https://bugs.launchpad.net/snapcraft/+bug/1551716 it would be nice your input too
[13:03] <seb128> Trevinho, well ideally you wouldn't need to patch a source to snap it
[13:03] <Trevinho> no, ideally not... But you know the world we live in
[13:03] <Trevinho> and forking just for a single patch is annoying to me
[13:04] <Trevinho> all the main pieces in core (nm, bluez) are still using patching in any case
[13:05] <seb128> yeah, that's fine for our stack
[13:05] <seb128> we create work for ourself so it's our choice
[13:05] <seb128> we shouldn't require that from app writers though
[13:05] <Trevinho> sure, upstream has not to do that
[13:06]  * desrt hugs the upstreams of the world
[13:06] <desrt> "we're all in this together, guys"
[13:07] <seb128> desrt, attente, do you me to write that email to the snappy list?
[13:07] <desrt> seb128: if you would like to, that would be great
[13:08] <seb128> k
[13:08] <desrt> i do have a slight aversion to getting involved in discussions that i know almost nothing about =)
[13:08] <Trevinho> seb128, attente: however one thing I was hacking on and that I think could be useful for this, is that IMHO when opened a snap should be do something like a bind mount on /this-snap or whatever that points to $STAN
[13:08] <Trevinho> $SNAP
[13:08] <Trevinho> in this way, we can just compile using /this-snap/ as prefix
[13:09] <desrt> *cough* filesystem *cough* namespaces
[13:09] <desrt> *cough* *cough*
[13:09] <Trevinho> well, naming can be better... But it's not the point
[13:10] <desrt> it's entirely the point
[13:10] <desrt> we could have some standard path that all snaps used without stepping on each others toes...
[13:10] <desrt> we could even give it a nice short easy-to-type name that looks friendly and familiar to everyone
[13:10] <desrt> maybe... oh... /usr, for example
[13:11]  * desrt twitches
[13:11] <Laney> :)
[13:11] <seb128> there might be a reason why they don't want to go that road
[13:12] <seb128> let's see what the discussion gives
[13:12] <seb128> at least filesystems namespaces can"t be used to restrict root apps
[13:12] <Laney> Mirv: can you point me to your list?
[13:12] <seb128> so it would work for desktop examples
[13:12] <seb128> but not for system services
[13:12]  * Laney knows a friendly archive admin
[13:12]  * Laney sniggers
[13:14] <desrt> seb128: filesystem namespaces can be used for root apps no problem
[13:14] <desrt> seb128: the basis of that discussion was that it may still be necessary to _also_ use apparmor for some things as well
[13:15] <desrt> (although i believe that the core kernel will improve to the point where this is not necessary... and if you use user namespaces, i'd say it's already there, modulo the horrifying bugs that appear on a semi-regular basis)
[13:15] <attente> Trevinho: isn't the same problem still going to happen? that's still going to be a hard-coded path in the final snap
[13:16] <Trevinho> attente: yeah, it's hardcoded, but it's always there
[13:16] <Trevinho> attente: while it won't be dependent on version or pkgname
[13:17] <desrt> since i can't really talk about the weather...
[13:17] <desrt> how many of you have stopped using firefox and switched entirely to chrome?
[13:18]  * desrt is starting to suspect that she may be the last holdout
[13:18] <Trevinho> desrt: although I've plenty of ram, chrome is too much a memory hog to me.. So no.
[13:18] <Trevinho> so.. firefox for life.
[13:19] <desrt> ....or until your next laptop upgrade :)
[13:19] <Trevinho> desrt: I did that.. And I've 32GB of ram, but still... I can't manage all my tabs in chrome :)
[13:19] <Laney> i use firefox too
[13:20]  * desrt very often gets into situations where firefox takes a very very long time to quit
[13:21] <desrt> clearing out history/awesomebar/etc/etc databases seems to help that for a bit, but it's not too long before it's back to where it was... and during that time, if i try to open another window (within 20 seconds, say, of last exit), i get "firefox is already running.  plz reboot."
[13:21] <desrt> any tips?
[13:21] <Mirv> Laney: bug #1586026 - ubuntu-archive not yet subscribed
[13:23] <Laney> Mirv: what does candidates: mean for yade?
[13:26] <Laney> desrt: seen the "firefox is still running" thing from time to time, but not slow quitting
[13:26] <Laney> no help from me then :(
[13:26] <desrt> the "firefox is still running" thing happens because it hasn't exited yet from the previous tim e
[13:26] <jbicha> desrt: I'm stil on firefox
[13:26] <desrt> ie: the windows are closed, but the process is still there, seemingly doing something in the background
[13:27] <desrt> jbicha: hey!
[13:27] <Laney> when i've seen it it's been a long time after quitting
[13:27] <seb128> grrr, got bitten again by docking my laptop changing connection which confuses IRC
[13:27] <desrt> jbicha: welcome back!
[13:27] <Laney> like the thing never managed to exit properly
[13:27] <seb128> if somebody talked to me since less than 10 min please repeat what you wrote
[13:28]  * Laney gets recruiter spam hiring for a cloud based tax and accounting platform
[13:28] <Laney> hmmmmmmmmmmmmmmmmmmmm maybe not
[13:28] <Mirv> Laney: that it was found in the cross-check list but check if it's failing a rebuild is not ready yet
[13:29] <Mirv> ie it did fail on armhf, but not yet sure if it would now fail on arm64. build still ongoing.
[13:29] <Laney> seb128: it breaks your existing network connections if you do that?
[13:30] <seb128> no, but I think it changes the routing
[13:30] <seb128> my dock is cable/eth connected
[13:30] <seb128> which becomes default over the wifi
[13:31] <Laney> not sure that should break established connections
[13:31] <Laney> did it always do that?
[13:31] <seb128> yes
[13:31] <Laney> annoying
[13:32] <seb128> indeed!
[13:34] <Laney> seb128: don't suppose you have a few minutes to process https://bugs.launchpad.net/ubuntu/+source/bino/+bug/1586026 do you?
[13:34] <Laney> if not then just goldencheetah would be appreciated
[13:35]  * Laney is attacking libical with maximum force
[13:35] <seb128> let me have a look
[13:35] <Laney> pretty sure the only thing left after that is indicator-datetime
[13:35]  * Laney stares at texas hard
[13:35] <seb128> why would they fail now if rebuilt?
[13:36] <seb128> teddddd
[13:36] <Laney> some gl change on arm64
[13:37] <seb128> shouldn't we fix gl/those then?
[13:37] <Laney> sure if you get the phone team that made this change to put it on their list
[13:38] <seb128> is goldencheetah blocking libical?
[13:38] <Laney> yep
[13:48] <seb128> Laney, done for goldencheetah, going to wait to hear more from Mirv before removing the others, looks like things that should be fixed to me
[13:50] <Laney> fine for me, fixing things is good, hope that happens ;-)
[13:50]  * Laney is bored of punching his phone
[14:55] <Sweet5hark> seb128: http://people.canonical.com/~bjoern/yakkety/5.1.3/ <- 5.1.3 yakkety for poppler transition and to avoid breaking against mdds
[14:56] <seb128> Sweet5hark, k, adding to my todo
[14:57] <Sweet5hark> seb128: I looked at bug 1586497 -- cant get any wiser from the logs there on what happened there really. I only see dpkg returning -1 in https://launchpadlibrarian.net/261979138/DpkgHistoryLog.txt but cant see why. I also note this happened with other packages before in the log ...
[14:57] <Sweet5hark> seb128: is that enough to mark it bot-stop-nagging?
[14:58] <seb128> Sweet5hark, right, maybe full disk or something, yeah just tag it
[15:03] <Sweet5hark> seb128: done (all SRU bugs now verification-done0.
[15:03] <seb128> Sweet5hark, thanks
[15:31] <seb128> Laney, ubuntu-app-launch was in main and demoted in xenial, I don't think it needs a MIR?
[15:32] <seb128> Sweet5hark, sponsored, ignore the rejected email, you included the orig in the libreoffice upload where it was already in yakkety, I hacked the .changes and reuploaded
[15:41] <Laney> seb128: you'd promote it?
[15:41] <Laney> I didn't find an mir bug
[15:42] <Laney> it looks like it went straight to main
[15:43] <seb128> Laney, https://bugs.launchpad.net/ubuntu/+source/upstart-app-launch/+bug/1218952
[15:43] <seb128> it was renamed
[15:43] <seb128> so yeah, let me repromote it
[15:44] <Laney> neat
[15:45] <Sweet5hark> seb128: whoops, sorry. thanks for fixing.
[15:47] <seb128> yw!
[15:47] <seb128> Laney, done
[15:59] <seb128> happyaron, still around?
[16:10] <seb128> happyaron, your openconnect SRU is buggy :-/ you included changes that are not described in the changelog, like using "--enable-absolute-paths" and you reverted the updated build-depends requirement from nm 0.9 to 1.1 ... I fixed it and sponsored
[16:13] <seb128> happyaron, also you changed the sru bug number, unsure if that was wanted?
[19:40] <jbicha> mterry: hi, since you uploaded webkitgtk, do you want to look at
[19:40] <jbicha> https://code.launchpad.net/~jbicha/lightdm-webkit-greeter/lp1588037-obsolete-webkit-dependency/+merge/296250
[19:41] <mterry> heh
[19:41] <mterry> jbicha, sure
[19:46] <jbicha> hmm, libwebkitgtk-doc breaks & replaces libwebkitgtk-dev (<< 2.4.10) but we'll need that bumped to 2.4.11-1~
[19:50] <mterry> jbicha, guh right
[19:50] <mterry> whoops
[20:15] <jbicha> seb128: if you're still around, could you remove anjuta 3.20 from y-proposed
[20:16] <jbicha> anjuta will need a simple rebuild to drop the libwebkit2gtk-3.0 dependency...it doesn't even need webkitgtk to finish building first
[21:47]  * desrt boggles at gcc
[21:47] <desrt>         movl    $4, %edx
[21:47] <desrt>         movl    $.LC6, %esi
[21:47] <desrt>         movq    %r13, %rdi
[21:47] <desrt>         call    memcmp
[21:47] <desrt> this is your code on -O3.... wtf
[21:53] <desrt> clang says: cmpl    $1852400175, -4(%rbx,%r14)
[21:53] <desrt> good clang *pat pat*
[22:30] <TheMuso> alexarnaud: I think Windows does have an option to let you boot into the UEFI settings on next boot, but from there you will need sighted help, unless of course your UEFI vendor has implemented some kind of accessibility, but that is very very unlikely.
[22:30] <TheMuso> alexarnaud: There also may be a keyboard shortcut to press at boot that will bring up the boot selection, but working out which one is your USB is another matter, again likely requiring assistance.


[06:32] <jonobacon> mhall119, around?
[07:29] <dholbach> good morning
[08:43] <davidcalle> Good morning o/
[08:45] <dholbach> salut davidcalle
[08:45] <davidcalle> Hey dholbach, how was you we?
[08:48] <dholbach> very good, but a bit bizarre - saturday I wanted to meet up with a couple of friends in a bar, but instead we managed to crash a new years party - some folks decided to have a belated new years party and invited us just off the street - at times our group was about 2/3 of the event (nobody of us knew the hosts of the party)
[08:49] <dholbach> it was good fun, but as I said, a bit bizarre :)
[08:49] <dholbach> how was yours?
[08:59] <davidcalle> dholbach, wow, interesting! Mine was very nice, kids were at Estelle's parents, so we had time to buy some new furnitures, see friends, and take some much needed rest :)
[09:05] <popey> My weekend was incredibly boring compared to dholbach :)
[09:09] <dholbach> I'm looking forward to seeing you guys next week :)
[09:11] <davidcalle> popey: boring is good! :)
[09:11] <davidcalle> Same :)
[09:13] <popey> :)
[09:38] <czajkowski> Aloha
[09:43] <popey> yo
[09:44] <nigelb> morning.
[13:39] <balloons> morning morning
[15:32] <dpm> mhall119, all set?
[15:35] <mhall119> dpm: one second
[17:04] <dholbach> all rightie........ I call it a day - see you all tomorrow!
[18:09] <inetpro> good evening
[18:12]  * inetpro looking for a good beginner's guide for Ubuntu
[18:14] <inetpro> need to send to someone who wants to explore Ubuntu with the idea to move away from Windows
[18:15] <pleia2> inetpro: the http://ubuntu-manual.org/ folks do a nice job (free pdf, cheap printed book)
[18:18] <inetpro> thanks pleia2
[18:35] <wxl> bet it's too early to ask if ubuntu's going to participate in google summer of code this year, but i have a google code-in student interested.
[19:30] <mhall119> wxl: I believe that jose was planning on getting us in GSoC this year
[19:31] <wxl> jose: if you can confirm or deny or otherwise provide information on Ubuntu's involvement in GSoC 2016, i'd appreciate it :)
[19:31] <wxl> thx btw mhall119
[21:42] <balloons> lol, because jose has magic powers right!
[21:43] <balloons> the biggest deal will be getting some mentors and tasks together -- even moreso than GCI.
[22:34] <jose> wxl: gsoc is intended for 18+ college students btw
[22:36] <wxl> good point, jose. i'll check into it.
[22:37] <jose> wxl, mhall119: but yes, I am intending to help run gsoc. it's going to be a bit harder though
[22:37] <jose> gsoc is one on one mentoring, where the student works to usually implement something on the code
[22:41] <wxl> jose: let me know how i can help!
[22:41] <jose> thanks
[22:42] <wxl> i know what a good idea for a gsoc project would be
[22:42] <wxl> give us a wiki system that doesn't suck!!!!!
[22:49] <wxl> and actually on that topic usually the big issue is logging in. maybe sso needs some help
[23:22]  * mhall119 wonders if jose will be the first person to both organize GSoC *and* participate in it as a student :)
[23:22] <mhall119> wxl: it took me 3 tries the other day to log in :/
[23:23] <jose> mhall119: lol, my coding skills are not that good :P
[23:23] <mhall119> that's what the mentors are for :)
[23:23] <mhall119> I'll get you started on summit


[06:00] <brobostigon> morning
[08:09] <zmoylan-pi> o/
[08:13] <brobostigon> \o
[13:30] <ujjain> Hey guys! I have received a job offer today, but I had a final stage interview last Friday with a company I like more. Which of these e-mails would sound better?
[13:30] <ujjain> - May I ask at what stage is the review of my interview? I have received other offers as well and would Like to know about my application as well at your company so I can fully review my offers in order to let everyone know my next step.
[13:30] <ujjain> - My job search has reached the offer stage with my other applications. Can you let me know when you are planning to update as to the status of my application, so that I can fully evaluate my options.


[02:04] <MsMaco> hello folks. ive been trying to help this tommy_ fellow get his screen to do its native 1024x768. we went through xrandr --newmode and --addmode and now it shows in his screen config gui (yay) but it fails when he tries to do xrandr --output default --mode 1024x768_60
[02:04] <MsMaco> ive hit the limits of my xrandr knowledge, so...can anyone help?
[02:05] <tommy_> please :-)
[02:05] <MsMaco> i *thought* those were all the necessary steps...but maybe not... and if so, i suppose the answer is just "file a bug"
[02:05] <tommy_> everybody's sleeping it appears
[02:06] <MsMaco> its not an ordinarily busy channel... but i dont *think* everyone here's british
[02:06] <tommy_> neither am I lol
[02:07] <MsMaco> many ubuntu devs are british or otherwise european so finding them at this time of night can be hard
[02:07] <tommy_> ah gotcha
[02:07] <MsMaco> if youre in the US, there tend to be more people around noon-ish or late morning
[02:08] <tommy_> I mean using it now I'm almost somewhat not even noticing the frames
[02:08] <tommy_> but it's still annoying
[02:09] <tommy_> well I just rand xrandr by itself again
[02:09] <tommy_> and even though I told it to run at 1024x768 in the gui, it still says 800x600 in xrandr
[02:09] <tommy_> Screen 0: minimum 640 x 480, current 800 x 600, maximum 1024 x 768
[02:09] <tommy_> so it's an option now atleast, I just can't get it to set to the max
[02:10] <MsMaco> right it still says that cuz switching to 1024x768 failed
[02:11] <MsMaco> xrandr -s 1024x768
[02:11] <MsMaco> maybe?
[02:11] <MsMaco> thats an old way to do it, but worth a shot
[02:11] <tommy_> failed
[02:12] <tommy_> see if I can get any luck out of the other channel
[02:18] <tommy_> hello anyone around?
[03:42] <tommy_> hello anyone here?
[03:44] <MsMaco> tommy_: i asked a friend that does some X stuff and he said that error sounds like the driver's refusing to accept the mode
[03:44] <MsMaco> i still dont know why he doesnt join this channel
[03:44] <tommy_> well upon restart
[03:44] <tommy_> the 1024x768 option dissapeared from the gui
[03:44] <tommy_> and xrandr
[03:45] <tommy_> windows has no problem doing it
[03:45] <tommy_> so I know its possible
[03:45] <MsMaco> its not the hardware. its likely the driver being stupid
[03:45] <MsMaco> which graphics chip do you have anyway?
[03:46] <tommy_> I don't think it knows what kind of display it is so it's just using generic settings
[03:46] <tommy_> not too sure to be honest
[03:46] <MsMaco> lspci
[03:46] <MsMaco> !pastebin
[03:46] <tommy_> hm?
[03:47] <MsMaco> pastebin the output of "lspci"
[03:47] <tommy_> !pastebin 00:00.0 Host bridge: Intel Corporation 82440MX Host Bridge (rev 01)
[03:47] <tommy_> 00:00.1 Multimedia audio controller: Intel Corporation 82440MX AC'97 Audio Controller
[03:47] <tommy_> 00:00.2 Modem: Intel Corporation 82440MX AC'97 Modem Controller
[03:47] <tommy_> 00:02.0 VGA compatible controller: Silicon Motion, Inc. SM712 LynxEM+ (rev a0)
[03:47] <tommy_> 00:03.0 CardBus bridge: O2 Micro, Inc. OZ6812 CardBus Controller (rev 05)
[03:47] <tommy_> 00:06.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01)
[03:47] <tommy_> 00:07.0 ISA bridge: Intel Corporation 82440MX ISA Bridge (rev 01)
[03:47] <tommy_> 00:07.1 IDE interface: Intel Corporation 82440MX EIDE Controller
[03:47] <tommy_> 00:07.2 USB Controller: Intel Corporation 82440MX USB Universal Host Controller
[03:47] <tommy_> 00:07.3 Bridge: Intel Corporation 82440MX Power Management Controller
[03:47] <tommy_> did that work?
[03:47] <MsMaco> you didnt actually read the output of the pastebin factoid, huh?
[03:47] <MsMaco> anyway....
[03:47] <tommy_> lol
[03:48] <MsMaco> silicon motion
[03:48] <tommy_> hows pastebin work
[03:49] <MsMaco> Ubuntu pastebin is at  http://paste.ubuntu.com
[03:49] <MsMaco> you paste stuff in the text box and hit submit. it gives you a link
[03:49] <MsMaco> you give us the link, and then we dont get 15 lines of stuff in the channel
[03:49] <tommy_> got it
[03:52] <tommy_> does that help any?
[03:53] <MsMaco> im asking a friend
[03:54] <bgamari> Honestly, I doubt I'll be very much
[03:54] <bgamari> help
[03:54] <MsMaco> you've a better chance of figuring out if the modeline's slightly wrong than i do
[03:54] <bgamari> it sounds as if you just need to throw a debugger on the xserver and figure out why the driver is failing
[03:55] <bgamari> You've checked the Xorg log, right?
[03:55] <MsMaco> no
[03:55] <MsMaco> didnt think about that
[03:55] <MsMaco> tommy_: this is ben.
[03:55] <tommy_> be prepared to walk me through this lol
[03:55] <MsMaco> he works on intel graphics, but i figured he might have some idea how X works in general...or at least a better idea than i do
[03:56] <tommy_> yeah I'm at a complete loss
[03:56] <bgamari> first look in /var/log/Xorg.log
[03:56] <MsMaco> bgamari: would a tail -f while doing the xrandr stuff we did before make sense?
[03:57] <bgamari> sure
[03:57] <MsMaco> tommy_: two terminals. in one "tail -f /var/log/Xorg.log"
[03:57] <MsMaco> in the other...do you still have the xrandr commands we did before?
[03:57] <tommy_> unfortunately not
[03:58] <MsMaco> ok
[03:58] <tommy_> xrandr doesn't even have 1024x768 as an option anymore
[03:58] <tommy_> after a restart it reset to default
[03:58] <MsMaco> xrandr --addmode "1024x768" "63.50  1024 1072 1176 1328  768 771 775 798 -hsync +vsync"
[03:58] <MsMaco> that was the mode we used
[03:58] <MsMaco> doh
[03:58] <MsMaco> that's newmode
[03:59] <MsMaco> then after that it was: xrandr --addmode default 1024x768
[03:59] <tommy_> that tail comand did nothing
[03:59] <MsMaco> itll show the end and follow it as the file changes
[03:59] <tommy_> just gave me a > prompt
[03:59] <MsMaco> so if theres a new error added to it, itll show it
[03:59] <MsMaco> hrm
[04:00] <MsMaco> and then "xrandr --mode default 1024x768" was the last part...where the error happened...
[04:00] <MsMaco> wiat.
[04:00] <MsMaco> it should be Xorg.0.log
[04:00] <MsMaco> not Xorg.log
[04:00] <tommy_> I've got xorg.r.log
[04:00] <tommy_> yeah
[04:00] <bgamari> Unfortunately I've got to run in 5 or so
[04:01] <MsMaco> bgamari: bedtime?
[04:01] <bgamari> Naw, need to go meet my girlfriend
[04:02] <tommy_> cannot find output 1024x768
[04:02] <MsMaco> output was default
[04:03] <MsMaco> bgamari: ah ok
[04:04] <tommy_> ok what did we do to get it to work before
[04:04] <tommy_> I got the tail working
[04:04] <MsMaco> did the name change from default to something else?
[04:04] <MsMaco> pastebin plain old "xrandr"'s output
[04:05] <tommy_> it's still called default
[04:05] <MsMaco> maybe if you put "" around the 1024x768?
[04:06] <tommy_> it was
[04:07] <tommy_> ok...
[04:07] <tommy_>  xrandr --addmode "1024x768" "63.50  1024 1072 1176 1328  768 771 775 798 -hsync +vsync"
[04:07] <tommy_> ?
[04:08] <tommy_> cannot find output
[04:09] <tommy_> what did we do last time
[04:09] <MsMaco> oh no no i said above "oops that shouldve been newmode"
[04:09] <tommy_> oooh gotcha
[04:09] <tommy_> hold o
[04:10] <tommy_> nothin
[04:10] <tommy_> it gave me the the whole xrandr command menu
[04:10] <tommy_> hold on less quotes
[04:12] <MsMaco> hola andresmujica
[04:12] <andresmujica> hola msmaco
[04:12] <andresmujica> maco as in mackenzie?
[04:12] <MsMaco> aye
[04:13] <tommy_> this isn't working
[04:13] <andresmujica> oui. hi, what's up?
[04:13] <tommy_> it just keeps giving me the proper syntax formatting thing for xrandr
[04:13] <MsMaco> trying to make his screen to 1024x768
[04:13] <tommy_> it's not recognizing how it's formatted
[04:13] <MsMaco> *do
[04:14] <MsMaco> are you copying and pasting my quotes?
[04:14] <tommy_> yes only I changed it to newmode
[04:14] <MsMaco> i think i have stupid curly quotes in my irc client...that could break things
[04:14] <MsMaco> or do they show as normal straight quotes when you look in your terminal?
[04:14] <tommy_> they're normal
[04:14] <tommy_> type it one more time :-)
[04:15] <tommy_> cause whatever you told me to do last time worked
[04:15] <MsMaco> well last time we named it 1024x768_60
[04:15] <MsMaco> i dont think the name should make a difference but *shrug*
[04:16] <tommy_> I'm lost
[04:16] <MsMaco> maybe xrandr --newmode "1024x768_60" "63.50  1024 1072 1176 1328  768 771 775 798 -hsync +vsync"
[04:16] <MsMaco> since thats what we did before the reboot
[04:17] <tommy_> it's not accepting your formatting
[04:17] <tommy_> for one reason or another
[04:18] <tommy_> should there be two spaces in those two spots?
[04:18] <MsMaco> its a copy and paste from my terminal...same as i pasted to you before
[04:19] <tommy_> well what the shit
[04:19] <tommy_> I don't get it
[04:21] <MsMaco> _xrandr --newmode "1024x768_60.00"
[04:21] <MsMaco> er without the _
[04:21] <MsMaco> and then "63.50  1024 1072 1176 1328  768 771 775 798 -hsync +vsync" the same
[04:21] <MsMaco> if the formatting of the name matters, i will be peeved
[04:22] <MsMaco> andresmujica: do you know how to work this xrandr thing?
[04:22] <andresmujica> tommy_ you can try http://xtiming.sourceforge.net/cgi-bin/xtiming.pl  and this http://www.arachnoid.com/modelines/   those can help you generate a working modeline.  However, i would try renaming the xorg.conf file so it gets autogenerated by the system itself.    i don't really use xrandr... the applet works good enough for me.. :)
[04:23] <MsMaco> andresmujica: its a new install and it only detected 640x480 and 800x600 by default
[04:23] <andresmujica> ohh..
[04:23] <andresmujica> sis video card.
[04:23] <MsMaco> so we're trying to add 1024x768 so the applet can do it
[04:23] <MsMaco> yes, sis
[04:23] <tommy_> it's not accepting it still
[04:23] <MsMaco> from what i recall *shudder*
[04:27] <tommy_> here I'm sending this entire thing to pastebin
[04:28] <tommy_> did you see it
[04:29] <MsMaco> you have to give me the link
[04:29] <tommy_> o
[04:29] <tommy_> http://paste.ubuntu.com/255515/
[04:30] <MsMaco> ok try without quotse then
[04:30] <tommy_> around anything?
[04:30] <MsMaco> yeah
[04:31] <andresmujica> yeap without the quotes
[04:32] <tommy_> bash: syntax error near unexpected token `;'
[04:32] <MsMaco> whys there a ; in it?
[04:33] <MsMaco> oh because you bumped it
[04:33] <andresmujica> xrandr --newmode 1024x768_60.0 63.50  1024 1072 1176 1328  768 771 775 798 -hsync +vsync
[04:33] <MsMaco> i can see it in the pastebin
[04:34] <tommy_> http://paste.ubuntu.com/255520/
[04:34] <MsMaco> oh it has got it in there
[04:34] <MsMaco> ok
[04:34] <MsMaco> xrandr --addmode default 1024x768_60.0
[04:36] <tommy_> http://paste.ubuntu.com/255521/
[04:36] <MsMaco> yay its associated with the output device now
[04:37] <MsMaco> so were at the point before where itd show in the applet
[04:37] <MsMaco> now lets see if Xorg.0.log says anything when you do this:
[04:37] <MsMaco> xrandr --output default --mode 1024x768_60.0
[04:37] <tommy_> I tried switching it through the gui
[04:38] <tommy_> screen blinked
[04:38] <tommy_> xrandr: Configure crtc 0 failed
[04:38] <tommy_> nothing changed in the log
[04:39] <MsMaco> :(
[04:39] <tommy_> I'm so confused
[04:39] <tommy_> it's like it tried and then said "F*CK YOU"
[04:40] <MsMaco> mmm yeah
[04:40] <MsMaco> by the way.... even without the "u" not really supposed to say that
[04:40] <tommy_> ok sorry
[04:40] <tommy_> just getting frustrated
[04:40] <MsMaco> well... getting around it with fsck is not too uncommon since thats an actual command...
[04:40] <MsMaco> anyway
[04:41] <tommy_> lol
[04:41] <MsMaco> ben's hypothesis was that the driver is screwing up
[04:41] <andresmujica> try generating the correct modeline with http://xtiming.sourceforge.net/cgi-bin/xtiming.pl  you'll need your monitor specs thou.  probably a freq thingie
[04:41] <MsMaco> yeah the modeline we tried was a generic 1024x768 one
[04:41] <MsMaco> maybe your screen is not-so-generic
[04:41] <tommy_> thats what xp says it is
[04:42] <MsMaco> no i mean in terms of those other numbers
[04:42] <MsMaco> 1024 1072 1176 1328  768 771 775 798 <- these ones
[04:42] <tommy_> oooh
[04:42] <MsMaco> and that 63.50 number
[04:42] <tommy_> so now how would I figure this out?
[04:42] <MsMaco> do what andres said
[04:43] <tommy_> k
[04:43] <andresmujica> behind you monitor you'll find a plate with some specs on it, or at least the monitor model, so you can check in google about the right specs for your monitor so it can be used by the xtiming.pl
[04:43] <MsMaco> laptop
[04:43] <MsMaco> lshw?
[04:43] <andresmujica> holly gosh.. i thought it was a CRT model...
[04:44] <MsMaco> *grumble* screws should be far more difficult to lose. then i wouldnt have half-put-together furniture
[04:45] <tommy_> Modeline "1024x768@0" 0.00 1024 1056 1056 1088 768 787 787 807
[04:45] <tommy_> thats what it spit out at me
[04:46] <andresmujica> hmm 0.00 ?
[04:46] <MsMaco> yeah thats what i was staring at
[04:46] <tommy_> yeah found that odd too
[04:46] <tommy_> should I try it on my other comp with xp?
[04:46] <tommy_> they're identical machines
[04:46] <MsMaco> well we're obviously on the same page
[04:47] <tommy_> but that ones actually running at 1024
[04:47] <tommy_> maybe that'll give me the right hrz
[04:47] <tommy_> khz*
[04:48] <andresmujica> take into account that the modeline potentially can cause DAMAGE to your computer.
[04:48] <MsMaco> if its wrong
[04:48] <tommy_> well we got it wrong once and it didn't blow up
[04:48] <tommy_> lol
[04:48] <tommy_> I've got like 8 of these anyway
[04:49] <andresmujica> so i'll recommend you to find the right specs for your laptop, so you can test with confidence..
[04:49] <tommy_> it I fry one it won't be that big of a deal
[04:49] <andresmujica> hehehe
[04:49] <tommy_> would it be documented anywhere?
[04:49] <andresmujica> i don't know if you can find that info in windows.
[04:50] <andresmujica> Yeap if it' s a laptop it should be available at the specs from the vendor
[04:50] <tommy_> lemme see if I can find it
[04:51] <tommy_> or see if you can find it before me
[04:51] <tommy_> lol
[04:55] <tommy_> 13.3 XGA(1024x768) TFT LCD
[04:55] <tommy_> is all I'm able to find
[04:57] <MsMaco> lshw maybe tell you the exact lcd model?
[04:57] <tommy_> whats that
[04:57] <tommy_> a command?
[04:59] <tommy_> http://paste.ubuntu.com/255531/
[05:00] <andresmujica> which one is the laptop?
[05:01] <tommy_> hm?
[05:02] <andresmujica> model/vendor
[05:02] <tommy_> IBM ThinkPad iSeries 1300 7WU
[05:03] <tommy_> 1300 1171-7WU
[05:07] <tommy_> found it
[05:07] <andresmujica> oh well.. time to go.  didn't find anything valuable in google.. :(  i'll keep trying different modelines (anyway it should be autodetected, so it must be a bug somewhere around..)
[05:07] <andresmujica> what did u found?
[05:07] <tommy_> http://www.broadbandreports.com/forum/remark,14829837
[05:08] <andresmujica> yeap, but it's with a trident card..
[05:08] <andresmujica> but its worth a try.
[05:08] <andresmujica> good luck!!
[05:08] <tommy_> oh
[05:08] <tommy_> hm
[05:08] <tommy_> well I'll poke around
[05:08] <tommy_> so I'd just do those commands again
[05:08] <tommy_> only with new values?
[05:09] <andresmujica> why don't you try with some livecd's, maybe one of them gives the right config... (jaunty, hardy, karmic4)
[05:09] <andresmujica> so we can chase down the bug.
[05:10] <tommy_> actually
[05:10] <tommy_> I had DSL loaded on here
[05:10] <tommy_> and it worked fine
[05:10] <tommy_> say I stuck in the liveCD for that, how would I find the value, just do xrandr ?
[05:10] <andresmujica> g'night.. see ya msmaco.. ahh Damn Small, try using that xorg.conf  get it from there!!! you've got the solution!
[05:11] <tommy_> just view the file?
[05:11] <MsMaco> save it to a flash drive
[05:11] <MsMaco> and copy it over
[05:11] <MsMaco>  /etc/X11/xorg.conf
[05:11] <tommy_> ok great
[05:11] <tommy_> lemme go find the cd and boot it in a twin machine
[05:12] <tommy_> I"ll be back in 2
[05:15] <tommy_> ok dsl is booting from cd
[05:18] <tommy_> ok now I'm lost
[05:31] <tommy_> still here ms?
[05:33] <tommy_> anyone here?
[06:02] <tommy_> hellllo?
[06:19] <tommy_> andreas
[06:20] <tommy_> or duke
[06:20] <tommy_> or anyone
[06:20] <Duke`> ?
[06:21] <tommy_> I need help
[06:21] <tommy_> I've got a laptop, and can't get the resolution high enough to fill the entire viewing area
[06:21] <tommy_> I've got 1" frames on all sides
[06:22] <Duke`> which resolution?
[06:22] <tommy_> the highest I'm able to go is 800x600
[06:22] <tommy_> I need it at 1024x768
[06:23] <tommy_> I was able to get this far with it ... http://paste.ubuntu.com/255557/
[06:23] <Duke`> what is screen size?
[06:23] <tommy_> 13.3
[06:23] <tommy_> check out that paste bin and see if you can help me at all
[06:23] <tommy_> I'm very new to linux I dunno much
[06:24] <Duke`> I'm not good at modelines, so I can't tell you if it's correct
[06:24] <Duke`> are you sure your laptop can to 1024?
[06:24] <Duke`> *can do
[06:24] <tommy_> I loaded a live CD of DamnSmallLinux and it loaded fine at 1024x768 full screened, but I dunno where I can find the settings at
[06:24] <tommy_> yes positive
[06:24] <MsMaco> he used a script to get a modeline, but it gave 0.00 clock rate...which...er...
[06:24] <tommy_> I've got an identicle machine next to me
[06:24] <tommy_> it's running at 1024
[06:24] <MsMaco> DSL shouldve had the xorg.conf in /etc/X11/xorg.conf
[06:24] <MsMaco> if you copy it from DSL to Ubuntu it should work
[06:24] <tommy_> that file doesn't exist
[06:25] <Duke`> you can write at<EMAIL_ADDRESS>describing your problem
[06:25] <MsMaco> DSL uses XFree86, doesnt it?
[06:25] <MsMaco> instead of X11?
[06:25] <tommy_> I dunno it's got an X11 dir
[06:25] <Duke`> MsMaco: maybe an older driver
[06:25] <tommy_> just no xorg.conf
[06:26] <Duke`> so not so old...
[06:26] <tommy_> someone told me to create one with some code
[06:26] <tommy_> but being a live cd there's no file writing capability
[06:27] <tommy_> theres no way to get the values from it without that file?
[06:28] <Duke`> try looking in /var/log/Xorg.0.log
[06:29] <tommy_> I may have just found something
[06:29] <tommy_> http://www.perimeterless.org/?p=106
[06:30] <tjaalton> eww, siliconmotion
[06:30] <MsMaco> haha
[06:30] <MsMaco> that looks kinda like andres's reaction too
[06:31] <tjaalton> logfile would still be helpful
[06:31] <tommy_> hahaha
[06:31] <tommy_> it doesn't kick anything to the log
[06:31] <tjaalton> Xorg.0.log?
[06:31] <tommy_> never changed
[06:31] <tjaalton> sorry, don't believe you ;)
[06:31] <tommy_> lol
[06:32] <MsMaco> tjaalton: had him tail -f it while he set it up with xrandr
[06:32] <MsMaco> on ubuntu, i mean
[06:32] <tjaalton> xrandr doesn't matter
[06:32] <tjaalton> the driver doesn't support randr-1.2 anyway
[06:32] <MsMaco> well we were doing --addmode and --newmode stuff
[06:32] <tjaalton> I'm interested in why it fails to set the native mode, and that's in the logfile
[06:33] <tommy_> I'll paste bin it hold on
[06:33] <MsMaco> tjaalton: fails to set? it doesnt offer the native mode at all....
[06:34] <MsMaco> or do you mean after we added the mode?
[06:34] <tommy_> hsync out of range
[06:34] <tommy_> for 1024x768
[06:34] <tjaalton> MsMaco: it should start with that mode, no?
[06:34] <tjaalton> tommy_: right, full log please
[06:35] <tommy_> http://paste.ubuntu.com/255560/
[06:35] <MsMaco> tjaalton: im not sure what order X tries to do things, i just know its not detecting the native range as even being something the screen can do
[06:35] <tommy_> thats not the full log
[06:35] <tommy_> everything silicone motion related tho
[06:35] <MsMaco> tjaalton: so we were playing with xrandr trying to convince X that yes, the screen really can do that
[06:35] <tommy_> and then some
[06:36] <tjaalton> MsMaco: but you can't tell the server what the monitor can do, other than via xorg.conf
[06:37] <tjaalton> just force the monitor values to xorg.conf and it should be fine
[06:37] <tjaalton> it's still a bug though
[06:37] <tjaalton> DSL probably forced the range
[06:37] <tommy_> like it said to do in that link I sent?
[06:37] <tjaalton> would be nice to know though
[06:37] <tjaalton> tommy_: yes
[06:37] <tommy_> ok I'm gonna give it a shot
[06:37] <tommy_> I'll be back
[06:39] <tommy_> hm
[06:40] <tommy_> there's absolutely nothing in my monitor section
[06:40] <tjaalton> so create one
[06:40] <tommy_> should i just add the parts in bold like it said to or add all those values
[06:41] <tommy_> stupid question
[06:41] <tommy_> don't answer that
[06:41] <tommy_> lol
[06:41] <tjaalton> put everything from that blog to an empty file, and replace your current conffile with it
[06:42] <tjaalton> well, not everything..
[06:42] <tommy_> it won't let me save
[06:42] <tjaalton> surely you must be root
[06:42] <tjaalton> sudo -i/-s
[06:45] <tommy_> how do I save in nano
[06:45] <tjaalton> ctrl-x
[06:45] <tjaalton> to exit
[06:45] <tommy_> saves on exit?
[06:45] <tjaalton> it'll ask..
[06:45] <tommy_> heard
[06:45] <tommy_> thanks
[06:46] <tommy_> ok restart
[06:46] <tommy_> wish me luck
[06:51] <tommy> PERFECT
[06:51] <Guest35750> thanks everyone
[06:51] <tjaalton> good
[06:52] <Guest35750> why am I guest now?
[06:52] <Guest35750> lol
[06:52] <tommy_> there
[06:53] <tommy_> but yes thank you very very very much
[06:53] <MsMaco> yay!
[06:53] <tommy_> god that was a headache lol
[06:53] <MsMaco> tjaalton: thank you for making up for my failure
[06:54] <tommy_> mainly from staring at such a tiny screen trying to read
[06:55] <tjaalton> MsMaco: np
[06:56] <tommy_> thanks both of you
[06:56] <tommy_> life savers!
[06:56] <tommy_> I can finally goto bed now
[06:56] <tommy_> lol
[07:44] <bryce> heya tjaalton
[07:50] <tjaalton> hey bryce
[07:59] <bryce> tjaalton, have you gotten any info on when mesa 7.6 is likely to come?  or any rc's?
[08:00] <bryce> tjaalton, I'm wondering pretty strongly if it'd make sense to pull in a git snapshot for now maybe
[08:01] <tjaalton> bryce: no idea, haven't seen any talk about that
[08:04] <tjaalton> I think there's going to be 7.5.1 before any 7.6rc
[08:06] <bryce> I heard a rumor it might not be until mid/late september for 7.6 at the earliest
[08:06] <bryce> so maybe getting too late for karmic
[08:10] <tjaalton> might be
[10:46] <Ng> http://blogs.gnome.org/hughsie/2009/08/17/gnome-power-manager-and-blanking-removal-of-bodges/
[10:46] <Ng> I can't remember if I pasted that yet or not. it's been on my todo list to do so and wasn't removed ;)
[11:12] <bryce> Ng, christ that sounds complicated
[11:12] <Ng> bryce: I came away with a headache, and the nugget of fact that there are patches that make it all play nicely ;)
[11:13] <bryce> well, in theory ;-)
[11:15] <bryce> urf reading the comments again the old saw comes up that "xorg needs more developers"
[11:16] <bryce> xorg has plenty of developers, it's just that they're implementing features instead of attending to their bug reports
[11:17] <bryce> (well, in general; -intel often does good, as do other pockets here and there)
[11:17] <jcristau> plenty of developers, really?
[11:17] <bryce> jcristau, yeah, most of the bugs/bugfixes we see are outcomes of regressions caused by feature development, moreso than say just new hardware or longstanding regressions
[11:18] <bryce> jcristau, it's the same situation I see in inkscape
[11:19] <bryce> just piling on more developers doesn't make bugs go away, rather it means you get a higher rate of feature work, which means you get *more* bugs
[11:19] <bryce> of course, if the new features actually work, that's nice, once the bugs get worked out ;-)
[11:21] <bryce> anyway, it irritates me when I see "distros need to be providing more developers to help xorg".  It's more QA that's needed.
[11:22] <jcristau> yes.  qa isn't just done by machines though ;)
[11:25] <bryce> that's not entirely always true.  ;-)
[11:25] <bryce> anyway, it's well past time for bed.  nite.
[11:26] <jcristau> bye
[13:03] <diverse_izzue> i have a problem with dual screen on karmic. if use use two screens such that the primary screen doesn't change (that is external screen right of internal), everything works fine. If i place the external screen left of the internal one so that it becomes the primary screen, i have some trouble.
[13:03] <diverse_izzue> a) i cannot place the gnome panel on the other screen
[13:03] <diverse_izzue> b) the primary screen doesn't adjust its size to the dimension of the external monitor, so if i maximize windows they become too large.
[18:40] <bryce> Ng, stuck that second patch into xserver, thanks for mentioning it to me
[18:41] <Ng> win
[18:41] <Ng> I will now claim full credit for karmic being awesome ;)
[18:41] <Ng> I mean, thanks!
[18:45] <tjaalton> I'd be happy if the screensaver worked
[18:45] <tjaalton> maybe this will help
[18:45] <bryce> tjaalton, how's it not working?
[18:46] <tjaalton> bryce: it doesn't kick in
[18:46] <tjaalton> the screen just stays on forever
[18:46] <bryce> I've seen that on my laptop, but it's very intermittent
[18:46] <bryce> sometimes it works, sometimes not
[18:46] <tjaalton> maybe it works until I suspend the first time
[18:46] <tjaalton> happens both on my laptop and desktop
[18:47] <bryce> I get the same on my desktop come to think of it... sometimes the screen blanks on its own, sometimes it stays on forever
[18:47] <bryce> heisensaver
[18:48] <tjaalton> yeah
[20:02] <Q-FUNK> howdy!
[20:02] <Q-FUNK> can anybody sync -geode from debian?
[20:03] <Q-FUNK> minor fix cherry-picked from git
[20:03] <Q-FUNK> or well, the patch is small but the benefit significant:  restores usability on GX2 hardware
[20:12] <Q-FUNK> it simply disables the buggy EXA support in the GX driver, which makes it fall back on XAA.
[20:16] <tjaalton> use requestsync
[20:26] <Q-FUNK> doesn't work
[20:26] <Q-FUNK> change logs appear to be out of sync on the server
[20:29] <tjaalton> well, no-one here can sync it
[20:34] <Q-FUNK> ok


[03:26] <DNS> hi:) can some1 please check whats wrong with that import → https://code.launchpad.net/~rbose-vcs-imports/emacs/trunk i can not see any error in the log or what could be wrong
[03:31] <wgrant> DNS: There's nothing wrong
[03:31] <wgrant> It's just importing gradually, 30000 revisions at a time
[03:31] <wgrant> Rather than trying to convert potentially hundreds of thousands or millions of revisions at once
[03:32] <DNS> but there are no files after "job is finished"?
[03:34] <wgrant> They'll be available after the initial import is done, once the jobs start finishing completely (a green tick, rather than a grey partial success)
[03:36] <DNS> ah i think i understand now:)
[03:39] <DNS> wgrant: thx for the info
[03:39] <wgrant> np
[03:42] <DNS> wgrant: btw i filed a bug about 2 weeks ago not sure if you saw my reply: https://bugs.launchpad.net/launchpad/+bug/1078172 the mc packages for example are from 2011-07-23, so i wonder if that is related to bug https://bugs.launchpad.net/launchpad/+bug/1071562
[03:44] <StevenK> It takes two weeks for binaries to fully expire out
[03:45] <DNS> but those are deleted in 2011?
[03:45] <DNS> and still shown?
[03:46] <DNS> i tried to delete them again thats why a new date is shown
[03:53] <DNS> ok sorry im confused, it seems those files werent deleted in 2011 but should be more than 2 weeks ago now :x
[04:00] <DNS> and https://launchpad.net/~dns/+archive/sound/+delete-packages?field.name_filter=gmidi&field.status_filter=superseded&field.series_filter= says it had a "Removal requested on 2012-03-03." so i wonder a bit
[04:00] <DNS> why this is still shown
[04:13] <wgrant> DNS: Things will be shown there until their files are actually removed, which most often happens if there are binaries left over (in which case you'll need to redelete), or if the source is published in another series too
[04:21] <DNS> wgrant: ok, thx again for info :)
[05:18] <ebergen> hooray for the ability to change a username
[06:04] <profzoom> I'm trying to request a merge of a branch.  The documentation says there should be a "Propose for merging into another branch" link on the branch page, but I can't find it anywhere.  Could anyone point me in the right direction?
[06:06] <wgrant> profzoom: Which page are you looking at?
[06:10] <profzoom> https://code.launchpad.net/~profzoom/+junk/wmaker
[06:10] <profzoom> I'm trying to request that it be merged into the wmaker package
[06:32] <wgrant> profzoom: Ah, +junk branches aren't related to a project or package, so you can't propose them for merging. You might want to push to eg. lp:~profzoom/ubuntu/quantal/wmaker/bug-1079925 instead.
[06:32] <wgrant> That way it will be mergable into other wmaker branches
[10:07] <shadeslayer> would it be possible for someone to rescore a small build for me? it's a 5 minute build and I'll have to wait an hour before it gets built
[10:07] <shadeslayer> kind of blocking my work :P
[10:08] <shadeslayer> https://launchpad.net/~netrunner-os/+archive/build/+build/4018538
[10:11] <czajkowski> an hour isn't that bad compared to others.
[10:11] <czajkowski> but will see
[10:17] <shadeslayer> czajkowski: thanks :)
[10:21] <czajkowski> StevenK: could you help out please with this ppa increase
[10:21] <czajkowski> I've tried to bump the score but nothing changed.
[10:21] <StevenK> It didn't work, I've done so
[10:22] <czajkowski> StevenK: cheers
[10:31] <shadeslayer> StevenK: czajkowski thanks alot!
[12:18] <Laney> https://launchpadlibrarian.net/124313309/buildlog_ubuntu-raring-i386.libubuntuone_4.0.0-0ubuntu2%7Eubuntu13.04.1_FAILEDTOBUILD.txt.gz
[12:18] <Laney> sad PPA buildd?
[12:30] <geser> "Unrecognized character \x06 at /home/buildd/.sbuildrc line 1." nice error
[14:33] <oerdnj> hi, akhlut builds are broken, do you already know it or should I report it somewhere?
[14:37] <oerdnj> says: Unrecognized character \x06 at /home/buildd/.sbuildrc line 1.
[14:44] <czajkowski> oerdnj: we know
[14:44] <oerdnj> czajkowski: ok, cool, goot to know. no need to report bug then... thanks for the answer
[17:14] <vankooch> Hi, I've uploaded a package to launchpad… but I've problems.. to get it build there… it builds correct on i386 but does fail on amd64. Locally I only have a amd64, and it builds there without any problems on a clean vm and on my dev machine. A friend also tried to build it locally on his amd64 machine without any problems. All have been tested on 12.04. Can someone please help me?
[17:14] <vankooch> that is the log: https://launchpadlibrarian.net/124266893/buildlog_ubuntu-precise-amd64.yate_4.2.1-ubuntu1-sico1~precise_FAILEDTOBUILD.txt.gz
[22:46] <xnox> launchpad has an interesting interpretation of release milestones
[22:46] <xnox> https://launchpad.net/procenv/+series
[22:48] <wgrant> xnox: What do you mean? Those were manually created by the project maintainer
[22:48] <xnox> wgrant: sure, but the ordering is intersting it's neither: numeric, alphabetic, chronological
[22:49] <xnox> wgrant: on the graph.
[22:49] <wgrant> It's going to be a little confused by the v being added in some of the milestone names
[22:49] <wgrant> I've never seen a project do that before
[22:49] <xnox> wgrant: the latest releases for the trunk paragraph below is correct (reverse chronological?!)
[22:50] <xnox> wgrant: sure. it's peculiar =) but the project is FTBFS across 12 architectures on debian and each 'release' tried to fix some of them to uncover more problems.
[22:51] <wgrant> Sure, but that doesn't explain why the version scheme grew a 'v' at the start recently :)
[22:51] <wgrant> Changing that half way through is likely to confuse things, so I can't really blame LP for beings somewhat confused.
[22:57] <xnox> wgrant: do you want this bug of questionable value, or will you remember this as an omg "funny things launchpad users do" =)))))
[22:57] <wgrant> We have enough bugs already, but if you really want to file it you can
[22:57] <wgrant> I'd suggest just making the milestone naming consistent, though!
[22:58] <maxb> Perhaps the bug should be "LP should document how it handles milestone ordering on the milestone creation form"


[04:32] <gevreeen> is this service subject to us export restrictions?
[11:29] <cjwatson> gevreeen: I am not a lawyer, but Launchpad is not hosted in the US so it seems difficult to see how it could be
[11:30] <cjwatson> gevreeen: (though, for completeness, some parts of the build farm are hosted in the US, specifically arm64, ppc64el, and s390x builders)