[00:11] <bdrung> ebroder, micahg: are you happy with the result: http://people.ubuntu.com/~bdrung/sponsoring/ ?
[00:12] <ebroder> bdrung: Looks good to me, modulo minor whining about sorttable not sorting the time in queue column correctly, but I still think it's an awesome improvement
[00:14] <bdrung> ebroder: fix sorttable ;)
[00:15] <bcurtiswx> an error like http://paste.ubuntu.com/533289/ , would I try to fix something in libindicate.patch or configure.ac ?
[00:16] <bcurtiswx> i.e. what file should I be looking at those error lines
[00:16] <bdrung> bcurtiswx: at configure.ac
[00:18] <bcurtiswx> bdrung, configure.ac doesn't have a line 597
[00:18] <micahg> bdrung: yes, looks good
[00:19] <bdrung> bcurtiswx: that may be the reason why it failed to apply
[00:22] <bcurtiswx> bdrung, hmm, k thx
[01:45] <bcurtiswx> whats the proper way to edit hunks in a patch?  i found the problem and know the issue
[01:46] <bcurtiswx> manually edit the patch, or is there some other commands that are proper
[01:47] <micahg> bcurtiswx: in Lucid and later there should be edit-patch
[01:48] <bcurtiswx> is it self-explanatory ?
[01:48] <micahg> bcurtiswx: if it's source format 3, there's quilt
[01:48] <micahg> bcurtiswx: there should be a man page :)
[01:48] <bcurtiswx> well i know man pages can be very confusing :P
[01:48] <kklimonda> bcurtiswx: you can edit it manually and then use editdiff
[01:48] <kklimonda> by hand*
[01:49] <micahg> kklimonda: there are tools for patch editing which make it easier
[01:49] <kklimonda> bcurtiswx: or maybe it's rediff for hand edited diffs and editdiff just wraps around it - see man editdiff :)
[01:50] <micahg> kklimonda: hmmm...that's a nice tool though :)
[01:50] <micahg> assuming you're working in one file
[01:50] <kklimonda> micahg: well, his question was about editing hunks in a patch itself :)
[01:51] <bcurtiswx> kklimonda, so if i have the diff that worked before and the new diff.. rediff will work on those two?
[01:51] <kklimonda> bcurtiswx: no, I don't think it's that smart :)
[01:51] <kklimonda> bcurtiswx: rediff most likely fixes stuff like offsets etc.
[01:52] <bcurtiswx> yeah, im reading the man on it..
[01:52] <bcurtiswx> Then run rediff, telling it the name of the original diff file and the name of the one you have edited
[01:53] <bcurtiswx> so you need the original (before edits)...
[01:53] <bcurtiswx> then rename the edited one?
[01:53] <nigelb> wouldn't there be a .rej file?
[01:58] <bcurtiswx> nigelb,  I don't see a .rej file
[01:59] <nigelb> bcurtiswx: ok, I think that's when you force the patch to apply.  Apologies :)
[02:00] <bcurtiswx> nigelb, no no, thanks for the help :)
[02:00] <nigelb> :)
[02:01] <bcurtiswx> ah i found the .rej file
[02:02] <bcurtiswx> it was on the configure.ac
[02:02] <bcurtiswx> shows the parts that were rejected
[02:02] <bcurtiswx> how would I use that and the orig to fix the diff
[02:03] <bcurtiswx> would that be what rediff is saying when i need two diff files ?
[02:06] <kklimonda> bcurtiswx: to be honest, what I when patche doesn't apply is that:
[02:06] <kklimonda> bcurtiswx: 1) quilt push -f
[02:06] <kklimonda> it creates a .rej file
[02:06] <kklimonda> I deal with it
[02:07] <kklimonda> I think by using quilt edit file
[02:07] <kklimonda> or maybe just normal editing..
[02:07] <kklimonda> and then I generate a new patch - all thanks to power of vcs :)
[02:10] <micahg> kklimonda: that would be normal editing after step 1, then quilt refresh
[02:11] <micahg> I happen to use this: quilt refresh --diffstat -U8 --no-timestamps
[02:12] <kklimonda> micahg: ah, good to know - I wasn't sure if I didn't dream this up :)
[02:12] <bcurtiswx> so i 1) quilt push -f
[02:12] <bcurtiswx> 2) edit the file, don't worry about editing counts
[02:12] <bcurtiswx> or do i use quilt edit ?
[02:12] <bcurtiswx> 3) once done, quilt refresh --diffstat -U8 --no-timestamps ?
[02:13] <kklimonda> I think you should use quilt edit but if micahg says otherwise then listen to him :)
[02:14] <micahg> bcurtiswx: also, if you need to add a file to the diff, use quilt add before editing, otherwise, just a regular editor (quilt knowns which patch you're on (quilt top)
[02:16] <micahg> bcurtiswx: you can use quilt edit if you want (I never have had a need)
[02:16] <micahg> bcurtiswx: http://pkg-perl.alioth.debian.org/howto/quilt.html
[02:22] <bcurtiswx> micahg, hmm, im using an ~ubuntu-desktop bzr branch where only the debian directory is provided.. would I need to get the entire source before editing the patches?
[02:25] <micahg> bcurtiswx: with this method, yes
[02:25] <ebroder> bcurtiswx: I don't know for sure, but you might want to check out http://jameswestby.net/bzr/builddeb/user_manual/merge.html
[02:25] <ebroder> (for getting your working copy setup)
[02:26] <micahg> we (mozilla team) have a get-orig-source rule to get the source and we just have the debian dir as well, idk how the desktop team does things
[02:28] <ScottK> Desktop team also just tracks /debian in bzr (as does Kubuntu as well)
[02:28] <micahg> ScottK: right, but idk how they get their source tarball :)
[02:28] <ScottK> Unless it's a new upstream version you're packaging, apt-get source works.
[02:31] <bcurtiswx> i got it, i remember bzr bd-do
[02:31] <bcurtiswx> but now, this is weird (to me at least)
[02:31] <bcurtiswx> the bzr bd fails at a patch, but by bzr bd-do and using quilt push -f, the patch works fine
[02:33] <bcurtiswx> ScottK: ^^ any ideas why?
[02:34] <ScottK> Because the bzr stuff is complicated and confusing.
[02:34] <kklimonda> +1
[02:34] <bcurtiswx> ScottK: how could I work around this?
[02:35] <ScottK> I generally apt-get source the package, make a local branch of the /debian and then use diff and patch to copy stuff between the package and bzr.
[02:35] <ajmitch> revu's list is depressingly long at the moment
[02:35] <ScottK> ajmitch: You have root where it's db lives.  You can fix this.
[02:35] <ScottK> Then I use normal dpkg like tools to build the packages.
[02:35] <ajmitch> ScottK: tempting, given that I'm wanting to migrate it to another host
[02:36] <kklimonda> "oops, something broke"? :)
[02:36] <ajmitch> there's a large number of packages on revu from 2009
[02:37] <ajmitch> I've archived a small number of packages that were uploaded to revu & then made their way into debian
[02:37] <bcurtiswx> will quilt fix the patches (after it finds how far away it is from before).. if so I can copy the fixed patch to the bzr branch
[02:38] <bcurtiswx> so when I quilt push -f to the patch that caused errors before, and it correctly applies the patch, will it go ahead and edit the patch as well updating the offsets it found ?
[02:38] <bcurtiswx> or do i have to run another command to do that
[02:38] <psusi> you need to quilt refresh to do that
[02:39] <bcurtiswx> psusi, right after the patch applies correctly, or do I need to go through the entire thing?
[02:39] <ajmitch> Do you think it's worth us scheduling a REVU day or two before feature freeze?
[02:40]  * ajmitch is undecided as to whether we want yet more packages in universe :)
[02:40] <psusi> generally if the patch does not apply cleanly,  you want to force the first patch that failed to apply, review it, make any corrections needed, and once you are sure it has been applied correctly to the new source, quilt refresh, then move to the next patch
[02:40] <ScottK> ajmitch: I think if someone is willing to coordinate them, we ought to start now.
[02:40] <kklimonda> ajmitch: only if they come with maintainers :)
[02:40] <ajmitch> kklimonda: right, that'
[02:40]  * psusi wouldn't mind getting the defrag package back into the official archive
[02:40] <ajmitch> that's something we'd have to require, I think
[02:40] <ebroder> Do we have any uscanning infrastructure?
[02:40] <ebroder> For keeping track of new versions
[02:40] <ajmitch> UEHS
[02:41] <ajmitch> http://qa.ubuntuwire.org/uehs/
[02:41] <ajmitch> I'd have to check whether it's up to date
[02:42] <kklimonda> it doesn't work
[02:42] <ajmitch> be more specific
[02:43] <kklimonda> I've typped two packages I know are outdated and have working watch files and it just shows empty page
[02:43]  * psusi really would like to get the defrag package back into universe, and updated to provide a nice alternate grub boot entry to perform a defrag of the root fs and optimize for boot time, coordinated with ureadahead
[02:43] <ajmitch> kklimonda: examples?
[02:43] <kklimonda> well - "empty" as in with header and footer but without any data :)
[02:43] <kklimonda> ajmitch: hamster-applet and transmission
[02:44] <bcurtiswx> seems to have worked.. the bzr bd failed, but i did bzr bd-do and manually pushed up until the patch that was failing.. saw it succeeded.. did a quilt refresh.. it updated that patch and i got out of the build environment, saw the patch was fixed and so far the build is going OK
[02:44] <ajmitch> kklimonda: thanks, I'll take a look as to why
[02:44] <bcurtiswx> much thanks to all who helped :)
[02:44] <ajmitch> psusi: convince a nice friendly person around here to upload it, then the rest can be sorted out )
[02:46] <psusi> ajmitch, you are nice and friendly... care to upload it? ;)
[02:46] <ajmitch> no I'm mean & nasty
[02:46] <psusi> I've had it updated and working and packaged on lp for several months now... so far the only comments I have had about it are 1) don't put the debian/ directory in the "upstream" release, and update to a more recent deb-helper
[02:47] <ScottK> That and he lives in NZ so uploads take an eternity due to the soda straw through which he has to do them.
[02:47] <ajmitch> & trying to sort out these ubuntuwire tools
[02:47] <RAOF> psusi: Last time we discussed this, questions like “how much error detection does this do, and will it eat people's data” came up.
[02:47] <ScottK> Ohhh.  A voice from amongst that almost nearly as badly bandwidth deprived ...
[02:48] <ScottK> ;-)
[02:48] <psusi> RAOF, hence the big warning made very prominent in the package description ( more so than it was last time it actually was in the official repos )
[02:48]  * ajmitch remembers being around for that data-eating discussion
[02:48] <ajmitch> apart from that, I don't think there were objections, were there?
[02:48] <ajmitch> I suspect it's that none of us want to take responsibility for uploading something to kill data :)
[02:49] <RAOF> No.  From memory, my position was that a warning in the package description was insufficient, and the binary should also prominantly warn.
[02:49] <psusi> I'm all for adding a "Hey dummy, you DID back up this volume first, right?" message ;)
[02:49] <ajmitch> wgrant: does UEHS need to be manually updated in several places to check natty?
[02:50] <ajmitch> or at least in update_wwwal.sh
[02:50] <wgrant> ajmitch: It probably will, yeah.
[02:50] <wgrant> ajmitch: There's a file in my ~ describing the changes that it needs.
[02:50] <ajmitch> ok, will check that out
[02:51] <ajmitch> just trying to see why there's still a run.lock file around for it
[02:51] <psusi> it just gets me that this was in the archives for so many years when it was confirmed that it did not work, and would eat your data, and now I've had it working well as far as I know for months ;)
[02:52] <wgrant> ajmitch: I'd do it myself, but I'm currently trying to defeat Launchpad.
[02:52] <psusi> especially when it can lead to sub 10 second boot times on modest rotational hard disks
[02:52] <ajmitch> wgrant: yeah, I saw you trying to break stuff in #lp-dev
[02:53] <wgrant> Yeah...
[02:54] <bcurtiswx> build success, woo... updating changelog and will request SRU shortly (empathy 2.32.1-0ubuntu1)
[02:55] <ajmitch> psusi: it's just that we know what users are like with ignoring warnings & being willing to do something for speed
[02:55] <ajmitch> automatix, anyone?
[02:55] <ajmitch> we shouldn't try & protect users too much, but at least let them know of consequences
[02:55] <ScottK> psusi: Did you try to get it into Debian?
[02:55] <psusi> ScottK, nope...
[02:56] <psusi> it was in debian... it was dropped after having no maintainer for many years...
[02:56] <ScottK> We'd get it via autosync then and none of us objecting would be likely to stop it.
[02:56] <ScottK> Right, but if you want to maintain it, then go for it.
[02:56] <ajmitch> I suspect it could be easier & more beneficial to be in debian
[02:57] <psusi> well, I have made an effort to adopt it and become upstream maintainer of it.. I host the project now on lp
[02:57] <psusi> but it seems like I would have to become a debian developer to get it into debia
[02:57] <psusi> debian...
[02:57] <ajmitch> no you don't
[02:57] <ScottK> No, you can get sponsored into Debian.
[02:57] <psusi> hrm... got a url for the debian sponsorship process?
[02:57] <ScottK> It might even be that one or more of the people you're chatting with are DDs and could sponsor it.
[02:57] <ajmitch> see mentors.debian.net for a useful place for finding sponsors, or you can ask any DDs that you know
[02:58]  * psusi doesn't knowingly now any these days, having used Ubuntu instead of debian since '04 or so
[02:59]  * ajmitch has heard that ScottK has plenty of bandwidth
[02:59]  * RAOF knows that at least two of your interlocutors are DDs
[03:00] <psusi> quam interloqutor?
[03:01]  * psusi might be a bit drunk, and might have just slipped into Latin
[03:29] <bcurtiswx> not sure who to ping for SRU but https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/675555
[03:36] <ebroder> bcurtiswx: We don't generally take upstream microreleases as-is. Instead we prefer to backport the patches that are relevant
[03:37] <ebroder> The wiki talks more about it:
[03:37] <ebroder> !sru | bcurtiswx
[03:37] <ubottu> bcurtiswx: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
[03:37] <ajmitch> empathy may be a special case if it's part of the usual gnome release set
[03:38] <bcurtiswx> didrocks would know best, i can bother him tomorrow
[03:38] <ebroder> But we only do that for LTS, right?
[03:39] <RAOF> I'm pretty sure that's for all releases.
[03:39] <ebroder> bcurtiswx: Also, your branch doesn't change anything except for the configure.ac file. All of the other changes are just in the patch metadata
[03:44] <bcurtiswx> ebroder, i bugged the desktop team as im using the ~ubuntu-desktop/empathy/ubuntu branch (thats how they maintain it).  i didn't edit anything escept the debian/changelog with the exception of having to update a patch so the offsets were better..
[03:44] <bcurtiswx> except*
[03:45] <ebroder> bcurtiswx: Sorry, I'll stop throwing criticisms when I don't understand the situation now
[03:46] <bcurtiswx> ebroder, yeah, i can be confusing.  I'll talk with didrocks (who maintains the branch i'm working on) and seb128 who's been helping me learn MOTU here and there.. much appreciate your help :)
[06:16] <kaushal> hi
[06:16] <kaushal> https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/651720
[06:16] <kaushal> is version 5.2 available in Hardy backports ?
[06:27] <kklimonda> no
[07:23] <Rhonda> kaushal: http://packages.ubuntu.com/openssh and you can answer yourself. ;)
[07:24] <Rhonda> … and the answer in that bugreport is pretty exhaustive, isn't it?
[07:28] <kaushal> what does openssh-server 1:4.7p1-8ubuntu1.2
[07:28] <kaushal> what does 1:4.7p1.... mean ?
[07:29] <kaushal> Rhonda: so add that line as per the bug report
[07:34] <Rhonda> 1: is a debian/ubuntu internal sorting enhancement in case one had to go back with version schema.
[07:34] <Rhonda> Only 4.7p1 is the real upstream version.
[07:36] <micahg> kaushal: did you see the cve tracker link I gave you about this?
[07:39] <kaushal> micahg: not sure
[07:39] <kaushal> I might have missed it
[07:39] <kaushal> micahg: please paste it again
[07:39] <micahg> kaushal: http://people.canonical.com/~ubuntu-security/cve/2008/CVE-2008-5161.html
[07:39] <ubottu> Error handling in the SSH protocol in (1) SSH Tectia Client and Server and Connector 4.0 through 4.4.11, 5.0 through 5.2.4, and 5.3 through 5.3.8; Client and Server and ConnectSecure 6.0 through 6.0.4; Server for Linux on IBM System z 6.0.4; Server for IBM z/OS 5.5.1 and earlier, 6.0.0, and 6.0.1; and Client 4.0-J through 4.3.3-J and 4.0-K through 4.3.10-K; and (2) OpenSSH 4.7p1 and possibly other versions, when using a block cipher algorithm in Ciph
[07:41] <kaushal> micahg: Thanks
[07:41]  * kaushal reading it
[07:51] <dholbach> good morning!
[07:52] <hyperair> kaushal: i thought someone told you to use the workaround yesterday
[07:57] <Rhonda> And actually I guess these kind of questions are better suited in #ubuntu, this channel is about packaging efforts.
[07:58] <micahg> Rhonda: I answered the question in -hardened yesterday
[07:58] <kaushal> hyperair: nope
[07:59] <kaushal> so use the workaround as suggested
[07:59] <kaushal> right ?
[08:00] <Rhonda> Yes.
[08:00] <hyperair> yes
[08:00] <kaushal> Thanks a lot
[08:00] <kaushal> So do i need to rescan again ?
[08:00] <kaushal> I mean the OpenVAS Scanner
[08:01] <kaushal> after setting the workaround
[08:01] <hyperair> kaushal: scottk told you to use the workaround listed in the bug report yesterday..
[08:01] <hyperair> kaushal: and you even posted the Ciphers line
[08:01] <kaushal> hyperair: yes
[08:01] <hyperair> it was just 16 hours ago!
[08:01] <kaushal> apologies
[08:02] <Rhonda> kaushal: The scanner only goes by version number, it doesn't try the exploit.
[08:02] <hyperair> kaushal: you probably want to reload/restart your ssh server as well
[08:02] <Rhonda> kaushal: So the scanner actually will always produce false positives.
[08:02]  * micahg gave a link to the CVE tracker with the Ciphers listed about 19 hrs ago
[08:02] <kaushal> so rescanning wont help
[08:02] <kaushal> right
[08:02] <kaushal> just to understand more
[08:02] <Rhonda> It will still show you as being affected, yes.
[08:03] <kaushal> ah ok
[08:03] <kaushal> Rhonda: Thanks
[08:03] <kaushal> hyperair: Thanls
[08:03] <kaushal> micahg: Thanks
[08:03] <kaushal> Thanks a Lot all
[08:03] <Rhonda> If you use such tools you should learn about its limitations.
[08:03] <kaushal> since i need to be doubly sure to put forward in front of my organization
[08:03] <kaushal> Rhonda: :)
[08:04] <hyperair> kaushal: if you wanted to be really sure, use a newer LTS.
[08:04] <Rhonda> Scanners usually only do non-intrusive tests, and that is plain version comparision.
[08:04] <hyperair> i think hardy is no longer supported.
[08:04] <kaushal> hyperair: it is
[08:04] <hyperair> oh it is?
[08:04] <hyperair> whoops
[08:04] <kaushal> uptill 1012
[08:04] <micahg> hyperair: hardy is supported on teh server until Apr 2013
[08:04] <Rhonda> That though won't work at all when the fixes get backported instead of blindly rolling out the new version (with all new bugs included, too)
[08:04] <hyperair> i see
[08:04] <kaushal> sorry Apr 2013
[08:04] <hyperair> that's long, yeah
[08:05] <Rhonda> hyperair: the server packages, not the whole of hardy
[08:05] <hyperair> Rhonda: right.
[08:05] <Rhonda> It's even on the entry page of wiki.ubuntu.com  ;)
[08:05] <micahg> and core server, with Dapper it was about 80 packages IIRC
[08:05] <Rhonda>  	
[08:05] <Rhonda> Supported until April 2011 (Desktop) or April 2013 (Server)
[08:05] <hyperair> well, now you know i don't go to the entry page of wiki.ubuntu.com much ;-)
[08:06] <Rhonda> Right, just mentioning it that the information isn't hidden very deep. :)
[08:06] <hyperair> yeah well =)
[08:06] <hyperair> i think wikipedia also has it listed
[08:07] <jpds> hyperair: /Releases
[08:08] <hyperair> jpds: ?
[08:08] <jpds> hyperair: w.u.c/Releases
[08:08] <hyperair> ah
[08:14] <Rhonda> jpds: It's all on the main page too, at least the most important data.
[08:15] <jpds> Rhonda: Woohoo, redundancy.
[08:15] <Rhonda> I guess H was left out after Gutsy to not have a repeat?
[08:15] <Rhonda> I would have voted for horny horses (and then run away like one ...)
[08:16] <Rhonda> But why wasn't there a cuddly chipmunk after breezy?
[08:17] <Rhonda> copyright issues? ;)
[08:18] <micahg> Rhonda: Hardy Heron?
[08:18] <Rhonda> Right, just noticed.
[08:19]  * Rhonda . o O ( ogling owl )
[10:47] <happyaron> What should be done when a package found to be not comply DFSG and should be removed from archive?
[10:48] <wgrant> happyaron: Which package? What's wrong with the license?
[10:49] <Rhonda> happyaron: File a bugreport against it and subscribe ubuntu-archive
[10:49] <happyaron> wgrant: fcitx, an required file in it can only be used to the specific package and cannot be reused by other projects
[10:49] <happyaron> Rhonda: thanks
[10:50] <Rhonda> happyaron: And also please file a serious bugreport in the Debian bugtracker if the package is still in there, too.
[10:50] <Rhonda> Otherwise it will get autosynced back into Ubuntu and you wasted your own effort. :)
[10:51] <happyaron> Rhonda: there is RM request on bts against ftp.debian.org
[10:51] <happyaron> Rhonda: the problem should be solved in upstream's upcoming major release, but older versions should be removed
[10:52] <happyaron> they are debian 603569, debian 603570 and debian 603571
[10:52] <ubottu> Debian bug 603569 in ftp.debian.org "RM: fcitx/stable -- ROM; not dfsg free" [Normal,Open] http://bugs.debian.org/603569
[10:52] <ubottu> Debian bug 603570 in ftp.debian.org "RM: fcitx/testing -- ROM; not dfsg free" [Normal,Open] http://bugs.debian.org/603570
[10:53] <ubottu> Debian bug 603571 in ftp.debian.org "RM: fcitx/unstable -- ROM; not dfsg free" [Normal,Open] http://bugs.debian.org/603571
[10:53] <wgrant> It's redistributable, so it's not absolutely critical.
[10:53] <happyaron> we can distribute it in archive, but it doesn't comply DFSG, that's the problem
[10:54] <wgrant> Right.
[13:03] <ScottK> happyaron: So it should be moved to Multiverse, not removed entirely.
[13:06] <happyaron> ScottK: thanks
[13:06] <ScottK> happyaron: Please update the bug to ask it to be moved.
[13:07] <happyaron> ScottK: okay
[13:18] <Rhonda> And in Debian moved to non-free
[13:18] <Rhonda> Unless the maintainer really doesn't want to continue to maintain it.
[13:19] <happyaron> er, busy right now, will change soon
[13:19] <happyaron> in fact, the upcoming release will be dfsg free, so moving to non-free is not a good idea
[13:22] <Rhonda> When is the release expected? Maybe the removal from unstable/natty can wait for that?
[13:22] <Rhonda> So that the package won't have to run through NEW again?
[13:26] <happyaron> Rhonda: the upstream release will be in a week or so hopefully, but the I don't have enough time to have a quick version for Debian then. The package was maintained by another person, but he doesn't give any feedback, so I plan to do it myself
[13:29] <ScottK> happyaron: At least in Ubuntu, it's very easy to get it moved back to Universe when there's a free version available.
[13:30] <happyaron> ScottK: that's good
[13:30] <happyaron> changing the ubuntu bug now
[13:32] <ScottK> Perhaps DktrKranz can advise you on the best thing in Debian ...
[13:34] <happyaron> yes... the bug on Debian BTS was filed by a DD, not me...though I found the problem when working on 4.0rc1
[13:34] <Rhonda> happyaron: Will the new upstream release be that much changed that the release team will _not_ let it go into squeeze? Or is ist "just" the licensing adjust?
[13:34] <happyaron> ScottK: changed, thanks
[13:34] <ScottK> Thanks.
[13:34] <happyaron> Rhonda: a major release
[13:35] <Rhonda> then I fear it won't make it into squeeze :/
[13:35] <happyaron> with a lot of new features, so perhaps release team will not let it go into squeeze.
[13:35] <ScottK> happyaron: Perhaps upstream could relicense the existing file in the current release and documentation of that could be added to debian/copyright?
[13:35] <Rhonda> Unless the licensing fixes can get extracted explicitly into the package
[13:36] <ScottK> Licensing "fix" could be an email from the copyright holder.
[13:36] <happyaron> ScottK: nope, the copyright holder didn't response, at least till now
[13:36] <Rhonda> It would be really swift if you could check for that.
[13:36] <ScottK> Ah.  That makes it tough.
[13:36] <Rhonda> So what's the upstream fix for the issue?
[13:37] <happyaron> Rhonda: change to use another set of data that doesn't have the problem
[13:37] <happyaron> Rhonda: it could be backport to the 3.6.x branch easily if I'm not wrong
[13:39] <happyaron> Rhonda: but will cause noticeable change on user experience, because it is a data file of an input method
[13:39] <Rhonda> huhm
[13:39] <Rhonda> Better discuss the issue with the release team directly, then.
[13:40] <Rhonda> #debian-release on oftc. Or better, mail debian-release
[13:40] <happyaron> okay, thanks
[13:40] <Rhonda> @lists.debian.org of course :)
[13:40] <happyaron> :)
=== zul is now known as ep
=== ep is now known as zul
=== menesis1 is now known as menesis
[14:02] <DktrKranz> ScottK: about?
[14:02] <ScottK> DktrKranz: Yes.
[14:03] <DktrKranz> so, re-enter a package previously dropped?
[14:03] <ScottK> Well the question is how to deal with non-freeness and how hard it would be to get back from non-free to Main once the problem is fixed.
[14:03] <ScottK> It does seem that happyaron and Rhonda have come up with a possibly better solution.
[14:04] <DktrKranz> just upload to main
[14:04] <DktrKranz> it will have to pass NEW again, though
[14:06] <lucidfox> YokoZar, what's multiarch?
[14:19] <geser> lucidfox: having multiple architectures installed in parallel, e.g. being able to run 32 bit apps (i386) on an amd64 installation
[14:20] <geser> which means you have to have also all needed 32bit libs installed (next to the 64bit ones)
=== yofel_ is now known as yofel
=== Quintasan_ is now known as Quintasan
=== hannesw_ is now known as hannesw
=== jdstrand is now known as jdstrand_
[18:14] <SpamapS> ScottK: those little arm build boxes you had at UDS... do they have USB ports?
[18:14] <ScottK> SpamapS: They do.
[18:14] <ScottK> Two in fact.
[18:14] <SpamapS> ScottK: do you by any chance know where they can be bought, and/or what the model number is? I want one.
[18:15] <ScottK> SpamapS: https://www.genesi-usa.com/store/details/11
[18:16] <ScottK> SpamapS: They come with Karmic on them, but there will be a Natty kernel for them as well.
[18:16] <SpamapS> fantastic.
[18:16] <Laney> Some (mine) come with Maverick
[18:16] <Laney> I can't remember why...
[18:16] <SpamapS> I want to use it a) to build arm stuff, and b) to run a local mirror.
[18:16] <ScottK> Laney: I don't think those are production models.
[18:16] <ScottK> SpamapS: I do builds in a natty chroot just fine.
[18:16] <Laney> ok
[18:17] <ScottK> Laney: Check though, it probably has a maverick userspace and a Karmic kernel.
[18:17] <micahg> mine came with Maverick also, but a Karmic kernel
[18:17] <SpamapS> I actually don't have any "always on" computers in my house.. but its either have a local apt cache/mirror.. or upgrade my u-verse from 7Mbit to 20Mbit so I can stop waiting to bootstrap everything :p
[18:17] <Laney> laney@efikamx:~$ uname -a
[18:17] <Laney> Linux efikamx 2.6.31.14-efikamx #1 PREEMPT Tue Sep 14 22:23:30 CDT 2010 armv7l GNU/Linux
[18:18] <ScottK> SpamapS: The USB port is the reason I can build qt4-x11 on it.  I bought a 16GB USB stick and mounted it as /var/cache.
[18:18]  * micahg thought there was a maverick kernel for these boards
[18:18] <ScottK> Laney: That's Karmic.
[18:18] <Laney> Yeah
[18:18] <ScottK> I've got one of those too.
[18:18] <ScottK> Does yours shutdown cleanly?
[18:18] <SpamapS> ScottK: I have two 1TB USB drives that are grossly underused.. so local mirror seems a good choice given the number of builds/packages/merges/etc. I do.
[18:18] <Laney> About to restart it, so we'll see. Don't remember any problems though.
[18:19] <SpamapS> that way I can also keep bringing one of the 1TB drives with me on trips.
[18:22] <highvoltage> I wish these kind of devices would switch to ARM: http://store.computer-source.ca/store/viewItem.asp?idProduct=77060
[18:22] <highvoltage> (I guess it's just a matter of time)
[18:25] <Laney> ScottK: shut down just fine
[18:25] <ScottK> Thanks.  Must be something odd in my box then.
[18:29] <SpamapS> highvoltage: they'll switch when its cheaper for them.
[18:29] <SpamapS> highvoltage: or if they get wise to the "green economy" and can say "the low carbon footprint storage solution"
[18:41] <ari-tczew> whoa, how much core-devs are coming! and zero MOTUs this time
[18:43] <ajmitch> hm?
[18:43] <geser> ajmitch: see DMB agenda
[18:45] <ajmitch> right
=== zul_ is now known as zul
=== xfaf is now known as zul
=== hanska is now known as dapal
[19:58] <ari-tczew> pull-debian-source doesn't work in natty :(
[19:59] <ari-tczew> The source package konversation isn't available in Debian testing.
[19:59] <jpds> Nice.
[20:00] <ajmitch> that seems just a bit broken
[20:09] <Laney> good job it's foss ;-)
[20:11] <ajmitch> Laney: it wouldn't have helped if it was looking at a broken site for its data
[20:11] <ajmitch> but qa.debian.org/madison.php is giving me the right output
[20:14] <Laney> i bet it's the multiple source entries thing
[20:19] <geser> as far as I can tell, only one version in testing
[20:20] <Laney> I think the "testing" part is misleading
[20:20] <Laney> a bug in the error message, it's actually looking in unstable
[20:23] <ajmitch> funnily enough, appending testing to the command line does fetch it
[20:23] <Laney> exactly
[20:23] <ajmitch> pull-debian-source konversation unstable is what fails for me
[20:24] <ajmitch> r773, committed on 17 oct
[20:27] <Laney> that is suspicious
[20:28] <Laney> 103-107 are weird too. trim()?
[20:29] <Laney> and right, it doesn't look like it handles multiple source entries
[20:46] <DeepBlue74> hi, anybody here to get a newbie some starting pointers?
=== barry` is now known as barry_
[21:52] <rsajdok> Which of package contains module: gnome-keybindings
[21:53] <rsajdok> ?