=== RAOF_ is now known as RAOF [00:30] yo. === foka_ is now known as foka === ccheney is now known as calc [01:11] hello [01:11] i am now safe at davidm's house :) [01:17] calc: How're things over there? [01:17] wgrant: much better up here than where i live ;) [01:17] its already up to 27mph wind at my house [01:17] projected 80mph+ [01:18] no trees to buffer it where i live either [01:18] its clear cut in the neighborhood and backs up to a large AM radio tower array [01:18] Ah. [01:18] oh the plus side that means no trees to fall on the house [01:48] * flyback bbl, mabye === jono__ is now known as jono [02:21] hola wgrant [02:21] Hi NCommander. [02:23] how goes it wgrant? [02:30] NCommander: Busy as usual. :( [02:32] wgrant: sounds like fun. I'm trying to kill the backports queue again [02:37] Lovely. [02:37] Clearly you don't want me uploading Ada SRU's then. [02:38] ScottK-laptop: Right now, I'm just focusing on fixing Subversion :-) [02:38] Cool. [02:39] Is this the libneon thing? [02:39] ScottK-laptop: yeah [02:39] I'm rolling a debdiff to switch the build dependency, and then I'm going to shove it in the PPA [02:40] We should look at making the same change in intrepid, since the bug exists there too [02:40] Intrepid likely ought be fixed *before* backports. [02:40] persia: well, I'm not sure if it should be fixed [02:41] The Debian maintainer made a change from openssl->gnutls [02:41] (hardy used libneon backed on openssl) [02:41] NCommander: You're going to have to explain it then, because as I read what was said to be the relevant Debian bug it didn't seem to apply to the versions we had. [02:41] There is a bug in gnutls that currently breaks SVN when you try and use SSL certificates [02:41] Oh, good [02:41] I didn't realize we already patched around that bug [02:41] No, I think our versions are before it was introduced. [02:42] OTOH, someone was saying they had the problem, so dunno. [02:42] Three people acked the bug [02:42] I may just be incorrectly versioned in BTS. [02:42] I/It [02:42] so its a confirmed issue in the hardy backport [02:42] OK. Can you reproduce it? [02:42] No, since I don't have an SSL certificate [02:43] ^system setup [02:43] I'm rolling a backport with the proposed fixed, and then uploading to the PPA, and asking people to test that [02:43] OK. [02:44] I figure that's the best way to test it [02:45] The best way is for the developer to reproduce the problem and see it go away, but absent that and if you're willing to take on the karmic load of enticing people to install packages from unsigned repos, yes. [02:45] That's the metaphysical karma, not the LP kind. [02:46] ScottK-laptop: I'm just following the instructions from the backports wiki page [02:46] Ah. You are just following orders. [02:46] Well, there is a work around (an ugly one) for the current issue, Read the current bug? [02:47] Not today. [02:47] What's the bug? [02:47] https://bugs.edge.launchpad.net/hardy-backports/+bug/265065 [02:48] Launchpad bug 265065 in subversion "Subversion 1.5.1 does not work with SSL certificates" [Undecided,New] [02:48] * ScottK-laptop looks [02:49] You can do the .p12 -> .pfx thing with openssl too can't you? [02:49] * ScottK-laptop looks into that so we can at least have a work around that doesn't require a Windows box. [02:53] ScottK-laptop: not a clue [02:54] The answer will make your eyes bleed. I think it's a bogus clue. [02:54] symlinking one lib for the other is ugly, but I'm not suprised it works. [02:56] ScottK: its proof enough for me that switching the build-dep will likely fix the bug [02:58] Is switching the build-dep legal? [02:59] It's considered a code-changing backport. I thought there was a requirement that any such bugs must first be fixed in intrepid (as with SRUs). [03:00] Is Subversion appropriately licensed to link to OpenSSL? [03:00] wgrant: its not subversion that links to openssl [03:00] wgrant: its one of its build-deps that is [03:00] libneon can be linked to openssl or gnutls [03:01] In intrepid, via a sync, SVN was switched to link against libneon gnutls [03:01] Oughtn't we just backport that then? [03:01] It appears that intrepid is currently unaffected [03:02] libneon? [03:02] It has a good number of rdepends :-/ [03:03] persia: It's not quite the same thing. [03:04] Often we have to do things in backports that aren't directly relevant to the development release. [03:05] ScottK-laptop: OK. As with all things backports, I'll defer to you. I just don't like fixing bugs in backports if the bugs exist in the main trunk, and generally think it's better to do a fresh backport than fiddle with an outdated one. [03:05] The most awful thing I've had to do (to make a backport work on Dapper) was to take the Feisty version of a package, swap in the Dapper versions of debian/rules, and grab one file out of the upstream source from Hardy and slam it all together. [03:06] It worked. [03:07] Wtf? Why does Firefox show an EULA? [03:08] ScottK-laptop: what package? [03:08] ion_: I thought I saw a page load up this morning with "mozeula" on the end, but I closed it too quickly to notice. [03:09] ion_: So I wasn't imagining things? [03:10] NCommander: I think it was avscan. [03:10] ow :-P [03:12] I had to do something ugly to python-clamav in Dapper too. [03:13] ion_: I THINK I JUST DIED OF A CAPITAL LETTER OVERLOAD. [03:13] We must be able to disable that by default. [03:14] It also seems to be wrong, as I don't think we have any blobs (except for the logo) in the Ubuntu version. [03:14] persia: svn isn't GPL, so openssl linking isn't an issue. [03:16] wgrant: ^ [03:16] ScottK-laptop: Ah, convenient. [03:17] ScottK-laptop: it won't be so bad if clamav didn't believe in breaking the API/ABI every release without bumping the soname [03:17] NCommander: At least they have releases. [03:17] wgrant: your refering to ffmpeg I assume [03:17] NCommander: They actually bump the soname now, but the problem is they don't provide any transition. [03:18] We just changed over to libclamav5, so they are bumping it. [03:18] NCommander: I am. [03:18] It was a good update too, only 1/3 of the rdpends FTBFS this time. [03:18] Usually it's 100% [03:19] ScottK-laptop: That PHP one was evil [03:20] PHP is evil. [03:20] That was mostly libtool's fault though. [03:21] I don't think my NMU got uploaded yet [03:21] wgrant: Right, so what happens with you build a php library with libtool to integrate with libclamav. It's like a black hole of evil. [03:21] NCommander: Nope. [03:22] * NCommander just happens to be immune to backports [03:22] er blackholes [03:22] ScottK-laptop: Something bad, I suspect. [03:22] wgrant: your eyes would bleed if you saw the size of the hack I put in place to fix it [03:22] But if we also throw ffmpeg into the mix, I suspect that a LHC-esque world destruction will commence. [03:23] wgrant: it could be worse, ffmpeg could ship a debian folder [03:23] IIRC mplayer does. [03:23] So why wouldn't ffmpeg? [03:24] * ScottK-laptop hands wgrant http://hasthelargehadroncolliderdestroyedtheworldyet.com/ [03:24] ScottK-laptop: BTW< do you have one of those nokia internet tablets? [03:24] No. [03:24] Actually I have an old one around here somewhere. [03:24] N770 I think. [03:24] ScottK-laptop: Haha. [03:25] ScottK-laptop: care to enable root, give it access to some large space, and turn it into a buildd for Kubuntu-arm? [03:25] * NCommander managed to get an arm port in the agenda at the last Kubuntu meeting :-) [03:26] Hmmm. [03:26] That'd take a long time to build anything. [03:26] ScottK-laptop: On my arm board (266Mhz/32MB), building GCC took roughly 16 hours [03:27] Beating out m68k by two or three orders of magatitude. [03:27] (GCC on m68k takes a week, GCJ takes another one. We don't have GNAT (yet)) [03:28] NCommander: Did you see http://suihkulokki.blogspot.com/2008/09/marvell-mv78x00-board.html [03:28] and suddenly my wallet cried out in pain and was suddenly silenced [03:30] Scott, got any idea what that thing runs? [03:31] * NCommander can't even find that board on their webpage :-/ [03:31] Nope. [03:33] ScottK-laptop: Its a pity QEMU still doesn't have armel support [03:36] That there is a very nice piece of equipment. Clearly there need to be lots of them in lots of places :) [03:38] persia: it would be a good buildd, I'll probably end up supplimenting my armel buildd with distcc to speed it up [03:39] NCommander: I'm tempted as a desktop. Probably has significantly lower heat production than my current system (which can only operate ~9 months a year) [03:40] persia: I want an ARM or MIPS based netbook badly [03:41] persia: well, china has a prototype of the later so it may just happen [03:41] * NCommander will port ubuntu to armel hopefully ;-) [03:44] NCommander: Seriously, chat with the mojo folk. There's work already done there, and at least three other private ports of which I have heard. [03:45] persia: they do arm, not armel [03:45] persia: and #mojo doesn't exist :-) [03:49] NCommander: #handhelds@OFTC, but it seems to be mostly an email-driven group. Anyway, differences between arm and armel aren't that huge, when compared to differences between {arm|armel|} and i386. [03:49] Still a good source of hints and guidance for your quest [03:51] * NCommander nods [03:51] * NCommander waits to see if his post shows up on planet [03:57] * NCommander wishes he was a core-dev so he wouldn't have to tor^W ask Scott to upload backport fixes [04:00] THat being said, I'd be afraid an offical arm port of Ubuntu will end up like PowerPC, which gets relatively little love [04:02] NCommander: It's a matter of interest and use. As long as there is enough hardware, I suspect it will get used. powerpc was significantly more active before new ones stopped being sold, and most people didn't have them anymore. [04:03] With current hardware, I'd expect an armel port to be mostly interesting for NAS, routers, and MIDs. [04:03] (where NAS and routers are probably handled by ubuntu-server, and MIDs by ubuntu-mid) [04:03] Well, I've been working to fix most of the larger issues w/ PPC [04:03] Of course, that's just speculation: I could be wrong. [04:03] * NCommander has a rather large sweet spot for that architecture [04:04] Excellent! Do you have both "regular" PPC and ps3 HW? I believe both need a bit of attention. [04:04] Just regular PowerPC [04:04] But I've been testing anything that hits hardy-proposed thats PPC specific [04:06] My largest pet peeve ATM is we don't have Kubuntu or Xubuntu CDs for ports [04:07] SPARC also needs huge amounts of love [04:07] I have a friend who tried Ubuntu SPARC and went back to Debian within a release citing unstabilitiy. My brief experiences tend to agree with him [04:09] REVU runs on sparc. [04:09] The issues may be resolved by now ;-) [04:10] Pretty well except when they hard drive died. [04:10] they/th [04:10] * NCommander notes that for future reference someone asks me to fix a Sparc related FTBFS [04:10] e [04:10] It seems the only architecture I can't fix FTBFS for is now HPPA === jscinoz_ is now known as jscinoz [04:11] NCommander: You have access to ia64? [04:12] d'oh [04:12] Everyone forgets ia64 [04:12] Intel wants to forget ia64 [04:12] Yeah, and it's starting to get in sad shape. [04:12] My one or two experiences with ia64 scared me for life likely [04:13] ia64 was up-to-date for hardy: it just doesn't seem to have gotten any attention for intrepid yet. [04:13] persia: know where I can find a community ia64 box? [04:15] ScottK: I've been thinking [04:16] ScottK: Could we possibly backport debhelper 7 (which is very different from six if you use the new style commands) under a different source package name so it would be easier to do actual backporting? [04:16] No. [04:17] * NCommander waits fodr Scott to explain the reason which I likely overlooke [04:17] *overlooked [04:17] That's way past my crack-o-meter limit. [04:18] NCommander: It's not just a new name, it'd have to be co-installable so it'd have to live in a completely different namespace, but still work the same. [04:18] ScottK-laptop: so dump it out of the path, and then in packages that legit. need it, just add the PATH to the top of the rules [04:19] * NCommander runs from scott before his crack-o-meter explodes [04:19] NCommander: backports is inherently crack, but is supported because it's high-quality crack, cut with only the finest ingredients, with significant quality control. [04:20] * ScottK-laptop looks around for his advocation of NCommander for UCD. [04:20] backports stays supported only so long as our crack is better than other crack. [04:20] persia: hence why Dapper backports have died [04:20] NCommander: No, I think anyone still using Dapper either really wants exactly an unchanged system or is just lazy. [04:21] ScottK-laptop: We just got a dapper backporting request :-) [04:21] Note that I still have a Kubuntu Dapper desktop. I'm reason number 2 [04:21] NCommander: Is it tested? [04:22] ScottK-laptop: I said we got a request to do a backport, I didn't say I touched it ;-) [04:22] * NCommander is subscribed to backport emails [04:22] K. Let me know. [04:23] ScottK-laptop: I thought you advocating on my UCD [04:24] Right. I did. Now I'm wondering if I made a mistake. [04:24] *advoacting/advocated [04:24] ;-) [04:24] ScottK-laptop: -_-; It was an idea [04:24] Not like I already generated a source package or somethng ... [04:25] I fix libtool bugs. You need to realize at some point, my tolerance for horrible hacks is somewhat high :-P [04:25] True [04:26] wow, someone ported openjdk to m68k [04:26] O_O; [04:26] Could someone please give-back https://launchpad.net/ubuntu/+source/debian-installer/20080522ubuntu14/+build/715838 ? [04:27] It should build now. [04:28] I feel like fixing something [04:28] anyone know any good fixs? [04:28] er, anything that needs a good fix? [04:28] You've fixed all the FTBFS already? [04:29] Almost all in main [04:29] er [04:29] guess CUPS broke since the last time I looked [04:30] persia: Retried. [04:31] ScottK-laptop: Thank you. [04:31] No problem [04:31] * NCommander looks at the Debian failed statats [04:32] NCommander: Have you been introduced to conflictchecker yet? [04:32] no [04:34] heh [04:35] should I run now? [04:35] http://conflictchecker.ubuntu.com/ has all the possible file conflicts for all the possible versions of packages that aren't already covered by a Conflicts: relation. Some of them are spurious. Others would benefit from versioned Conflicts: and possibly Replaces: [04:35] Or even integration with the update-alternatives system. [04:35] Fixing them all means fewer failed upgrades for people. While there is upgrade testing between ISOs, there isn't much for every possible package, hence conflictchecker. [04:35] possible-conflcts 0 kb [04:36] this sounds like britney on steriods [04:36] http://conflictchecker.ubuntu.com/possible-conflicts/intrepid/main.txt [04:36] WTF [04:36] Clicking that link opened OOo [04:36] Yes, something like britney's great-grandchild after an intensive breeding program. [04:37] It's CSV. Use a browser that doesn't try to parse everything if you want to see the text. [04:37] I dont' even grok the output of this [04:39] NCommander: It lists a package, another package, and a file that is shared between them. [04:39] I'm not sure why it's listing SPRs that didn't originate in Hardy. [04:39] NCommander: Looking at the first line: it appears that the bison package was split in feisty, pulling out bison-doc. This might conflict with the bison from Dapper. [04:40] * flyback is sick of spending weekends working on work stuff [04:40] wgrant: It lists everything because someone might have an old version installed, from some point. [04:40] I think you hurt my brain [04:40] persia: They shouldn't ever have an old version if a new version exists. That's not a supported upgrade path. [04:41] wgrant: conflict checker isn't about "supported upgrade paths". It's about supporting all possible upgrade paths. [04:41] persia: Perhaps. [04:42] Looks like an insane amount of work [04:42] wgrant: No, that's what conflictchecker does. Whether it's worth fixing them all or not is a different question. [04:42] NCommander: Sounds perfect for you. [04:42] NCommander: Obviously, you'll want to apply some filters to look for sane upgrade paths, etc. [04:43] wgrant: If you look, you'll notice that a number of the conflicts aren't even published anywhere: they were just intermediate versions during some development cycle. [04:43] I'm going to go get dinner first [04:43] persia: True. [04:43] Then maybe see if I can stomach this kind of work [04:45] NCommander: If you find a class of conflicts you believe ought be handled by the checker, feel free to update https://code.launchpad.net/conflictchecker [04:46] * NCommander runs in fear [04:46] Nice, you found something more evil than libtool FTBFS :-) [04:46] * persia ties little red bows on conflictchecker, and lays out a trail of candy [04:47] This is something that should be built in Launchpad for easy review and data parsing [04:47] NCommander: It just seems to be the class of stuff you like. A large volume of repetitive tasks that require a moderate amount of technical knowledge, and a willingness to look where most fear to tread. [04:47] just moderate? [04:47] Bah :-P [04:48] I'm happier it's external: that way we can hack it to make it better. Next year, I'll probably agree with you. [04:48] * NCommander watches his ego deflate faster then the devaluation of the dollar [04:48] NCommander: Not a measure of your technical knowledge, it's just that you seem to prefer volume rather than the 2-month bugs. [04:49] If you prefer *hard* bugs to volume, feel free to clear out oldlibs :) [04:49] oldlibs? [04:49] Oh, finding rdepends and removing them [04:49] right? [04:49] WHere's the current NBS list? [04:49] * NCommander might as well get to work [04:49] brb [04:49] Section: oldlibs. Stuff that wasn't ever ported to a new API, and we support the old API (sometimes for years) because of two or three defunct upsteams. [04:52] NCommander: Or if you want, you can figure how to embed a copy of the newer ghc6 compiler in the DARCS package since it runs dog slow and we don't have enough time to to a proper transition of all the ghc6 packcages to the new (not brokenly slow) library. [04:53] Or we can come up with more hard bugs :) [05:01] I think maybe we scared him. [05:01] I hope not. [05:03] zirconium seems not to want to do anything right now :( [05:10] ScottK-laptop: I went away from keyboard [05:10] yay, dinner [05:10] Dacrs as in darcs VCS? [05:11] Yes. Darcs as in the VCS. It's written in Haskell and is not at all happy with our current gch6. [05:11] It's the only solution I've come up with. [05:11] Dunno if it's at all feasible or not. [05:11] Seemed like your kind of challenge. [05:13] Well [05:13] I know Ada [05:13] How can Haskell be? [05:13] ScottK-laptop: Dont' expect a debdiff, since it would be massive [05:13] Dunno. [05:14] Is upstream dead on dracs? [05:14] er [05:14] wait [05:14] What am I trying to do again? [05:15] Not AFAIK. The problem isn't in darcs, it's in our ghc6 [05:15] oh [05:15] OH! [05:15] Ew [05:15] Get the new GCH6 from Debian and find some magic way to build darcs against it and have it use it without having to transition every Haskell package in the distro. [05:16] Yeah, like I said, you're kind of thing. [05:16] There's probably even bootstrapping of some kind involved. [05:16] Would be creating a new ghc source package (ghc6-something) be acceptable? [05:16] NCommander: Dunno. [05:16] NCommander: Bug 263773 has the reference discussion. [05:16] Launchpad bug 263773 in ghc6 "ghc 6.8.2 has important performance bug, should be updated to 6.8.3" [Medium,New] https://launchpad.net/bugs/263773 [05:17] Yeah [05:17] just found that [05:17] I think its the only sane way to do it [05:18] Whatever you consider, I'd ask sistpoty about it, since he coordinated the last GCH6 transition. [05:19] sid and intrepid have the same ghc version [05:19] Hmmm. Maybe it's a new upstream then. [05:20] is anyone who is on release still awake? [05:21] NCommander: Main or Universe? [05:21] ghc is universe [05:21] so universe [05:21] You mean someone other than me? [05:22] Your on -release? [05:22] I thought you resigned that position [05:22] Yes. No, I quite motu-sru. [05:23] Oh [05:23] Ok [05:23] Remember the flamestorm over Ruby Gems? [05:23] ScottK-laptop: I didn't realize you were still -release [05:23] If you don't associate that with me, then my duck and cover worked better than I ever imagined. [05:23] OK. [05:23] Well, what I'd like to do if you believe ghc6.8.3 is worth it is put it as a seperate source package (ghc6-*something*), then transition each package by hand that needs the performance tweaks [05:24] NCommander: I think it's worth considering and the sistpoty is the expert. Run it by him. [05:24] When jaunty is opened, Debian should have finished the transition, we sync the resulting ghc packages, and then zap the old ones [05:24] He's not online, but I left a comment in that discussion [05:24] I'm looking at oldlibs [05:24] A bunch of these no longer have rdepends [05:25] NCommander: Debian is releasing Lenny RSN: there oughtn't be a leftover transition we can't do something about for intrepid. [05:25] Does that mean I should start filing removal requests? [05:25] NCommander: You're looking at reverse depends, reverse recommends, reverse build-depends, and reverse build-depends-indep? [05:25] If there's something in oldlibs with *none* of those, it can likely go. [05:25] persia: I'd say Debian is scheduled to release Lenny soon. [05:25] persia: I just checked apt-cache rdepends, is there a quick way to check all that? [05:26] * ScottK-laptop hands NCommander grep-dctrl. [05:26] ScottK-laptop: Fair enough, but I don't expect Intrepid before Lenny. [05:26] * NCommander needs the manual [05:26] NCommander: apt-rdepends tries to do some of it, but grep-dctrl is definitely the right tool. [05:26] So what command do I type? [05:27] * NCommander has bad luck with advanced grep like commands [05:27] NCommander: There's also a cheater script for it in ubuntu-dev-tools named something like reverse-build-deps. [05:27] Look at that and you'll get the idea. [05:27] Its clear on libdb1-compat [05:27] * NCommander looks up filing a removal request [05:28] anyone running hardy? [05:29] NCommander: You could create a hardy chroot ... [05:30] NCommander: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing%20Packages if you didn't find it already. [05:31] I am [05:31] NCommander: I'm running hardy. [05:31] ScottK-laptop: want to run reverse-build-depends on libdb1-compat? [05:31] I'll do it. [05:31] NCommander: Nothing. [05:33] Yeah [05:33] Ok [05:33] Removal request filed [05:33] https://bugs.edge.launchpad.net/ubuntu/+source/db1-compat/+bug/269674 [05:33] Launchpad bug 269674 in db1-compat "Request for Removal: unneeded oldlibs" [Undecided,New] [05:34] When I was doing some cruft cleaning for Hardy, I ended up asking for removal of a GCC 2. something package. [05:35] ScottK-laptop: For any packages I need to get free from the rdepends in Debain, will you sponsor NMUs? [05:35] NCommander: IANADD. [05:35] oops [05:36] * NCommander files a removal request for atm-dev, which was a transitional package which has now existed for two LTSs, and is safe to remove [05:38] NCommander: IIRC there is slypheed package and a sylpheed-gtk2 package. If that memory is correct, I'm pretty sure sylpheed can die. [05:38] Don't see it in oldlibs [05:40] And I can't find reasons why things were put in oldlibs [05:40] oh, I see [05:40] No. That's not in oldlibs, it's just a generic thing that can die. [05:40] It appears dead [05:40] * NCommander attacks gnucash [05:41] OK. [05:41] NCommander: What's the bug for atm-dev? :-) [05:45] StevenK: I need to tweak the source package to stop making atm-dev [05:45] StevenK: want to kill libdb1-compat while I do that? [05:46] StevenK: https://bugs.edge.launchpad.net/ubuntu/+source/db1-compat/+bug/269674 [05:46] Launchpad bug 269674 in db1-compat "Request for Removal: unneeded oldlibs" [Undecided,New] [05:46] * NCommander wants to kill every oldlibs now ;-) [05:46] NCommander: Once you tweak the source package, it will get NBS'd out [05:46] Score, care to sponsor that upload then? [05:47] And should I bother with an SRU to remove it from hardy? [05:47] NCommander: Nope. [05:47] I'll see about doing an NMU on this for Debian [05:48] (which may or may not be successful) [05:48] (the package is quite dead, four NMUs in a row) [05:48] NCommander: Removals virtually never happen after release. [05:48] legal reasons usually are the only reason, right? [05:49] That'd be the main one. [05:49] IIRC there was one time due to security concerns. [05:50] StevenK: rolling linux-atm [05:52] * StevenK won't be doing a NBS run today [05:57] StevenK: but would you upload a package that would create a NBS? [05:58] I dunno. [05:58] * NCommander confirmed it builds [05:58] :-P [06:00] Are there any buildd admins about today? I'm having a queuing issue. [06:00] StevenK: https://bugs.edge.launchpad.net/ubuntu/+source/linux-atm/+bug/269683 [06:00] Launchpad bug 269683 in linux-atm "Patch to remove atm-dev" [Wishlist,New] [06:00] I think I got gnucash building on goffice-0-6 [06:00] :-) [06:00] another oldlibs bites the dust [06:02] ScottK: you should have pointed me to the oldlibs list ages ago [06:03] * flyback still thinks "cranky crackmonkey" was a better name for ucuntu 6.0666 [06:03] go ahead and ban me too, i'm not going to be around much longer to give a fuck [06:05] 8.04 seems sane though [06:08] StevenK: I filed a bug against the Debian package on atm-dev [06:13] ScottK or StevenK: https://bugs.edge.launchpad.net/ubuntu/+source/gnucash/+bug/269687 [06:13] Launchpad bug 269687 in gnucash "Change of dependencies from goffice 0.4 to 0.6" [Undecided,New] [06:15] NCommander: I seem to remember there being some regressions in gnucash when that was last tried in gutsy. Are you sure they are solved now? [06:15] NCommander: Which goffice is in oldlibs? [06:16] NCommander: Also, siretart (IIRC) has done some looking into this package at times. I'd check with him. [06:16] LaserJock as well. [06:18] NCommander: Why are you building the Hardy version of kdenetwork in your PPA? Didn't I upload that one already? [06:18] ScottK-laptop: I uploaded it to testbuild it at some point. Its just been pending constantly for some reason [06:18] ScottK-laptop: looking at both slackware and MacPorts, the change has been made without regressions [06:18] Ah. OK. [06:18] Well it's not pending now. [06:19] I take that back. Separate issue. [06:19] It's building anyway. [06:19] Do you know what the regressions are? [06:19] I can test now [06:19] (or if you wish to point me at the bug) [06:20] I don't remember clearly: if both slackware and MacPorts have migrated, it's likely safe. [06:21] I just ran gnucash, and tried a few basic operations, and it appears to be safe [06:21] * NCommander added an account, and put more money then I have into it [06:31] persia: well, macports transitioned three upstream releases ago, and slackware around the same time. [06:31] So it should be safe [06:42] * flyback is really starting to believe that terrorists have the right idea when dealing with assholes that piss you off [06:48] * realist wonders if the NSA is listening... [06:53] I hope so [06:53] they can come ot my house and shoot me [06:53] it's a win win for everyone === jscinoz_ is now known as jscinoz [07:09] * flyback decides that if he ever contacts his biological father his words of wisdom will be "NEXT TIME USE A FUCKING CONDUM" [07:17] ScottK: are you still around? [07:59] NCommander: do you want to at least talk with the Debian gnucash maintainer, please, before bumping its library dependencies based on nothing more than what other OSes are doing? "It builds and lets me create an account" is not exactly a high QA standard for something that handles people's money. [08:01] slangasek: I filed a bug against Debian asking them to make the same change, and the justification behind it. [08:05] slangasek: if upstream supports goffice 0.6 natively (the package was ported to support 0.6 at some point in development), I've got to assume its relatively safe [08:05] no, you don't /have/ to assume that [08:06] there are lots of ways in which linking against goffice 0.6 instead of 0.4 might be broken for non-obvious reasons, only on Debian/Ubuntu [08:07] slangasek: so what do you suggest I do then [08:07] test it more extensively, and/or find a gnucash user to do some testing [08:08] * NCommander nods [08:08] Why did the launchpad feel the need to try rebuilding miro on hppa? It still fails, because python-gtk2-dev is still not installable. [08:08] Ok, but since I'm not a regular user of gnucash, do you have any ideas where I could find a good tester? [08:08] RAOF: my fault, sorta. I posted an SRU on gnome-python-extras [08:08] RAOF: which triggered the rebuild. [08:09] no; you're the one who's pushing a library change for the package in advance of Debian, I think it's your responsibility to find the testers [08:10] slangasek: I realize that. Then I will try and find a gnucash user who is willing to help test it [08:10] NCommander: #ubuntu-bugs is often a good place to troll for testers, or #ubuntu+1 [08:12] * flyback would like to find the idoits who did his grandma's drive way and convinced her that since the olddrain pipes from the gutter were now blocked, the solution was to just cap over the downsports and force the water to all the way to another corner of the house to drain [08:12] persia: thanks, that's helpful, I'll post gnucash to my PPA so testers can easily install it [08:13] * flyback returns wet and miserable from unlocking the shit [08:15] flyback: this is a channel for Ubuntu development; please take your random comments (and inappropriate language) somewhere else [08:15] I could say the same about your buggy distro [08:19] I'm new to the world of development. I read the wiki, but still have a question. Where's a good place for new people to start? The wiki makes it look like you have to be seasoned pro to get in at square one. (sorry if this is a dumb question) [08:22] Phil_S_: That's certainly not the case; which wiki page is so discouraging? [08:22] Phil_S_: #ubuntu-motu is likely the best place to start if you want to do packaging work; #ubuntu-bugs will likely be useful if you want to start triaging bugs. [08:25] Okay, I'll try #ubuntu-motu. I was looking through the wiki for UbuntuDevelopers and must have side tracked before finding a starting point. Thanks for the help. [08:53] kees: kill -9 $$ ? [08:56] Mithrandir: heh, a little delayed? :) [09:00] * Hobbsee curses - damned intrepid bugs. [09:27] slangasek: slightly. :-) [09:31] oh, ewwww! [09:31] we have EULA's on ubuntu now? [09:31] * Mithrandir ruffles the crazy green alien. [09:31] hey Mithrandir! [09:54] Hobbsee: It's optional. epiphany-browser also works. [09:54] persia: i like firefox, though. I just don't want a eula, which i apparently can't officially accept or decline. [09:55] Hobbsee: Well, the accept-or-decline thing is a bug, but I think the EULA is just part-and-parcel of the odd Firefox licensing anyway. [09:55] persia: yeah, well. [09:55] persia: i just don't really want to see it thrown in my face like that. [09:55] So, it's either use iceweasel or have a EULA, I think. I saw some traffic about abrowser that might be a workaround. [10:03] abrowser doesn't seem to be a workaround. [10:03] At least it wasn't for me. [10:03] Why does $NEW_VERSION require a EULA when < $NEW_VERSION doesn't? This seems suspicious and wrong. [10:06] wgrant: I suspect an upstream change of some sort, although I've not inspected the code. [10:06] Also, I thought abrowser was supposed to be trademark-free (no branding). How does that require a EULA? [10:06] It seems a rather odd change for a 0.0.1 increment. [10:06] persia: Maybe somebody forgot to turn it off. [10:07] That would make sense. abrowser *ought* to be a workaround. [10:08] It doesn't seem to mention trademarks. [10:09] It just says that a portion of the code might be available. [10:09] And that I need to read the EULAs of the other pieces of software that the installer may ask me to install. [10:09] Both of which are false. [10:10] Right. I can accept the idea of a click-through EULA, but only if it's actually accurate. [10:10] Well, the first is true. [10:10] It's not click-through, though. [10:10] And the second is a good idea. [10:10] What installer? [10:10] We do not have the installer of which it speaks. [10:10] libapt and similar sorts of things. [10:11] So, I've got a somewhat strange i18n bug from gnome-do. When the translation .mo file is installed under /usr/share/locale/[lang]/LC_MESSAGES translations don't work; when it's under locale-langpack it works. [10:11] It's a good idea to read the licenses, although it's generally true that anything in main or universe is at least free to use for any purpose. [10:12] The end of section 3 appears to be the only mildly useful piece of information. [10:16] I'm pretty clueless about i18n. It's my understanding that installing the mo files to /usr/share/locale/[lang]/LC_MESSAGES should work. Any ideas why it doesn't, and why moving them to locale-langpack makes it work? [10:18] When will the 96.xx.07 driver be in envyng [10:19] After someone answers my question about translations, hopefully :) [10:23] Hmmm, the EULA has " | Ubuntu" on the end of the title. This must mean it is deliberate. [10:39] tseliot, when will the envyng program work with legacy cards using 96.xx.xx [10:40] terminator_: you should really ask nvidia about this. It's not my fault [10:41] I know it's not your fault and I did write nvidia and I am waiting for a reply [10:41] I just thought you might have am ideaa when it would be ready. [10:41] no, sorry [10:42] OK , thank you. I will keep pestering nvidia for an answer. [10:53] persia: you still awake? [10:53] NCommander: typically [10:54] persia: I'm curious if you believe removal of gtk 1.2 from the archive (that is, fixing or porting all of its rdepends), is a worthwhile goal for jaunty [10:56] * NCommander notes the last release of gtk was sometime in '02 [10:57] er, 1.2 [10:58] NCommander: I've thought it was a worthwhile goal for each release since feisty. Mind you, I don't think it's worth removing any applications. [10:59] persia: I'm filing a bug with taks on every rdepend (132) for gtk1.2 towards that goal [10:59] And I'm going to work probably through all of jaunty removing gtk1.2 from the archive by clearing its rdepends one by one [10:59] and filing patches with Debian and upstreams [11:01] NCommander: OK. Towards accomplishing that, could I convince you to port searchandrescue to the new joystick API? It uses the linux 2.2 API (which is still supported), but that requires a GTK1.2 joystick calibration tool, which breaks joystick calibration for everything else. [11:02] persia: I don't own a joystick so I can't say I'm suited for that goal due to lack of hardware [11:02] I should be able to assume that GTK 2 has a joystick calibration tool as well, right? [11:04] * NCommander found the joystick code in search and rescue [11:05] That uses libjsw, and not gtk directly [11:05] So it appears the changes need to be made there, and not in sar === tkamppeter_ is now known as tkamppeter [11:06] so the package that needs porting to be specific is jscalibrator [11:06] *specifically [11:09] NCommander: No. jscalibrator and libjsw need to be deleted with prejudice. [11:09] (read the changelog to see how I developed this opinion) [11:10] ow [11:10] I'm unaware of any other joystick libraries [11:11] Then again, only search and rescue use libjsw [11:13] persia: so should I should try and kill libjsw if possible? [11:15] persia: SDL has a joystick library, probably the best chance of porting this successfully [11:17] persia: ew, libjsw and searchandrescue were written by the same author. I don't think they want to dump their own joystick library [11:19] NCommander: searchandrescue is dead upstream. Debian will accept the patch as soon as squeeze opens. [11:20] (well, not "dead", but no longer of real interest to the primary developers) [11:20] It's exceedingly likely that Fedora will also accept the patch, as interest has been expressed. [11:21] persia: I don't have joystick hardware so I can't do it. The best I can do is port the calibration rtool, and leave an open tracker item [11:22] NCommander: gizmod will let you map any arbitrary input device to any other arbitrary input device with a couple lines of python. Just mirror your mouse to be a 2-axis, 5-button joystick. [11:24] persia: SDL hooks right into the kernel joystick driver, and I don't think gizmod would emulate joydev [11:25] NCommander: It does. gizmod works at the device layer. [11:26] I'll look into it [11:26] Mind you, gizmod is complex enough that everyone else also writes dedicated userspace drivers for random input devices, and there's talk of extending DeviceKit so that gizmod is obsolete, but for now it's still easier than using uinput directly. [11:52] * NCommander finds that porting packages with funny font manipulation feels like an oncoming headache [12:14] why did intrepid change kernel where they use an rc kernel? [12:21] s0u][ight: There were reports of issues with 2.6.26 that were known solved in 2.6.27, and it was believed that 2.6.27 would fix more problems than would be introduced by the inevitable regressions. Whether this is true has yet to be determined. [12:22] like with compat-wireless there are now 2 versions introduced [12:22] and some patches i need don't apply for the new one [12:23] 2.6.27 broke ACPI on my laptop it seems :-/ [12:23] Or at least, power management [12:46] NCommander: please see my comment on your bug report about libdb1-compat; when the maintainer is an Ubuntu developer, it might be worth talking with them about it :) [12:46] is it possible with the alternate ubuntu installer to encrypt just one partition, and not the whole drive? [12:46] cjwatson: the package was synced from Debian though [12:46] wgrant: abrowser shouldn't display the EULA; that's definitely a bug, and worth filing separately from the one you already filed [12:46] uh oh [12:46] NCommander: yes, I'm aware of that :) [12:47] * NCommander aims gun. Shoots foot [12:47] cjwatson: Filing, thanks. [12:48] cjwatson: ok, well .... now that I've already shot myself in the foot, I'll mark that invalid :-) [12:49] NCommander: ok, thanks [12:49] cjwatson, remember me trying to install the 2.6.26-5-generic? [12:49] yes [12:50] cjwatson: does that also apply to ncurses5? [12:50] NCommander: I know nothing about that [12:50] the linux-headers-2.6.26-5-generic didn't install because i didn't have the linux-headers-2.6.26-5 in my repos :) [12:50] NCommander: best would be to look back through the history for the reason it was introduced [12:50] there's usually a bug report or something [12:50] s0u][ight: that would be it [12:51] theclaw: yes, you can do that with manual partitioning, though it's fiddle [12:51] fiddly [12:52] Oh, it was done since some things didn't support the new ABI of ncurses5 [12:52] er, api [12:52] theclaw: create a partition, mark it as use as: physical volume for encryption, select configure encrypted volumes, follow prompts, then you should get a new region of free space in the main partitioning display on which you can create a normal partition [12:53] theclaw: I don't recall whether doing this for your root filesystem works, though [12:54] cjwatson: oh, I overlooked this "configure encrypted volumes" option, thanks [13:02] Hey! I want to make a new geometry-file for my Typematrix and share with you guys, is there any cool apps to do this or do I need to do it in text-mode..? if so, is there something I need to have in mind? Thanks in advance [13:12] cjwatson: that's a bit strange: in the encrypted lvm volume, I could create only one partition; the other space was labeled as "unsued" and I couldn't create a new partition there, but just "show information" [13:12] cjwatson: I hope I can do this later on [13:40] why does it want to have lilo installed instead of grub? [13:41] it wants to install lilo on /dev/mapper/sda5_crypt === Mirv_ is now known as Mirv === Eghie is now known as Eghie`afk [14:43] theclaw: yes, you can only create one partition; if you want more than one, create a single partition there, mark it as "physical volume for LVM", select "configure the logical volume manager", and create multiple logical volumes. [14:44] theclaw: sounds like you tried to put the partition containing /boot on LVM. grub doesn't work with that [14:44] (or at any rate the installer code believes it doesn't) [14:45] theclaw: you probably just need to create a separate unencrypted /boot [14:56] cjwatson: no, I didn't, boot is a seperate partition [14:56] cjwatson: I forgot to set the bootable flag [14:56] cjwatson: it works now, but I created just a single partition inside lvm, no physical volume [14:56] cjwatson: can I put this partition in a new physical volume without reinstalling? [14:58] only if you have enough space on the disk to move all the data elsewhere temporarily, and if you're familiar with using the LVM tools by hand [14:58] if the installation is new and there's nothing important there, it would probably be easier to just blow it away ... [14:59] oh mz. [14:59] oh my. [15:00] so do I get this right? I create a "physical volume for lvm", i.e. at the moment I'm not using LVM at all? I'm just using dmcrypt? [15:00] *sigh* [15:01] that's right [15:01] assuming you *didn't* create a physical volume for LVM [15:01] I did say it was fiddly :-/ [15:02] I just created a physical volume for encryption, yep. [15:02] I thought it does all that "behind the scenes" and that it's just a installer-bug which caused the 1-partition-limit ;) [15:02] yep, then I'll blow all away again [15:03] thanks cjwatson :) [15:03] for your help [15:03] no big deal reinstalling, anyway. [15:07] I feel like a idiot now :) [15:07] *an [15:08] don't. the partitioner's support for complex block devices is more complicated than it should be. [15:11] hmm [15:12] when I create a volume inside a volume group, it seems that the size of this volume can't be set to an arbitrary value [15:13] can you be more specific? [15:14] sorry; I set it to '48000 MB', but it's 50331 MB [15:14] (50331 MB is shown it "configuration details" [15:16] hmm [15:16] $ bc -lq [15:16] 48000*1024*1024/1000/1000 [15:16] 50331.64800000000000000000 [15:16] it's using the wrong units [15:17] thanks [15:17] maybe mib works [15:17] doubt it [15:18] this is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411943 [15:18] Error: Could not parse data returned by Debian bugtracker: global name 'ls' is not defined (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411943;mbox=yes) [15:18] it's fixed in current partman-lvm but I wasn't happy about pulling the changes involved into intrepid after feature freeze [15:18] so we'll get it in jaunty [15:20] okay [15:24] haha that's so confusing; sometimes it also displays the correct values! [15:25] or, no, doesn't :) [15:25] sorry, I'm kinda confused now, but so what, I have to do it only once ;) === pbn_ is now known as pbn [15:31] "This issue has been in partman for quite some time. There's absolutely no [15:31] reason to consider it anything than a cosmetic issue. [15:31] (sorry, two lines) - what an arrogant .. [15:45] theclaw: perhaps, but his motives at the time were to try to produce a stable Debian release and he was responding to the relatively high severity set on the bug. You need to read it in context [15:45] Frans is a good guy [15:46] I didn't think about that [15:50] thanks alot for your help cjwatson :) [15:51] #pennergam [15:51] no problem [15:51] #pennergame [15:51] Gelikafkal_: please don't spam here. [15:51] yes [15:51] ok [15:52] i've tried something out === asac_ is now known as asac [16:57] the misc-fixed bitmap-font seems to be installed, however I can't select it in gnome terminal; I did enable bitmap-fonts with 'dpkg-reconfigure fontconfig-config', and I can also select helvetica, for example; xlsfonts also lists misc-fixed-* [16:57] any idea why? [16:59] hello [17:00] hey calc [17:00] * calc still hanging out at davidm's :) [17:01] the hurricane followed me up to his place, they are expecting gusts of 50mph here [17:02] not nearly as bad as what happened at my place i'm sure, hopefully its still intact when i get home [17:02] i think they expected gusts ~ 95mph there [17:07] 3mil people in houston have no electricity :\ i'm guessing that includes my house [17:08] "The city’s last direct hit from a hurricane came from Alicia in 1983, when 750,000 CenterPoint customers lost power. It took 16 days to restore all service." [17:08] and this storm did double that === sabdfl1 is now known as sabdfl === herb_ is now known as herb === Eghie`afk is now known as Eghie [18:52] heh, who added 9MB to the live CDs overnight? :P [18:53] There was a language pack run last night? [18:53] wasn't me :) [18:53] i was hiding from a hurricane :) [18:53] calc: wimp ;-) [18:54] Nafallo: :-P [18:54] oh, it's probably whatever pulled in tcl/tk [18:55] python, seemingly [19:04] calc: you didn't make any font changes in OOo, by chance? === foka_ is now known as foka [19:05] ttf-dejavu is now being pulled in too, for 2.5MB [19:06] doko: it looks like something is wrong with the new python build, it's pulling in all of (blt -> (tcl8.5, tk8.5), tcl8.4, tk8.4) now [19:08] slangasek: it is. it is the _tkinter_failed.so stuff. the damn python configure wants to build with 8.5, and then fails. 8.5 seems to be installed, but not the -dev package. feel free to fix. I'm away for today [19:08] hmm, ok [19:08] I can look at it tomorrow [19:08] it may end up waiting for you, I don't think I have time to tackle it today [19:13] slangasek: didn't make any changes in the past couple days anyway [19:14] calc: this may be the first successful livefs build since the landscape-client issue; did you make any changes regarding font deps in the couple days before that? :) [19:14] I think the likely culprit is fontconfig-config, I'm just not sure why [19:18] yah, fontconfig-config is pulling in ttf-dejavu because its deps get pulled in before whatever pulls in ttf-freefont and ttf-bitstream-vera, both of which are also included and satisfy the | dep [19:19] slangasek: the last time i changed anything in OOo was for the 8ubuntu1 upload [19:19] slangasek: i've been working on updates since then but haven't uploaded anything else yet [19:19] * slangasek nods [19:19] calc: ok, you're off the hook then ;) [19:25] ah, the extra fonts also trace back to the python dep on tcl8.4 [19:25] that makes it easy [19:35] hi === Tonikq is now known as Tonik === hardwire is now known as CrankWidow === CrankWidow is now known as hardwire [21:40] is there some unofficial build of Nautilus offering more view options than just Icons and List? === hardwire is now known as CrankWido === CrankWido is now known as CrankWidow