[04:48] <MTecknology> If I have a newer version of a package that's un universe for lucid; is it possible to get the newer version into backports?
[04:49] <ebroder> MTecknology: is that version in maverick or natty?
[04:50] <MTecknology> ebroder: nope.. I'm hoping to get it into natty soon though
[04:50] <ebroder> MTecknology: backports only happen from ubuntu releases, so once the version is in natty, then you can file a backport bug
[04:51] <MTecknology> ebroder: thanks :)
[04:51] <MTecknology> ebroder: so could it be backported to both maverick and lucid?
[04:51] <ebroder> sure
[04:51] <ebroder> actually, it would have to be
[04:51] <MTecknology> yay
[04:51] <ebroder> because there are rules about the upgrade path with backports enabled
[04:52] <ebroder> (if you have a backported version of a package installed, that package should get upgraded when you do a release upgrade of your system, either from a backport in the newer release, or the package the backport was backported from. *phew*)
[04:55] <MTecknology> ebroder: the current version of the package has some bugs in it - they're as trivial as.. there should be a space in this comment line - if I made a debdiff for that - would that fix make it into lucid; or would it be just too trivial at this point?
[04:55] <ebroder> do the bugs actually affect functionality? "space in this comment line" sounds aesthetic
[04:56] <MTecknology> the comment is part of an example config - but no- it's pretty aesthetic
[04:56] <ebroder> we have a process for fixing packages in stable releases
[04:56] <ebroder> !sru | MTecknology
[04:56] <MTecknology> ebroder: I was just looking at bug 655407
[04:57] <ebroder> i don't know nginx config - does that cause an error, or does it cause the line to be treated as a comment?
[04:57] <ebroder> if it's an error, then it could maybe be fixed with an sru
[04:58] <MTecknology> #includefastcgi_params;  <-- if you tried to uncomment that line and use it - you would get an error that wouldn't let nginx start
[04:59] <ebroder> ah, i see. that's a little harder to call
[04:59] <MTecknology> the way it exists now would not cause an error at all
[05:00] <ebroder> i don't decide whether bugs qualify for srus or not, but my inclination would be to leave it, and assume that an admin intelligent enough to uncomment that line would be intelligent enough to add the missing space
[05:00] <MTecknology> alrighty
[05:00] <MTecknology> If I get this package into natty and it goes through backports the issue will go away anyway
[05:01] <ebroder> err, well, to step back, are you trying to get a backport just to fix that bug, or because there are actually new features?
[05:01] <MTecknology> crap ton for new features
[05:01] <ebroder> ok, good. then backports is the right answer
[05:02] <MTecknology> actually- it's from nginx-0.7.67 to nginx-0.8.53
[05:03] <MTecknology> ebroder: thanks :)
[05:03] <ebroder> np
[05:04] <MTecknology> ebroder: so now I just need to figure out bug 547267 for my package; fix it for the other package; get that one fixed via SRU if it's required (slipping in the space); and woohoo
[05:12] <MTecknology> ebroder: heh... looks like that work has already been dealt with :)
[05:13] <MTecknology> ebroder: http://bazaar.launchpad.net/~nginx/nginx/debian/revision/91 && https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/616685
[05:18] <micahg> lfaraone: I gave you the task of updating sugar-firefox-activity to Firefox 4 once it's in Natty, is that ok?
[05:28] <MTecknology> how do I add a lintain overrid?
[05:28] <MTecknology> override*
[05:35] <Rhonda> MTecknology: See man dh_lintian - you put them into debian/$packagename.lintian-overrides
[05:35] <MTecknology> Rhonda: thanks :)
[05:38] <MTecknology> Rhonda: I guess lintian isn't complaining about what I thought it would - instead it's complaining about something I'm confused about :P
[05:39] <Rhonda> But only add overrides if you really are sure lintian is wrong there.
[05:40] <Rhonda> And if it's wrong it might be proper to teach lintian to guess right ;)
[05:40] <MTecknology> Rhonda: It's complaining about XSBC-Original-Maintainer: being used
[05:40] <ebroder> MTecknology: that just means you have an old lintian
[05:40] <MTecknology> oh
[05:40] <Rhonda> MTecknology: Are you using the Debian lintian? It might be that this got patched in only in Ubuntu.
[05:40] <ebroder> although i think it's just Original-Maintainer these days (no XSBC- needed)
[05:40] <MTecknology> I'm using lucid
[05:41] <Rhonda> lucid shouldn't be that old for that …
[05:41]  * ebroder goes rumaging for his lucid vm...
[05:41] <Rhonda> So adding an override for that should be the wrong approach, me thinks.
[05:41] <MTecknology> syntax hilighting seems to like XSBC-Original-Maintainer but not Original-Maintainer
[05:41] <MTecknology> yay for older things
[05:41] <Rhonda> What does the long description of the message say?
[05:42] <MTecknology> I'll move all my stuff to az maverick vm..
[05:42] <Rhonda> Then maybe the syntax hilighting is outdated, not lintian. ;)
[05:42] <MTecknology> W: nginx source: unknown-field-in-dsc original-maintainer
[05:42] <MTecknology> I wasn't saying that was an error or anything :)
[05:42] <Rhonda> Did you check with the documentation/wiki?
[05:42] <MTecknology> ?
[05:43] <ebroder> ah - "  + [RA] Ignore Original-Maintainer if the version contains ubuntu."
[05:43] <Rhonda> Right, but adding overrides should be done only after full check :)
[05:43] <ebroder> MTecknology: what's your version number for post-merge?
[05:43] <MTecknology> wow- I've been battling for a while and yet I still feel so green
[05:43] <MTecknology> ebroder: no idea..
[05:44] <Rhonda> MTecknology: green is good, I like my packages green. ;)
[05:44] <Rhonda> But yes, XSBC-Original-Maintainer is documented in the wiki everywhere …
[05:44] <MTecknology> so both would be right?
[05:44] <ebroder> Original-Maintainer is preferred now
[05:44] <MTecknology> ok
[05:44] <Rhonda> https://wiki.ubuntu.com/UbuntuDevelopment/FAQ speaks of XSBC-Original-Maintainer
[05:45] <Rhonda> ebroder: Then the documentation should get updated. :)
[05:45] <Rhonda> https://wiki.ubuntu.com/PackagingGuide/Howtos/PackagingFromScratchHelloControl the same.
[05:45] <Rhonda> Only matches for XSBC-O-M, no match for O-M on its own without XSBC prefix: https://wiki.ubuntu.com/Home?action=fullsearch&context=180&value=original-maintainer&fullsearch=Text
[05:46] <MTecknology> https://wiki.ubuntu.com/PackagingGuide/Complete <-- I was trying to find something here to teach me about using lintian
[05:46] <MTecknology> I need to stop using a lucid chroot for this, huh?
[05:46] <Rhonda> MTecknology: Maybe it should be renamed to /InComplete then. :P
[05:47] <ebroder> you used XSBC-Original-Maintainer because dpkg didn't know about Original-Maintainer yet, but i thougth it had learned
[05:47] <ebroder> but looking at update-maintainer, it still uses XSBC-O-M, too. so maybe i'm just really confused
[05:47] <Rhonda> More seriously, guess it can't go into deeper details on all areas, there is too much to cover.
[05:49] <MTecknology> every time I start with packaging stuff I feel like I'm working in whitespace code :P
[05:50] <MTecknology> ok- I upped myself to a maverick chroot and no more errors
[05:51] <MTecknology> is there any guide to lintian?
[05:51] <MTecknology> I've just been using debuild -S -sa and seeing what errors it reports
[05:51] <MTecknology> if there's a way I could make it more verbose and yell at me more- I'd actually like that
[05:52] <Rhonda> I always use lintian -IE --pedantic on the resulting .changes file.
[05:52] <MTecknology> lol... pedantic
[05:52] <MTecknology> sounds like my life
[05:52] <Rhonda> That yields some things that might be ignored, but it catches much more.
[05:53] <MTecknology> that would be exactly what I was asking for :D
[05:53] <MTecknology> and it only had one thing to complain about
[05:53] <Rhonda> It gives things that one might want to think about.
[05:53] <Rhonda> It also gives typos in upstream code. :P
[05:53] <MTecknology> I: nginx source: quilt-patch-missing-description nginx-echo.diff
[05:54] <MTecknology> that's all it gave me :)
[05:54] <Rhonda> See, and that's a useful thing.
[05:54] <Rhonda> You *really* should add a patch description. :)
[05:54] <MTecknology> I'm doing it now
[05:54] <Rhonda> … given that you did the patch.
[05:54] <MTecknology> I really need to get my changes merged into debain or I'm going to go insane :P
[05:56] <MTecknology> diff -urN nginx/modules/nginx-upstream-fair/config nginx.debian/modules/nginx-upstream-fair/config
[05:56] <MTecknology> what's that?
[05:58] <MTecknology> Rhonda: there we go - lintian -IE --pedantic whines about nothing
[05:59] <MTecknology> now to add example files and clean the thing up...
[05:59] <MTecknology> I might actually do something useful :D
[06:01] <MTecknology> Rhonda: ebroder: Thanks :)
[06:31] <MTecknology> If I'm adding default website files to a package that will be viewable from the internet but not changeable (static html 644); would that go in /usr/share/app/web ?
[06:33] <micahg> MTecknology: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA
[06:34] <MTecknology> micahg: perfect, thanks :D
[06:35] <micahg> MTecknology: actually I think this is what you're looking for: http://webapps-common.alioth.debian.org/draft/html/ch-issues.html
[06:35] <micahg> hmm, that's a draft, maybe not
[06:36] <MTecknology> micahg: I'm just putting two static html files there
[06:38] <MTecknology> micahg: looks like exactly what I needed - thanks much
[06:38] <micahg> MTecknology: np
[06:40] <dholbach> good morning!
[06:40] <MTecknology> dholbach: HI!!!
[06:41]  * MTecknology pounces
[06:41] <dholbach> hi MTecknology
[06:41] <MTecknology> dholbach: howdy, how ya been?
[06:41] <dholbach> still jetlagged from getting home from UDS but alright, how 'bout you?
[06:43] <MTecknology> extremely tired - probably feeling about the same as you - I don't really know what jetlag feels like though. I've been getting 3hr/night :P - I'd go to sleep now but I'm too hung up on making this package good enough that some parts can be merged to debian and the rest can find its way into main for natty
[06:43] <MTecknology> hopefully..
[06:43] <StevenK> MTecknology: Jetlag is "I'm so tired and broken, I don't know what day it is."
[06:44] <MTecknology> StevenK: oh.. then ya - I'm feeling about like that- I dealt with a co-working again so I know prior to 00:00 was monday.. he always reminds me what day it is...
[06:45] <MTecknology> if something is completely lintian clean, used by a lot of people, and blah blah (basically fixing all bugs in the nginx packaging), how hard would it be to get it into main for natty?
[06:45] <dholbach> go! to! bed!
[06:46] <dholbach> 3hr/night is only good for killing yourself
[06:46] <StevenK> MTecknology: We would probably only want one webserver in main
[06:46] <micahg> MTecknology: https://wiki.ubuntu.com/MainInclusionProcess
[06:46] <StevenK> And I like Apache far too much to stop using it.
[06:47] <MTecknology> dholbach: I've been liquidating my company and it takes a lot to do - especially with the people I've been dealing with - but after that a normal sleep pattern should show up :)
[06:47] <MTecknology> StevenK: but apache is horrible
[06:47] <micahg> apache FTW
[06:47] <StevenK> MTecknology: How is it horrible?
[06:47] <MTecknology> it's fat bloated and ugly
[06:47] <StevenK> It's none of those?
[06:47] <MTecknology> of course it is :)
[06:47] <MTecknology> religious debates :P
[06:47] <micahg> MTecknology: main doesn't matter so much unless it's going to be on a CD
[06:48] <StevenK> And that
[06:48] <MTecknology> oh
[06:48] <micahg> MTecknology: only other difference is Security team active support vs community support for security
[06:48] <StevenK> I like my servers to use main-only, but if you want something like rwhod, you need universe anyway
[06:49] <micahg> MTecknology: and universe will be going away eventually, so it'll all end up in main :)
[06:49] <MTecknology> micahg: oh?
[06:49] <StevenK> ArchiveReorg
[06:50] <StevenK> I'm unhappy about it, but the only reason I have currently is it turns into scorched earth for mirrors
[06:50] <MTecknology> universe will be merged with main?
[06:51] <micahg> MTecknology: https://wiki.ubuntu.com/ArchiveReorganisation/Components
[06:52] <MTecknology> micahg: so will motu go away..?
[06:52] <micahg> MTecknology: no, name change to Masters of the Unseeded
[06:52] <MTecknology> .. *blink*
[06:53] <MTecknology> I was barely starting to understand some of this
[06:54]  * micahg would explain more, but sleep is calling
[06:54] <MTecknology> unseeded means?
[06:54] <StevenK> Packages not in any seeds
[06:55] <micahg> MTecknology: not in a seed: http://people.canonical.com/~ubuntu-archive/germinate-output/
[06:55] <MTecknology> seeds meaning?
[06:55] <StevenK> Things like -desktop and kubuntu are grown from seeds - a list of which packages to include
[06:55] <StevenK> The seeds live in bzr branches on LP
[06:56] <MTecknology> like code.launchpad.net/nginx ?
[06:56] <StevenK> https://code.edge.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.natty
[06:58] <MTecknology> I think maybe after I liquidate my company and get out of school I need to see if I can find a motu mentor to help me get a clue
[06:58] <MTecknology> I feel like I've been failing pretty bad
[06:59] <MTecknology> For example - I spent a lot of time working and perfecting one package that's in debian and ubuntu - but I don't know if my work will grow beyond that ppa (hoping it does)
[07:02] <MTecknology> dholbach: I hear you're a good motu mentor!
[07:02] <dholbach> no, I'm not
[07:02] <dholbach> I'm consistently running out of time on most things
[07:03] <MTecknology> sounds about normal for a FOSS activist :P
[07:04] <StevenK> dholbach: How's your patch for 30 hour days coming?
[07:04] <MTecknology> 6hr to sleep and 24hr to work! :D
[07:04] <dholbach> StevenK, not there yet
[07:04] <dholbach> ran out of time
[07:05] <MTecknology> maybe tomorrow I'll fire a request off to the list. I feel like I at least have a slight grasp on some things so maybe I'm not as lost as I feel... or maybe someone will start working with me and a week later come hang me..
[07:05] <MTecknology> I'm going to pass out for now - see ya'll in about 4hr (unless I decide to sleep in)..
[15:36] <jrgp> anyone have and recommendations for packaging php scripts or are phpmyadmin/roundcube good enough references?
[15:37] <persia> Often it's as simple as base boring packaging and a detailed debian/foo.install file.
[15:37] <persia> Feel free to use something else as a reference, but if it seems complicated, ask immediately, because it oughtn't be.
[15:37] <jrgp> can you please link me to a good tutorial?
[15:38] <jrgp> is using dpkg-deb --build bad?
[15:38] <persia> No, because it's not written up nicely.
[15:38] <persia> I can link to a slightly out of date one though.
[15:38] <persia> Yes.
[15:38] <jrgp> yes i've noticed the inconsistent docs
[15:38] <persia> https://wiki.ubuntu.com/MOTU/School/PackagingWithoutCompiling
[15:39] <persia> Needs more people working on them.  If you've time, help is appreciated.
[15:40] <jrgp> near unlimited, i spend it mostly dealing with forums and my own apps
[15:41] <jrgp> what's the deadline to get new stuff into notty? and if i instead get it into debian trsting/unstable, will it wind up in ubuntu eventually?
[15:41] <SpamapS> its actually "natty", and there's a release schedule.. digging up link...
[15:42] <jrgp> sorry typo on phone
[15:42] <SpamapS> https://wiki.ubuntu.com/NattyReleaseSchedule
[15:42] <jrgp> thanks
[15:42] <SpamapS> jrgp: you'll want to get it in before FeatureFreeze
[15:42] <jrgp> rigtht  so pretty much anything debian gets inevitably gets into ubuntu?
[15:43] <persia> With a few very specific and very intentional exceptions, yes.
[15:43] <jrgp> neat
[15:44] <jrgp> stuff like the differing init system?
[15:44] <persia> http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
[15:46] <persia> The list changes regularly, but getting on it is hard: in general, it's easier to make a source package that works fine for both Debian and Ubuntu, and then only maintain the one package.
[15:52] <micahg> can someone please open tasks for me on bug 669620?
[15:52] <persia> micahg, approving...
[15:52] <micahg> persia: am I correct in that due to the nature of this regression, it's not worth sounding the alarms on?
[15:53] <micahg> persia: and thanks BTW :)
[15:54] <persia> I don't think that's a case for all-hands-on critical regression, no.
[15:54] <micahg> persia: ok
[17:09] <ari-tczew> TheMuso: ping
[17:10] <TheMuso> ari-tczew: Just ask your question and I will respond when I am around. About to go AFK, but will answer when I get back.
[17:13] <ari-tczew> TheMuso: could you merge gnome-speech ?
[17:15] <TheMuso> ari-tczew: Do you really need it for something? its no longer supported upstream. In fact, in the medium to long term, it needs to e considered for removal, both in Ubuntu and Debian.
[17:16] <ari-tczew> TheMuso: we are cleaning remaining merges. I can take a look if you are not interested.
[18:19] <achiang> does anyone know if the plugins shipped in gstreamer0.10-ffmpeg are free/unencumbered?
[18:19] <achiang> or can point me at the appropriate forum to ask?
[18:19] <xteejx> webtest 1.2.2-1 FTBFS, but lcoally it builds fine, could it be the recent update to python 2.7 that fixed it? And can I request a rebuild?
[18:20] <ebroder> xteejx: i'll trigger a build retry
[18:21] <xteejx> ebroder: Cool, thank you :)
[18:21] <ebroder> np
[18:40] <xteejx> If a package is patchless, do we start using quilt or just go ahead and edit the source directly?
[18:43] <ari-tczew> xteejx: directly
[18:44] <xteejx> ari-tczew: That's what I thought, wasn't sure. Thank you :)
[18:44] <ari-tczew> np
[18:59] <ari-tczew> xteejx: are you going fix all FTBFS related to missed links? :)
[19:00] <xteejx> ari-tczew: lol Cheeky ;) We'll see how it goes, but I expect an accepted MOTU application for this hehe
[19:01] <ari-tczew> xteejx: for MOTU you have to show contribution in other areas like merges
[19:01] <xteejx> meh...that'll be the next things then :)
[19:01] <xteejx> s/things/thing
[19:25]  * persia notes that there is no requirement for aspirant MOTU to demonstrate activity in any specific area (including merges), but only a requirement that the aspirant demonstrate care for the quality of the archive as a whole and acceptance as a peer by existing MOTU
[19:28] <kklimonda_> o/ persia
[19:28] <kklimonda_> and good evening
[19:30] <persia> Good morning.
[19:30] <kklimonda_> does someone know why does gtkmm2.4 has such a weird version appended to libgtkmm-2.4?
[19:30] <kklimonda_> it's libgtkmm-2.4-1c2a
[19:30] <persia> probably http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
[19:31] <persia> 'c2' was the result of one ABI transition in Debian, and 'a' the result of another (I forget which precisely).  It's supposed to go away when upstream moves to a new ABI, but those guys have been especially good about maintaining stability and compatibility.
[19:32] <kklimonda_> :)
[19:33] <kklimonda_> persia: that's why I was asking, I knew where does the 1 come from but c2a was completely alien to me (it's neither in so name nor in the result of objdump). Should I dig into the document you have linked to read more about this particular case (when upstream doesn't bump abi but for some reason debian does)?
[19:34] <Rhonda> \o persia :)
[19:36] <persia> kklimonda_, It's worth reading the document, but it won't help in this case: it just indicates to follow the ABI.
[19:36] <kklimonda_> persia: I did in the past but I couldn't recall it mentioning this case
[19:37] <persia> And the cases where Debian bumps ABI but upstream doesn't are rare (like a new version of gcc that generates incompatible C++ code)
[19:37] <kklimonda_> (I've assumed that it either has been updated or I missed something)
[19:37] <kklimonda_> right
[19:40] <persia> No, you didn't miss something.  I think the example I used above was the "c2" part (but I'm unsure).  It happens rarely, and when it happens, affects just about every package in the archive.
[19:43] <Rhonda> Wasn't that library transition that libgtkmm links in, not within libgtkmm itself?
[19:44] <Rhonda> What comes to my mind is libpng transitions which happen regularly and require a rebuild of depending libraries to not make things segfault when having one library linked against the old libpng abi and another library against the new one used in the same application.
[19:44]  * Rhonda . o O ( rule #1: It's always the graphics' libraries )
[19:45] <persia> I thought we came up with a better way than ABI string extensions to deal with libpng.
[19:45] <Rhonda> Didn't follow recent development on that grounds. Then it's libjpeg. ;)
[19:46] <ajmitch> ah, special cases
[19:46] <persia> But in the case of libgtkmm, I know that at least one of the transitions had to do with how the C++ compiler allocated memory, and I think the other might have been something about ELF format (but I forget: 'c2' was 2004 or 2005 and 'a' was maybe 2006)
[19:46]  * Rhonda . o O ( rule #2: there's always another graphics format library left to blame )
[19:46] <ajmitch> was one of them a change in the c++ symbol mangling?
[19:46] <lifeless> yes
[19:46] <lifeless> a standard was introduced
[19:47] <persia> Maybe that was 'a'
[19:48] <ari-tczew> hmm. where we should add missing libs? to LDFLAGS or to LIBS?
[19:48] <ari-tczew> to fix FTBFS
[19:48] <persia> Depends on the upstream build system.
[19:48] <ari-tczew> omg, next tone of theory
[19:49] <ari-tczew> persia: how check it?
[19:50] <Rhonda> !omg ari-tczew
[19:50] <Rhonda> huhm
[19:50] <Pici> You need a pipe
[19:50] <Rhonda> | missing? :)
[19:50] <persia> There's no easy way, unfortunately.  One has to look at the upstream build system, and determine how they *use* things like LDFLAGS or LIBS
[19:50] <ari-tczew> Rhonda: fail? :(
[19:50] <micahg> Pici: I'm wondering if you highlight on bot failures :)
[19:51] <Pici> micahg: I just happen to notice them.
[21:24] <lfaraone> micahg: sure.
[21:25] <lfaraone> micahg: I doubt that many changes will be necc., since we're not shipping any extensions with it, nor bundling Firefox itself.
[21:25] <micahg> lfaraone: ok, cool