[00:00] <walters> Keybuk: aiui the default i/o scheduler will, if inside the same process, go for maximum speed if you do that
[00:00] <maco> Keybuk: do you line wrap at all to avoid scrolling forever to the right?
[00:00] <Keybuk> maco: no, since "word wrap" was invented in the 80s, there isn't a need
[00:00] <soren> Keybuk: Uh, yeah, silly question indeed. /ignore me
[00:01] <maco> Keybuk: web browsers havent caught up apparently
[00:01] <Keybuk> maco: you mean bugzilla hasn't
[00:02] <maco> i was actually thinking it was the mailing list since ive seen the no-wrap-grrr thing on other lists
[00:02] <slangasek> so if you needed to detect with gcc -E what libc your build system is building against, what's the best way to do that?  #include <stdlib.h>, look for __GLIBC__ et al.?
[00:02] <Keybuk> slangasek: guards> in general the fix is replace write(a,b,c) with send(a,b,c, MSG_NOSIGNAL)
[00:03] <slangasek> Keybuk: right; you seemed to be suggesting SIG_IGN earlier, which would certainly modify the caller's handling of other signals
[00:03] <slangasek> well
[00:03] <slangasek> its handling of that signal from other sources
[00:04] <soren> Keybuk: That's what I'm doing right now. Seems to be pretty well contained, actually.
[00:04] <Keybuk> no, in that case I just meant that I couldn't understand why, if soren was intent on hiding the bug rather than fixing it, his patch wasn't just signal(SIGPIPE, SIG_IGN)
[00:04] <Keybuk> soren: yeah, I figured it might be ;)
[00:05]  * slangasek looks for a nibble on his libc question
[00:07] <soren> Keybuk: Becuase if I called plymouth_disconnected, the connection would be proplerly cleaned up, which meant that it would attemt the reconnect. I didn't realise the plymouth client lib would do that on its own.
[00:13] <soren> Keybuk: Would there be any point in wrapping the MSG_NOSIGNAL in an #ifdef?
[00:14] <Keybuk> you could certainly do
[00:14] <Keybuk> #ifdef MSG_NOSIGNAL
[00:14] <Keybuk> err
[00:14] <Keybuk> send (a,b,c,
[00:14] <Keybuk> #ifdef MSG_NOSIGNAL
[00:14] <Keybuk> MSG_NOSIGNAL
[00:14] <Keybuk> #else
[00:14] <Keybuk> 0
[00:14] <Keybuk> #endif
[00:14] <Keybuk> );
[00:14] <broder> eww
[00:15] <Keybuk> I think we did that in D-Bus
[00:15] <Keybuk> actually, I think we did
[00:15] <Keybuk> #if HAVE_MSG_NOSIGNAL
[00:15] <Keybuk>    MSG_NOSIGNAL
[00:15] <Keybuk> ...
[00:15] <Keybuk> and added a configure check
[00:15] <Keybuk> in case it got defined as an enum
[00:16] <soren> Indeed you did.
[00:16] <soren> Oh.
[00:16] <soren> I did the other thing as:
[00:16] <soren> send(a,b,c,0
[00:16] <soren> #ifdef MSG_NOSIGNAL
[00:17] <soren>         |MSG_NOSIGNAL
[00:17] <soren> #endif
[00:17] <soren>        )
[00:17] <soren> But meh.
[00:17] <Keybuk> that works too ;-)
[00:17] <Keybuk> points for stylishness
[00:18] <soren> Keybuk: I learned from the master: http://cgit.freedesktop.org/dbus/dbus/commit/?id=c5d0998295a15fe649da854b68334c767aad1049
[00:18] <Keybuk> lol
[00:23] <soren> Keybuk: Hm... I think dbus is doing it wrong.
[00:24] <soren> Keybuk: HAVE_DECL_MSG_NOSIGNAL is 1 if MSG_SIGNAL exists, 0 otherwise.
[00:24] <soren> Keybuk: ...but the check is #fidef HAVE_DECL_MSG_NOSIGNAL.
[00:24] <soren> Keybuk: So it's always defined.
[00:24] <soren> Keybuk: Either that or the comment in config.h.in lies.
[00:28] <soren> Keybuk: Nope, the comment is accurate.
[00:34] <soren> Keybuk: Oh. That's fixed recently, apparantly.
[01:01] <soren> Keybuk: Thanks for the pointers. It seems to work well.
[01:01] <soren> Keybuk: I'll send it upstream Monday. I need to sleep now.
[01:09]  * cjwatson is glad Keybuk reviewed this before he got round to it
[01:09] <cjwatson> alexbligh1: it's entirely reasonable for a package to assume that its own debconf templates are there - it shouldn't need to do any defaulting
[01:28] <gurkan_> hi mates
[01:28] <gurkan_> need help about my /var/run/utmp file
[01:29] <gurkan_> i have read the man page but it's not clear on 2 points
[01:29] <gurkan_> i didn't understand the getutline and getutid fonctions
[01:30] <gurkan_> if someone seems to know well this function and utmp file he could explain me
[01:31] <psusi> what don't you understand about it?
[01:32] <gurkan_> the how !
[01:32] <gurkan_> i don't understand the how
[01:32] <psusi> how what?
[01:33] <gurkan_> how to implement in my code the getutline fonction for exploiting his return value if it is not empty how can i know about value contains
[01:34] <gurkan_> i read that search forward from the curent position ... blabla but
[01:34] <psusi> you don't implement the function in your code, it is part of the standard library... you just call it.  the man page shows example code
[01:36] <gurkan_> no the man page not show the exemple of getutline exemple , after you implement setutent in the code what did i extract whit getutline function
[01:37] <psusi> actually I guess the example is only of how to update the entries not read one
[01:37] <psusi> you extract a utmp entry in a struct utmp
[01:38] <gurkan_> yes this is the man page exemple , but the form which interest me is only the read in deep of all database
[01:38] <psusi> huh?
[01:39] <gurkan_> the man page show erase/append correct .
[01:39] <psusi> yes
[01:39] <gurkan_> as i said i try on to read
[01:39] <psusi> yea... so you call getutent() and then getutline() repeatedly
[01:39] <gurkan_> only to read with getutline
[01:40] <psusi> err, actually it looks like you just use getutent.. getutline seems to be for searching for a specific command someone is running
[01:42] <gurkan_> while ((u=getutent()) !=NULL) it's not enough
[01:43] <psusi> not enough for what?
[01:44] <psusi> that should set up a loop that will iterate over all of the utmp records
[01:44] <gurkan_> struct utmp *utmline;
[01:44] <gurkan_> struct utmp *ut ;
[01:44] <psusi> use pastebin
[01:44] <gurkan_> getutline() searches forward from the current file position in the utmp
[01:44] <gurkan_>        file.   It scans entries whose ut_type is USER_PROCESS or LOGIN_PROCESS
[01:44] <gurkan_>        and returns the first one whose ut_line field matches ut->ut_line.
[01:44] <gurkan_> it's not clear for
[01:45] <gurkan_> i need a sample exmeple of code
[01:45] <gurkan_> sorry
[01:45] <cjwatson> perhaps you could ask in a general C or Unix programming help channel
[01:45] <psusi> the while loop you just pasted is a good start... now just do something with u in the body
[01:45] <cjwatson> this is really not a programming help channel, unless you're specifically working on a piece of code in Ubuntu
[01:46] <gurkan_>  ok watson
[01:46] <gurkan_> sorry for my flood
[01:47] <psusi> cjwatson, hey cj... are you familliar with partman-ext3?  and if so, think you could get it to mount a newly formatted ext4 partition in natty with the mount option that prevents the background auto zeroing of the inode table so the installation goes faster? ;)
[01:47] <cjwatson> you already have a bug open about that don't you?
[01:47] <cjwatson> I'll get to it, if so :)
[01:47] <cjwatson> and yes, I'm familiar with partman-ext3
[01:48] <cjwatson> I've queued up bug 556621 in my browser for later action
[01:49] <cjwatson> not really enough brain to analyse it right now though
[01:53] <Keybuk> cjwatson: I tend to think that bugs like that are worth fixing properly, so the next person doesn't have to do the same "fix" you did befoer
[01:54] <cjwatson> Keybuk: oh I agree, I was just glad you got to think through it so I didn't have to :)
[01:55] <Keybuk> cjwatson: :D
[01:55] <Keybuk> and they say this place is a black hole...
[01:55] <cjwatson> you're just sentient Hawking radiation
[02:02] <psusi> cjwatson, yea, have a bug open
[02:03] <psusi> Keybuk, hey, there you are... not seen you lately.. still not had a chance to review my patches for ureadahead?  also I tried something a little nuts the other day... rather than only read the parts of the files that are still in the cache, I disabled the calls to mincore() and just had it read the entire file always... and it sped things up
[02:05] <psusi> managed to get down just under 15 seconds boot time with natty on the 1.5tb wd green drive
[02:06] <ohsix> what sort of changes? (url to patch/tree?)
[02:06] <psusi> must... get... to...10...
[02:06] <Keybuk> psusi: I'm not reviewing patches to ureadahead
[02:06] <Keybuk> if you want to play with it, be my guest
[02:07] <Keybuk> if you can improve things, w00t
[02:07] <psusi> ohsix, bzr branch code.launchpad.net/~psusi/ubuntu/natty/ureadahead/mine
[02:07] <psusi> that plus using e2defrag to pack the files
[02:08] <psusi> Keybuk, so I should poke pitti or cjwatson about it? ;)
[02:09] <Keybuk> psusi: I don't think you need to poke either of them
[02:09] <Keybuk> if you can make a new version and demonstrate it improves *for everybody*
[02:09] <Keybuk> then you touched it last ;-)
[02:10] <Keybuk> though for release tracking, you should probably demonstrate that to cjwatson
[02:10] <psusi> lol... so I get to become maintainer?  heheh...
[02:10] <Keybuk> since he's tech lead of foundations
[02:10] <psusi> probably getting a little late in this dev cycle for it now, but be nice to get it in early next cycle for testing
[02:11] <psusi> or maybe I make some more noise about getting people to test it from my ppa and report results...
[02:12] <psusi> I've been learning python lately too... really nice language... only took me about 10 minutes the other day to figure out how to write about a dozen lines of code to run ureadhaead --dump, parse the output, sort files from directories, and spit out the inode priority list file for e2defrag to pack the dirs first, then files
[02:13] <JanC> psusi: of course python is a nice language, it was named after Monty Python after all  ;)
[02:14] <psusi> hehe
[02:14] <Keybuk> psusi: probably the best plan would be to PPA test now, so then you can justify it for whatever natty+1 is called
[02:14] <ion> obese
[02:14] <Keybuk> oscillating ocelot?
[02:14] <psusi> Opal Ostrich
[02:18]  * JanC doesn't make proposals anymore, because my "superior proposals" for release names never get used  ;-(
[02:22] <psusi> this is the postinst from ureadhaead: http://pastebin.com/3W4Atpxg
[02:22] <psusi> that's not going to force a reprofile on upgrade is it?
[02:22] <psusi> only on trigger, right?
[02:24] <psusi> I can combine that into one line for configure | triggered) right? so both will reprofile?
[02:25] <Keybuk> yes
[02:25] <psusi> k.. I'll do that then call for testers
[03:59] <ChogyDan> RAOF: hey there, just leaving a note that it looks like 625280 might break upgrades from lucid->maverick.  The lucid package now outversions the maverick package
[08:46] <soren> If I want to patch Plymouth, do I have to push the changes to lp:ubuntu/plymouth first?
[08:48] <soren> I found dealing with that bzr branch very confusing. Apparantly, all the patches are already applied, but there's no .pc directory, so I don't know how to quilt push/pop and such.
[08:57] <lifeless> soren: bzr log ? :)
[09:00] <soren> lifeless: Hmm.. Yes, I guess that does hold the answer my question :) I'm still puzzled how I can work with quilt patches in there, though.
[09:02] <soren> Or perhaps I'm misunderstanding the error message I get when I try to quilt push -a.
[09:02] <lifeless> does the package already use quilt ?
[09:03] <soren> Every single patch fails to apply, apparantly.
[09:03] <soren> lifeless: Yes.
[09:03] <soren> ...and I somehow thought that was because they were already applied, but I also can't reverse apply them in reverse order, so this is even more confusing.
[09:07] <soren> meh
[09:08] <lifeless> gl
[10:57] <tim> hi ... how do i create a source package? git-buildpackage only creates a binary package for me ..
[10:59] <debfx> tim: git-buildpackage -S
[11:00] <tim> debfx: thanks!
[12:38] <tim> hm ... using dpkg-buildpackage, how can i force the creation of the orig tarball?
[12:39] <ogra> the orig tarball is the original upstream source tarball
[12:39] <ogra> dpkg-buildpackage does not create it, you have to do that
[12:40] <tim> orga, ok ... but then, how can i include it for a launchpad upload?
[12:43] <ogra> you take the original tarball you downloaded for the project and name it <sourcepackage name>_<upstream version>.orig.tar.gz in the dir above your package source tree
[12:43] <mr_pouit> you can also force with -sa (see men dpkg-genchanges)
[12:43] <mr_pouit> s/men/man/
[12:43] <ogra> mr_pouit, that will create a native package
[12:44] <soren> ogra: Uh... No, it won't?
[12:44] <mr_pouit> ogra: well, I don't know, it's still possible that it's e.g. xxx-2ubuntu1, in which case dpkg-genchanges wouldn't include the orig
[12:45] <soren> -sa means "always include orig tarball, even if the version number suggests that it's already in the repository".
[12:45] <ogra> soren, ?? since when ? -sa means only "attach source"
[12:45] <ogra> right
[12:45] <soren> ogra: Since I started using dpkg-buildpackage.
[12:45] <ogra> it doesnt *create* it
[12:45] <soren> ogra: Oh, sure.
[12:46] <soren> ogra: Oh, right,I see what you're saying.
[12:46] <ogra> it only adds it to dsc and changes so it gets uploaded alongside
[12:46] <soren> Ok, so adding your advice up, you're right..
[12:46] <mr_pouit> but I read his second question as "how to include it in the .changes anyway?"
[12:47] <soren> But individually, you're not :) It's not necessarily enough that the orig tarballs is there and is named correctly.
[12:47] <ogra> well, if it already exists -sa is definitely needed for a first upload
[12:47] <soren> The tarball has to be there, and to be sure it gets included, you have to pass -sa.
 hm ... using dpkg-buildpackage, how can i force the creation of the orig tarball?
