[01:11] <james_w> hi serialorder
[01:36] <ryanakca> Could one make a package such that for foobar-a , patch_1.diff is applied, but for foobar-b, patch_1.diff isn't?
[01:38] <serialorder> hi james
[01:39] <james_w> ryanakca: foobar-a and foobar-b are binary packages?
[01:41] <ryanakca> james_w: *nod*
[01:41] <RAOF> It'll need some makefile trickery, and you'll obviously need to build the source twice, but it's possible.
[01:42] <ryanakca> RAOF: thanks
[01:43] <RAOF> The last thing I touched that did something similar was making libasound2-plugins build 32 & 64
[01:43] <RAOF> bit binary packages on the appropriate archs.  That's not a good example, though, because there's all sorts of madness that's specific to biarch builds.
[01:44] <ryanakca> RAOF: Thanks :)
[06:30] <Laibsch> good morning
[06:31] <Laibsch> I am trying to get http://mentors.debian.net/debian/pool/main/g/gourmet/gourmet_0.14.2-1.dsc into shape for inclusion.  I think it is almost there, except for one thing; "E: gourmet: file-directly-in-usr-share usr/share/gourmet-0.14.2.egg-info"
[06:31] <Laibsch> http://wiki.debian.org/DebianPythonFAQ suggested to pass the option "--single-version-externally-managed" to the "setup.py install" call, but that did not work out "error: option --single-version-externally-managed not recognized"
[06:31] <Laibsch> Any suggestions?
[06:32] <Laibsch> james_w: Sorry for the late response.  Did you have a chance to push those wordpress changes.  If it helps, I can still prepare an intrepid debdiff.
[06:34] <dholbach> good morning
[06:36] <Hobbsee> morning horsemen
[06:36] <dholbach> hi Hobbsee
[07:09] <awmcclain> Anyone know of a way to cache your GnuPG passphrase without using Seahorse?
[07:10] <Hobbsee> pinentry-gtk2?
[07:10] <siretart> gnupg-agent?
[07:12] <awmcclain> Thank you!
[07:21] <awmcclain> Is there any way to give (pre-cache)  my passphrase to gpg-agent before it's actually asked?
[07:27] <Hobbsee> is there any good reason to do so?
[07:29] <awmcclain> Hobbsee: I'm using autoppa to upload the ~30 packages I maintain, and it dies if you need to enter a passphrase. :(
[07:30] <Hobbsee> awmcclain: well, you can't put it in a textfile, and get it to read that.
[07:30] <Hobbsee> therefore, you're going to have to physically type it in once anyway.
[07:31] <awmcclain> Hobbsee: That's fine. I just want to be able to have gpg-agent cache it _before_ I run autoppa.
[07:31] <Hobbsee> consequently, the suggestion would be that you debsign a .dsc file manually (or something similar), then run autoppa afterwards, when it should still be cached.
[07:32] <awmcclain> Hobbsee: Perfect. I need to brush up on the individual deb helpers. I couldn't remember which would prompt me for a signature.
[07:32] <Hobbsee> awmcclain: ah, cool.
[07:32] <awmcclain> Just want to prime the pump.
[07:38] <awmcclain> Well, crap. debuild --no-tgz-check -S is still prompting for a passphrase.
[08:00] <jmarsden> awmcclain: debuild -S -uc -us
[08:02] <awmcclain> jmarsden: But that doesn't launch debsign?
[08:02] <jmarsden> Right, I thought you didn't want to sign the package?
[08:02] <Hobbsee> jdong: ping?
[08:03] <awmcclain> jmarsden: No, I'm trying to sign it, but using the cached key in gpg-agent. I think the problem is that debsign isn't configured to use gpg-agent.
[08:03] <awmcclain> (Really, I'm trying to get autoppa not to break)
[08:04] <jmarsden> Are signed packages required for PPA upload?  if not, then not signing them should avoid all passphrases and thereby achieve your goal.\
[08:05] <awmcclain> jmarsden: They are, unfortunately. :-|
[08:06] <Hobbsee> jmarsden: they are, for very good reasons.
[08:07] <jmarsden> OK.  I've always signed mine, but I've never had a need to automate PPA upload either, I'm not that prolific.
[08:08] <awmcclain> Hobbsee: Very good, yes. Unfortunately for me, I should say.
[08:08] <Hobbsee> awmcclain: well, i'm sure someone can upload a whole bunch of packages, doing various things, under your name, instead, if you really wish :P
[08:09] <awmcclain> Hobbsee: No thanks! I'd rather just get my gpg caching working. :D
[08:09] <Hobbsee> haha ;)
[08:09]  * Hobbsee wonders where all the crackporters are.
[08:10] <Hobbsee> really odd, to not even have *one* around
[08:16] <awmcclain> Hrm. Slowly making progress. The real issue is that I'm doing all this just on a console.
[08:22] <awmcclain> Is pinentry a GUI thing? Seems like it depends on QT or GTK.
[08:24] <Hobbsee> it used to have a console based one,iirc.
[08:32] <james_w> morning all
[08:32] <james_w> Laibsch: I haven't yet, sorry. I'll look at it this morning.
[08:32] <Laibsch> great, thanks
[08:32] <Laibsch> let me know if there is anything I can do to help
[10:59] <james_w> slytherin: around?
[11:00] <james_w> slytherin: for lucene, does having that patch break anything?
[11:02] <slytherin> james_w: I wonder if that patch will apply at all. If it does, it will not break anything, simply bypass a unit test.
[11:02] <james_w> k
[11:06] <slytherin> james_w: I think it is better to wait till I file a bug. Just today lucene2 in Debian got updated to use libdb4.6-java as build and runtime dependency.
[11:07] <james_w> ok. I'll wait
[13:32] <savvas> does anyone have a source of an debian package that uses svn-buildpackage ?
[13:34] <white> savvas: foo2zjs
[13:36] <white> savvas: svn.debian.org/svn/foo2zjs
[13:38] <savvas> thanks white :)
[13:45] <slytherin> savvas: I believe any packages that is team maintained in some svn (pkg-java, pkg-mono) can be build using svn-buildpackage.
[13:47] <savvas> slytherin: I'm actually reading about frostwire, since their code is in svn
[13:48] <savvas> some say there's a problem with some libraries, but I don't know what
[14:00] <lfaraone> How long does it take after I dput for somethign to get to REVU?
[15:11] <james_w> Laibsch: hi, still around?
[15:11] <Laibsch> yes
[15:11] <Laibsch> any trouble?
[15:12] <ScottK> lfaraone: I think around 10 minutes.
[15:12] <james_w> Laibsch: sorry for the delay, I'm on it now
[15:13] <james_w> Laibsch: would you update the description of the bug as described in the SRU page?
[15:13] <james_w> !sru
[15:19] <Laibsch> james_w: Are you referring to "Procedure - section 2.1 to 2.5"?
[15:19] <Laibsch> I think all the points there were covered in the bug, although there is not one nice, single paragraph to point to
[15:19] <Laibsch> I can add that if that is what you are looking for
[15:19] <james_w> yeah, please edit the description, it helps the SRU teams a lot
[15:22] <geser> Hi bddebian!
[15:23] <bddebian> Heya gang
[15:23] <bddebian> Hi geser
[15:23] <sebner> hi bddebian
[15:24] <sebner> geser: you also plan a multi vote like persia? ^^
[15:24] <bddebian> Hi sebner
[15:33] <Laibsch> james_w: take a look
[15:34] <Laibsch> I think it should be a good balance between verbose and concise
[15:34] <james_w> Laibsch: the dev branch thing means jaunty, not upstream
[15:34] <Laibsch> Oh, I see
[15:34] <james_w> I believe this was folded in to the merge for Jaunty, correct?
[15:35] <Laibsch> yes
[15:44] <james_w> Laibsch: diffs attached to the bug for your review
[15:46] <didrocks> james_w: (hi) I have a question about your last mail
[15:46] <james_w> hi didrocks
[15:47] <didrocks> james_w: does the "dpkg-statoverride call" has to be in the init script?
[15:47] <geser> sebner: first I need to read my collect mails from today
[15:47] <james_w> didrocks: that's kind of my question
[15:47] <sebner> geser: heh =)
[15:48] <didrocks> james_w: from what I understand (but I maybe wrong), it's just for replacing the "chmod 777", right?
[15:48] <didrocks> (and as the init script is launched as root, this is possible)
[15:48] <james_w> I'm not sure what you mean
[15:49] <didrocks> james_w: sorry, trying again : the best pratice is to used dpkg-statoverride in the init script, instead of using chmod/chown option to enable everyone to write in /var/run
[15:49] <Laibsch> james_w: Looks good, the date in the hardy patch is Nov 14th, but I guess that is rather irrelevant
[15:50] <Laibsch> thanks for the clean-up
[15:50] <savvas> Does anyone know a cdbs package that compiles using ant and ant.mk ? I'd like to see an example
[15:51] <james_w> didrocks: ah, no, dpkg-statoverride allows the admin to tell packages not to chown/chmod certain files/directories. The init scripts I have seen that chmod/chown do not respect this.
[15:51] <james_w> Laibsch: cool, thanks, I'll upload
[15:52] <didrocks> james_w: but in this case, I do not understand how, after a reboot, the right directory in /var/run is still writable for everyone
[15:53] <james_w> why should they be writeable to everyone?
[15:54] <didrocks> I was thinking you were talking about this case (when chown/chmod was needed in init script)
[15:54] <didrocks> but that was because I didn't understand the dpkg-statoverride use
[15:54] <didrocks> so, now, I think it's ok :)
[15:55] <didrocks> thanks a lot james_w. Will look closely at the discussion about this point :)
[17:11] <iulian> Heya
[17:24] <james_w> directhex: hey, you about?
[17:25] <james_w> directhex: I've cot a bit of confusion with gmcs on ia64, and I would like you to tell me how it should look so I know what is broken
[17:31] <james_w> directhex: mono-gmcs doesn't seem to contain gmcs, but it's an Arch: all package.
[17:32] <sebner> james_w: afaik mono-gmcs contains gmcs1. gmcs2 is in mono-devel
[17:33] <james_w> I don't know how much to trust the Contents.gz, but they differ across arches
[17:33] <james_w> ia64 has gmcs2 in mono-gmcs and gmcs in mono-devel it seems
[17:34] <sebner> O_o
[17:34] <james_w> with gmcs in mono-gmcs and no mono-devel on i386
[17:34] <sebner> james_w: well, at least I had to install mono-devel so monodevelop alpha2 configure finds gmcs
[17:34] <sebner> on i386
[17:35] <james_w> this package may have built either side of mono2.0 being uploaded
[17:58] <jdong> wow, network-manager sets up ad-hoc NATs.
[17:58] <jdong> I didn't know that.
[17:59] <slytherin> jdong: As per my observation, the only thing that NM doesn't manage is firewire point to point network.
[18:02] <jdong> never tried that before, so I can't say.
[18:02] <jdong> I did find it a bit counterintuitive that "Set up wireless network" defaults to setting up a NAT
[18:02] <jdong> although the functionality is nice, I would've liked it to be a bit more clear that's what it does.
[18:11] <Tetracomm> Hello.
[18:11] <Tetracomm> Does anyone know if checkinstall packages will ever become acceptable?
[18:12] <sebner> Tetracomm: never ever ;)
[18:13] <guille_> hi all
[18:13] <slytherin> Tetracomm: without changes? no.
[18:13] <guille_> does exist a mail list for packages?
[18:13] <slytherin> guille_: hi
[18:13] <slytherin> guille_: what kind of mailing list?
[18:14] <guille_> not sure what kind. actually i'm trying to build mysql with sphinxse (an storage engine) an package it; but no way to do it. i would like to ask people who knows
[18:16] <slytherin> guille_: Considering that mysql is in main, you will have better luck if you ask on #ubuntu-devel channel.
[18:17] <guille_> slytherin: ok, thank you
[18:29] <Tetracomm> Something needs to be done about the overcomplicated package creation process.
[18:30] <jdong> what is overcomplicated?
[18:30] <slytherin> Tetracomm: what is overcomplicated?
[18:30]  * lamont grumbles at jpds
[18:30] <Tetracomm> The package creation process.
[18:31] <Tetracomm> It is too difficult.
[18:31] <jdong> can you be more specific?
[18:31] <jdong> what part(s) did you find to be difficult?
[18:31] <broonie> You may want to use CDBS or similar if you're packaging something noddy enough.
[18:33] <lamont> jpds: if you wanna send me your nmap diff, it'll probably get uploaded and synced faster
[19:09] <slytherin> geser: any idea if java packages will ever need ${shlibs:Depends}, ${misc:Depends} ?
[19:20] <leslieviljoen> hey ppl! I was wondering: are packages "owned" by certain motu's? I reported a certain bug almost a year ago, including a patch. Today I mailed the Debian maintainer and he said he'd never seen it. Who's supposed to inform upstream?
[19:21] <azeem> the Debian maintainer is not necessarily upstream
[19:21] <slytherin> leslieviljoen: No. Packages are now owned by certain motu's. It has some advantages and at least one disadvantage that you mentioned.
[19:21] <azeem> well, depends on what you're talking about
[19:22] <leslieviljoen> in this case, the Debian maintainer was upstream
[19:23] <leslieviljoen> so is there a way of finding out if anyone is attending to something? do the devs handle bugs randomly?
[19:23] <geser> slytherin: I assume that dh_shlibdeps won't work for java packages, so ${shlib:Depends} is useless here, but one could perhaps use ${misc:Depends} for automagic dependencies on jars in other packages (if it's somehow possible to discover the dependencies)
[19:25] <geser> leslieviljoen: you might look at the "also notified" list but that is no guarantee that those people are really interested in the package
[19:25] <slytherin> geser: I guess jaranalyzer is supposed to determine dependencies. Never actually used it though.
[19:26] <leslieviljoen> so they are handled on a "I'm interested in that" basis?
[19:28] <leslieviljoen> So it comes down to this: I'm interested in fixing certain things, and I'm capable of doing it, I just don't know how to get my fixes into the repos. At least not in under a year.
[19:29] <leslieviljoen> What should I do?
[19:30] <lamont> leslieviljoen: patches sent to the bug report tend to get attention faster than bugs with no patches
[19:32] <leslieviljoen> Well look here: https://bugs.launchpad.net/wajig/+bug/174261
[19:33] <leslieviljoen> It's a tiny problem but I fixed it almost a year ago. Upstream hasn't even heard of it yet.
[19:33] <leslieviljoen> (well they did today)
[19:34] <leslieviljoen> I made that fix to release a script that can find regressions in desktop packages: that script was a response to another bug I reported
[19:36] <leslieviljoen> so there seems to be a break-down in the link between launchpad and upstream - if there is any link
[19:56] <leslieviljoen> is there any reason not to report bugs directly upstream as opposed to launchpad?
[19:57] <geser> yes, as Ubuntu patches some packages/software a bug might be because of that patching so upstream can't really do anything about it
[19:58] <geser> and for the users it's easier to report bug reports at one place
[19:58] <geser> the downside is that we don't have enough manpower to distribute those bug reports to the different upstreams (after checking if it's really an upstream bug)
[20:01] <leslieviljoen> but I can easily check that
[20:01] <leslieviljoen> maybe I should become a motu
[20:01] <leslieviljoen> I just don't have consistent stretches of time
[20:02] <slytherin> leslieviljoen: that shouldn't stop you from trying
[20:02] <leslieviljoen> don't the motu's have set responsibilities?
[20:03] <leslieviljoen> ie. don't you need a certain minimum consistent amount of time to contribute?
[20:03] <directhex> if the patch is NOT in the packaging, then i'd STRONGLY recommend you file the bug upstream *yourself* and link the bug in launchpad
[20:03] <directhex> because chinese whispers are bad - you'd do a much better job of communicating the problem & answering questions than having a packager relay your issue without neccessarily fully understanding the issue
[20:05] <james_w> directhex: hey, did you see my question earlier?
[20:05] <james_w> directhex: it boiled down to which package is now supposed to ship /usr/bin/gmcs?
[20:06] <leslieviljoen> directhex: thanks for the advice. the problem is very rarely in the packaging though.
[20:06] <directhex> james_w, no, i didn't, sorry. things were exploding at work
[20:06] <james_w> directhex: no problem, it's not urgent
[20:07] <directhex> james_w, we now ship 'generic' scripts in mono-devel - which means things like "sn" (as opposed to sh1 for .net 1, sn2 for .net 2), "al" (as opposed to... blah blah). and gmcs comes into that category
[20:08] <geser> leslieviljoen: MOTUs contributing in their free time, so its up to everyone how much time he's ready to spend (no commitments)
[20:08] <james_w> directhex: aha, so a package that wants to use gmcs should B-D on mono-devel, rather than mono-gmcs?
[20:08] <directhex> james_w, if you're asking due to a build dep, then the advice is to actually override the compiler you use to force 'csc', which is a debian-specific script pointing to the default c# compiler, which is gmcs for now (but might go back to being mcs in the future - upstream were talking about merging them)
[20:09] <directhex> james_w, http://wiki.debian.org/Teams/DebianMonoGroup/Mono20Transition#head-67c13a005dab7f510b0fd1ee8db7a30689e89669
[20:09] <james_w> directhex: nice, thanks. I'll work on that part and then consult you about anything else needed for the transition.
[20:09] <directhex> james_w, yes, please don't hesitate to ask
[20:11] <directhex> james_w, 2.0 passed debian NEW literally 150 minutes ago, so the transition is entering full swing there too. in experimental,mind
[20:12] <serialorder> i am working on a merge and the ubuntu version used automake 1.10.1 while the new debian version uses 1.10 this leads to a few extra things in the Makefile.in, which version should I keep?
[20:13] <directhex> (ubuntu is still newer though, 2.0.1-0ubuntu2 > 2.0-1. 2.0.1-0ubuntu2 is being referred to as 2.0.1-1~pre3 in private repo; ~pre4 exists but has a bugfix which does not affect buildds)
[20:14] <leslieviljoen> ok, will read up on how to motu, thanks chaps
[20:17] <directhex> leslieviljoen, if you're interested in a specific package, also worth considering is helping ubuntu by helping debian - especially if the package version is a debian version (i.e. nobody from ubuntu has made ubuntu changes) or a 0ubuntuX (ubuntu has a newer version than debian), then helping debian helps BOTH distros, as well as hundreds of debian-based distros
[20:19] <slytherin> serialorder: what are those extra things?
[20:21] <serialorder> there are three
[20:21] <serialorder> <<<<<<< dasher-4.7.0-0ubuntu2 (ubuntu)
[20:21] <serialorder> # 2003, 2004, 2005, 2006, 2007, 2008  Free Software Foundation, Inc.
[20:21] <serialorder> [20:21] <serialorder> # 2003, 2004, 2005, 2006  Free Software Foundation, Inc.
[20:21] <serialorder> >>>>>>> dasher-4.7.3-1 (debian)
[20:21] <serialorder> <<<<<<< dasher-4.7.0-0ubuntu2 (ubuntu)
[20:21] <serialorder> DSYMUTIL = @DSYMUTIL@
[20:21] <serialorder> [20:21] <serialorder> >>>>>>> dasher-4.7.3-1 (debian)
[20:21] <serialorder> <<<<<<< dasher-4.7.0-0ubuntu2 (ubuntu)
[20:21] <serialorder> MSGFMT_OPTS = @MSGFMT_OPTS@
[20:21] <serialorder> MSGMERGE = @MSGMERGE@
[20:21] <serialorder> NMEDIT = @NMEDIT@
[20:21] <serialorder> [20:21] <directhex> blurp
[20:21] <serialorder> MSGFMT_OPTS = @MSGFMT_OPTS@
[20:21] <serialorder> >>>>>>> dasher-4.7.3-1 (debian)
[20:22] <leslieviljoen> is there any ubuntu team that just browses the bugs and reports them upstream if need be? Is that triaging?
[20:22] <superm1> !pastebin | serialorder
[20:22] <leslieviljoen> I am re-reporting my launchpad bugs in debian right now.
[20:26] <slytherin> leleobhz: yes, there is bug-squad. there channel is #ubuntu-nugs
[20:26] <slytherin> serialorder: please use pastebin for pasting anything more than two lines.
[20:27] <slytherin> serialorder: The difference look unnecessary to me unless they were done intentionally.
[20:27] <serialorder> sorry guys, didnt know
[20:31] <superm1> that reminds me... is there a nice GUI tool for handling when this 3 way merge stuff gets spewed into one file?  meld works wonders on a 3 way diff with 3 files
[20:31] <serialorder> slythering that is what i was thinking, there is nothing in the changelog to indicate it was intentional
[20:32] <slytherin> serialorder: so drop it
[20:35]  * slytherin calls of the day
[20:35] <slytherin> s/of/off
[21:47] <mathiaz> kirkland: ok - what's your question with iscsitarget?
[21:47] <kirkland> mathiaz: hey, so there appears to be a separate, but related bug in the iscsi_trgt.ko kernel module provided by l-u-m
[21:47] <kirkland> mathiaz: i've talked to smb and rtg, and they're going to work on that from the kernel side
[21:48] <jmarsden|work> http://packages.ubuntu.com appears to be down -- are others still able to access it?
[21:49] <kirkland> mathiaz: basically, the ubuntu module won't unload properly
[21:49] <kirkland> mathiaz: and the init script unloads that module on "stop" action
[21:49] <mathiaz> kirkland: ok
[21:49] <kirkland> mathiaz: exiting non-zero if it cannot unload the module
[21:50] <kirkland> mathiaz: which cause the package upgrade to fail
[21:50] <kirkland> mathiaz:  in the merged init script, i cleaned up a number of things, including lsb-izing it
[21:50] <kirkland> mathiaz: but i also made the module unload throw the warning/error, but it does not exit non-zero
[21:52] <kirkland> mathiaz: i was looking for a second opinion on that
[21:53] <mathiaz> kirkland: right - how important is it to unload the modules on stop?
[21:53] <kirkland> mathiaz: i also considered trying to put something in the pre-rm, that would soften the problems with the initscript "stop" failing, such that the package could be upgraded
[21:53] <kirkland> mathiaz: i'm not sure ...  the daemon is killed first, and that seems to happen well
[21:53] <mathiaz> kirkland: hm - right package upgrades.
[21:53] <kirkland> mathiaz: i can't get the module to unload at all, must reboot
[21:54] <mathiaz> kirkland: IIRC you could try to put some code in the new prerm script
[21:54] <kirkland> mathiaz: the "easy" work around is to a) stop the init script, ignore the error, b) move the init script out of the way, c) do the package upgraded
[21:54] <kirkland> mathiaz: yes, that would definitely work
[21:54] <kirkland> mathiaz: i thought maybe we'd see if a working module might be added to the kernel first
[21:55] <kirkland> mathiaz: but mainly, i was looking for a second opinion, and to alert someone about the potential issue
[21:55] <mathiaz> kirkland: yes - but that wouldn't help in the case of upgrades
[21:55] <kirkland> mathiaz: i also submitted a debian bug, with the patch
[21:55] <kirkland> mathiaz: i haven't heard anything back from them yet
[21:56] <mathiaz> kirkland: right - so you'd suggest to wait for the kernel fix before uploading a merge?
[21:56] <kirkland> mathiaz: sorry, no i uploaded the merge already
[21:57] <kirkland> mathiaz: and i noted in a bug report that a), b), c) workaround, if you're having trouble with the upgrade
[21:57] <kirkland> mathiaz: i'm asking you now if you think a maintainer script would be required
[21:58] <mathiaz> kirkland: yes
[21:58] <kirkland> mathiaz: okay ... next question...  there is a prerm script auto-generated by debhelper
[21:59] <mathiaz> kirkland: well - technically debhelper doesn't generate a prerm script - it substitutes some code in existing maintainer script
[22:00] <mathiaz> kirkland: the templates for the maintainer scripts can be found under /usr/share/debhelper/dh_make/debian
[22:06]  * lamont notes that packages.ubuntu.com is happy agaain
[22:06] <Nafallo> jmarsden|work: packages.u.c back.
[22:06] <jmarsden|work> Nafallo: thanks
[22:06] <Nafallo> meeh. stupid scroll up :-)
[22:07] <lamont> heh
[22:37] <nhandler> Could someone give me a hand with merging loadlin from Debian? It FTBFS (http://paste.ubuntu.com/76599/).
[22:38] <jdong> nhandler: try -fno-stack-protector in CFLAGS?
[22:38] <DktrKranz> nhandler, try passing -fno-stack-protector to CFLAGS
[22:38] <jdong> *tells ke<noping>es to look away*
[22:39] <james_w> https://wiki.ubuntu.com/CompilerFlags#-fstack-protector
[22:41] <nhandler> I'm building it again right now. In the mean time, I'll read through that wiki page. Thanks jdong, DktrKranz, and james_w!
[22:42] <DktrKranz> nhandler, as ke<noping>es says, it's better to fix it properly, but if you're in a hurry...
[22:43] <nhandler> Well, the -fno-stack-protector didn't solve the issue. It still FTBFS with the same error
[22:44] <jdong> well loadlin probably doesn't use stdlib anyway
[22:47] <DktrKranz> nhandler, be sure CFLAGS are handled by debian/rules. If not, you need to adjust Makefile (or whatever) manually
[22:49] <nhandler> DktrKranz: debian/rules is handling the CFLAGS
[22:49] <DktrKranz> nhandler, try to pass -U_FORTIFY_SOURCE too
[22:50] <DktrKranz> buffer overflows are easier to track
[22:54] <nhandler> DktrKranz: Nope. -U_FORTIFY_SOURCE didn't fix it either.
[22:54] <NCommander> DktrKranz, -U?
[22:54] <NCommander> Why do you want to undefine it?
[22:56] <DktrKranz> NCommander, testing purposed
[22:57] <NCommander> ah
[22:57] <DktrKranz> nhandler, my bet is debian/rules doesn't pass CFLAGS to inner Makefile
[22:59] <james_w> would anybody like to review my changes in http://paste.ubuntu.com/76605/ ?
[23:01] <nhandler> DktrKranz: You might be right. The rules file sets up the CFLAGS variable. However, the only time it uses it is when deeling with freeramdisk. (http://paste.ubuntu.com/76603/)
[23:02] <DktrKranz> nhandler, if you have a Makefile in parent directory, try adjusting it by inserting -fno-stack-protector after gcc invocation
[23:06] <DktrKranz> james_w, at a first glance, it seems good (it follows the recipe provided by CompilerFlags)
[23:09] <james_w> thanks DktrKranz
[23:14] <nhandler> DktrKranz: Nope. Adding -fno-stack-protector to the make file didn't do any good either.
[23:16] <kirkland> mathiaz: hmm, i'm having some strange problem with dh_installdeb
[23:19] <kirkland> mathiaz: my diff currently looks like this: http://pastebin.ubuntu.com/76612/
[23:22] <mathiaz> kirkland: where does the init script fail currently? In prerm?
[23:22] <kirkland> mathiaz: well, the substitution claimed by dh_installdeb isn't currently happening
[23:22] <kirkland> mathiaz: there must be a debian/rules step missing
[23:22] <kirkland> mathiaz: but dh_installdeb appears to be present in the two places i'd expect it
[23:25] <DktrKranz> nhandler, I need to look at it then
[23:26] <nhandler> DktrKranz: No problem. I'll probably just put the merge up for grabs. I have no personal reason for doing it. In the end, it would just be another MOTUs solution that I would use. If nobody handles it by DIF, I'll take another look at it.
[23:28] <DktrKranz> nhandler, ok. I'll leave soon (quite late here), I'll have a look at it tomorrow (if I remember, of course)
[23:29] <nhandler> Thanks again for your help DktrKranz
[23:29] <directhex> james_w, which package are you working on mono transition for, OOI? it would be great if you could take ownership on http://wiki.debian.org/Teams/DebianMonoGroup/Mono20TransitionTODO to avoid duplication of effort
[23:29] <james_w> directhex: it was banshee. I requested the sync, and so got stuck with the build failure email
[23:29] <directhex> ah, right
[23:30] <directhex> well, slomo will receive appropriate kicks up the butt. since mono 2 is now in experimental, he'll get the same FTBFS there until he makes a 1.4.1-2
[23:30] <james_w> yup
[23:31] <james_w> I'll see if I can get something that builds for him to start from
[23:31] <directhex> although no sign of meebey tonight (grrr!)
[23:33] <kirkland> mathiaz: ^ thoughts?
[23:34] <mathiaz> kirkland: looking at the package now
[23:34] <kirkland> mathiaz: thx
[23:35] <mathiaz> kirkland: but a quick comment regarding your pastbin - why not put the logic in failed-upgrade?
[23:35] <directhex> james_w, are you a banshee user, then?
[23:35] <mathiaz> kirkland: it seems that this is the place to handle a failure of the prerm script from the existing package
[23:35] <james_w> directhex: nope
[23:44] <snikker> when i try to make a .deb package, i've got this warning: "dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}" and in "${misc:Depends}", can you help me?
[23:45] <mok0> snikker: they are defined in debian/control
[23:46] <mok0> snikker: you can safely delete it
[23:46] <azeem> snikker: it means nothing had to be substituted
[23:46] <azeem> AIUI
[23:46] <snikker> yes, they are there, isn't right?
[23:46] <azeem> well, apparently they are not needed
[23:46] <azeem> snikker: what programming language is your package in?
[23:46] <mok0> snikker: you can also leave them, it's not a serious problem
[23:47] <azeem> *if* they are really not needed
[23:47] <snikker> it's an service menu for kde4... so i can ignore it?
[23:47] <azeem> eh
[23:47] <azeem> kde4 is not a programming language
[23:47] <azeem> is it in C++?
[23:48] <mok0> snikker: so it's just image and text files?
[23:48] <kirkland> mathiaz: i suppose it could be handled there
[23:48] <snikker> if the servicemenu is in c++? no, it's just a text file (file.desktop)
[23:48] <azeem> ok then
[23:48] <azeem> snikker: then you can ignore it and/or delete it indeed
[23:49] <snikker> azeem: ok, thanks...
[23:50] <snikker> azeem: but suppose that i've got a c/c++ file (instead of text file) and i receive this warning, what i must do?
[23:52] <mok0> snikker: then you wouldn't get the warning
[23:53] <azeem> all c/c++ programs need at least the C/C++ system libraries, so if you get the ${shlibs:Depends} warning, it might mean the package build process failed to build or install the program
[23:53] <azeem> the ${misc:Depends} warning might not be a problem
[23:55] <snikker> azeem: ok, but if i've got a ${shlibs:Depends}, how can i check what's the problem?
[23:55] <snikker> there is a way for check it?
[23:58] <azeem> no, you will have to carefully manually inspect the .deb you get


[07:30] <SimonAnibal> Anyone familiar with SystemImager?
[07:31] <SimonAnibal> Good stuff
[07:31] <SimonAnibal> Helping me get away from reliance on Norton Ghost


[18:49] <kyanardag> hi, not sure if this is the right room.. I'm on ubuntu 17.10, gnome-shell 3.26.2, I'm using Logitech USB Optical Mouse and I removed the usb dongle, when I inserted back the mouse is not working. I see it is recognized from dmesg output, but I don't see the device in xinput output..
[18:50] <kyanardag> I tried restarting USB service but didn't help.. This happened before and I know restarting the system fixes the problem. But I'm looking for a way to recover usb mouse without restarting the system..
[19:42] <kyanardag> just solved the problem.. find the bus number (003) and then generate the string "usb3" then "echo usb3 | sudo tee /sys/bus/usb/drivers/usb/unbind"
[19:42] <kyanardag> and then echo usb3 | sudo tee /sys/bus/usb/drivers/usb/bind


[13:34] <Laney> cjwatson: Hi, could you check if you are grabbing appstream from us correctly please?
[13:34] <Laney> I added a timestamp on my end to check on this and yours doesn't have it
[13:45] <cjwatson> Laney: nothing worrisome in logs.  how long ago did you add it and on what host?
[13:46] <cjwatson> Laney: I don't see anything obviously timestamp-like when I try "rsync -av appstream.ubuntu.com::appstream/"
[13:47] <Laney> cjwatson: "Time" in the header document
[13:47] <Laney> I think it should have started appearing yesterday
[13:47] <cjwatson> which header document is that?
[13:47] <Laney> at least xenial/main/amd64 has it
[13:48] <cjwatson> is this somewhere inside xenial/main/Components-amd64.yml.gz ?
[13:48] <Laney> ubuntu@temp-rsync-host:~/appstream/xenial/main$ zgrep "Time:" Components-amd64.yml.gz
[13:48] <Laney> /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_GB.UTF-8)
[13:48] <Laney> Time: '2016-03-08T13:05:43.158291+00:00'
[13:56] <cjwatson> Laney: for some reason the mtime of that file is older than the version we already have, so LP doesn't install it
[13:56] <cjwatson> cjwatson@pepo:/srv/launchpad.net/ubuntu-archive$ ls -l ubuntu/dists/xenial/main/dep11/Components-amd64.yml.gz
[13:56] <cjwatson> -rw-rw-r-- 1 lp_publish lp_publish 433553 Mar  8 13:44 ubuntu/dists/xenial/main/dep11/Components-amd64.yml.gz
[13:56] <cjwatson> cjwatson@pepo:/srv/launchpad.net/ubuntu-archive$ ls -l ubuntu-staging/xenial/main/dep11/Components-amd64.yml.gz
[13:56] <cjwatson> -rw-rw-r-- 1 lp_publish lp_publish 429569 Mar  8 13:07 ubuntu-staging/xenial/main/dep11/Components-amd64.yml.gz
[13:57] <cjwatson> hm, that's today though
[13:57] <Laney> Is it possible that something is making that always be the case?
[13:57] <cjwatson> I thought I was fairly careful there
[13:58] <Laney> I think that I made emacs24 appear some time last week
[13:58] <Laney> and it's not in the archive's version
[13:58] <cjwatson> that mtime is super weird though
[13:58] <Laney> The first thing that made me suspicious enough to add this timestamp was not seeing apt downloading it very often
[13:59] <cjwatson> it's in the middle of release file generation
[13:59] <cjwatson> which is a bit WTF
[13:59] <cjwatson> oh
[13:59] <cjwatson> _syncTimestamps
[14:00] <cjwatson> there's a thing that makes sure that all the mtimes of Release and anything it contains match up, to make it easier to insert caching headers on mirrors
[14:00] <cjwatson> that clashes rather badly with this
[14:00] <cjwatson> probably with Contents files too
[14:00] <cjwatson> hm hm hm
[14:01] <cjwatson> Laney: please file a bug, this is definitely screwed but I need to think about the best way to fix it
[14:01] <Laney> OK
[14:02] <cjwatson> we may need to use something other than mtime for the sync-from-staging
[14:02]  * Laney gets this filed quickly so that he can go away before hearing too much of the archers
[14:03] <cjwatson> paging @SoVeryBritish
[14:05] <Laney> https://bugs.launchpad.net/launchpad/+bug/1554535
[14:06]  * Laney goes to lunch
[14:06] <cjwatson> ta
[15:25] <dpm> hi cjwatson, last week you mentioned an LP change that needed to land to fix snap builder issues. Has that landed and if not, is there a bug I can track?
[15:39] <cjwatson> dpm: it was a launchpad-buildd change, and it's landed
[15:39] <cjwatson> well, except on arm64 for reasons, I should go and chase that up
[15:51] <dpm> cjwatson, great, thanks. I saw the build of my snap failing again this morning, so I wasn't sure if it was the same issue. But it might also be the latest changes to the branch, which don't seem to be supported by snapcraft. I'll check later
[15:55] <cjwatson> dpm: link?
[15:55] <cjwatson> dpm: snapcraft compatibility is fairly, yes, well
[15:56] <cjwatson> dpm: afaics you've performed no snap builds on LP since last week
[17:11] <xnox> do clone links look broken here https://code.launchpad.net/~james-page/charms/+source/openstack-on-lxd-bundle/+git/openstack-on-lxd-bundle
[17:17] <cjwatson> they're OK aside from the annoying wrapping
[19:02] <dpm> cjwatson, indeed, no snap builds. Sorry, misread the subject of the e-mail notification, as I'm building both snaps and .debs for the same upstream project
[19:07] <xnox> cjwatson, imho they shall never wrap, like they don't on https://git.launchpad.net/~james-page/charms/+source/openstack-on-lxd-bundle
[19:07] <xnox> cjwatson, and e.g. i have enough screen space to have them non-wrapped.
[21:09] <cjwatson> xnox: (ITYM "should".)  I agree, file a bug?
[21:09] <ricotz> hello, how are spamming accounts suppose to be handled? https://answers.launchpad.net/synapse-project/+question/288140
[21:09] <cjwatson> wgrant: ^-
[21:09]  * wgrant applies fire.
[21:09] <ricotz> ;-)


