[17:31] <emet> can I join the documentation team?
[18:28] <seisen> emet, https://wiki.ubuntu.com/DocumentationTeam/Mentoring
[19:36] <Atamira> and welcome emet
[19:39] <emet> hi
[23:51] <kgoetz> hi all. has string freeze set in?
[23:57] <kgoetz> anyhow. i want to propose this change: http://paste.ubuntu.com/45068/
[23:57] <kgoetz> i had to google define: the word, and i'm guessing its not an uncommon thing.


[00:09] <jono> what is the best wiki page to read that outlines the quality checks that are made for new packages in Ubuntu?
[00:11] <tumbleweed> Laney: Haskell page on the wiki says I should ask you: http://launchpadlibrarian.net/50767019/buildlog_ubuntu-maverick-armel.haskell-testpack_2.0.0-3_FAILEDTOBUILD.txt.gz
[00:13] <Laney> tumbleweed: you need to rebuild those dependencies
[00:13] <tumbleweed> Laney: I was guessing as much
[00:13] <Laney> you might find http://orangesquash.org.uk/~laney/haskell-installability/armel.png useful
[00:14] <Laney> but if you're just fixing stuff off the FTBFS list then I'd ignore Haskell things for now
[00:14] <tumbleweed> Laney: no that was an upload of mine
[00:15] <tumbleweed> I can have a prod at the dependancies
[00:15] <Laney> cool
[00:15] <Laney> i should chase down those haskell merges
[00:16] <Laney> http://pastebin.ca/1888897
[00:18] <jpds> Laney: Dude, that thing killed X.
[00:19] <Laney> You need a better X!
[00:19] <jpds> Here's some big .png's from me: http://people.canonical.com/~jpds/mirrors/
[00:20] <lifeless> morning jpds
[00:20] <jpds> Evening lifeless.
[00:20] <lifeless> jono: I'm not sure there is one.
[00:20] <jono> lifeless, thats what I thought
[00:21] <lifeless> jono: there are two basic checks: 'package is good' - which is the union of all quality guidelines.
[00:21] <lifeless> so a page just listing it would be a) huge and b) out of date on day 2.
[00:21] <Laney> jono: will try to reply to your mail tomorrow
[00:22] <lifeless> the second check is 'package copyright and license are documented well enough [and compatible with the suite they are going to be put into'
[00:22] <lifeless> which is actually conceptually redundant with the first check (and package merges from $source [e.g.] upstream *really should* check this hasn't changed, its a bit of a hole at the moment.
[00:22] <lifeless> jono: ^
[00:25] <jono> Laney, awesome, I am just writing another change and merging in mdz's comments
[04:50] <EzraR> anyone want to revu a package :) should be an easy review allready has one akk
[05:59] <NorthernLights> Hi there
[06:51] <dholbach> good morning
[06:58] <iulian> Morning Daniel.
[06:59] <dholbach> hey iulian
[07:26] <didrocks> hyperair: Laney: FYI, I will make some packaging changes to Banshee (enabling some plugin by default and make some patch), the idea is to experiment there and once stabilized (I hope in one week approximately), I will sum up changes that should be upstreamed and those which make sense to Debian as well. Does it sound ok?
[07:27] <hyperair> where is there?
[07:27] <didrocks> hyperair: for now, my changes is just in a bzr branch, one sec
[07:27]  * hyperair groans at the mention of bzr
[07:28] <didrocks> hyperair: it's just easier in my system and make sense.
[07:28] <didrocks> hyperair: https://code.edge.launchpad.net/~didrocks/banshee/une-modif
[07:28] <didrocks> hyperair: it's really small tweaking for now, mostly make it fit in non meego environment
[07:38] <hyperair> didrocks: those look like changes that should be upstreamed immediately, to be honest.
[07:39] <didrocks> hyperair: well, I'm not quite sure it's the definitive answer, that's why I want to test them before next banshee release, (I'm waiting for the last change I discussed in Banshee ML first). But I can post on both
[07:39] <hyperair> post on both what?
[07:42] <didrocks> hyperair: upload to ubuntu and propose them to upstream
[07:44] <hyperair> i'd prefer you propose them upstream first, then upload to ubuntu.
[07:45] <didrocks> hyperair: well, that's the same in a question of 10 minutes delay, but if this matters to you
[07:45] <hyperair> i'm rather apprehensive about having Ubuntu's Banshee package fork from Debian at all, and to a slightly lesser extent, about having Debian's package fork from upstream at all.
[07:46] <hyperair> in fact, i'd propose you do all this testing in a PPA, rather than putting it into maverick directly.
[07:46] <didrocks> hyperair: well, the only change I think that you want in Debian is enabling the import from ~/Music and ~/Video by default
[07:46] <didrocks> hyperair: well, maverick is unstable
[07:47] <didrocks> hyperair: I don't see why those changes who works shouldn't go to maverick
[07:47] <didrocks> but ok, I'll post my patches upstream and upload the changes to ubuntu
[07:48] <hyperair> just a question.. exactly what changes are you planning to include?
[07:48] <hyperair> importing of ~/Music and ~/Video by default is something i wouldn't condone.
[07:48] <hyperair> a prompt would be good
[07:48] <hyperair> i think it was mentioned on the mailing list
[07:48] <hyperair> "Do you want to import .... "
[07:48] <didrocks> hyperair: yeah, and I gave some answer to them. Prompts are ugly on first launch
[07:49] <didrocks> hyperair: for the changes, did you see my branch ^
[07:49] <hyperair> but importing automatically is getting ahead of yourself.
[07:49] <hyperair> i saw 5 commits, but i'm thinking you might have other changes in mind?
[07:49] <hyperair> i'm asking about all the *planned* changes, not just the ones you've already done so far.
[07:50] <didrocks> hyperair: just the notification think we discussed on IRC. It's really small things, as said
[07:50] <didrocks> and enabling import by default
[07:50] <hyperair> notification?
[07:50] <hyperair> what notification?
[07:51] <didrocks> hyperair: the "your list of music is empty, if you want to fill it up, please use the import or drop in …"
[07:51] <hyperair> er, isn't that kind of redundant with importing from ~/Music and ~/Videos by default?
[07:52] <hyperair> or do you mean it as a mutually exclusive thing?
[07:52] <didrocks> hyperair: not really, because if you activate importing from ~/Music and ~/Videos by default and you don't have music there
[07:52] <didrocks> you should be told where to put your music
[07:53] <hyperair> i get the feeling i'd be really annoyed if i tried banshee for the first time and it immediately imported my ~/Music and ~/Videos immediately.
[07:54] <hyperair> i'd be happier if it popped up the import dialog on first run though
[07:54] <didrocks> hyperair: really? prompting has been defeated. Do you remember amarok in KDE3?
[07:55] <hyperair> i remember using the old amarok, ages ago.
[07:55] <didrocks> it went to an extense "which DB do you want to use"
[07:55] <hyperair> that was ridiculous.
[07:55] <didrocks> right, I think for most of people telling where your music should be imported is the same
[07:55] <hyperair> but amarok lost many amarok1.* users
[07:56] <hyperair> i've seen many amarok 1.* users jumping over to banshee
[07:56] <hyperair> because they hate amarok2.
[07:56] <hyperair> doesn't that say something to you?
[07:56] <didrocks> well, I switched to rhythmbox :)
[07:56] <didrocks> at the time
[07:56] <RAOF> But amarok2 drastically changed the UI, and was broken for ages, wasn't it?
[07:57] <hyperair> and does rhythmbox automatically import ~/Music and ~/Videos without letting the user know?
[07:57] <hyperair> i don't think so.
[07:57] <hyperair> at least, i don't remember rhythmbox doing something like that, or i'd have held a strong grudge against it
[07:57] <didrocks> hyperair: we are discussing doing that as well
[07:58] <RAOF> hyperair: Why?  As long as it defaults to not touching the files, why would you _not_ want an audio file in ~/Music to be in your Banshee DB?
[07:58] <hyperair> RAOF: because importing is a CPU and I/O intensive process that is likely to slow down the computer and i don't want it to be doing something like that without my knowledge.
[07:59] <didrocks> I still think this is the goal of Ubuntu: making things easy to the user, and have something ready out of the box
[07:59] <RAOF> It wouldn't be without your knowledge, though - it'd say “importing files”
[08:00] <hyperair> didrocks: i'd rather you talk to upstream *properly* and come to a consensus about this before pulling something like this.
[08:00] <RAOF> While you can _technically_ use Banshee without having a local library, it's fundamentally a media library program and deliberately not having media listed in the library seems strange.
[08:00] <hyperair> RAOF: some people (like me) have focus prevention on which makes new windows appear behind the currently focused windows.
[08:01] <didrocks> hyperair: why? does GNOME upstream decide about distro app by default, for instance?
[08:01] <hyperair> RAOF: this means banshee will appear behind what i'm currently working on, and then will cause my computer to slow down and have weird hangs here and there, and i will be wondering wtf is going on, until i start conky and seeing banshee consume 100% of my CPU and 100% of my I/O.
[08:02] <hyperair> or top, or gnome system monitor, for that matter.
[08:02] <hyperair> didrocks: that's a different matter, imo
[08:03] <didrocks> I disagree, that's not different, we change also a lot of gconf settings and debian does in /usr/share/gconf/defaults/
[08:03] <hyperair> didrocks: and banshee upstream has already taken statistics, and found that most of the Banshee users are Ubuntu users. we're talking about moer than 50% here, somewhere around 70%.
[08:03] <hyperair> didrocks: this means they will be willing to compromise, and listen to anything Ubuntu has to say
[08:04] <hyperair> which also means we shouldn't push them away and introduce changes like this.
[08:04] <didrocks> hyperair: I can engage the discussion on the import by default settings, but for me, it's still a setting
[08:04] <hyperair> it will cause unnecessary drift between Ubuntu and upstream Banshee.
[08:08] <hyperair> then please do engage in the discussion. if upstream really doesn't agree, and the desktop team decides that it's better for all media players to automatically import on first run, then let's consider a downstream patch.
[08:10] <didrocks> hyperair: I'm preparing an email on banshee ML right now
[08:10] <hyperair> okay
[08:10] <superm1> hyperair, importing doesn't have to be CPU intensive or IO intensive though
[08:11] <hyperair> superm1: i think it's a bug filed on banshee somewhere.
[08:11] <RAOF> Well, it's probably going to be a bit I/O intensive.
[08:12] <hyperair> superm1: but for huge ~/Music (20G+) folders, which i'm sure many have, Banshee will need to scan for all media files, read their tags, optionally perform Mirage's scanning and BPM detection....
[08:12] <hyperair> it's going to be both CPU and I/O intensive.
[08:12] <superm1> that's not to say that can't be improved though with lower priority threads
[08:13] <RAOF> But it's not going to perform mirage scanning or bpm detection because they've just started up, and neither of those are enabled by default.
[08:13] <hyperair> our dear Completely Fair Scheduler has a habit of making X's cursor motion lag during heavy CPU of even processes/threads with high nice values.
[08:14] <hyperair> RAOF: doesn't it perform those when importing music?
[08:14] <RAOF> hyperair: Only when they're enabled.
[08:14] <RAOF> We're talking about import on first launch - there's no way the user could have enabled them yet.
[08:15] <hyperair> RAOF: ah, they're not enabled by default then?
[08:15]  * hyperair has forgotten
[08:15] <RAOF> Not enabled by default, no :)
[08:15] <hyperair> i see.
[08:15] <hyperair> well then that just leaves the heavy I/O of staring at the tags and recording them in the sqlite DB.
[08:15] <RAOF> Yeah.
[08:16] <RAOF> I'm not convinced that anyone's going to start up banshee for the /first time/ and leave it running in the background.
[08:17]  * hyperair shrugs.
[08:17] <hyperair> maybe not, but i'd still be happier to see something like...
[08:18] <RAOF> I mean, sure - we should ensure that the IO problem is minimised.
[08:18]  * RAOF heads livingroomward for bonus gas fire.
[08:18] <superm1> RAOF, what was that i saw murmured about hotplugging vga and intel the other day?
[08:19] <hyperair> how about when banshee's collection is empty, the treeview widget gets disabled and on top of it, a message that says "Your collection is empty. Do you want to import media?"
[08:19] <hyperair> something like how DAAP shares which can't be connected to get a message
[08:19] <didrocks> hyperair: still not sure, not ready "out of the box"
[08:20] <RAOF> Yeah, I think that would be a good idea.  It would be nicer if Banshee saw “hey, you've got audio files in ~/Music - I'm guessing that's your music”, though.
[08:20] <hyperair> RAOF: yeah, that's exactly what i'm thinking about.
[08:20] <didrocks> oh, btw, I just tried meego during we were discussing, there are enabling the plugin… I was thinking it was upstream banshee who made the tweaks, isn't it?
[08:21] <hyperair> didrocks: next you'll be telling me that mail clients shouldn't require account setup, but should automatically read the user's mind for usernames and passwords and automatically fetch mail.
[08:21] <RAOF> superm1: It works, and with the new xserver TheMuso sponsored for me it won't freeze compiz, either!
[08:21] <didrocks> hyperair: you are not being positive there.
[08:21] <hyperair> didrocks: i'm putting things in perspective.
[08:21] <superm1> RAOF, oooh purdy.  is it done in a nice way that other drivers will be able to add the functionality too?
[08:21] <RAOF> hyperair: If there was a ~/this-is-my-email-setup I totally _would_ expect email programs to read that on startup.
[08:22] <didrocks> there is no way to guess your email account
[08:22] <RAOF> superm1: nouveau already supports it, and I'm pretty sure radeon does, too.
[08:22] <didrocks> but there are for your music and video
[08:22] <superm1> RAOF, awesome!
[08:22] <hyperair> didrocks: okay, another example. you know how chromium prompts for importing of data from firefox/any other browser on your system?
[08:22] <hyperair> didrocks: in your case, it would *automatically* do that, without prompting.
[08:23] <superm1> on some hardware i've seen fglrx blob do something like that too, but it was probably cheating since it gets to leave a daemon running
[08:23] <didrocks> hyperair: this is because your are transitionning from one software to another
[08:23] <didrocks> hyperair: if I use rhythmbox
[08:23] <didrocks> and banshee propose me to import the rhythmbox collection
[08:23] <didrocks> that would make sense
[08:24] <RAOF> superm1: the kernel modules now trigger uevents on input hotplug, and the DDX is able to catch them.
[08:25] <hyperair> didrocks: it just seems to me like more consistent behaviour to follow the same first-time-running procedure for all use cases, whether the user has previously used rhythmbox, amarok, itunes, or not.
[08:25] <didrocks> hyperair: I clearly disagree on that point and it seems we won't reach an agreement there :/
[08:25] <hyperair> didrocks: so that when banshee first starts up, it brings up the first time running dialogue, which asks if the user wants to: i) import music from some other player, ii) import music from ~/Music
[08:26] <didrocks> do you imagine if every software would do that?
[08:26] <didrocks> a prompt at startup
[08:26] <didrocks> or worse, the "hint of the day" :-)
[08:26] <hyperair> a hint of the day is useless, imo, and can't really compare to this.
[08:27] <RAOF> hyperair: Apart from the IO issue, is there any other reason why you wouldn't want to have ~/Music in your banshee db?
[08:28] <hyperair> didrocks: okay, supposing that i did transition from Rhythmbox to Banshee, but my ~/.rhythmbox or whatever it is, isn't in a standard location, say an old /home directory which isn't /home any more.  Banshee starts up for the first time and immediately begins importing everything. what i'll need to do is cancel the importing, and then use the import media dialogue to specify that other location.
[08:29] <didrocks> hyperair: seems a more advanced use case to me
[08:29] <didrocks> hyperair: we are trying to adress the daily computer user, non geek one
[08:30] <didrocks> this one will use the default folder by default, that's why they are there
[08:30] <hyperair> didrocks: i understand that, but while we are trying to address the daily computer user, we end up creating loops for the geek ones to follow.
[08:30] <didrocks> hyperair: is it so much overhead?
[08:31] <didrocks> otherwise, we can propose installing GNOME or openbox if we want to go down the path :)
[08:31] <RAOF> But we're not talking about automatically importing ~/.rhythmbox; we're talking about ~/Music.
[08:32] <hyperair> RAOF: automatically importing ~/Music instead of ~/.rhythmbox makes rhythmbox->banshee users, which there will inevitably be, if Ubuntu switches to Banshee as default, lose all their ratings, play and skip counts.
[08:32] <hyperair> RAOF: that won't be pretty.
[08:33] <didrocks> hyperair: for people upgrading, they still have rhythmbox, we don't remove apps by default
[08:33] <didrocks> hyperair: it's for UNE users btw, not desktop ones
[08:34] <RAOF> hyperair: What happens if users then import their Rhythmbox library?
[08:35] <RAOF> IE: is there any reason why they couldn't later on import their Rhythmbox library, and have their ratings, play, and skip counts merged into the Banshee db?
[08:36] <directhex> FWIW rhythmbox imports my stuff by default. but i think it does ~
[08:37] <hyperair> RAOF: i dunno, i've never attempted.
[09:26] <didrocks> hyperair: did you try the banshee indicator in your previous upload? it doesn't work
[09:33] <hyperair> didrocks: eh? the one i just did hours ago?
[09:34] <didrocks> hyperair: right, I was hoping your rebuild with new -cli fixes it as you uploaded it
[09:34] <hyperair> no i didn't test it on maverick
[09:35] <didrocks> oh ok…
[09:35] <hyperair> didrocks: could you file a bug?
[09:35] <didrocks> hyperair: sure
[09:36] <hyperair> or maybe reopen the bug that was closed by that upload..
[09:36] <hyperair> no on second thoughts a new bug would be better
[09:36] <hyperair> didrocks: could i see the output of "banshee --debug"?
[09:36] <didrocks> hyperair: ok, will do :) btw, why do you enable lirc by default only on ubuntu
[09:36] <didrocks> sure, one sec
[09:36] <hyperair> didrocks: because the build-deps aren't satisfied on debian.
[09:37] <hyperair> didrocks: i remember poking someone about lirc on debian,  but he seemed to run into problem after problem trying to get lirc updated on debian. something about the debian team not acting, or something.
[09:38] <didrocks> hyperair: http://paste.ubuntu.com/453811/
[09:38] <didrocks> hyperair: ok, make sense
[09:40] <hyperair> didrocks: is that all that's mentioned? or is there any more?
[09:40] <didrocks> hyperair: no, even with --debug
[09:41] <hyperair> hmm
[09:41] <didrocks> (when I activate the indicator extension)
[09:41] <hyperair> well file a bug and subscribe qense to it then =)
[09:43] <didrocks> ok :)
[10:32] <huats> morning
[10:33] <shadeslayer_> huats: hey
[10:33] <eagles0513875> shadeslayer_: poke
[13:16] <dholbach_> can I persuade somebody to give a session at Ubuntu Developer Week? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the preliminary schedule
[13:34] <Rhonda> I got a mail that wesnoth-1.8 got accepted into karmic-backports, but rmadison doesn't show it yet, neither packages.ubuntu.com?
[13:36] <wgrant> Rhonda: It's in NEW.
[13:36] <wgrant> So you probably didn't get an email of acceptance.
[13:39] <Rhonda> I got a Fix Released launchpad notice.
[13:40] <Rhonda> I thought that would mean release. :)
[15:40] <Philip5> is it possible somehow to set at ie [i386] rule in a packagename.install file to controll if a file should be installed on [i386] but might not exist on [amd64]?
[15:40] <Philip5> or do i have to installed the file from debian/rules?
[15:41] <Philip5> anyone done this with .install files?
[15:44] <ScottK> Rhonda: I just pushed it through source New.  It'll hit binary New again after it's built though.
[15:46] <ScottK> Philip5: Something like this is done in kdebase-workspace for linux/non-linux architectures (Debian has non-linux architectures), so you might look at it for inspiration.
[15:47] <Philip5> ScottK: i'll have a look... i thought it would be nicer to do it that way than moving files in rules
[15:48] <Rhonda> ScottK: Ah, alright. :)
[15:48] <ScottK> Philip5: It uses arch specific install files and you can see how they use them in debian/rules
[16:31] <EricBa> Hello, is there a motu who has some time to review my package? It's already reviewed by one motu. My programm is a wallpaper changer for gnome. - http://revu.ubuntuwire.com/p/cortina It was already advocated by one reviewer.. so this won't take much time to review.
[16:34] <Rhonda> Yet another wallpaper changer for gnome? :)
[16:37] <shadeslayer_> tumbleweed: poke
[16:38] <tumbleweed> shadeslayer_: not a good time, about to go to pub quiz
[16:38] <shadeslayer_> sure
[16:38] <shadeslayer_> tumbleweed: any idea when you will be back?
[16:38] <tumbleweed> shadeslayer_: ~11pm SAST
[16:38] <shadeslayer_> ok
[16:42] <EricBa> Rhonda: exactly this one ;) I dont wont to manage my program on sourceforge, softpedia,.. etc. It's hard to upload it to every side
[16:43] <shadeslayer_> ok,since im using source format v3 i dont need a watch file right?
[16:43] <Rhonda> What has watch file to do with source format v3?
[16:43] <shadeslayer_> Rhonda: well i was advised not to use get-orig-source in rules,so im asking if i need a watch file
[16:44] <Rhonda> watch file is about getting notifications about new upstream versions. I have no idea why this should be obsoleted with source format v3
[16:44] <shadeslayer_> ok
[16:44] <Rhonda> not use get-orig-source? Why not?
 shadeslayer_: have you thought about using v3 source format? that way you could use the upstream tar.bz2 as is (v3 gives you "You don't have to repack the upstream tarball to strip the debian directory." for free)
