=== x-spec-t is now known as Spec [01:12] is a 2GB file size limit a property of the kernel or filesystem? [01:13] Filesystem. Don't use fat, it's borken :) [01:13] I'm not using fat [01:13] I'm using ext3 [01:14] * RAOF looks at his various >4GB files sitting on ext3 [01:14] And is surprised. [01:15] then maybe it is the kernel? [01:15] or maybe an old version of ext3 [01:16] or a < 2gb HD [01:16] leonel: LOL. [01:16] LaserJock: 2GB is such a weird size [01:16] LaserJock: what inode size did you set up? [01:17] LaserJock: you didn't hit that news server button thing for fun did you? :) [01:18] no [01:18] I just have an old Debian version [01:18] it's a 120GB hard drive [01:19] and I was writing a data file and it said it reached a 2Gb limit [01:19] LaserJock: 2GB file size limit is likely the result of silly inode sizes [01:19] how can I check that? [01:19] preferably without destroying my data :-) [01:20] LaserJock: dumpe2fs dev_node [01:20] LaserJock: I think that's Block size: 1024 you should be lookin for [01:26] jdong: so it's not because I'm running a 2.4 kernel? [01:26] I get a block size of 1024 it looks like [01:27] LaserJock: I'm at least not aware of kernel 2.4 limiting filesizes down to that extremity [01:27] LaserJock: I know some userland apps have trouble with >4GiB but I'm unaware of a 2GB barrier [01:27] really? [01:27] we used to have 2GB barriers all the time [01:27] LaserJock: maybe I was just really really poor when I started with Linux 2.4 :D [01:27] was a problem when DVD .isos started being made [01:28] LaserJock: oh yeah, wget had a 2GB barrier didn't it. [01:28] yep [01:28] yeah you're right, you might be hitting userland size type barriers [01:28] I believe that stemmed from "well, we can't make a file bigger than 2GB anyway" [01:29] btw I liked your piece on Fedora [01:29] I think it roughly mirrors my experience with the distro and its community too [01:30] glad somebody thought it was ok [01:30] next up I'm gonna look at Fedora and Ubuntu SRU policies [01:30] that's the one I'm gonna put my fire suit on for ;-) [01:31] I thought Fedora didn't freeze, and as such didn't really have a SRU policy? [01:31] LaserJock: yeah you're really gonna need a fire suit for that [01:31] RAOF: they partially freeze [01:31] RAOF: i.e. they won't bring in big things that'll break the world [01:31] they have a "be sensible" freeze [01:31] RAOF: i.e. toolchain, certain kernel updates, GNOME core [01:31] RAOF: but they will feel free to bring in basically anything we call universe [01:31] Right. That makes sense. [01:32] IMO it's sensible for the home Linux enthusiast [01:32] but there are some other more philosophical things as well I'm gonna try to hit on [01:32] it's not terribly appropriate for the enterprise deployment [01:32] and I think that's something that needs to be addressed in your thoughts on it, LaserJock [01:32] Which means that their SRU policy is likely at least as stringent as Ubuntu's, right? [01:32] i.e. Ubuntu tries to cater to both enterprise and enthusiast users [01:32] while Fedora only has to dealw it hthe latter. [01:32] RHEL's SRU policy is even more stringent than Ubuntu's [01:32] (If we restrict 'stable' to mean 'the part that's frozen') [01:33] RAOF: correct [01:33] RAOF: they do RHEL-style backporting for the part that's frozen [01:33] "As a 32-bit UNIX system, Linux can handle files not longer than 2Gb." [01:33] RAOF: but that's less of a concern for the end user that just wonders why the latest K3b isn't available in a 4-month-old release [01:34] jdong: Yeah. It makes a lot of sense for some fraction of the userbase. [01:35] bye bye reiser [01:35] RAOF: I like Ubuntu's duality and I think ultimately our best solution is to cater to Fedora-like users with a more expanded, open Backports-style effort, while still doing traditional SRUs side by side [01:35] RAOF: there's no reason why they have to be mutually exclusive the way they are now [01:36] if someone wants to bring in KTorrent 2.0.4 to fix a bug in KTorrent 2.0.3, there's no reason why we should reject that just because we *can* do a SRU patch-backport [01:36] zul: I saw that. [01:36] jdong: Have some sort of Debian-testing like backports thing? [01:36] LaserJock: Yeah I liked your piece on Fedora. I intend installing Fedora on a new box I got recently alongside other distros. I want to see whats going on elsewhere. [01:36] TheMuso: let the jokes begin :) [01:36] I was honestly surprised [01:36] RAOF: yeah, I'm thinking a backports-proposed repo that all MOTUs are allowed to upload any (reasonable) packaging of their choosing [01:36] for my laptop Fedora would be my #2 distro [01:37] Debian's nice but takes quite a bit of work on my laptop [01:37] RAOF: and then the backports team ACKs such packages for copying into backports [01:37] LaserJock: I feel better having some OS diversity across my systems too [01:37] LaserJock: I'm strongly considering turning one of my systems to Fedora [01:37] jdong: the problem I personally have -backports is I almost never want the whole thing [01:38] jdong: it's well worth having a look at what they're doing [01:38] LaserJock: perhaps we need to handle pinning better via update-manager and apt/preferences then [01:38] Isn't it by default pinned so that you can install individual things & pull in the necessary deps? [01:38] RAOF: no default, backports is shut off entirely [01:38] RAOF: turning it on, update manager recognizes backports separately but checks them all by default [01:38] jdong: I mean, once you turn it on. [01:39] RAOF: and also, update-manager nags about backports updates just like any other update [01:39] RAOF: when you turn it on, it's not pinned at all [01:39] Oh, right. Yeah, that could be better. [01:39] jdong: what if we did something more like Main -> more enterprise like, Universe -> more desktop like [01:39] and have a strict SRU policy for Main and Fedora-like for Universe? [01:39] LaserJock: doesn't handle the use case of transmission, KTorrent, and other universe-like apps that seeped into main [01:40] LaserJock: but in general that distinction works well [01:40] jdong: but those could be perhaps handled via exceptions? [01:40] LaserJock: perhaps the added provision that we are allowed in universe-SRU to override a main package [01:40] (puts on flamesuit!) [01:40] yikes [01:40] Or a reworking of the archive structure, ala that u-d thread. [01:40] LaserJock: it sounded better before I wrote it down! [01:41] RAOF: that would be a rather messy SRU policy [01:41] I'm not sure how we'd do it there [01:41] per-seed SRU policies sounds like not-so-fun times [01:41] LaserJock: my opinion still stands that we should open backports uploads to all SRUs and filter them through a -proposed queue on backports [01:42] and keep SRUs there too [01:42] hmm [01:42] there's defintiely some packages in universe we want to do regular SRUs for, like lighttpd, clamav, etc [01:42] I kinda am not found of that idea [01:42] *fond [01:42] and IMO those two styles of updating should be kept as independent efforts in independent repos [01:42] Fedora makes no attempt to combine them [01:42] which is why Fedora is not designed for an enterprise environment [01:42] if an SRU should be done it should be done, doing it in -backports seems like a workaround [01:43] LaserJock: it might be a workaround but is a faster , more effortless soltuion that satisfies the enthusiast user [01:43] LaserJock: it doesn't preclude the delivery of a SRU [01:43] maybe we can have an SRU policy that accommodates that though [01:43] LaserJock: that's like the archive admins refusing to pull a faulty update because it's a workaround of uploading a new fixed one tomorrow ;-) [01:43] well, let me rethink this [01:43] they should be complementary [01:44] I guess in a broad definition of SRU it makes sense [01:44] so if we break it up into bug SRUs and feature SRUs [01:44] LaserJock: I think it makes more sense to break this down in terms of use cases [01:44] then we have a reasonable definition of -updates and -backports [01:44] we clearly have two different usecases that Ubuntu tries to meet: [01:45] (1) Joe User is running Ubuntu on his personal laptop. He hears about the newest KTorrent that fixes 2 bugs and adds a major new feature. He wants to try it out. [01:45] (2) Bob Sysadmin manages an enterprise KDE rollout. He is concerned about 1 of the bugs in KTorrent which is a remote crasher but doesn't want the risk of regressions from the unrelated updates. [01:45] #1 should be handled as a backport and #2 should be a traditional SRU [01:46] sure [01:46] both can be offered side by side because typically it's different people who want them [01:46] that's the current situation, IMO [01:46] and in fact different people who will perform the update [01:46] LaserJock: current situation is technically we're not allowed to backport for the purpose of bugfixing [01:46] LaserJock: and also backports must be derived from development packaging, when sometimes current packaging + uupdate is more appropriate [01:46] but that would be a SRU under your scheme [01:46] (i.e. when Intrepid undergoes some migration or rocky packaging) [01:47] what I'm saying is we should be allowed to do both. Both backport with intent to fix bugs AND introduce new features [01:47] well [01:47] that's kinda grey [01:48] the only major issue I see is versioning convention [01:48] if doing a new upstream releases fixes bugs I don't think anybody is going to complain ;-) [01:48] but the purpose of -backports is for user 1) [01:48] LaserJock: indeed , but the current imposed limitations on backports doesn't satify user #1 [01:48] jdong: why? [01:48] LaserJock: I'd estimate 25% of backports requests get approved ultimately. [01:49] jdong: Backports shouldn't be a workaround for SRUs are to hard. [01:49] hi [01:49] i hope here am right [01:49] LaserJock: the remaining 25% are packages that FTBFS due to a migration, 25% are bugfix-only updates that the archive admins would reject, and the remaining are during a freeze or other case where development branch cannot receive the new version necessary [01:49] can someone help me with this bug ? https://bugs.launchpad.net/ubuntu/+bug/223843 [01:49] i found out it have nothing to do with the xrdb error messages in .xsession-errors [01:49] jdong: I think backporting for non-sru worthy bug fixes should be fine. [01:50] ScottK: I don't think we need to preclude backporting SRU-worthy fixes either [01:50] I've been accepting that all along in fact. [01:50] ScottK: because there's no reason why the presence of that backport would discourage/preclude a SRU anyway [01:50] jdong: but they should be fixed in -updates? [01:50] LaserJock: ideally they should be fixed in both [01:50] jdong: I think they should do the SRU first if it's feasible. [01:50] LaserJock: independently at their own pace [01:50] jdong: well, sure [01:50] but there's nothing that says you can't do that now [01:50] one should not discourage/preclude the other [01:51] jdong: I think that's a good theory, but in practice backports do take the pressure off getting an SRU done. [01:51] I just don't know why you'd want to do the same thing twice [01:51] ScottK: should we really be artificially be imposing that pressure to favor SRUs though? [01:51] It's not the same thing twice. [01:51] jdong: We should. -updates is enabled by default and -backports is not. [01:52] LaserJock: a SRU fix is often not the same as a backport both in the patch itself and the validation process involved [01:52] Each for good reasons.. [01:52] ScottK: why isn't it? [01:52] LaserJock: volatility and reduced QA [01:52] I'm just not sure I have good realistic cases here [01:52] LaserJock: backports is pretty lax on letting new packages in and they're probably at a higher regression risk [01:52] jdong: so? [01:53] LaserJock: users might cry and whine when backports breaks things [01:53] not like they don't when -updates breaks things ;-) [01:53] what I'm saying is, if a bug is SRU worthy, then should get it into -updates [01:53] The standard for backports is "Builds, Installs, Runs". Updates go through rather more QA. [01:53] why would we then do the same thing in -backports? [01:53] when the user is getting the fix from -updates [01:53] We wouldn't do the same thing. [01:53] LaserJock: because it's often not the same thing [01:53] then I don't see the problem [01:53] you can already do it [01:53] LaserJock: the backport would be we take the latest upstream tarball and package it and upload it [01:53] just upload your new upstream release [01:53] -updates would get a targetted patch. -backports gets the whole new version. [01:53] ScottK: that's my point [01:53] LaserJock: the SRU would be examining the changes line-by-line and isolating only the useful ones [01:54] there's no reason you can't do that now [01:54] LaserJock: other than the limitations the TB imposed on backports [01:54] no [01:54] LaserJock: i.e. speicifcally we are not allowed to backport for bugfixing reasons [01:54] but you aren't [01:54] you're backporting a new version that happens to fix a bug [01:54] no biggie [01:54] LaserJock: try telling the archive admins that ;-) [01:54] why would they object? [01:55] LaserJock: I've gotten rejected backport approvals for that reason before [01:55] how would they know? [01:55] LaserJock: i.e. "this looks like it should be SRU, won't do" [01:55] LaserJock: they read the backports bug tickets [01:55] hmm, I guess I'm not really up on -backports, I can't imagine why there's an issue [01:56] if a bug is SRU worthy then it should be in -updates [01:56] that says *nothing* about -backports [01:56] LaserJock: agreed [01:56] ScottK: do you think I'd be in a shark-infested pool alone to propose that -backports get a -backports-proposed where all MOTUs are allowed to upload? ;-) [01:57] jdong: what would that do for us? [01:57] I suspect the rationale is that a bugfix oughtn't be backported before it goes to -updates, rather than that bugfixes oughtn't go to backports. [01:57] LaserJock: increase the accessibility of the backports path [01:57] persia: I think the ultimate rationale is that IF we allow backports to do it, then nobody would bother separating out the patch for SRU because it's more work [01:57] i.e. people would start saying that Backports "fixes" some bug as a solution. [01:58] jdong: and why do we want that? [01:58] jdong: I think anything that increases archive admin steps is a bad idea in the current archive management paradigm. [01:58] jdong: Right, [01:58] jdong: I think that's correct [01:58] LaserJock: why do we want the current system that I have to keep ScottK on a leash for sponsoring backports? ;-) [01:58] we want to push people to -updates for bug fixes [01:59] as that's turned on by default and is the minimal use-case for getting a fix to people [01:59] jdong: I just wondered if you're having a hard time getting backports done or what. I just don't know [02:00] LaserJock: at times, yes. I feel like the burden is mostly on ScottK and I to do all of the grunt of the work and people who can be testing can't really test because packages are not readily available [02:00] We have choke points all along the path. [02:00] k [02:00] I don't do backports because I don't use -backports [02:00] Not enough testers, not enough core-dev support, not enough archive admin time. [02:00] that's sort of a limitation === twanj____ is now known as twanj [02:01] LaserJock: backports would work great from a community testing model where users volunteer as guinea pigs for a -proposed archive of just generously-built backports [02:01] LaserJock: msot of the users I speak to have no reservations about putting their systems up for such a job [02:01] LaserJock: but they also are afraid of the pbuilder/prevu build process [02:02] hmm [02:02] what if you had a PPA? or do you do that already? [02:02] LaserJock: imagine if all SRU verifications had to be done by posting a debdiff and asking users to "go test" [02:02] LaserJock: well I've considered using a PPA to simulate such a build but I'd like it better if it were something official [02:03] hmm [02:03] it just seems to me that we should be able to create common testing grounds/tools/strategies [02:04] I don't think we get nearly enough testing from -proposed [02:04] LaserJock: the other advantage of having an archive is the ability to directly copy a tested backport verbatim, without having to deal with the race condition of the devel branch getting a new upload [02:04] We get 'go path' is the bug fixed testing, not are there regressions testing. [02:04] LaserJock: I don't think users are too aware of the SRU -proposed archive sheerly because of its low volume and "uninteresting" updates [02:05] LaserJock: I'd venture a bet that a theoretical testing backports repo that accepted new version backports of everything to be quite "popular" ;-) [02:05] (good thing or not, I won't say!) [02:06] *sigh* [02:06] I suppose [02:06] maybe I've just completely lost my sanity tonight :) [02:06] if we could get more testing though I think we could have more interesting uploads to -proposed [02:06] s/tonight//g [02:06] LaserJock: there is this viscous cycle :) [02:08] jdong and LaserJock: My clamav updates to Dapper are perhaps an interesting hybrid. That went PPA (test) -> dapper-backports (test) -> dapper-updates [02:09] clamav and a all the needed rdepends [02:12] in reality, I think -proposed is almost useless [02:13] for almost all SRUs your not gonna just enable -proposed and say, "Oh, they fixed that, cool" [02:13] When there was a bad upload of svn to gutsy-proposed a few months ago we got a lot of bug. [02:13] * ScottK would never just enable proposed (although apparently people do). [02:13] people most often have to read the bug report, check out the use cases, and actively test [02:14] you're pretty much just as well to attach a .deb or link to a PPA [02:15] What proposed gets you is knowing exactly what's going to end up in -updates is what got testing. [02:15] yep [02:15] assuming that people actually test & give feedback on -proposed [02:15] That and you aren't encouraging people to install random software from bug reports/third party repos. [02:16] but having an option for it in "Software Sources" does pretty much nothing [02:16] if you know what I mean [02:16] -proposed and -backports should really be pinned when enabled... why don't we do that? [02:17] Good question. [02:17] * wgrant hasn't read the whole conversation, as he's at work. [02:18] I'm just trying to think of some ways that we can actually get some testing for SRUs [02:18] as I think that opens up a lot of possibilities [02:19] Have people subscribe to a mythical testing ML, to which emails soliciting SRU testing are sent. [02:20] that's a good idea [02:21] hmm, I wonder if something along the lines of the iso tracker could be used [02:21] and plugging more into the QA team [02:23] say we had a page with a list of packages [02:23] and then individual pages for them that give the test case and a place to click on a "worked for me" [02:23] then promote the snot out of it [02:25] Heya gang [02:26] * ScottK is envisioning this page on Launchpad. It will be slow and very confusing, but look really cool. [02:26] heya bd. [02:26] bddebian even [02:27] Gotta hit tab for the tab completion to work. [02:27] Heya ScottK [03:21] leonel: Debian package of clamav 0.93 is up in the clamav PPA. [03:42] soyuz eating ppa uploads for anyone else? [03:50] Nevermind. Finally showed up. === dmb_ is now known as dmb [04:11] Three cheers for upstreams that rely on internal interfaces of things they build against. [04:11] * ScottK slaps klamav across the room and heads for bed. === greeneggsnospam is now known as jsgotangco [04:22] so when I try to build a package with dpkg-buildpackage it complains about no Makefile [04:22] ..but it has the instructions it needs in the rules file. I'm lost.. [04:22] Zelut: Is the rules file executable? [04:23] TheMuso: it is [04:23] Well obviously a makefile is not found, which the rules file in calling the make command, says it needs. [04:24] http://pastebin.ca/1001327 - this is the output of my attempt. [04:25] the application does not need to be compiled. the rules file just needs to install them to a few locations. [04:26] I guess I don't see / am not familiar enough with the rules file to see why/where its looking for a Makefile [04:29] Line 27. It calls make. This implicitly looks for a Makefile. [04:30] this is my first rules file.. let me paste what I have and maybe ya'll can tell me what to trim [04:31] * persia suspects the problem is the use of dh_make [04:31] http://pastebin.ca/1001333 [04:31] OK. Quick look: firstly, do you have a ./configure in the source? [04:32] I don't. [04:32] OK. Then you likely don't need either of the configure or configure-stamp rules. [04:32] all this package needs to do is place 'origami' in /usr/bin and the docs in /usr/share/doc. [04:32] Keep walking through the file with the same sanity check. [04:33] For something that simple, I'd recommend just having a CDBS include of debhelper.mk, and an entry in debian/origami.install [04:33] I'm fine with that too if you want to walk me through that :) [04:37] Zelut: OK. Rules file is two lines. [04:37] #!/usr/bin/make -f [04:38] include /usr/share/cdbs/1/rules/debhelper.mk [04:38] debian/origami.install is one line [04:38] origami usr/bin [04:38] add CDBS to the build-dependencies in debian/control [04:39] done [04:40] do I need to add the docs I want in /usr/share/doc/origami into the origami.install file? [04:41] what is the proper way to use dh_compress and dh_installman? [04:41] assuming I have a prog.1 file already [04:41] Zelut: List them in debian/origmai.docs [04:41] coppro: List it in debian/package.manpages [04:42] dh_compress first, right? [04:42] coppro: I think you shouldn't have to give any arguments to dh_compress [04:42] No. [04:42] StevenK: thank you. [04:42] dh_man first. [04:42] ok [04:42] persia: ok, so what do I use to build this voodoo magic? [04:42] thanks. let's see if this works [04:42] Zelut: debuild :) [04:43] (assuming CDBS and debhelper are installed) [04:43] % debuild :) [04:43] zsh: parse error near `)' [04:43] * StevenK hides. [04:43] mksh: syntax error: ')' unexpected [04:43] Right then. `debuild # :)` [04:43] 1| [04:44] haha [04:44] persia: wow.. so it built. cdbs is magical voodoo isn't it :) [04:45] Yes. It's magic. For simple things, magic is quick and easy. If it gets complex, it may be worth unwinding (I really don't like the sendmail debian/rules) [04:46] now, lets say I wanted this package to run three basic commands to clean something up. How would I do that? [04:47] See, that's where you start getting into deep magic. You'd add an override rule. Look at the CDBS documentation from perso.duckcorp: it has a list of common overrides. When you get longer than about 30 lines, you likely don't want to be using CDBS anymore. [04:48] ok. [04:52] and where can I find the correct list of possible options to fix a doc-base-unknown-section error? [04:52] I can't figure it out! === RAOF_ is now known as RAOF === dmb_ is now known as dmb [05:08] i wrote a patch to fix a bug (LP: #221661). would someone be willing to review it and tell me if it's OK? [05:13] (perhaps ubuntu-devel is a better place to ask... i'll try there) [05:13] bug #221661 [05:13] a7x: it might be easier to apply the patch and upload to revu [05:13] persia: bot is gone [05:14] Erm, no. bugfixes don't belong in REVU: that's for new packages. [05:14] ah [05:14] debdiff on bug report thats right [05:14] For bugfixes, best to generate a patch, either put it in a debdiff (or have someone else do that), and subscribe the sponsors. [05:17] i'm new: what's debdiff? [05:18] a7x: you'd really want to catch mvo or Amaranth who are both familiar with compiz enough to give you a meaningful answer [05:18] ScottK: Great diffs I'll send them tomorrow [05:18] a7x: intuitively from looking at the patch I side with you that the current use of export $ENV does nothing useful [05:18] a7x: You might want to take a look at https://wiki.ubuntu.com/MOTU/Contributing (although you may well find someone here who would review your patch) [05:19] jdong and persia: thanks [05:19] how do I get rid of doc-base-unknown-section [05:20] br1|: /win 11 [05:23] well that was deft [06:13] Good morning [06:18] * persia is amused by intrepid FTBFS reports, and wonders if the FTBFS tracker is watching intrepid yet [06:20] Hah [06:22] persia: It is now. [06:22] It's not right, but... [06:24] I can't see why. [06:26] Hey, what exactly do I put into dput to upload to hardy-proposed for an SRU? [06:27] incoming = /hardy-proposed/ ? [06:27] All 0? Strange. I received at least two reports for hppa. [06:27] persia: As did I. [06:27] Well, they were for lpia, and one for hppa. [06:27] actually launchpad rejected incoming = /hardy-proposed [06:27] YokoZar: just upload to ubuntu as usual, with hardy-proposed in your .changes file [06:28] Actually, I've a couple powerpc failures as well. [06:28] YokoZar: new wine for -proposed already? :) [06:28] Ah. [06:28] rmadison is broken. [06:28] persia: you mean as distribution? [06:29] YokoZar: preceisely [06:29] ajmitch: Yeah the package needs to depend on lib32nss-mdns otherwise dns can't be done on amd64 [06:29] You can set this in your changelog entry [06:30] Hmm, I think intrepid is borked. [06:30] It has no packages. [06:31] borked, or just not setup fully yet? [06:31] YokoZar: yes, that's a definite issue [06:31] Both. [06:31] YokoZar: Isn't that only the case when libnss-mdns is installed? [06:32] wgrant: The Packages files seem large enough [06:32] Hrm. Somehow I don't think the buildds ought be running intrepid before it's set up... [06:34] StevenK: Ah, it didn't have any packages a few hours ago, and I presumed that was why rmadison was being empty. I see it has packages now. [06:34] (hardy)root@liquified:~# grep -c Package /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_intrepid_*Packages | cut -d: -f2 | numsum [06:34] 24819 [06:35] I see LP even says it has packages. [06:36] So rmadison ought catch up with the next run of some cronjob? [06:36] So somebody needs to fix rmadison. [06:36] Is rmadison using a dak import, or some new Soyuz-specific implementation? [06:36] Neither [06:37] StevenK: What, then? [06:37] wgrant: It runs madison-lite [06:37] Aha. [06:43] StevenK: Should I poke some archive person about it when they appear? [06:44] I don't see the point bugging them until the toolchain is uploaded. [06:51] Is it not yet? Why am I getting build failure messages then? [06:52] Is it just trying to rebuild packages with the old toolchain when the binary version doesn't match the source version? [06:53] persia: That's right. [06:54] IIRC the build queue thing creates build records for the next distroseries if the build in the previous distroseries failed. [06:54] Nifty. All the FTBFS's that don't with the latest build tools ought get fixed then :) === Coper_ is now known as Coper [06:56] Yay, we have a bot. [07:35] wgrant: rmadison should be sorted. [07:38] siretart: hi, do you know if the pulseaudio fixes and improvements mentioned in libxine 1.1.12 relnotes are the same ones backported in ubuntu's 1.1.11.1-1ubuntu3? [07:52] hey kahrytan can't you get to terminal? ctrl+alt+f1? [07:52] Taylor, What? [07:53] kahrytan: because if you can get to the terminal by pressing ctrl+alt+f1, then the monitor isn't supported by xorg by default [07:54] I can get to it but screen resolution is messed up. Text is enlarged. [07:54] You must have been in club. [07:55] janimo: yes, at least they should be. why? [07:55] siretart: thanks [07:56] siretart: PA does not seem to get along with totem-xine [07:56] Taylor, Why you talking to me here? [07:56] siretart: and I was suggested to maybe check out the latest xine which has PA fixes [07:56] we had testers on launchpad claiming it would work [07:57] kahrytan: because you left ##club-ubuntu [07:58] No one talked. [07:58] kahrytan: that's true [07:59] kahrytan: did you try editing the xorg config? [07:59] pm [07:59] yeah [08:00] !pastebin > kahrytan [08:37] Bug #220952, someone added linux-restricted-modules-2.6.24 to the bug even though it has nothing to do with nvidia drivers. Though, someone did attach mandriva #40403 bug to it and it mirrors the same problem. Could someone correct the bad attachment. [08:39] kahrytan: That's really an #ubuntu-bugs question: looking anyway [08:39] aww. ill redirect in the future [08:41] * persia waits for a join for feedback... [08:43] morning [08:43] What is motu? [08:44] motu is an acronym for 'masters of the universe' [08:45] they take care of the 'universe' component of ubuntu [08:45] which is the community maintained part of ubuntu [08:45] Oh [08:45] so the motus are mostly community developers [08:45] Then, are you to blame for adding the broken Alien Arena to Hardy [08:45] the motu-games team have merged with the debian games team. [08:46] darn [08:46] in short, the answer to your question is yes. [08:46] The game is broken .. seems well known [08:46] but you might have to hound the debian-games team for that problem :) [08:46] that's a pity. it's a very popular game. [08:46] Well, a fair number of debian-games people are also here [08:46] try playing it for more then 2 maps on single player ... [08:47] 2008 version works from google search. [09:53] happy SRU'ing everybody [10:40] norsetto: Indeed...already got one for Wine... [10:54] G'morning [10:55] morning iulian [10:56] Hey jpatrick [11:03] way to go yokozar [11:33] oy === Nightrose_ is now known as Nightrose [11:51] super proppy is in, all bow [11:54] * proppy hail to norsetto [11:54] \o/ .* [11:54] .* = fireworks ? [11:54] .* == regexp [11:55] aah ^.*$ [11:55] No point doing that. [11:56] Restricting that there are 0 or more of any character anywhere in the line should be somewhat similar to matching 0 or more of any character being the entire line. [11:56] sure, but it's pretty [11:56] FSVO pretty. [11:56] useless is pretty [11:57] wgrant: FSVO ? [11:57] For some values of. [12:09] hi folks [12:17] heya [12:17] hi emgent === __Czessi is now known as Czessi [12:52] !bot [12:52] I am ubot5, ubotu's backup today. :) [12:53] ah, there we are [12:59] \sh: ping [13:01] <\sh> zul, pong [13:01] \sh: do you do the php-xdebug stuff for universe? [13:02] <\sh> zul, I uploaded and bugfixed the packages, yes [13:02] \sh: : have you seen #217980 [13:02] <\sh> bug #217980 [13:03] ubotu must be on holidays :) [13:03] <\sh> zul, hmm?? no open bugs? [13:04] check the apache2 bug listing for 217980 [13:04] <\sh> zul, yes...I have it now [13:04] <\sh> well, the problem is zend-platform ;) [13:05] hoi [13:07] \sh: well no the user says he had to remove php5-xdebug [13:07] <\sh> zul, yes, because zend-platform does not support other modules next to it [13:07] \sh: ok [13:08] <\sh> zul, acrtually zend-platform is closed source, in our company the situation was that, that we couldn't use zend-platform with xdebug, because zend-platform doesn't like some compile options [13:08] btw, is the UTF8 character at the beginning of the /topic intentional? [13:08] <\sh> zul, btw..this applies on windows, too [13:09] care to comment on the bug report then [13:10] <\sh> I'll do...I'll subscribe to the bug and do a full knowledge transfer this evening from home... [13:11] * \sh just wonders why he doesn't use the build in zend module for debugging, which is delivered with zend-platform [13:11] thanks [13:11] <\sh> well, most likely it crashs because of the strange compile stuff they need...and the build in module works only with zend-core apache package, which doesn't work with php-xdebug, too ;) [13:23] So. I've got this opensuse src.rpm that I know must have the patch I need in it. What's the easy way to break into this thing and extract stuff? [13:24] ScottK: turn it into a tar.gz using alien? [13:24] Maybe. I'm asking. [13:24] \sh: You used to do rpm stuff all the time. What do you recommend? [13:27] ScottK: running away. [13:27] laga: That seems to work. THanks. [13:27] Hobbsee: That's worked up to now. Unfortunately klamav FTBFS with the new clamav just uploaded to Debian and opensuse seem to have got it working. [13:28] <\sh> ScottK, you just need to extract a patch? [13:28] <\sh> ScottK, apt-get install rpm ; mc ; choose the rpm voila [13:31] mc does that. Cool. [13:32] <\sh> ScottK, the magic is pkg rpm ;) without it, it doesn't extract the cpio ;9 [13:32] <\sh> zul, anyways..updated the bug report...you can decide to invalid it [13:33] \sh: thanks [13:33] Right. [13:39] The magic opensuse solution was "remove klammail as it no longer builds against clamav". Urgh. I'd hoped for actual fixing. [13:39] <\sh> lol === danielm_ is now known as danielm [13:43] Even better their patch removed the binary, but left the UI for the now missing function. [13:44] yay, I win with the first package in hardy-updates :) [13:46] damn :) [13:54] sistpoty|work: I'm not sure that's actually a 'win'. [13:55] ScottK: depensd if it builds or not. [13:55] Yeah. Particularly in this case. [13:58] hm? it is already published actually, so it did build... :) [13:59] sistpoty|work: re bug 208666, I'm not suure Debian's binNMUs are synced or rebuilt automatically, so we probably need a manual rebuild. [13:59] DktrKranz2: yes... error on my side. the source version is not changed, so nothing to sync. I'll take care once intrepid is open [14:00] sistpoty|work: thakns. and congrats to be the first one to populate hardy-updates :p [14:00] thanks :) [14:00] *thanks === asac_ is now known as asac [14:12] can i already upload debdiffs to launchpad and subscribe u-u-s? or doesnt it make sense yet? [14:14] Kopfgeldjaeger, For hardy? [14:14] for intrepid [14:14] Sure, upload it. [14:14] ok [14:15] It won't be uploaded until Intrepid is open but you'll be able to get it reviewed and what not and be able to get it in quick once it is open. [14:17] assuming the package doesn't need a merge, or further modifications to make it build. [14:18] norsetto: I've been playing with libitpp yesterday evening, but I couldn't actually find s.th. which doesn't work with the *old* version. any hints what I could try? [14:18] (as I'm looking for a good test case) [14:19] sistpoty|work: can't help you there, I have spent days looking for something too without success [14:20] ah, k [14:49] how can i make debdiff not show the /tmp directories? i mean, when i debdiff two .dsc's, i get something like this: http://nopaste.com/p/aFY7mefYB [14:49] but of course i only want the path starting from gthumb-2.10.6/... [14:50] i knew the solution some time ago :/ but i've forgotten it [14:50] Kopfgeldjaeger: cd into the directory which contains the gthumb-* ? [14:50] whihc appears to be different directories, in your patch [14:51] Kopfgeldjaeger: Generally, install patch-utils. If that's not enough, you're working on a native package. [14:52] persia: oh, so that's the problem. [14:52] yeah. i thought the solution once was to install the package patch-utils and then debdiff behaved the "right" way. but patchutils is installed :/ [14:53] Kopfgeldjaeger: uh, those sources are in 2 different parent directories, in /tmp. [14:53] Kopfgeldjaeger: it's never oging to wokr if you do that. [14:53] Kopfgeldjaeger: hm... this looks like you're trying to debdiff too different upstream versions (at least the dirs indicate that) [14:54] or otherwise the patch paths are borked [14:54] Yes. So I guess I shouldn't do that? [14:54] Kopfgeldjaeger: You can't debdiff that. Just attach the diff.gz, and the sponsor will unroll it (make sure you have a working get-orig-source rule) [14:54] persia: why can't you? i've done so before, iirc [14:54] OK. thanks. [14:55] Hobbsee: Well, it works in some rare cases, but it's not guaranteed. Essentially, debdiff can't handle the sort of changes that are permitted in orig.tar.gz, so it's not recommended to use it. [14:56] I'm not sure how debdiff will handle the new packaging formats, or if we will have to define a special procedure to handle processing patches for each one. [14:56] hm, right [14:57] persia: Just one question left. Can you give me a link about this get-orig-surce rule? [14:59] Kopfgeldjaeger: I believe https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball is the best in Ubuntu, but the Debian wiki likely has more [14:59] thanks [15:01] I need some help.... i found a bug #221973, which is now in hardy-proposed but now i found another bug that just shows when upgrading... should this be addressed to in the SRU? [15:01] CrippledCanary: Error: Could not parse data returned by Launchpad: The read operation timed out [15:01] bug #221973 [15:01] Launchpad bug 221973 in smstools "smstools folder under /var/run isn't recreated after reboot" [Undecided,Confirmed] https://launchpad.net/bugs/221973 [15:02] CrippledCanary: Is it another bug or does your fix cause a regression? [15:03] it's another bug... but it stops the smsd daemon from working when doing an upgrade [15:03] a line in the config that before upgrade is ...... # eventhandler = @EVENTHANDLER@ [15:03] but after upgrade it gets uncommented [15:04] doing a clean install of the new version works and the line is commented out [15:04] prolly something in postinst [15:04] Dear Compiz: [15:04] The bullet point toolbar is *NOT* the main Openoffice Writer window. [15:04] CrippledCanary: I guess that should be fixed as well [15:04] The one you're looking for is the one that occupies 230MB RAM currently. [15:05] PLEASE don't think I closed openoffice every time the freaking toolbar disapears! [15:05] Love, John [15:05] heh [15:05] P.S. Do it one more time and I'll go back to LaTeX [15:06] sistpoty|work: then someone will need to help me sort it out [15:06] jdong :) [15:06] CrippledCanary: I'd finish your current SRU (as it affects all users and not just upgrades) and then evaluate if another SRU is warranted. [15:06] But that's just me. [15:07] mok0: sistpoty|work: heya. You may also want to add a testimonial. https://wiki.ubuntu.com/StefanEbner ^^ [15:07] ScottK: sounds as a reasonable solution to me to but I wanted to check here first... [15:08] sebner: sure, I will write something [15:08] sebner: lol at the current testimonials [15:08] hrhr ^^^ [15:08] mok0: thx :) [15:09] sebner: must add s.th. from home, I have no clue how to log in to the wiki from work *g* [15:09] sebner: ah, you're hellboy95? Hehe [15:09] sistpoty|work: np np np [15:09] mok0: yeah ^^ [15:09] CrippledCanary: if it's urgent enough, you can push ubuntu0.2 and go to verification phase with two different test cases [15:10] DktrKranz2: ah, I was looking for you. please write a testimonial :P [15:10] sebner: sure. 150 euros [15:10] * mok0 will abstain from making nasty comments about Austria and pedophiles [15:11] Ooops [15:11] rofl [15:11] DktrKranz2: hrhr. free mind and not free beer. how true this is :P [15:12] sebner: I don't like beer :D [15:12] even free one [15:12] dito :) [15:12] <\sh> DktrKranz2, free wine -> apt-get install wine ,-> [15:13] \sh, wine is good, italian one, of course :) [15:13] apt-get install gerstensaft :P [15:13] DktrKranz2: haven't heard good things about italian wine ;) [15:13] *recently* [15:14] <\sh> sistpoty|work, ah the very well known gerstensaft...I remember having gestersaft on every invoice of our drink delivery company during redhat times in stuttgart :) [15:14] <\sh> gerstensaft even ;) [15:14] heh [15:14] sebner: a silly try from french producers [15:14] (strange enough /me prefers wheat beer though, but that's not in the archives) [15:14] DktrKranz2: hm? [15:15] only french producers dare say something negative about our wines :P [15:15] lol [15:15] DktrKranz2: what about the scandal with chemicals in you wine? [15:15] *your [15:16] DktrKranz2: You mean the cheap stuff being sold as expensive wines? [15:16] <\sh> guys, I switched from french/italian wine to good red wines from stellenbosch, cape area, ZA :) [15:17] mok0: these are french ones, our "brunello" is expensive sold as cheap :P [15:17] <\sh> ok...end of business [15:17] <\sh> cu later5 [15:17] sebner: I'm still alive, so... I'm immune to chemical stuffs or no chemical in our wines :) [15:18] cya \sh [15:18] cu \sh [15:18] woo-hooo... 3 RC closed in Debian today \o/ [15:18] DktrKranz2: lol. If it doesn't kill you it doesn't mean that that it isn't dangerous ;) [15:20] DktrKranz2: It's quite easy to work around so i'll just file another bug and wait. [15:21] the old working config gets backed up so the only thing to do is to restore that one [15:23] CrippledCanary: ok, then. Subscribe motu-sru when ready. Thanks ;) [15:28] what sould i do with the previous SRU bug... just make a comment that I verify the fix (and perhaps give a pointer to the new one)? [15:28] oh bloody hell wine in backports FTBFSed on all arches [15:29] * jdong looks to see what embarrassing thing he did wrong [15:29] let's get someone check it, two or more people are ok, sru-verification is better [15:29] BFD: /build/buildd/wine-0.9.59/debian/wine-dbgsym/usr/lib/debug/./usr/bin/wine-kthread: section `.note.ABI-tag' can't be allocated in segment 2 [15:29] urr.... [15:29] I swear that didn't happen in my pbuilder [15:34] I commented the old bug as fixed verified and the new one is bug #224241 [15:34] Launchpad bug 224241 in smstools "smstools stop working after upgrade" [Undecided,New] https://launchpad.net/bugs/224241 [15:38] Is 224241 SRU worthy at all...? should I subscribe motu-sru? [15:38] CrippledCanary: I'd ask a motu-sru member (like DktrKranz2) here what they think. [15:39] on the face of it, I think any bugfix that would be worth an upload to Intrepid is also worthy of a SRU [15:39] CrippledCanary: definitely. [15:39] CrippledCanary: but pertaining yoru bug specifically, can you please describe exactly how this bug happens? [15:40] CrippledCanary: how does the .bak file get created? does the upgrade overwrite a config file? try to "upgrade" the existing config file? [15:40] postinst creates the .bak file from the original and then creates a new "default" /etc/smsd.conf [15:40] Heya gang [15:41] CrippledCanary: err... postinst unconditionally overwrites the config file and just saves a backup? [15:41] CrippledCanary: well at any rate, we can "discuss" that "feature" another time, but please do prepare a SRU to fix the default config file :) [15:42] jdong: I'll try to... not that good at postinst I'm afraid [15:43] CrippledCanary: well in this case it looks like the "default" config file is simply malformed [15:44] jdong: but it works from a clean install with the same postinst script... strange [15:44] CrippledCanary: it doesn't feel correct to me that postinst places a dummy config file that's not working by default, regardless of if the user had a previous config file [15:44] jdong: Can't agree more but that's how the debian folks have packed it [15:45] CrippledCanary: agreed, it's not appropriate at a SRU stage to fix that, but if installing the SRU causes configs to break, that's an issue [15:45] CrippledCanary: see if you can (1) reproduce the bug (2) more concisely state with reference to lines in the postinst script what's going on [15:46] jdong: I can reproduce the bug... described how to in the bug report [15:46] CrippledCanary: ah, ok, you reproduced it. [15:47] CrippledCanary: well in that case I think this should be combined with the other SRU [15:47] CrippledCanary: as without it, the other SRU would be a regression. [15:47] i.e. installing it causes the config file to bork [15:47] CrippledCanary: I think you should modify postinst so that if it detects an existing smsd.conf, it doesn't try to replace it. [15:48] probably get DktrKranz2's opinion on the combining of the SRUs too [15:48] jdong: should a new SRU be ubuntu0.2 then or just keep adding on to the 0.1 one? [15:50] and should I assign it to me while trying to sort it out? [15:50] CrippledCanary: should be 0.2, since 0.1 is a faulty update [15:50] CrippledCanary: and yes, you can claim ownership via assignment if you plan on doing it [15:51] jdong: I'd guess the best way to learn postinst is to start fixing bugs :) [15:51] CrippledCanary: That's the right idea. Keep at it. [15:51] :) [15:52] I think we got ourselves a future MOTU in the making :) [15:52] * jdong whispers to ScottK to lock the doors [15:52] shoud I subscribe motu-sru to the new bug as well? [15:52] CrippledCanary: yeah, once the combined debdiff is available [15:52] * jdong wonders if we should just merge the two bug reports together [15:53] jdong: First SRU is already in proposed, so shouldn't he just diff against that? [15:54] ScottK: same result. Ultimately I want 0.2 to contain both fixes [15:54] whether he wants to base off 0.1 or start over from -1 I'm fine [15:54] probably your proposal makes more sense :) [15:54] It doesn't matter to me... I just want to use the correct procedures [15:56] And perhaps keeping them as separate bugs is more useful if someone from upstream have a look as the first affects only ubuntu and the second prolly both ubuntu and debian [15:56] jdong: I think uploading a second SRU against ubuntu0.1 is enough, given that we preserve first fix. [15:57] so, once ubuntu0.2 will be copied in -updates, we will ship both SRU fix [15:57] DktrKranz2: Ok... new patch against 0.1 and fix both in 0.2 [15:58] (I'm not an archive-admin, this is just my opinion) [15:59] CrippledCanary: both should be relevant to Debian, but what's clear to me is 0.1 should NOT go in without 0.2's fixes [15:59] as currently 0.1 alone would break upgrades [15:59] jdong: just doing a version bump to -1 would actually trigger the bug... the 0.1 fix isn't the source [16:00] jdong: but agree... both should be fixed [16:02] CrippledCanary: it isn't the source but it does show up at that point [16:03] jdong: yes and prolly upgrade from 7.10 to 8.04 to [16:03] indeed === x-spec-t is now known as Spec [16:06] what does "db_get" do in a postinst? [16:06] CrippledCanary: it gets a value from debconf [16:07] CrippledCanary: man debconf or man debconf-devel [16:07] for the latter, you probably also need the debconf-docs package [16:07] laga: shit, then I have to learn that to :) [16:07] debconf-doc* [16:07] CrippledCanary: debconf is great :) [16:14] laga: the debian/config is the file that controls debconf, right? === x-spec-t is now known as Spec [16:40] * ScottK encourages the hamsters for the PPA buildd to peddle faster. [16:41] lol [16:43] http://xkcd.com/413/ [16:43] yay, hamsters! === x-spec-t is now known as Spec [17:15] If a stable release update only affects a specific arch, will a later package version only be released for that arch? [17:16] I'm thinking of https://bugs.edge.launchpad.net/ubuntu/+source/wine/+bug/224042 -- the 32 bit package should be identical to how it was before [17:16] Launchpad bug 224042 in wine "Wine 64 bit does not depend on lib32nss-mdns package; dns lookups broken" [Medium,Confirmed] === x-spec-t is now known as SPec === SPec is now known as Spec [17:16] YokoZar: it will always get rebuilt for all arches, so it may not be bit-identical [17:17] sistpoty|work: That's what I figured, I'm just sort of wondering if that needs to be the case [17:17] YokoZar: for ubuntu it needs to be like that, as there's no way to say you want only one arch rebuilt [17:18] (and if there are source changes, you'd always need to rebuild all arches, otherwise source wouldn't match the binary) [17:21] Can't one give-back a specific arch manually? [17:21] Or does that only work when it previously FTBFS? [17:22] YokoZar: ping [17:23] LaserJock: pong [17:23] YokoZar: did you get MOTU SRU approval for bug #224042? [17:23] Launchpad bug 224042 in wine "Wine 64 bit does not depend on lib32nss-mdns package; dns lookups broken" [Medium,Confirmed] https://launchpad.net/bugs/224042 [17:23] LaserJock: still waiting on it [17:24] YokoZar: but it's already been uploaded to proposed? [17:25] LaserJock: have I done something really wrong? I just followed the instructions on the wiki page: https://wiki.ubuntu.com/StableReleaseUpdates [17:25] YokoZar: you aren't supposed to upload it until it's been approved [17:25] so it's already going through without any MOTU SRU member looking at it [17:27] YokoZar: so please do wait until MOTU SRU has ack'd it before uploading :-) [17:27] persia: once it's published, you cannot give-back s.th. (otherwise we wouldn't need to upload packages for rebuilds) [17:28] LaserJock: :( I thought uploading to -proposed was how the SRU team looked at the new version of the package. There's nothing between step 3 and 4 that says to wait for approval, so I naturally thought that came in the -proposed to -updates transition [17:30] YokoZar: yeah, we should probably make that clearer :-) [17:30] gotta run, bbl maybe [17:30] sistpoty|work: Ah. It's the publish run. Thanks for the clarification. [17:30] persia: I'm not too sure, if it's the publisher run actually (as I don't know lp internals that much) [17:31] maybe wgrant would know the details though? [17:31] sistpoty|work: Well, right. In simple terms, the issue is likely that one can't update a binary package to the same version number. [17:32] YokoZar: SRU page is not clear that way, it doesn'tsay developers needs to wait for an ACK before uploading to proposed [17:32] persia: yes (which does make some sense... otherwise apt wouldn't draw in the "new" packages... and it sounds awful to me to change s.th. which is already released at a version) [17:37] sistpoty|work: Oh, I agree it'd be ugly. Be nice if Soyuz grew a function to do binNMU's at the click of a button (for appropriately authorised people: e.g. those who can upload there) [17:38] persia: hm, yes, that'd be nice indeed :) [17:38] persia: you still think new contributors group is open tomorrow? ^^ [17:39] sebner: I've had no information on the matter since it was last discussed. [17:39] grml [17:39] kk. thx anyway [17:40] * sistpoty|work heads home now... cya [17:40] sistpoty|work: hf === x-spec-t is now known as Spec [17:53] Any doubts I had about not jumping straight to clamav 0.93 before we released are resolved. [17:53] Every single package that build-dep's on libclamav-dev FTBFS against 0.93. [18:00] nxvl: ready for your session in ~1 hour? === slangase` is now known as slangasek [18:13] jcastro: always ready [18:13] :D [18:15] jcastro: i'm just working on the last details [18:46] I'd love it if someone would look at the serpentine crashes that are coming in and come up with an SRU to make the bugmail stop. [19:02] TheMuso: Dunno if it's something you're interested in or not, but I see some kind of accessibility issue in the last comment for Bug 220475 [19:02] Launchpad bug 220475 in virtkey "Onboard segfaults on Ubuntu Hardy" [High,New] https://launchpad.net/bugs/220475 === fta_ is now known as fta [19:46] Do you agree with this guy that this is not a bug? https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/221995 [19:46] Launchpad bug 221995 in rhythmbox "Last.fm plug-in fails to communicate current song to lyrics plug-in and cover art plug-in" [Wishlist,New] [19:54] i dont want to ask this in -devel because its not really related to devel, though theyre probably the ones that could answer best... if im writing a script to download the current source package for the kernel and make a modification that fixes a bug and recompile it, do i need to include for it to compile l-r-m? The bugfix isn't in a spot related to any restricted modules, but will the fact that its even slightly different have an effect? [20:04] does anyone here know where debconf information is stored? i want to make sure they are gone for a package i'm debugging [20:09] CrippledCanary: /var/cache/debconf/*.dat [20:09] crimsun: thanks [20:12] crimsun: is there any tools for cleaning that up [20:19] CrippledCanary: I need more info to answer your question adequately. [20:20] CrippledCanary: e.g., are you attempting to edit /var/cache/debconf/config.dat by hand, or are you attempting to clean it programatically using a package's postrm? [20:21] crimsun: by hand... === santiago-php is now known as santiago-ve [20:22] cleaning up [20:22] i'm working on a SRU here... don't want to change more then necessary so changing postrm is not on the schedule :) [20:23] CrippledCanary: ok, I'm lacking context for the SRU. Which is it? [20:27] maco: to address your question from 2:54, please see the ABI checking portion of debian/rules [20:30] its bug #224241 which should be combined with bug #224241 to make it through -proposed [20:30] Launchpad bug 224241 in smstools "smstools stop working after upgrade" [Undecided,New] https://launchpad.net/bugs/224241 [20:30] err [20:31] sorry bug 221973 [20:31] CrippledCanary: Error: Could not parse data returned by Launchpad: The read operation timed out [20:31] the bug #221973 made a upgrade bug visible that is addressed in 224241 [20:31] Launchpad bug 221973 in smstools "smstools folder under /var/run isn't recreated after reboot" [Undecided,Confirmed] https://launchpad.net/bugs/221973 [20:33] i just attached a debdiff to 224241 and subscribed it to motu-sru [20:34] crimsun: in l-r-m or the kernel one? [20:36] maco: linux. [20:37] crimsun: actually, how do i change the abi number? i do want to change it because if i leave it the same, update manager tries to "upgrade" from the new, edited one to the old one [20:38] maco: no, you don't want to bump the ABI unnecessarily. You want to adjust the version number in debian/changelog. [20:38] crimsun: oh. ok... [20:39] crimsun: since it's 16.30, should i make it 16.30.1? im afraid putting .31 would mean that when the next kernel update comes out itll be .31 and i dont know how it would react to that [20:41] maco: I would use 2.6.24-16.30+foo [20:42] ok [20:42] that sorts before the unextremely unlikely 2.6.24-16.30.1 and thus trivially before 2.6.24-16.31, which is far more likely [20:42] ugh [20:42] extremely^ [20:42] ok [20:43] but it comes after jut plain 16.30? [20:43] yes [20:43] ok [20:43] is there a list of what +, -, and ~ (anything else?) do in sorting? [20:43] yeah, in Debian Policy [20:43] ok [20:44] (http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version) [20:45] you can check these by dpkg --compare-versions and checking the exit value [20:45] or use &&, etc., etc. [20:45] ok [20:47] CrippledCanary: ok, a few comments on the 0.2 debdiff [20:48] CrippledCanary: first, the distro should be hardy-proposed. Second, do you really want to include the commented-out debugging echo? [20:49] crimsun: will fix both those things... in a few min [20:58] crimsun: a new debdiff is attached [20:58] crimsun: ok so if i just change the version number and i leave the ABI number alone, l-r-m doesn't need to be recompiled, right? [20:59] maco: if the ABI in fact does not change, correct. [20:59] CrippledCanary: ok, ~motu-sru will process it. [20:59] crimsun: it's this: http://tinyurl.com/5vm3ul i dont think that changes the ABI [21:00] i could be totally wrong, of course [21:00] crimsun: great, thanks for your attention [21:01] maco: you're correct; it does not. Have you filed a bug against linux? [21:01] that's a trivial fix. [21:01] crimsun: there's a bug filed, targetted at 8.04.1 [21:01] good. [21:01] i just figure someone might want 3D in the meantime === cprov is now known as cprov-afk [21:09] Hi, I'm using a combination of distutils, pycentral and cdbs to create a package from my Python program. Now, how do I split it up in multiple binary packages? Is there any documentation available in this regard? [21:12] someone knows a tool to se what parts of an application uses most of the memory? [21:16] rulus: dh_install(1) [21:19] crimsun: thanks :) [21:19] rulus: for an example, see quodlibet source. [21:21] will do, thanks again === never|mobi is now known as neversfelde|mobi === ubot5 is now known as ubottu [22:39] can i convert a dpatch to a normal patch? [22:39] it's a normal patch. patch should strip the leading "garbage" [22:40] ok, thanks === wolfger_ is now known as wolfger [22:50] 16 hunks FAILED. super, that means i may go through a 500 lines patch by hand [22:52] ouch [23:34] ScottK: I am aware of that issue, and will be preparing an SRU for that today. [23:34] I filed that bug FWIW. === ember_ is now known as ember [23:53] TheMuso: OK. I just saw it in bugmail and it seemed up your alley. I guess so. [23:57] ScottK: Are there DVDs built? [23:57] I'm at Interop this week and I'm seeding all the CD torrents ... [23:58] Yes. [23:58] They were built before release.