[10:25] <ws2k3> anyone around?
[10:26] <ws2k3> im trying to find out why a upstart service is not starting after boot. when i start it manualy it works just fine. there is also no .log file in /var/log/upstart anyone an idea on how to debug?


[13:41] <mynameismevin> wow. I see like 4 of my current/past coworkers in this group.
[13:41] <mynameismevin> small world.


[00:33] <RAOF> Urgh, autopackagtests.
[00:34] <vorlon> urgh? :)
[00:36] <RAOF> Every SRU I look at releasing is blocked on autopkgtests which look like they might not be false-positives..
[00:36] <RAOF> But also, autopkgtests continue to be a flood of false-positives.
[00:37] <vorlon> hmm
[00:37] <vorlon> I must have stockholm syndrome
[00:37] <vorlon> the rate of false-positives is higher than I want (because I want it to be 0) but I wouldn't have called it a flood
[00:38] <RAOF> And not just random universe packages; apt is blocked because apport's autopkgtests are broken in a way that looks like it's probably a false-positive, maybe?
[00:39] <vorlon> yeah I was just noticing that and I suspect it might be "regressed in release" rather than false-positive
[00:39] <RAOF> Right, but for apt that's a false-positive.
[00:39] <vorlon> well, yes
[00:39] <vorlon> step 1) get autopkgtests running continuously in a loop
[00:40] <vorlon> but also, juliank evidently retried apport's autopkgtest against the release pocket but nobody told us to hint it :)
[00:41] <vorlon> adding hint now
[01:22] <RAOF> What is it with people uploading SRUs to Bionic and Disco, but not Cosmic?
[01:22] <RAOF> 058813
[05:19] <tjaalton> bdmurray: thanks for reviewing mesa, turns out that the dropped patch was actually cruft in the source root dir, so was meant to be dropped :P
[05:25] -queuebot:#ubuntu-release- Unapproved: mesa (disco-proposed/main) [19.0.2-1ubuntu1 => 19.0.2-1ubuntu1.1] (core, xorg)
[06:07] <jamespage> vorlon: upstream == ceph project itself in this case
[06:07] <jamespage> it is a bit of a nebulous comment I agree
[06:58] <juliank> vorlon, RAOF apt/denial? I uploaded a fixed apport, hence did not ask for an unblock.
[06:59] <juliank> Um, s/denial/xenial/
[07:04] <RAOF> juliank: Ah, yes.
[07:05] <RAOF> juliank: That upload would appear to address only one of the two autopkgtest failures, though?
[07:08] <juliank> RAOF: well, it worked when I uploaded it. Apparently a PPA used in tests has been removed in the meantime?
[07:08] <juliank> ~fooser/+archive/ubuntu/bar-ppa
[07:08] <RAOF> Plausibly? The other failure was failing to find a specific set of packages on Launchpad, IIRC.
[07:08] <juliank> I can't open ~fooser, so I assume it's gone
[07:09] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.38 => 2.39.2] (desktop-core, ubuntu-server)
[07:09] <juliank> WARNING: cannot connect to: https://api.launchpad.net/devel/ubuntu/+archive/primary/?ws.op=getPublishedBinaries&binary_name=unity-services&version=7.2.5+14.04.20150521.1-0ubuntu1&exact_match=true
[07:09] <juliank> I think that's the issue
[07:10] <RAOF> Seems right.
[07:10] -queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.38+18.04 => 2.39.2+18.04] (desktop-core, ubuntu-server)
[07:11] <juliank> These launchpad tests are so flaky
[07:11] -queuebot:#ubuntu-release- Unapproved: snapd (cosmic-proposed/main) [2.38+18.10 => 2.39.2+18.10] (desktop-core, ubuntu-server)
[07:11] -queuebot:#ubuntu-release- Unapproved: snapd (disco-proposed/main) [2.38+19.04 => 2.39.2+19.04] (core)
[07:11] <juliank> Usually the error here is launchpad timing out
[07:11] <juliank> Because it's doing stuff
[07:13] <juliank> It's unclear if the last two runs were just unlucky or if there's another issue now
[07:25] <RAOF> Darn tests interacting with external services!
[08:04]  * apw looks at snapd
[08:33] <LocutusOfBorg> hello AA please remove circlator NBS proposed thanks https://bugs.launchpad.net/ubuntu/+source/circ
[08:33] <LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/circlator/+bug/1828408
[08:35] <cjwatson> juliank: That request is pretty expensive.  Can you use either ordered=false or order_by_date=true?
[08:35] <cjwatson> (potentially expensive anyway)
[08:50] <juliank> cjwatson: Hmm, probably.
[08:51] <juliank> cjwatson: Should it return an empty list though? unity 7.2.5+14.04.20150521.1-0ubuntu1 certainly exists, but I get back {"total_size": 0, "start": 0, "entries": []}
[08:52] <juliank> What we're trying to figure out is the deb file for a given binary package name, version, arch
[08:53] <juliank> It returns empty even for 7.2.6+14.04.20160408-0ubuntu1 , which is currently in trusty-updatesd
[08:54] <juliank> oops, + URL encoding
[08:58] <juliank> So, RAOF , these failures seem to be communication issues w/ launchpad timing out - I just ran it locally and it failed for qemu-utils, but not unity-services
[09:00] <juliank> maybe we should write a dummy launchpad for testing, I don't know
[09:00] <juliank> or just mock launchpad in urlopen
[09:15] <cjwatson> juliank: Are you just trying to download the .deb?
[09:16] <juliank> cjwatson: So, the function parsing this currently returns the URL of the deb and its sha1
[09:16] <juliank> I mean, we do want some assurance the deb is not broken optimally I guess
[09:16] <cjwatson> juliank: Have you considered https://launchpad.net/ubuntu/+archive/primary/+files/unity-services_7.2.5+14.04.20150521.1-0ubuntu1_amd64.deb ?
[09:17] <juliank> cjwatson: I see two problems: (1) we don't get a hash and (2) we have to try up to two times, for Architecture: all
[09:18] <cjwatson> We could consider adding headers to librarian responses giving the hash, perhaps
[09:18] <juliank> though not sure about (2)
[09:18] <cjwatson> (2) would still be cheaper than making fairly expensive API requests, I'm sure
[09:19] <juliank> yup
[09:20] <juliank> the header trick for (1) is probably OK, but requires some refactoring on the client
[09:20] <juliank> as it currently uses APT'S builtin hash support
[09:20] <juliank> that is, it stores the hash in the download item, so apt verifies it while downloading
[09:21] <cjwatson> However, for purposes of integrity, I think it would be sufficient to check the size to guard against short responses; you can rely on TLS for the rest
[09:21] <cjwatson> In this particular case
[09:21] <cjwatson> Check the size against Content-Length, that is
[09:21] <juliank> apt does that already
[09:22] <juliank> ah, but one problem with re-trying for arch: all is that we build a queue of all items to fetch and then fetch them
[09:22] <juliank> so some would fail and we'd have to retry those
[09:22] <juliank> that's not entirely optimal
[09:22] <cjwatson> It's possible this strategy doesn't work, I just wanted to know if you'd considered it since in some ways it's simpler
[09:24] <cjwatson> Certainly if this is in test code then I think you should mock LP
[12:14] -queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.26 => 1.3.1-1ubuntu10.27] (ubuntu-server, virt)
[12:16] <cpaelzer__> coreycb: ^^ FYI
[12:17] <coreycb> cpaelzer: thanks!
[13:16] -queuebot:#ubuntu-release- Unapproved: lvm2 (bionic-proposed/main) [2.02.176-4.1ubuntu3 => 2.02.176-4.1ubuntu<IP_ADDRESS>] (core)
[14:44] -queuebot:#ubuntu-release- Unapproved: neutron (cosmic-proposed/main) [2:13.0.2-0ubuntu3.3 => 2:13.0.3-0ubuntu1] (openstack, ubuntu-server)
[16:11] -queuebot:#ubuntu-release- Unapproved: binutils (cosmic-proposed/main) [2.31.1-6ubuntu1.1 => 2.31.1-6ubuntu1.2] (core) (sync)
[16:12] -queuebot:#ubuntu-release- Unapproved: eclipse-titan (cosmic-proposed/universe) [6.3.1-1build4.1 => 6.3.1-1build4.2] (no packageset) (sync)
[16:12] -queuebot:#ubuntu-release- Unapproved: gcc-7 (cosmic-proposed/main) [7.4.0-1ubuntu1~18.10 => 7.4.0-1ubuntu1~18.10.1] (core) (sync)
[16:13] -queuebot:#ubuntu-release- Unapproved: gcc-7-cross (cosmic-proposed/universe) [26ubuntu1.1 => 26ubuntu1.2] (no packageset) (sync)
[16:14] -queuebot:#ubuntu-release- Unapproved: gcc-7-cross-ports (cosmic-proposed/universe) [21ubuntu1.1 => 21ubuntu1.2] (no packageset) (sync)
[16:14] -queuebot:#ubuntu-release- Unapproved: gcc-8 (cosmic-proposed/main) [8.3.0-6ubuntu1~18.10 => 8.3.0-6ubuntu1~18.10.1] (core) (sync)
[16:15] -queuebot:#ubuntu-release- Unapproved: gcc-8-cross (cosmic-proposed/main) [21ubuntu1.1 => 21ubuntu1.2] (ubuntu-desktop) (sync)
[16:16] -queuebot:#ubuntu-release- Unapproved: gcc-8-cross-ports (cosmic-proposed/universe) [12ubuntu1.1 => 12ubuntu1.2] (no packageset) (sync)
[16:16] -queuebot:#ubuntu-release- Unapproved: gcc-defaults (cosmic-proposed/main) [1.179ubuntu1.1 => 1.179ubuntu1.2] (core) (sync)
[16:17] -queuebot:#ubuntu-release- Unapproved: gcc-defaults-ports (cosmic-proposed/universe) [1.178ubuntu1.1 => 1.178ubuntu1.2] (no packageset) (sync)
[16:17] -queuebot:#ubuntu-release- Unapproved: ggcov (cosmic-proposed/universe) [0.9+20190314-0ubuntu1~18.10 => 0.9+20190314-0ubuntu1~18.10.1] (no packageset) (sync)
[16:18] -queuebot:#ubuntu-release- Unapproved: binutils (bionic-proposed/main) [2.30-21ubuntu1~18.04.1 => 2.30-21ubuntu1~18.04.2] (core) (sync)
[16:18] -queuebot:#ubuntu-release- Unapproved: gcc-7 (bionic-proposed/main) [7.4.0-1ubuntu1~18.04 => 7.4.0-1ubuntu1~18.04.1] (core) (sync)
[16:19] -queuebot:#ubuntu-release- Unapproved: eclipse-titan (bionic-proposed/universe) [6.3.1-1build1.2 => 6.3.1-1build1.3] (no packageset) (sync)
[16:19] -queuebot:#ubuntu-release- Unapproved: gcc-7-cross (bionic-proposed/main) [21ubuntu0.2 => 21ubuntu0.3] (ubuntu-desktop) (sync)
[16:20] <sil2100> It's the -security-only rebuilds if anything, I'm handling those ^
[16:20] -queuebot:#ubuntu-release- Unapproved: gcc-7-cross-ports (bionic-proposed/universe) [17ubuntu0.2 => 17ubuntu0.3] (no packageset) (sync)
[16:20] -queuebot:#ubuntu-release- Unapproved: gcc-8 (bionic-proposed/main) [8.3.0-6ubuntu1~18.04 => 8.3.0-6ubuntu1~18.04.1] (core) (sync)
[16:21] <sil2100> (-security-only rebuilds of toolchain packages for b/c)
[16:21] -queuebot:#ubuntu-release- Unapproved: gcc-8-cross (bionic-proposed/main) [18ubuntu0.3 => 18ubuntu0.4] (ubuntu-desktop) (sync)
[16:22] -queuebot:#ubuntu-release- Unapproved: gcc-8-cross-ports (bionic-proposed/universe) [9ubuntu0.3 => 9ubuntu0.4] (no packageset) (sync)
[16:22] -queuebot:#ubuntu-release- Unapproved: gcc-defaults (bionic-proposed/main) [1.176ubuntu2.2 => 1.176ubuntu2.3] (core) (sync)
[16:23] -queuebot:#ubuntu-release- Unapproved: gcc-defaults-ports (bionic-proposed/universe) [1.176ubuntu1.2 => 1.176ubuntu1.3] (no packageset) (sync)
[16:23] -queuebot:#ubuntu-release- Unapproved: ggcov (bionic-proposed/universe) [0.9+20190314-0ubuntu1~18.04 => 0.9+20190314-0ubuntu1~18.04.1] (no packageset) (sync)
[16:23] -queuebot:#ubuntu-release- Unapproved: accepted binutils [sync] (cosmic-proposed) [2.31.1-6ubuntu1.2]
[16:24] -queuebot:#ubuntu-release- Unapproved: accepted eclipse-titan [sync] (cosmic-proposed) [6.3.1-1build4.2]
[16:26] -queuebot:#ubuntu-release- Unapproved: accepted gcc-7 [sync] (cosmic-proposed) [7.4.0-1ubuntu1~18.10.1]
[16:27] -queuebot:#ubuntu-release- Unapproved: accepted gcc-7-cross [sync] (cosmic-proposed) [26ubuntu1.2]
[16:27] -queuebot:#ubuntu-release- Unapproved: accepted gcc-7-cross-ports [sync] (cosmic-proposed) [21ubuntu1.2]
[16:29] -queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross [sync] (cosmic-proposed) [21ubuntu1.2]
[16:29] -queuebot:#ubuntu-release- Unapproved: accepted gcc-8 [sync] (cosmic-proposed) [8.3.0-6ubuntu1~18.10.1]
[16:29] -queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross-ports [sync] (cosmic-proposed) [12ubuntu1.2]
[16:30] -queuebot:#ubuntu-release- Unapproved: accepted gcc-defaults [sync] (cosmic-proposed) [1.179ubuntu1.2]
[16:30] -queuebot:#ubuntu-release- Unapproved: accepted gcc-defaults-ports [sync] (cosmic-proposed) [1.178ubuntu1.2]
[16:32] -queuebot:#ubuntu-release- Unapproved: accepted ggcov [sync] (cosmic-proposed) [0.9+20190314-0ubuntu1~18.10.1]
[16:33] -queuebot:#ubuntu-release- Unapproved: accepted binutils [sync] (bionic-proposed) [2.30-21ubuntu1~18.04.2]
[16:33] -queuebot:#ubuntu-release- Unapproved: accepted eclipse-titan [sync] (bionic-proposed) [6.3.1-1build1.3]
[16:34] -queuebot:#ubuntu-release- Unapproved: accepted gcc-7 [sync] (bionic-proposed) [7.4.0-1ubuntu1~18.04.1]
[16:34] -queuebot:#ubuntu-release- Unapproved: accepted gcc-7-cross [sync] (bionic-proposed) [21ubuntu0.3]
[16:35] -queuebot:#ubuntu-release- Unapproved: accepted gcc-7-cross-ports [sync] (bionic-proposed) [17ubuntu0.3]
[16:36] -queuebot:#ubuntu-release- Unapproved: accepted gcc-8 [sync] (bionic-proposed) [8.3.0-6ubuntu1~18.04.1]
[16:37] -queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross [sync] (bionic-proposed) [18ubuntu0.4]
[16:37] -queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross-ports [sync] (bionic-proposed) [9ubuntu0.4]
[16:38] -queuebot:#ubuntu-release- Unapproved: accepted gcc-defaults [sync] (bionic-proposed) [1.176ubuntu2.3]
[16:38] -queuebot:#ubuntu-release- Unapproved: accepted gcc-defaults-ports [sync] (bionic-proposed) [1.176ubuntu1.3]
[16:39] -queuebot:#ubuntu-release- Unapproved: accepted ggcov [sync] (bionic-proposed) [0.9+20190314-0ubuntu1~18.04.1]
[18:22] -queuebot:#ubuntu-release- Unapproved: curtin (bionic-proposed/main) [18.2-10-g7afd77fa-0ubuntu1~18.04.1 => 19.1-7-g37a7a0f4-0ubuntu1~18.04.1] (ubuntu-desktop, ubuntu-server)
[18:26] -queuebot:#ubuntu-release- Unapproved: curtin (xenial-proposed/main) [18.2-10-g7afd77fa-0ubuntu1~16.04.1 => 19.1-7-g37a7a0f4-0ubuntu1~16.04.1] (ubuntu-server)
[18:46] -queuebot:#ubuntu-release- Unapproved: curtin (cosmic-proposed/main) [18.2-10-g7afd77fa-0ubuntu1~18.10.1 => 19.1-7-g37a7a0f4-0ubuntu1~18.10.1] (ubuntu-desktop, ubuntu-server)
[18:55] -queuebot:#ubuntu-release- Unapproved: curtin (disco-proposed/main) [18.2-22-g08bf6ff7-0ubuntu1 => 19.1-7-g37a7a0f4-0ubuntu1~19.04.1] (ubuntu-desktop, ubuntu-server)
[20:10] -queuebot:#ubuntu-release- Unapproved: walinuxagent (disco-proposed/main) [2.2.32-0ubuntu2 => 2.2.40-0ubuntu1~19.04.1] (core, ubuntu-cloud)
[20:12] -queuebot:#ubuntu-release- Unapproved: walinuxagent (cosmic-proposed/main) [2.2.32-0ubuntu1~18.10.2 => 2.2.40-0ubuntu1~18.10.1] (ubuntu-cloud)
[21:32] -queuebot:#ubuntu-release- Unapproved: walinuxagent (xenial-proposed/main) [2.2.32-0ubuntu1~16.04.2 => 2.2.40-0ubuntu1~16.04.1] (ubuntu-cloud, ubuntu-server)
[21:33] -queuebot:#ubuntu-release- Unapproved: walinuxagent (bionic-proposed/main) [2.2.32-0ubuntu1~18.04.2 => 2.2.40-0ubuntu1~18.04.1] (ubuntu-cloud)
[21:55] <vorlon> cyphermox: I see that you've made substantive changes to http://wiki.ubuntu.com/walinuxagentUpdates, which was an exception process approved by the SRU team; who have these changes been discussed with?
[23:12] <cyphermox> vorlon: I believe these are no-op changes. Just rather than testing in a PPA, pushing packages to devel-proposed and testing there *unless* there is a reason to be secretive.
[23:13] <cyphermox> (In other words, there was no discussion with the SRU team prior to right now)
[23:14] <cyphermox> I have however discussed this with fginther, clarifying things because *I* was confused by the doc mentioning uploading to a PPA
[23:21] <vorlon> cyphermox: ok; I reverted the one change that I considered incorrect
[23:22] <vorlon> (the section that talked about post-upload testing suddenly became pre-upload testing)
[23:25] <cyphermox> oh?
[23:26] <cyphermox> well, that makes sense anyway