[16:45] <tumbleweed> shadeslayer_: sounds sensible ^
[16:46] <shadeslayer> tumbleweed: ok.. so dont use get-orig-source,but i do need to add watch file
[16:46] <tumbleweed> shadeslayer: you always should have a watch file
[16:46] <tumbleweed> (unless upstream doesn't have tarballs of any form)
[16:47] <shadeslayer> ok
[16:50] <Rhonda> shadeslayer: But from what I understand get-orig-source isn't only about repacking the upstream source but fetching too.
[16:52] <Rhonda> Especially repacking usually doesn't produce the same hash, or do I completely misunderstand the target?
[16:52] <Rhonda> repacking again, that is
[17:00] <shadeslayer> Rhonda: do we prefer a patch system or can the patches be inline?
[17:02] <Rhonda> Who is we - and I don't get your question.
[17:02] <shadeslayer> Rhonda: we == Ubuntu packagers?
[17:03] <Rhonda> patch system is always preferred to have the patches seperated
[17:04] <shadeslayer> hmm ok
[17:14] <shadeslayer> Rhonda: hmm : dpkg-source: error: LC_ALL="C" LANG="C" patch -s -t -F 0 -N -p1 -u -V never -g0 -E -b -B .pc/01_kubuntu_translate_patch.patch/ gave error exit status 1
[17:17] <shadeslayer> more info http://pastebin.com/thnErWSu
[17:23] <shadeslayer> btw i dont need : opts=dversionmangle=s/\+ds// \ since im not repacking source now,right?
[17:23] <shadeslayer> im debian/watch
[17:24] <shadeslayer> *in
[17:39]  * shadeslayer wonders who will answer
[18:05] <tumbleweed> shadeslayer: correct (my quiz was cancelled)
[18:05] <shadeslayer> tumbleweed: idk if i should be happy or sad :P
[18:06] <shadeslayer> tumbleweed: ok,i have a patching error
[18:07] <shadeslayer> tumbleweed: http://shadeslayer.pastebin.com/qLULztwE
[18:07] <shadeslayer> if i use patch -p0 <mypatch.patch , it works
[18:08] <shadeslayer> hmm.. hold on .. i think i have to add the patch system to rules
[18:09] <tumbleweed> shadeslayer: quilt patches should be p1
[18:12] <shadeslayer> tumbleweed: anyways.. any idea what i should add in debian/rules to enable patches?
[18:12] <tumbleweed> with source format 3, nothing. it happens automatically on dpkg-source -x
[18:13] <shadeslayer> any idea on the error then?
[18:17] <tumbleweed> shadeslayer: 19:09 < tumbleweed> shadeslayer: quilt patches should be p1
[18:18] <shadeslayer> tumbleweed: no so what do i do to correct it :P
[18:18] <tumbleweed> shadeslayer: do you know that the -p flag does?
[18:24] <shadeslayer> tumbleweed: no
[18:25] <tumbleweed> it's the number of directories to strip off the front of every path in the patch file
[18:25] <shadeslayer> ah ok
[18:25] <shadeslayer> so i guess my patch is bad?
[18:26] <shadeslayer> tumbleweed: http://pastebin.com/upWBzryf
[18:27] <tumbleweed> that's a simple patch, so you can just manually edit it. Add something random to the beginning of each path. i.e. a/ and b/
[18:28] <shadeslayer> tumbleweed: w00t
[18:28] <shadeslayer> building in pbuilder and will upload
[18:30] <tumbleweed> shadeslayer: while you are waiting, look at this: http://dep.debian.net/deps/dep3/
[18:31] <shadeslayer> ok
[18:32] <shadeslayer> tumbleweed: thanks for all the help ;)
[18:37] <shadeslayer> tumbleweed: i fixed this issue earlier,but dont remember now : http://shadeslayer.pastebin.com/7gVvaLVK
[18:37] <shadeslayer> how to fix it
[18:41] <tumbleweed> shadeslayer: so, where does the contents of the .changes file come from?
[18:42] <shadeslayer> tumbleweed: uh.. from debuild?
[18:43] <tumbleweed> no, I mean where does it get the contents that it puts in there from?
[18:44] <geser> Changed-By is the from the last changelog entry
[18:44] <shadeslayer> tumbleweed: hmm.. debian/changelog
[18:44] <tumbleweed> shadeslayer: so, look at that error, and the changelog, and see if you can see why you are getting it
[18:45] <shadeslayer> hmm... cant see why its giving that
[18:46] <tumbleweed> how is your change signed off in the changelog? paste that line
[18:46] <geser> can you paste the line from your changelog entry beginning with " --"?
[18:49] <shadeslayer> geser:  -- Rohan Garg<EMAIL_ADDRESS>Tue, 22 Jun 2010 20:56:42 +0530
[18:50] <geser> hmm
[18:51] <shadeslayer> geser: ill remove the changelog and create a new one
[18:58] <shadeslayer> geser: is it necessary to do dep3 ?
[19:00] <geser> it's no requirement, but it has some advantages and some people like to see the dep3 headers on patches
[19:01]  * shadeslayer doesnt want to do more additions/changes  :P
[19:02] <shadeslayer> geser: and its still complaining about the chages
[19:02] <shadeslayer> *changes
[19:02] <geser> hmm
[19:08] <shadeslayer> geser: im uploading it,i think lintian has gone mad :P
[19:08] <shadeslayer> apart from that there are other lintian errors that can be ignored.. binary without manpage stuff....
[19:15] <shadeslayer> geser: http://revu.ubuntuwire.com/details.py?upid=8334
[19:15] <shadeslayer> tumbleweed: ^^
[19:19] <RainCT> didrocks: Hey
[19:20] <RainCT> didrocks: I've created https://code.edge.launchpad.net/~zeitgeist-packagers
[19:21] <sebner> RainCT: tell him to switch to dh7 or I'm gonna cry :P
[19:21] <RainCT> sebner: lol. It is hd7 in Debian :)
[19:21] <RainCT> *dh7
[19:21] <sebner> didrocks: don't be such a backboy and sync with Debian!
[19:21]  * sebner hugs RainCT
[19:21] <sebner> *badboy even
[19:21] <sebner> xD
[19:22] <RainCT> sebner: Don't you have something more interesting to do than to check whether packages use dh7 or not? ;)
[19:23] <sebner> RainCT: pfff, don't be mean, I noticed the 0.4 upload to maverick and since it's your baby I took a look :P
[19:23] <RainCT> :)
[19:27] <didrocks> sebner: I've proposed to comaintained in Debian :)
[19:27] <didrocks> RainCT: thanks for the team btw
[19:28] <sebner> didrocks: cool .. then you are forced to use dh7 too \o/ :P
[19:28] <didrocks> sebner: well, I used dh7 for some packages. Knowing that I'll synced soon zg again with debian, (0.4.1 I hope), I didn't investigate on the merge now :)
[19:28] <RainCT> didrocks: Np, thanks for your help :)
[19:29]  * RainCT hopes sebner doesn't remember that half of my packages still use CDBS :P
[19:30] <didrocks> RainCT: btw, if you are not aware: bug #597687
[19:30] <didrocks> well, cdbs isn't so bad :)
[19:31] <RainCT> Yeah, it rocks (until it fails awfully and you don't know why :)). But dh7 is much nicer.
[19:31] <sebner> didrocks: hahaaha, good joke. Haven't laughed that much in a while :D
[19:31] <sebner> RainCT: I do ;)
[19:31] <RainCT> dkd
[19:32] <RainCT> * didrocks: Yep seen the MIR. Awesome :D.     Although now this is my second package moving into main :/
[19:33] <didrocks> RainCT: you're not a core-dev? you should upload for per package upload
[19:33] <didrocks> apply*
[19:33] <didrocks> sebner: really, GNOME lives with it for so long :)
[19:34] <didrocks> sebner: it just habits, most of the time, but yeah, dh7 is clean
[19:34] <sebner> didrocks: one of the most sad things, right
[19:34] <didrocks> sebner: we have also to do port the strip translations/desktop.in to dh7
[19:35] <didrocks> but in any case, we will just follow debian packaging, won't create a diff on merge for that
[19:35] <sebner> didrocks: heh, nice. Long long time ago I also wanted to get involved with gnome-packages. After looking at the packages, especially the rules file I decided: "Before I touch this, I'm gonna die" :P
[19:36] <RainCT> By the way, is there anyone maintaining DistUtilsExtra?
[19:36] <didrocks> sebner: that's because you looked at gtk or glib :-)
[19:36] <sebner> didrocks: pff, cdbs is cdbs. I just tell what's going on there and that scares me
[19:36] <didrocks> RainCT: well, pitti is doing it most of the time, I still push some patchs from time to time and want to find more for annoying issues
[19:36] <sebner> *can't tell
[19:37] <RainCT> didrocks: I have a couple patches filed against the upstream project which are feeling very lonely :)
[19:37] <didrocks> sebner: did you look at unity packages? they are not so complicated
[19:37] <didrocks> RainCT: oh really?
[19:37]  * didrocks opens the project view
[19:38] <RainCT> Yep, not sure what they where though. I'd probably have some more but since those got ignored I didn't bother.
[19:39] <didrocks> RainCT: you are talking about bug #510957 ?
[19:39] <sebner> didrocks: that's true but still ..
[19:39] <didrocks> (just seeing this one)
[19:40] <didrocks> sebner: for instance, we will in gnome run autoreconf for most of our package, it's one line in cdbs, I should have a look at how to do that in dh7
[19:40] <RainCT> didrocks: Yup that's one (some Gentoo guy was asking us to move GNOME Activity Journal to autotools because of that -.-), the other is #503026 but I see it isn't a patch just the idea; I can write one if you're going to include it though
[19:41] <RainCT> And I'll try to remember what the other stuff was ;)
[19:41] <didrocks> RainCT: LINGUAS can be an environment variable too it seems?
[19:52] <tumbleweed> shadeslayer: those two patches should be combined into one
[19:52] <tumbleweed> they're the same thing
[19:53] <shadeslayer> tumbleweed: ok.. btw im doing some more work :)
[19:53] <shadeslayer> on the package...
[19:53] <tumbleweed> bonus points for a DEP3 header
[19:53] <shadeslayer> hehe :)
[19:53] <shadeslayer> will do :P
[19:54] <shadeslayer> tumbleweed: any other issues?
[19:54]  * tumbleweed looks
[19:55] <shadeslayer> still have no idea why im getting the changes issues
[19:55] <tumbleweed> description is a bit weird
[19:56] <shadeslayer> tumbleweed: yeah correcting that as well :P
[19:56] <shadeslayer> modified debian/docs as well
[19:56] <tumbleweed> btw quilt patches don't need numbers, the order is defined by debian/patches/series
[19:56] <shadeslayer> tumbleweed: ah ok..
[19:57] <shadeslayer> tumbleweed: watch file isnt working for now :P
[19:59] <tumbleweed> shadeslayer: not that it matters, but you forgot to escape the final . in the watch file
[19:59] <shadeslayer> tumbleweed: uh.. what?
[19:59] <tumbleweed> it's a regex, so a literal . should be written as \.
[20:00] <shadeslayer> tumbleweed: http://qipmsg.googlecode.com/files/qipmsg-(.*)\.tar.bz2
[20:00] <tumbleweed> http://qipmsg.googlecode.com/files/qipmsg-(.*)\.tar\.bz2
[20:00] <NorthernLights> Hello all
[20:00] <shadeslayer> ah
[20:00] <shadeslayer> NorthernLights: hi
[20:01] <tumbleweed> shadeslayer: you probably want to use http://googlecode.debian.net/p/qipmsg/qipmsg-(.*)\.tar\.bz2
[20:01] <shadeslayer> tumbleweed: thats a 404
[20:01] <RainCT> didrocks, sebner: Sorry, my network card was being stupid. What did I miss?
[20:02] <tumbleweed> shadeslayer: that's not how watch files work. read uscan's man page
[20:02] <tumbleweed> shadeslayer: http://googlecode.debian.net/p/qipmsg does not 404
[20:02] <didrocks> RainCT: nothing, I saw that you quit :) I've merge your LINGUAS change btw
[20:02] <didrocks> sorry it took so long
[20:02] <sebner> RainCT: nothing (?) , my network broke down too xD
[20:02] <RainCT> lol
[20:02] <RainCT> didrocks: Cool thanks.
[20:02] <didrocks> oh, that's why it was so quiet :)
[20:02]  * didrocks kidding
[20:02] <didrocks> RainCT: you're welcome, thanks for the patch
[20:02] <shadeslayer> tumbleweed: ah ok
[20:03] <tumbleweed> NorthernLights: I see you posted your synergy+ to<EMAIL_ADDRESS>did you subscribe to the mailing list? (you got at least one reply)
[20:04] <NorthernLights> yep
[20:04] <NorthernLights> I answered
[20:04] <NorthernLights> and invited upstream to comment on it
[20:04] <tumbleweed> NorthernLights: good answer. I was hoping someone would ask you that question
[20:08] <tumbleweed> shadeslayer: oh, um, any reason why you ignored W: qipmsg: extra-license-file usr/share/doc/qipmsg/Copying.txt.gz
[20:08] <shadeslayer> tumbleweed: i removed that
[20:08] <shadeslayer> from debian/docs
[20:08] <tumbleweed> cool
[20:08] <shadeslayer> im sure of it
[20:09] <shadeslayer> no i mean i removed it before the upload
[20:11] <didrocks> nigelb: do you want to rebase the debdiff you posted for bug #111939 or could I just integrate the patch?
[20:11] <didrocks> nigelb: I can do it very quickly, so if you don't mind, I can just copy mcclasen patch and rebase to the last version
[20:16] <shadeslayer> tumbleweed: btw the 2 patches modify 2 different files
[20:16] <shadeslayer> how do i combine them?
[20:17] <tumbleweed> shadeslayer: but they depend on each other. They exist to fix the same problem
[20:17] <shadeslayer> tumbleweed: how do they depend on each other
[20:20] <tumbleweed> shadeslayer: one corrects a spelling mistake, one corrects the translation for the same spelling mistake
[20:21] <shadeslayer> ah
[20:22] <tumbleweed> shadeslayer: hint: it's the upstream's makefile that's installing Copying.txt it also installs another file you don't need
[20:24] <geser> shadeslayer: why not make 1 patch from those two?
[20:25] <fabrice_sp> Is there a page somewhere with the number of package I sponsored?
[20:25] <geser> not that I know of
[20:25] <tumbleweed> geser: yeah that's what I'm suggesting he do
[20:26] <fabrice_sp> geser, ok. I'll check with the launchpad API, because it seems that the data is there
[20:27] <tumbleweed> fabrice_sp: btw, did you read zaytsev's reasoning in Bug #565826
[20:27] <fabrice_sp> tumbleweed, nop. Let me check
[20:28] <geser> fabrice_sp: I guess you would be faster with greping the -changes archive for your name in Signed-By
[20:29] <fabrice_sp> geser, I did that, but actually, I also got all packages I uploaded, and not only the ones I sponsored
[20:30] <fabrice_sp> someone made some script to extract the same info from udd for Debian
[20:30] <fabrice_sp> tumbleweed, what is your opinion about keeping or not the patch? It seems that it can be dropped
[20:30] <fabrice_sp> but the bug report was really that people anted mcedit to be the default at intall time
[20:31] <tumbleweed> fabrice_sp: yeah. it'll irritate the odd person, but they can change it at least
[20:31] <fabrice_sp> s/anted/wanted/
[20:31] <fabrice_sp> tumbleweed, yeah: it doesn't seems to be worth keeping the diff
[20:32] <tumbleweed> ok, I'll ack it
[21:07] <Rhonda> shadeslayer: dversionmangle=s/\+ds// removes the string +ds from the Debian version for comparison. Not sure what that would represent, might be debian source, and then it's only used when stuff got removed from the tarball, not for a simple repack from .tar.bz2 to .tar.gz or similar.
[21:14] <tumbleweed> Rhonda: "debian source" yes
[21:17]  * NorthernLights still tries to ask for a REVU review ;)  . For packages synergy-plus and kill-rogues. Thanks!
[21:17] <NorthernLights> s/kill-rogues/killrogues
[21:18] <tumbleweed> NorthernLights: not waiting to see whether the merge-into-synergy route will work out?
[21:26] <NorthernLights> tumbleweed, i don't how that will go but i'd still like to know what's my package worth.
[21:27] <tumbleweed> looks like that won't be quick anyway...
[21:27] <NorthernLights> yep
[21:27] <NorthernLights> if it goes into a lenghy conversation with synergy author i'll say that proves we need synergy+, even if temporarily
[21:28] <NorthernLights> we still can make a transitional package of synergy laster
[21:28] <Rhonda> tumbleweed: Never had the need to do that, gladly. :)
[21:28] <NorthernLights> later
[22:09] <micahg> is there a trick for regenerating a control file for another version of Ubuntu from Lucid (i.e. w/a debian/control target in debian/rules) or do you need to be in a chroot?
[22:10] <tumbleweed> micahg: generating control files from rules is ugly
[22:10] <soren> micahg: There's nothing version specific in debian/control.
[22:11] <tumbleweed> the version comes from changelog
[22:11] <micahg> soren: there's a control.in file
[22:11] <micahg> I was just wondering if this is a general thing or more specific to the pacakge I'm working with openjdk
[22:12] <tumbleweed> micahg: what problem are you trying to solve?
[22:13] <micahg> tumbleweed: I need to regenerate the control file for jaunty and karmic from the lucid build (it's possible, I just don't know how)
[22:13] <soren> micahg: ...which generates a control file which doesn't have anything series specific in it.
[22:13] <micahg> soren: yes, but what needs to be in there *is* series specific due to stuff in debian/rules
[22:14] <soren> micahg: The only reference to series is in the changelog and the changes file.
[22:14] <ajmitch> different xulrunner dependencies?
[22:14] <micahg> soren: nm, I'll just go ask dokko
[22:14] <micahg> *soko
[22:14] <micahg> *doko
[22:14] <soren> micahg: Can you explain what it is that needs to vary depending on series?
[22:16] <anoteng> anybody know if dh_python2 is in maverick?
[22:16] <micahg> soren: http://bazaar.launchpad.net/~openjdk/openjdk/openjdk6/annotate/head:/rules
[22:17] <tumbleweed> anoteng: not yet
[22:17] <anoteng> mkay, guess I'll have to install sid then…
[22:18] <soren> micahg: Yikes.
[22:18] <soren> micahg: That's all I have to say.
[22:18] <micahg> soren: right :)
[22:19] <ScottK> anoteng: It's only partly in.  It will be shortly.
[22:43] <jono_> Laney, ping?
[22:49] <gaston_> can anyone tell me where can I find the .deb files naming convention?
[22:50] <gaston_> I can't find it in the MOTU wiki, thank you
[22:54] <tumbleweed> gaston_: the debian policy manual covers some of it
[22:59] <gaston_> ok, found that, thanks
[23:31] <jono> Laney, ping?


