| xnox | stgraber: is lxd on github / linuxcontainers.org yet? | 00:03 |
|---|---|---|
| xnox | =) | 00:03 |
| stgraber | xnox: github.com/lxc/lxd all 0 bytes of it :) | 00:05 |
| xnox | stgraber: =) cool. | 00:07 |
| xnox | stgraber: pleaora of people are talking about it, sounds exiting and people are undecided whether it's an NIH or indeed something cooler than docker. | 00:11 |
| xnox | stgraber: however with lack of public source code for inspection it's hard to tell what it is. | 00:11 |
| stgraber | well, currently there's very little code available, we've got a python prototype and a Go prototype which each do different things. The plan is to have the Go one be split into pieces and contributed upstream through the usual review process bit by bit rather than have a single massive code dump that nobody can seriously review. | 00:14 |
| xnox | stgraber: i take it, the go code is/was not written by you?! | 00:18 |
| hallyn | chuckle | 00:18 |
| hallyn | xnox: I wrote some of it. | 00:19 |
| xnox | hallyn: i did bits of gocode for phablet gogotools. How do you like golang so far? | 00:20 |
| hallyn | xnox: i have issues with the dogmatic refusal to allow me to control goroutines. | 00:20 |
| hallyn | aside from that, it's a lot of fun | 00:20 |
| hallyn | i love the multile return values | 00:21 |
| hallyn | i appreciate the way you build 'classes', basically feels like the way the vfs in the kernel does it | 00:21 |
| xnox | hallyn: i don't think i've used goroutines correctly (especially asynchronously feeding a channel and synchronising that / calling golang select across them and all that) | 00:21 |
| xnox | i don't quite like how error handling is done, but i guess that will not change (essentially everything must return an error as one of the multiple return values, and everything must check/bubble it up) | 00:22 |
| hallyn | right, my problem was i was doing io.Copy() inside goroutines to pass data from console to a socket, then on the other end from a socket to a pty which was hooked to a container using attach, | 00:22 |
| hallyn | and my problem was that i couldn't find a good way to select(0 so that i could add a second channel with which to interrupt | 00:22 |
| hallyn | but it worked out ok with how the attach happens through the lxc go bindings. | 00:23 |
| hallyn | so yeah, i like it :) | 00:23 |
| hallyn | better than i thought i would | 00:23 |
| hallyn | anyway, it's 1:30am here and i should really get to bed - gnight | 00:23 |
| xnox | night. | 00:39 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === doko_ is now known as doko | ||
| RAOF | !regression-alert | 03:57 |
| ubottu | bdmurray, cjwatson, Daviey, didrocks, doko, infinity, jdstrand, pitti, RAOF, Riddell, ScottK, seb128, skaet, slangasek, SpamapS, stgraber: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive | 03:57 |
| RAOF | openjdk security update - https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1389493 | 03:57 |
| ubottu | Ubuntu bug 1389493 in openjdk-7 (Ubuntu) "Package dropped pulse-java.jar, breaking some development environments" [High,New] | 03:57 |
| cyphermox | xnox: I see now why you were happy not to touch ppp :) | 04:00 |
| infinity | doko: ^ | 04:02 |
| slangasek | RAOF: I'm puzzled by that description. Projects show as broken in eclipse even if they don't use pulse-java.jar? | 04:26 |
| RAOF | slangasek: Apparently eclipse keeps a list of all the files in the JRE it's got registered and complains if any of them disappear. | 04:26 |
| slangasek | RAOF: fwiw my understanding from watching from the sidelines was that pulse-java.jar had been superseded by icedtea-sound.jar; I'm not sure how it's anything other than a bug in eclipse that it behaves this way though | 04:27 |
| RAOF | slangasek: I agree that it does seem to be profoundly stupid behaviour from Eclipse. | 04:27 |
| slangasek | (of course, we may be stuck working around it in openjdk-7, but I'd like to know why eclipse does this) | 04:27 |
| slangasek | anyway, no quick rollbacks on this one; I'll assign it to doko for further investigation | 04:28 |
| RAOF | I have no idea why Eclipse would choose to do this, but my knowledge of Java development is pretty much restricted to “there was a dude on IRC complaining that we broke Eclipse”. | 04:28 |
| RAOF | Yeah, that was my assessment of the situation. | 04:28 |
| pitti | Good morning | 07:25 |
| MasterPiece | pitti, moin :) | 07:37 |
| pitti | infinity: https://jenkins.qa.ubuntu.com/job/vivid-adt-glibc/7/ARCH=i386,label=adt/console -> looks like fallout from new dpkg? | 07:48 |
| pitti | dpkg-source: error: binary package stanza libc-bin is using an obsolete Build-Profiles field syntax | 07:48 |
| Tribaal | guys, how can I help with https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1386455 ? It is a little scary that some potentially serious vulnerabilities have been addressed and not yet packaged... | 07:49 |
| ubottu | Ubuntu bug 1386455 in chromium-browser (Ubuntu) "Chromium 37 has 159 known security issues" [Undecided,Confirmed] | 07:49 |
| Mirv | would some core dev be available to review (ack) bregma's first vivid compiz release packaging changes? seems like ok cleanup https://ci-train.ubuntu.com/job/ubuntu-landing-014-2-publish/lastSuccessfulBuild/artifact/packaging_changes_compiz_1%3A0.9.12.0+15.04.20141104-0ubuntu1.diff | 07:55 |
| Mirv | compiz-gnome seemingly got python dependencies since it already had the migration scripts in python, but missed the explicit dependencies | 07:55 |
| infinity | pitti: Whee. Probably already fixed in Debian, I'll have a look and either merge or fix and merge. | 07:57 |
| pitti | infinity: thanks; it's probably trivial, but I haven't looked into that field at all | 07:58 |
| infinity | Mirv: I assume the removal of debian/patches/99_valid_ccsm_desktop_file.patch coincides with upstream fixing that? | 08:00 |
| infinity | Mirv: It would be (really) nice if the Debian changelog actually logged the debian changes. :/ | 08:00 |
| infinity | Mirv: The changes (except that patch dropping, which I can't audit on a partial diff) all look sane to me, but I'm going to NACK it based on being sick and tired of changelogs without changes logged. | 08:02 |
| infinity | Mirv: Which means there's no rationale for the new python dep or the patch being dropped. | 08:02 |
| Mirv | infinity: yes, the MP states it was moved into the source | 08:03 |
| infinity | Mirv: The rules, copyright, and language cleanup changes look fine though. | 08:03 |
| infinity | Mirv: That's lovely that the MP says that, why isn't it in the changelog? Seriously. | 08:03 |
| Mirv | bregma: ^ infinity would want better changelogs | 08:03 |
| infinity | Mirv: Is this a process failure that MP changes should be getting jammed into the changelogs, or an upstream failure that the changelog should be hand-edited to be more verbose? | 08:04 |
| Mirv | infinity: that's a common problem. it's a process failure that the MP commit messages for the branch are kept shorter than for example the actual accumulated commit messages that were made to the branch. | 08:05 |
| Mirv | for example here https://code.launchpad.net/~bregma/compiz/fix-lintian-warnings/+merge/240298 it only says "fixed numerous minor Lintian warnings in the Ubuntu packaging" (this gets into debian/changelog), while the description is a lot more verbose and the branch has later commits which say eg "ccsm.desktop: removed deprecated attributes (moved patch inline)" that should have been added to the branch's commit message | 08:05 |
| infinity | Mirv: Maybe we should get Linus up in here to tell people (with his usual "friendly" style) what good changelogs look like. ;) | 08:06 |
| infinity | Though, I'm pretty sure that Linus and the Ubuntu CoC are fundamentally incompatible. | 08:07 |
| Mirv | I see that all around canonical upstreams that the MP:s are well thought out and tested, but the branch commit message is there often just "fixes important bugs" or such | 08:14 |
| Mirv | infinity: this is also an usability issue in LP. I find it cumbersome that when proposing a branch, only description is asked for, while the commit message is what gets used here. so commit message more naturally always comes as an afterthought "oh right I should fill in something here" | 08:14 |
| Mirv | instead of it being thoughtfully written at the time of proposing the branch | 08:15 |
| infinity | Mirv: Well, a branch commit message is often just "pull random crap from George" anyway. It's the next level down that's interesting. | 08:17 |
| mardy | Mirv: hi! I added you to this review, I guess it should be pretty familiar changes for you :-) https://code.launchpad.net/~online-accounts/accounts-qml-module/packaging/+merge/240688 | 08:29 |
| smb | Question, I have a package that uses .xz for the orig tarball in Vivid. Now I want to do minor release updates for Utopic and Trusty (where I previously still used .gz). Is it ok to change the compression type of the orig tarball in a MRE upload? | 08:34 |
| Mirv | mardy: thanks, looking | 08:47 |
| === Saviq is now known as Saviq-codedive | ||
| apachelogger | stgraber: remember the ip problems I had when starting multiple containers at the same time? http://paste.ubuntu.com/8833121/ <- I am no specialist but that output looks rather weird (: | 09:39 |
| LocutusOfBorg1 | Laney, gdcm accepted, can you please rebuild insighttoolkit and insighttoolkit4? | 09:52 |
| LocutusOfBorg1 | (nifti2dicom should wait for them) | 09:52 |
| mlankhorst | arges: ok re-uploaded mesa. :P | 09:52 |
| Laney | LocutusOfBorg1: will do later | 09:54 |
| LocutusOfBorg1 | thanks :) | 09:54 |
| Laney | yw! | 09:54 |
| infinity | smb: An MRE implies it's a new upstream version, right? | 10:01 |
| infinity | smb: And thus, a new orig. | 10:01 |
| infinity | smb: So, sure, compression type really doesn't matter, as long as the tools in the target distro support it (and trusty supports .xz just fine). | 10:02 |
| smb | infinity, right. 4.4.0 -> 4.4.1 | 10:02 |
| smb | infinity, Ok, then I go forward and use the same orig for all of them. thanks | 10:03 |
| ochosi | hey folks, if this is the wrong channel, sorry in advance (and please feel free to point me in the right direction), i just quickly wanted to know whether there is a plan on when status.ubuntu.com will be activated for V | 10:26 |
| doko | pitti, do you understand the marble autopkg test failure? | 10:39 |
| cjwatson | arges: on vac / conf leave this week, hopefully somebody else can advise | 11:27 |
| doko | Riddell, ScottK, jibel, pitti: the marble autopkg tests fail very often. any hint on that? for now it's blocking gcc-4.9 | 11:31 |
| pitti | doko: looking now (sorry, had a long doctor appointment, just back) | 11:31 |
| pitti | 8 - MarbleRunnerManagerTest (Failed) | 11:32 |
| pitti | that doesn't look like an infrastructure problem, but a real failure? | 11:32 |
| pitti | it's also holding back qt4-x11 | 11:32 |
| pitti | doko: ah, Riddell already overrode the test | 11:33 |
| pitti | doko: gcc-4.9 is blocked on gamera; that regressed because apparently distutils is unhappy about parsing the "2.0rc1" version number from pygments (?) | 11:34 |
| doko | fixed, it's testing for a strict version | 11:34 |
| pitti | https://jenkins.qa.ubuntu.com/job/vivid-adt-gamera/6/ARCH=amd64,label=adt/console | 11:34 |
| === freyes is now known as zz_freyes | ||
| pitti | infinity, cjwatson: can you make any sense of this? http://paste.ubuntu.com/8834547/ | 11:37 |
| pitti | i. e. why don't the -proposed binaries get cleaned up? | 11:37 |
| Riddell | doko: upstream says it fails often anyway because it tries to download stuff so I overrode it | 11:38 |
| pitti | doko: "fixed" -> i. e. there's a new upload of pygments/distutils/whatever in -proposed which resolves this? or does this need further investigation? | 11:38 |
| Riddell | pitti: ↑ | 11:38 |
| pitti | tests can downlaod stuff now (through the proxy), but that's apparently not what marble stumbled over | 11:39 |
| === _salem is now known as salem_ | ||
| brainwash_ | mdeslaur: isn't bug 1312219 a critical one? I'm somewhat surprised that there is still no official or ubuntu-only fix | 12:01 |
| ubottu | bug 1312219 in pepperflashplugin-nonfree (Ubuntu) "Plugin needs to update automatically" [Undecided,Confirmed] https://launchpad.net/bugs/1312219 | 12:01 |
| mdeslaur | brainwash_: it's a hard problem to solve, we can't redistribute it like we do with the ordinary flash, so we can't rely on a version being available somewhere as when new chrome versions come out, they remove the old ones | 12:02 |
| mdeslaur | brainwash_: if you have a good idea on how to solve that, feel free to comment in the bug | 12:03 |
| brainwash_ | recommending google chrome is the only solution as of now I guess | 12:05 |
| brainwash_ | also, chromium-browser updates are delayed most of time | 12:05 |
| brainwash_ | which makes chromium-browser + pepperflashplugin-nonfree a dangerous combination | 12:06 |
| mdeslaur | brainwash_: yep, which is why they are both in universe still | 12:07 |
| Tribaal | brainwash_: mdeslaur: any news on chromimu 38? 37 has quite a few secuirty problems... | 12:07 |
| Tribaal | I am glad to help if I can | 12:07 |
| brainwash_ | bug 1386455 | 12:08 |
| ubottu | bug 1386455 in chromium-browser (Ubuntu) "Chromium 37 has 159 known security issues" [Undecided,Confirmed] https://launchpad.net/bugs/1386455 | 12:08 |
| mdeslaur | Tribaal: it's being worked on, as usual, it refuses to compile on some of our archs, so chad is working hard on getting it fixed | 12:08 |
| mdeslaur | we have someone full-time on getting chromium built | 12:08 |
| Tribaal | mdeslaur: ahhh I understand the problem now. I didn't realize it was a compilation problem. | 12:09 |
| Tribaal | mdeslaur: thanks for the answer | 12:09 |
| mdeslaur | you can monitor progress here: https://launchpad.net/~canonical-chromium-builds/+archive/ubuntu/stage/+packages | 12:10 |
| mdeslaur | also, upstream switched to requiring llvm to compile it, so chad has been working on getting llvm built for older releases, etc. | 12:10 |
| brainwash_ | sadly I cannot help with fixing those issue | 12:11 |
| brainwash_ | but I assume that chromium and the pepperflashplugin are quite popular | 12:12 |
| brainwash_ | maybe the update policy for both packages should be discussed (somewhere) | 12:13 |
| ypwong | xnox, cjwatson: could you take a look at bug 1330410? not sure what wrong, but from the package I built myself, the bug does not exist. | 12:19 |
| ubottu | bug 1330410 in Ubuntu Kylin "All keyboard types in "Keyboard layout" are not localized during installation" [High,Triaged] https://launchpad.net/bugs/1330410 | 12:20 |
| ypwong | thanks | 12:20 |
| Riddell | mdeslaur: further security update in bug 1389665 goes public tomorrow | 12:27 |
| ubottu | Error: Launchpad bug 1389665 could not be found | 12:27 |
| mdeslaur | Riddell: ack, subscribed ubuntu-security-sponsors | 12:28 |
| mdeslaur | Riddell: thanks | 12:28 |
| didrocks | Riddell: hey, not sure if you saw my ping the other day, but I plan to have a bluez5 session at UOS. Would be nice to have some kubuntu guys to sync up (from what I read, everything is ready from the KDE-front to work with bluez5) | 12:31 |
| Riddell | didrocks: oh yes, I asked a bit and didn't get any answer, I'll ask louder | 12:32 |
| didrocks | thanks :) | 12:34 |
| cjwatson | pitti: they need to migrate but have unsatisfiable dependencies; see near top of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html | 12:34 |
| cjwatson | ypwong: not until next week at least, on vacation / conference leave | 12:35 |
| pitti | cjwatson: right, but why is britney migrating the version at all? I thought it should wait for all arches? | 12:35 |
| cjwatson | pitti: it only waits for things that are out-of-date | 12:37 |
| cjwatson | pitti: so if only those first four architectures had ever been built first time round, it wouldn't have considered that it needed to wait for the remaining two | 12:37 |
| pitti | ah | 12:37 |
| pitti | jibel: ^ FYI | 12:37 |
| infinity | cjwatson: Although, it's broken anyway, since it copied armhf, which has the same problem. | 12:38 |
| infinity | cjwatson: I presume because it's just a source-with-binary copy, and the armhf build raced in under the wire. | 12:38 |
| infinity | (Though, how ppc64el didn't, I don't know...) | 12:38 |
| cjwatson | Could be, haven't gone back to analyse | 12:39 |
| infinity | Seems to come down to libfftw3 being broken on some arches. | 12:41 |
| infinity | Oh, not broken, just missing longdouble support on some. | 12:46 |
| infinity | Retrying arm64 and ppc64el should work, armhf will still fail. | 12:46 |
| mardy | Mirv: I updated https://code.launchpad.net/~online-accounts/accounts-qml-module/packaging/+merge/240688 | 13:28 |
| === MacSlow is now known as MacSlow|errand | ||
| === zz_freyes is now known as freyes | ||
| stgraber | apachelogger: hmm, yeah, that looks like a lxc-info bug :) Can you report that? | 14:24 |
| === MacSlow|errand is now known as MacSlow | ||
| ypwong | cjwatson, ok, no hurry, perhaps xnox will be able to check the bug since he did the last upload of that package | 14:36 |
| xnox | ypwong: highly unlikely. Maybe stgraber or infinity would step in to do it =) | 14:45 |
| === broder_ is now known as broder | ||
| === pitti` is now known as pitti | ||
| === timrc-afk is now known as timrc | ||
| === freyes is now known as zz_freyes | ||
| bdmurray | seb128: the file-roller retraces fail due to missing debug symbol packages for file-roller | 15:52 |
| bdmurray | seb128: http://ddebs.ubuntu.com/pool/main/f/file-roller/ notice no amd64 / i386 for the utopic package version | 15:52 |
| seb128 | bdmurray, hum, do we know why? | 15:53 |
| seb128 | bdmurray, I guess we need a no change rebuild to fix that? | 15:53 |
| bdmurray | seb128: yeah, I did a few uploads during the sprint before release didn't get to file-roller | 15:54 |
| bdmurray | pitti: is there some way to get utopic amd64 and i386 ddebs for file-roller? | 15:55 |
| bdmurray | pitti: we have them for every other arch... | 15:55 |
| seb128 | bdmurray, if we need an upload I'm just going for a bugfix worth SRUing so we don't do an upload for nothing | 16:03 |
| bdmurray | seb128: alright, sounds good | 16:04 |
| Laney | LocutusOfBorg1: okay, got some time now | 16:21 |
| Laney | what's the first level? | 16:21 |
| === seelaman` is now known as seelaman | ||
| LocutusOfBorg1 | Laney, I would say insighttoolkit and insighttoolkit4 | 16:30 |
| LocutusOfBorg1 | the second/last level should be nifti2dicom, but itk4 takes almost 10 hours to build... | 16:31 |
| Laney | I made a transition tracker entry | 16:33 |
| Laney | let's see what it says | 16:33 |
| LocutusOfBorg1 | Laney, http://people.canonical.com/~ubuntu-archive/transitions/ | 16:47 |
| LocutusOfBorg1 | I don't see it... | 16:47 |
| Laney | you need to wait for it to update | 16:48 |
| Laney | see the time at the bottom | 16:48 |
| LocutusOfBorg1 | oh yes ;) | 16:48 |
| LocutusOfBorg1 | I don't know how much time takes ben to update :) | 16:48 |
| Laney | LocutusOfBorg1: there | 17:10 |
| LocutusOfBorg1 | mmm strange, so nifti2dicom doesn't need a rebuild= | 17:14 |
| LocutusOfBorg1 | seems legit | 17:14 |
| Laney | no it only depends on libinsighttoolkit4.6 | 17:16 |
| LocutusOfBorg1 | yep, I though it was a level2, but yes, doesn't need a rebuild | 17:17 |
| eto | hello i would like to know if it is possible to run systemd on current ubuntu server LTS | 17:21 |
| eto | and if yes how hard it would be to switch to it? | 17:21 |
| eto | does such switch require compiling it from source? | 17:23 |
| LocutusOfBorg1 | ubuntu 14.04 LTS has systemd in the repository | 17:24 |
| LocutusOfBorg1 | switching to it from an existing installation might be hard, because I got some upgrades (mainly in debian testing) that didn't boot up after the reboot | 17:24 |
| Quintasan | LocutusOfBorg1: Trusty has no candidate for systemd package if I'm not mistaken | 17:26 |
| LocutusOfBorg1 | https://launchpad.net/ubuntu/+source/systemd | 17:26 |
| LocutusOfBorg1 | the package seems built for trusty | 17:26 |
| Quintasan | LocutusOfBorg1: I believe it is crippled as in it's lacking systemd binary | 17:27 |
| LocutusOfBorg1 | https://wiki.ubuntu.com/systemd | 17:27 |
| LocutusOfBorg1 | Quintasan, don't know honestly | 17:27 |
| LocutusOfBorg1 | :) | 17:27 |
| LocutusOfBorg1 | I think pitti has the correct answer ;)( | 17:28 |
| Quintasan | Yeah, it's crippled in Trusty | 17:28 |
| LocutusOfBorg1 | I won't install that think unless forced to :) | 17:28 |
| Quintasan | I believe I wanted to give it a go before the whole Debian stuff happened and I no packages provide the binary | 17:28 |
| === zz_freyes is now known as freyes | ||
| === Elimin8r is now known as Elimin8er | ||
| === freyes is now known as zz_freyes | ||
| Bluefoxicy | Sometimes, I really wonder if it's a waste of effort to respond to the mailing list with a logical, well-thought argument; or if I should just hit REPLY ALL and type "Your mom." | 17:34 |
| === zz_freyes is now known as freyes | ||
| eto | LocutusOfBorg1: well i am not really familiar with ubuntu-server per se but given it's linux and systemd is inevitable i would like to use it at least | 17:38 |
| eto | LocutusOfBorg1: as external admins use ubu-server i was thinking maybe i could at least get some systemd features just by replacing init | 17:38 |
| LocutusOfBorg1 | eto, I don't know what to say, I would like to give a try with debian jessie, with systemd by default | 17:39 |
| LocutusOfBorg1 | maybe you can test your system, and when ubuntu switch you can go back | 17:39 |
| eto | LocutusOfBorg1: actually our requirements are minimal | 17:39 |
| eto | LocutusOfBorg1: i mean we probably don't neet everything included in ubu-server - so maybe it would be wiser to interview admins if they would be okay with debian jessie? | 17:40 |
| Bluefoxicy | jessie? is Debian using Pokemon for names now? | 17:40 |
| eto | LocutusOfBorg1: are there big differences between debian and ubuntu-server ? besides extra tooling i guess | 17:41 |
| LocutusOfBorg1 | Bluefoxicy, https://www.google.it/search?q=Jessie+toy+story&safe=off&client=ubuntu&hs=F7Q&channel=fs&tbm=isch&imgil=dNwnIGUOfxNI4M%253A%253B8TFYPGjXPwr_0M%253Bhttp%25253A%25252F%25252Fdisney.wikia.com%25252Fwiki%25252FFile%25253AJessie_from_toy_story_2.png&source=iu&pf=m&fir=dNwnIGUOfxNI4M%253A%252C8TFYPGjXPwr_0M%252C_&usg=__N8VW64Q0nKA4RjuvlHcNS9WT7cU%3D&biw=1920&bih=954&ved=0CDMQyjc&ei=bmFaVP3AF4eR7Abm8YCwBQ#facrc=_&img | 17:42 |
| LocutusOfBorg1 | dii=_&imgrc=dNwnIGUOfxNI4M%253A%3B8TFYPGjXPwr_0M%3Bhttp%253A%252F%252Fimg4.wikia.nocookie.net%252F__cb20130718165011%252Fdisney%252Fimages%252Fd%252Fdf%252FJessie_from_toy_story_2.png%3Bhttp%253A%252F%252Fdisney.wikia.com%252Fwiki%252FFile%253AJessie_from_toy_story_2.png%3B1200%3B1052 | 17:42 |
| LocutusOfBorg1 | oops http://img4.wikia.nocookie.net/__cb20130718165011/disney/images/d/df/Jessie_from_toy_story_2.png | 17:42 |
| LocutusOfBorg1 | jessie is from toy story, like all the other debian names | 17:42 |
| LocutusOfBorg1 | (excluding rc-buggy lol) | 17:42 |
| Bluefoxicy | o.o | 17:43 |
| Bluefoxicy | that URL is amazing | 17:43 |
| LocutusOfBorg1 | bdrung_work, do you plan to merge this? https://code.launchpad.net/~uwelk/vlc/daily-packaging/+merge/240758 | 17:46 |
| LocutusOfBorg1 | adding protobuf-compiler should fix the building issues | 17:46 |
| LocutusOfBorg1 | https://code.launchpad.net/~uwelk/vlc/daily-packaging/+merge/240759 this one | 17:47 |
| Bluefoxicy | so, I work at a major media company | 17:48 |
| eto | so basically from quick search jessie seems like lighter alternative to ubuntu server is that right? | 17:48 |
| Bluefoxicy | we've found that the ffmpeg precompiled, static-linked binary is like... it takes 5 seconds to encode a video that takes 35-45 seconds on the same version out of the repos in Fedora or Ubuntu | 17:48 |
| Bluefoxicy | H.264 with AAC | 17:49 |
| eto | Bluefoxicy: with static buld all filters are included into single binary? | 17:49 |
| eto | build | 17:49 |
| Bluefoxicy | eto: Yes, but that only affects dynamic linking; it doesn't affect runtime speed | 17:49 |
| Bluefoxicy | a static built Openoffice.org would load immediately, instead of in 17 seconds; but it would operate all runtime functions at the same speed as the dynamic binary | 17:50 |
| eto | Bluefoxicy: but if you use lot of execs from external script it might affect processing right? ffmpeg | 17:50 |
| Bluefoxicy | no | 17:50 |
| Bluefoxicy | the single binary runs for the full encoding period, one run. | 17:50 |
| Bluefoxicy | we're talking about bulk mathematics processing, not large amounts of shell script invocation | 17:50 |
| eto | yes but it starts in 5 seconds without linking stage right? | 17:51 |
| Bluefoxicy | no | 17:51 |
| eto | roger | 17:51 |
| Bluefoxicy | it completes the full task of encoding the video in 5 seconds | 17:51 |
| eto | how come? | 17:51 |
| Bluefoxicy | that's what I want to know. | 17:51 |
| Bluefoxicy | There was a point in time when Ubuntu's firefox was slow as living hell, and the static build of Firefox was snappy; it was so bad that nearly everyone had installed the Firefox downloaded from mozilla.org at the time | 17:52 |
| eto | Bluefoxicy: are you using ubuntu server in your stack? | 17:52 |
| ogra_ | Bluefoxicy, likely because you only build it for one arch and dont need to take ppc, ppc64, arm64 or whatever into account ... which might add other code paths and patches to generalize the code a bit more | 17:52 |
| Bluefoxicy | I've tested with multiple | 17:52 |
| Bluefoxicy | ogra_: those are defined with conditional compilation | 17:52 |
| ogra_ | some are, some arent | 17:52 |
| Bluefoxicy | also, code existing and code being run are two different things. You can compile in as much code as you want without making a program slower, if you don't ever call that code | 17:53 |
| ogra_ | also are you sure you use the exact same toolchain with exactly the same options ? (which are also a selection to make it work on as many arches as possible) | 17:53 |
| Bluefoxicy | ppc and ARM patches tend to provide an alternate code path, often hand-optimized assembly. Similarly, mmx and sse patches use wrapper functions or direct assembly | 17:53 |
| Bluefoxicy | ogra_: regardless, none of that should cause one compilation of an application to run 5-10 times faster than another. | 17:54 |
| Bluefoxicy | as well, libav is different than ffmpeg in many ways, but it's not clearly ridiculously slow; and the ffmpeg in fedora is also slow. | 17:54 |
| ogra_ | you are heavily using math ... it will definitely make a difference if you have your code adjusted for generic usage vs very specific optimization for just one arch | 17:55 |
| Bluefoxicy | yeah, but the generic one is the one that's fast. | 17:55 |
| ogra_ | you said the archive one isnt fast | 17:55 |
| ogra_ | while your personally compiled one is | 17:55 |
| Bluefoxicy | ogra_: https://www.ffmpeg.org/download.html these are fast (particularly, the linux static build) | 17:58 |
| eto | ty guys | 17:58 |
| Bluefoxicy | ogra_: anyway, my point is there should be some investigation about why libav in Ubuntu is ridiculously slow compared to the release provided; it's investigation I don't know how to do | 17:59 |
| Bluefoxicy | and I am now in webinar for negotiation for 5 hours, sorry later. | 17:59 |
| ogra_ | well, i would start comparing the patch sets vs the source that static package was built from | 17:59 |
| ogra_ | if you are sure you use the same toolchain for both, it can only be patches | 18:00 |
| Bluefoxicy | wow | 18:08 |
| Bluefoxicy | that guy responded to the list with "fuck you", and then called me a femenist and talked about Tim Cook ruining the world for "regular men" o.o | 18:08 |
| Bluefoxicy | just wow. | 18:08 |
| Bluefoxicy | and... now he's advocating murder. | 18:09 |
| Bluefoxicy | Somebody please check the lists. | 18:09 |
| Bluefoxicy | mhall119: Thanks. | 18:11 |
| mhall119 | yeah, trolling troll is trolling, I'm working on it | 18:11 |
| rickspencer3 | slangasek, around at all? | 18:28 |
| slangasek | rickspencer3: hi | 18:28 |
| rickspencer3 | slangasek, there seems to be some unfortunate exchange going on on @ubuntu-devel-discuss | 18:28 |
| slangasek | mmm | 18:28 |
| ogra_ | rickspencer3, mhall119 is on it | 18:28 |
| rickspencer3 | it doesn't seem to really have any value to the community, I was wondering if there options to stop it? | 18:28 |
| rickspencer3 | ogra_, thanks | 18:28 |
| rickspencer3 | slangasek, nm | 18:29 |
| rickspencer3 | :) | 18:29 |
| slangasek | ok | 18:29 |
| ogra_ | though we might need a list admin to block the troll | 18:29 |
| slangasek | I'm sure there are options, but I don't know who the list admins are - I'm not | 18:29 |
| rickspencer3 | ok | 18:29 |
| rickspencer3 | I think if mhall119 is on it, then it will be handled professionally and quickly | 18:29 |
| ogra_ | ubuntu-devel-announce list run by cjwatson at ubuntu.com, steve.langasek at ubuntu.com, adconrad at ubuntu.com | 18:29 |
| * rickspencer3 backs away slowly | 18:29 | |
| ogra_ | slangasek, the list disagrees :) | 18:30 |
| rickspencer3 | boom | 18:30 |
| rickspencer3 | :) | 18:30 |
| slangasek | ogra_: you may notice that -announce != -discuss | 18:30 |
| slangasek | ;) | 18:30 |
| ogra_ | oh, wait | 18:30 |
| ogra_ | sorry ... | 18:30 |
| * ogra_ blames evulotion :P | 18:30 | |
| slangasek | https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss/ says it's mhall119's problem! | 18:30 |
| * slangasek wipes his hands | 18:30 | |
| ogra_ | haha | 18:30 |
| * rickspencer3 exercises mute feature on thread | 18:30 | |
| mhall119 | slangasek: it is now | 18:30 |
| ogra_ | argh | 18:32 |
| ogra_ | he moved to ubuntu-users | 18:32 |
| mitya57 | systemd threads — now on every mailing list near you | 18:36 |
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| dobey | multiprocessing via email | 18:41 |
| mitya57 | (as usual, incorrectly capitalized) | 18:44 |
| === Saviq-codedive is now known as Saviq | ||
| Bluefoxicy | man this is ridiculous. I'm trying to update a printer firmware, but it uses a windows software program instead of giving me a firmware update file to upload to the printer | 19:13 |
| Bluefoxicy | so I tried to install the printer on windows. | 19:13 |
| Bluefoxicy | ... ... ... yeah uh. Why does hardware just plug in and work on Ubuntu, but require some arcane incantation to make work on Windows? | 19:14 |
| sarnold | "arcane incantation"? what could be simpler than googling for "<printer model number> download drivers", clicking on the first 438 megabyte file you can find, double-clicking it to start an installer, clicking "next" nine times, uninstalling the three browser toolbars you get, and then rebooting? | 19:15 |
| mdeslaur | sarnold: you forgot the step where you run the weird registry cleaner tool because you *gasp* plugged the printer in _before_ installing the driver | 19:19 |
| sarnold | mdeslaur: haha you don't make that mistake twice! :) | 19:19 |
| teward | is there a way to see what udev rules get installed on a Vivid system by default...? | 19:20 |
| teward | i'm trying to figure out a hardware support problem i've observed in Trusty and Utopic with certain equipment, and checking the udev rules accordingly | 19:21 |
| === roadmr is now known as roadmr_afk | ||
| === freyes is now known as zz_freyes | ||
| Bluefoxicy | sarnold: the problem is I installed the print driver on Windows, and it says it doesn't know what to do with it. I downloaded the print driver software package, and it says it can't find the printer. And so on and so forth. "What's this funky USB device?" "Here's the driver" "I don't know how to talk to it to see if the driver works" "Okay, here's the software the manufacturer sent" "Where's the printer? I can't i | 19:41 |
| Bluefoxicy | nstall the drivers if I can't see the printer!" | 19:41 |
| Bluefoxicy | sarnold: plug it into an Ubuntu box. "WOULD YOU LIKE TO PRINT A TEST PAGE?!" o.o | 19:41 |
| Bluefoxicy | and yet people still mock me about the strange shell commands supposedly required to get a sound card working on Linux. :| | 19:42 |
| * Bluefoxicy is frustrated today. | 19:42 | |
| sarnold | Bluefoxicy: we haven't even had to edit modelines in a decade.. sheesh :) | 19:43 |
| dobey | sarnold: go buy a 4k monitor and try to get it working on displayport :) | 19:45 |
| dobey | sarnold: if you don't need to edit modelines, you just need better hardware ;) | 19:46 |
| sarnold | dobey: hahaha :) | 19:47 |
| sarnold | actually, I've got the 4k tv.. I doubt this intel graphics in my laptop could actually drive it at that resolution, but it might be fun to see how far it can get | 19:47 |
| dobey | is it ivybridge or haswell? | 19:48 |
| sarnold | "Intel(R) Core(TM) i7-3520M CPU" | 19:48 |
| sarnold | not haswell but I also don't know about ivybridge :) | 19:48 |
| dobey | you might be able to do it on hdmi | 19:49 |
| dobey | it's ivybridge | 19:50 |
| Bluefoxicy | i plugged my computer into a 39 inch TV from LG | 19:50 |
| Bluefoxicy | HDMI on my computer | 19:50 |
| dobey | ivybridge doesn't do displayport 1.2 i don't think, which is required for the multi stream transport used by 4K monitors | 19:50 |
| dobey | eh 39" is way too big to use at a desk | 19:51 |
| ogra_ | depends on the thickness of your glasses | 19:51 |
| sarnold | dobey: oh, cool, though all I've got for outputs is minidisplay port and VGA | 19:52 |
| dobey | ogra_: would depend more on the curvature than the thickness. you'd need fisheye lens to be able to see the whole screen from so close :) | 19:53 |
| ogra_ | :) | 19:53 |
| pitti | desrt: hey Ryan! | 20:24 |
| desrt | hihi | 20:24 |
| pitti | desrt: would you mind doing another systemd-shim upstream release? | 20:25 |
| desrt | no problem | 20:25 |
| desrt | for the security policy thing? | 20:25 |
| pitti | desrt: I fixed several bugs, amongst them the grave Debian RC one | 20:25 |
| desrt | there was an RC bug? | 20:25 |
| pitti | desrt: yeah, see git log | 20:25 |
| pitti | desrt: I was also looking into bug 1359439 | 20:25 |
| ubottu | bug 1359439 in systemd-shim (Ubuntu) "[ 7.287663] systemd-logind[1057]: Failed to start unit user@126.service: Unknown unit: user@126.service" [Undecided,In progress] https://launchpad.net/bugs/1359439 | 20:25 |
| desrt | thanks :) | 20:25 |
| pitti | desrt: but despite looking really simple, it's a can of worms | 20:26 |
| desrt | ...like most things here | 20:26 |
| shirgall | Yeah, I saw that one this morning. | 20:26 |
| pitti | desrt: I have a patch which "fakes" those units, but then this requires implementing even more properties/API, etc. | 20:26 |
| === zz_freyes is now known as freyes | ||
| pitti | desrt: so I think it's better to do a release now, calm down the debian folks a bit, and tackle this for release 10 | 20:26 |
| desrt | pitti: sounds like you were in the same area of pain that i was | 20:26 |
| desrt | pitti: will roll a release right now... i have a few minutes :) | 20:27 |
| pitti | desrt: if you have some mins to cross-check my commits to see that I don't anything profoundly stupid, that'd be welcome of course | 20:27 |
| desrt | you in fact fixed what i had been working on before (before i got distracted to other things) | 20:27 |
| pitti | desrt: otherwise, I tested it pretty thoroughly on my workstation and in a VM with various scenarios, and the logind session cleanup works really nicely now | 20:27 |
| desrt | pitti: isn't the usual pattern to ask for this before committing? :) | 20:27 |
| pitti | desrt: *shrug*, github allows push -f :) but yeah, if you prefer that I can also work in a branch | 20:28 |
| desrt | pitti: i'm sure this is all quite fine | 20:28 |
| desrt | don't overestimate how much i care about this project | 20:28 |
| desrt | which is: not much :) | 20:28 |
| pitti | desrt: oh, were you working on the notify_on_release stuff, too? | 20:29 |
| desrt | ya | 20:29 |
| desrt | i'm happy that you beat me to it though | 20:29 |
| pitti | desrt: care> well, this is mostly for Debian's benefit at this point, jessie freeze is today | 20:29 |
| desrt | it was getting can-of-wormsy as well | 20:29 |
| xnox | stgraber: Montreal folks are so vicious, it's been a year now, and the bug reporters cannot get used to the fact that America/Toronto & America/Montreal got merged into a single timezone in zone.tab - "America/Toronto - Ontario & Quebec - most locations" | 20:29 |
| pitti | desrt: yeah, took me a while to fully understand what systemd/logind are doing there | 20:29 |
| * xnox closed 3 bug reports now. | 20:29 | |
| pitti | slangasek: ^ on that note, do you want to package systemd-shim 9 (bug refs are in the git changelog), or want me to? | 20:30 |
| pitti | Maintainer: and all that | 20:30 |
| desrt | pitti: looks like there are some compiler warnings here | 20:30 |
| slangasek | pitti: you can probably get to it sooner than me, I'm happy for you to and also add yourself as an uploader ;-) | 20:30 |
| pitti | oha? I didn't spot any, sorry | 20:30 |
| pitti | slangasek: ack | 20:30 |
| slangasek | pitti: and thanks for sorting out these bugs! | 20:30 |
| desrt | implicit declarations of g_access and perror | 20:30 |
| desrt | i'll clean them up | 20:30 |
| pitti | slangasek: cheers | 20:30 |
| pitti | desrt: whoops | 20:31 |
| desrt | pitti: fwiw, don't use g_access() | 20:31 |
| desrt | this is only useful if your program is intended to be portable to windows | 20:31 |
| pitti | desrt: EAFP instead of LBYL? | 20:31 |
| desrt | since otherwise it is just an alias for access() | 20:31 |
| pitti | ah | 20:31 |
| pitti | desrt: I got into a habit of using that for glib-y stuff, fewer includes etc. | 20:32 |
| pitti | is there any downside to it? | 20:32 |
| desrt | pitti: you need to include gstdio.h for this one :) | 20:32 |
| desrt | since it is only a #define alias for the standard library function | 20:32 |
| desrt | (so you still need the system headers) | 20:32 |
| pitti | desrt: I just built it again, and get zero warnings; but I just ./configure'd with the defaults, so maybe I'm missing some extra warning opts that you specified? | 20:32 |
| desrt | pitti: i did the same, but i'm on fedora | 20:33 |
| desrt | so maybe my gcc is stricter by default | 20:33 |
| pitti | desrt: ah, I'm on vivid | 20:33 |
| stgraber | xnox: well, it'd help if clicking on Montreal on the map would actually do something rather than give you an empty timezone :) | 20:33 |
| stgraber | xnox: so yeah, the two were merged, but badly so :) | 20:33 |
| desrt | pitti: diversity win, i guess | 20:33 |
| pitti | heh | 20:33 |
| pitti | desrt: oh, and we don't install the d-bus policy any more, so perhaps we should remove it upstream as well? | 20:34 |
| pitti | desrt: it was only really useful for a split systemd-services build, but nobody does that any more | 20:35 |
| xnox | stgraber: our plan (b) was to ship 10'000 top locations on the cd and pick from them. Because we also have a persistent request to "add Beijing" instead of "Shanghai". Man, politics are hard - google maps have three maps for ukraine at the moment. | 20:35 |
| pitti | desrt: if you want to, I can commit that cleanup for 9 still (it's trivial) | 20:35 |
| desrt | pitti: sure | 20:35 |
| desrt | i just pushed the warnings fixes | 20:35 |
| === wedgwood1 is now known as wedgwood | ||
| pitti | desrt: policy drop fixed | 20:39 |
| pitti | desrt: err, what a grammar -- policy dropping committed | 20:39 |
| pitti | desrt: peux-tu préparer la nouvelle version neuf maintenant ? :-) | 20:40 |
| desrt | uh... oui! | 20:40 |
| desrt | (i hope) | 20:40 |
| desrt | so we have an interesting problem | 20:43 |
| desrt | my homedir on gnome.org has mysteriously vanished | 20:44 |
| pitti | WT...H? | 20:45 |
| desrt | #sysadmin says they know about it and are investigating | 20:46 |
| desrt | want me to email you the tarball or something? :) | 20:46 |
| pitti | desrt: WFM, or people.c.c. or whatever | 20:46 |
| desrt | first let's get this out of the way: | 20:47 |
| desrt | f1d69073037cc48562dd25d10ba069ff92f759381fa79042c5be4248b9c56e78 systemd-shim-9.tar.xz | 20:47 |
| pitti | desrt: cheers! got it | 20:51 |
| pitti | desrt, slangasek: uploaded | 20:57 |
| * pitti waves good night, take II | 20:57 | |
| sarnold | night pitti :) | 20:57 |
| bdmurray | slangasek: any ideas about bug 1384946? | 20:59 |
| ubottu | bug 1384946 in ubuntu-release-upgrader (Ubuntu) "Trying to upgrade to utopic, cannot compute changes due to gnuplot" [Undecided,Confirmed] https://launchpad.net/bugs/1384946 | 20:59 |
| === roadmr_afk is now known as roadmr | ||
| desrt | pitti: cheers | 21:07 |
| infinity | hallyn: Why is there no qemu-kvm on arm64 and ppc64el? | 22:14 |
| hallyn | infinity: does 'qemu-system-ppc64 --enable-kvm' work? | 22:38 |
| hallyn | if so, then it's just bc we need to add those arches to the qemu-kvm pkg, so i should see if we can do that straight in debian | 22:39 |
| infinity | hallyn: Yes, it does. | 22:45 |
| infinity | hallyn: (Only on a subset of machines, but that's no different from x86, their subset is just larger) | 22:46 |
| infinity | hallyn: The description for qemu-kvm is also a lie. :P | 22:48 |
| infinity | hallyn: Or does that get arch-specific mangling at build time? | 22:48 |
| hallyn | which part is a lie? it is in fact currently a wrapper script only around qemu-system-x86 | 22:49 |
| infinity | hallyn: Oh. So, that's entirely wrong, then, that it's built on arm, powerpc, and sparc. | 22:49 |
| infinity | hallyn: I would have epxected it to depend on qemu-system-${native} and then wrap appropriately. | 22:50 |
| infinity | hallyn: So we have a one-stop shop to tell people "if you want qemu w/ kvm capabilites on any arch, just apt-get install qemu-kvm" instead of having the end user map machine arch and qemu-system-arch. | 22:50 |
| mwhudson | oh hai | 22:51 |
| mwhudson | fwiw, devstack needs to do exactly this | 22:52 |
| mwhudson | it currently installs qemu-kvm | 22:52 |
| mwhudson | for my arm64 patches i install qemu-system but that's overkill | 22:53 |
| mwhudson | i wonder what the nova packaging does... | 22:53 |
| infinity | mwhudson: So, the short term solution is a local mapping of arch:arch. | 22:53 |
| mwhudson | oh right, installing nova doesn't get you a hypervisor, you get to decide | 22:54 |
| infinity | mwhudson: So on arm64, you install qemu-system-arm, on ppc64el, you install qemu-system-ppc, etc. But fixing qemu-kvm is the right answer, IMO. | 22:54 |
| mwhudson | infinity: ack | 22:54 |
| mwhudson | infinity: shall i file a bug on +source/qemu | 22:54 |
| mwhudson | ? | 22:54 |
| infinity | Plus, installing qemu-system-foo doesn't tell you what command you need to run to make it work. | 22:54 |
| infinity | Which the kvm wrapper fixes. | 22:54 |
| infinity | mwhudson: If you want to summarize the above and file a bug, that would be great. | 22:55 |
| mwhudson | i guess libvirt has that knowledge somehow? | 22:55 |
| infinity | mwhudson: Yeah, if you're running through libvirt, it's supposed to know. | 22:55 |
| hallyn | infinity: agreed, it'd be good to generalize that | 22:55 |
| hallyn | yeah libvirt just round qemu-system$arch --enable-kvm | 22:55 |
| hallyn | really qemu-kvm just providses a wrapper script for the lazy | 22:56 |
| hallyn | like me | 22:56 |
| infinity | hallyn: The wrapper script is less interesting to me (though we should fix it at the same time), it's the packaging shortcut that's nice. | 22:56 |
| infinity | hallyn: I'd rather depend on "qemu-kvm" for native support than "qemu-system-foo [foo bar], qemu-system-quux [quux baz], etc" | 22:56 |
| hallyn | true | 22:58 |
| hallyn | yeah mwhudson pls file the bug and while i have scant days left in 2014 i'll try to get that fixed in vivid | 22:58 |
| infinity | hallyn: And, FWIW, if we fix it sanely in vivid, I'd happily accept (and even encourage) an SRU to trusty and utopic with the same change. | 23:00 |
| infinity | Would be great if HOWTOs can just say "Step 1: install qemu-kvm" and it works on all arches. | 23:01 |
| infinity | Well, all arches with KVM support, but that happens to be all the ones we ship (plus sparc, apparently). | 23:01 |
| mwhudson | infinity, hallyn: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1389897 | 23:02 |
| ubottu | Ubuntu bug 1389897 in qemu (Ubuntu) "no way to install "enough qemu for kvm" in a cross platform way" [Undecided,New] | 23:02 |
| mwhudson | i think even my packaging skills might be up to fixing this | 23:04 |
| mwhudson | it's just a matter of sprinkling []s in qemu-kvm's Depends: line, right? | 23:04 |
| hallyn | "plus psarc, apparently" - wut? | 23:06 |
| hallyn | mwhudson: i'm abroad this week so if you don't mind then by al lmeans please do | 23:06 |
| slangasek | bdmurray: 1384946> doesn't that show that the user has an old, pre-trusty version of gnuplot installed? trusty has 4.6.4-2, not 4.4.3-0ubuntu3 | 23:08 |
| slangasek | ah | 23:09 |
| slangasek | you noted this already | 23:09 |
| slangasek | so, hmm, no specific ideas here, but I guess we should fix the precise->trusty dist-upgrade path for it if possible | 23:09 |
| infinity | mwhudson: That, and fixing the description to be arch-agnostic. And, the harder part, fixing the wrapper to DTRT (perhaps generating it at build time, rather than having complex case statements) | 23:14 |
| mwhudson | oh right, the wrapper | 23:15 |
| infinity | mwhudson: And dropping /usr/bin/qemu-system-x86_64-spice and /usr/bin/kvm-spice from !x86 | 23:17 |
| mwhudson | fetching git://anonscm.debian.org/pkg-qemu/qemu.git is taking aaages | 23:17 |
| infinity | mwhudson: Oh, I'd just work from the vivid sources, throw a patch at hallyn, and let him resolve it with git. :P | 23:18 |
| infinity | mwhudson: But I'm lazy that way. | 23:18 |
| mwhudson | ehh the kvm wrapper is only installed on x86 it seems | 23:20 |
| mwhudson | even though the package is built on various arches | 23:20 |
| infinity | mwhudson: So, a first cut could just be to change the deps, but the right answer is to make the wrapper work everywhere, IMO. | 23:21 |
| hallyn | infinity: mwhudson: yeah the ubuntu-devel branch of git://anonscm.debian.org/pkg-qemu/qemu.git should be identical to the vivid sources, so if you want to jus tpost a debdiff to the bug i'll work out the git bits and try to convince mjt it's a good idea for debian too :) | 23:22 |
| * hallyn out - gnight | 23:22 | |
| mwhudson | the clone has finished now | 23:22 |
| mwhudson | er | 23:25 |
| mwhudson | is there a reason why it depends on qemu-system-x86 (>= 1.7.0+dfsg-2~) rather than (= ${binary:Version}) ? | 23:26 |
| doko | great, now gcc-4.9 migration is blocked by some r-cran stuff ... https://jenkins.qa.ubuntu.com/job/vivid-adt-r-cran-surveillance/lastBuild/ARCH=amd64,label=adt/console | 23:26 |
| doko | pitti, jibel: ^^^ this definitely doesn't scale .... | 23:27 |
| mwhudson | infinity: does qemu-system-ppc cover ppc64el? | 23:30 |
| infinity | mwhudson: Yeahp. | 23:30 |
| infinity | mwhudson: For powerpc, ppc64, and ppc64el, it should all be 'qemu-system-ppc64 --enable-kvm' in the wrapper. | 23:31 |
| infinity | mwhudson: If there are 32-bit systems with KVM support, they're outliers, and I'll let BenC whine about them. :P | 23:31 |
| BenC | infinity: They’re far from outliers | 23:32 |
| infinity | mwhudson: I assume that dep was originally because of the Breaks/Replaces there too (as files moved around), but (= ${binary:Version}) would probably make more sense if the intent is to use qemu-kvm to install the right qemu-system. | 23:32 |
| BenC | But I can’t get Canonical to bother with anything I’m doing so, have at it | 23:32 |
| infinity | BenC: Well, I'm not regressing anything here, this already doesn't work right. But if we can come up with a way to make the wrapper DTRT, do let's. | 23:32 |
| infinity | BenC: We could key off 'uname -m' on powerpc, and call the right qemu. | 23:33 |
| BenC | infinity: Check CPU type in /proc/cpuinfo. If it’s e500mc, use qemu-system-ppcemb | 23:34 |
| infinity | BenC: Oh, there's a special build for emb? | 23:34 |
| BenC | If if’s `uname -m` == ppc and not e500mc, then use whatever else | 23:34 |
| infinity | So there is. | 23:34 |
| BenC | infinity: It has all the right mojo to emulate a n E500 machine and connect to the right kvm bits | 23:34 |
| BenC | e500 or e500mc that is | 23:35 |
| infinity | BenC: Want to pastebin a cpuinfo from such a machine? | 23:35 |
| mwhudson | so if feels like mv debian/kvm debian/kvm.x86, vim debian/kvm.aarch64 etc etc and install the right one? | 23:36 |
| mwhudson | *it | 23:36 |
| mwhudson | or is ppc the only snowflake and we can do the others with sed? | 23:36 |
| infinity | mwhudson: Others may be snowflaky in Debian (like mips*, perhaps) | 23:37 |
| BenC | infinity: http://pastebin.ubuntu.com/8842972/ | 23:37 |
| infinity | mwhudson: So, having one file per arch, and mangling as needed seems the right path. | 23:37 |
| BenC | That other would show cpu: e500v2" | 23:37 |
| BenC | Which would use the same binary | 23:38 |
| infinity | mwhudson: For most, it should look identical to the current x86 one, for ppc, it'll be a bit more involved. | 23:38 |
| BenC | It’s self detecting for the host | 23:38 |
| infinity | BenC: Are there any e500* that wouldn't want this, or can we just wildcard it? | 23:38 |
| BenC | infinity: e500v1, but that wont have a /dev/kvm, so wouldn’t much matter | 23:39 |
| infinity | Right, kay. | 23:39 |
| BenC | e500mc and e500v2 are the kvm enabled ones | 23:39 |
| infinity | So, we can just wildcard a case, probably. That's lazier/easier. :) | 23:39 |
| mwhudson | oh god, kvm has a shitty inaccurate man page too | 23:40 |
| BenC | Sure ‘^cpu:[[:space:]]*e500.*’ should match all things of interest for ppcemb | 23:40 |
| mwhudson | oh maybe not inaccurate | 23:40 |
| mwhudson | why is everything horrible | 23:40 |
| infinity | Because life. | 23:41 |
| infinity | BenC: So, your 64-bit platform just uses the standard qemu-system-ppc64? | 23:44 |
| BenC | infinity: I’d have to check. I think it may need to use ppcemb as well | 23:46 |
| BenC | proc cpuinfo would show e6500 | 23:46 |
| BenC | infinity: Confirmed | 23:47 |
| BenC | so e500* and e6500 | 23:47 |
| BenC | processor: 20 | 23:47 |
| BenC | cpu: e6500, altivec supported | 23:47 |
| BenC | clock: 1666.666650MHz | 23:47 |
| BenC | revision: 1.0 (pvr 8040 0010) | 23:47 |
| BenC | That’s the relevant cpu stanza | 23:47 |
| BenC | Both platforms are BookE, hence the ppcemb usage | 23:49 |
| infinity | BenC: So, something like this: http://paste.ubuntu.com/8843119/ | 23:49 |
| infinity | mwhudson: ^ | 23:49 |
| mwhudson | good timing, i'm typing my commit message for the other wrappers now | 23:50 |
| infinity | Err, missing a trailing ;; on the last outer case. | 23:50 |
| BenC | infinity: The awk statement works on both systems, so passes a cursory check | 23:50 |
| infinity | That was obviously written blind. :P | 23:50 |
| BenC | It atleast passes the the correct output on my boxes :) | 23:51 |
| mwhudson | infinity: is there a reason to handle power64 in this same file, particularly? | 23:52 |
| infinity | mwhudson: Most 32-bit powerpc installs are on 64-bit kernels. | 23:53 |
| BenC | mwhudson: 32-bit userspace can run on 64-bit platforms | 23:53 |
| mwhudson | ok | 23:53 |
| infinity | http://paste.ubuntu.com/8843150/ <--- that one looks like more correct shell. | 23:54 |
| infinity | BenC: Can you run that with sh -x on your machines and make sure it's trying to run the right binary? | 23:55 |
| infinity | Passes on a ppc64, ppc64el and ppc machine here. | 23:55 |
| BenC | infinity: If you’re going to use $(…) notation, should it not use bash? | 23:56 |
| BenC | Or am I behind the times | 23:56 |
| infinity | $() is POSIX. | 23:56 |
| infinity | Could be backticks, doesn't really matter. I just use $() more these days to avoid confusing myself when nesting. | 23:57 |
| BenC | infinity: Works on both, thanks | 23:57 |
| infinity | BenC: Ta. | 23:57 |
| infinity | mwhudson: So, that last pastebin with the quoting and ;; fixes should DTRT for qemu-kvm:powerpc | 23:58 |
| mwhudson | infinity: thanks | 23:58 |
| infinity | mwhudson: You could reuse it for :ppc64 and ppc64el too, though it's mostly a no-op for them, it simplifies the packaging to just symlink. :P | 23:58 |
| mwhudson | infinity: i just attached some patches to the bug https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1389897 | 23:59 |
| ubottu | Ubuntu bug 1389897 in qemu (Ubuntu) "no way to install "enough qemu for kvm" in a cross platform way" [Undecided,Confirmed] | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
