[01:12] <LaserJock> is a 2GB file size limit a property of the kernel or filesystem?
[01:13] <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:14]  * RAOF looks at his various >4GB files sitting on ext3
[01:14] <RAOF> And is surprised.
[01:15] <LaserJock> then maybe it is the kernel?
[01:15] <LaserJock> or maybe an old version of ext3
[01:16] <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:17] <jdong> LaserJock: you didn't hit that news server button thing for fun did you? :)
[01:18] <LaserJock> no
[01:18] <LaserJock> I just have an old Debian version
[01:18] <LaserJock> it's a 120GB hard drive
[01:19] <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:20] <jdong> LaserJock: dumpe2fs dev_node
[01:20] <jdong> LaserJock: I think that's Block size:               1024 you should be lookin for
[01:26] <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:27] <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:28] <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:29] <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:30] <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:31] <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:32] <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:33] <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:34] <RAOF> jdong: Yeah.  It makes a lot of sense for some fraction of the userbase.
[01:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <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:50] <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:51] <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:52] <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:53] <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:54] <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:55] <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:56] <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:57] <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:58] <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:59] <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
[02:00] <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:01] <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:02] <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:03] <LaserJock> hmm
[02:03] <LaserJock> it just seems to me that we should be able to create common testing grounds/tools/strategies
[02:04] <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:05] <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:06] <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:08] <ScottK> jdong and LaserJock: My clamav updates to Dapper are perhaps an interesting hybrid.  That went PPA (test) -> dapper-backports (test) -> dapper-updates
[02:09] <ScottK> clamav and a all the needed rdepends
[02:12] <LaserJock> in reality, I think -proposed is almost useless
[02:13] <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:14] <LaserJock> you're pretty much just as well to attach a .deb or link to a PPA
[02:15] <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:16] <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:17] <ScottK> Good question.
[02:17]  * wgrant hasn't read the whole conversation, as he's at work.
[02:18] <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:19] <wgrant> Have people subscribe to a mythical testing ML, to which emails soliciting SRU testing are sent.
[02:20] <LaserJock> that's a good idea
[02:21] <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:23] <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:25] <bddebian> Heya gang
[02:26]  * 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:27] <ScottK> Gotta hit tab for the tab completion to work.
[02:27] <bddebian> Heya ScottK
[03:21] <ScottK> leonel: Debian package of clamav 0.93 is up in the clamav PPA.
[03:42] <ScottK> soyuz eating ppa uploads for anyone else?
[03:50] <ScottK> Nevermind.  Finally showed up.
[04:11] <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:22] <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:23] <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:24] <Zelut> http://pastebin.ca/1001327 - this is the output of my attempt.
[04:25] <Zelut> the application does not need to be compiled. the rules file just needs to install them to a few locations.
[04:26] <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:29] <persia> Line 27.  It calls make.  This implicitly looks for a Makefile.
[04:30] <Zelut> 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] <Zelut> http://pastebin.ca/1001333
[04:31] <persia> OK.  Quick look: firstly, do you have a ./configure in the source?
[04:32] <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:33] <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:37] <persia> Zelut: OK.  Rules file is two lines.
[04:37] <persia> #!/usr/bin/make -f
[04:38] <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:39] <Zelut> done
[04:40] <Zelut> do I need to add the docs I want in /usr/share/doc/origami into the origami.install file?
[04:41] <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:42] <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:43] <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:44] <TheMuso> haha
[04:44] <Zelut> persia: wow.. so it built.  cdbs is magical voodoo isn't it :)
[04:45] <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:46] <Zelut> now, lets say I wanted this package to run three basic commands to clean something up.  How would I do that?
[04:47] <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:48] <Zelut> ok.
[04:52] <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!
[05:08] <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:13] <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:14] <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:17] <a7x> i'm new:  what's debdiff?
[05:18] <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:19] <a7x> jdong and persia:  thanks
[05:19] <coppro> how do I get rid of doc-base-unknown-section
[05:20] <bimberi> br1|: /win 11
[05:23] <bimberi> well that was deft
[06:13] <warp10> Good morning
[06:18]  * persia is amused by intrepid FTBFS reports, and wonders if the FTBFS tracker is watching intrepid yet
[06:20] <StevenK> Hah
[06:22] <wgrant> persia: It is now.
[06:22] <wgrant> It's not right, but...
[06:24] <wgrant> I can't see why.
[06:26] <YokoZar> Hey, what exactly do I put into dput to upload to hardy-proposed for an SRU?
[06:27] <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:28] <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:29] <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:30] <wgrant> Hmm, I think intrepid is borked.
[06:30] <wgrant> It has no packages.
[06:31] <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:32] <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:34] <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:35] <wgrant> I see LP even says it has packages.
[06:36] <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:37] <wgrant> StevenK: What, then?
[06:37] <StevenK> wgrant: It runs madison-lite
[06:37] <wgrant> Aha.
[06:43] <wgrant> StevenK: Should I poke some archive person about it when they appear?
[06:44] <StevenK> I don't see the point bugging them until the toolchain is uploaded.
[06:51] <persia> Is it not yet?  Why am I getting build failure messages then?
[06:52] <persia> Is it just trying to rebuild packages with the old toolchain when the binary version doesn't match the source version?
[06:53] <wgrant> persia: That's right.
[06:54] <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:56] <wgrant> Yay, we have a bot.
[07:35] <StevenK> wgrant: rmadison should be sorted.
[07:38] <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 <IP_ADDRESS>-1ubuntu3?
[07:52] <Taylor> hey kahrytan can't you get to terminal? ctrl+alt+f1?
[07:52] <kahrytan> Taylor,  What?
[07:53] <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:54] <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:55] <siretart> janimo: yes, at least they should be. why?
[07:55] <janimo> siretart: thanks
[07:56] <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:57] <Taylor> kahrytan: because you left ##club-ubuntu
[07:58] <kahrytan> No one talked.
[07:58] <Taylor> kahrytan: that's true
[07:59] <Taylor> kahrytan: did you try editing the xorg config?
[07:59] <Taylor> pm
[07:59] <kahrytan> yeah
[08:00] <kahrytan> !pastebin > kahrytan
[08:37] <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:39] <persia> kahrytan: That's really an #ubuntu-bugs question: looking anyway
[08:39] <kahrytan> aww. ill redirect in the future
[08:41]  * persia waits for a join for feedback...
[08:43] <emgent> morning
[08:43] <kahrytan> What is motu?
[08:44] <highvoltage> motu is an acronym for 'masters of the universe'
[08:45] <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:46] <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:47] <kahrytan> 2008 version works from google search.
[09:53] <norsetto> happy SRU'ing everybody
[10:40] <YokoZar> norsetto: Indeed...already got one for Wine...
[10:54] <iulian> G'morning
[10:55] <jpatrick> morning iulian
[10:56] <iulian> Hey jpatrick
[11:03] <norsetto> way to go yokozar
[11:33] <proppy> oy
[11:51] <norsetto> super proppy is in, all bow
[11:54]  * proppy hail to norsetto
[11:54] <wgrant> \o/ .*
[11:54] <proppy> .* = fireworks ?
[11:54] <wgrant> .* == regexp
[11:55] <proppy> aah ^.*$
[11:55] <wgrant> No point doing that.
[11:56] <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:57] <proppy> wgrant: FSVO ?
[11:57] <wgrant> For some values of.
[12:09] <sistpoty|work> hi folks
[12:17] <emgent> heya
[12:17] <sistpoty|work> hi emgent
[12:52] <Myrtti> !bot
[12:53] <Hobbsee> ah, there we are
[12:59] <zul> \sh: ping
[13:01] <\sh> zul, pong
[13:01] <zul> \sh: do you do the php-xdebug stuff for universe?
[13:02] <\sh> zul, I uploaded and bugfixed the packages, yes
[13:02] <zul> \sh: : have you seen #217980
[13:02] <\sh> bug #217980
[13:03] <sistpoty|work> ubotu must be on holidays :)
[13:03] <\sh> zul, hmm?? no open bugs?
[13:04] <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:05] <Kopfgeldjaeger> hoi
[13:07] <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: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] <azeem> btw, is the UTF8 character at the beginning of the /topic intentional?
[13:08] <\sh> zul, btw..this applies on windows, too
[13:09] <zul> 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] <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:23] <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:24] <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:27] <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:28] <\sh> ScottK, you just need to extract a patch?
[13:28] <\sh> ScottK, apt-get install rpm ; mc ; choose the rpm <enter> voila
[13:31] <ScottK> 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] <zul> \sh: thanks
[13:33] <ScottK> Right.
[13:39] <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:43] <ScottK> Even better their patch removed the binary, but left the UI for the now missing function.
[13:44] <sistpoty|work> yay, I win with the first package in hardy-updates :)
[13:46] <laga> damn :)
[13:54] <ScottK> sistpoty|work: I'm not sure that's actually a 'win'.
[13:55] <Hobbsee> ScottK: depensd if it builds or not.
[13:55] <ScottK> Yeah.  Particularly in this case.
[13:58] <sistpoty|work> hm? it is already published actually, so it did build... :)
[13:59] <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
[14:00] <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:12] <Kopfgeldjaeger> can i already upload debdiffs to launchpad and subscribe u-u-s? or doesnt it make sense yet?
[14:14] <cody-somerville> Kopfgeldjaeger, For hardy?
[14:14] <Kopfgeldjaeger> for intrepid
[14:14] <cody-somerville> Sure, upload it.
[14:14] <Kopfgeldjaeger> ok
[14:15] <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:17] <Hobbsee> assuming the package doesn't need a merge, or further modifications to make it build.
[14:18] <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:19] <norsetto> sistpoty|work: can't help you there, I have spent days looking for something too without success
[14:20] <sistpoty|work> ah, k
[14:49] <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:50] <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:51] <persia> Kopfgeldjaeger: Generally, install patch-utils.  If that's not enough, you're working on a native package.
[14:52] <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:53] <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:54] <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:55] <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:56] <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:57] <Kopfgeldjaeger> persia: Just one question left. Can you give me a link about this get-orig-surce rule?
[14:59] <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
[15:01] <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] <CrippledCanary> bug #221973
[15:02] <ScottK> CrippledCanary: Is it another bug or does your fix cause a regression?
[15:03] <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:04] <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:05] <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:06] <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:07] <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:08] <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:09] <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:10] <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:11] <mok0> Ooops
[15:11] <sebner> rofl
[15:11] <sebner> DktrKranz2: hrhr. free mind and not free beer. how true this is :P
[15:12] <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:13] <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: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] <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:15] <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:16] <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:17] <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:18] <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:20] <CrippledCanary> DktrKranz2: It's quite easy to work around so i'll just file another bug and wait.
[15:21] <CrippledCanary> the old working config gets backed up so the only thing to do is to restore that one
[15:23] <DktrKranz2> CrippledCanary: ok, then. Subscribe motu-sru when ready. Thanks ;)
[15:28] <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:29]  * 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:34] <CrippledCanary> I commented the old bug as fixed verified and the new one is bug  #224241
[15:38] <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:39] <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:40] <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:41] <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:42] <CrippledCanary> jdong: I'll try to... not that good at postinst I'm afraid
[15:43] <jdong> CrippledCanary: well in this case it looks like the "default" config file is simply malformed
[15:44] <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:45] <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:46] <CrippledCanary> jdong: I can reproduce the bug... described how to in the bug report
[15:46] <jdong> CrippledCanary: ah, ok, you reproduced it.
[15:47] <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:48] <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:50] <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:51] <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:52] <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:53] <ScottK> jdong: First SRU is already in proposed, so shouldn't he just diff against that?
[15:54] <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:56] <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:57] <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:58] <DktrKranz2> (I'm not an archive-admin, this is just my opinion)
[15:59] <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
[16:00] <CrippledCanary> jdong: but agree... both should be fixed
[16:02] <jdong> CrippledCanary: it isn't the source but it does show up at that point
[16:03] <CrippledCanary> jdong: yes and prolly upgrade from 7.10 to 8.04 to
[16:03] <jdong> indeed
[16:06] <CrippledCanary> what does "db_get" do in a postinst?
[16:06] <laga> CrippledCanary: it gets a value from debconf
[16:07] <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:14] <CrippledCanary> laga: the debian/config is the file that controls debconf, right?
[16:40]  * ScottK encourages the hamsters for the PPA buildd to peddle faster.
[16:41] <cprov> lol
[16:43] <persia> http://xkcd.com/413/
[16:43] <Hobbsee> yay, hamsters!
[17:15] <YokoZar> If a stable release update only affects a specific arch, will a later package version only be released for that arch?
[17:16] <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] <sistpoty|work> YokoZar: it will always get rebuilt for all arches, so it may not be bit-identical
[17:17] <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:18] <sistpoty|work> (and if there are source changes, you'd always need to rebuild all arches, otherwise source wouldn't match the binary)
[17:21] <persia> Can't one give-back a specific arch manually?
[17:21] <persia> Or does that only work when it previously FTBFS?
[17:22] <LaserJock> YokoZar: ping
[17:23] <YokoZar> LaserJock: pong
[17:23] <LaserJock> YokoZar: did you get MOTU SRU approval for bug #224042?
[17:23] <YokoZar> LaserJock: still waiting on it
[17:24] <LaserJock> YokoZar: but it's already been uploaded to proposed?
[17:25] <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:27] <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:28] <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:30] <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:31] <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:32] <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:37] <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:38] <sistpoty|work> persia: hm, yes, that'd be nice indeed :)
[17:38] <sebner> persia: you still think new contributors group is open tomorrow? ^^
[17:39] <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:40]  * sistpoty|work heads home now... cya
[17:40] <sebner> sistpoty|work: hf
[17:53] <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.
[18:00] <jcastro> nxvl: ready for your session in ~1 hour?
[18:13] <nxvl> jcastro: always ready
[18:13] <nxvl> :D
[18:15] <nxvl> jcastro: i'm just working on the last details
[18:46] <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.
[19:02] <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:46] <cyberix> Do you agree with this guy that this is not a bug? https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/221995
[19:54] <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?
[20:04] <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:09] <crimsun> CrippledCanary: /var/cache/debconf/*.dat
[20:09] <CrippledCanary> crimsun: thanks
[20:12] <CrippledCanary> crimsun: is there any tools for cleaning that up
[20:19] <crimsun> CrippledCanary: I need more info to answer your question adequately.
[20:20] <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:21] <CrippledCanary> crimsun: by hand...
[20:22] <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:23] <crimsun> CrippledCanary: ok, I'm lacking context for the SRU.  Which is it?
[20:27] <crimsun> maco: to address your question from 2:54, please see the ABI checking portion of debian/rules
[20:30] <CrippledCanary> its bug #224241 which should be combined with bug #224241 to make it through -proposed
[20:30] <crimsun> err
[20:31] <CrippledCanary> sorry bug 221973
[20:31] <CrippledCanary> the bug #221973 made a upgrade bug visible that is addressed in 224241
[20:33] <CrippledCanary> i just attached a debdiff to 224241 and subscribed it to motu-sru
[20:34] <maco> crimsun: in l-r-m or the kernel one?
[20:36] <crimsun> maco: linux.
[20:37] <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:38] <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:39] <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:41] <crimsun> maco: I would use 2.6.24-16.30+foo
[20:42] <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:43] <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:44] <crimsun> (http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version)
[20:45] <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:47] <crimsun> CrippledCanary: ok, a few comments on the 0.2 debdiff
[20:48] <crimsun> CrippledCanary: first, the distro should be hardy-proposed.  Second, do you really want to include the commented-out debugging echo?
[20:49] <CrippledCanary> crimsun: will fix both those things... in a few min
[20:58] <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:59] <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
[21:00] <maco> i could be totally wrong, of course
[21:00] <CrippledCanary> crimsun: great, thanks for your attention
[21:01] <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:09] <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:12] <elmargol> someone knows a tool to se what parts of an application uses most of the memory?
[21:16] <crimsun> rulus: dh_install(1)
[21:19] <rulus> crimsun: thanks :)
[21:19] <crimsun> rulus: for an example, see quodlibet source.
[21:21] <rulus> will do, thanks again
[22:39] <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:40] <Kopfgeldjaeger> ok, thanks
[22:50] <Kopfgeldjaeger> 16 hunks FAILED. super, that means i may go through a 500 lines patch by hand
[22:52] <Flare183> ouch
[23:34] <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:53] <ScottK> TheMuso: OK.  I just saw it in bugmail and it seemed up your alley.  I guess so.
[23:57] <milli> ScottK: Are there DVDs built?
[23:57] <milli> I'm at Interop this week and I'm seeding all the CD torrents ...
[23:58] <ScottK> Yes.
[23:58] <ScottK> They were built before release.


[18:23] <UBUxUBU>  iwould like to propose a change to the way the minimal install occurs, i don't think it should be part of the full installer at all, but its own installer. i dont think it is a good idea to to have an OS installer, install the full system, ans then remove all the extra apps after the fact and then call it a minimal install. i think a minimal install should be a separate installer all by itself. i think it will result in a cleaner system.
[18:45] <TJ-> UBuxuBU: are you volunteering to do that work? The reason the desktop installer does it the way it does is it avoids duplication of resources; we don't want an additional installer ISO to maintain
[18:46] <tsimonq2> UBuxuBU: We're also moving towards stacking squashfses.
[18:46] <tsimonq2> So instead of installing all of it and then removing the unneeded bits, it'll only copy the core squashfs.
[18:46] <UBuxuBU> well then u could it for LTS releases only
[18:46] <tsimonq2> That's coming, probably, before the next LTS.
[18:47] <tsimonq2> I respectfully disagree that your idea is practical.
[18:48] <UBuxuBU> if ic ould lean how to do it i would do that for u
[18:48] <UBuxuBU> now that i see it infornt if me installed i beleive it is the best option
[18:49] <UBuxuBU> it is very quiet
[18:56] <UBuxuBU> wow my disk in only 28C temp
[19:51] <hwpplayer1> hi people
[19:51] <UBuxuBU> whats does it mean: stacking squashfses?


[06:56] <flocculant> bluesabre: I git pulled and rebuilt - forwards and backwards it goes
[07:15] <flocculant> I can almost ditch the mpd plugin as I don't much use any of the 'extra' options there
[07:15] <flocculant> so \o/ for one less thing on panel
[12:19] <bluesabre> flocculant: awesome :)
[12:20] <flocculant> bluesabre: indeed it is
[12:20] <bluesabre> Pushed a fix for Parole missing... assuming I did Parole's reverse domain name launcher correctly, the pa plugin should show some players that indicator-sound misses
[12:23] <flocculant> oh rightio - I'll check that out then :)
[12:23] <flocculant> bluesabre: I'm kind of assuming we'll be liking this for 18.04?
[12:24] <flocculant> if app indicators are 'going' that means we have indicator for messaging and sound only ? If I read things right
[12:28] <flocculant> can confirm that works too
[12:28] <bluesabre> flocculant: yeah, I think if we can stabilize this, we'll prefer it to indicator-sound
[12:29] <flocculant> mmm
[12:29] <flocculant> didn't like parole being quit then :p
[12:30] <bluesabre> I think we're considering the statusnotifier plugin for app indicators, not sure what plans we have for messaging
[12:30] <bluesabre> flocculant: yeah, it's a bit crashy at times :D
[12:30] <bluesabre> really hard to debug a panel plugin
[12:30] <flocculant> yea
[12:30] <flocculant> ok - as long as you're aware of that :p
[12:31] <bluesabre> I've had it kill other panel applets a few times
[12:31] <bluesabre> For a while I ran with a single panel plugin, :D
[12:32] <flocculant> ha ha ha
[12:33] <flocculant> well I've got the crash report if it helps at all
[12:43] <bluesabre> I think I've tracked it down
[12:43] <bluesabre> But folks are waking up around here now, so fixes later :D
[12:43] <flocculant> bluesabre: ok - and did you know it remembers now?
[12:43] <bluesabre> flocculant: indeed! :)
[12:44] <flocculant> cool - so do I now lol
[12:44] <flocculant> anyway have a good weekend
[12:44] <bluesabre> you too flocculant
[12:44] <flocculant> away tomorrow till Monday evening
[15:35] <bluesabre> flocculant: crash on player exit should be fixed now
[15:42] <flocculant> bluesabre: ack - I'll grab latest now - check it out etc etc
[15:43] <flocculant> then come back with some issue the other  7,523,292,963 of us never find :D
[17:23] <bluesabre> :)
[17:23] <bluesabre> latest commit adds showing the player window if hidden and launching if its not running
[17:23] <bluesabre> though, launching crashes the plugin :\
[17:27] <knome> heh
[17:28] <knome> almost there then, eh? ;)
[17:35] <bluesabre> yup
[17:35] <bluesabre> just bug fixing and code cleanup now
[20:06] <flocculant> not crashing here :)
[20:07] <flocculant> and nice :D
[20:46] <Unit193> bluesabre: If we're going with statusnotifier, we need to get it in ASAP.