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