[00:00] ryanakca: it has some little differences... like the h and the r being excanged [00:00] lfaraone: both are orthogonal === ZehRique_ is now known as ZehRique [01:50] I was wondering if it was okay to contact upstream about including gpl info into the source code, and if getting the okay, including a patch with the package? [02:03] binarymutant: If upstream agrees about having the GPL info in the source (like it should be), I would try and get them to make the changes themself. That way, we don't even need to patch it. [02:04] nhandler, I just didn't want to wait for another release to have those gpl paragraphs included in the source code :/ [02:04] directhex, ping [02:05] binarymutant: It all depends on upstream. Some upstream developers have no issue relasing new versions of the application that only fix minor issues (like the GPL one) [02:05] NCommander, sleepy pong [02:05] directhex, I have a patch for mono on armel, where do you want it? [02:05] thanks nhandler for the info [02:05] NCommander, bugs.debian.org. or if you prefer, pkg-mono@lists.debian.org [02:06] NCommander, actually, maybe upstream wants it? i could bridge it into novell bugzilla tomorrow [02:06] directhex, ok, ping me tommorow === santiago-pgsql is now known as Guest63277 === Guest63277 is now known as santiago-ve [03:13] nhandler, Note that we're note supposed to patch the license while packaging, which it probably a stronger argument for doing/not doing than most others. [03:15] persia: Thanks for clarifying. I knew it wasn't commonly done. I also knew it wasn't recommended. However, I wasn't sure if it wasn't allowed. [03:16] nhandler, Essentially, the licensing is the license extended to the packager. Such a license (WTFPL) generally doesn't permit the user to modify the license while not altering the attribution when distributing. === not_rly is now known as orly_owl [03:17] s/WTFPL/WTFPL excepted) [03:17] nhandler, So, if you take licensed code, and modify it a bit, and create something different, you can do license cleanup. [03:17] (to a limited degree, depending on the license). [03:18] If you're just packaging, and claiming that this is upstream source, with upstream licensing, you generally can't. [03:18] (again, WTFPL excepted) [03:19] (note: for those seeking a definition of "free" that goes well beyond anarchy, the WTFPL is a good choice) [03:26] If anyone has time, could you look at the buildlogs for herwigpp in my ppa: https://launchpad.net/~jsmidt/+archive [03:26] The build isn't working [03:27] It has this error: dh_shlibdeps: command returned error code 512 [03:28] I'm new at packaging and I am trying to figure out what exactly is going wrong. [05:41] hi [05:42] good morning [05:42] morning [05:43] i'am confused... i want to contribute to ubuntu project ..but i dunno where to start [05:43] i thought of packaging [05:43] edajai: what are you interested in? [05:43] ah great [05:43] programming [05:43] check out https://wiki.ubuntu.com/MOTU/GettingStarted [05:44] i know c++ [05:44] it links to a lot or resources like the packaging guide, tutorials, videos, etc [05:44] i thought MOTU was for packaging only [05:44] we fix a lot of bugs too :) [05:44] so knowing a programming language or two definitely helps [05:44] oh..nice [05:45] Hi dholbach :-) [05:45] can u please provide me links to relatively less complex bugs that can be easily fixed [05:45] once you feel like you've played with the toys^Wtools a bit, there's also lists of bugs that might be easy to start with on the wiki page I gave you [05:45] hi dholbach :) [05:45] hi fabrice_sp [05:45] hi nellery [05:45] toys^Wtools??? [05:45] tools [05:46] k [05:46] which IDE would u recommend? [05:47] regarding "^w": http://en.wikipedia.org/wiki/%5EW [05:47] I need some help with a watch file. I have this line inside: http://sf.net/dvdstyler/DVDStyler-(.*)\.tar\.bz2 [05:47] edajai: just go with any editor you're familiar with for now [05:47] but I'm getting DVDStyler-1.7.1b1.tar.bz2 as newer than DVDStyler-1.7.1.tar.bz2, when b1 is neta [05:47] s/neta/beta/ [05:48] k [05:48] How can I get that 1.7.1 is newer than 1.7.1b1 ? [05:48] fabrice_sp: [05:48] daniel@lovegood:~$ dpkg --compare-versions 1.7.1b1 gt 1.7.1 && echo TRUE [05:48] TRUE [05:48] daniel@lovegood:~$ [05:48] seems that upstream's to blame [05:49] wow... we're at bug 299776 now [05:49] Launchpad bug 299776 in evolution "evolution spontaneously crashes." [Undecided,New] https://launchpad.net/bugs/299776 [05:49] dholbach: that's what I thought :-) [05:49] thanks [05:49] I guess today we'll get to bug 300000 [05:49] Error: Launchpad bug 300000 could not be found [05:49] ubottu: not yet [05:49] Sorry, I don't know anything about not yet [05:50] do we have stats on bugs/versions? Just curious :-) [05:50] we should have, if you ask me :) [05:50] lol [05:51] just curious.. is there any work being done on delta deb upgrades?? [05:52] fabrice_sp, You might want to look at uversionmangle in the uscan manpage. changing the 'b' to "~b" might do it. [05:53] fabrice_sp, If you do that, you probably also want to adjust 'a' in case upstream releases an alpha, rather than a beta. [05:54] persia: there have been alpha, so I'll have a look at that! Thanks! === dholbach_ is now known as dholbach [06:19] It worked! Thanks persia for the solution! This is the line I put: opts=uversionmangle=s/b/~b/;s/a/~a/ [06:20] fabrice_sp, Would you mind adding some documentation on that hint, and the specific regex to the wiki page on creating watch files? [06:20] This is the second or third time I've seen the question, and I think maybe the uscan manpage language isn't accessible to some people. [06:21] fabrice_sp, Also, you might consider something like /([a-z])/~$1/ (if I remember perl correctly) to generalize rather than calling two match expressions. [06:28] persia: I'll have a look at the wiki, but that's true that as it's perl regex, it's not so easy :-) [06:29] fabrice_sp, If you can't get the perl syntax right, that's fine. Just the hint for 'a' and 'b' will probably save a lot of people pain. [06:31] I'm used to vi, so I know this kind of regex, but as it's perl, it's a bit different. For sure it's not simple :-) [06:31] Anyway, I'll update the wiki :-) [06:40] rainct: oh, thanks. === jmarsden_ is now known as jmarsden [08:38] geser: FYI ... about 20 jboss related packages have entered 'NEW' queue in Debian main. Let's hop our build failures will get solved this time. [08:43] if someone can review my package http://revu.ubuntuwire.com/details.py?package=sqliteman .... === gouki_ is now known as gouki [09:05] can somebody help me and review http://revu.ubuntuwire.com/details.py?package=teamgit [09:10] slytherin: that would be awesome [09:16] bain: It seems that is something like git-cola. http://cola.tuxfamily.org/screenshots.php. [09:16] bain: I will have a look at it when I get back home from school. [09:16] iulian, yes its something like git-cola but with different ultimate goals [09:16] Looks interesting, I wonder what it can do. [09:16] OK. [09:17] iulian, thanks, is it a bad thing to have two packages doing similar thigns? [09:18] bain: I believe not. But IMHO we should keep the one which is the best. [09:18] iulian, teamgit will be the best ;-) (hint i am the author :p ) [09:19] Yes, I saw :) [10:43] Hello [10:44] any MOTUs around ? [10:46] Probably about half of the active ones. Better to ask a specific question, as it collects more interest. [10:47] the usual approach I had to ask that specific question every 10 joins or so, without much results, I am trying a new approach [10:47] can someone advocate http://revu.ubuntuwire.com/details.py?package=amoebax ? Thanks [10:48] Oh. Yeah. That question doesn't tend to collect much interest except on REVU days, unless someone is particularly bored. [10:48] Also, it's probably better to ask for a review than an advocation. [10:48] I already got enough reviews, I believe its the proper time for advocation [10:49] 4 months reviewing should be sufficient [10:49] Well, a review will result in an advocation if it's ready. [10:49] Unless you've already got one advocate; once you've got one, advertising the fact is a good idea. [10:49] Also, there were only one or two REVU days during intrepid, so it's really only been about 3 weeks that the queue has been being processed much. [10:50] RAOF, Good point. [10:50] * persia usually looks for one-advocate packages with problems. [10:50] persia, the package was already reviewed before intrepid, that counts because the package was not started from scratch [10:52] I am confident on the package status, that is why I am asking for someone with the ability to advocate [10:53] joaopinto, Where can I get the originals for the art? Or where is this stated? I don't see it from my quick look so far, but it appears to be a requirement of the license. [10:54] which originals ? The art is contained on the source [10:54] joaopinto, The license for the art requires that the recipient be provided with information to collect the originals. [10:54] I don't know where the originals live, or anything about them. If you also don't, I think you've a bit of investigation to do. [10:55] "the originals" are contained on the source [10:56] Surely that's the distributed copy. [10:56] * persia reads the license again [10:56] Also, in the ,desktop file, why drop the category "LogicGame", and why add "StartupNotify=true"? [10:58] No, it clearly states "You can freely distribute the copies of these works, modified or not, whatever their medium, wherever you wish, for a fee or for free, if you observe all the following conditions: ... specify to the recipient where he will be able to access the originals (original and subsequent)." [10:59] From my reading, it just needs a URL somewhere. Maybe it's in the README (haven't gotten to that file yet). [10:59] persia, that statement applies to derivated/modificated work, the artwork distributed is the "originals" [10:59] "modified or not" [11:00] persia, the download link is on the top of the copyright, that covers the "originals" availability requirement [11:00] regarding startupnotify, what is wrong on using it ? [11:00] * persia refuses to argue, but will need to find a link somewhere to advocate with that license [11:01] If the application doesn't support it, it hangs a process for 120 seconds. [11:02] how is that checked, exit code ? [11:03] I'm not 100% sure, but my understanding is that it's a window manager hint callback that the application can use to say "I've started cleanly". There's a hardcoded 120 second timeout to stop the "Starting application" pointer if it's not supported, but it's best to only use it when it is supported. [11:03] persia, be more specific, what link do you need related to the license, there is a link which points to the page from where you can get the original art.. [11:03] ok, I will update the desktop patch [11:03] joaopinto, Yes. I'll be looking at that. I've not gotten to it yet. [11:07] joaopinto, Your watchfile doesn't work for me. [11:09] persia, please post the comments on revu, I will only be able to fix the package later today :\ [11:09] joaopinto, Oh, sure. No problem. [11:16] persia, if you are in a reviewing mood , please consider watching my pkg (http://revu.ubuntuwire.com/details.py?package=sqliteman) .. thanks a lot! [11:28] eMerzh, I'll take a quick look, but am still running the processing for the amoebax review. [11:28] eMerzh, No point mentioning debian/patches/00list in the changelog. [11:29] Be good to have a README.source [11:29] oki thanks persia [11:29] ok [11:30] Better to use /usr/share/cdbs/1/rules/dpatch.mk than the mess you have in debian/rules [11:31] ALso, make triple-sure README isn't ending up in the binary package, as it's useless for end-users, but CDBS might try to include it by default. [11:31] Nothing else obvious from glancing through debian/ [11:49] persia, what should be in the README.source? [11:52] eMerzh, http://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource but ideally you want to point at common shared instructions for dpatch. [12:08] eMerzh: https://wiki.ubuntu.com/README.sourceHowTo [12:09] (note especially the note on the top of the page that it is becoming obsolete) [12:10] ah ok, thanks slytherin ...how should i point to /usr/share/doc/dpatch/README.source.gz ? [12:16] eMerzh: no idea. persia, can you please help with that question ^^? [12:16] :) [12:20] Just some informal text. Something like "This package uses dpatch for patch management. Please see usr/share/doc/dpatch/README.source.gz for usage details" or something. === thekorn__ is now known as thekorn === LucidFox_ is now known as LucidFox [15:19] hm. how much pain and/or stabbing is involved in bundling a non-final RC or pre-RC of something into a release, then SRUing the hell out of it ASAP? [15:20] directhex, Heaps. SRUs should be cherrypicks, except when there is a *very* convincing reason. [15:20] the latter part will be a pain, the former part will not. [15:27] monodevelop has been ancient and crap for ages - but upstream have been warning us not to try and use a pre-release alpha tarball as something to support for months on end. the next major release is due in 3-4 months [15:29] Right. Push to Jaunty, Track upstream, and get final in the release. [15:29] backport final to intrepid/hardy. Let the cruft remain otherwise. [15:29] * persia isn't on the SRU team, but is opinionated [15:30] directhex: is the situation similar to how it was for FF 3.0 beta in hardy? [15:30] persia, i wasn't actually talking about intrepid/hardy (it needs a new mono stack, so won't happen officially). i really meant for jaunty, since it's likely to miss assorted freezes [15:30] slytherin, AFAIK yes [15:31] directhex, If you want to pre-check with MOTU release, send mail to ubuntu-motu@lists.ubuntu.com describing the plan,and asking for MOTU release acceptance in advance. [15:32] persia, as someone who isn't on the SRU team, but is opinionated, would you back a hardy-ff3-style plan? [15:32] directhex: You might also consider freeze exception depending on when the final release comes out. [15:33] directhex, If you're not SRUing, it's not an SRU decision: it's a Release decision. Personally, I don't like to see snapshots in releases, but if you're sure you can get a real release for e.g. beta, I'd think it was good (but it's really a MOTU Release decision). === kirkland` is now known as kirkland [16:16] nixternal: geser: hey guys ... would you mind voting on my core-dev application sometime soon? thanks, cheers. [16:19] kirkland: I voted a while back [16:23] persia, there we go, ML mailed. i hope i've described the situation adequately [16:24] directhex, Cool. [16:24] nixternal: hey, hmm, i don't see it, in my inbox, or in the threaded archive [16:24] nixternal: i have your vote for my MOTU, back in September [16:25] nixternal: this is for core-dev, https://lists.ubuntu.com/archives/motu-council/2008-October/001725.html [16:29] kirkland: you are right, I sent it to persia only...I just resent it to the list...I apologize for that [16:30] So this is why I was sure you'd voted :) [16:30] nixternal: awesome, thanks ;-) [16:31] persia: hehe, ya :) [16:41] kirkland: I try to get it done today, actually I just wanted to start on it [16:41] Hello, I am trying to add a gconf schemas file to a debian source python debian package, but there remains an entry in the gconf database after uninstalling the package. I described the problem in the following thread: http://ubuntuforums.org/showthread.php?t=984014 Could anybody please tell me where the problem? [16:57] geser: great, thanks! [17:08] What I don't understand is why "gconf-schemas --unregister onboard.schemas" does not delete everything in the gconf database!? What could be the reason? If somebody has an idea that would be great. [17:20] is there any order to the REVU process? [17:20] like, the first packages in are the ones that get reviewed first? [17:22] JonReagan: not really [17:22] ah, thx [17:22] JonReagan: although we are trying to work through the backlog [17:23] ah, lol... yeah I noticed there were quite a few [17:24] good problem to have i guess [17:24] It overwhelming [17:24] yeah... sorry. I uploaded mine this morning ;) [17:24] JonReagan: except not everyone who uploads has the stamina to keep going [17:25] ah [17:25] So there's a lot of wasted time and effort [17:25] ah, that's not good [17:25] And many MOTUs don't really want new software in Universe [17:26] ah [17:26] well, I'm dedicated on working on my package, so at least that's one not to be worried about. [17:26] :) [17:26] JonReagan: There's > 1000 packages to maintain [17:26] ! [17:27] JonReagan: what package? [17:27] openproj [17:27] version 1.4, to be exact [17:27] it's my first package upload to revu [17:27] JonReagan: I'll take a quick look [17:27] * JonReagan does happy dance [17:28] oh, thank you so much! [17:28] http://revu.ubuntuwire.com/details.py?package=openproj - here's the link [17:28] JonReagan: you've been maintaining this for your own use? [17:29] for my own use? [17:30] I was hoping that it would find it's way into some repo for Ubuntu, either universe or multiverse [17:30] JonReagan: it's not been in a distro [17:30] not included in one yet [17:31] Ubuntu will be the first one [17:31] ok [17:32] JonReagan: you need to take the debian/ dir out of the tarball [17:32] JonReagan: since this is not a native package. [17:32] ah, ok [17:33] to upload the tarball after I have removed the debian folders, is there anything different from uploading the package with dput? [17:33] JonReagan: (I also make a comment on revu) [17:33] ah, thanks [17:34] JonReagan: lets get to that later [17:34] k [17:36] JonReagan: in debian/changelog, you have to trim it down to the latest version. We are only interested in what happens after Ubuntu submission [17:36] ok [17:37] distribution is jaunty not GA [17:37] k [17:38] just so I'll know... these changes need to be made in the original tarball and then recompiled for upload to revu? [17:38] JonReagan: and version will be (1.4-0ubuntu1) [17:38] * JonReagan writes it down [17:39] JonReagan: I am pasting my comments to REVU as well [17:39] thanks! [17:39] JonReagan: did you create a needs-packaging bug on LP? [17:40] yes I did... it got marked as a duplicate, however [17:40] the other bug was a request for openproj that I had made a year ealier [17:40] *earlier [17:40] and the request was for an old version [17:40] JonReagan: you need to close the LP bug in the changelog [17:40] ok [17:42] JonReagan: debian/control now [17:43] after compiling and installing, my package at "dpkg-genchanges: failure: cannot read files list file: No such file or directory" .... anyone has an idea how to fix it? google don't help me much on this.... [17:43] i change arch from any to all , but always the same pbm [17:44] do I need to place a link to the new lp bug in the changelog and debian/control? [17:44] JonReagan: Maintainer is: Ubuntu MOTU Developers [17:44] JonReagan: you will be XSBC-Original-Maintainer: [17:44] ah, wondered about that... thanks [17:45] JonReagan: Standards-Version is 3.8.0 now [17:45] ah... k [17:45] Is there a homepage for this app? [17:46] openproj.org [17:47] JonReagan: You need to work more on the long description. Look at the hints in the Debian Maintainers Guide [17:47] ok [17:48] JonReagan: Lemme just see if I can find a link for that [17:49] oh, thanks... I was hittin up google now [17:50] AHAHAH [17:50] I got bug #3000000 [17:50] Error: Launchpad bug 3000000 could not be found [17:50] I got bug #300000 [17:50] :-P [17:50] Launchpad bug 300000 in libgtk2-perl "FTBFS fix" [Undecided,New] https://launchpad.net/bugs/300000 [17:51] IT'S OVER 3000000!!!!! [17:51] (sorry :D) [17:53] mok0: I found it [17:53] http://www.debian.org/doc/maint-guide/ [17:53] thx [17:54] I think this is where I've seen the instructions on how to write a proper long description [17:55] jdong: That should be a bad things, isn't it? [17:55] s/things/thing/ [17:55] iulian, I fixed the teamgit package according to your comments [17:56] JonReagan: OK I have submitted a comment for your package, which will now appear in the "needs work" section... :-) [17:56] ah, thank you so much! :D [17:56] you have been a ton of help! [17:56] JonReagan: when you "dput" your changes file next time, it should include a diff.gz file that contains the debian/ dir (and nothing else) [17:57] JonReagan: glad to be of help :-) [17:57] bain: OK, will have a look at it again in a moment. [17:57] ah, k thx [17:57] JonReagan: I am not good at Java packages, so I have skipped some things for now [17:58] ok, I know some java folks who might be able to help me out on those [17:58] OK, dinnertime :-P [17:58] lunchtime for me ;) [17:58] JonReagan: it's more about Ubuntu policy [17:58] JonReagan: You might want to talk to slytherin or geser. They are good at Java packaging. [17:59] JonReagan: where to place things etc. [17:59] Bon appetit! hehe [17:59] iulian, judging from mok0's comments my diff.gz contains few files that are not correct [17:59] ah, ok. Thanks! I will get to work on the stuff you recommended [17:59] iulian, will fix and report back here [17:59] iulian: just saw your PM... I'll be back later [18:00] ooh, after I finish the fixes, do I need to recompile the original source file? [18:01] someone could help me to remove the README from the installed file? [18:02] JonReagan: Build the package and upload it again. [18:03] ah, thanks! [18:03] eMerzh: Upstream's README? [18:03] thank you so much everyone! [18:06] iulian, did the fix please review it whenever possible thanks [18:06] iulian, yep the readme about how to compile ,... [18:08] eMerzh: You can remove it from the debian/docs file. Sometimes README files are very useful but sometimes aren't, please double check when you remove it. [18:08] bain: OK, I'm looking at it now. [18:14] bain: I see that it's a native package. Do you want to ship the debian/ dir in the original tarball? [18:14] Or it's just a mistake? [18:14] geser: do you mind if I work on libjdic-java merge/sync? [18:14] iulian, no i do want to ship it [18:14] bain: Then please remove it. [18:15] Ahh, you do want. [18:15] Sorry, misread. [18:15] iulian, i don't have it in a debian/docs ....i haven't a docs file :) [18:17] bain: Remove -0 from the version since it's a native package. [18:17] iulian, ok should i do it now or wait for more of your comments [18:18] bain: What's with that debian/clean file? Please add that in the clean target in debian/rules. [18:19] iulian, actually i did that acting on your comment "Please merge rm -rf into dh_clean." [18:20] i obviously misunderstood [18:20] bain: I didn't tell anything about creating a debian/clean file :) [18:21] so i should just add the listing in the rules file in front of dh_clean? === Pici` is now known as Pici [18:23] slytherin: no, please go ahead [18:24] bain: $(MAKE) clean should do it for you. [18:24] kirkland: done [18:24] bain: Please rename that to [ ! -f Makefile ] || $(MAKE) clean [18:26] iulian, make clean does not get rid of these files [18:26] i use qmake for generating makefiles and can't figure out how to do that [18:27] bain: Well, I've never worked with qmake so I can't give you any advice about it. [18:28] Perhaps someone from this channel knows? [18:29] iulian, ok make distclean will do it, can i change to that? [18:30] bain: If it does, yes. [18:30] In the end we're trying to get rid of unwanted files. [18:40] * iulian is going to school to take his notebook. [18:40] I obviously forgot about it. [18:40] iulian, ok i have almost fixed all the things you told so far, thanks for your help [18:41] iulian, review whenever you get time next chao [18:42] bain: OK, good. Will review it again when I get back home. School is not so far. [18:43] iulian, i won't be on irc as this is past midnight here in india please leave a comment ... thanks again for your help === spacey_ is now known as spacey === leonel_ is now known as leonel [19:33] anyone around? [19:34] depends on what you need === cprov-lunch is now known as cprov [19:36] well then you are probably not around =) [19:37] I am interested in contributing, I have read quite a bit of the documentation on the MOTU wiki but the process still seems rather opaque to me [19:37] where are you stuck? [19:39] a lot of the technical parts are pretty clear, retrieving a source, applying a change, rebuilding etc... [19:40] the hard part is actually finding something that needs to be done, I have looked in launchpad and that is just a bit overwhelming [19:42] have you a software/package where are you interested in? if yes, you could check their bugs for example [19:43] * geser checks if there are some bitesize tagged bugs [19:45] you could also check the pending merges (if you're interested) and work on them (after coordinating with the previous uploader) [19:46] im going to look around for that [19:49] there are many tasks so I often have problems to point people to one specific task as it depends on what someone is interested in [19:52] I guess I am also not sure of exactly what my interests are, as funny as that sounds [19:53] sadly, there is not one package that I am absolutely enamored with or anything [19:53] just sort of want to help fix things [19:58] hey geser [19:59] Hi NCommander [19:59] geser, how goes it? [20:00] good, just to much work has accumulated in the past and this doesn't actually increase my motivation to work on it :( [20:01] anyone have a good link for docs that would help me setup my own local buildd here at work? [20:02] would love to have a setup similar to what we have now, where people will upload (dput), and then I have to approve or deny the packages [20:03] nixternal: iirc NCommander has already set one buildd up [20:04] NCommander: you better help me then :) [20:04] nixternal, aka, you want something with a NEW queue, right? [20:04] don't want to spend a lot of time doing it, but would like to get it up soon so I can start working on a migration path for our appliances here [20:04] NCommander: yes [20:04] nixternal, then you want dak [20:04] Which kills the "don't want to spend a lot of time doing it" requirement [20:05] hehe [20:05] figures [20:05] It's not that bad [20:05] WHen do you want it by? [20:05] next few weeks [20:05] actually [20:05] WHere are you in the world nixternal ? [20:05] I have time to spend on it, just didn't :) [20:05] Chicago silly [20:05] right [20:05] Well [20:05] Two choices [20:05] We do it at UDS [20:05] You give me the couch and I drive to Chicago [20:06] that could be a viable option actually [20:09] whihc nixternal which one? [20:14] nixternal, I can come to Chicago a week and a half from now [20:14] nixternal: Careful. He'll do it. [20:15] ScottK, you know me too well :-P [20:16] ports.u.c just went down ... [20:16] bah [20:18] nixternal, ? [20:22] hello [20:22] anyone here involved with Xen support on Ubuntu? [20:26] NCommander: get together at UDS possibly [20:26] shay: try #ubuntu-kernel or contacting zul [20:27] nixternal, you need a build machine the same architecture(s) you want, a machine to run wanna-build and wanna-persue on, and all buildds must be able to send email [20:27] thanks geser [20:27] ya, looking at that now [20:45] ScottK: not all the patches you sent can be applied [20:45] ScottK: still working === jmarsden_ is now known as jmarsden|work [21:06] leonel: It doesn't suprise me not all of them are relevant to 0.92.1. Thanks for working on this. I know it's a lot. [21:11] NCommander, did you file that armel bug yet, or am i not getting mail from bugs.debian.org? [21:11] I hadn't filed the bug yet [21:11] geser: cheers! thanks. [21:22] RainCT: ah... he means to stick some # comments in the patchfile ... ## patch_name.diff by Me \n ## [21:40] asac: drive-by: How serious is xulrunner about breaking yelp < 2.22.1-0ubuntu2.8.04.1? I'm guessing backports should rebuild a yelp. [21:46] anyone available to answer a quick question? [21:46] no [21:46] nobody [21:46] its an easy one [21:46] i think [21:46]