[12:47] <ogra> that doesnt suggest that it exists yet though
[12:48] <soren> True indeed.
[12:48] <ogra> :)
[12:48] <soren> I'm just saying (or trying to say) that finding the tarball and naming it the rigth way doesn't necessarily mean it gets included in his upload.
[12:48] <ogra> yeah
[12:49] <ogra> thats the second step indeed
[12:49] <ogra> there you need .sa
[12:49] <ogra> *-sa
[12:49] <tim> ok ... then how do i sign the *upload file manually?
[12:49] <soren> The upload file doesn't get signed. The .dsc and .changes do.
[12:49] <ogra> dpkg-buildpackage -S should offer that to you automatically
[12:49] <ogra> err, right
[12:49] <ogra> what soren said
[12:50] <ogra> .upload is effectively only the stamp for a successfull upload
[12:51] <tim> ok, answering all my questions: the -sa flag adds the orig.tar.gz file to the .changes
[12:52] <tim> but it is passed from git-buildpackage to dpkg-buildpackage to dpkg-genchanges
[12:52] <ogra> right
[12:52] <tim> wonderful
[12:52]  * ogra doesnt know git-buildpackage ... 
[12:52] <ogra> i stay away from git as far as i can :)
[12:52] <tim> it is very annoying that one program has flags, which are not documented in the man pages
[12:53] <tim> -sa is neither documented in git-buildpackage nor in dpkg-buildpackage
[12:53] <tim> the manpage of dpkg-buildpackage tells just tells, that it is passed to dpkg-genchanges
[12:54] <ogra> it is point 7 in the dpkg-buildpackage manpage
[12:54] <ogra> might not be 100% obvious on first sight though
[12:55] <tim> ... now when searching for a specific option, in manpage 1 it won't search in manpage 2
[12:55] <ogra> file a whishlist bug for nested searching in man then ;)
[12:55] <penguin42> tim: I have some sympathy; I spent an hour before I got out of the office last night fighting this
[12:56] <tim> quite annoying if you just build a new package every few months
[12:56] <penguin42> yeh
[12:57] <tim> well ... rant is over ... will need to go to work now ...
[12:57] <tim> anyway ... thanks for the help!
[14:00] <trudell> hi guys
[14:01] <trudell> i and a lot of users thinks that is important a mplayer compiled with midi support
[14:01] <trudell> so mplayer-plugin needs mplayer with midi support and timidity plugin to run midi files from web browser
[14:01] <trudell> but is out in kubuntu compilation
[14:01] <trudell> i compiled my own version of mplayer, but is incompatible with smplayer
[14:03] <trudell> so, developers here thinks about mplayer compiled with midi support and timidity plugin for mplayer
[14:04] <trudell> if not, how i can compile the same version used in ubuntu with midi support?
[14:07] <shadeslayer> kees: around? can you have a look at bug 702026 ?
[14:13] <bdrung> kirkland: please unsubscribe ubuntu-sponsors once you uploaded the package
[14:14] <killown> I've been having this problem with flash 10.2 on ubuntu, basically if I have a youtube video open it is still shown even when It's been closed or if I scroll off the page. However weirdly it only shows on the black parts of my screen, for example a black picture will show a perfect picture of the youtube player with the last video I watched, even if I close the video (and firefox), please ubuntu devels make a flash 10.1 package and purge this
[14:14] <killown>  10.2 buls***
[14:14] <persia> Or, for that matter, if there's some reason it can't/shouldn't be uploaded (e.g. you committed upstream, or the proposed "fix" isn't actually any sort of codefix, etc.)
[14:18] <kklimonda> hey, would that be unthinkable to bundle some library with Transmission, and link to it statically for natty?
[14:19] <hallyn> is anyone else having trouble in natty as of latest upgrade with update-grub hanging?
[14:19] <hallyn> oooooh
[14:19] <hallyn> f
[14:19] <hallyn> It's cause /dev/nbd01 exists
[14:19] <hallyn> never mind :)
[14:20] <kklimonda> That's how Transmission developers did that in the past - bundling the version of libevent they required, as distributions didn't provide an updated version, but then we've managed to update it, and they have dropped the bundled version. But now we are in the same situation, as we may not be able to update libevent to the new version, and it's not installable in parallel with the old one.
[14:22] <trudell> i and a lot of users thinks that is important a mplayer compiled with midi support
[14:22] <trudell> so mplayer-plugin needs mplayer with midi support and timidity plugin to run midi files from web browser
[14:22] <trudell> but is out in kubuntu compilation
[14:22] <trudell> so, developers here thinks about mplayer compiled with midi support and timidity plugin for mplayer
[14:23] <trudell> i compiled my own version of mplayer, but is incompatible with smplayer
[14:25] <kklimonda> trudell: have you tried asking someone, for example siretart, for the reason why is midi support in mplayer disabled?
[14:26] <cjwatson> also, it isn't manageable for everyone to report bugs (or change/enhancement requests or whatever) on IRC.  could you please use the bug tracking system instead?
[14:33] <trudell> kklimonad: nope. Why reason, do you know?
[14:34] <trudell> siretart: why reason midi support and timidity plugin for mplayer are disabled?
[14:37] <bdrung> tumbleweed: around?
[14:41] <trudell> why reason midi support and timidity plugin for mplayer are disabled? anyone knows?
[14:41] <trudell> can developers change this custom?
[14:42] <trudell> abiliting the midi support?
[14:44] <kklimonda> trudell: just broadcasting the question, in the middle of the weekend, won't get you the answer any faster. You can try ubuntu-devel-discuss mailing list.
[14:47] <trudell> kklimonda: have you the adress of ubuntu-devel-discuss?
[14:48] <kklimonda> !list
[14:48] <kklimonda> hmm
[14:48] <kklimonda> trudell: check https://lists.ubuntu.com/
[14:51] <trudell> kklimonda: thx so much for your attention, i will come back in the middle of week to talk with siretart or another developer
[14:51] <cjwatson> trudell: and like I say, the bug tracking system is more appropriate anyway
[14:52] <trudell> do you know where i can do suggestions to kubuntu developers?
[14:52] <cjwatson> file a bug
[14:52] <cjwatson> better than trying to get a developer's attention when they may be working on something else; a bug report means that it will be queued, not forgotten
[14:53] <trudell> bugtracking? have bug in mplayer's midi support?
[14:53] <cjwatson> we use the bug tracking system for enhancement requests as well as for actual bugs
[14:54] <cjwatson> "please enable MIDI support in mplayer" is a reasonable enhancement request (assuming you've already done due diligence in searching the web to see that it hasn't already come up)
[14:54] <trudell> can developers get users suggestions through bur-report?
[14:54] <trudell> *bug-report
[14:55] <cjwatson> yes
[14:55] <trudell> yeah, me and a lot of users
[14:56] <trudell> and have not affect any function if enabled
[14:56] <cjwatson> IRC is not appropriate for this
[14:56] <trudell> sorry, i'm newbie
[14:56] <cjwatson> most of the developers on this channel don't do anything related to mplayer
[14:57] <cjwatson> the bug tracking system allows messages to be directed to developers who are interested in the topic in question
[14:57] <cjwatson> rather than broadcast to everyone on the channel
[15:07] <trudell> alright, thx
[15:39] <bdrung> tumbleweed: u-d-t build failure fixed
[15:54] <kees> shadeslayer: what can I help with on that bug?
[15:57] <ImGangsta> !ops
[15:59] <ImGangsta> !ops
[15:59] <sebner> ImGangsta: ??
[16:00] <ImGangsta> Im gangsta
[16:00] <sebner> rofl
[16:10] <iulian> o_O
[16:27] <kirkland> bdrung: why?
[16:28] <kirkland> bdrung: the bug should be closed at that point
[16:28] <kirkland> bdrung: if there's more traffic on the bug after that, then ubuntu-sponsors should be aware
[16:28] <bdrung> kirkland: not for SRUs
[16:29] <bdrung> kirkland: the usual work flow is to unsubscribe ubuntu-sponsor and subscribe yourself
[16:45] <shadeslayer> kees: https://bugs.launchpad.net/ubuntu/+source/dcmtk/+bug/702026/comments/1 << :)
[16:50] <ScottK> lamont: Any chance for postfix 2.8.0 this weekend?  We're getting close to feature freeze ...
[16:55] <kees> shadeslayer: oh, hey, I missed me. (I was already subscribed via MIR so I didn't notice, and got distracted by the compilation failure discussion.) heh
[16:55] <kees> shadeslayer: yeah, I'll look at it, thanks!
[16:55] <shadeslayer> ;)
[16:55] <shadeslayer> thanks! :)
[18:45] <kklimonda> hmm, any idea if there is a way to download all maintainer scripts for all packages in Ubuntu?
[18:45] <ari-tczew> kklimonda: apt-get source ubuntu-dev-tools devscripts ?
[18:46] <kklimonda> ari-tczew: I was thinking about package maintainer scripts (postinst, prerm etc.)
[18:48] <nhandler> kklimonda: There isn't an easy way to get all of the maintainer scripts (not quite sure why you would want to do that). You could probably hack something together (but it would probably involve downloading all the source packages and checking if they have maintainer scripts)
[18:48] <kklimonda> I can probably limit it to downloading only .diff.gz/debian.tar.gz files
[18:48] <kklimonda> to download*
[18:50] <kklimonda> as for why - I'm interested what are main uses of those scripts, how many packages use them, how many of them are used by standalone desktop applications for something else then updating various databases
[18:59] <geser> kklimonda: are you only interested in manual written ones? dh_* may create maintainer scripts but you don't see a trace in .diff.gz/debian.tar.gz
[19:00] <geser> looks like you need a ubuntu mirror and extract all maintainer scripts from the .debs
[19:02] <kklimonda> geser: yes, I only care about ones written by maintainers, not those automagically generated
[20:08] <lamont> ScottK: I'll make time for 2.8.0 this weekend, though it might be monday before an upload
[20:08] <ScottK> lamont: Cool.  I think a lot of people will want to give postcreen a shot.
[20:38] <ohsix> whats needed in checkbox so pulseaudio's package can go with flat-volumes on? (the problems are down to broken drivers w/invalid information, lots have been fixed since 9.04)
[20:41] <ImGangsta> Im gangsta
[20:42] <ImGangsta> !ops
[20:42] <ImGangsta> !ops
[20:43] <ImGangsta> !ops
[20:43] <ImGangsta> hey bitch
[20:43] <ImGangsta> im gangsta
[21:06] <siretart> kklimonda: if trudell appears again: patches welcome! :-)
[21:12] <Dr_Who> anyone creating seeds with germinate will want to know about bug #717879
[21:50] <penguin42> does anyone know if Natty's use of log files has purposely changed or is my empty /v/l/messages a bug ?
[22:00] <ScottK> penguin42: There were some changes.  I don't think it's a bug, but I'm not sure.
[22:01] <penguin42> I think everyone is in that boat :-)
[22:02] <penguin42> the stanza for catch-all log files is commented out in /etc/rsyslogd.d/50-default.conf
[22:03] <penguin42> ah
[22:03] <penguin42> changelog comments say it's on purpose
[22:03] <penguin42> 'Disable redundant and non-synchonous log files by default (this will only affect new installations), to reduce disk size overhead and unnecessary wakeups and IO'
[22:03] <penguin42> hmm not a new installation, but still
[22:05] <ion> I liked that change. I never liked the redundant log files that each received a slightly different set of lines.
[22:07] <psusi> indeed
[22:11] <penguin42> yeh probably not a bad idea - might take me a while to actually figure out where to look; I've been looking at /v/l/messages for about 15 years
[22:36] <broder> penguin42: /var/log/syslog has always had more than /var/log/messages on debian/ubuntu