[00:06] <dtchen_> welp, Friday night seems as good a night as any to have an impromptu session: 1) on triaging Karmic sound bugs; 2) on the way forward in Lucid
[00:06] <dtchen_> (so, as I don't suspect anyone's really lurking, this will just be a braindump to go on the bugsquad/debugging wiki)
[00:07] <dtchen_> ** So, firstly, triaging Karmic sound bugs **
[00:07] <dtchen_> Probably the most important page anyone can reference is https://wiki.ubuntu.com/DebuggingSoundProblems/KarmicCaveats
[00:08] <dtchen_> Just about anyone experiencing sound problems in Karmic should be directed to read that page first, then seek assistance using either the #ubuntu-bugs irc channel here on Freenode or by using https://answers.launchpad.net
[00:09] <dtchen_> Very briefly, I'll summarise some of the points that I first mentioned in my blog post and which were later nicely written up by David H
[00:09] <dtchen_> A) By far the most common problem in dist-upgrades from Jaunty to Karmic has been "the case of the missing Karmic kernel in the grub boot menu"
[00:10] <dtchen_> There are ongoing efforts to diagnose precisely what's causing this symptom. What's complicating matters is that some people appear to have manually modified their grub configuration file (grub.cfg/menu.lst), so there isn't one approach to catch all culprits.
[00:11] <dtchen_> If, however, as a triager or reporter, you see that the bug report mentions that you're running 9.10 (Karmic) but running a non-2.6.31-based kernel, and you *know* that you dist-upgraded from 9.04 (Jaunty) without having messed with grub or kernels, then go ahead and file the bug, then triage the bug to affect the grub source package.
[00:13] <dtchen_> B) A lesser severity (but no less annoying) issue lies in how Ubuntu Karmic's PulseAudio handles softmodem and softMIDI applications.
[00:14] <dtchen_> I need to emphasize that usually the bug reporter is not at fault in choosing to install the packages sl-modem-daemon or timidity.
[00:14] <dtchen_> (Normally System > Administration > Hardware Drivers, better known as Jockey, offers/suggests to install the modem driver if the hardware is discovered.)
[00:16] <dtchen_> What usually happens is that the user has one or more of the sl-modem-daemon or timidity packages installed, and as both of these are not natively-PulseAudio aware (but instead speak directly to ALSA), the user encounters the classic race of "who can grab the sound device first?"
[00:18] <dtchen_> The culprit is actually PulseAudio's module-udev-detect module, which skips an entire ALSA hw: device once it encounters a softmodem. This is a bug in the pulseaudio source package, but it has not been resolved upstream yet. We're discussing ways to work around this symptom properly, but it touches more than just PA -- alsa-driver/linux is also involved.
[00:19] <dtchen_> C) Yet another bug people are encountering is the "omg volume too loud/distorted/kills kittens" symptom, which boils down to one of two sources:
[00:20] <dtchen_> --> alsa-driver/linux is misreporting the sound device's dB range, so PA either happily accepts this absurdity or flails and uses its own calculated range
[00:20] <dtchen_> --> your sound hardware is good and truly fscked
[00:21] <dtchen_> (That isn't to say that both can't be applicable simultaneously...)
[00:22] <dtchen_> D) Some people with higher-end (non-HDA; ICE17xx-driven) sound cards are encountering an alsa-lib bug where the "front:" virtual definition incorrectly lacks the proper number of channels.
[00:22] <dtchen_> As a result, when PA queries alsa-lib, it gets nonsense back and simply skips the sound device.
[00:23] <dtchen_> So, right above I've summarised the four major (A, B, C, D) bug classes I've been triaging in these weeks since Karmic released.
[00:24] <dtchen_> A question that ultimately is raised is "How can we automate this triaging? Bug patterns? etc."
[00:25] <dtchen_> That's a very good question, and a few of us (Brad, Luke, David H, and I) are discussing how to best hook these processes into apport and checkbox.
[00:25] <dtchen_> ** Next, the way forward in Lucid **
[00:26] <dtchen_> Since I will not be attending UDS-L, we've already been discussing what to do about the massive volume of user experience snafus when it comes to audio in Ubuntu.
[00:27] <dtchen_> A) Firstly, on the hardware enablement (alsa-driver/linux) front, we will be rolling either weekly or daily builds of the stable alsa-driver snapshots from upstream ALSA.
[00:28] <dtchen_> For Karmic, we're having quite good experiences with linux-backports-modules-alsa-karmic-generic [for desktops], because this package (well, linux-backports-modules-alsa-2.6.31-xx-generic) contains a much newer alsa-driver from 20091012.
[00:29] <dtchen_> (The real grunt work was done by Tim (rtg) and Andy (apw), so buy them beers!)
[00:30] <dtchen_> Since much of my hardware enablement efforts will be upstream this cycle, having these weekly/daily builds will allow early Lucid testers with *extremely* new HDA hardware to be able to help track and fix regressions.
[00:32] <dtchen_> B) Secondly, similar to the USB testing images that were used during Karmic's development cycle at Linux conferences, the kernel team will be doing something similar with the above weekly/daily snapshots. In this fashion, we'll have checkbox run on a lot of bare metal, which always helps.
[00:33] <dtchen_> C) Luke and I have agreed to freeze as much of the sound stack as early as possible, which probably means that we won't be shipping anything newer than ALSA* 1.0.22 (presuming it is released soon enough).
[00:33] <dtchen_> Now, this point is actually up for discussion at UDS-L, so my words above need to be taken with a grain of salt.
[00:34] <dtchen_> D) We're still a long way from getting everything properly integrated with PulseAudio. Even applications such as timidity should be configured to use libao instead of ALSA directly, because it's much easier to tell /etc/libao.conf to use pulse as its backend.
[00:34] <dtchen_> (And that's just one application)
[00:35] <dtchen_> E) Jack Audio Connection Kit will be in main for Lucid, which should finally lay to rest some w(e)ariness.
[00:35] <dtchen_> ** End notes **
[00:39] <hggdh> dtchen_: are you going to save this?
[00:39] <pleia2> hggdh: I'll link the logs link to the classroom wiki
[00:40] <hggdh> thank you, pleia2.
[00:41] <dtchen_> ok, good, because I was having a bear of a time copying, pasting, pg-down, copying, ...
[00:47] <nhandler> Logs from this channel are also available on irclogs.ubuntu.com automatically
[00:56] <dtchen_> linked from https://wiki.ubuntu.com/Classroom
[22:45] <qwebirc10414> i need help please


