=== anthonyf is now known as Guest23073
[04:56] <Mirv> doko: ack, I asked mandel to look at the bug, he probably knows what it's about then
[05:03] <linuxuz3r> just wanna say hi
[05:03] <linuxuz3r> im a noob
[05:24] <pitti> Good morning
[05:30] <Unit193> Howdy, pitti.
=== anthonyf is now known as Guest46780
=== anthonyf is now known as Guest47313
[09:12] <doko> infinity, subscribed glibc to https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1248642
[09:12] <ubottu> Ubuntu bug 1248642 in nvidia-graphics-drivers-331 (Ubuntu Trusty) "dynamic library inconsistencies with OpenGL/C++" [Undecided,Confirmed]
=== Malsasa_ is now known as Malsasa
[11:05] <caribou> merge question : rsyslog installs an "upstart only" job (saving dmesg on boot) in the vivid version
[11:05] <caribou> should I migrate it to systemd ?
=== _salem is now known as salem_
[11:48] <caribou> on the same topic, should I also migrate the upstart job to systemd ? upstream debian  hasn't done the systemd bits yet
=== MacSlow is now known as MacSlow|lunch
[11:58] <rbasak> caribou: does that mean that Vivid with systemd regresses the saving dmesg on boot functionality?
[11:59] <rbasak> caribou: AIUI, yes we should fix that in systemd.
[11:59] <rbasak> pitti: ^^
[11:59] <caribou> rbasak: I would think so
[11:59] <rbasak> I wonder if we should SRU a fix for that to VIvid.
[11:59] <caribou> rbasak: FYI I went ahead & created an rsyslog-dmesg.service
[11:59] <rbasak> Saving dmesg on boot is useful.
[11:59] <caribou> rbasak: I can create the bug & SRU once the merge is done
[12:00] <rbasak> Users will only discover it not there when they debug and can't find it.
[12:00] <rbasak> caribou: thanks!
[12:00] <caribou> rbasak: how about migrating the upstart script to systemd ?
[12:00] <rbasak> caribou: the regular rsyslog job?
[12:01] <caribou> well, upstream only has an init job but we do provide an upstart job merged in
[12:01] <rbasak> Then the init.d job is fine unless losing the upstart job regresses some functionality
[12:01] <caribou> rbasak: the upstart job is now obsolete so it means relying on upstream init script
[12:02] <caribou> rbasak: I'll check it out
[12:02] <rbasak> Obsolete for Ubuntu, yes. Debian could use it for Debian users using upstart though
[12:04] <caribou> rbasak: ok got bug #1464227
[12:04] <ubottu> bug 1464227 in rsyslog (Ubuntu) "kernel messages are not saved when rsyslog is started" [High,In progress] https://launchpad.net/bugs/1464227
[12:05] <caribou> rbasak: don't think it is in the debian package
[12:23] <pitti> caribou: it's all in the journal, isn't it?
[12:27] <rbasak> Hmm. I suppose if systemd provides equivalent functionality then we don't need it? (Does it?)
[12:30] <mdeslaur> pitti: the journal isn't enabled by default though, no?
[12:31]  * mdeslaur doesn't have a /var/log/journal directory
[12:31] <pitti> mdeslaur: journal is (in /run), just not persistant journal in /var
[12:32] <pitti> but rsyslog also captures kernel messages
[12:32] <mdeslaur> hrm, I don't have anything in /run/systemd/journal either
[12:32] <mdeslaur> I guess it's in ram
[12:32] <pitti> mdeslaur: it is in /run/systemd/journal
[12:32] <pitti> mdeslaur: "sudo journalctl -b" -> does that work?
[12:33] <mdeslaur> yeah, that works
[12:33] <rbasak> wfm
[12:33] <mdeslaur> it's cached in ram
[12:33] <rbasak> Will that retain "dmesg on boot" indefinitely or will it roll over eventually?
[12:34] <rbasak> "systemd-journal[318]: Runtime journal is using 8.0M (max allowed 77.8M..."
[12:34] <rbasak> The usefulness of /var/log/dmesg is that once dmesg wraps it's still available.
[12:34] <pitti> rbasak: nothing is kept indefinitely :) (logrotate etc.)
[12:34] <rbasak> If systemd can still wrap, I think it'd still be useful to have /var/log/dmesg.
[12:35] <mdeslaur> I do seem to have my dmesg stuff in /var/log/kern.log
[12:35] <pitti> yes, journal will wrap eventually, depending on the amount of RAM (or disk, if you use persistancy)
[12:35] <pitti> mdeslaur: yes, that too
[12:35] <pitti> we cleaned up some of rsyslog's duplication a while ago, but there's still plenty
[12:36] <pitti> and as long as we install rsyslog I don't want to enable persistant journal by default
[12:36] <pitti> we already hit/wake up the disk enough as it is
[12:36] <mdeslaur> nah, no sense logging twice
[12:36] <mdeslaur> and dmesg is in kern.log
[12:36] <mdeslaur> so I don't see why a separate /var/log/dmesg is required
[12:37] <pitti> yes, me neither; that's why I never bothered to port it, it's just the fourth duplicate
[12:37] <rbasak> pitti: /var/log/dmesg was previously kept at least until next boot
[12:37] <rbasak> mdeslaur, pitti: kern.log eventually rotates round within the same long-lived boot
[12:37] <rbasak> Nevertheless it's useful to see what the kernel said on boot without having to reboot
[12:38] <rbasak> That's where /var/log/dmesg comes in.
[12:38] <ogra_> there was an upstart job that just echoed dmesg into that file right after boot ... /var/log/dmesg is really really helpful
[12:38] <mdeslaur> rbasak: oh, I see, hrm
[12:38] <pitti> well, lots of things are "really really helpful"
[12:38]  * ogra_ is fully with rbasak here and would like to have it back
[12:38] <pitti> but writing everything four times isn't
[12:38] <rbasak> It's only small and is only written once on boot
[12:38] <ogra_> well, dmesg eventually scrolls away
[12:38] <rbasak> /var/log/dmesg doesn't get written or grow at any other time.
[12:38] <ogra_> and there is no other log that has this info
[12:38] <pitti> syslog is kept for a fair while
[12:39] <pitti> ogra_: sure, /var/log/syslog, /var/log/kern.log, and the journal
[12:39] <ogra_> syslo doesnt have these messages
[12:39] <ogra_> and kern.log starts later as well
[12:39]  * ogra_ buys a new g key
[12:39] <rbasak> /var/log/dmesg is useful after a server has been running a really long time. After all logs have rotated away.
[12:39] <ogra_> not only a server :)
[12:39] <rbasak> :)
[12:40] <pitti> rbasak: how is it more useful than, e. g. knowing what postfix did 233 days ago?
[12:40] <rbasak> pitti: it's the kernel messages on boot that are useful.
[12:40] <ogra_> right
[12:40] <pitti> I mean, I do appreaciate log files, but it's always a trade-off between wakeups, disk space, and retaining information
[12:40] <rbasak> pitti: since they are still relevant to the running system and aren't necessarily historical.
[12:40] <pitti> and right now we rather have too much duplication still
[12:40] <rbasak> No wakeups for /var/log/dmesg
[12:41] <rbasak> Mine is 89K.
[12:41] <ogra_> it is the one place where you have proper boot messages and its tiny
[12:41] <rbasak> pitti: you realise /var/log/dmesg is only written on boot and never touched again, right?
[12:41] <pitti> yes
[12:45] <rbasak> pitti: get systemd upstream to not rotate the first dmesg output out, and then we won't need to keep a file with it any more. If you really want :)
[12:45] <pitti> rbasak: systemd? linux you mean?
[12:45] <rbasak> No I think linux would insist it's a userspace concern.
[12:45] <pitti> but the entire dmesg is in the journal
[12:45] <rbasak> It will rotate out, no?
[12:46] <pitti> rbasak: dmesg is the kernel's ringbuffer
[12:46] <rbasak> Yes, which rotates.
[12:46] <pitti> rbasak: yes, depending on your disk space
[12:46] <rbasak> OK. I'm saying that what was in the kernel's ringbuffer straight after boot is important, should be kept and should not rotate out ever.
[12:46] <rbasak> It's ~100K so that shouldn't really be a problem at all.
[12:46] <pitti> well, *shrug*, if you really care about yet another copy, I don't veto if someone adds that job to rsyslog; I just always foud it rather pointless
[12:47] <rbasak> We already did it in /var/log/dmesg, so let's keep doing that unless there's a replacement.
[12:47] <rbasak> OK, thanks :)
[12:47] <pitti> if you find it useful, I mean
[12:47] <rbasak> I have used it in the past a number of times.
[12:47] <rbasak> Saves having to reboot to get that information.
[12:47] <ogra_> yeah
[12:47] <pitti> TBH, I didn't even know that it existed until now :)
[12:48] <rbasak> "should not rotate out ever" -- well, rotating once-per-boot (like it did < Vivid) is fine.
[12:49]  * pitti checks, journal logging on my desktop goes back to April 22
[12:50] <rbasak> Sometimes things spam to dmesg
[12:51] <rbasak> Logging with rotation is never expected to always go all the way back to boot.
[12:51] <rbasak> (and that wouldn't be reasonable because of the space it might take)
[12:51] <mdeslaur> caribou: see the can of worms you've opened? :)
[12:53] <pitti> yeah, classical bikeshed territory :)
[12:53] <ogra_> mdeslaur, well, we heard about a "new fledgling in the Foundations team nest" .... worms are the food of the day ;)
[12:53] <pitti> you could have waited until Friday
[12:53] <pitti> ogra_: *tweet* *tweet*
[12:53] <ogra_> :D
[12:54] <mdeslaur> heh
=== MacSlow|lunch is now known as MacSlow
[13:44] <caribou> mdeslaur: ouch, I stepped out a while & missed on all the fun :)
[13:45] <mdeslaur> caribou: nice try :)
[13:45] <caribou> mdeslaur: well, looks like the rsyslog merge (aside from bikesheding) in not as hard as it looked
[13:45] <mdeslaur> caribou: cool
[13:46] <caribou> mdeslaur: most of the diff was in the CVE that you uploaded a while ago & that was a backport from newer versions
[13:53] <caribou> rbasak: back at the upstart migration to systemd topic, the main difference in the upstart job it that it takes care of the apparmor profile
[13:53] <caribou> rbasak: so I do think that it is sufficient to justify migrating the job
[13:53] <rbasak> caribou: I think systemd has syntax for AppArmor
=== strikov is now known as strikov-lunch
[14:08] <mdeslaur> caribou: you can drop the apparmor stuff if you convert it to a systemd unit
[14:09] <mdeslaur> err, systemd service
[14:09] <caribou> mdeslaur: why ? seems rather trivial to keep it
[14:09] <mdeslaur> caribou: the apparmor stuff in upstart scripts was to prevent race conditions
[14:10] <mdeslaur> caribou: the systemd unit file for apparmor should be started early enough for that to not be a problem
[14:10] <caribou> rbasak: yeah, I found AppArmorProfile=, but according to the doc it still needs the profile to be loaded first
[14:10] <mdeslaur> caribou: yeah, don't use apparmorprofile=
[14:10] <caribou> mdeslaur: ah, ok
=== athairus_oops is now known as athairus
=== strikov-lunch is now known as strikov
[14:56] <gogis_> I know C/++, Python, Pascal, quite Java... I also understand Assembly and I can learn other languages quickly... can I somehow help with the development of ubuntu?
[14:58] <gogis_> hmm, it's quiet here :D
[15:05] <dobey> gogis_: do you have any particular things you are interested in helping with? there are plenty of bugs filed on launchpad (or in upstream bug trackers), which you could submit patches for
[15:07] <gogis_> dobey: Well, firstly, I should probably learn something more about how these works :)
[15:07] <gogis_> but where can I find the sources and how do I submit patches?
[15:12] <dobey> gogis_: generally, the best place to submit patches is to upstreams.
[15:13] <gogis_> dobey: okay, thanks :)
[15:43] <chiluk> hallyn, re: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1451598   ... I talked to arges a few days back about pushing the SRU, and he told me that you were bundling up a few fixes for precise ... is that still true or was it an error in communication?
[15:43] <ubottu> Ubuntu bug 1451598 in libvirt (Ubuntu Precise) "Libvirt spams libvirt.log with virNetSocketReadWire and similar errors" [Medium,New]
[15:44] <arges> there are also some libvirt bugs needing verification before we can accept the current libvirt in the queue
[15:44] <arges> #1425619 #1447030
[15:45] <chiluk> arges 1425619 is a trusty only fix.
[15:45] <chiluk> I'm concerned with precise only.
[15:46] <arges> chiluk: its in the pending queue. i missed it yesterday
[15:46] <arges> unapproved queue that is
[15:46] <chiluk> arges 1379585 is the one we need verified
[15:47] <chiluk> arges it looks like hallyn already verified 1379585
[15:47] <chiluk> so I'm not sure what's holding up the promotion to updates..
=== alvesadrian is now known as adrian
[17:36] <infinity> Huh.  I wonder why '-vga qxl' isn't the qemu default.  It actually functions sanely, unlike pretty much all the others.
[17:53] <juliank> Any idea how I can trigger bug 1445949 ?
[17:53] <ubottu> bug 1445949 in python-apt (Ubuntu) "Version does not conform to PEP440" [Undecided,New] https://launchpad.net/bugs/1445949
[17:54] <juliank> I have a workaround that normalizes the part of the Debian versioning scheme we use to PEP440 (ubuntu => +ubuntu, ~alpha => .a, ~beta=>.b, ~rc => .rc, ~exp => .dev, build is stripped)
[17:55] <juliank> This should make it happy, so I'd like to test it
[18:21] <hallyn> chiluk: i have a sru list but none for precise, so feel free to push that one
[18:22] <chiluk> arges ^^ do you mind?
[18:22] <chiluk> thanks hallyn ... I'm not a core dev yet.
[18:23] <arges> chiluk: sure
[18:23] <hallyn> oh
[18:23] <arges> chiluk: hallyn done
[18:24] <chiluk> I guess that's an indication that I probably should be ..
[18:24] <hallyn> what'd done exactly?  you pushed the fix for 1451598 ?
[18:25] <arges> hallyn: i've accepted libvirt into precise-proposed
[18:25] <arges> it was already sponsored
[18:25] <hallyn> oooh.
[18:25] <hallyn> i confused myself
[18:26] <arges> i have the same problems too
[18:27] <hallyn> well glad it's all settled :)  \0
[18:27] <hallyn> thx arges
[19:22] <dobey> infinity: hi! just curious on what else is holding up the nettle transition still. i see curl is a valid candidate now on the excuses page
[19:25] <infinity> dobey: A little too much multitasking is preventing me from unwinding it all right this instant.
[19:26] <dobey> infinity: ok
[19:27] <infinity> dobey: We probably need to decouple it from the Haskell transition, but I haven't had time to see if anything else is also holding it up.
[19:27] <dobey> ok.
=== pgraner is now known as pgraner-afk
=== salem_ is now known as _salem
[22:16] <juliank> Can/Should somebody mark bug 1464305 as only affecting vivid, utopic, and trusty? Wily's ndiswrapper supports kernel 4.0. The other(s) need a tiny fix, if someone wants to SRU them (https://anonscm.debian.org/cgit/collab-maint/ndiswrapper.git/commit/?id=fe307aab912c55fb357670e5e838c353712a689b)
[22:16] <ubottu> bug 1464305 in ndiswrapper (Ubuntu) "ndiswrapper-dkms 1.59-2: does not support kernel 4.0" [Undecided,New] https://launchpad.net/bugs/1464305
[22:18] <juliank> Because the only thing to care about is the strncasecmp strnicmp rename in the kernel, so it's not like this could break anything in an SRU
=== utlemming is now known as utlemming_away