=== mwhudson_ is now known as mwhudson
[00:58] <sn33zy> im having a hard time finding the package to satisfy aclocal-1.13
[01:02] <sarnold> sn33zy: the saucy automake package offered one http://packages.ubuntu.com/search?searchon=contents&keywords=aclocal-1.13&mode=exactfilename&suite=saucy&arch=any
[01:07] <sn33zy> sarnold, yeah i later realized i have aclocal 1.14 installed and wondering why it DESIRES the 1.13 version for the build instead
[01:08] <sarnold> sn33zy: auto* stuff sometimes doesn't work with newer versions; you can try with 1.14 and if it works fine, hooray :)
[01:17] <sn33zy> gah
[01:17] <sn33zy> ./configure: line 22834: GNOME_DEBUG_CHECK: command not found
[01:17] <sn33zy> ./configure: line 22835: syntax error near unexpected token `maximum'
[01:17] <sn33zy> ./configure: line 22835: `GNOME_COMPILE_WARNINGS(maximum)'
=== _salem is now known as salem_
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[03:21] <lamont> is utopic currently safe to do-release-upgrade to?
[03:21] <lamont> for developer values of safe, that is.
[03:22] <ScottK> It's certainly safe for me if you do it.
[03:23] <stgraber> lamont: I did it this morning on my laptop and outside of some compiz packaging mess which has been reasonably easy to fix (remove the mess, install ubuntu-desktop^), things went fine and the machine still boots
=== salem_ is now known as _salem
=== didrocks1 is now known as didrocks
[04:49] <pitti> Good morning
[04:49] <pitti> hallyn: sure
[05:49] <pitti> hallyn: uploaded; and yay that we can sync now
=== Guest33473 is now known as StevenK
[07:04] <LocutusOfBorg1> can anybody please retry this build? https://launchpad.net/ubuntu/+source/aegisub/3.1.2-1/+build/5939512
[07:04] <LocutusOfBorg1> it is a really old ICE
[07:05] <pitti> LocutusOfBorg1: done
[07:05] <LocutusOfBorg1> 10x
[07:15] <dholbach> good morning
[07:15] <ion> that
[07:17] <dholbach> Noskcaj, did you have any luck with python-wsme?
[07:18] <dholbach> Noskcaj, I'd really appreciate if you could take a look at it and fix it some time soon, or let folks know on the mailing list of elsewhere, that you need some help
[07:39] <LocutusOfBorg1> wxpython3.0 fails to build on ubuntu because of a missing dependency on mesa-common-dev
[07:39] <LocutusOfBorg1> dragged in by gtk2.0-dev in debian, but NOT in ubuntu
[07:39] <LocutusOfBorg1> some substvars is not working
[07:43] <LocutusOfBorg1> pitti, failing :(
=== doko_ is now known as doko
[08:04] <doko> tkamppeter, system-config-printer python3 \o/, what is left, hplip?
[08:12] <pitti> oh wow, it did happen? nice!
[08:14] <pitti> err, how would that work? system-config-printer-gnome is still pulling in python-gtk2 and all the python 2 bits?
[08:15] <pitti> tkamppeter: ^ ah, it actually does use python3-gi and various gir1.2-* now, seems you just didn't update the Depends: for python3 and GI?
[08:16] <pitti> awesome, this was a really tough one
[08:46]  * xnox ponders who maintains system-config- et.al and friends
[08:47] <LocutusOfBorg1> pitti did you read the mesa-common-dev problem?
[08:48] <LocutusOfBorg1> seems that pango in debian needs it, while in ubuntu doesn't
[08:48] <LocutusOfBorg1> and this is (one) of the cause of the build failures
[08:48] <pitti> LocutusOfBorg1: sounds like a missing build dep in wxpython then?
[08:50] <LocutusOfBorg1> sound like a missing wl,as-needed in debian/pango? :)
[08:50] <LocutusOfBorg1> I wonder why pango drags unneeded dependencies
[08:51] <LocutusOfBorg1> anyway your solution seems the right one ;)
[09:22] <LocutusOfBorg1> seb128, you there?
[09:22] <LocutusOfBorg1> sorry for bothering
[09:22] <seb128> LocutusOfBorg1, sort of, not really, in a meeting
[09:22] <seb128> why?
[09:22] <LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/1353362
[09:23] <ubottu> Ubuntu bug 1353362 in cairo (Ubuntu) "cairo needs merge from debian" [Undecided,New]
[09:23] <LocutusOfBorg1> ^^^
[09:23] <seb128> I can have a look to that next week
[09:23] <seb128> I'm travelling this week/in meetings until friday
[09:23] <seb128> but anyone can do that
[09:24] <LocutusOfBorg1> can I just copy the debian packaging, look at the ubuntu1 delta and ask for a sponsor?
[09:25] <seb128> well, you can do the merge if you want yes
[09:26] <seb128> if that's the question
[09:27] <LocutusOfBorg1> yes, I don't know too much about cairo, I don't want to prepare a stupid debdiff
[09:27] <LocutusOfBorg1> this is why I asked you ;)
[09:27] <LocutusOfBorg1> I don't know how big is the delta from debian
[09:27] <Noskcaj> dholbach, transaction is not actively maintained in debian, and turbogears use python-support and many universe depends :(
[09:27] <dholbach> Noskcaj, yep, doko mentioned something like that - might be worth trying to workaround the new (build-)dep
[09:28] <Noskcaj> the debian maintainer seems to think it's needed, but i'll branch the code and have a look
[09:29] <dholbach> great
[09:29] <doko> Noskcaj, can can see this here: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[09:30]  * Noskcaj cries
[09:54] <Noskcaj> dholbach, Crappy patch for turbogears made, transaction maintainer contacted
[10:02] <Noskcaj> I'll push my fixes on i work transaction out
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
=== ricmm_ is now known as ricmm
=== MacSlow is now known as MacSlow|lunch
[11:01] <tkamppeter> pitti, principally, I have switched over to the Python-3-based s-c-p 1.5.0 now. If something in the packaging is still missing/wrong, please tell me (or patches welcome). Thanks.
[11:02] <pitti> tkamppeter: yes, the build deps are py3 now, but not the binary deps
[11:23] <doko> Noskcaj, transaction seems to be unproblematic, turbogears2 is the problematic one
[11:43] <tkamppeter> pitti, following python3 packages do not exist: python3-gtk2, python3-notify, python3-libxml2, python3-gnomekeyring, python3-pycurl. What are the replacements for them?
[11:44] <tkamppeter> pitti, is it correct that python-gobject is replaced by python3-gi?
[11:51] <pitti> tkamppeter: yes, python-gobject -> python3-gi
[11:52] <pitti> tkamppeter: python-gtk2 etc. are replaced with gir1.2-*-*
[11:52] <pitti> tkamppeter: you need to grep for "from gi.repository import" (e. g. Gtk, Pango, etc.) and map these to the gir1.2-* names
[11:52] <pitti> tkamppeter: python3-pycurl does exist
[11:53] <pitti> tkamppeter: supposedly python3-lxml is the corresponding replacement for python3-libxml2, but I'm not 100% sure
[12:16] <slangasek> xnox: so lp:~xnox/ubuntu/utopic/upstart/core-split says it's been merged, does that mean you no longer need my review?
[12:22] <xnox> slangasek: pitti has battled it out =)
[12:23] <xnox> slangasek: it typically request multiple reviews, but await at least one extensive review.
[12:23] <pitti> oh right, it's already in NEW; thanks xnox
[12:23] <xnox> slangasek: where is, is xnox =)
[12:23] <xnox> slangasek: where it, is xnox =)
[12:23]  * xnox can't type today
[12:23] <xnox> upgrades & operation tested on phone, desktop and server as well.
[12:25] <xnox> slangasek: you of course, as an archive admin, may choose to review NEW =)
[12:27] <tkamppeter> pitti, thanks. I did all the changes, but did not find a gdk and a gobject in the gir1.2 collection. All the rest seems to be solved.
[12:28] <pitti> tkamppeter: Gdk is part of gir1.2-gtk-3.0
[12:28] <pitti> tkamppeter: GObject is part of gir1.2-glib-2.0
[12:28] <tkamppeter> pitti, OK, thanks.
[12:31] <tkamppeter> pitti, as the whole thing is running with python3 now and depends only on python3 packages, do I have to rename the python-cupshelpers package into python3-cupshelpers (or simply let it provide python3-cupshelpers so that both python2 and python3 apps can use it)?
[12:31] <pitti> tkamppeter: err yes, it needs to be renamed to python3-cupshelpers
[12:32] <pitti> tkamppeter: in fact, the current python-cupshelpers is broken as it only provides a Python 2 package
[12:32] <pitti> tkamppeter: fortunately the only reverse dependencies are system-config-printer itself
[12:32] <pitti> so it didn't break anything
[12:32] <pitti> tkamppeter: but the rename needs to be done
[12:32] <tkamppeter> pitti, ho do I get a python3 package then?
[12:33] <pitti> tkamppeter: look at its contents, it already is a python3 package
[12:33] <pitti> tkamppeter: /usr/lib/python3/dist-packages/cupshelpers
[12:33] <pitti> tkamppeter: it just needs to be renamed
[12:33] <pitti> tkamppeter: and ${python:Depends} changed to ${python3:Depends}, and similar
[12:33] <pitti> tkamppeter: I suppose you updated its python-pycurl dep already
[12:35] <tkamppeter> yes I did so.
[12:36] <tkamppeter> pitti, all ${python:Depends} I replaced by ${python3:Depends} in the control file, all python-cupshelpers by python3-cupshelpers.
[12:36] <pitti> tkamppeter: great, thanks
[12:36] <tkamppeter> pitti, no "python-" any more, all "python3-" now.
[12:36] <pitti> \o/
[12:37] <tkamppeter> pitti, all "gir"ified in system-config-printer-gnome
[12:38] <LocutusOfBorg1> dholbach, do you have time for looking for a package?
[12:38] <tkamppeter> pitti, anything to do with the old python-cupshelpers binary package? Or will it simply go away by "apt-get autoremove"?
[12:39] <LocutusOfBorg1> or pitti maybe ;)
[12:39] <dholbach> LocutusOfBorg1, is it on http://reqorts.qa.ubuntu.com/reports/sponsoring/? :)
[12:40] <pitti> tkamppeter: yes, it'll be removed semi-automatically as it doesn't have remainin reverse dependencies
[12:40] <pitti> tkamppeter: so don't worry about it
[12:41] <dholbach> LocutusOfBorg1, I'm just asking because that's usually the best place to put something which needs uploading :)
[12:42] <LocutusOfBorg1> not right now
[12:42] <LocutusOfBorg1> yes I know
[12:42] <dholbach> ok good :)
[12:42] <LocutusOfBorg1> ;)
[12:42] <LocutusOfBorg1> (I just would like to see the problem fixed asap
[12:43] <dholbach> ok, which package is it?
[12:43] <LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/1353362
[12:43] <ubottu> Ubuntu bug 1353362 in cairo (Ubuntu) "cairo needs merge from debian" [Undecided,New]
[12:44] <LocutusOfBorg1> sorry for the long time, I needed to prepare the debdiff
[12:44] <tkamppeter> pitti, thank you very much, the package is on the way.
[12:44] <LocutusOfBorg1> and to check every change in debian if was merging with ubunut
[12:44] <slangasek> xnox: only the binary packages get into the new queue, no sane diffs from there ;P
[12:44] <LocutusOfBorg1>  /s/ubunut/ubuntu
[12:44] <slangasek> but yeah, I can look at it if no one beats me to it
[12:44] <LocutusOfBorg1> I checked every git commit since the last merge from debian and cherry picked them in ubuntu
[12:45] <LocutusOfBorg1> and for the shlib file I built it locally and double checked if symbols were still there in .13 release
[12:45] <LocutusOfBorg1> everything was good so far
[12:45] <dholbach> LocutusOfBorg1, maybe I'm not the best person to review this, but instead somebody from the desktop team could take a look at it?
[12:45] <LocutusOfBorg1> I still don't know if this is needed
[12:45] <LocutusOfBorg1> +  * debian/patches/server_side_gradients.patch:
[12:45] <LocutusOfBorg1> +    - Don't use server side gradients, most drivers don't handle those and
[12:45] <LocutusOfBorg1> +      are really slow
[12:46] <LocutusOfBorg1> seb128 has quit
[12:46] <dholbach> I mentioned this in #ubuntu-desktop
[12:46] <dholbach> LocutusOfBorg1, Séb is in China, where it's 20:46 right now :)
[12:46] <LocutusOfBorg1> wonderful :)
[12:46] <LocutusOfBorg1> time for VAC ;)
[12:47] <LocutusOfBorg1> anyway this is something that worries me a little bit, since the last 10 debian release fixed a lot of problems in the package
=== _salem is now known as salem_
[12:47] <tjaalton> LocutusOfBorg1: can't enable gl backend
[12:47] <tjaalton> because of bug #725434
[12:47] <ubottu> bug 725434 in cairo (Ubuntu Natty) "Nvidia drivers lead to extra memory usage for each process using libGL" [High,Fix released] https://launchpad.net/bugs/725434
[12:48] <xnox> slangasek: well the diff is already generated for the source package by launchpad http://launchpadlibrarian.net/181650696/upstart_1.13.1-0ubuntu2_1.13.1-0ubuntu3.diff.gz
[12:48] <dholbach> LocutusOfBorg1, no vac though
[12:48] <xnox> slangasek: maybe queudiff simply needs to be taught how to fetch those?
[12:49] <slangasek> not particularly; the binary NEW review is for reviewing the binary delta
[12:52] <LocutusOfBorg1> tjaalton, do you think it is still the case? why debian doesn't have this problem?
[12:55] <tjaalton> i don't know
[12:57] <LocutusOfBorg1> anyway disabling again might be trivial
[13:20] <tkamppeter> pitti, the new python3-cupshelpers 1.5.0...0ubuntu3 conflicts with python-cupshelpers 1.5.0...0ubuntu1 and python-cupshelpers 1.5.0...0ubuntu2, but not with python-cupshelpers 1.4.x and older. How do I the breaks/conflicts/replaces with correct versioning?
[13:20] <pitti> tkamppeter: ah, for upgrades within utopic from the past few days
[13:21] <pitti> tkamppeter: hmm, tricky; but I suppose if you just do Replaces:/Breaks: python-cupshelpers (<< 1.5.0...0ubuntu3) it'll do
[13:21] <pitti> tkamppeter: you can drop these after a few weeks or so
[13:33] <tkamppeter> pitti, I get paste.ubuntu.com/7970474/  Anytjing missing?
[13:34] <tkamppeter> pitti, do I also needs Conflicts: or Provides:
[13:34] <pitti> tkamppeter: use --auto-deconfigure as advertised, or dpkg -P python-cupshelpers first and run it a few times
[13:35] <pitti> tkamppeter: with dpkg alone it's hard to upgrade over breaks: and package renames; apt will figure it out
[13:35] <pitti> tkamppeter: no, Provides: would be entirely wrong; Breaks:/Replaces: is correct and sufficient, no Conflcits: necessary
[13:36] <tkamppeter> pitti, thanks. So then all is correct and I can upload it?
[13:36] <doko> xnox, did you recently touch mpi? https://launchpadlibrarian.net/181599384/buildlog_ubuntu-utopic-amd64.dolfin_1.3.0%2Bdfsg-2build2_FAILEDTOBUILD.txt.gz
[13:36] <pitti> tkamppeter: did you manage to install the packages now?
[13:36] <pitti> tkamppeter: if that works (with removing python-cupshelpers manually), and s-c-p still runs, it's fine
[13:39] <tkamppeter> pitti, all works now. Thank you. I will upload now.
[13:40] <pitti> tkamppeter: cool, danke!
[13:41] <xnox> doko: i did touch a lot of mpi.... =(
[13:42] <xnox> doko: fun, we did do libpetsc3.4.2-dev transition as part of the mega transition.
[13:43] <xnox> doko: i like how ppc64el is green =) so perfect - ship it. Everyone has switched to ppc64el by now, haven't they? =)
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
=== mbarnett` is now known as mbarnett
[13:47] <mlankhorst> can xserver-xorg-video-s3 be removed? it's no longer in debian
[13:56] <doko> xnox, no, blacs-mpi wasn't built there. now fixed
[14:03] <hallyn> pitti: \o/  thanks
[14:09] <pitti> hallyn: ah, it's imported, want me to sync, or are you at it?
[14:10] <hallyn> what does imported mean?
[14:11] <pitti> hallyn: into Launchpad, so it's syncable
[14:13] <hallyn> ok - please go ahead, else i'll do it after bfast
[14:13] <hallyn> "you people" had a busy night, 236 unread since 8 hrs ago
[14:14] <pitti> hallyn: synced
[14:16] <hallyn> thx
[14:56] <LocutusOfBorg1> tjaalton, I'm checking right now
[15:01] <zyga> cjwatson: hi, I'm trying to convert pyotherside packaging from SVN to git and move it to collab-maint, I got the git tree by following https://wiki.debian.org/Alioth/Git#Convert_a_SVN_Alioth_repository_to_Git but I'm unsure about a few things. Do you have a moment for a few questions here on IRC?
[15:03] <cjwatson> zyga: probably not today; though in general I'd recommend asking rather than asking to ask :)
[15:05] <xnox> current utopic (without proposed) is trying to remove unity and compiz on upgrade and hold-back unity8
[15:05] <xnox> =(
[15:06] <zyga> cjwatson: excellent advice: should I try to integrate upstream git repository into the packaging repository? should I (do I have to?) do the same for pristine upstream tarballs
[15:07] <zyga> cjwatson: and lastly (most importantly perhaps) where do I put the repository to? various alioth docs are kind of fuzzy about that, links end up 404, etc
[15:11] <xnox> actually, i had a broken unity installed locally, downgrading to utopic fixed everything.
[15:13] <cjwatson> zyga: my opinion (not shared by everyone, apparently, but what the hell) is that if upstream git exists or is easily synthesisable, then there's no excuse for not integrating it into the packaging repository
[15:13] <cjwatson> zyga: pristine tarballs are really easy to handle in git using pristine-tar
[15:14] <cjwatson> zyga: I've been converting all my packages to git-dpm, and love it; it makes both the above things pretty straightforward.  I've gone on about it fairly recently on debian-devel
[15:15] <zyga> cjwatson: do you have an example package that I could look at?
[15:15] <zyga> cjwatson: branch/tag/etc arrangement
[15:15] <cjwatson> zyga: openssh, parted, grub2
[15:15] <zyga> cjwatson: where can I find them?
[15:15]  * zyga looks at grub2 control file
[15:15] <cjwatson> apt-cache showsrc has the vcs-* headers
[15:15] <zyga> right, thanks
[15:16] <cjwatson> zyga: or smaller-scale: man-db, putty, six, trn4
[15:16] <cjwatson> zyga: if you don't already have a suitable alioth group, you can push packages under users/; e.g. I have this in ~/.gitconfig:
[15:16] <cjwatson> [url "git+ssh://git.debian.org/git/"]
[15:16] <cjwatson>         insteadof = debian:
[15:17] <zyga> users/ ?
[15:17] <cjwatson> then I push to e.g. debian:users/cjwatson/libpipeline.git, and that shows up as git://anonscm.debian.org/users/cjwatson/libpipeline.git and http://anonscm.debian.org/cgit/users/cjwatson/libpipeline/
[15:17] <zyga> ah
[15:17] <zyga> do you co-maintain any of your packages?
[15:18] <cjwatson> yes, e.g. six is under collab-maint
[15:18] <zyga> ok, I'll start with that, thanks for your time!
[15:18] <cjwatson> so that's debian:collab-maint/six, git://anonscm.debian.org/collab-maint/six.git, http://anonscm.debian.org/gitweb/?p=collab-maint/six.git
[15:18] <cjwatson> or indeed http://anonscm.debian.org/cgit/collab-maint/six.git
[15:19] <cjwatson> zyga: http://lists.alioth.debian.org/pipermail/pkg-grub-devel/2014-January/013883.html may be helpful too
[15:20] <zyga> cjwatson: thanks!
[15:21] <cjwatson> zyga: oh, my last comment, for converting existing packages I always like to keep as much history as possible, and http://www.catb.org/~esr/reposurgeon/ was the first tool I found that would let me convert my svn/bzr/etc. history into git without ridiculous amounts of effort
[15:22] <cjwatson> so I can recommend that as a good building block
[15:22] <zyga> cjwatson: git-svn got the history I wanted
[15:22] <zyga> cjwatson: though, that's a bare debian repo history
[15:22] <zyga> cjwatson: so I'm not sure if I shoud reply that on top of upstream releases or not
[15:22] <cjwatson> ah, you would want to stitch that into something better
[15:23] <cjwatson> if that were me, I would use reposurgeon to stitch it in on top of upstream so that I could pretend it was always that way
[15:23] <cjwatson> but your call :)
[15:23] <zyga> cjwatson: I guess a plain rebase will do in this case
[15:23] <zyga> cjwatson: rebase the packaging on top of each release
[15:23]  * zyga is still unclear about branches though
[15:23] <cjwatson> A plain rebase is unlikely to be at all straightforward with more than one branch point like that
[15:24] <cjwatson> Branches: if they're ones I want to generally advertise, I create them at the top level and push them, for random personal experimentation in shared repositories I tend to call them people/cjwatson/foo
[15:24] <cjwatson> if I want to push them
[15:25] <cjwatson> Not much more needed really.  If you're using git properly you'll likely have lots of short-term branches locally that you never push anywhere
[15:25] <zyga> cjwatson: I need to look at your code to have more meaningful questions now
[15:25] <cjwatson> Most of my packaging branches have master, upstream, pristine-tar at a minimum
[15:25] <cjwatson> *packaging repositories
[15:25] <zyga> I meant the upstream vs debianized branches
[15:25] <cjwatson> That's upstream vs. master
[15:25] <cjwatson> git-dpm puts the upstream ref in the right place when you import a new upstream version
[15:26] <cjwatson> Which in best practice is a commit whose parent is the upstream tag and which contains the delta between the upstream tag and the released tarball (if any)
=== juliank0 is now known as juliank
[15:48] <gQuigs> I was wondering why bootchart2 hasn't been automatically synced from debian?  (https://bugs.launchpad.net/ubuntu/+source/bootchart/+bug/1035385)
[15:48] <ubottu> Ubuntu bug 1035385 in bootchart (Ubuntu) "[ Request ] Missing bootchart2, please sync it from Debian Sid" [High,Triaged]
[15:49] <gQuigs> ^the bug is now out of date as bootchart2 has made it all the way to stable (I'm not sure the best place to sync from right now...)
[16:08] <cjwatson> gQuigs: overwrites binaries from bootchart; when I last checked I heard there wasn't much point as our bootchart had most of the relevant stuff anyway
[16:08] <cjwatson> Actually binaries from pybootchartgui
[16:08] <cjwatson> anyway it's in the sync blacklist
[16:08] <cjwatson> bootchart # keybuk, entirely separate packaging
[16:08] <cjwatson> bootchart2 # cjwatson, ditto; our bootchart source has many of the improvements here, and the pybootchartgui binary clashes
[16:10] <gQuigs> cjwatson: oh.. in that case should I guess I should file a separate request to pull the systemd units out of boothchart2?
[16:10] <cjwatson> That might be a good idea, yeah
[16:10] <tedg> pitti, Saviq and I are looking at some PPA build issues, which might be from systemd needing a new sysvinit in proposed. Do you know about that?
[16:11] <gQuigs> cjwatson: will do, thanks
[16:14] <xnox> gQuigs: the problem with bootchart2 was that it was systemd only and doesn't support upstart boot. Kind of worthless for comparing bootspeed on ubuntu then, isn't it.
[16:15] <gQuigs> xnox: oh, right, that would make it very useless..
[16:17] <gQuigs> so I believe that bug could be marked "Won't Fix"
[16:36] <LocutusOfBorg1> tjaalton, please let me know if something else is needed
[16:36] <LocutusOfBorg1> right now I'm testing my package ;)
[16:52] <pitti> tedg: err no, I don't -- what's up with that?
[16:52] <tedg> pitti, It seems to be causing some failure in proposed
[16:52] <tedg> pitti, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#systemd
[16:53] <pitti> tedg: oh argh -- I have a new sysvinit installed locally for a week or so, waiting for slangasek's go ahead
[17:31] <doko> tkamppeter, pitti: no way for foo2zjs to use lcms1 again ...
[17:45] <pitti> tedg: I uploaded another systemd with lower initscripts dep; thanks
[17:45] <pitti> Saviq: ^
[17:50] <pitti> stgraber: https://github.com/lxc/lxc/commit/281b843 > whoops, thanks!
[17:51] <stgraber> np :)
=== roadmr is now known as roadmr_afk
=== and`_ is now known as and`
[18:34] <tedg> xnox, stgraber, so I'm trying to use the cgroup feature in Upstart. But it seems on the N4 there is no cpuset or even an upstart dir in /sys/fs/cgroup
[18:35] <tedg> Is there something I need to do to get those?
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
[18:47] <stgraber> tedg: no and they don't need to be there so long as cgmanager is running
[18:51] <tedg> stgraber, Then what should my cgroup line be in my upstart job? I was using "cpuset" before because that seemed to work on my desktop.
=== arrrghhh is now known as arrrghhhAWAY
[18:51] <tedg> stgraber, So it was just "cgroup cpuset"
=== roadmr_afk is now known as roadmr
[19:00] <stgraber> tedg: just had a quick look at what cgroups are enabled in the mako kernel
[19:00] <stgraber> tedg: it looks like you can only use: debug, cpu, cpuacct and freezer
[19:00] <stgraber> tedg: if you need memory, cpuset or any of the others, you'll have to talk to the kernel team
[19:01] <tedg> stgraber, Well, what should I use? :-)  I really just want a bag of PIDs.
[19:01] <tedg> I tried cpu on my desktop, but that didn't seem to work.
[19:01] <tedg> Changing to cpuset fixed things
[19:02] <stgraber> tedg: did you try freezer? seems like this one is available everywhere
[19:02] <tedg> stgraber, No, I didn't. I can.
[19:12] <tedg> stgraber, freezer gets me much further, thanks!
[19:16] <hallyn> you can also just mount -o name=bag , if you only want to collect pids
[19:39] <stgraber> hallyn: you'd need to do that before cgmanager starts if you want to use it with upstart
[19:49] <hallyn> stgraber: /etc/default/cgmanager
[19:49] <hallyn> (add it to the list of options)
=== huats_ is now known as huats
=== timrc is now known as timrc-afk
[21:50] <tkamppeter> doko, what do you mean? What is broken with foo2zjs?
=== arrrghhhAWAY is now known as arrrghhh
=== salem_ is now known as _salem
=== timrc-afk is now known as timrc