[12:05] <Guest74> Can someone assist me please , with Ubuntu 22.04 , with MATE I only have Powersave and High Performance modes , with GNOME I have Balanced
[12:05] <Guest74> but I just don't like GNOME
[12:06] <Guest74> Is there something that I am misssing?
[12:49] <Guest74> Anyone can help me with Ubuntu MATE power modes?
[13:06] <sixwheeledbeast> where are you looking at these schedulers?
[13:16] <Guest74> from cpu frequency scaler
[13:16] <Guest74> and also from here
[13:16] <Guest74> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
[13:17] <Guest74> but other desktops like default ubuntu and kde , can bring balanced from same laptop
[13:17] <Guest74> Intel® Core™ i5-10210U CPU
[13:29] <sixwheeledbeast> do you have cpufrequtils to check?
[13:31] <sixwheeledbeast> it may use intel-pstates driver. I have never come across it before I have no Intel CPUs
[13:31] <Guest74> sudo install cpufrequtils ?
[13:31] <Guest74> sudo apt install *
[13:32] <sixwheeledbeast> cpufreq-info --driver
[13:33] <sixwheeledbeast> if it is intel-pstates maybe try with "intel_pstate=disable" kernel flag?
[13:33] <Guest74> yes intel_pstate
[13:34] <Guest74> how cani i try that?
[13:35] <sixwheeledbeast> https://wiki.ubuntu.com/Kernel/KernelBootParameters
[13:35] <Guest74> but i doubt it';s the kernel
[13:35] <Guest74> it's MATE
[13:36] <Guest74> because in the same installation , i will just download GNOME or KDE , and boom I have balanced option
[13:37] <Guest74> the kernel didn't change
[13:39] <sixwheeledbeast> well to prove it, check driver with gnome
[13:40] <Guest74> hmmm i see what you mean , ok will try
[13:41] <Guest74> you ar eright
[13:41] <Guest74> check here
[13:41] <Guest74> https://www.percona.com/blog/2016/05/06/cpu-governor-performance/
[13:52] <Guest74> sixwheeledbeast, you just fixed a problem for me that lasted for long time
[13:52] <Guest74> thank you
[13:52] <sixwheeledbeast> np
[13:53] <Guest74> I edited it to this GRUB_CMDLINE_LINUX_DEFAULT="intel_pstate=disable"
[13:54] <Guest74> it was like this
[13:54] <Guest74> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
[13:54] <Guest74> is it ok ?
[14:19] <sixwheeledbeast> you'll get boot output instead, i prefer that.


