| === anthonyf is now known as Guest23073 | ||
| Mirv | doko: ack, I asked mandel to look at the bug, he probably knows what it's about then | 04:56 |
|---|---|---|
| linuxuz3r | just wanna say hi | 05:03 |
| linuxuz3r | im a noob | 05:03 |
| pitti | Good morning | 05:24 |
| Unit193 | Howdy, pitti. | 05:30 |
| === anthonyf is now known as Guest46780 | ||
| === anthonyf is now known as Guest47313 | ||
| 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] | 09:12 |
| === Malsasa_ is now known as Malsasa | ||
| 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 ? | 11:05 |
| === _salem is now known as salem_ | ||
| caribou | on the same topic, should I also migrate the upstart job to systemd ? upstream debian hasn't done the systemd bits yet | 11:48 |
| === MacSlow is now known as MacSlow|lunch | ||
| rbasak | caribou: does that mean that Vivid with systemd regresses the saving dmesg on boot functionality? | 11:58 |
| 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 | 11:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:04 |
| caribou | rbasak: don't think it is in the debian package | 12:05 |
| pitti | caribou: it's all in the journal, isn't it? | 12:23 |
| rbasak | Hmm. I suppose if systemd provides equivalent functionality then we don't need it? (Does it?) | 12:27 |
| mdeslaur | pitti: the journal isn't enabled by default though, no? | 12:30 |
| * mdeslaur doesn't have a /var/log/journal directory | 12:31 | |
| pitti | mdeslaur: journal is (in /run), just not persistant journal in /var | 12:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:45 |
| 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:46 |
| 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:47 |
| rbasak | "should not rotate out ever" -- well, rotating once-per-boot (like it did < Vivid) is fine. | 12:48 |
| * pitti checks, journal logging on my desktop goes back to April 22 | 12:49 | |
| rbasak | Sometimes things spam to dmesg | 12:50 |
| 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:51 |
| 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:53 |
| mdeslaur | heh | 12:54 |
| === MacSlow|lunch is now known as MacSlow | ||
| caribou | mdeslaur: ouch, I stepped out a while & missed on all the fun :) | 13:44 |
| 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:45 |
| caribou | mdeslaur: most of the diff was in the CVE that you uploaded a while ago & that was a backport from newer versions | 13:46 |
| 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 | 13:53 |
| === strikov is now known as strikov-lunch | ||
| mdeslaur | caribou: you can drop the apparmor stuff if you convert it to a systemd unit | 14:08 |
| 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:09 |
| 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 | 14:10 |
| === athairus_oops is now known as athairus | ||
| === strikov-lunch is now known as strikov | ||
| 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:56 |
| gogis_ | hmm, it's quiet here :D | 14:58 |
| 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:05 |
| 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:07 |
| dobey | gogis_: generally, the best place to submit patches is to upstreams. | 15:12 |
| gogis_ | dobey: okay, thanks :) | 15:13 |
| 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:43 |
| 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:44 |
| chiluk | arges 1425619 is a trusty only fix. | 15:45 |
| chiluk | I'm concerned with precise only. | 15:45 |
| 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:46 |
| 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.. | 15:47 |
| === alvesadrian is now known as adrian | ||
| infinity | Huh. I wonder why '-vga qxl' isn't the qemu default. It actually functions sanely, unlike pretty much all the others. | 17:36 |
| 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:53 |
| 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:54 |
| juliank | This should make it happy, so I'd like to test it | 17:55 |
| hallyn | chiluk: i have a sru list but none for precise, so feel free to push that one | 18:21 |
| chiluk | arges ^^ do you mind? | 18:22 |
| chiluk | thanks hallyn ... I'm not a core dev yet. | 18:22 |
| arges | chiluk: sure | 18:23 |
| hallyn | oh | 18:23 |
| arges | chiluk: hallyn done | 18:23 |
| 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:24 |
| 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:25 |
| arges | i have the same problems too | 18:26 |
| hallyn | well glad it's all settled :) \0 | 18:27 |
| hallyn | thx arges | 18:27 |
| 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:22 |
| infinity | dobey: A little too much multitasking is preventing me from unwinding it all right this instant. | 19:25 |
| dobey | infinity: ok | 19:26 |
| 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. | 19:27 |
| === pgraner is now known as pgraner-afk | ||
| === salem_ is now known as _salem | ||
| 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:16 |
| 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 | 22:18 |
| === utlemming is now known as utlemming_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!