[08:23] <alourie> gema: thanks for the guide fixes, it's much better now
[13:13] <brendand> hey mvo
[13:14] <mvo> hey brendand
[13:15] <brendand> mvo - if i were to propose a branch with the junitxml changes, would you take it?
[13:15] <brendand> mvo - i could potentially make the xml output switchable (-x option for example)
[13:41] <gema> alourie: no problem!
[13:41] <gema> alourie: it was good already, quite sharp on what needs doing, so *thank you*
[14:10] <brendand> mvo - so i wrote a script which junitizes all the tests.
[14:15] <mvo> brendand: right, I wonder if there is a better way, i.e. simply using a tiny wrapper, let me try this out (a tiny wrapper instead of having to modify every file)
[14:19] <brendand> mvo - yeah, i thought about that a little bit, but didn't get anywhere
[14:23] <jp_Hranice> Hallo
[14:24] <jp_Hranice> I can not run Ubuntu Precise in low-graphic mode to allow nvidia graphic driver.
[15:09] <mvo> brendand: I think I have some ideas around the junitest stuff, I will push a branch later
[15:14] <mvo> brendand: could you please check lp:~mvo/software-center/junitxml ? that contains a small unittest2junitxml helper
[15:17] <brendand> mvo - how to use it?
[15:23] <brendand> mvo - never mind
[15:23] <jibel> mvo, brendand i'm jumping into the conversation, so forgive me if I'm out of context but you can also run python unittest with subunit and pipe the stream to subunit2junitxml
[15:23] <jibel> it works this way: python -m subunit.run  test_yourtest | subunit2junitxml
[15:23] <brendand> hurray!
[15:23] <brendand> jibel saves the day
[15:24] <jibel> for example with s-c this works: python -m subunit.run test_netstatus|subunit2junitxml
[15:24] <brendand> jibel - great, thanks!
[15:25] <jibel> yw :)
[15:25] <brendand> mvo - so actually all is really necessary is to modify test-all.sh to allow it to specify xml output
[15:28] <brendand> jibel - oh, but i wonder how to make it work with python-coverage then?
[15:38] <brendand> i can only seem to get the modified unittest cases to work with python-coverage
[15:40] <mvo> brendand: is my small helper not working?
[15:41] <mvo> jibel: oh, interessting, I was not aware of this, that would have saved me a bit of poking around :)
[15:43] <brendand> mvo - it does work, if you run it like  'PYTHONPATH=.:$PYTHONPATH ./unittest2junitxml test_debfileapplication.py'
[15:44] <brendand> and so does jibels tip
[15:44] <brendand> but i can't figure out how to combine them with python-coverage
[15:46] <mvo> brendand: dosn't "make" just work ? I thought it did for me
[15:46]  * mvo tries that
[15:49] <brendand> mvo - ah, yes i see. it does then
[15:52] <brendand> mvo - there's some little faults in your wrapper. i don't want to pick on it, since i couldn't have written the same, but it seems to depend on unittest.TestCase derived classes being named a particular way
[15:52] <brendand>         if name.startswith("Test"):
[15:53] <jibel> brendand, nose is another options in this case
[15:53] <jibel> nosetests --with-coverage --with-xunit --xunit-file=result.xml test_netstatus
[15:53] <jibel> or something like that
[15:54] <brendand> haha, so many options. don't you love the linux world?
[15:54] <jibel> anything but rewriting something that already exists :)
[15:55] <glebaron> I have some questions about hardware certification that I hope someone can answer.
[15:55] <brendand> glebaron - ask me
[15:55] <glebaron> I am currently looking at a Dell Precision T1600 workstation which has been certified on 11.04 and 10.10 pre-installed.
[15:56] <brendand> glebaron - sure
[15:56] <glebaron> They want to run 10.04 64-bit.
[15:56] <glebaron> Is this a problem.
[15:56] <mvo> brendand: *cough* you got me ;) its just a quick wrapper and jibel pointed us to better options. so I guess we say goodbye to it and use e.g. nose
[15:57] <mvo> thanks jibel btw
[15:57] <brendand> mvo - sure thing, i'll look into jibel's nose
[15:57] <brendand> (weird sentence)
[15:57] <mvo> enjoy!
[15:57] <glebaron> Same question for a Dell Latitude E6420.
[15:57] <jibel> :D
[15:58] <brendand> glebaron - it's our policy to only certify clients (laptops and desktops) with 32-bit. why do they want 64-bit?
[15:58] <glebaron> 8gb ram.
[15:58] <glebaron> doing analysis on multi-million record datasets.
[15:59] <brendand> glebaron - you mean a server?
[15:59] <brendand> glebaron - is the system already purchased, or being considered?
[15:59] <glebaron> brendand, well no, it's laptop and workstation, I know that.
[15:59] <glebaron> brendand, it's being considered.
[15:59] <roadmr> the E6420 is a laptop, the T1600 a workstation
[16:00] <glebaron> brendand, I am leaning toward telling them it's not an issue.
[16:00] <glebaron> I run 64-bit on all kinds of stuff with no problems.
[16:00] <glebaron> but I just thought I would get your opinions first.
[16:00] <brendand> glebaron - true. but they are *not* certified with 64-bit.
[16:01] <roadmr> glebaron: we have seen cases of systems working fine in 32-bit and then failing certification on 64-bit (I think it was a video driver issue)
[16:01] <glebaron> so the only way to tell would be to get one and test it.
[16:01] <roadmr> glebaron: if possible, my advice would be to get a sample system and test it yourself
[16:02] <glebaron> roadmr, I would love to do that.
[16:02] <roadmr> glebaron: you could check Dell's return policy, get a system to test, and if it fails (unlikely, but as I said, no promises) you can just return it
[16:04] <glebaron> I have an E6400 that I can test on.
[16:04] <glebaron> I guess I will try that and then research hardware differences to see what I can find out.
[16:05] <roadmr> glebaron: beware, even if the model number is the same, the manufacturer may change components without warning, it's caused us some headaches when a certified model's components change and it stops working for people
[16:05] <roadmr> glebaron: it's why in the certification website we show a detailed list of components
[16:06] <brendand> glebaron - +1 to what roadmr said. that's way more important than the difference between 32 and 64 bit
[16:06] <glebaron> roadmr, thanks, for the info. It's a very good site.
[16:06] <brendand> glebaron - http://www.ubuntu.com/certification/hardware/201011-6865
[16:06] <brendand> glebaron - make sure the components match, particularly CPU, wireless and graphics cards
[16:06] <glebaron> ok.
[16:07] <brendand> glebaron - so that one is just all onboard, intel graphics and intel wireless
[16:09] <glebaron> brendand, the T1600?
[16:10] <brendand> glebaron - yeah.
[16:12] <brendand> glebaron - the E6420 is a tricky one actually. we certified 3 different configs
[16:13] <glebaron> yep, it's kinda busy.
[16:13] <glebaron> brendand, is there a reason they are not tested with 10.04?
[16:15] <roadmr> glebaron: maybe the manufacturer didn't request 10.04 certification
[16:15] <brendand> glebaron - that's complicated
[16:15] <brendand> roadmr's answer is pretty much true
[16:15] <brendand> it's up to the OEM which releases they want certified
[16:16] <brendand> as to why they didn't ask for 10.04, that's what's complicated
[16:16] <glebaron> I was just curious. I like 10.04 because I tend to stick with LTS.
[16:17] <brendand> glebaron - could be it's new hardware that doesn't work with older kernels
[16:18] <glebaron> brendand, but then you update your kernel and you are good.
[16:18] <brendand> glebaron - update to what? an unsupported kernel?
[16:20] <glebaron> brendand, don't they update the kernel pretty regularly. My current one is 2.6.32 and I'm pretty sure I didn't start off with that one.
[16:21] <brendand> glebaron - true, but with bug fixes - not enabling hardware
[16:21] <brendand> glebaron - and actually Lucid has always been 2.6.32, but different versions within that
[16:22] <brendand> latest is 2.6.32-37.81
[16:22] <glebaron> brendand, I learn new stuff every day. Thanks for that.
[16:23] <brendand> last year it was 2.6.32-26.47
[16:25] <glebaron> brendand and roadmr, thanks for the info. I will tell them that the only way to be sure is to test.
[16:26] <roadmr> glebaron: yep, sorry about that - 64-bit certification for clients may come in the future, but we don't have a definite timeframe for that
[16:38] <brendand> roadmr - didn't they talk at UDS about making 64-bit the officially supported version?
[16:39] <roadmr> brendand: yep, the consensus was to gather information before making a decision - it may or may not happen for 12.04, there's no firm decision that I know of
[16:39] <roadmr> brendand: we were asked to provide information from UF and checkbox testing results, I think cr3 found that like 80% of all systems are 64-bit capable
[16:40] <roadmr> but also, that ~80% of all installs are still 32-bit (similar %, but of course they don't necessarily overlap)
[16:41] <brendand> https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-64bit-by-default


[12:01] -queuebot:#lubuntu-devel- New binary: lubuntu-artwork [amd64] (zesty-proposed/universe) [0.65] (lubuntu)
[16:42] -queuebot:#lubuntu-devel- New: accepted lubuntu-artwork [amd64] (zesty-proposed) [0.65]


[08:45] <iOllieN> Hi
[08:46] <iOllieN> I am trying to bootstrap Juju  on LXD cluster and it keeps failing due to this error:
[08:46] <iOllieN> 08:44:16 DEBUG juju.provider.common bootstrap.go:282 failed to start instance in availability zone "OD-06": x509: certificate is valid for mgnt-lxd.metal.domain, mgnt-lxd-01.domain, mgnt-lxd-02.metal.domain, mgnt-lxd-03.metal.domain, not ollie-deploy
[08:47] <iOllieN> The SSL cluster is valid for the cluster name (LXD endoint) and all 3 hosts.  Ollie-deploy is a VM i am trying to bootstrap on
[08:47] <iOllieN> The error suggests I'd need to add ollie-deploy to the SSL but this doesn't seem right. I shouldn't have to change the clusters certificates everytime I bootstrap on a machine
[08:47] <iOllieN> If anyone is able to point me in the right direction it would be great. I've been stuck on this for days
[15:28] <achilleasa> iOllieN: I think this PR (https://github.com/juju/juju/pull/13103) might solve the issue you are having
[15:42] <iOllieN> Thanks


[18:00] <arunkr> "Error in service module" message And I cann't login in Ubuntu 7.10 any way (GDM and console). any solution


[04:37] <hikiko> Hi
[05:29] <pitti> Good morning
[08:02] <Sweet5hark> moin
[09:03] <ricotz> Sweet5hark, 5.1.2 \o/
[09:04] <ricotz> Sweet5hark, the hardcoded dep on openjdk-7-jdk in control.subsequentcheckbase.in should be openjdk-8-jdk or even more loose?
[11:03] <andyrock> hey
[11:59] <desrt> hihi hackers
[12:43] <Sweet5hark> <- out for some
[21:43] <robert_ancell> attente, how are you going with the g-s update?
[21:44] <attente> robert_ancell: got stuck trying to cherry pick some of the commits...
[21:45] <robert_ancell> attente, need any help?
[21:46] <attente> could do
[21:46] <attente> currently trying 92fedd999c9b169cf574b5d231e479aa6c318ba4
[21:46] <attente> "Mark license and provenance based on the APT sources"
[21:58] <robert_ancell> attente, did you try using git am to build the branch from debian/patches?
[21:59] <attente> robert_ancell: i used the patches as a reference point for cherry picking commits (or merging in the case of the reviews)
[22:00] <attente> robert_ancell: i'm basically at the same point now as the debian/patches set
[22:01] <attente> and i'm comparing the current branch against another branch which has all of the feature branches merged together. the diff is still 1375 lines long


[12:59] <jelly-home> "China and Hong Kong Customs’ have temporarily increased package inspection due to China’s upcoming National Congress [of China Communist Party] resulting in some shipping delays."
[14:24] <jelly-home> "Samoborskom Kolodvoru" http://goo.gl/maps/DsPz6
[17:13] <jelly-home> http://www.youtube.com/watch?v=PreIm3FGx8M
[17:14] <datase> jelly-home: Title: Fatboy Slim - In heaven, Views: 20726, Rating: 99.25926%