[03:31] <hyperair> vish: turns out indicator-messages is causing my memleaks after all.
[03:32] <hyperair> http://people.ubuntu.com/~hyperair/massif-output
[03:32]  * hyperair installs dbgsyms for indicator-messages and tries again
[04:36] <LoverBoyV> Hello all.
[05:47] <hyperair> vish: oho! i've found my bug!
[05:47] <hyperair> vish: it happens when indicator-messages needs to resize icons
[05:47] <hyperair> it resizes the pixbuf, and doesn't free the original
[07:15] <vish> hyperair: why is it resizing icons?
[07:21] <hyperair> vish: i guess it's because some apps send larger than necessary icons over dbus?
[07:28] <hyperair> hmm 32M after 1 hour and 15 minutes
[07:28] <hyperair> vish: how much memory does indicator-applet usually use?
[07:28] <hyperair> i think there might be some issues with strdup on a long run, but haven't identified them yet.
[07:29] <vish> hyperair: 6.9M after 1d10h
[07:29] <hyperair> huh what
[07:29] <vish> err, 6.2
[07:29] <hyperair> that's ridiculously small
[07:29] <hyperair> i guess i should stick my massif script back in.
[07:29] <hyperair> vish: are you using the default theme or the elementary theme?
[07:30] <vish> hyperair: well, a tweaked version of the default
[07:30] <hyperair> ah i see.
[07:30] <hyperair> i'm using the elementary =\
[07:30] <hyperair> which probably gave higher-res icons than usual to indicator-applet, causing it to leak
[07:30] <hyperair> but i wonder what's going on now
[07:31] <vish> i doubt that..
[07:31] <hyperair> oh well i'll wait for another day or so
[07:31] <vish> hyperair: switch the them and check..
[07:31] <vish> theme*
[07:31] <hyperair> but i don't like the default theme =\
[07:31] <hyperair> and i'll have to bear with it for a day or so
[07:31]  * hyperair sighs
[07:32] <vish> hyperair: pff! 1h15min is not too long to test it.. ;p
[07:32] <hyperair> vish: hmph. maybe some other time. =p
[07:32] <hyperair> for now i'll just observe how far it rises, and then run massif again
[08:27] <hyperair> hmm 43M and 2 hours.
[08:27] <hyperair> it's still leaking.
[10:57] <coz_> good day


