[02:01] <lfaraone> The "foo has been converted to an upstart job" symlink is automatically created whenever you install an upstart job on a package that supports upstart, right?
[02:01] <lfaraone> *install a package that supports upstart on a system that uses upstart
[02:05] <xnox> lfaraone: no, not any more.
[02:05] <lfaraone> xnox: oh, what happens these days?
[02:06] <xnox> lfaraone: init.d script & upstart jobs can co-exist. and $ service command knows which one to pick
[02:06] <xnox> lfaraone: use $ service, for both init.d and upstart job control.
[02:06] <lfaraone> xnox: okay. What if somebody calls the init job directly?
[02:06] <xnox> lfaraone: how?
[02:07] <lfaraone> xnox: I don't know, somebody has muscle memory for `/etc/init.d/foobar start`
[02:07] <xnox> exit 1
[02:07] <lfaraone> xnox: so, we should have the script test if upstart is installed and if so exit?
[02:07] <xnox> at the moment. which imho is regression from previous ways, where the real thing was still called & warning messages printed.
[02:08] <xnox> lfaraone: yes, there is a guide about it. One sec.
[02:08] <xnox> lfaraone: https://wiki.ubuntu.com/UpstartCompatibleInitScripts
[02:09] <xnox> lfaraone: there is a helper function "init_is_upstart" and one does: if init_is_upstart; then case $1 in stop) exit 0 ;; case start|restart|force-restart) exit 1;; esac
[02:09] <xnox> fi
=== freeflying is now known as freeflying_away
=== freeflying_away is now known as freeflying
[05:40] <pitti> Good morning
[05:43] <pitti> rsalveti: Ah sorry, forgot to drop Md's custom rules; will upload a fix now
=== iahmad is now known as iahmad|afk
[09:12] <ogra_> pitti, your last systemd upload broke touch completely ... http://paste.ubuntu.com/6389687/
[09:13] <ogra_> pitti, i guess you forgot to rebuild the initrd when testing it ?
[09:13] <pitti> ogra_: fix uploaded this morning, sorry
[09:13] <pitti> I rebuilt it on my desktop, but Debian's rules work there
[09:13] <pitti> so I didn't notice at first
[09:14] <ogra_> ah, k
[09:23] <pitti> ogra_: the fix is in trusty, but I suppose we might not have a daily build after that yet
[09:23] <ogra_> we do all builds manually, since we have a no regression policy and test the images first
[09:23] <ogra_> (imagine each image is a milestone)
[09:24] <ogra_> s/is/as/
[09:25] <ogra_> pitti, did you test this on touch ? (we have a bunch of people out there with bricked phones from the weekend due to the issue, i would like to be 100% sure that we dont do that again)
[09:26] <pitti> ogra_: no, I didn't; can do it now
[09:26] <ogra_> great, thanks :)
[09:27] <ogra_> if it still boots we're fine
[09:29] <pitti> ogra_: dist-upgrade running (but ports.u.c. is slooow)
[09:35] <ogra_> pitti, oh, i would only have installed udev
[09:36] <ogra_> pitti, the rw space is very limited, dist-upgrade might make you run out of sapce
[09:36] <ogra_> *space too
[09:37] <pitti> that went well, but hicolor-icon-theme trigger failed because it can't write /usr/lib/arm-linux-gnueabihf/gdk-pixbuf-2.0/2.10.0/loaders.cache
[09:37] <ogra_> yes, rw has various issues (hardlinks dont work across the loop dev mounts)
[09:39] <pitti> ogra_: update-initramfs has a few complaints: http://paste.ubuntu.com/6398748/
[09:40] <pitti> and lxc-android-config doens't upgrade because of the hardlink issue you mentioned
[09:40] <ogra_> pitti, yeah, thats fine
[09:40] <ogra_> (sounds more fatal than it is :) )
[09:41] <pitti> ogra_: but with udev 204-5ubuntu5 it boots fine
[09:41] <ogra_> pitti, awesome, thanks !
[09:41] <pitti> (i. e. complete dist-upgrade except lxc-android-config)
[09:41]  * ogra_ will start an image build 
[09:41] <pitti> ogra_: sorry for ruining the weekend :(
[09:43] <jamespage> apw, I discussed dropping the openvswitch dkms package with the dev's upstream; there are still some experimental features still not in the kernel tree (specifically LISP overlay networking)
[09:43] <ogra_> pitti, all fine ... no worries
[09:44] <jamespage> so I'll fixup for the time being - the recommendation for openstack will be to use the GRE/VXLAN support in tree though - which makes deployment might faster \o/
[09:56] <Laney> doko__: seen http://paste.ubuntu.com/6398826/ ?
[10:06] <zyga> good morning
[10:06] <zyga> pitti, ogra_: interesting thoughts guys, thanks for sharing them
[10:07] <apw> jamespage, ack, and if they are 'experimental' we can care less about temporary breakage in that package too
[10:07] <jamespage> apw, ack
=== _salem is now known as salem_
=== freeflying is now known as freeflying_away
[11:28] <arrun> Hello and greetings to all the sir/maam here , I  wanted to ask a question for language stuffs , please help me fix those
=== slacker_1l is now known as slacker_nl
[11:36] <knocte> arrun: don't ask to ask, simply ask your question and wait
[11:37] <arrun> I wanted to add a new language having code ISO 639-3: the in the Language support , how can I do that ??
[11:44] <xnox> arrun: what language is it? to add translations to launchpad, a new language may need to be added there. For installer it should be enabled in Debian. Once there are some translations language packs can be generated for it.
[11:47] <arrun> xnox: the Language is ISO 639-3: the Chitwania Tharu , I have created the po and mo files by translating the pot in the Launchpad ...
[11:48] <arrun> xnox: I have the both po and mo files downloaded from the launchpad for the "the" Chitwania Tharu, but how can I have it installed and named it in the Language support
[11:50] <xnox> arrun: i see "the" is in launchpad already.
[11:50] <xnox> arrun: at https://translations.launchpad.net/ubuntu/saucy/+lang/the there are no translations available.
[11:51] <xnox> arrun: i guess we could generate an "empty" translation pack with no translations.
[11:51] <arrun> xnox: yup I had requested "the" to be added in Launchpad
[11:52] <arrun> xnox: I had translated the pot files, to po and mo in another sections and has already downloaded, how can I add the language packs in the Language Support ??
[11:53] <xnox> arrun: you should setup "Ubuntu Translation group" on launchpad for the Ubuntu/the, then upload translations to translations.launchpad.net/ubuntu/ and then we can generate a language pack for hte language support.
[11:54] <xnox> pitti: do you know how to enable a previously non-existant in ubuntu language for language packs et. al.? ^
[11:54] <arrun> xnox: oh, so won't I be able to create it in it  ??
[11:54] <pitti> xnox: does it have a locale already?
[11:55] <xnox> pitti: looks like it's called "the" in ISO standard, locale defined where?
[11:55] <pitti> arrun, xnox: in /usr/share/i18n/SUPPORTED
[11:55] <pitti> there's no existing locale for that ATM
[11:56] <xnox> =(
[11:56] <rsalveti> ogra_: will revert the initrd revert, as that broke the emulator
[11:57] <pitti> xnox, arrun: langpack-o-matic already knows about it, so as soon as we'll have a locale, it'll start building langpacks
[11:58] <rsalveti> pitti: and thanks for the fix :-)
[11:58] <pitti> rsalveti: no worries, sorry for breaking it; I didn't notice the regression on the desktop
[12:00] <rsalveti> pitti: yeah, I wonder why debian is shipping it's own custom rules files for storage
[12:00] <arrun> pitti: can I be able to produce the langpacks myself ??
[12:01] <pitti> rsalveti: hysterical raisins mostly, I hope Md will eventually switch to the upstream rules too
[12:01] <rsalveti> got it, cool
[12:13] <ogra_> rsalveti, ah, i was planning to do that after we could test #19
[12:14] <rsalveti> ogra_: I'm building the emulator from scratch to test it first
[12:14] <ogra_> ok
[12:14] <ogra_> i'm waiting for stgraber to enable system-image imports again
[12:20] <pitti> arrun: in principle yes, but they aren't useful without a locale
=== freeflying_away is now known as freeflying
[12:37] <fabcal> Hi all
[12:38] <fabcal> please could any of you tell me by when is the next "ClamAV" ver. 0.98 supposed to be released as an UBUNTU package?
=== MacSlow is now known as MacSlow|lunch
[12:42] <xnox> fabcal: it needs to be in debian first.
[12:42] <xnox> fabcal: then it needs to be merged, since ubuntu has modifications on top of debian.
[12:43] <ogra_> iirc in the past ScottK maintained it in both distros
[12:43] <xnox> fabcal: see http://packages.qa.debian.org/c/clamav.html
[12:43] <ogra_> (not sure thats still the case)
[12:43] <xnox> fabcal: and the ubuntu box on the right on that page.
[12:44] <fabcal> xnox, thanks alot
[12:59] <diwic> pitti, hi, is /run/* not emptied on bootup?
[12:59] <pitti> diwic: it's a tmpfs, so it starts as empty on boot
[12:59] <diwic> pitti, if you have time, there is bug 1197395
[12:59] <ubottu> bug 1197395 in pulseaudio (Ubuntu) "/run/user/$ID/pulse owned by root and not by the user" [High,Triaged] https://launchpad.net/bugs/1197395
[13:00] <diwic> pitti, people are claiming it happens after a forced shutdown
[13:01] <pitti> diwic: I also have a root:root /tmp/pulse-PKdhtXMmr18n/ directory
[13:02] <pitti> diwic: I have a suspicion that lightdm starts that somehow, but we never tracked it down
[13:03] <diwic> pitti, ok...
[13:03] <pitti> or perhaps something using pulse that you start with sudo?
[13:03] <diwic> pitti, yeah, could be
[13:04] <pitti> diwic: as you said, pulse itself doesn't even have that permission, so it's certainly related to logging int
[13:04] <pitti> in
[13:04] <pitti> or running something sudo
[13:05] <diwic> pitti, could it be apport related ...I'm thinking that if the system hard shuts down, maybe apport/whoopsie/etc will come up and try to analyze the error
[13:05] <diwic> pitti, and trying to take debug logs from PulseAudio or something
[13:08] <pitti> diwic: on crash time apport doesn't run hooks, but certainly when you click on "report"
[13:08] <diwic> pitti, also could you read https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1197395/comments/26 and see if the comment there makes sense to you or not?
[13:08] <ubottu> Ubuntu bug 1197395 in pulseaudio (Ubuntu) "/run/user/$ID/pulse owned by root and not by the user" [High,Triaged]
[13:09] <diwic> pitti, right, but are those hooks run as root or as the logged in user, or as some kind of hybrid that could cause this error perhaps?
[13:12] <pitti> diwic: as the user of the process that crashed, so usually not root for pulse
=== MacSlow|lunch is now known as MacSlow
[13:42] <ScottK> fabcal: I've almost got the package done, just a few issues to sort.
[13:48] <fabcal> ScottK, this is great, thanks alot for your information
=== greyback is now known as greyback|lunch
=== greyback|lunch is now known as greyback
=== synaptix is now known as thecowmoos
=== thecowmoos is now known as synaptix
=== jono is now known as Guest19842
[16:02] <stgraber> ogra_: sorry, didn't see the hilight up until now... enabling auto-import now
[16:02] <ogra_> stgraber, i already did :)
[16:03] <ogra_> stgraber, i only copied orig over config
[16:03] <ogra_> so remove it to your liking
[16:04] <stgraber> ogra_: ok
[16:23] <jamespage> barry, whats the conventions for managing file path conflicts between python2/python3?
[16:24] <jamespage> i.e. /usr/bin/jsonpatch is causing be problems right now :-)
[16:24] <jamespage> bug 1250088 for reference
[16:24] <ubottu> bug 1250088 in python-json-patch (Ubuntu) "python3-json-patch conflicts with python-json-patch" [Medium,Confirmed] https://launchpad.net/bugs/1250088
[16:24] <barry> jamespage: looking
[16:24] <jamespage> I was thinking /usr/bin/jsonpatch3 ?
[16:26] <barry> jamespage: debian doesn't have strong concensus on this (we hit similar issues with things like nose and other cli-providing packages), but generally we try to use X.Y versions with symlinks for X versions.  e.g. /usr/bin/jsonpatch3.3 and symlinked from /usr/bin/jsonpatch3
[16:26] <jamespage> barry, OK _ I'll hack something out and try it
[16:26] <jamespage> thanks for the help
[16:26] <barry> jamespage: +1.  np.  i'll follow up on the bug for posterity
[16:30] <barry> jamespage: my recommendation above is a little off, but watch the bug
[16:31] <jamespage> ok
=== pbn_ is now known as pbn
[16:45] <lfaraone> Ugh. Are the PPA builders in a different environment from the archive builders? I built a package for trusty locally, it FTBFS, so I tried to build it in a PPA, and it succeeded at https://launchpadlibrarian.net/156299609/buildlog_ubuntu-trusty-amd64.ogre-1.8_1.8.1%2Bdfsg-0ubuntu3_UPLOADING.txt.gz , so I assumed I just had a broken local environment.
[16:45] <lfaraone> then I upload it and am greeted with https://launchpadlibrarian.net/156332270/buildlog_ubuntu-trusty-arm64.ogre-1.8_1.8.1%2Bdfsg-0ubuntu3_FAILEDTOBUILD.txt.gz ;(
[16:49] <xnox> lfaraone: yes, all three are different (local, ppa, distro builders)
[16:50]  * lfaraone sobs softly.
[16:50] <xnox> lfaraone: your first one (PPA) doesn't have trusty-proposed enabled.
[16:50] <xnox> (which is actually where all packages are built)
[16:50] <lfaraone> Right.
[16:51] <lfaraone> oh, it BFS on i386 and amd64, its just sad on arm.
[16:51] <xnox> but from proposed only python is fethed so it can't be just that.
[16:51] <lfaraone> the current version in saucy is also FTBFS on arm64
[16:52] <lfaraone> so, not my fault at least :)
[16:54] <xnox> lfaraone: anyway why do you care about ogre-1.8 in the first place? things should be rebuild against 1.9, and 1.8 removed from the archive.
[16:54] <xnox> =)
[16:54] <lfaraone> xnox: idk, just going through the sponsor queue
[16:54] <xnox> lfaraone: ah, ok.
[16:54] <lfaraone> xnox: Laney motivated me to actually make some uploads :P
[16:55] <Laney> \o/
[16:55] <mlankhorst> lucky, I'm stuck on red tape
[16:56] <lfaraone> the queue is now at 64!
[16:56]  * lfaraone admittedly has been sort of out of it on Ubuntu development; the last time I was seriously involved was late 2011
=== salem_ is now known as _salem
=== dpm is now known as dpm-afk
=== _salem is now known as salem_
=== slomo_ is now known as slomo
[18:34] <zyga> mhall119: ping
[18:34] <zyga> mhall119: who is handling ubuntu community translations?
[18:50] <clefebvre> hi pitti, sorry for the highlight. There's a critical bug in Saucy (and most distros right now) in PAM/Systemd, I'd love to chat with you about.
[18:51] <clefebvre> I left a comment at https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1197395 to explain a little (it's not related to pulseaudio in particular)
[18:51] <ubottu> Ubuntu bug 1197395 in pulseaudio (Ubuntu) "/run/user/$ID/pulse owned by root and not by the user" [High,Triaged]
[18:54] <mhall119> zyga: pong
[18:55] <mhall119> zyga: dpm-afk is our goto guy for community translations
[18:55] <dpm-afk> hi zyga, what's up?
[18:55] <zyga> dpm-afk: hey, a community member asked me about how the translation stuff works
[18:56] <zyga> frecel: ^^
[18:56] <zyga> dpm-afk: apparently there are 5000 translations that need to be reviewed on launchpad for the polish language
[18:56] <frecel> here!
[18:56] <zyga> dpm-afk: and frecel was worried that his work is not getting used because of that
[18:57] <frecel> Well I'm just thinking that it kinda looks abandoned so I figured I could help
[18:58] <frecel> I couldn't get in touch with the administrators of Polish Translation Team btw
[18:58] <dpm-afk> zyga, I've not been in touch with the Polish translations team coordinator for a while, but I get the impression he's not very active and thus there's not much of a team atm
[18:59] <zyga> dpm-afk: is there a process where a new team can be formed if the old team is (theoretically) unreachable?
[19:03] <xnox> dpm-afk: have translations been moved to trusty series yet? from https://translations.launchpad.net/ubuntu all language links point to saucy.
[19:04] <frecel> Is there any way to check when the last suggestion was reviewed on launchpad?
=== cr3_ is now known as cr3
=== cr3 is now known as Guest17024
[19:28] <frecel> and it got quiet...
[19:28] <dpm-afk> zyga, yes, there is: https://wiki.ubuntu.com/Translations/KnowledgeBase/RoleReassignmentPolicy
=== Guest17024 is now known as cr3
[19:29] <dpm-afk> xnox, they've not been opened yet, no
[19:51] <hallyn_> ok, i installed a precise desktop from the desktop image.  installed qemu-kvm.  proposed is not in sources.list.  but the version of libvirt-bin is the one in -proposed (.15), not in -updates (.13).
[19:51] <hallyn_> haven't yet figurd out why
[20:06] <TJ-> hallyn_: "security" ?
[20:09] <TJ-> hallyn_: ahh, no... but what does "apt-cache policy  libvirt-bin" show?
=== pbn_ is now known as pbn
[20:14] <hallyn_> TJ-: WTF.  there's a /etc/apt/sources.list.d/proposed.list
[20:14] <Frodo> Hello all,
[20:14] <Frodo> I am truly intrested to join the Ubuntu community. I am a software developer and I am looking to participate in Ubuntu development. As far as i read, I should start doing junior jobs first as i am new to Linux development.
[20:14] <Frodo> I am looking for somebody to guide me what i should do to get started. And what technologies i should learn. If somebody can adobt me as a student and start assignining me homeworks until i become ready for junior jobs, i would truly appreciate it.
[20:14] <Frodo> If you do not have time to help me, at least let me know what technologies i should learn and then whom to ask about jounior task.
[20:14] <Frodo> Thanks for you help and kindness...
[20:22] <blueyed> Frodo: you might want to start here: https://wiki.ubuntu.com/UbuntuDevelopment
[20:22] <blueyed> Also, come over into #ubuntu-motu, and ask there.
[20:23] <ersi> (motu stands for "Masters of the Universe" and universe is the packaging universe ;)
[20:23] <Frodo> thnaks alot friends
[20:24] <Frodo> :)
[20:36] <melodie> hello
[20:36] <melodie> does someone know if the kernel series 3.2.0-x for Precise always be PAE free until 2017 when the support for 12.04 will be ended?
[20:45] <mdeslaur> melodie: that is the plan, yes
[20:46] <melodie> mdeslaur thanks you! If I may, could I ask when the commit for the bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1246664 will be integrated? You could have a look at my last comment
[20:46] <ubottu> Ubuntu bug 1246664 in linux (Ubuntu Precise) ""Buffer I/O error on device zram0, logical block 515067"" [Medium,Fix committed]
[20:46] <melodie> if you have any idea of course... :)
[20:47] <mdeslaur> melodie: perhaps ask in #ubuntu-kernel, I don't really know and it's off-topic for this channel
[20:47] <melodie> mdeslaur ok, I will, thank you very much!
[20:47] <mdeslaur> yw
[20:57] <dupondje> jamespage: I saw you worked on Bacula. Are there eventually plans to include Bareos as Bacula replacement?
=== doko__ is now known as doko
[21:41] <tjaalton> hrm, is the PPA build environment somehow different from a typical sbuild one? Trying to update xmlrpc-c but it fails to run the tests on LP
[21:48] <tjaalton> hmm it probably was something transient after all
[22:01] <saiarcot895> If a package uses a slightly-modified version of a third-party library, should it still have the option to use the system version of the library?
[22:05] <infinity> saiarcot895: Ideally, it really shouldn't use a modified library at all, and if they have fixed, we should get those into the shared system library.
[22:06] <infinity> saiarcot895: But if a package absolutely MUST bundle a broken fork of a library, then that seems at odds with also being able to use the system version.  You can't really have both situations.
[22:06] <saiarcot895> infinity: ok, just making sure of policy. It will be going into a PPA soon, so it's not critical at the moment, but regardless, I like to follow policy
[22:07] <saiarcot895> infinity: From what I can tell, it's just additional header files and a few defines (it's C code)
[22:08] <infinity> saiarcot895: Well, you could move the new bits into static definition in the application proper or, if they're generically good fixes/changes that all consumers of the library should want, get that into the upstream version of said library and into its packaging.
[22:09] <infinity> saiarcot895: But yeah, both policy and common sense dictates that shipping forked libraries sort of defeats the purpose of shared libraries, so do try to avoid it unless you really can't.
[22:09] <infinity> (There are many packages in the archive that ship private copies of libraries, you wouldn't be the first, it's not *forbidden*, but it's highly discouraged)
[22:10] <infinity> And the security team and others will frown heavily on such things for inclusion in main, since keeping track of embedded libraries in various packages is very painful.
[22:10] <saiarcot895> I believe chromium-browser is an exception, the reason being they keep their libraries up-to-date generally
[22:11] <infinity> They're not an exception because we think they're a good upstream, they're an exception because maintaining their massive maze of twisty awful is painful. :P
[22:12] <infinity> (Also, it's in universe)
[22:12] <saiarcot895> true
=== salem_ is now known as _salem
=== freeflying is now known as freeflying_away
[23:32] <orbisvicis> I am running into an error with dh I don't understand: "dh: Unknown sequence list-missing" with the rule "%: dh: Unknown sequence list-missing"
[23:33] <jtaylor> orbisvicis: how does the rules look like?
[23:34] <orbisvicis> oh, "%: dh --with-quilt $@"
[23:34] <jtaylor> exactly like that?
[23:34] <jtaylor> its --with quilt
[23:34] <jtaylor> without the -
[23:36] <orbisvicis> exactly like: "%:\n\tdh --with quilt $@"
[23:36] <orbisvicis> sorry about that, can't copy to the clipboard over ssh for some reason
[23:38] <jtaylor> do you have dh_install call somewhere?
[23:39] <jtaylor> because that takes the --list-missing argument
[23:39] <jtaylor> maybe its in DH_OPTIONS?
[23:44] <orbisvicis> no. it tries to run "dh --with quilt list-missing", not an "--list-missing" argument
=== freeflying_away is now known as freeflying
[23:45] <jtaylor> how are you calling the rules file?
[23:46] <orbisvicis> pdebuild -> dpkg-buildpackage -> (trying to read the output)
[23:47] <jtaylor> I don't know why it would call the rules with that argument
[23:48] <jtaylor> maybe clean your environment and grep for list-missing
[23:48] <orbisvicis> jtaylor: yes already grep'ed and not an env. variable
[23:48] <orbisvicis> ok I see: fakeroot debian/rules clean -> debian/rules build -> fakeroot debian/rules binary
[23:49] <orbisvicis> then "   dh_builddeb" as the last binary target, followed by lots of builddeb output, then "I: checking for missing files." \n "dh --with quilt list-missing" \n "dh: Unknown sequence list-missing (choose from: binary binary-arch binary-indep build clean install patch)"
[23:50] <jtaylor> maybe a broken pbuilder hook
[23:50] <orbisvicis> so I'm not sure if its part of the binary sequence, or a new target
[23:50] <orbisvicis> jtaylor: hmm good idea, let me check
[23:50] <orbisvicis> 1st time having this problem, first time using hooks....
[23:50] <jtaylor> why are you even using --with quilt and not format 3.0 (quilt)
[23:51] <jtaylor> list-missing is a cdbs rule
[23:51] <jtaylor> possibly something tries to use cdbs with a dh-7 package
[23:56] <orbisvicis> jtaylor: modification of an old package
[23:56] <orbisvicis> what do you mean, dh-7 package? such as? and how could they get mixed with cdbs
[23:57] <orbisvicis> anyway, it was one of the hooks. builds fine now