[09:26] <PinchMe> Hi all, it was suggested i ask here for an ubuntu project cloak. I'm pinchme at launchpad, so i suppose the cloak should reflect that.
[09:28] <DJones> Give it a bit of time, one of the IRCC will be along at some point to check eligibility etc
[09:29] <Tm_T> PinchMe: hi, could you link to your launchpad profile while I check other details?
[09:29] <PinchMe> Thanks you
[09:30] <PinchMe> I'm new in the ubuntu sphere, so i'm not sure about the rules
[09:31] <PinchMe> trying to figure out the bzr commands so i can push initial code (git user...)
[09:31] <PinchMe> :)
[09:31] <Tm_T> PinchMe: you are this? https://launchpad.net/~pinchme
[09:31] <PinchMe> Tm_T: that's right
[09:32] <IdleOne> !membership
[09:32] <PinchMe> i just opened the account for my project
[09:32] <PinchMe> IdleOne: thanks! i'll read the guidelines
[09:32] <Tm_T> PinchMe: Ubuntu project cloak is for Ubuntu members, see the membership page linked above (:
[09:33] <PinchMe> Tm_T: well, i'm working on an ubuntu fork for appliances and should be a member - reading up on it
[09:34] <PinchMe> ah, it's for contributions directly to ubuntu, not forks i suppose
[09:35] <Tm_T> yes
[12:21] <m4v> IRCC: might I have an ubuntu cloak? https://launchpad.net/~m4v
[12:26] <Tm_T> m4v: who are you
[12:26]  * Tm_T huggles m4v with all the motherly love
[12:27] <Tm_T> staff, may we have ubuntu/member/m4v cloak for m4v please?
[12:33] <m4v> Tm_T: a bot herder? :P
[12:34] <Tm_T> m4v: you should have that as your job title on business card
[12:37] <m4v> err, I might have to change it to "maintainer of automated service software for IRC networks" or something
[12:38]  * tsimpson goes for "software management practitioner for real-time network communication services and utilities"
[12:39] <tsimpson> though that may not fit on the card ;)
[12:43] <Tm_T> Myrtti: ^
[12:46] <Myrtti> mmm
[12:47] <Myrtti> done
[12:48] <m4v> thanks.
[12:48] <Myrtti> np
[13:04] <Tm_T> Myrtti: thank you (:


[01:44] <noinip> Does this guide still work as expected for transcoding
[01:44] <noinip> http://ubuntuforums.org/showthread.php?t=346778
[01:44] <noinip> Or should I follow something else?
[02:19] <pteague> ok, gotta love this...  on my pvr-500 tuner #2 usually dies either before a recording or in the middle of 1... #1 always works...  so tonight i had something i really wanted to record & something else i thought it'd be kinda nice to record... set up the must have to record on #1, the nice to have on #2... so guess which 1 crapped out on me tonight?
[05:09] <fnc1> evening all.. anyone around?
[05:13] <IOU> evening
[05:14] <fnc1> im looking at redoing my mythbackend... and was thinking about using mythbuntu
[05:16] <fnc1> but after some diggin i see that if i want to do a sw raid then im probably gong to have do a alt ubuntu install, then install the mythbuntu package?
[05:16] <fnc1> or is there a mythbuntu iso that i can use that im not seeing?
[05:16] <hads> Na, not a big deal though, it's all the same repository
[05:17] <hads> So you'll end up with the same packages
[05:17] <fnc1> if it makes a difference..  i want to install the os on its own drive, then the /video  or whatever it was called on the raid 5
[05:17] <IOU> just have the raided drive mount on /var/lib/mythtv
[05:17] <IOU> thats what mine does
[05:17] <hads> Well you can always setup RAID after you install
[05:18] <IOU> or that
[05:18] <hads> If you don't want RAID on /
[05:18] <fnc1> i was kinda thinking that... just set /video on the / then change it later
[05:19] <fnc1> and if thats the case i guess i could just use the desktop iso (and wouldnt need the alternate iso one)
[05:20] <fnc1> any of you guys happen to be running a software raid for your /video ?  any issues there?
[05:21] <hads> I don't RAID on my mythboxes but there won't be an issue
[05:22] <IOU> i raid my box
[05:22] <IOU> i have a 60G drive that holds the OS
[05:22] <hads> I don't care enough about recordings for RAID
[05:22] <IOU> and i have two 200G striped to 400G which is mounted on /var/lib/mythtv
[05:22] <IOU> i just got sick of one of my drives getting full
[05:23] <fnc1> got cha
[05:23] <IOU> so i installed Mythbuntu on the 60
[05:23] <fnc1> i cant remember how large my os drive is but im guessing at least 320
[05:23] <hads> Ah, I use NFS to a server for stored videos etc.
[05:23] <IOU> set up the software raid and mounted on that path
[05:23] <IOU> hads: i would have done that, but this is the machine with the biggest storage media lol
[05:24] <fnc1> i have a nfs hardware raid box.. but its only got 750gb left so i wanted to set something else up to store all my huge atsc recordings
[05:24] <fnc1> (until i manage to build a new bigger hard ware raid)
[05:25] <fnc1> so my backend would be 320 or something for the os and 5x750 gb for /video
[05:25] <fnc1> software raid 5
[05:26] <IOU> 320 gig for the OS? Overkill ? lol
[05:26] <IOU> :)
[05:26] <fnc1> originally i wanted to do like you an offload the recordings to my big raid. but after ripping my dvds, its kinda full
[05:26] <fnc1> well its whats in there now..
[05:27] <IOU> i was gonna do it like this:
[05:28] <IOU> /dev/sda1 - 200G - Videos/Recordings
[05:28] <IOU> /dev/sdb1 - 200G - Music
[05:28] <IOU> but i couldnt be assed
[05:28] <IOU> i need to re-think my setup anyhow
[05:28] <fnc1> yeah.. thats what im doing now
[05:28] <fnc1> heh
[05:29] <fnc1> /dev/sda3             285G  103G  171G  38% /
[05:29] <fnc1> /dev/sda1              99M   21M   73M  23% /boot
[05:29] <fnc1> tmpfs                1014M   12K 1014M   1% /dev/shm
[05:29] <fnc1> /dev/sdb1             459G  430G  5.4G  99% /video/tv
[05:30] <fnc1> 5.4g free doesnt work too well.. there is no more room for recordings
[05:34] <hads> It's fine with automatic deletion
[05:35] <fnc1> cept i dont like deleteing things :-/
[05:35] <fnc1> /media/disk
[05:35] <fnc1><PHONE_NUMBER><PHONE_NUMBER><PHONE_NUMBER>  89% /mnt/raid
[05:36] <fnc1> see
[15:51] <zyberwoof> Adding QAM channels is a pain in the rear.  Mythbuntu found all of the channel, but was unable to lable any of them.  So now I am going back channel by channel, and finding out if the channel works and which it is.  Once I figure out what it is by watching it, I match it up to my report on SchedulesDirect.org and type in the xmlid, callsign, and name.  Once I do that, mythfilldatabase populates the guide just fine.
[15:51] <zyberwoof> I have two questions.
[15:51] <zyberwoof> 1) Is there an easier (more automatic) way to populate Mythbuntu with the correct channel information?
[15:51] <zyberwoof> 2) If not, is there a simple method to export/import this information both for archival purposes and to share with others who have the same provider and live in my area?
[15:51] <zyberwoof> I have Mythbuntu 8.04 running as a VM in VMware.  My tuner is HDHomeRun.  I live outside of Atlanta (Alpharetta) and have Comcast.  So far all I have been adding is Qam256 channels.
[16:40] <superm1> zyberwoof, so that data comes with the channel stream.  if comcast doesn't provide it, then you have to do it manually
[16:40] <superm1> you can export the tables from your database i believe, but that's abou  it
[17:30] <EvilGuru> Can LVM be set up from the normal CD nowadays? Or is the alternate install still needed?
[17:30] <rhpot1991> EvilGuru: alternate only I do believe
[17:30] <rhpot1991> LVM is less useful now that we have storage groups though
[17:31] <EvilGuru> I also keep my DVD rips and music on my mythbox
[17:31] <rhpot1991> so do I...
[17:31] <rhpot1991> just plan ahead and you should be ok, otherwise use the altnerate disc
[17:47] <EvilGuru> I feel more comfortable with the alternate one
[17:48] <EvilGuru> I may be wrong, but I think back in the 5.04 days the only way to install ubuntu was to use the 'alternate' disk, as the live cd was just live
[17:56] <EvilGuru> Hmm, seems as if 9.04 will not have alternate disks
[18:19] <zyberwoof> My /var/log/mythtv/mythfrontend.log file keeps growing huge.  It is completely filling up my root partition.  It seems to be around 5.2 GiB right now and my hard drive is full.  All the log keeps saying is "LiveTV forcing JumpTo 1".  Any way to fix this?
[20:10] <EvilGuru> Does 9.10 (or the alphas which will one day become such) support the iMON LCD/remote out of the box, or does one need to manually compile lirc & friends
[20:17] <EvilGuru> As poking around the ubuntu forums 8.04 users and 8.10 users seem to be having some trouble with it
[20:25] <foxbuntu> EvilGuru, depends on the device, some of them yes, some of them no
[20:26] <EvilGuru> Guess I'll need to wait until my case comes to know
[20:26] <foxbuntu> EvilGuru, Antec Silver or Black?
[20:26] <EvilGuru> (Silverstone GD01B-MXR
[20:26] <foxbuntu> oh
[20:26] <foxbuntu> yeah...not sure which imon they use
[20:33] <EvilGuru> Well I always have my Hauppauge remote if things don't work
[21:34] <t1ger> !help
[21:34] <Zinn> !help For a  complete list of my knowledge visit: http://www.baablogic.net/Zinn.cgi  Other available commands: !status, !about, !bug [bug_number].
[21:56] <IOU> Is there a way I can re-scan the video collection from the command line ?
[22:17] <IOU> anyone ?
[23:43] <IOU> Is there a way I can re-scan the video/music collections from the command line ?


[10:50] <Kano> hi BenC , rtg , would you like to merge <IP_ADDRESS> (then you could drop my uvcvideo patch)
[10:52] <Kano> basically only the position and comment is differnt
[23:37] <mermaidman> I ask that the kernel devs include ext4
[23:53] <mermaidman> its not that hard to tick the option in the kernel config
[23:55] <sn9> not that hard to use dkms, either
[23:55] <mermaidman> all other major dists have ext4