[00:00] <xnox> looking at distutils-extra the built_target is quite naive and hardcodes build/
[00:00] <xnox> (not sure if it's intentional to use the same mo_dir for all runs.
[00:01] <barry> slangasek: gotta run, but will check the scrollback when i'm back later tonight
[00:02] <slangasek> barry: ah, k - is the --install-layout stuff a likely cause of the issue?
[00:19] <GuidoPallemans> where can I find the source for the ubuntu phone internet application?
[00:31] <slangasek> barry: aha, so pybuild creates .pybuild/pythonX.Y_3.3/.pydistutils.cfg, which sets 'skip-build=1'... I'm guessing that's the issue
[00:36] <slangasek> barry: sure enough, omitting skip-build=1 fixes the issue
[00:36]  * slangasek files a bug on python-defaults
[00:36] <xnox> yeah, cause there is no sane way to override .pydistutils.cfg =/
[00:37] <xnox> alternatively, distutils-extra should provide install_* commands.
[00:37] <slangasek> it could, but wouldn't that effectively be an interface change for the users of distutils-extra?
[00:37] <xnox> yes.
[00:37] <slangasek> so, not my first choice
[00:46]  * xnox is failing to use --before-install option
[00:46] <xnox> slangasek: http://paste.ubuntu.com/1702914/
[00:46] <xnox> works, but it's ugly......
[00:47] <slangasek> xnox: easier: I just added skip-build=0 to setup.cfg
[00:47] <xnox> =)
[00:50] <xnox> slangasek: all shebangs are wrong. they are all 3.3
[00:50] <xnox> but should be python3
[00:50] <slangasek> tsk
[00:51] <slangasek> so why is that?
[00:51] <xnox> because the scripts got build with python3.3 not python3
[00:51] <slangasek> well, why did pybuild do that?
[00:52]  * xnox does override_dh_python3: dh_python3 --shebang=/usr/bin/python3 (to fix this)
[00:53] <xnox> I am constantly told that "dh_python3 does that out of the box by default" but it doesn't seem to for me ever without override.
[00:53] <xnox> Also, I often find a need to select py2 or py3 for the scripts.... and there is no way to say build py2/3 modules, but py2 scripts.
[00:53] <xnox> and vice versa.
[00:54] <xnox> slangasek: i recommend to raise compat to level 8 or the default 9.
[00:55] <xnox> as currently it ends up calling python_support (if available)
[00:55] <slangasek> right, mterry has a branch for that already
[00:55] <xnox> ok.
[03:16] <barry> slangasek: interesting.  thanks for filing that bug
[06:15] <pitti> Good morning
[06:24] <pitti> slangasek: so from what I understood from scrollback, the problem is that ./setup.py build_i18n dynamically adds the generated .mo files (which are put into ./build/mo, but that shouldn't matter) to data_files, but a subsequent ./setup.py install loses that information, right?
[06:24] <pitti> slangasek: i. e. to be able to split the commands in that way, the dynamic data_files need to be put into a file instead of just in distutils' brain?
[07:07] <pitti> stgraber: hey
[07:08] <pitti> stgraber: do you know if inotify is supposed to work in LXC containers?
[07:08] <pitti> stgraber: we run jhbuild in lxc, and inotify_init() always fails with EMFILE (Too many open files)
[07:36] <Whoopie> Hi, seb128 was so kind to sponsor the upload of usbmuxd, and it's now in the unapproved queue. What needs to be done to get it approved?
[07:38] <Whoopie> mdeslaur: Hi, I just saw that you sponsored iptables (bug 1074923). There's already another upload in the queue. Perhaps, both upload should be merged?
[07:47] <Whoopie> mdeslaur: and a look into the debian-changes-1.4.12-1ubuntu4 should also be done, as it reverts some parts of 0001-libxt_recent-Add-support-for-reap-option.patch
[07:59] <geser> Whoopie: wait till a SRU member reviews it (I assume it's about the SRU)
[08:00] <Whoopie> geser: alright. so it's "just" a matter of time and ressources?
[08:00] <Whoopie> mdeslaur: I made a debdiff for the iptables merge in bug 1074923.
[08:20] <mpt> Which package provides the default locale data? E.g. the default time format for each locale
[08:21] <slangasek> mpt: that bit should come from eglibc
[08:23] <mpt> slangasek, thanks, I moved bug 1130501 there
[08:24] <slangasek> heh, pretty sure there is no es_US locale
[08:24] <slangasek> but there does seem to be an es_PR, so that's valid
[08:24] <slangasek> (for es_US, that may be related to an installer bug cjwatson has been working on recently)
[09:39] <tjaalton> doko: so.. how urgently do you need clang/llvm fixed? :)
[09:41] <doko> tjaalton, well, it makes it a bit unusable ... so within a week or so?
[09:41] <tjaalton> doko: oh, early next week for sure
[09:42] <tjaalton> i'm away this week though
[09:42] <doko> just want it be tracked, and afaics there is currently no workaround
[09:42] <tjaalton> and discussing this with upstream so there's a sane resolution
[09:43] <tjaalton> current upstream has touched the intrinsics again..
[09:51] <zyga> pitti: hey
[09:52] <zyga> pitti: I talked to virtualenv upstream and they would be glad to take a patch that fixes the issue we talked about yesterday
[09:53] <zyga> pitti: have you had a word from barry?
[09:53] <zyga> pitti: the solution I talked about would involve not creating 'python' symlink when virtualenv is called with -p python3.*, instead python3 symlink would be created
[09:54] <zyga> pitti: if we make that patch in the next week it will be included in the pip next pip release which we could just pull to ubuntu
[09:58] <zyga> pitti: and I meant virtalenv release, not pip release
[09:59] <cjwatson> slangasek: as it happens, there is an es_US
[09:59] <cjwatson> Which makes sense given the number of speakers
[10:29] <pitti> hey zyga
[10:29] <pitti> zyga: no, barry didn't answer to this
[10:30] <pitti> zyga: it can always create a python3 symlink, it's the "python -> python3" symlink which hurts
[10:32] <diwic> pitti, hi, may I assing bug 1131139 to you?
[10:33] <diwic> s/assing/assign
[10:33] <pitti> diwic: oh right, please
[10:33] <pitti> XDG_RUNTIME_DIR
[10:33] <diwic> pitti, thanks a lot!
[10:34] <zyga> pitti: it creates three executables actually, (well, one and two symlinks)
[10:34] <zyga> pitti: for python, pythonX and pythonX.Y
[10:34] <zyga> pitti: I'll patch virtualenv to skip the 'python' one for python3
[10:34] <zyga> pitti: we'll review the patch and I'll push it upstream
[10:35] <pitti> zyga: splendid, thanks!
[11:43] <Quintasan> Hello
[12:05] <TheMuso> Do any of our python gurus know whether we have http://bugs.python.org/issue16327 fixed in raring?
[12:18] <GuidoPallemans> anyone else having trouble with qt creator since installing the sdk?
[12:18] <GuidoPallemans> none of my plugins will load any longer
[12:31] <mlankhorst> could anyone look at https://bugs.launchpad.net/precise-backports/+bug/1131173
[12:32] <mlankhorst> I need to make a similar one for xorg-gtest too, but iirc it needs some patching so I need to push that fix to raring first
[12:33] <Laney> will do, sec
[12:40] <Laney> mlankhorst: we'll need to backport to quantal as well to maintain the upgrade path so please also test there
[12:41] <Laney> (g'day)
[12:45] <mdeslaur> Whoopie: ah, thanks for noticing that...I had not realized there was one in the queue already. I'll take a look later on today.
[12:46] <GuidoPallemans> anyone else having trouble with qt creator since installing the sdk?
[12:49] <mlankhorst> Laney: sure np
[12:50] <mdeslaur> tkamppeter: is there a public source code repo somewhere for hplip?
[12:52] <mlankhorst> so what's the recommended way with dealing with xorg-gtest? it fails to build in the ppa because it expects a kernel module when running tests
[12:52] <mlankhorst> https://launchpadlibrarian.net/130037138/buildlog_ubuntu-precise-i386.xorg-gtest_0.7.0-0~ubuntu0~ppa1_FAILEDTOBUILD.txt.gz
[12:56] <vibhav> mlankhorst: I do my exactly know the build procedure for xorg-gtests, but what does it need tye kernel module for?
[12:57] <vibhav> s/do my/don't/
[12:57] <mlankhorst> running the tests during verification phase
[12:58] <vibhav> mlankhorst: How does it use the kernel module?
[12:58] <mlankhorst> uinput simulates input events it wants
[12:58] <vibhav> Ah
[13:00] <mlankhorst> easiest workaround is to skip tests though
[13:00] <TheMuso> \/c
[13:01] <cjwatson> GuidoPallemans: #ubuntu-app-devel might have more people with relevant expertise
[13:02] <vibhav> mlankhorst: you took the package from Raring?
[13:02] <vibhav> s/package/package source/
[13:20] <mdeslaur> anybody have any tips on quilt failing miserably to patch a file with crlf terminators?
[13:22] <diwic> mdeslaur, quilt push -f, patch -p1 < patchname, quilt refresh ?
[13:23] <diwic> mdeslaur, just a guess though
[13:23] <mdeslaur> diwic: as soon as I quilt pop and quilt push, it won't apply again
[13:23] <diwic> mdeslaur, okay, then I have no idea
[13:23] <mdeslaur> oh, wait, it's when I edit the patch to add the patch tags...
[13:24] <mdeslaur> my editor fixes the line breaks, which then beaks quilt
[13:24] <mdeslaur> diwic: nm, got it
[13:24] <mdeslaur> thanks
[13:28] <GuidoPallemans> cjwatson: thanks
[13:56] <zul> mterry: ping
[13:57] <mterry> zul, hello!
[13:57] <zul> mterry:  can we get a quick review of oslo-config please (https://bugs.launchpad.net/ubuntu/+source/oslo-config/+bug/1130196)
[13:57] <zul> mterry:  its pretty simple package and should be ready to go
[13:59] <mterry> zul, looking
[14:00] <zul> mterry: thanks
[14:06] <GuidoPallemans> anyone else having trouble with qt creator since installing the sdk?
[14:07] <cjwatson> GuidoPallemans: like I say, #ubuntu-app-devel, please
[14:11] <mterry> zul, the right package name would be python-oslo.config
[14:11] <zul> mterry: uh?
[14:12] <mterry> zul, rather than python-oslo-config
[14:12] <zul> mterry: why?
[14:12] <diwic> TheMuso, feel like sponsoring bug 1074673 to make jackd2 start on the nexus7?
[14:12] <mterry> zul, package names are supposed to be python-XXX where XXX is what you use to import the module
[14:12] <mterry> zul, see for example python3-zope.event
[14:14] <zul> mterry:  ok this is blocking a new openstack upload to raring can i get a provisional ok provided that that package renaming?
[14:15] <mterry> zul, yeah, it seems fine beside.  let me comment in bug
[14:15] <zul> mterry: cool thanks
[14:15] <stgraber> pitti: it should work, but you may have hit the limit of inotify watches on the host
[14:16] <pitti> stgraber: yeah, we figured this out; thanks!
[14:16] <stgraber> pitti: np. Did you just bump the limit in /proc/sys/fs/inotify?
[14:16] <pitti> stgraber: right, we did
[14:17] <TheMuso> diwic: Sure.
[14:17] <diwic> TheMuso, thanks!
[14:18] <Daviey> mterry: erm, the binary package is already called what you described.. no?
[14:19] <Daviey> https://launchpad.net/ubuntu/+source/oslo-config/2013.1~b3-0ubuntu1
[14:19] <zul> Daviey:  not python-oslo.config
[14:20] <mterry> Daviey, dot instead of hyphen
[14:20] <mterry> small nit really
[14:21] <mterry> But if we're going to fix it, the sooner the better
[14:22] <Daviey> mterry: sorry, i've never seen that in policy.. can you point me to it?
[14:33] <TheMuso> diwic: has this been tested on armhf?
[14:38] <TheMuso> diwic: Oh and you forgot to run update-maintainers on the package.
[14:43] <mterry> Daviey, so obviously http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names has the basics, which is just that "if your module is foo, name it python-foo", which is ambiguous in such cases as a submodule.  I asked the question a while ago of barry, and he told me that dots were preferred to hyphens
[14:44] <barry> mterry, Daviey yes, e.g. python-foo.bar
[14:44] <mterry> Daviey, so..  "no, but I can point you to barry"  :)
[14:44] <barry> python-zope.interfaces
[14:45] <mterry> barry, could that be made clearer in the above python policy documetn?
[14:46] <Daviey> yeah.. there are a few packages i have NEW reviewed that haven't got this.. and a few that have been MIR'd i've noticed already
[14:46] <barry> mterry: hmm, would have thought it would be but i don't have that document tattooed to the back of my eyelids ;)
[14:46] <Daviey> barry: Policy is your friend. Trust the Policy. Love the Policy. Obey the Policy. :)
[14:46] <TheMuso> barry: Perhaps you can tell me whether we have the fix for http://bugs.python.org/issue16327 in our python toolchain yet. I've got a python 3 process here thats leaking file descriptors under particular circumstances. I'm working with upstream to get this solved, and was pointed to this bug.
[14:46] <barry> http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names
[14:47] <barry> so, yeah this should be added
[14:47]  * barry files a bug
[14:47] <mterry> Daviey, yeah it's not a commonly-followed aspect of the policy since it isn't actually written in it
[14:49] <barry> TheMuso: looks like that was applied to the 3.3 branch on 2012-11-11 so i would expect it should be in raring's 3.3 snapshot, which doko is pretty good at keeping up to date with hg head.  i'd have to investigate a bit to see if it's been backported
[14:49] <TheMuso> Hrm ok thanks.
[14:49] <Daviey> whilst decimals are fugly in package names IMO, if it is standardised and written intopolicy, i am happy. :)
[14:49] <stgraber> hallyn: hey, pitti and jibel strongly suspect some kernel bug that'd prevent inotify watches setup by containers from being properly freeed on container exit. Any idea how we'd go about debugging this?
[14:49] <stgraber> s/by/inside/
[14:50] <stgraber> this leads to the machine running out of watches (default being 8192) and then inotify stopping to work completely
[14:57] <vibhav> stgraber: Can inotify be used outside the kernel?
[14:58]  * vibhav was reading about inotify yesterday 
[14:59] <stgraber> vibhav: yeah, tons of stuff in userspace use inotify watches. I don't think the kernel itself uses those, it just provides the API.
[15:02] <vibhav> stgraber: AFAIK, inotify provides inotify_rm_watch for freeing watches, are you saying that this routine has a bug?
[15:06] <stgraber> vibhav: either that (but we probably would have noticed on a regular desktop) or the fact that a container can be killed at once (killing all the processes and destroying the various namespaces) somehow causes a race which prevents those watches from being freeed
[15:06] <doko> TheMuso, barry: it's in raring
[15:07] <TheMuso> doko: Thanks.
[15:09] <hallyn> stgraber: uh, one sec,
[15:10] <stgraber> pitti, jibel: do you already have some kind of reproducer script? (something that registers as many watches as possible until it reaches the limit)
[15:10] <pitti> stgraber: we don't yet, we just discovered about an hour ago that rebooting the host helps
[15:18] <vibhav> stgraber: Maybe I could write the reproduced script. What should it exactly do?
[15:18] <vibhav> reproducer*
[15:19] <hallyn> stgraber: vibhav i doubt many ppl use inotify_rm_watch, it's teh cleanup at task exit that's likely at fault
[15:21]  * vibhav takes a look 
[15:24] <vibhav> hallyn: Does a process using inotify automatically cleanup during exit?
[15:25] <vibhav> (even if it doesn't use rm_watches)
[15:25] <hallyn> vibhav: yes
[15:25] <hallyn> well, once all tasks using the inotify watch close
[15:26] <vibhav> Gotcha
[15:26] <hallyn> stgraber: well really i guess a little python script using pyinotify to open 8000 watches should help
[15:26] <hallyn> run it ina container, shut down container, restart,
[15:27] <hallyn> then try it without container, and with lxc-share
[15:27] <vibhav> When a process exits, exit_files() and exit_fs() are called
[15:28] <vibhav> To destroy objects related to file system data
[15:29] <vibhav> hallyn: If not with rm_watch, there could be a bug with exit_fs
[15:30] <vibhav> Which probably doesn't free the inotify watch
[15:45] <stgraber> hallyn: I'll do a quick test script, walking the FS and setting up a watch for everything it sees until it fails because it reaches the limit, after that it should just be a matter of killing the container and see if they got freeed
[15:48] <vibhav> stgraber: containers rely on cgroups, right?
[15:50] <stgraber> vibhav: lxc uses cgroups but cgroups aren't an actual requirement of containers. It's just that without them you don't get any kind of resource control (but you still get the namespacing).
[15:53] <hallyn> stgraber: i've got a script, hold on,
[15:54] <hallyn> i think the bug only triggers AFTER you max out the inotify_user_watches
[15:55] <hallyn> stgraber: http://33ad.org/pb/3YJ
[15:55] <hallyn> I ran this in a container, killed the container, could still keep running it,
[15:55] <hallyn> but after i ran it in a container *and* tried to run it on host at same time, i had trouble
[15:55] <hallyn> and now, i'll have to reboot :)
[15:56] <hallyn> no, ran it twice concurrently on the host
[15:56] <hallyn> hm, no,
[15:56] <hallyn> it just took awhile for the watches to clean up
[15:57] <vibhav> stgraber: void destroy(struct cgroup_subsys *ss, struct cgroup *cgrp) destroys a c group
[15:58] <hallyn> stgraber: (do a 'for i in `seq 0 6000`; do touch x-$i; done' before running that script)
[15:58] <vibhav> What about a bug there?
[15:59] <hallyn> ok i'm moving back to libvirt until there are more details (seems to be working right for me here)
[16:04] <hallyn> stgraber: btw, paste.ubuntu.com was hiccoughing when i tried to paste that script into it
[16:07] <stgraber> hallyn: script looks fine here, so the paste worked. I'll poke at it in a bit.
[16:08] <stgraber> pitti: can you share some details on the setup? are those standard fs backed containers (simple /var/lib/lxc entry without fancy lvm)? is the fs for / and /var/lib/lxc the same?
[16:12] <jibel> stgraber, it's a very standard 12.10 server, ext4 witouth lvm and everything on the same fs
[16:12] <stgraber> jibel: ok, I'll setup a VM with the same setup then. Thanks
[16:12] <jibel> stgraber, we are building gnome modules on this machine with the test suites that comes with the packages
[16:13] <jibel> stgraber, the cotnainer is raring amd64
[16:13] <jibel> *container
[16:40] <seif> hey guys
[16:41] <seif> how do i access the terminal on the tablet
[16:41] <seif> ?
[16:55] <Daviey> stgraber: hey, is there any news on that precise apparmor lxc issue we discussed a few weeks ago?
[16:56] <stgraber> Daviey: yep, SRUs for precise and quantal are in -proposed and all bugs have been verified, just waiting for the 7 days wait period
[16:59] <Daviey> stgraber: entered -proposed on the 20th?  with the changelog date being the 7th!?
[17:00] <Daviey> stgraber: to confirm, it includes the fix we discussed.. as you mentioned it missed one of the uploads
[17:04] <mterry> seif, I think you have to do such things over adb
[17:05] <seif> seriously?
[17:10] <stgraber> Daviey: yeah, with 12.04.2 it took a while to get the sru accepted into proposed
[17:11] <stgraber> Daviey: I uploaded on the 7th, then had to reject+fix an issue I spotted at the last minute, so final upload was on the 8th and they were accepted on the 20th
[17:28] <mterry> jono, heyo!  http://developer.ubuntu.com/get-started/gomobile/ is telling people to install ubuntu-sdk, but the PPA just has qt-components-ubuntu
[17:29] <jono> hey mterry
[17:29] <jono> dpm, ^
[17:30] <jono> mterry, dpm should be able to get that fixed
[17:31] <dpm> mterry, I assume this is Raring: didrocks did some packaging changes, but I didn't know ubuntu-sdk had been removed?
[17:32] <Daviey> stgraber: ah, thanks
[17:33] <dpm> mterry, I can see ubuntu-sdk in https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-proper?field.series_filter=raring - which PPA are you using?
[17:33] <mterry> dpm, this is P, Q, and R.   I don't know if ubuntu-sdk is old or new name, but all I've ever seen in that PPA is qt-components-ubuntu.  I believe the web page used to recommend downloading that name.  this is the first time I've heard the name "ubuntu-sdk"
[17:34] <dpm> mterry, which PPA are you using?
[17:34] <mterry> dpm, ah!  It's in the qt5-proper PPA.  I'm not using that, just the ubuntu-sdk-team/ppa PPA
[17:34] <mterry> dpm, since I'm on raring, I figured the qt5-proper PPA didn't hold anything of interest for me
[17:34] <mterry> (since raring has qt5 natively)
[17:35] <dpm> mterry, for now it's still the instructions on http://developer.ubuntu.com/get-started/gomobile/ (2nd step instructs to add that PPA)
[17:35] <mterry> dpm, sure.  My own fault for not following the instructions correctly
[17:36] <mterry> dpm, (though, I would have expected the sdk to be in the ubuntu-sdk-team's PPA.  Seems natural)
[17:36] <dpm> mterry, no worries, glad to hear it's not a packaging issue. Let me know if it woks.
[18:07] <stgraber> hallyn, pitti, jibel: right, so I've been playing with pyinotify on 12.10 with a 13.04 container, trying to use watches on both host and container, randomly killing the container. All the watches are properly cleared...
[18:25] <zul> can an archive admin promote python-oslo-config please? https://bugs.launchpad.net/ubuntu/+source/oslo-config/+bug/1130196
[18:29] <jibel> stgraber, ok, thanks for looking. For the moment I increased the number of inotify instances and restarted the server. I'll see if the problem occurs again.
[18:31] <stgraber> jibel: ok. If it does, it'd be interesting to kill all containers, then run: http://paste.ubuntu.com/5555887/
[18:32] <stgraber> this will try to setup 9000 watches and will print you how many it managed to setup
[18:32] <stgraber> on your setup, it should be 9000 unless something is wrong, then you'd get the number of free watches (if any) back
[18:36] <gkcn> has anybody experienced this evince crash: http://paste.ubuntu.com/5555900/
[18:37] <gkcn> on raring. it seems to be realted with libgeis1
[18:52] <gkcn> (filed a bug report https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1131886)
[19:16] <infinity> hallyn: Your new qemu conflicts with itself all over, thanks to the kvm conflict being unversioned.
[19:21] <infinity> hallyn: Oh, or because you added qemu-kvm, kvm to provides for all arches, while Debian only has it for x86...
[19:21] <infinity> hallyn: Though, that's not thinking ahead on Debian's part, since other arches could get kvm ported to them (I know it's coming for ARM).
[19:22] <hallyn> infinity: feh, i did it right in 1.3.0, did i mis-rebase?
[19:22] <infinity> hallyn: Anyhow, for now, britney won't let it through (and rightly so), cause it's all uninstallable.
[19:22] <infinity> -Provides: ${sysprovides:arm}
[19:22] <infinity> +Provides: ${sysprovides:arm}, qemu-kvm, kvm
[19:23] <infinity> (and the same for other arches)
[19:23] <infinity> That bit makes it uninstallable.
[19:23] <infinity> Since qemu-system-x86 conflicts with kvm.
[19:23] <infinity> And then qemu-system can't be installed, cause it wants to install both.
[19:24] <hallyn> infinity: so if you kick that, can i re-use that version #?
[19:25] <slangasek> no
[19:25] <slangasek> once it's accepted into the archive, the version number is forever
[19:25] <hallyn> k
[19:25] <hallyn> yes, but i didn't knwo whether it made it into the archive
[19:25] <hallyn> no idea where 'britney' sits
[19:25] <infinity> hallyn: What he said.
[19:25] <infinity> hallyn: britney is the bit of code between proposed and release.
[19:26] <infinity> hallyn: http://people.canonical.com/~ubuntu-archive/proposed-migration/
[19:26] <hallyn> oh
[19:26] <hallyn> infinity: the breaks/replaces in qemu-system-* to kvm was versioned in 1.3.0.  that got dropped
[19:27] <infinity> hallyn: That's not the problem.
[19:27] <infinity> hallyn: The problem is the provides versus conflicts.
[19:27] <infinity> hallyn: You didn't used to provide kvm from all the other arches.
[19:27] <hallyn> hm.  and i don't need to, as it was ever just a metapackage
[19:28] <hallyn> infinity: so i should be able to drop that, and keep the non-versioned B/R in qemu-system-* ?
[19:28] <infinity> hallyn: No, those should be versioned as well.
[19:29] <hallyn> ok
[19:29] <infinity> Replaces should, as a general rule, always be versioned, except in the special case of P/C/R.
[19:29] <hallyn> qemu-system-x86 did Provides: kvm in 1.3.0
[19:29] <infinity> Yeah, but none of the others did.
[19:29] <infinity> So, now qemu-system-x86 conflicts with qemu-system-arm.
[19:29] <hallyn> right
[19:30] <hallyn> thanks, will push fix asap
[19:32] <infinity> hallyn: Before you upload, you might want to test that the new world order still upgrades smoothly from, say, precise.
[19:32] <infinity> hallyn: Lots of mangling seems to have gone on here, and it was all pretty fragile to start with.
[19:36] <hallyn> infinity: i've pushed the proposed fix to github.com/hallyn/qemu # de.feb20.ubuntu2 ; will probably not push to archive until monday, after testing
[19:37] <infinity> hallyn: Sounds good.  britney's preventing the archive from exploding, so it's not urgent.
[19:38] <hallyn> infinity: testing from precise ...  is there a way to have do-release-upgrade itself look at /mirrors/debian?  Will it automatically do so if it's listed in sources.list?
[19:38] <hallyn> should i suppose... i was thinking ppas which are disabled, but this should work
[19:38] <infinity> hallyn: do-release-upgrade is a bit heavy-handed here, I'd just install qemu-kvm in a precise chroot, s/precise/raring/ in sources.list, and try a dist-upgrade. :P
[19:39] <infinity> hallyn: In fact, if a dist-upgrade works, that also means do-release-upgrade needs no painful quirking, which is a Good Thing.  The less release-upgrader needs to fix, the better.
[19:40] <hallyn> will try
[19:59] <Dimensional> Anyone here an official Ubuntu system developer?
[19:59] <Dimensional> I'm having a question/idea I'd like to discuss.
[20:00] <SpamapS> Dimensional: quite a few are. But its best to just ask the question and wait for an answer. Note that ubuntu-devel-discuss@lists.ubuntu.com may also be a better place to discuss big questions
[20:00] <Dimensional> Hmm.
[20:01] <cjwatson> zul: Done
[20:01] <cjwatson> Er, in theory, change-override seems to be taking a while ...
[20:01] <cjwatson> Ah, there it goes
[20:02] <Dimensional> The question involves the fact that each install CD is now too big to be on CD's, and barely take up a DVD themselves. The idea is that if possibly done right, one could package both images into the same DVD, and use some ISO bootloader to select which one to boot into. If it was integrated, it could make essentially a Universal Ubuntu Install DVD.
[20:02] <Dimensional> Installing 32 or 64 bit systems.
[20:03] <Dimensional> I now realize that's less of a question and just an idea.
[20:03] <cjwatson> It's been suggested but isn't high up the list at the moment
[20:03] <Dimensional> oh
[20:03] <Dimensional> Cool
[20:03] <cjwatson> I think last time it came up our DVDs were >half the limit so it didn't make sense
[20:03] <Dimensional> ?
[20:03] <cjwatson> Ages ago
[20:04] <cjwatson> On the other hand - it would mean having people download considerably more than they need, and bandwidth still isn't so plentiful that that's ignorable - it's not a completely obvious trade-off
[20:04]  * Dimensional was able to do it, but wishes it could be more integrated. Something that could also detech which hardware architecture the disc was running on, and if it saw it was a 63-bit, would give a boot option to which architecture to install on.
[20:05] <Dimensional> It's an obvious tradeoff when you account for the fact that you'd be burning 2 DVDs instead of one. They might be cheap, but not that cheap.
[20:05] <cjwatson> Eh, only if you need both!
[20:05] <sarnold> 63 bit? :) is that a new IBM machine similar to their 31-bit z/OS? :)
[20:05] <Dimensional> 64*
[20:05] <Dimensional> I shall make a new system. It shall have a 2-bit architecture, because I can't stand 1-bit of competition. :P
[20:06] <cjwatson> I suspect that for me the bandwidth cost of an extra few hundred megabytes may actually exceed the cost of a blank DVD - would have to sit down and do the sums
[20:06] <sarnold> I'd personally prefer something be thrown overboard and drop back to CD-R size. I've got another 20 or so CD-Rs from a 50-pacl bought ages ago, and never had a need to buy any writable DVDs before..
[20:06] <cjwatson> In any case, I can see the point of it a bit more now that UEFI has meant we don't have a common image that boots on all 32-bit machines
[20:06] <sarnold> Dimensional: lol
[20:06] <clue_h> I think it would be good for folks with a couple of machines and want to install a minimal on one and full on the other etc. But people prefer the different options they have for the ISOs they download
[20:06] <cjwatson> sarnold: really, really unlikely to happen, I'm afraid - we fought that battle for many years and eventually lost
[20:06] <sarnold> cjwatson: I figured it wasn't given up lightly :(
[20:07] <Dimensional> ok
[20:07]  * Dimensional is a little lost.
[20:07] <cjwatson> s/boots on all 32-bit machines/boots on all x86 machines/ in my last-but-one comment
[20:08] <zul> cjwatson: thanks
[20:08] <Dimensional> ok
[20:08] <Dimensional> Hmm.
[20:09] <Dimensional> So you were meaning of combining the DVD images and using a UEFI bootloader?
[20:09]  * Dimensional is still lost, he might have found the map.
[20:09] <Dimensional> no. Not a map.
[20:10] <Dimensional> With UEFI, the possibility of putting them both onto a single DVD is more likely?
[20:29] <cjwatson> Dimensional: No, what I mean is that the advent of widespread UEFI means that the 32-bit image is no longer a sane default that works on most systems; when we had that sane default there was little reason to bother with a "universal" image
[20:29] <Dimensional> ah
[20:29] <cjwatson> So it perhaps makes it more likely that we might do this; but of the people who work on this kind of thing their plates are all very full for a good while to come already
[20:29] <Dimensional> kk
[20:29] <cjwatson> It's worth us thinking about again, though, I agree; thanks
[20:30] <infinity> cjwatson: It's probably worth just revisiting what the "default" image is again, too.  New 32-bit systems are vanishingly rare (or nonexistent?)
[20:30] <infinity> cjwatson: Last time it came up, Atom was the killer, but new Atoms are x86_64.
[20:32] <infinity> (Personally, I'd still like to see the default be an amd64 kernel, x32 userspace, and i386 multiarch for binary blob support, but we're years away from that being viable, I suspect)
[20:32] <cjwatson> amd64 kernel and i386 userspace is viable, though, and is more power-efficient IIRC
[20:32] <cjwatson> At least more memory-efficient
[20:32]  * infinity nods.
[20:33] <infinity> It can lose out on performance, due to the LCD being rather low.
[20:33] <cjwatson> LCD?
[20:33] <infinity> (And the lack of registers)
[20:33] <cjwatson> Oh, right
[20:33] <cjwatson> Yeah
[20:33] <infinity> Lowest Common Denominator.
[20:34] <Dimensional> I can see some day that 32 bit systems will be gone, and we'll remove the 'long' flag from the CPU and just have it default to 64. So the new 'long' flag would refer to a 128-bit architecture.
[20:34] <infinity> 128-bit computing is probably much further out than people think (or never going to happen in general purpose CPUs).
[20:34] <sarnold> hunh. my largest process only has a vsz of 2042M...
[20:35] <cjwatson> I confidently predict that nobody will ever be silly enough to remove the "long" flag
[20:35] <infinity> Eventually, we hit the brick wall of how small you can make parts.
[20:35] <cjwatson> Not while remaining otherwise architecturally compatible, at any rate
[20:35] <infinity> Trinary quantum computing could change all that, but that changes EVERYTHING anyway, not just address space. :P
[20:35] <infinity> And also hurts my brain to start thinking in a different number system.
[20:36] <Dimensional> yup
[20:36] <Dimensional> heh
[20:36]  * Dimensional already thought about another numbering system and ways of implimentation. Head still hurts, but so worth it.
[20:37] <dobey> infinity: don't think of it as a different number system. just think of all the bits being both on and off at the same time :)
[20:39] <infinity> dobey: Thanks.  That didn't give me an aneurysm at all.
[20:42] <Dimensional> For me, I had thought it over more like directions. For hard drives, in order to tell if something is a 1 or a 0, it checks two bits on the hardware. Two magnetic pieces. If their polarity is the same, it's a 0. If they are different, then it's a 1. So what if we worked on increasing the accuracy of the head and instead read it with directions. Both left, 0. one left, one right, 1. Both right, 2
[20:42] <melodie> hi
[20:42] <Dimensional> hello
[21:12] <dobey> infinity: haha. it's ok though. you're still alive, even if you're dead. all the bits are zombies!
[21:16] <infinity> dobey: http://www.youtube.com/watch?v=ueBZuZAoglE
[21:20] <dobey> lol
[22:51] <hallyn> infinity: well dist-upgrade from precise mostly went fine (no complaints/refusals from qemu itself), but my archive seems to have ended up somewhat b0rked, I get things like
[22:51] <hallyn> E: Internal Error, No file name for libblkid1
[22:52] <infinity> hallyn: Hrm.  Can you reproduce that?  I'd love a solid reproducer for that, so I can hunt it down.
[22:53] <hallyn> infinity: i assume so, but as my victim box was already running precise I first tested on the bare metal.  gotta frst reinstall and set up some containers to test in.
[22:53] <infinity> Ahh.
[22:54] <hallyn> (well i guess i can let the archive rot, and use a container anyway)
[22:54] <hallyn> (trying that for the sake of time)
[23:08] <hallyn> infinity: i can definately reproduce it with the new qemu packages, let me try without them
[23:16] <hallyn> i think it's a bug in how i make my local mirror
[23:51] <hallyn> well i dunno, it only does it when i start from precise, follow https://wiki.ubuntu.com/SergeHallyn_localrepo and actually put the new qemu debs into the local mirror, sed -i 's/precise/raring/' sources.list, and update/dist-upgrade...
[23:52] <hallyn> so it almost seems like it insists that deps for the pkgs in local mirror must also be in the local mirror
[23:53]  * hallyn out