[19:19] <cjwatson> Laney: please pull the transition-tracker branch
[20:44] <Laney> cjwatson: righto
[21:37] <cjwatson> ta
[21:38] <Laney> looks easy ;-)
[21:39] <cjwatson> yeah
[21:40] <cjwatson> I may be turning into a slight NBS obsessive
[21:41] <Laney> there are worse things to be obsessed with than archive health
[21:42] <Laney> currently i'm obsessed with f5ing nm.d.o
[21:44] <cjwatson> meant to be RSN, eh?
[21:45]  * cjwatson remembers that phase ...
[21:46] <cjwatson> (actually, *that* bit was short in my case, it was the two AMs who vanished on me that slowed things down)
[21:46] <cjwatson> the DAM approval stage was 10 hours or so ;-)
[21:47] <Laney> it's "how soon can you get enrico involved"
[21:47] <cjwatson> it was tbm in my day
[21:47] <cjwatson><EMAIL_ADDRESS>[21:51]  * cjwatson tries to work out why dvbstreamer is missing its shlibdeps
[21:53] <cjwatson> ... also missing its binaries, well that explains that part ...
[22:00] <Laney> your tin anniversary has passed :-)
[22:01] <Laney> alioth being down is irritating, maybe i'll join the nbs-fest
[22:02] <cjwatson> heh, yeah
[22:02]  * cjwatson fixes dvbstreamer
[22:07] <cjwatson> poked the Debian bug for multiwatch to see if I can help with sponsorship
[22:10] <cjwatson> and uploaded everything else for libev
[22:11] <cjwatson> ocaml is done aside from the llvms


