[04:59] <Noskcaj> aeoril, of course. I have limited time thisafternoon, but i'll help you as much as i can
[05:01] <aeoril> Can you look at this forum post please, Noskcaj:  http://ubuntuforums.org/showthread.php?t=2263747
[05:01] <aeoril> Noskcaj and, thanks!
[05:03] <Noskcaj> So first off, make a launchpad bug with instructions to reliably reproduce this.
[05:04] <Noskcaj> Then see if it still affects the version in vivid and git master
[05:04] <aeoril> ok, I searched in launchpad bugs for "vi resize" and found nothing similar, so I think it is safe that it is not a duplicate
[05:04] <aeoril> git master?
[05:04] <lathiat> Anyone seeing or know a bug number for getting spurious \ or \\ input when entering characters like | on vivid.. started happening a few days ago.  maybe there isn't one but having a hard time search as i'm not really sure what package that's ultimately going to be.  happens often when inputting |, if i type a character immediately after (rapidly) its more likely to occur or input even more \ characters.
[05:04] <Noskcaj> git.gnome.org/browse/gnome-terminal
[05:04] <Noskcaj> aeoril, upstream's git
[05:05] <aeoril> ok
[05:05] <Noskcaj> also maybe check bugzilla.gnome.org for the bug (upstream bugtracker)
[05:05] <aeoril> you think it might be vim, or bash?  Not gnome-terminal?
[05:06] <aeoril> or the virtual display driver or whatever, Noskcaj?  I guess I am asking why did you immediately think it was gnome-terminal?  Just from past experience?
[05:08] <Noskcaj_> aeoril: I'll look in an hour, playing dota then getting ready for some after-school stuff
[05:08] <darkxst> aeoril, you need to isolate that, if there is some other cli app that has problems then its gnome-terminal
[05:08] <darkxst> if not then its vim
[05:09] <aeoril> darkxst ok, thanks - I will try out some other stuff - can you think of something good to try that uses the screen like vim?
[05:09] <darkxst> if it is fixed in vivid or 14.10 then its a matter of finding the patch that fixed it
[05:09] <darkxst> you could try some curses apps? although don't think vim uses curses
[05:10] <aeoril> darkxst I was thinking of curses - if it is fixed in vivid or 14.10, the point of finding the patch is to backport?
[05:11] <darkxst> aeoril, yes
[05:11] <aeoril> ok
[05:11] <aeoril> what about emacs?  Is that character based, or its own gui?
[05:12] <aeoril> (I forget)
[05:14] <aeoril> oh, the man page viewer, but that might just use vim ... ???
[05:17] <aeoril> darkxst man page viewer worked fine ...
[05:27] <aeoril> darkxst nano, irssi and the man page viewer all worked fine - I will file a bug report against vim.  Thanks.
[05:31] <aeoril> Noskcaj fyi I am going to bed now (late here) - I think it is vim - will file bug report against vim tomorrow.  Thanks.
[05:37] <tumbleweed> Noskcaj: sure (re rebuilds)
[05:41] <tumbleweed> uploaded
[05:59] <Noskcaj> aeoril, ok, good to see progress
[06:00] <Noskcaj> tumbleweed, thanks. Also bug 1417257
[06:05] <tumbleweed> Noskcaj: not now, but I can look in the morning
[06:05] <Noskcaj> ty
[06:08] <pitti> Good morning
[06:11] <darkxst> hey pitti
[06:12] <darkxst> I can't reproduce that boot bug anywhere else ;(
[06:13] <pitti> darkxst: yeah, I couldn't either, although I have a good idea why it happens
[06:13] <darkxst> I may have hit a similar state with samba on my laptop, however it didn't block the boot like happens on my desktop
[06:13] <pitti> darkxst: some more things: could you attach your /etc/network/interfaces, and try to comment out eth0 so that network-manager will bring it up instead of ifupdown? does that make a difference?
[06:13] <darkxst> (i.e. lots of jobs waiting on ifup after login)
[06:13] <pitti> darkxst: I think I fixed that in -7ubuntu1
[06:14] <darkxst> pitti,  is really just:
[06:14] <darkxst> auto eth0
[06:14] <darkxst> iface eth0 inet dhcp
[06:14] <darkxst> maybe thats not needed anymore with systemd-networkd in play though?
[06:14] <pitti> darkxst: ok, I figured (and that's what I tried); I'd like to know if the hang also happens with that commented out
[06:15] <darkxst> ok will try
[06:28] <darkxst> pitti, boots fine with out /etc/network/interfaces snippet
[06:28] <pitti> darkxst: ok, interesting; thanks
[06:29] <pitti> darkxst: so then I don't understand why it doesn't start after the 2 mins of network-online.target timeout if you do use ifupdown
[06:29] <darkxst> I do see other interfaces being brought up (virtual ones) ok
[06:30] <darkxst> pitti, I don't either, but the message says 'no limit' which is presumably the timeout
[06:30] <pitti> darkxst: oh, which "the message"?
[06:30] <pitti> darkxst: I mean ifup-wait-all-auto.service has a timeout of 2 mins
[06:31] <darkxst> pitti, when it hangs it says "a start job is waiting for ifup on eth0 (<timer>/no limit)
[06:31] <darkxst> or similar to that alteast
[06:32] <pitti> hm, interesting; do you happen to know which job that is?
[06:34] <pitti> darkxst: can you boot with the debug shell and "systemd.log_level=debug", let it sit there for some 3 minutes, then do "journalctl > /root/logs" in the debug shell, reboot to a  working system, and attach /root/logs to the bug?
[06:34] <pitti> (this assumes that in the broken case you don't get any gettys or lightdm)
[06:36] <darkxst> pitti, right, when it hangs I never gets and never gets to the dm
[06:52] <darkxst> pitt added to bug 1417010
[06:52] <darkxst> ^pitti
[06:53] <pitti> darkxst: thanks! looking
[07:06] <pitti> darkxst: do you have something in /etc/network/interfaces.d/ which defines a "test" interfaces?
[07:07] <darkxst> pitti, no
[07:07] <pitti> Feb 03 17:43:46 duhast systemd[1]: ifup@test.service changed dead -> start
[07:07] <pitti> hm, so where does that come from then
[07:07] <pitti> Feb 03 17:43:46 duhast systemd[1]: sys-subsystem-net-devices-test.device changed dead -> plugged
[07:07] <pitti> Feb 03 17:43:46 duhast systemd[1]: sys-devices-virtual-net-test.device changed dead -> plugged
[07:08] <pitti> darkxst: so your "ip a" presumably has some "test" thingy?
[07:09] <darkxst> pitti, not that I can see
[07:09] <pitti> darkxst: ls -l /sys/class/net/*test* ?
[07:10] <darkxst> lrwxrwxrwx 1 root root 0 Feb  3 18:09 /sys/class/net/test -> ../../devices/virtual/net/test
[07:10] <pitti> ok; but that succeeded, so shouldn't be responsible for these woes
[07:11] <pitti> darkxst: hm, I still don't see anything in the logs which would actually wait for ifup@eth0..
[07:12] <darkxst> pitti, it was actually " A start job is running for ifup on eth0"
[07:13] <pitti> darkxst: right, and that job never finishes, I wonder why; it starts fine, but then NM seems to get in the way
[07:14] <pitti> actually no, I guess it just logs that eth0 got online
[07:15] <darkxst> I wonder if vmware runs hooks to bridge in the virtual network interfaces?
[07:16] <darkxst> though the virtual interfaces seem to come up fine
[07:16] <pitti> darkxst: oh, argh; can you please try somethign?
[07:17] <pitti> darkxst: edit /lib/systemd/system/ifup@.service to fix thsi:
[07:17] <pitti> (give me a sec)
[07:17] <pitti> Before=network.target
[07:17] <pitti> to
[07:17] <pitti> Before=network-onlnie.target
[07:17] <pitti> erk
[07:17] <pitti> Before=network-online.target
[07:18] <pitti> darkxst: this should at least fix network.target, and probably a whole slew of services which need it
[07:18] <darkxst> pitti, ok, trying now
[07:27] <darkxst> pitti, still hanging, but now there are 2 jobs trying to start for ifup@eth0
[07:28] <darkxst> and I am getting a little concerned about the races happening with gdm everytime I boot with upstart ;(
[07:28] <pitti> darkxst: there should be a lot fewer jobs be in "start waiting" now
[07:28] <pitti> (systemctl list-jobs)
[07:28] <pitti> ^ output of that appreciated
[07:28] <darkxst> I didnt check that, but it was the same message as before but with (1 of 2), (2 of 2) alternating
[07:30] <darkxst> pitti, ok, but this is the last reboot! atleast until I find the charger for my laptop
[07:30] <pitti> darkxst: argh, sorry about that; I wish I could reproduce this, would make things so much easier to debug
[07:31] <darkxst> pitti, yep always the case
[07:38] <darkxst> pitti, http://pastebin.com/HNQDUL5B 32 vs ~40 before
[07:40] <pitti> darkxst: thanks; I guess the remainder is due to init.d scripts waiting for $network, i. e. the loop that I explained in the bug
[07:42] <darkxst> pitti, right, but that doesnt bring us closer to why ifup is hanging!
[07:42] <pitti> darkxst: it's waiting for systemctl reload smbd.service (through the dhcp-enter-hoooks script)
[07:42] <pitti> darkxst: and smbd.service is in turn waiting for network-online.target as it depends on $network
[07:43] <darkxst> all my VM's boot in about 0.5sec even when I install smbd and configure shares
[07:43] <pitti> darkxst: and network-online.target is waiting for ifup@eth0.service to finish, closing the dependency loop
[07:43] <pitti> but the latter axis should be broken after 2 mins, so that timeout isn't working
[07:45] <darkxst> pitti, right, could that be hardware specific?
[07:45] <pitti> darkxst: I doubt it; I haven't fully read the samba hook yet, but apparently it behaves differently depending on the config
[07:47] <pitti> darkxst: what's interesting is that networking.service is not running for you
[07:47] <pitti> darkxst: i. e. in that regard it could be hw specific, in that eth0 isn't detected by the kernel at that time already
[07:49] <pitti> but according to your debug log it is detected before, so it ought to already block networking.service
[07:52] <pitti> darkxst: oh, I think I can funge something similar in my VM
[07:53] <pitti> darkxst: I'll try to analyze and understand that more thoroughly, but have a doctor's appointment first; I'll get back to you later (or via a bug reply if you are already off for the evening)
[08:19] <darkxst> pitti, just cooking dinner will be back later for a bit
[08:20] <dholbach> good morning
[08:21] <mvo_> pitti: good morning! could you think of a reason why we would not want http://paste.ubuntu.com/10030708/ ?  if not I will upload in a bit
[09:01] <pitti> mvo_: what will that change?
[09:02] <pitti> mvo_: i. e. would be nice to give the rationale to in the changelog and forward it to Debian
[09:04] <pitti> mvo, wgrant, infinity: wrt. apt-ftparchive clean as in http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/archivepublisher/model/ftparchive.py#L796 (which I'm trying to do in the ddeb retriever), this fails with "unable to allocate space from the buffer cache" for me
[09:04] <pitti> is there a trick to increase its cache, with env vars or config items or so?
[09:05] <wgrant> Hm, I don't remember anything special.
[09:05] <wgrant> What's the syscall that's failing?
[09:06] <mvo_> pitti: sure, I send #776905 to debian, it will make the partition labels visible when run as non-root. right now they are empty and only filled when running as root
[09:07] <pitti> mvo_: or for blkid?
[09:07] <mvo_> pitti: lsblk, I have not check blkid
[09:07] <pitti> wgrant: I haven't straced it yet; it's a berkeley db thingy, I just wanted to know whether you happened to come across that
[09:07] <mvo_> pitti: what is the exact error message for apt-ftparchive, could you pastebinit?
[09:08] <wgrant> No, we hadn't, I'm afraid.
[09:08] <mvo_> pitti: not from the top of my head either, sorry (the apt-ftparchive issue)
[09:08] <pitti> mvo_: ah ok, lsblk and sudo lsblk don't look any different here; but sure, go ahead (with mentioning that in the changelog please)
[09:08] <pitti> wgrant: ack, thanks
[09:08] <mvo_> pitti: do you have a disklabel?
[09:08] <mvo_> pitti: you might create one first using e2label to see a difference :)
[09:09] <pitti> mvo_: ah heh, I guess I don't; the installer doesn't seem to create one
[09:09] <pitti> mvo_: btrfs here :)
[09:10] <mvo_> :)
[09:10] <pitti> mvo_: error message> running again (takes a while)
[09:10] <mvo_> ok
[09:13] <pitti> mvo_: tried in a VM, still no diff between user and sudo; so lsblk might just always need that?
[09:14] <pitti> mvo_: (sudo blkid shows it fine)
[09:15] <mvo_> pitti: oh? strange, for me it was no label without libudev-dev b-d and label with it
[09:15] <pitti> mvo_: right, my point; I was saying that user vs. root makes no difference
[09:18] <mvo_> pitti: always need libudev-dev you mean ? could be I did not dig very deep. I wonder if its a issue in debian with non-linux arches(?)
[09:20] <pitti> mvo_: for sure, but you can mark it as [linux-any]
[09:20] <pitti> mvo_: non-linux arches just won't get that feature then *shrug* (not a regression)
[09:20]  * mvo_ nods
[09:27] <xnox> morning. So cold here.... we even had slow
[09:27] <xnox> *snow
[09:28] <pitti> hey xnox ; here too, -8 degrees, *brrr*
[09:28] <Unit193> -18C here. :P
[09:30] <seb128> mlankhorst, hey, is your ppa for xmir supposed to work on current vivid amd64? it wants to uninstall the drivers because abi mismatch here
[09:31] <pitti> Unit193: double-brr
[09:37] <ogra_> pitti, line 404 ff ... how do i find out more about that failure in the systemd world (i guess there is a way to get finer grained info from a job ?) http://paste.ubuntu.com/10031420/
[09:37] <mlankhorst> seb128: add the x-staging ppa
[09:38] <seb128> mlankhorst, not sure I want to go off vivid by so much
[09:38] <mlankhorst> The x-staging ppa only has rebuilds against the new abi
[09:39] <pitti> ogra_: .device units are really just representations of the actual udev devices, so I don't think there's much further logging
[09:39] <pitti> ogra_: in general, "sudo systemctl status -l unitname" gives you the most useful things, like the current status and the last few lines of journal output that belogns to that unit
[09:40] <pitti> ogra_: in this concrete case it looks like mmcblk0p1 was requested through /etc/fstab, but the device never actually appears
[09:40] <ogra_> pitti, right, which i guess is just the same i already have there ... just filtered
[09:40] <ogra_> pitti, heh, exactly ...
[09:40] <pitti> ogra_: and if you look at the kernel messages, it only sees 0p4 and 0p2
[09:40] <ogra_> which is weird
[09:41] <ogra_> this is a normal snappy install (well, should be at least, not sure how teh user built it )
[09:41] <pitti> ogra_: on that device, looking at parted and sudo blkid might be insightful
[09:41] <ogra_> we did already :)
[09:41] <pitti> i. e. perhaps there just aren't any partitions like that
[09:41] <ogra_> well, with blkid
[09:41] <ogra_> it seems to be all fine
[09:42] <pitti> ogra_: hm, missing fs driver in the kernel then? what did blkid say?
[09:42] <pitti> ogra_: I take it there really is no /dev/mmcblk0p1? if there is, then we indeed have a bug in systemd
[09:42] <ogra_> vfat (as it should ...) and labelled "system-boot" (as it should)
[09:42] <ogra_> the device exists in a booted system and can manually be mounted
[09:43] <ogra_> we use "auto" in fstab ... i was wondering if it has to do with that
[09:43] <ogra_> (btw, you dont seem to be in #snappy :) )
[09:44] <pitti> ogra_: argh, bip restart last Friday, sorry :) I am now
[09:44] <ogra_> heh
[09:52] <LocutusOfBorg1> sil2100, I uploaded the new lucene++ on debian and syncd in ubuntu, hope is ok for you :)
[09:52] <LocutusOfBorg1> also put in collab-maint shared git repository
[10:31] <pitti> darkxst: I posted a possible solution to bug 1417010
[10:36] <darkxst> pitti, will look tomorrow, its late now
[10:37] <darkxst> but thanks for investigating
[10:37] <pitti> darkxst: ack, thansk
[11:00] <LocutusOfBorg1> dholbach, poedit is sync'd from debian/experimental, I updated it on experimental again, will it be sync'd automatically?
[11:00] <dholbach> no
[11:01] <LocutusOfBorg1> thanks :)
[11:01] <LocutusOfBorg1> can you please sync again :p
[11:01] <dholbach> do you need it synced?
[11:01] <LocutusOfBorg1> :)
[11:01] <dholbach> sure
[11:01] <dholbach> let me take a look - no need to file a bug
[11:01] <LocutusOfBorg1> the 1.7.4 is a little bug fix release, mostly for macosx, but something is linux related
[11:02] <LocutusOfBorg1> thanks, much appreciated!
[11:02] <LocutusOfBorg1> I hope debian will be released soon, so I'll start again uploading in unstable :p
[11:03] <dholbach> :)
[11:08] <LocutusOfBorg1> thanks!
[11:48] <doko> Riddell, ScottK: which of the cantor, kio, marble autopkg tests can be ignored?
[11:49] <doko> pitti, ^^^
[11:49] <Riddell> doko: all of them, upstream doesn't mind that they fail
[11:49] <pitti> doko: for gcc probably all of them
[11:49] <doko> pitti, ok, and how much do we care about mysql-5.5?
[11:50] <doko> ugh, still in main, and 5.6 still in universe
[11:54] <pitti> doko: probably not at all, AFAIK it's slated for removal
[11:55] <doko> pitti, can you override these?
[11:57] <cjwatson> Might be a good idea to check that one with the server team.
[11:57] <cjwatson> I vaguely recall it not being quite trivial.
[11:59] <rbasak> I've been working on mysql for the last few weeks.
[11:59] <rbasak> I should have an upload soon. Then we can lose 5.5.
[11:59] <doko> rbasak, 5.5, or 5.6?
[11:59] <pitti> doko: yep, will do in a bit (still drowning on IRC)
[11:59] <rbasak> doko: the upload will be for 5.6. So we can then remove 5.5, and put 5.6 in main.
[11:59] <rbasak> (both are currently in the archive)
[12:25] <rsalveti> pitti: just noticed we still got whoopsie crashing in loop (desktop and touch), we need to fix this at some point
[12:25] <rsalveti> no crashing, just the upstart job failing to start because of the lock file
[12:33] <mdeslaur> @pilot in
[12:47] <medicalwei> Hello
[12:48] <medicalwei> I'd like to fix a bug in a package in Ubuntu, I am wondering what's the routine if the bug is fixed in Debian.
[12:48] <medicalwei> Do Ubuntu have a sponsored upload like which in Debian?
[12:49] <highvoltage> medicalwei: http://packaging.ubuntu.com/html/fixing-a-bug.html
[12:49] <highvoltage> medicalwei: you might want to join #ubuntu-packaging and #ubuntu-motu for packaging related questions
[12:50] <highvoltage> medicalwei: (but yes, you can request a sponsor for your upload)
[12:50] <medicalwei> highvoltage, Thanks :)
[12:52] <rbasak> medicalwei: https://wiki.ubuntu.com/SponsorshipProcess might also be relevant for you.
[12:53] <medicalwei> Okay. My case is that the bug is fixed in the packaging git repo (Alioth) in Debian, but the maintainer says he won't upload since Debian jessie is frozen.
[12:53] <rbasak> That's fine. Just point that out in your sponsorship request.
[12:54] <rbasak> The sponsor can take that into account.
[13:05] <xnox> didrocks: yo, didier. I think i got preset-transient to work correctly.
[13:06] <xnox> my initial patch from hackfest is very very buggy.
[13:06] <didrocks> xnox: nice! I'm still working on the fsck thing
[13:07] <xnox> there are many places where it is assumed that "!UNIT_FILE_SYSTEM" means user mode. Thus adding a new system-level scope is hard.
[13:07]  * xnox ponders if we should talk on #systemd, but meh
[13:07] <didrocks> ah ok
[13:07] <didrocks> yeah, making sense
[13:07] <didrocks> I need still to send that email (probably tomorrow) summarizing the solution we decided on
[13:07] <xnox> didrocks: so i have a better patch, which adds a new option (as a /proc/cmdline, --arg, config file setting)
[13:07] <didrocks> but the fsck thing got all my time
[13:08] <didrocks> what do you mean about the option?
[13:08] <xnox> didrocks: well, keep working on the fsck thing for now. I'll test my updated patch again and will send you that for re-review.
[13:08] <didrocks> xnox: great!
[13:08] <xnox> didrocks: one has to opt-into transient presets explicitely.
[13:09] <xnox> and i'm now pondering, if we even need separete /lib/systemd/system-preset-transient in that case.
[13:09] <didrocks> hum… didn't we say that we would only do this if there were some presets?
[13:09] <didrocks> like, if the dir exists and there are some presets in it
[13:09] <xnox> as the policy is the same, whether or not it's transient or normal preset.
[13:09] <xnox> looking at the code checking whether or not there are any presets is fragileish =)
[13:10] <xnox> (as one needs to stat a lot of dirs)
[13:10] <didrocks> hum, not sure that upstream would like that though
[13:10] <xnox> with normal preset the flag file is /etc/machine-id
[13:10] <xnox> in transient-preset case it's a runtime option.
[13:10] <xnox> imho applying normal presets should also be a runtime option.
[13:11] <didrocks> I guess we discussed the case where some people would want a default distro + a first setup?
[13:11] <xnox> cause e.g. in debian case we wouldn't want to enable / apply normal presets by default (when machine-id is missing)
[13:11] <xnox> making it a first-class option makes it easier for distro-system-user-admin configuration
[13:12] <xnox> just like --show-status --dump-core --log-level etc.
[13:12] <didrocks> but I think that on some setups, they sys admin of the domain would want a first-time setup
[13:12] <xnox> anyway, let me test this more and send you the updated patch
[13:12] <didrocks> ok
[13:12] <didrocks> xnox: enjoy :)
[13:19] <pitti> doko_: ok, gcc unstuck; also some of python-defaults, I'll have a closer look after lunch
[15:04] <xnox> didrocks: i think i'm happy now. performance is bad if one has a lot of units without any "Install" sections....
[15:04] <xnox> which systemd seems to ship quite a few....
[15:05] <xnox> adding a massive "disable *" helps.
[15:06] <xnox> or well shipping "disable basic.target" "disable emergency.target" et.c
[15:06] <xnox> overall it's then just a small penalty.
[15:09] <lfrlucas> Hi. I would like to know if this bug will be fixed on Ubuntu 14.04 using KDE (kubuntu): https://bugs.kde.org/show_bug.cgi?id=271934
[15:10] <lfrlucas> This is a memory leak related with policykit package. It was already solved on upstream...
[15:11] <lfrlucas> Every time we make ssh kdeinit4 memory grows.
[15:12] <brendand_> does anyone know why bzr push and pull are hanging so frequently these days? is it just me?
[15:12] <lfrlucas> We are using Ubuntu server 14.04 and kde desktops in our university lab. Since we do a lot of ssh, this bug is quite severe for us. I would like to know if it would be solved, or if you have any workaround. Otherwise the only solution for us seems to migrate to opensuse, which already fixed this bug
[15:12] <rbasak> lfrlucas: is there a bug in Launchpad tracking this?
[15:14] <rbasak> lfrlucas: also, #kubuntu or #kubuntu-devel might be more relevant channels with people more likely to know the answer there.
[15:14] <xnox> didrocks: if you want to try that preset patch on ubuntu, make sure you at least copy the 90-systemd.preset file into system-preset-transient dir.... otherwise you will boot to shutdown.target.
[15:14] <rbasak> But generally, bugs that don't get reported are unlikely to get fixed.
[15:14] <didrocks> xnox: will probably try tomorrow
[15:14] <didrocks> xnox: want to concentrate/finish/polish
[15:14] <xnox> didrocks: and given how all of this works, i'm siding to actually have "disable *" policy now
[15:14] <xnox> didrocks: on the fsck, yeah. please =)
[15:15] <didrocks> ;)
[15:15] <lfrlucas> rbasak: Only found this bug reported on  https://bugs.kde.org/show_bug.cgi?id=271934, but this is not kde related. I discussed on #kubuntu-devel  and the problem is on  policykit-1 http://packages.ubuntu.com/trusty/policykit-1
[15:15] <xnox> didrocks: once your done i'll steal your fsck stuff for stuff in debian probably.
[15:15] <lfrlucas> rbasak: So, I guess only ubuntu team can fix this bug
[15:15] <didrocks> xnox: be my guest :)
[15:16] <didrocks> xnox: I'm rewritting it to use epoll, almost done, but there is still this libplymouth thingy
[15:16] <lfrlucas> I guess the soution si simply to update policykit-1
[15:18] <rbasak> lfrlucas: well, a first step is to have a good quality bug report in Launchpad that you can point to.
[15:18] <lfrlucas> I would expect to see this bug fixed. But several weeks passed and nothing.  I don't understand how an LTS version can exist with a leak like this. Every time we make ssh used memory grows 2-3 mb. We lots of scripts making ssh, and dektop machines get memory full in few days
[15:19] <rbasak> lfrlucas: I would expect nothing without a bug report in Launchpad.
[15:19] <rbasak> lfrlucas: if this is of particular impact to Kubuntu users, the Kubuntu team might be interested in fixing the issue.
[15:20] <lfrlucas> rbasak: How can I open a bug report. I don't find any place on website to open new bug
[15:21] <rbasak> lfrlucas: https://help.ubuntu.com/community/ReportingBugs
[15:23] <lfrlucas> rbasak: I read that page. I continue without understanding how to open new bug report
[15:23] <rbasak> lfrlucas: try #ubuntu for help on this.
[15:23] <rbasak> lfrlucas: or #kubuntu, if it really affects KDE users particularly.
[15:26] <dupondje> cyphermox: lets hope you can fix the NetworkManager crashes :)
[15:27] <cyphermox> dupondje: not a problem, I just pushed it to a PPA to try it out
[15:28] <lfrlucas> rbasak: This affects kubuntu and ubuntu. We have 15 machines running ubuntu-server and kubuntu. If we don't solve this, we have to migrate all machines to another distro, including ubuntu-server, we should use the same basis distro in all machines.
[15:29] <lfrlucas> rbasak: THe problem is identified and fixed upstream. It is on policykit package. I'm trying to open bug but I don''t find
[15:30] <rbasak> lfrlucas: I use Ubuntu server constantly, as do many others. Are you sure you aren't doing something special that results in your leak, that doesn't affect others?
[15:31] <lfrlucas> rbasak: The leak is only visible in ubuntu machines using kde. But I just saying, that this should be of interest of ubuntu guys to. Because we can not keep ubuntu-server machines with leaked kubuntu machines.
[15:32] <rbasak> lfrlucas: OK, you're probably best off asking in #kubuntu to help get the bug filed then.
[15:32] <cjwatson> Run "ubuntu-bug policykit-1"; that should walk you through reporting a bug against that.
[15:33] <lfrlucas> tarpman: On kubuntu apps,  the bug report only points to kde.bugs
[15:33] <lfrlucas> cjwatson: Thanks!
[15:47] <doko> I hate arm64 ... both gcc-4.9 and gcc-5 are unable to build gcc-5
[15:52] <lfrlucas> rbasak: Here it is https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1417637
[15:52] <xnox> doko: It's ok, it hates you to. bootstrapping toolchain - who cares about that =)
[15:54] <xnox> lfrlucas: well the patch at https://bugs.freedesktop.org/attachment.cgi?id=112087 looks trivial.
[15:54] <lfrlucas> rbasak: We already have solution. I hope ubuntu team can solve this bug quickly! Otherwise we cannot continue using ubuntu like this...
[15:54] <xnox> lfrlucas: did you try rebuilding policykit package with that patch to see if it solves the problem for you?
[15:54] <xnox> if it does doing an SRU for this one-liner is trivial.
[15:54] <lfrlucas> xnox: Noo, I have no experience rebuild system packages on ubuntu
[15:55] <lfrlucas> xnox: But I would like to help on that
[15:55] <xnox> lfrlucas: do you know how to use "diff" and "patch" utilities?
[15:55] <lfrlucas> ya
[15:58] <lfrlucas> xnox: The problem should be to gennerate deb.. And what source code ubuntu uses for policykit-1 ?
[15:59] <AkivaAvraham> Hey all: Live Ask Ubuntu Anything live in 5 minutes: http://ubuntuonair.com | #ubuntu-on-air
[15:59] <xnox> lfrlucas: https://help.ubuntu.com/community/UpdatingADeb
[16:00] <xnox> lfrlucas: follow that, policykit-1 is the package name, patch is at http://cgit.freedesktop.org/polkit/patch/?id=f4d71e0de885010494b8b0b8d62ca910011d7544
[16:15] <mdeslaur> @pilot out
[16:18] <lfrlucas> xnox: Could you help here? http://pastebin.com/JCarGuH2
[16:24] <lfrlucas> Anyone could help here?  http://pastebin.com/JCarGuH2
[16:28] <rbasak> lfrlucas: your version number for an update to Trusty needs to be 0.105-4ubuntu2.14.04.1. Get rid of the "patched" thing, it's messing it up.
[16:29] <lfrlucas> rbasak: I'm testing the patch that solves the bug of policykit. How to test the patch?
[16:29] <lfrlucas> rbasak: xnox pointed me to  https://help.ubuntu.com/community/UpdatingADeb
[16:34] <lfrlucas> xnox, rbasak: I used dpkg-buildpackage -b and run debi.
[16:34] <lfrlucas> xnox, rbasak: I can confirm that the patch in http://cgit.freedesktop.org/polkit/patch/?id=f4d71e0de885010494b8b0b8d62ca910011d7544 solves the bug in https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1417637
[16:35] <lfrlucas> Kdeinit4 does not grow anymore in this machine were I installed patched policykit
[16:35] <xnox> lfrlucas: well comment on the bug report. For faster SRU times it's best to document how to observe the bug, and how to observe that it is gone after policykit is upgrade with such a patch.
[16:36] <lfrlucas> *where
[16:36] <lfrlucas> just looking memory usage in htop
[16:36] <xnox> lfrlucas: e.g. i run this commend to check memory usage of foo, ssh in, check again it grows, but now it stays constant.
[16:37] <xnox> lfrlucas: well on irc we know that =) random people reading and/or processing that stable release upgrade will only see what's in the bug report =)
[16:41] <lfrlucas> xnox: I guess I made what you asked...
[16:42] <lfrlucas> xnox: Now, should we wait for someone to fix this?
[16:43] <xnox> lfrlucas: if you can prepare a debdiff - that is the diff of all packaging before and after the patch is applied with the right version number targetting vivid that would be first step.
[16:43] <xnox> if you have the new .dsc that you just compiled: $ debdiff old.dsc new.dsc
[16:43] <xnox> should produce that.
[16:44] <lfrlucas> vivid? and trusty?
[16:44] <xnox> (not version number for vivid would be e.g. 0.1-2ubuntu3, where the last digit is one higher than last one, or some such)
[16:44] <xnox> then attaching such a debdiff and subscribing sponsor would seal the deal for now.
[16:44] <xnox> lfrlucas: once the patch is in vivid, debdiffs for utopic & trusty can be created and uploaded.
[16:45] <lfrlucas> I made the patch on trusty....
[16:45] <xnox> lfrlucas: bug affects current development series (15.04) and needs to be fixed there first.
[16:45] <xnox> as well as stable series.
[16:45] <xnox> lfrlucas: attach that, it's already some work done - for trusty upload.
[16:46] <xnox> you can do pull-lp-source policykit-1 vivid
[16:46] <lfrlucas> xnox: What about version numbering? I didn't change anything
[16:46] <xnox> to get the vivid's current .dsc & well utopics, and rince & repeat.
[16:46] <xnox> $ dch -i
[16:46] <xnox> should do the right thing, it will increment the version number and open the debian/changelog to fill in details.
[16:47] <xnox> Fix memory leak in foobar (LP: #bugnumber)
[16:47] <xnox> is all that's needed there.
[16:47] <lfrlucas> It shows vim with this first line: policykit-1 (0.105-4ubuntu3) UNRELEASED; urgency=medium
[16:47] <lfrlucas> xnox: should I change anything
[16:47] <xnox> i need to go, but hopefully somebody can help you.
[16:47] <xnox> let me point you at documentation
[16:48] <xnox> lfrlucas: http://packaging.ubuntu.com/html/fixing-a-bug.html#documenting-the-fix
[16:48] <lfrlucas> xnox: thanks
[16:48] <xnox> the guide uses bzr as well... but that bit is optional.
[16:49] <xnox> you can do $ debuild -S to get new dsc, and then generate debdiff with $ debdiff trusty-current.dsc your-new.dsc
[16:49] <xnox> once attached to the bug report subscribe "~ubuntu-sponsors" team =)
[17:04] <lfrlucas> xnox: debuild -S doesn't work for me. But dpkg-buildpackage -b works
[17:05] <lfrlucas> dpkg-source: error: cannot represent change to src/polkitagent/PolkitAgent-1.0.typelib: binary file contents changed
[17:05] <lfrlucas> dpkg-source: error: add src/polkitagent/PolkitAgent-1.0.typelib in debian/source/include-binaries if you want to store the modified binary in the Debian tar-ball
[17:05] <xnox> lfrlucas: typically the patch should be stored in debian/patches directory
[17:05] <lfrlucas> hmmm
[17:05] <xnox> and added to the debian/patches/series file
[17:06] <xnox> lfrlucas: binary contents changed - run $ ./debian/rules clean
[17:06] <xnox> lfrlucas: if that does not help, remove the binary files that are changed. E.g. rm src/polkitagent/PolkitAgent-1.0.typelib should do the trick
[17:06] <xnox> (it's a way to specify "i did not change this" and "please use copy from upstream tarball")
[17:06] <lfrlucas> xnox: What description should I use for patch. Bugfix?
[17:07] <xnox> fixes a memory leak when this and that happens (LP: #bugnumber)
[17:07] <lfrlucas> And patch name?
[17:07] <xnox> lfrlucas: re-use / get insparation from the the git patch commit message
[17:07] <lfrlucas> ok
[17:08] <xnox> lfrlucas: it's free-form text, see previous changelog entries for style / feel as to how to write them.
[17:08] <lfrlucas> Most patches have number, like this: 01_pam_polkit.patch
[17:09] <lfrlucas> Is it required?
[17:09] <lfrlucas> kdeleak_fix.patch?
[17:24] <lfrlucas> gpg: /tmp/debsign.bKOjVp0a/policykit-1_0.105-4ubuntu3.dsc: clearsign failed: secret key not available
[17:24] <lfrlucas> debsign: gpg error occurred!  Aborting....
[17:24] <lfrlucas> Any help?
[17:27] <cjwatson> lfrlucas: You can ignore that if you aren't planning to upload the source package itself to an archive.
[17:27] <lfrlucas> cjwatson: But debuild -S fails...
[17:27] <lfrlucas> debsign: gpg error occurred!  Aborting....
[17:27] <lfrlucas> debuild: fatal error at line 1283:
[17:28] <lfrlucas> I want to fix bug  https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1417637
[17:30] <rbasak> lfrlucas: call debuild with -us -uc also. That'll tell it not to sign.
[17:32] <lfrlucas> rbasak: thanks
[17:32] <cjwatson> lfrlucas: It only fails right at the end, and it has in fact successfully generated a source package.  And as rbasak says.
[17:35] <lfrlucas> cjwatson: I already have debdiff output. How should I update launchpad?
[17:36] <lfrlucas> Here it is : http://pastebin.com/E2yGwp4n
[17:37] <cjwatson> Save the debdiff to a file and attach it to the bug.
[17:37] <cjwatson> Not a pastebin link, because pastebins can expire.
[17:37] <lfrlucas> ok, thanks
[17:37] <lfrlucas> Can I call debdiff ?
[17:37] <lfrlucas> name it debdiff
[17:37] <cjwatson> Why not?
[17:37] <lfrlucas> ok
[17:37] <cjwatson> It hardly matters.
[17:38] <lfrlucas> This is my first time doing this
[17:41] <alexbligh1> hi rbasak - don't suppose you've made any progress with the backport to T of https://bugs.launchpad.net/ubuntu/trusty/+source/apache2/+bug/1366174 ?
[17:45] <lfrlucas> cjwatson, xnox, rbasak: Debdiff is uploaded: https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/1417637
[17:45] <lfrlucas> What will happen then?
[17:46] <xnox> lfrlucas: looks good. By large it is correct, and should be easy enough to be tweaked to upload into each of the required series where the fix is needed.
[17:47] <cjwatson> It's on the sponsorship queue, so it'll get looked at in time
[17:47] <cjwatson> http://reqorts.qa.ubuntu.com/reports/sponsoring/ - well, it'll get there in a moment
[17:49] <xnox> lfrlucas: thank you for contributing to ubuntu development.
[18:06] <lfrlucas> Thank you all. We have about 7 kubuntu machines and 7 ubuntu-server machines in your university research lab. I hope to see this bug fixed ...
[18:17] <lfrlucas> What's sponsor team ?
[18:32] <lfrlucas> Is it possible to remove packages installed by apt-get build-dep policykit-1 ?
[18:35] <sarnold> lfrlucas: best is if you still have that list of packages in scrollback and can apt-get purge them all with copy-and-paste :)
[18:35] <sarnold> lfrlucas: /var/log/dpkg.log is there in case you don't have it in scrollback any longer
[18:35] <lfrlucas> sarnold: thanks
[18:35] <sarnold> lfrlucas: ... and it'd be best to use sbuild in the future to avoid the issue :)
[18:45] <lfrlucas> sarnold: To replace the patched  policykit-1 which I installed using debi, with the original repository version, the apt-get install policykit-1 command should be enough?
[18:46] <sarnold> lfrlucas: unlikely, that one might be difficult to easily fix
[18:49] <lfrlucas> sarnold: At leas it installed policykit-1-0.105-4ubuntu2 over my version policykit-1-0.105-4ubuntu3 which I generated before.
[18:50] <sarnold> lfrlucas: ah, nice
[19:02] <dobey> you can specify an exact version with apt-get install, and you can --reinstall as well
[19:03] <sarnold> dobey: ooo. nice on both counts. :)
[19:04] <dobey> apt-get install policykit-1=0.105-4ubuntu2 for example
[19:05] <lfrlucas> dobey: It will replace an higher version without problem, even if the installed files are different? In my case, the file files should be the same
[19:05] <cjwatson> Yes
[19:05] <lfrlucas> hmm nice
[19:07] <lfrlucas> cjwatson: xnox told me before to subscribe to sponsors-team after upload debdiff. Is that required? What is that intended for?
[19:07] <cjwatson> it's already done
[19:08] <cjwatson> and it causes the bug to end up on the sponsorship queue, which I linked to above
[19:08] <lfrlucas> So you guys made it for me?
[19:08] <cjwatson> Somebody did, I don't know who
[19:09] <lfrlucas> nice, thanks
[19:09] <cjwatson> I had been about to do it for you and noticed that somebody already had
[19:09] <lfrlucas> I think it was xnox
[19:20] <asac> doko: slangasek: https://bugs.launchpad.net/ubuntu/+source/gcc-4.9/+bug/1417664
[20:04] <Noskcaj> What would be causing https://launchpadlibrarian.net/196501062/buildlog_ubuntu-vivid-amd64.sagan_1.0.0~RC4-0ubuntu1~vivid1_FAILEDTOBUILD.txt.gz to not build? It says it can't make executables
[20:15] <cjwatson> Noskcaj: I think "/usr/bin/ld: cannot find -lee" may be the real error message there, so pehaps just a missing build-dep
[20:15] <cjwatson> *perhaps
[20:16] <Noskcaj> thanks, i'd forgot that was needed as well (it was listed in the FTBFS bug report somewhere)
[20:48] <flexiondotorg> cyphermox, https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-meta
[20:59] <cyphermox> flexiondotorg: cool, so I think we should start with reviewing the packages that are still only in ubuntu-mate-dev PPA and get them to the archive, and finish with the meta-package
[20:59] <flexiondotorg> Agreed.
[21:00] <cyphermox> let's start with fun stuff, yoga-gtk-theme maybe? :)
[21:02] <flexiondotorg> cyphermox, https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/yuyo-gtk-theme
[21:03] <cyphermox> oh, yuyo, not yoga