[09:14] <ren0v0> hi, can someone tell me where LXD images are stored when you run  "lxc publish" ?
[12:51] <teward> I need some update/upgrade opinions.  Got an ancient 8.04 box that we've scheduled for migration to a newer OS, but we've got limited time, and not enough time to install clean 14.04 and then migrate everything.  Would a sane solution be to, for now, upgrade the box to 12.04 in place after taking a backup of the machine, and then in the summer when we have our next maintenance period (and two - three months to complete the update instead of
[12:51] <teward> two weeks), do the clean 14.04 install and migrate data over?
[12:51] <teward> or would it be more sane to start fresh anyways
[12:55] <maxb> I don't think anyone can suggest anything without knowing more about what migration means to you
[12:55] <jelly> don't you need to do release upgrades 8.04 -> 10.04 -> 12.04, going from hardy to precise directly would not be supported?
[12:56] <teward> jelly: well, i meant that :P
[12:56] <teward> maxb: that's up to the people above me in the pay chain :/
[12:56] <teward> and they said "Research potential courses of action, present them today"
[12:56] <teward> so :/
[12:56] <maxb> For example, it's unclear to me why you'd have time to upgrade some versions but not all the way to 14.04
[12:57] <jelly> it's hard to say what might break without knowing what services and apps you're actually running there, and which infrastructure (database, language versions) they depend on
[12:58] <jelly> right, going up to 12.04 and fixing everything, but not 14.04 seems somewhat arbitrary
[12:58] <maxb> Indeed. The practicality of in place upgrade varies widely depending on what services you're running, and how long they can be down whilst you deal with any oddities such as configuration changes that end up being needed
[12:59] <jelly> teward: see if you have... time to clone the machine into a VM, then test your desired course of action
[13:01] <maxb> We also need to know your uptime requirements - because if you're aiming for minimal downtime you'd be a lot safer just building out a replacement
[14:37] <tansy> Hi Guys,, anyone knows if i can change device name from /dev/sda to  /dev/sdb
[14:37] <tansy> ?
[14:38] <teward> jelly: that's actually my plan there xD
[14:38] <teward> (to clone the VM to another VM, and then test the upgrade paths)
[14:38] <TJ-> tansy: I just answered you in #ubuntu
[14:38] <TJ-> tansy: use the symlinks in /dev/disk/by-*/*
[14:39] <TJ-> tansy: that's the entire point of them; there is by-uuid, by-id, and a couple of useful others
[14:39] <teward> jelly: the main reason to 12.04 and not 14.04 is because we need a 'temporary' solution, and i know one of the things won't run on 14.04 (in-house program)
[14:40] <tansy> Hi TJ... i have 15 raw disks attached to server...
[14:41] <tansy> on 1 disk say /dev/sde my OS is installed.
[14:41] <tansy> but after reboot the name changes..
[14:41] <tansy> i am creating some storage cluster with disk names.
[14:41] <tansy> so i need persistent disk names
[14:41] <TJ-> tansy: right, which is what the persistent naming under /dev/disk/by-uuid/ is designed for
[14:42] <tansy> TJ.. by uuid is only if i create partitions or lvols..
[14:42] <tansy> but raw disks are not under uuid..
[14:43] <TJ-> tansy: then use by-id
[14:43] <TJ-> tansy: in some Ubuntu releases we used to have by-path too
[14:44] <tansy> so TJ the id's are consistens you mean.. and /dev/sd* can change ?
[14:45] <TJ-> tansy: correct, the nodes under /dev/disk/by*/* are symlinks to the actual block device nodes
[14:45] <TJ-> tansy: you could create your own udevd rule to create, for example, /dev/disk/by-serial/<disk-serial-number> sym-links
[14:46] <tansy> yes .. i see
[14:46] <tansy> wwn-0x678da6e715bce5201e04a7afa762365e -> ../../sdq
[14:46] <tansy> lets say after reboot the sdq starts poing to another block disk..
[14:46] <tansy> then what would happen
[14:46] <TJ-> tansy: right, those are the WWN namings so will be unique
[14:49] <tansy> Hi TJ..I got your point..
[14:49] <tansy> i was creating a storage cluster in which i was combinging /dev/sda of 10 nodes in 1 cluster...
[14:49] <tansy> so my script was expecting a single name accross all nodes..
[14:50] <tansy> otherwise it would be quite difficult to manage in my script..
[14:50] <TJ-> so the device presented by the cluster should be consistent? What are you using, iSCSI ?
[14:51] <tansy> yes it should be consistent.
[14:52] <tansy> TJ. i am actually not doing that... my storage colleague is creating ceph cluster and facing issue.
[15:36] <IIT> in installation of ubuntu server..
[15:36] <IIT> it is asking me to select the kernel so i am confused which one to select ?
[15:37] <IIT> by default it's highlighting vivid, which is 15.04 and i am installing linux 14.04.3 so how's that possible ?
[15:37] <IIT> and which kernel to choose ?
[15:50] <IIT> generic, virtula, signed ? which one to select
[15:50] <IIT> what's the difference between each of them
[16:29] <jelly> IIT: I think "vivid" means the "hardware enablement stack" of kernel for your release that's exactly the same version as comes with vivid.  Pick that and generic if you don't know better.
[16:31] <teward> jelly: they got an answer in #ubuntu i believe
[16:37] <jelly> ah.  Usually there's so much traffic there, I don't even bother trying to check
[16:40] <teward> :P
[16:47] <IIT> jelly, thanks for the reply :) yeah i got the point with the help of Pici :)
[16:50] <nacc> rharper: ping
[17:46] <Logos01> Is there any chance anyone here is already using Pulp for repository mirroring?
[18:10] <IIT> for server which repos should i enable ?
[18:10] <IIT> and which one i shouldn't
[18:13] <teward> IIT: that's really your call.  On my servers, I want things to get bug fixes as well as Security fixes, so I keep the -updates and -security repositories enabled
[18:13] <teward> and my applications on there have Universe dependencies, so i enable the Universe repositories too
[18:14] <teward> (but what you should enable is up to you and your needs)
[18:16] <IIT> teward, can you share your sources.list file ?
[18:20] <teward> Not from here I can't, no SSH to my servers
[18:20] <teward> (my keys are unfortunately back at home :/)
[18:22] <IIT> np :)
[18:23] <IIT> anyone who read the msg can share their source.list :)
[18:46] <patdk-wk> hmm, don't care
[18:46] <patdk-wk> share
[18:46] <patdk-wk> just go into your sources.list and edit it
[18:46] <patdk-wk> and if you want security updates, do not enable backtrack
[18:46] <patdk-wk> or backport, whatever it is called :)
[18:50] <IIT> patdk-wk, okay :)
[18:51] <IIT> the prob was when i installed a new ubuntu-server there were no repos listed in sources.list and i was curious to learn different repos meant and started googling out..
[18:52] <patdk-wk> none at all?
[18:52] <patdk-wk> I wonder how you managed that
[18:52] <IIT> yes none
[18:52] <Logos01> patdk-wk: What makes you say that about ${release}-backports vs ${release}-security ?
[18:53] <Logos01> Do they have naming conflicts or something?
[18:53] <IIT> and the cd-rom repo was the single line that too uncommented..
[18:53] <IIT> it was really hard time typing out the long list of all the repos. :/
[18:53] <patdk-wk> -security is security only, not updates
[18:53] <patdk-wk> -updates, not too sure
[18:53] <patdk-wk> -backport is NEW VERSIONS, security updates are not done for these, except by chance
[18:54] <patdk-wk> say like, you need a newer version of dovecot, for a new feature, it might be in backports
[18:54] <patdk-wk> but if there is ever a security issue with it, you are not guarrenteed to ever get that security issue patched
[18:55] <IIT> so it's better not to use backports..
[18:55] <patdk-wk> or only on a package by package bases if you must
[18:55] <Logos01> patdk-wk: Unless it's updated in the later release and backport is renewed.
[18:55] <patdk-wk> or if the server that security doesn't matter
[18:56] <Logos01> Since that's what backports are.
[18:56] <IIT> okay :)
[18:56] <IIT> Logos01, can you share sources.list ? if possible
[18:56] <patdk-wk> Logos01, heh?
[18:57] <patdk-wk> they don't respin everything on newer releases into backports
[18:57] <Logos01> IIT: You probably don't want to copy mine. I do ... stuff, and things.
[18:57] <patdk-wk> https://wiki.ubuntu.com/UbuntuBackports
[18:58] <IIT> just for learning purpose Logos01 :)
[18:58] <Logos01> https://help.ubuntu.com/lts/serverguide/configuration.html
[19:00] <IIT> ideally i should have this enabled ?
[19:00] <IIT> frankly i am going to use ssh and qemu that's it ..
[19:00] <slidinghorn> IIT: Have you come across this answer yet?  http://askubuntu.com/questions/586595/restore-default-apt-repositories-in-sources-list-from-command-line
[19:01] <IIT> slidinghorn, no, this seems to be useful
[19:03] <Jeeves_Moss> do I only need the SNMP daemon if I'm not running the server?
[19:03] <Logos01> patdk-wk: "When a package which has been backported receives a security update, the Ubuntu Backporters will make a best-effort attempt to update the backport."
[19:04] <Logos01> patdk-wk: Most of the times it's pretty automatic.
[19:04] <Logos01> Jeeves_Moss: You need the snmp daemon if you're running a service that uses snmp to communicate with the server.
[19:04] <Logos01> That could for example be a nagios server.
[19:06] <Jeeves_Moss> Logos01, thanks!  that's what I'm looking to do!  I'm just testing right now, then I'll use chef to roll it out
[19:12] <Logos01> Re-asking for consistency's sake and because it's semi-relevant; has anyone here done any groundwork for enabling .deb support in Pulp for their local usage?
[19:18] <micahg> if you don't see a backport request for a relevant security update, feel free to file a new backport request for it
[19:20] <micahg> sorry, I meant to say if you don't see a backport updated in a timely manner, feel free to request a new backport that includes the security update
[21:01] <TJ-> 12.04, apache2, listening on an IPv6 address (confirmed with 'ss' and 'netstat'), ip6tables shows port 80/443 allowed in, but unable to make IPv6 connections from external networks, or even from the host itself. manual 'telnet' connections timeout without connecting. Any ideas?
[21:06] <jrwren> TJ-: do you have a return route?
[21:07] <ianorlin> TJ-: traceroute6?
[21:08] <TJ-> jrwren: ianorlin it fails on the host itself; but route is fine, icmpv6 pings OK
[21:08] <ianorlin> I do not know how to help you then
[21:10] <TJ-> it's puzzling me terribly! ssh on IPv6 is fine too
[21:12] <ianorlin> TJ-: wget -6 ?
[21:13] <TJ-> ianorlin: well telnet fails so wget does too
[21:28] <genii> Maybe only udp forwarding is on
[21:29] <patdk-wk> define ssh is fine
[21:29] <patdk-wk> do you have a pmtu problem?
[21:30] <patdk-wk> mtu issue?
[21:30] <patdk-wk> you didn't block icmp6 did you?
[21:32] <DammitJim> is there a way to install ubuntu and set up LVM?
[21:32] <DammitJim> I"m confused about the installer
[21:36] <Logos01> DammitJim: I ran into that problem, sort of, just recently -- the installer had a serious hate-on for my LVM config.
[21:36] <Logos01> Had to do a manual install, which was all sorts of headache.
[21:37] <Logos01> TJ-: is there anything in sysctl -a | grep -i tcp that might indicate ipv6 is disallowed?
[21:37] <Logos01> TJ-: Also, are you getting any DEN errors in dmesg/auditd ?
[21:37] <DammitJim> so, i need to do a manual partition?
[21:38] <DammitJim> it doesn't revert the stupid thing
[21:38] <TJ-> Logos01: ssh/icmpv6 are all working fine
[21:38] <Logos01> TJ-: That doesn't answer my question.
[21:38] <DammitJim> I am installing now, but I let the system do LVM automatically
[21:38] <Logos01> DammitJim: I'm not saying that -- I'm saying that *I* wound up doing what I did.
[21:38] <DammitJim> oh
[21:40] <DammitJim> Dammit... I"m such an idiot
[21:40] <DammitJim> I was installing ubuntu desktop
[21:41] <TJ-> IPv6/Apache diags/config: http://paste.ubuntu.com/14132555/
[21:41] <Logos01> ...
[21:42] <Logos01> TJ-: Is there anything in "sysctl -a | grep -i tcp" or "dmesg | grep DEN" that might appear to be related to your http traffic?
[21:47] <TJ-> Logos01: no, nothing
[21:49] <Logos01> TJ-: So in your netstat and iptables output I see that traffic is hitting the port and that there's actually a daemon listening.
[21:49] <RoyK> Logos01: you have to do manual installation with existing lvm setup
[21:49] <TJ-> Logos01: correct; although the port 80 count is not increasing, and nor is my remote host count for 2a02:8011:2007::/48
[21:50] <Logos01> TJ-: what happens when you run "tail -f /var/log/apache2/*.log & curl -X HEAD http://::1"
[21:50] <Logos01> Err, sorry, that'd be curl -X HEAD -i
[21:50] <TJ-> Logos01: no such logs; its vhosts; each domain under /home/<domainname>/logs/ for that
[21:50] <RoyK> TJ-: erm - are you using a /48 mask for a host?
[21:50] <TJ-> RoyK: /64
[21:50] <RoyK> makes more sense :P
[21:51] <Logos01> TJ-: "17  1360 ACCEPT     tcp      eth0   *       ::/0                 ::/0                 tcp dpt:80 /* HTTP *"
[21:51] <Logos01> Shows 17 unique connections historically having hit.
[21:52] <TJ-> more configs: http://paste.ubuntu.com/14132647/
[21:52] <Logos01> The established connections would go to the "state RELATED,ESTABLISHED", right, so you wouldn't see packet increases except for unique connection attempts.
[21:52] <Logos01> As to the /home/<domainname>/logs/
[21:52] <Logos01> ... why in the hell would you do that?
[21:52] <Logos01> Logfiles shouldn't go to /home/
[21:52] <TJ-> Yes, they should
[21:53] <RoyK> no, they shouldn't
[21:53] <TJ-> apache2 is using suexec, each domain is a separate user account, and the server spawns a separate process for each uid
[21:53] <Logos01> RoyK: Yeah, I didn't want to but the desktop installer wouldn't let me do anything but /boot and a single logvol for /
[21:53] <Logos01> RoyK: Which is quite the opposite of CIS compliance.
[21:54] <Logos01> TJ-: ... even so, daemons should not log to /home
[21:54] <RoyK> Logos01: in his setting, it makes sense
[21:54] <Logos01> Case in point; where are the logfiles for the global/parent daemon itself?
[21:55] <TJ-> Logos01: the 'daemons' are running as the user itself
[21:55] <TJ-> that's the point of apache's suexec
[21:55] <Logos01> ...
[21:55] <Logos01> Where are the logfiles for the global/parent daemon itself?
[21:56] <Logos01> Furthermore; doesn't matter that the individual domains' workers are running as a specific user; they should still be logging in FHS-compliant manner, tbqh.
[21:57] <TJ-> Logos01: the usual place; and there's nothing in error.log or suexec.log indicating an issue. This was working fine for years, until about 3 hours ago, when there was a minor change in a site config that required a service restart. I suspect some recent package updates have caused this, since the service had been running for several months before that
[21:57] <Logos01> And does apachectl configtest return anything problematic?
[21:58] <TJ-> "Syntax OK"
[21:59] <Logos01> So according to your ip6tables config, you're allowing and receiving traffic on port 80 and port 443
[21:59] <TJ-> I'm not sure if this excludes apache2 or not, as yet, but I wanted to have 'nc' listen on the port but it seems to be so old as to not parse IPv6, but I tried bash with "cat </dev/tcp/<ipv6-address>/80" and clients couldn't connect either
[21:59] <Logos01> According to your netstat/ss output, you have listeners.
[22:00] <Logos01> So there's something already handling your ::*:80 and ::*:443
[22:00] <Logos01> And what do you get when you use "nc -6 -vv ::* 443" ?
[22:01] <Logos01> Err, ::1
[22:01] <RoyK> TJ-: try wireshark
[22:03] <TJ-> Logos01: there is no IPv6 support in 'nc' on 12.04
[22:03] <TJ-> RoyK: for what?
[22:03] <RoyK> TJ-: for seeing what's going over the wire
[22:03] <TJ-> RoyK: I'll run tcpdump on the server, if thats what you mean
[22:04] <patdk-wk> logos01, I dunno what you mean by state RELATED,ESTABLISHED
[22:04] <patdk-wk> oh wait, I misread that
[22:05] <patdk-wk> odd config, from what I am used to
[22:06] <patdk-wk> what doesn't work about ipv6?
[22:06] <patdk-wk> it works for me atleast
[22:06] <patdk-wk> https://[2a01:7e00:e000:151:0:1:1:2]/
[22:06] <patdk-wk> Squoo.sh those bugs
[22:06] <patdk-wk> Automated Diagnostic and Repair services for GNU/Linux systems
[22:06] <TJ-> patdk-wk: you just hit it from  2001:470:e0ba:5:f500:78f6:322c:9e86.52642 ?
[22:06] <patdk-wk> yes
[22:07] <TJ-> patdk-wk: in which case something very weird is happening on my local end; doesn't explain why I couldn't get it to operate on the host itself though! *head spinning*
[22:07] <TJ-> patdk-wk: I've got a telnet still waiting to connect, but I have an SSH and a ping both working to that same IPv6 address
[22:07] <Logos01> TJ-: ... why are you on 12.04 ?
[22:08] <TJ-> Logos01: why not? it's supported
[22:08] <ianorlin> I don't think 12.04 supported ipv6 well
[22:08] <patdk-wk> it supports it, but ya, lots of programs didn't
[22:08] <Logos01> There's a clean/sane upgrade path from 12.04 to 14.04; 16.04 is about to come out, ipv6 in particular was not really as much of a "thing" three years ago -- the system support for things like the apache version was not so hot
[22:09] <patdk-wk> I am having a horrible time attempting to upgrade from 12.04 to 14.04
[22:09] <patdk-wk> all kind of php upgrade issues
[22:09] <Logos01> patdk-wk: It's nothing like 10.04 to 12.04 though.
[22:09] <patdk-wk> I have no issues from 10.04 to 12.04
[22:09] <Logos01> patdk-wk: They changed toplevel directories.
[22:09] <TJ-> patdk-wk: I'm doing a clean install in a chroot alongside to 16.04 :)
[22:10] <patdk-wk> heh?
[22:10] <patdk-wk> that iddn't affect me at all
[22:10] <Logos01> 16.04 is gonna be a headache upgrade, though.
[22:10] <Logos01> upstart -> systemd
[22:10] <TJ-> I don't allow php on the server
[22:10] <ianorlin> I like static site generators
[22:10] <Logos01> I mean, compared between the two -- Loennart notwithstanding -- systemd is better than upstart.
[22:10] <RoyK> Logos01: fresh install may be easier
[22:10] <Logos01> RoyK: True.
[22:11] <RoyK> Logos01: but last time I tried upgrading to debian 8, it worked flawlessly
[22:11] <Logos01> RoyK: I have a bunch of desktop/physical-server installs that use ZFS as root filesystem, as well.
[22:11] <patdk-wk> Logos01, depends on the scope of systemd :)
[22:11] <RoyK> Logos01: not from upstart, though, from sysV to systemd
[22:11] <TJ-> I've had this server operating since 2007, starting with hardy-heron and upgraded since; time for a fresh install to abandon the cruft
[22:11] <RoyK> Logos01: sounds like a pita
[22:12] <Logos01> RoyK: I expect it to be. But then again it may be far less of one, considering the 16.04 version should have native support for ZFS baked-in.
[22:12] <Logos01> And I'll finally have a distro-release stable driver of ZFS to play with, if all goes well.
[22:12] <Logos01> The trick is gonna be seeing how the systemd bits play with all the crap I have on my laptop for example -- I've been carrying basically the same install since 2009.
[22:13] <Logos01> The servers... well, if I have to blow them up, then I have to blow them up.
[22:13] <RoyK> Logos01: 15.10 has zfs support, but a very old version
[22:14] <Logos01> RoyK: Right, which might come back to bite me considering I'm running relatively recent feature-flags.
[22:14] <Logos01> Had to patch and compile GRUB myself.
[22:14] <RoyK> Logos01: I was thinking more about bugs than features
[22:15] <RoyK> Logos01: zol isn't really stable as in stable. I've used it in production for a year without issues, but there are several unresolved issues known
[22:16] <RoyK> Logos01: I have a 60TiB pool (two raidz2 vdevs with 11+12 drives) at work scheduled for demolishment to be replaced by striped mirrors (23 mirrors, 4TB each, plus two spares)
[22:17] <RoyK> Logos01: I've been working with zfs for 5+ years and although there are issues with zol, I'd rather use that than illumos because of the userspace
[22:17] <Logos01> http://paste.ubuntu.com/14132856/
[22:18] <RoyK> Logos01: zpool status?
[22:18] <Logos01> RoyK: It's just a single backing drive.
[22:18]  * patdk-wk can't wait
[22:19] <Logos01> I have larger setups but this is just a desktop.
[22:19]  * patdk-wk wants to play with 500gig m.2 nvme
[22:19] <patdk-wk> should have been here, but isn't yet :(
[22:19] <Logos01> W/ a 500GB desktop hybrid drive ... I'm not really worried about checksum failures/errors
[22:19] <patdk-wk> probably got delayed somehow
[22:19] <patdk-wk> problem with ordering new crap
[22:20] <RoyK> Logos01: zfs will find the checsum errors, but won't be able to do anything about them without redundancy
[22:27] <wafflejock> trying to build the latest apache (on Ubuntu Server 14.04) but when trying to get the libapr1-dev dependency for building I'm getting an error libapr1-dev : Depends: libapr1 (= 1.5.0-1) but 1.5.1-2+deb.sury.org~precise+1 is to be installed, what to do? need to get the latest Apache for PCI compliance (or at least version 2.4.16, right now have downloaded source for 2.4.18)
[22:29] <patdk-wk> wafflejock, you don't understand pci compliance then
[22:30] <patdk-wk> WHAT is it that isn't compliant?
[22:30] <ianorlin> also doesn't the packages in archives have backports
[22:30] <ianorlin> for vulnverabilities?
[22:30] <wafflejock> Details: Multiple vulnerabilities fixed in Apache HTTP Server 2.4.16, 07/20/15 CVE 2015-0228 CVE 2015-0253 CVE 2015-3183 CVE 2015-3185 Apache HTTP Server 2.4.16 fixed multiple vulnerabilities.
[22:31] <wafflejock> yup
[22:31] <patdk-wk> and those affect ubuntu?
[22:31] <wafflejock> there's more
[22:31] <wafflejock> one sec will paste
[22:31] <patdk-wk> http://www.ubuntu.com/usn/usn-2523-1/
[22:32] <patdk-wk> according to that url, it was fixed, you should NOT upgrade to 2.4.16
[22:32] <wafflejock> http://paste.ubuntu.com/14132939/
[22:32] <ianorlin> apt-get chanelog apache2 show having stuff backported to fix cve's
[22:33] <wafflejock> well I did sudo apt-get update and sudo apt-get upgrade and the latest apache I have says it's 2.4.10 so the PCI scan appears to be correct
[22:33] <patdk-wk> no
[22:33] <patdk-wk> you read that wrong
[22:33] <patdk-wk> you do not have apache 2.4.10
[22:33] <wafflejock> ?
[22:33] <patdk-wk> you have apache 2.4.10+ubuntu-updates-and-security-patches
[22:33] <wafflejock> I did apache2 -version it says 2.4.10
[22:33] <wafflejock> ah okay
[22:33] <patdk-wk> so?
[22:33] <wafflejock> well
[22:33] <patdk-wk> what package do you have installed?
[22:33] <wafflejock> how do I fix this?
[22:34] <patdk-wk> you don't fix it
[22:34] <patdk-wk> what apache is ACTUALLY installed?
[22:34] <patdk-wk> using dpkg
[22:35] <patdk-wk> dpkg -l apache2
[22:35] <wafflejock> apache2
[22:36] <TJ-> apt-cache policy apache2
[22:36] <ianorlin> why not try apt-get changelog apache2 and see what things have been patched
[22:36] <patdk-wk> could probably do that
[22:36] <wafflejock> 2.4.10-1+deb.sury.org~precise+1
[22:37] <TJ-> huh? that's not the 14.04 apache2
[22:37] <patdk-wk> nope, looks like he already started down the bad pci road
[22:37] <patdk-wk> and found random ppa's to upgrade apache with
[22:37] <TJ-> the latest in 14.04 is " 2.4.7-1ubuntu4.5 " from ubuntu-security
[22:37] <wafflejock> I'm on 14.04.3 but this server was upgraded from 12.04 I'm almost positive
[22:37] <wafflejock> patdk-wk: nope
[22:37] <patdk-wk> yes :)
[22:37] <TJ-> changelog for Trusty here http://changelogs.ubuntu.com/changelogs/pool/main/a/apache2/apache2_2.4.7-1ubuntu4.5/changelog
[22:37] <patdk-wk> https://launchpad.net/~ondrej/+archive/ubuntu/php5/+index?field.series_filter=precise
[22:38] <wafflejock> eh well didn't do it recently then patdk-wk :)
[22:38] <patdk-wk> well, the problem is now, you no long are using ubunt usecurity updates, but depending on that person to do them for you
[22:38] <ianorlin> !ppa
[22:39] <patdk-wk> personally, I would find out if you REALLY REALLY need 2.4.10 (doubtful)
[22:39] <patdk-wk> and if not, go back to stock ubuntu apache2
[22:39] <wafflejock> yup well aware of PPAs I typically don't add them
[22:39] <wafflejock> maybe was daft in this case
[22:39] <patdk-wk> then you just post the changelog as the, why this case is solved and mitigated to your pci compliance service
[22:39] <ianorlin> unsupported stuff on things you want pci compliance for o.0
[22:39] <TJ-> looks like that came in due to adding a PPA that is primarily for PHP 5.6
[22:40] <ianorlin> this is why I don't apt-get install -y
[22:41] <TJ-> I use apt-changelog - its extremely useful for keeping up
[22:41] <TJ-> so you get to see the changelogs of each upgrading package before it is installed
[22:41] <patdk-wk> I use apt-cahangelog to know if I should bother or not :)
[22:42] <patdk-wk> if so, on the test machine, roll to production
[22:42] <TJ-> it looks like my IPv6 issue may be due to a failure on my ISPs network; looks like they installed a transparent proxy that isn't transparent, and is failing too
[22:42] <wafflejock> alright well thanks patdk-wk, TJ, and ianorlin time to clean up my stupid mess
[22:43] <patdk-wk> pci compliance people are lazy :)
[22:43] <patdk-wk> they just attempt to figure out what version you have, not if you are vaunerable
[22:43] <patdk-wk> so you just have to reply, yes, my version is old, but it was patched for this issue, see here
[23:15] <TJ-> whats with the terrible letsencrypt scripts!? I ran it, it reports an error from 1 of the scripts, which is under /tmp/   which it immediately deletes so I cannot investigate!
[23:26] <zune> hey anyone got an idea on how to make cs-go servers work after last update...
[23:26] <zune> mine is restricted to local access
[23:39] <wafflejock> patdk-wk: sorry for the attitude can't believe I had installed that via PPA, have it fixed now thanks again