| persia | Testing with amd64 vs. powerpc would probably be best (does 64/32 and BE/LE). | 00:00 |
|---|---|---|
| persia | Or check other packages, to see if .mo files are being produced by arch:all packages. | 00:00 |
| ripps | persia: some bug-reports online say that .mo might be arch-specific, I'll move them into the base package just to be safe. | 00:02 |
| ripps | It implies that .mo, arent' inherently arch-specific, but they rely on some tables and alignment and stuff that might be different between arches. | 00:03 |
| persia | ripps: If they really are arch-specific, they don't really belong in /usr/share, but that might be a complicated discussion :) | 00:31 |
| ripps | persia: well, from what I read, .mo specification is suppose to be arch-independent, but for some reason or another, a few programs don't have the exact same layout parameters between the arches. gmpc might not have this problem, but I guess it's better to ere on the side of caution | 00:32 |
| persia | Well, no. | 00:33 |
| persia | Everything in /usr/share is required to be arch-independent. | 00:33 |
| persia | There's some issues that make it hard to have a shared /usr/share using Ubuntu, but that doesn't affect policy. | 00:33 |
| === patx2 is now known as patx | ||
| === funkyHat is now known as funkyTones | ||
| === funkyTones is now known as funkyHat | ||
| _Andrew | Hi guys, I have this debian folder I'm using the package up a library but I'm having problems with the .install file. Inside I have usr/include/LIB/* however it isn't getting the files that get installed when I run it through pbuilder | 02:44 |
| _Andrew | Some examples of files it installs are /usr/include/LIB/file.h and /usr/include/LIB/SUB/file.h | 02:45 |
| _Andrew | How to I make sure it globs everything recursively? | 02:46 |
| RAOF | You could just install usr/include/$LIB | 02:47 |
| RAOF | That'll install the full directory tree. | 02:48 |
| hyperair | hmm how do i get myself added to uus? | 02:52 |
| * hyperair tickles persia | 02:52 | |
| hyperair | thanks for adding me to ~motu already by the way =) | 02:52 |
| persia | Err, you ask one of the admins :) | 02:52 |
| hyperair | persia: and you are :) | 02:53 |
| persia | And you are | 02:53 |
| hyperair | eh? | 02:53 |
| hyperair | thanks =) | 02:53 |
| ajmitch | looks like my membership in that team lapses in a week | 02:54 |
| persia | hyperair: But there's not much to sponsor. If you feel like patch review *please* work with the Ubuntu Reviewers team, and help reduce the ~2000 patches we have outstanding that need integration or analysis. | 02:55 |
| persia | ajmitch: You may want to wait. Come Tuesday, the team might be abolished. | 02:55 |
| hyperair | hmm? ubuntu reviewers? | 02:55 |
| hyperair | persia: where are these outstanding patches? | 02:55 |
| ajmitch | persia: being a team member isn't exactly critical as it is | 02:55 |
| persia | hyperair: Yeah. That's the team that reviews all the patches people submit to launchpad and gets them integrated into Ubuntu or Debian or Upstream, or rejects them for well-explained reasons. | 02:55 |
| hyperair | persia: as in, patches not put into debdiffs? | 02:56 |
| persia | ajmitch: True :) | 02:56 |
| persia | hyperair: Some of them are sometimes also debdiffs against random versions, or malformed debdiffs, etc. | 02:56 |
| hyperair | ah okay | 02:56 |
| persia | hyperair: Basically, it's random patches and stuff, as opposed to stuff where active Ubuntu Developers are trying to upload something to somewhere they don't (yet) have access. | 02:57 |
| persia | Whereas sponsoring is more of an in-crowd thing: it's mostly developers who get sponsored (some might be relatively inactive, or brand new, but they are still trying to be Ubuntu Developers, as opposed to sharing patches) | 02:57 |
| * hyperair nods | 03:00 | |
| _Andrew | hyperair, ah, the library i'm packaging is ogre so would it be "usr/include/$OGRE" ? | 03:06 |
| RAOF | _Andrew: No; it'd be "usr/include/ogre", or whatever directory it installs its include files to. $LIB is being used as a variable reference for you to replace with whatever is approprate :). | 03:08 |
| _Andrew | ah | 03:09 |
| _Andrew | thanks | 03:09 |
| _Andrew | Sorry, I have another question | 03:11 |
| _Andrew | Is there some way to tell if I have missed a file in the deb that was added via make install? | 03:12 |
| _Andrew | What I mean is there a tool or something that does it automated | 03:12 |
| RAOF | dh_install --list-missing (or --fail-missing, if you want to fail the build when you've missed something). | 03:12 |
| _Andrew | I have multiple packages so would that still work? | 03:13 |
| RAOF | Yup. | 03:13 |
| _Andrew | awesome | 03:13 |
| _Andrew | thanks | 03:13 |
| RAOF | Depending on your rules file, you'll need to do different things to pass those options to dh_install. | 03:13 |
| === paissad_ is now known as paissad | ||
| === wgrant_ is now known as wgrant | ||
| ripps | Can someone explain to me what's wrong with this package? http://launchpadlibrarian.net/39498488/buildlog_ubuntu-lucid-amd64.gmpc_0.19.100%2Bgit20100221.2c55870-0ubuntu1~ripps4_FAILEDTOBUILD.txt.gz | 03:52 |
| ripps | This only seems to happen with lucid amd64, not any other ubuntu. Karmic to Hardy all build fine, only Lucid seems to have problems here. | 03:53 |
| persia | Probably a gcc 4.4 thing then. | 03:54 |
| ripps | persia: yeah, I checked and it seems the gmpc in the repos had this problem, but than it went away, How did you guys fix it? | 03:54 |
| persia | ripps: Check the changelog for lucid gmpc :) | 03:56 |
| ripps | persia: I checked that too, it still at the debian version. http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi lists the exact problem that I have, but the version in the repos looks fine. I don't understand why | 03:58 |
| persia | Well, it looks like the binaries in the repository were built against karmic. | 04:00 |
| ripps | oh, so they never fixed it. | 04:00 |
| persia | This is a bit of an issue, as it means that we can't currently build the binaries we're distributing (which is why it's highlighted on the udd list). | 04:00 |
| persia | But the binaries may well still *run*, even if they cannot be built. | 04:01 |
| persia | Right. | 04:01 |
| ripps | hmmm.... | 04:01 |
| === ApOgEE__ is now known as ApOgEE | ||
| zooko | Folks: Tahoe-LAFS v1.6.1, which is just a couple of fixes of regressions in Tahoe-LAFS v1.6.0, will be released next weekend, not this weekend. | 04:09 |
| ripps | persia: the new gmpc-data package I've made works fine, it just gives me an error when I'm installing it for the first time, it's probably freaking because it's trying to install files that was provided by the old gmpc. Is it possible to prevent this? | 04:36 |
| ripps | a simple 'apt-get -f install' fixes it, but I don't want my users to have to be bothered to do this. | 04:36 |
| persia | ripps: You want a combination of "Conflicts" and "Replaces" in your control file. | 04:38 |
| lifeless | persia: breaks | 04:38 |
| lifeless | persia: not conflicts | 04:39 |
| === mhall119|work is now known as mhall119|SCaLE8x | ||
| persia | ripps: use versioned Conflicts and Replaces for the old versions. | 04:39 |
| persia | lifeless: Conflicts is supposed to be used when two packages contain the same file. | 04:39 |
| lifeless | persia: not if one of them replaces it | 04:39 |
| persia | No? | 04:39 |
| persia | So just Breaks/Replaces? | 04:39 |
| lifeless | persia: conflicts is only needed when dpkg can't unpack without it | 04:39 |
| persia | But why Breaks, if the replacements are clean? | 04:39 |
| lifeless | breaks is used when dpkg can unpack, but the thing won't work. | 04:40 |
| persia | So in this case, just Replaces. | 04:40 |
| ripps | lifeless: do I just do 'Breaks: gmpc' in the gmpc-data section? | 04:40 |
| lifeless | persia: possibly; depends on the exact topology of changes. | 04:40 |
| lifeless | ripps: so, to be clear: | 04:40 |
| lifeless | gmpc version X has a file Y, and gmpc-data is a new package that will now be responsible for delivering Y to users ? | 04:41 |
| ripps | lifeless: correct | 04:41 |
| lifeless | persia: conflicts makes upgrade _much_ harder because you have to remove, rather than just unconfigure/reconfigure. It would be good to be able to do an upgrade without aptitude supplying --force-conflicts to dpkg | 04:42 |
| lifeless | ripps: ok, what you want is this: | 04:42 |
| persia | lifeless: I thought that with versioned conflicts, everything was good, as long as the newer package was available. | 04:42 |
| lifeless | gmpc-data - Replaces: gmpc ( << new version) Breaks: gmpc (<< new version) - unless it won't break the old gmpc | 04:43 |
| lifeless | persia: no, because you can't decide on the right ordering, in many cases. | 04:44 |
| lifeless | persia: and its not semantically correct either | 04:44 |
| lifeless | ripps: gmpc should depend on gmpc-data too | 04:44 |
| lifeless | ripps: you need the replaces: header so that dpkg knows it can install gmpc-data while the old gmpc is still installed. | 04:45 |
| lifeless | ripps: if installing the new gmpc-data while the old gmpc is installed will cause the old gmpc to stop working, then you should add the breaks: header too | 04:45 |
| lifeless | persia: example. say you have a similar situation to the above, but files moving in both directions. So you have A and A-data | 04:47 |
| lifeless | persia: and A' and A'-data where A' is newer | 04:47 |
| ripps | lifeless: thanks, I'll commit that now | 04:47 |
| lifeless | if you use conflicts, you have: | 04:47 |
| lifeless | A': conflicts A-data | 04:47 |
| lifeless | A'-data: conflicts A | 04:47 |
| lifeless | and usually you also have | 04:47 |
| lifeless | A': depends A'-data | 04:47 |
| persia | Right. | 04:48 |
| superm1 | i've wondered sometimes why packages actually split into x-data and x when the data isn't useful from any other package and no other package depends on "just the x-data" | 04:48 |
| * persia attempts to commit this update to best practices to long-term memort | 04:48 | |
| lifeless | persia: now, given that conflicts means 'cannot coexist on disk', what order of unpack operations will let dpkg move from A + A-data to A' + A'-data without violating either the A: depends A-data, A': depends A'-data, and the conflicts rules. | 04:48 |
| persia | superm1: To reduce archive size, because x-data is often arch:all. This gets kinda important when -data packages can run 100s of MB. | 04:49 |
| superm1 | persia, ah; that would make more sense then :) but for packages that are already arch:all it's a moot point then | 04:49 |
| lifeless | persia: the answer is 'there is no sequence': if you upgrade A'-data first, dpkg cannot unpack anything because A'-data conflicts with A. The reverse is also true, so you cannot upgrade that package. | 04:49 |
| persia | superm1: Indeed. For arch:all packages it's entirely pointless. | 04:50 |
| lifeless | in actual fact though, they don't *conflict*, they *break*, so using breaks is better. | 04:50 |
| persia | And they may not even break, depending on which files moved how, etc. | 04:51 |
| lifeless | right | 04:51 |
| lifeless | but as a rule, using breaks + replaces will do the right thing | 04:51 |
| lifeless | such that you can do 'dpkg -i A' A'-data' and have it work. | 04:51 |
| ripps | technically, I had two new packages, gmpc-data and gmpc-humanity. gmpc-humanity is an optional set of icons that qball, the developer, recommended should be moved to a seperate package. gmpc-humanity is a Recommend to gmpc now, so it can be removed without affecting gmpc | 04:52 |
| _Andrew | hyperair, I tried "usr/include/OGRE" but it doesn't catch files such as "usr/include/OGRE/OgreGpuProgramParams.h" | 04:54 |
| _Andrew | Infact it doesn't seem to catch anything in the folder | 04:54 |
| lifeless | ripps: ok. so the same rules will apply | 04:56 |
| ripps | I wish there were some kind of way to see what the download stats for my ppa are. I've heard from the irc-channels that quite a few people use, but I wish I had an exact number so I know when I should discontinue my hardy backports | 04:58 |
| lifeless | wgrant is working on that | 04:58 |
| wgrant | ripps: I implemented that over the weekend. | 04:59 |
| RAOF | _Andrew: Are you pinging hyperair for some reason? He's not in the channel. And, in response to your question: is usr/include/OGRE being installed to an appropriate directory by “make install”? Are you actually calling dh_install? Is your .install file called the right thing? | 04:59 |
| ripps | wgrant: huh? where? | 04:59 |
| wgrant | ripps: In a branch which is yet to be looked at by anyone else. | 05:00 |
| ripps | wgrant: cool, let's hope it gets to edge soon | 05:00 |
| wgrant | ripps: It can't go to edge before the next release (because it needs DB and server changes to actually store the data), but it might make the next release in 1.5 weeks if I'm lucky. | 05:02 |
| * ripps crosses fingers | 05:02 | |
| _Andrew | RAOF, oh I didn't notice he left. I checked the log and it says it's installing in blah/blah/debian/tmp/usr/include/OGRE/Filename.h and here is a pastebin of my rules and .install file.. http://pastebin.com/d6760106c [rules file] & http://pastebin.com/d729c162a [install file] | 05:02 |
| persia | _Andrew: That's the right location, you might want to check dpkg --contents on the .deb | 05:03 |
| RAOF | Also, is there any particular reason you're only installing usr/include/OGRE, and not simply usr/include? | 05:03 |
| _Andrew | I guess not | 05:04 |
| kamalmostafa | persia: i'm available for libtifiles review, if you wish | 05:05 |
| _Andrew | I added --fail-missing and it's coming up with what looks like every file it should be installing | 05:06 |
| RAOF | What is the name of your install file? | 05:06 |
| persia | kamalmostafa: You mean "why haven't you looked at libtifiles yet"? | 05:06 |
| _Andrew | libogre-dev.install | 05:06 |
| _Andrew | There's more then one though | 05:06 |
| _Andrew | I'm just concentrating my effort to fix one | 05:07 |
| kamalmostafa | persia: oh not at all! just letting you know that i'll be available for the next couple of hours if you need me. :-) | 05:07 |
| RAOF | _Andrew: And for completenes, want to pastebin your debian/control? | 05:08 |
| _Andrew | sure | 05:09 |
| _Andrew | http://pastebin.com/d4dee29b3 | 05:09 |
| RAOF | Why are you calling dh_install -plibogre-dev twice? | 05:12 |
| RAOF | (Once in binary-arch, once in binary-indep) | 05:13 |
| _Andrew | woops | 05:13 |
| RAOF | In fact, that package seems to call dh_install an unnecessarily large number of times. | 05:15 |
| persia | Once is usually completely sufficient. | 05:20 |
| _Andrew | Oh really? | 05:20 |
| _Andrew | Don't you need to do it per deb? | 05:20 |
| StevenK | Nope | 05:20 |
| _Andrew | woops | 05:21 |
| _Andrew | :) | 05:21 |
| ripps | Is it possible to force a program to compile with an older version of gcc, even if it's configure doesn't allow for specifying gcc version? | 05:28 |
| lifeless | yes | 05:29 |
| persia | ripps: You can set funny build-dependencies, and forcibly patch the build system. | 05:29 |
| lifeless | if you export CC | 05:29 |
| lifeless | CC=gcc-3.0 | 05:29 |
| persia | In almost every case, it's better to just fix the issue. | 05:29 |
| ripps | Yeah, but the issue doesn't seem to be with the code, both me and the developer have looked at it. It's glitchin on a gob file as it's declaring a public... no reason for it to break. Seems to be a bug with gcc | 05:30 |
| lifeless | ripps: have you filed the bug? | 05:31 |
| ripps | not yet | 05:31 |
| persia | kamalmostafa: Why drop all the past Ubuntu changelog entries for 507741? | 05:48 |
| kamalmostafa | persia: I thought (incorrectly?) that only one changelog entry could be inserted for any change, so I just tacked my new one on to what was there in "libtifiles". | 05:52 |
| persia | Well, the changelog is supposed to represent the history of the package. Given that this is a merge of two packages with completely separate histories, I think it makes sense to credit all the prior contributors directly. | 05:53 |
| kamalmostafa | i mean... those changelog entries from Ubuntu's "libtifiles2" weren't ever really applied to the "libtifiles" tree. If I were to put changelog entries in, it would imply that such a history existed when it didn't. Instead, I tried to credit the (one) contributor by copying the exact content of his change (the 0ubuntu1 change) and I credited him below it [Chris Coulson...]. | 05:55 |
| persia | OK. That's a fair argument. bddebian has plenty of credit anyway. | 05:56 |
| kamalmostafa | bddebian? did I miss a credit? | 05:57 |
| persia | https://wiki.ubuntu.com/BddebianIsAGod | 05:57 |
| persia | kamalmostafa: bddebian did the initial packaging in Ubuntu, but he doesn't care about the package (my experience is that he doesn't much care about any specifics, as long as there are fewer bugs) | 05:59 |
| persia | And LP has the history, and we're removing that package anyway, and we'll sync in the future, dropping all the Ubuntu credits, so it should be fine. | 05:59 |
| kamalmostafa | persia: ok yes I see it now... but *technically* that work (the initial 1.1.2 packaging) is *not* merged into this tree, I think. :-) | 05:59 |
| persia | I'll push what I have, assuming I don't find something else obvious. | 05:59 |
| kamalmostafa | persia: (but no arguing the bddebian godhood status issue ;-) | 06:00 |
| persia | kamalmostafa: I don't tend to think of credit in terms of direct bit links, but rather on a holistic level. So, I like to credit someone for something even when it's no longer directly present, unless there's some reason not to do so. | 06:02 |
| kamalmostafa | persia: okay, in that case, I'll revert to "ooops, I missed it". ;-) | 06:02 |
| persia | It's the same argument for keeping all the Ubuntu changelog entries in a merge even though the only remaining diff after several years is s/iceweasel/firefox/ in a manpage. | 06:03 |
| persia | But I don't think it matters in this case, and the original packager has declared that they don't care much in this channel in prior discussions about this, so all should be fine. | 06:03 |
| kamalmostafa | lets talk about the changelog issue for a moment... I agree about wanting to merge in the *information* from the merged-in changelog, but I'm not convinced about the logic of creating multiple changelog entries for one change, since it implies a lineage that never actually existed. (and would builddeb even accept such a thing? i'll try it). | 06:06 |
| persia | kamalmostafa: If I was doing it, I'd interleave the changelog entries in version order. | 06:07 |
| persia | kamalmostafa: And you may have to pass -- -vnnnnn to get the right .changes file. | 06:07 |
| persia | kamalmostafa: Anyway, uploaded. | 06:10 |
| kamalmostafa | persia: okay, thanks a bunch. debuild seems to have no problem with multiple changelog entries (as I bet you already knew). I'll ponder some more on how I feel about it. I guess I also dislike the idea that it implies that the real authors of those changes were responsible for merging them into this tree. If I've merged their work improperly, then I should take the blame, not them. | 06:17 |
| persia | Oh, you would, because your name would show up as "Changed-By". | 06:17 |
| persia | Their work would only show in prior changelog entries. | 06:17 |
| persia | So, have you filed the removal bugs for libti*2 yet? | 06:18 |
| kamalmostafa | that's true -- but I know that I generally assume that if somebody's name is on the change log entry, that they themselves touched the tree. anyway... | 06:18 |
| kamalmostafa | no I haven't filed removal bugs yet. I'd like to ensure that libtifiles and libticalcs both build properly first, if that's ok. | 06:19 |
| persia | Sure. How are they doing? Do they need a give-back? | 06:22 |
| kamalmostafa | persia: need a what now? | 06:22 |
| kamalmostafa | what is a "give-back"? | 06:23 |
| persia | A give-back is when we give Soyuz back the same source to build again, rather than triggering with a new upload. | 06:28 |
| kamalmostafa | persia: same as a "retry build"? | 06:28 |
| StevenK | Exactly the same | 06:28 |
| kamalmostafa | okay, then, yes -- we will need retry/give-back libticalcs once libtifiles completes | 06:29 |
| persia | OK. I wasn't sure if libticalcs had built against libtifles. | 06:31 |
| persia | Err, libtifiles2 | 06:31 |
| persia | Oh, right, it wouldn't have, because of build-depends. | 06:32 |
| kamalmostafa | yes, calcs depends on files. The libticalcs you uploaded yesterday seems to be pending, waiting for libtifiles-dev to appear. | 06:32 |
| * persia gets confused again, and hopes that this sort of thing doesn't need to happen for any other packages. | 06:32 | |
| kamalmostafa | persia: um... hate to tell you this, but there are a few more packages in the libti* set, and they're going to need exactly this same treatment. | 06:33 |
| persia | kamalmostafa: Right. I thought it might have built against the libtifiles-dev provided by libtifiles2, but then I remembered that libtifiles2 provided libtifiles2-dev just for extra annoyance. | 06:33 |
| persia | kamalmostafa: All of libti* needs the source-package-name merge? | 06:34 |
| persia | Or do they just need to be rebuilt? | 06:34 |
| kamalmostafa | persia: yup, extra *bonus* annoyance no less. Anyway, my libtifiles and libticalcs *did* build successfully together in a PPA (5 weeks ago, so who knows) | 06:34 |
| kamalmostafa | they all need the same "drop the 2" procedure | 06:34 |
| persia | and merge from separate Ubuntu and Debian sources? | 06:35 |
| kamalmostafa | i (foolishly?) signed on to take care of them as well -- although if the group here collectively rushes out and does them all overnight to prevent me from touching them i won't be surprised! ;-) | 06:35 |
| kamalmostafa | I haven't looked at the details for the rest of them yet. | 06:35 |
| persia | I think you have different expectations than are normally warranted then :) | 06:35 |
| kamalmostafa | I got the impression from a quick glance that they all were in a similar state as these first two -- small changes need to be merged from the diverged libtiXXX2-0ubuntuY versions | 06:37 |
| persia | kamalmostafa: For the future ones, please do merge the entire Ubuntu changelog as well. | 06:42 |
| persia | (interleaved as appropriate, depending on version history). | 06:42 |
| persia | This will follow the standard practice in merging, and make it kinda look like the package didn't have the silly name difference all this time. | 06:42 |
| kamalmostafa | persia: okay, will do. Is there any "standard practice" documentation for merging that I could keep handy? | 06:45 |
| persia | !merge | 06:45 |
| ubottu | https://wiki.ubuntu.com/UbuntuDevelopment/Merging | 06:45 |
| kamalmostafa | excellent, thanks | 06:46 |
| kamalmostafa | and while we wait for that build here... thanks again for your help last night -- in particular your comments about the importance of avoiding the impression that Ubuntu would callously throw away their work -- that's a very clear way to keep things in the right perspective (keeping the feelings of upstream in mind). | 06:48 |
| persia | It's all a cascade. We'd be completely unable to do what we do without both those who work upstream of us (in Debian or software authors, etc.), and those who work downstream (documentation team, support team, etc.). | 06:52 |
| persia | I think we do our best work when the solutions we find incorporate as much of what is available from others (in both directions) into what is provided, and we share information about changes up and down to keep everyone informed. | 06:54 |
| _Andrew | ok | 07:00 |
| _Andrew | So I changed the install file from usr/include/OGRE to usr/include and I get the error message "cannot stat `usr/include`: No such file or directory" | 07:01 |
| persia | which debhelper are you using? | 07:02 |
| persia | and what compat level? | 07:02 |
| kamalmostafa | persia: yup. furthermore, I like the idea that the wishes of the software authors themselves are "most" important (i.e. I should try to retain the work of the original upstream authors in preference to changes done at Ubuntu or Debian, if I have to make a choice). | 07:02 |
| _Andrew | debhelper (>= 5) with compat at 5 | 07:03 |
| persia | kamalmostafa: I'm less confident about that. I think that there's room for debate and discussion in many cases, and within the context of a distribution, prefer to see integration supported over pure assumption of upstream preferences. | 07:03 |
| persia | _Andrew: Are you sure the build system is installing the headers into ${DESTDIR}/usr/include ? | 07:05 |
| persia | If not, you may have to use compat level 7 to fall back to checking ${CURDIR}/${INSTALL_CANDIDATE} if ${DESTDIR}/${INSTALL_CANDIDATE} is not found. | 07:06 |
| persia | (which an associated bump in the required minimum version of debhelper) | 07:06 |
| persia | s/which/with/ | 07:06 |
| _Andrew | Yes, here is the log.. http://pastebin.com/d7b36aeb3 | 07:06 |
| persia | _Andrew: What's the content of debian/install again? | 07:07 |
| kamalmostafa | persia: good point -- and I'm not trying to make such a wide generalization as I think I'm sounding like here -- its actually just that I think I had acquired too much of a "Debian-centric" view (that my #1 goal was supposed to be to keep divergence from Debian to a minimum) -- hence I wanted to throw away some of the upstream dev's work that I deemed "unimportant" just to keep us closer to Debian -- that was a misguided view, a | 07:07 |
| _Andrew | Currently looks like this.. http://pastebin.com/d27e53cee | 07:08 |
| persia | kamalmostafa: Ah, yes. The key is to balance the software authors, Debian, our work, the hints from the teams that use our work, and our users. | 07:08 |
| persia | _Andrew: And this package builds multiple binaries, and that's debian/ogre-dev.install or some such? | 07:09 |
| _Andrew | yep | 07:09 |
| * persia doesn't understand | 07:09 | |
| persia | Ought work. | 07:09 |
| _Andrew | I have the whole debian folder in bzr if you'd like to try yourself | 07:11 |
| persia | No, I believe you. I just don't understand why it's happening, so can't recommend anything towards a solution. | 07:12 |
| persia | (and don't even know where to start such an investigation) | 07:12 |
| kamalmostafa | I wonder if the builders (Soyuz?) are feeling okay. libtifiles builds seem "stuck" -- i386 has been saying that it started 0 seconds ago for the past 20 minutes or more: https://launchpad.net/ubuntu/+source/libtifiles/1.1.2-0ubuntu2 | 07:13 |
| _Andrew | It's at bazaar.launchpad.net/~andrewfenn/%2Bjunk/ogredev/ in the folder ogre/pre-karmic/debian if you would like to see the whole debian file. Maybe you can spot something that's wrong | 07:13 |
| persia | kamalmostafa: You can ask in #launchpad, but sometimes https://launchpad.net/builders provides a clue. | 07:13 |
| persia | In this case, I'd recommend asking because there are >500 jobs pending, and the buildds are idle :) | 07:14 |
| Speedy2 | www.search2.net | 07:34 |
| kamalmostafa | persia: looks like i'm going to fall asleep before the builders wake up here. think I'll call it a night. I'll file the removal bugs tomorrow (assuming successful builds of libtifiles and libticalcs). sounds good? | 07:37 |
| kamalmostafa | persia: thanks for the interesting discussion, the fine guidance, and all the help! | 07:39 |
| persia | kamalmostafa: Thanks for noticing the problem and stepping up to fix it :) | 07:43 |
| dholbach | good morning | 07:49 |
| slytherin | Laney: I decided to leave kiso as it is since I am not primarily KDE packager/user. Perhaps someone form kubuntu team should make the decision for removal. | 09:11 |
| Laney | slytherin: maybe you could ping a Kubuntu dev | 09:12 |
| slytherin | Laney: Will do when I find time. My hands are full with other things at the moment. | 09:13 |
| eagles0513875 | hey guys i have a question regarding packaging. is it best to use a machine and its hardware to the fullest or would kubuntu installed in virtual box be good enough? | 09:27 |
| persia | eagles0513875: It depends on what you seek to achieve, and how well your virtualisation solution works with your hardware and host environment. | 09:30 |
| eagles0513875 | i would like to start working with the ubuntu community by packaging but right now im limited on hardware to setup linux on. | 09:30 |
| persia | Doesn't really matter then. | 09:31 |
| eagles0513875 | ok just making sure | 09:31 |
| persia | Some people work on packages on 200MHz machines with 128MB of RAM. | 09:31 |
| persia | Some people have 8000-node grids. | 09:32 |
| persia | As long as the environment you're using is fast enough that you can feel productive, it's good. | 09:32 |
| eagles0513875 | :) ok sweet | 09:33 |
| eagles0513875 | persia: in that case would i be better off upgrading from a karmic install or installing right onto lucid | 09:33 |
| persia | again, it depends on what makes you most productive. | 09:33 |
| eagles0513875 | ok | 09:33 |
| persia | Since you're working in a virtual environment anyway, I'd expect you'd do better with lucid. | 09:33 |
| persia | Because if you put karmic in a virtual environment, you'll end up with lucid in a virtual or chroot environment inside the karmic virtual environment, etc. | 09:34 |
| * eagles0513875 goes about setting up a 2nd vm with what ever iso i have downloaded already | 09:42 | |
| slytherin | The solar theme for plymouth looks nice on lucid. :-) | 09:58 |
| christoph_debian | hm what does ubuntu do to require https://launchpad.net/ubuntu/+source/supertuxkart/0.6.2+dfsg1-1ubuntu1 ? | 10:41 |
| christoph_debian | someone a idea? | 10:41 |
| directhex | christoph_debian, have you got a handy build log from -1 to comparte to ubuntu's -1 build log? | 10:42 |
| christoph_debian | directhex: https://buildd.debian.org/fetch.cgi?pkg=supertuxkart&arch=i386&ver=0.6.2%2Bdfsg1-1&stamp=1251030938&file=log&as=raw or so? | 10:45 |
| Laney | it's probably related to debian bug #556477 | 10:46 |
| ubottu | Debian bug 556477 in src:supertuxkart "FTBFS with binutils-gold" [Minor,Open] http://bugs.debian.org/556477 | 10:46 |
| directhex | nice one Laney | 10:47 |
| christoph_debian | oh ubuntu runs -gold ? | 10:47 |
| Laney | I don't know, maybe different linker flags that trigger the same problem | 10:48 |
| Laney | probably a change you want to take back | 10:49 |
| * Laney spanks randomaction | 10:50 | |
| randomaction | christoph_debian, Laney: I believe it's newer mesa | 10:50 |
| christoph_debian | anyway it looks like something I want fixed in debian | 10:52 |
| randomaction | I was under impression that it's an upstream problem, like insufficient checks in configure | 10:56 |
| randomaction | cf http://people.ubuntuwire.org/~lucas/ubuntu-nbs/32/supertuxkart_0.6.2+dfsg1-1_llucid32.buildlog and http://launchpadlibrarian.net/39444809/buildlog_ubuntu-lucid-i386.supertuxkart_0.6.2%2Bdfsg1-1ubuntu1_FULLYBUILT.txt.gz | 10:56 |
| randomaction | in unpatched version, it finds -lGL and is content with it, while symbols from -lGLU will be required | 10:57 |
| geser | christoph_debian: see http://people.ubuntuwire.org/~lucas/ubuntu-nbs/32/supertuxkart_0.6.2+dfsg1-1_llucid32.buildlog for the original failure | 11:10 |
| siretart` | christoph_debian: oh, hi there. nice to see you around here :-) | 11:15 |
| === ShadowChild is now known as lukjad86 | ||
| BIDMAS | I'm packaging an application. JDK is a dependency. Specifically which package should I put as a dependency, and should it be in the pre-depends section? | 12:01 |
| persia | default-jdk and no. | 12:02 |
| BIDMAS | Thanks! | 12:02 |
| * BIDMAS edits his control file | 12:02 | |
| persia | But the advice you get in -java is likely to be both more robust and more correct. | 12:03 |
| \sh | does anyone has "serious kernel bug" alerting after reboot with latest lucid kernel? | 12:03 |
| persia | (and please don't ask the same question in two places without waiting for a reply: it just confuses folk) | 12:03 |
| Rhonda | BIDMAS: pre-depends is only required in really rare cases and should only be added with discussion first about wether it could be avoided at all. | 12:04 |
| BIDMAS | In that case, lucky I asked! | 12:04 |
| SevenMachines | BIDMAS: you should probably also add additional alternatives to default-jdk, such as (virtual packages) java-sdk, or versioned if necessary, java6-jdk and so on, to allow for other java implementations to be used | 12:06 |
| persia | BIDMAS: And you should really follow-up with slytherin in -java, who is going to give better advice than the rest of us. | 12:06 |
| SevenMachines | undoubtedly :) | 12:06 |
| SevenMachines | than mine anyway, not anyone elses! | 12:07 |
| BIDMAS | So which sections in the control file should I be editing, and with what specifically? | 12:09 |
| _Andrew | Just one more error left to fix.. | 12:11 |
| _Andrew | http://pastebin.com/d229edeca | 12:11 |
| BIDMAS | SevenMachines: If I put them all in the 'Depends' section, won't it require them all? | 12:12 |
| BIDMAS | So which section should I put it in? | 12:12 |
| BIDMAS | (section[s]) | 12:12 |
| SevenMachines | BIDMAS: seperate with an or '|' | 12:13 |
| BIDMAS | Hmm | 12:13 |
| BIDMAS | Thanks | 12:13 |
| SevenMachines | BIDMAS: if its a build dependency the 'Build-Depends' | 12:17 |
| SevenMachines | for example, Build-Depends: default-jdk | java-sdk | 12:18 |
| SevenMachines | if you need a specific jdk then change java-sdk to a versioned version like java6-jdk and so on | 12:19 |
| persia | Um, it's more complicated than that. | 12:19 |
| SevenMachines | it does confuse me a little to be honest | 12:20 |
| persia | That's why I keep pointing to -java, since someone was silling to help there. | 12:21 |
| slytherin | It is nice to see DEHS supporting 3.0 format packages. :-) | 12:27 |
| persia | And we have a luxurious 2 months to port it to UEHS :) | 12:28 |
| slytherin | is UEHS nothing but Ubuntu branded DEHS? | 12:29 |
| persia | slytherin: There's some different filtering, and a bit of other hackery, but essentially. | 12:29 |
| persia | The code ought be avialable, and referenced from the page. | 12:30 |
| slytherin | hmm, so it shouldn't be that hard. | 12:30 |
| persia | No, just needs merging. | 12:30 |
| persia | The differences are important, because we don't do by-maintainer searches, and filter out anything with a real maintainer in Debian, etc. | 12:30 |
| slytherin | wgrant: When you don't have anything better to do, can you look into fixing uehs to make it work with 3.0 format packages? | 12:32 |
| slytherin | forgot the 'please'. :-) | 12:32 |
| persia | Um, that might be a while. Soyuz needs a lot of work :) | 12:32 |
| persia | Is it more than a simple merge? | 12:33 |
| wgrant | slytherin: I believe it's fixed upstream. I'll try to merge that now. | 12:33 |
| * persia is impressed with responsiveness | 12:33 | |
| wgrant | Conflicts, conflicts, everywhere. | 12:36 |
| * wgrant resolves. | 12:36 | |
| BIDMAS | SevenMachines: Unfortunately that didn't work - default-jdk | java6-jdk | java-sdk | 12:44 |
| BIDMAS | Requires all of them, when only one is required :S | 12:44 |
| SevenMachines_ | BIDMAS: as persia mentioned -java is the place to go | 12:44 |
| SevenMachines_ | they'll know | 12:44 |
| BIDMAS | k | 12:49 |
| Laney | persia: Nice mail! | 12:51 |
| * Laney is glad that people think about these big picture things | 12:51 | |
| slytherin | Laney: Which one? Future of MOTU? | 12:51 |
| Laney | yes | 12:52 |
| persia | People keep telling me they read it, but nobody replies. I tried to organise it so that individual bits could be easily clipped for discussion. Please help make this a discussion. | 12:53 |
| sebner | Laney: persia: pretty nice and even more *long* mail | 12:53 |
| Laney | I will reply, don't worry | 12:53 |
| * persia prefers 1000 words to a picture. | 12:53 | |
| sebner | heh | 12:53 |
| sebner | persia: does it have any benefit if I answer "Full ACK"? | 12:53 |
| persia | sebner: Um, not so much :) | 12:54 |
| wgrant | slytherin: It seems to be running happily. I'll let you know when it finishes so you can confirm that it's working properly. | 12:54 |
| persia | sebner: But I can't believe you agree with every particular :p | 12:54 |
| slytherin | wgrant: Cool | 12:54 |
| sebner | persia: to be honest the are many areas were I'm not really involved so I don't really have an opinion there (e.g SRU) | 12:55 |
| Laney | you can have an opinion about how it might work though | 12:55 |
| persia | And that's the point. As MOTU, it is our individual responsibility to ensure that we remain MOTU (else we may as well resign from the team and go do something else). | 12:56 |
| persia | Apathy is our biggest enemy. | 12:56 |
| sebner | hyperair: hoia! finally you have upload rights :) | 13:03 |
| * sebner will wait what Laney writes and then copy&paste that with some other words | 13:03 | |
| hyperair | sebner: \o/ | 13:04 |
| * Laney eyes sebner | 13:04 | |
| sebner | Laney: you are my mental lead :D | 13:04 |
| Laney | maybe I'll hold off until you are finished responding :) | 13:05 |
| sebner | Laney: nice try ;) | 13:05 |
| hyperair | heheh | 13:06 |
| slytherin | hyperair: Congrats. | 13:07 |
| === verwilst_ is now known as verwilst | ||
| hyperair | slytherin: thanks | 13:10 |
| * slytherin just finished reading the mail. Will reply from home. | 13:11 | |
| wgrant | ... just before the UEHS run finished. | 13:17 |
| persia | He's just going home from work, and ought be back online in 45 minutes or so. | 13:18 |
| persia | (not that this isn't pointlessly late for you :) ) | 13:19 |
| wgrant | persia: Can you let him know when he gets back? | 13:22 |
| wgrant | I'll hopefully be long gone. | 13:22 |
| persia | I'll either do that, or redelegate to someone else if there is protracted absence. | 13:22 |
| persia | Have a good night. | 13:22 |
| wgrant | Thanks. You too. | 13:23 |
| Laney | erm, I'm writing too many words about REVU | 13:34 |
| Laney | sorry | 13:34 |
| * sebner kicks his router for breaking down every 5 minutes | 13:37 | |
| persia | Laney: There is no such thing as "too many words" :) | 13:37 |
| persia | Just be clear and concise, and use as many words as you need. | 13:38 |
| persia | So, clear, concise, and *complete* | 13:38 |
| Laney | We'll see if I achieved this... | 13:38 |
| sebner | persia: your mail is the longest I've ever read *g* | 13:39 |
| persia | sebner: You should read some of my other mail then :) | 13:39 |
| * persia used to have a job that involved writing ~50K of email daily | 13:40 | |
| persia | (mind you, this was in 100-150 separate messages) | 13:40 |
| sebner | persia: O_o, something is really wrong then (I guess) | 13:40 |
| sebner | persia: why do I have the feeling that 1 per day was normal work and the rest writing messages? ;D | 13:40 |
| sebner | *1 hour | 13:42 |
| persia | sebner: Hrm? My entire job was email. I was responsible for coordinating all technology activities for a multinational for two continents. I didn't do anything except break up project plans into actions, describe the actions to technicians, collate reponses, compose reports, and track exceptional issues. | 13:42 |
| persia | So there was no 1 hour :) | 13:42 |
| sebner | heh | 13:42 |
| sebner | persia: Urgh, nothing you want to make for 40 years I guess... I point of your mail was chatting in -motu right? I think we are OT ^^ | 13:43 |
| persia | heh :) | 13:43 |
| Laney | vim tells me I am 47% of the way through replying ;) | 13:44 |
| sebner | mail replying with vim | 13:45 |
| sebner | some people *really* are hardcore | 13:45 |
| Laney | mutt spawns it | 13:45 |
| Laney | I mean to try sup one day soon | 13:46 |
| * sebner hugs his gui *hehehehe* | 13:46 | |
| * Laney hits send | 14:05 | |
| james_w | Laney: notmuch > sup | 14:06 |
| Laney | I see what they did thar | 14:07 |
| directhex | yay james_w | 14:23 |
| === ikt_ is now known as ikt | ||
| nigelb | I could use some help with a build error. I copied an apport hook to debian folder and added a line "debian/source_rhythmbox.py usr/share/apport/package-hooks" and pbuiler gives me the error http://pastebin.com/d228e0a6f | 15:09 |
| nigelb | the line was added to rhythmbox.install | 15:09 |
| persia | And debian/source_rhythmbox.py exists? | 15:11 |
| nigelb | yes | 15:12 |
| persia | Does it automagically work if you set debian/compat to 7? | 15:12 |
| nigelb | lemme try | 15:12 |
| nigelb | what does that value do? | 15:13 |
| sebner | Laney: pkg-cli package set ftw! :) | 15:31 |
| nigelb | persia: Now, I get a new error. | 15:32 |
| Laney | sebner: now you get to write words | 15:32 |
| nigelb | http://pastebin.com/d5aef866 | 15:32 |
| Laney | get to it | 15:32 |
| sebner | Laney: Yeah, I just finish reading the other replies | 15:32 |
| persia | nigelb: Well then, the issue wasn't the one I thought. Are you absolutely sure about spelling? | 15:33 |
| nigelb | lemme confirm again! | 15:33 |
| persia | nigelb: One trick I use sometimes when I get issues like this is to try a local build in the chroot (pbuilder-dist lucid login or schroot -c lucid or some variation thereof) | 15:34 |
| persia | then use debuild -b | 15:34 |
| nigelb | I get this error in pbuilder | 15:34 |
| nigelb | not in debuild -S | 15:34 |
| persia | This is *not* a good way to test-build packages to submit to the archive, but it does leave you inside the build environment, so you can hunt down why something is failing, etc. | 15:34 |
| persia | Yes, I understand. | 15:34 |
| Laney | There is also a pbuilder hook to dump you in the build env on failures | 15:35 |
| persia | debuild -b is very similar to what pbuilder does when building a package, but you can run it after logging into the chroot, so you can track down issues in the half-built package on failure. | 15:35 |
| persia | Laney: Do you know the syntax? That might be as easy for nigelb | 15:35 |
| persia | nigelb: And do set the compat back to whatever it was before, since that doesn't automagically fix it. | 15:36 |
| Laney | persia: It's somewhere on the wiki | 15:36 |
| Laney | persia and nigelb: Right here — https://wiki.ubuntu.com/PbuilderHowto#Running%20a%20Shell%20When%20Build%20Fails%20(Intro%20to%20Hook%20Scripts) | 15:36 |
| nigelb | thanks Laney | 15:36 |
| nigelb | persia: i'm building from a bzr branch, so gimme 5 minutes to uncommit and set things right again | 15:37 |
| persia | nigelb: No rush, and I'm certainly not the only person to talk to about this. It's better to ask questions generally (especially because you're working in a language I don't know, on a package I don't use, and with a build tool I don't use :) | 15:39 |
| nigelb | lol | 15:39 |
| nigelb | okay | 15:39 |
| sebner | persia: what is meant with "MOTU-Debian liason"? | 15:40 |
| persia | sebner: Ask Laney | 15:40 |
| Laney | undefined | 15:40 |
| sebner | @Laney | 15:40 |
| persia | heh. | 15:40 |
| sebner | hrm | 15:40 |
| sebner | you both agree and don't know what it is about xD | 15:40 |
| persia | The DCT (Debian Coordination Team) used to be around. I think beuno was in charge of it last. | 15:40 |
| Laney | We have some DDs who are also MOTUs. They could be useful somehow ;) | 15:41 |
| persia | We both have loose definitions. The general idea is that we ought be tracking what we do more carefully, and ensuring that anything not specific to Ubuntu gets back to Debian. | 15:41 |
| persia | *especially* for unseeded packages, because any differential left over is something we have to fix. | 15:41 |
| persia | The second phase of the master plan would be to try to convince teams that insist a package must be changed for some reason add the package to their package set :) | 15:42 |
| sebner | Ah, understood :) | 15:42 |
| persia | (so, for example, everything affected by iceweasel/firefox ends up being mozillateam) | 15:42 |
| Laney | Will Maintainer: be changing to reflect package set ownership? | 15:43 |
| persia | THat way MOTU might end up with time to do things like try to get the archive conflict-correct, or debcheck clean or lintian clean, or entirely recompiled to use the security flags or other such things. | 15:43 |
| Laney | Might be tricky when packages are in more than one... | 15:43 |
| persia | Laney: There's already packages like that. They end up with both teams having upload access unless the archive-admins decide they are "core", and then it's only core-dev. | 15:44 |
| Laney | Does the maintainer field change? | 15:44 |
| Laney | So for one of these mozilla packages, it would be clear who is responsible for it | 15:44 |
| persia | But I think that the Maintainer: change to "Ubuntu Developers <ubuntu-devel-discuss>" for everything was supposed to mask the messiness from end-users. | 15:44 |
| sebner | persia: so, also core-dev remains or will it change to "Generalist Uploader" some time in the future? | 15:44 |
| Laney | I see it becoming very hard to get core-dev access | 15:45 |
| persia | sebner: I don't have a strong feeling on the terminology to be used in the future. I know at least some core devs are very attached to the identity as "Ubuntu Core Developer", and that the central package set is named "core", so I don't expect it to go away. | 15:45 |
| persia | (or at least not without protest) | 15:45 |
| persia | But that's just me guessing :) | 15:45 |
| sebner | persia: kk, I was just unsure about it :) | 15:46 |
| sebner | Laney: ack | 15:46 |
| nigelb | I see the line "cp: cannot stat `debian/tmp/debian/source_rhythmbox.py': No such file or directory" does that mean the file was not compied to the tmp? Is that default or should I add the command to do so? | 15:46 |
| === hannesw__ is now known as hannesw | ||
| persia | sebner: I'm not an authority on this: I just read the mails that go around, am subscribed to the wiki page, and attend the relevant meetings. | 15:48 |
| persia | sebner: If you have an opinion on the matter, please express it in the appropriate fora (ubuntu-devel list, or TB meetings, usually). | 15:49 |
| persia | If you don't,, you have access to all the same information as I about it :) | 15:49 |
| sebner | persia: I didn't attend the meetings but I also read the mails and the wiki page and the name popped up so I'm not uninformed ( ;) ) it's just confusing because everyone says something different it seems | 15:50 |
| nigelb | also, is the right way to install an apport hook to put in .install or rules? I pulled 2 sources and both of them did it differntly | 15:50 |
| sebner | Laney: I'm wondering how your "raise the barrier for REVU" could work. I'm also thinking/writing about that topic currently | 15:51 |
| persia | sebner: That's because it's still being debated. If consensus were easy, we would have had Archive Reorganisation done in Intrepid :) | 15:52 |
| persia | (or maybe even Hardy) | 15:52 |
| sebner | persia: heh, kk (though Archive-Reorg should slowly be finished the next months) | 15:54 |
| Laney | sebner: I was trying to argue two points — that we present an expectation of packages being reviewed that we have no hope of meeting, and that a lot of the packages which do get through end up not being maintained. So I was proposing to introduce more accountability, although my ideas were more rough thoughts. | 15:54 |
| persia | sebner: I think it will take a couple more releases. We're *really* close on ArchiveReorg/Permissions (just need to sort out "core-dev" and some lingering LP stuff). | 15:55 |
| persia | But ArchiveReorg/Components still needs a lot of work. | 15:55 |
| Laney | It seems like packaging new stuff is a common thing that people want to do, but it's really the wrong way to get started. | 15:55 |
| sebner | aye | 15:55 |
| sebner | to both :D | 15:55 |
| persia | I think our documentaiton is to blame. | 15:57 |
| persia | We point people to GettingStarted rather than to Contributing | 15:57 |
| persia | And GettingStarted talks about learning packaging. | 15:57 |
| kmdm | Hey guys, quick question if I may... taking postgresql-8.4 as an example it depends on postgresql-common (>= 98~) what does the ~ mean in that context? :) | 15:58 |
| persia | I'd rather tell all the new folk to go work in bugsquad, and if they think they can fix bugs, ask for help or guidance doing so. | 15:58 |
| Laney | I'm not sure... I think a lot of it is people wanting to package some cool piece of software, or making vanity packages. | 15:58 |
| Laney | I think if we raise the barrier and send people off to Debian then most people won't bother, and the quality of the packages that do make it will be better. | 15:59 |
| persia | kmdm: ~ is a special character in versions that sorts before nothing: that notation is usually added to allow backports to fulfill the requirement. | 15:59 |
| persia | I don't like raising the barrier because it makes it more complicated in other areas. | 15:59 |
| persia | While I am MOTU, I also wear other hats, and some of the teams in which I participate have reasons they want or need new packages to meet release goals. | 16:00 |
| Laney | right, I'm talking about MOTU here | 16:00 |
| persia | Sometimes those packages aren't entirely perfect by FeatureFreeze, but as they will be getting additional bugfix work for the rest of the cycle, this is less important. | 16:00 |
| kmdm | persia: Gah, so it is. I've never seen it trailing with nothing following it... (and I've used ~blah) alot *sigh* Thanks ;) | 16:00 |
| persia | Laney: I'd be perfectly happy to say that no new packages should be uploaded for MOTU alone :) | 16:01 |
| Laney | maybe a "New Package Exception" process for MOTU | 16:01 |
| persia | The entire *point* of the new definition of MOTU is that we care for packages that are not maintained. Having someone want to maintain them automatically exludes them from our purview. | 16:01 |
| persia | That said, I think we happen to have some expertise with all the different ways things can go wrong in packages :) So we're probably good reviewers. | 16:02 |
| persia | But that's part of why I don't think NEW package review belongs to MOTU. it should be centralised. | 16:02 |
| persia | Those of us who like doing it can still partifipate, but it doesn't feel like a MOTU function to me. | 16:02 |
| Laney | It's really not. Packages destined for a seed will usually be fine, as there is a designated set of maintainers to be poked. | 16:03 |
| * persia will still review stuff, as it's a fun way to spend a few hours every once in a while, but just doesn't expect to wear a MOTU hat whilst doing so. | 16:03 | |
| persia | And vanity packages are fine, if the vain person is a developer. | 16:04 |
| directhex | i think once the dust settles, i might be better placed not as a motu, but as someone with upload rights to all my crap | 16:04 |
| persia | That's a perk I can live with (because we can poke them). | 16:04 |
| directhex | "my" being a blanket term here | 16:04 |
| persia | directhex: Yes, but realise that this does *not* grant you exclusivity. We have no maintainers, and we're not growing any. | 16:04 |
| Laney | what do you think to the New Package Exception process then? For packages not going into any set. | 16:04 |
| directhex | persia, i don't expect exclusivity. teams are vital to ubuntu | 16:05 |
| Laney | You'd have to explain why it can't go to Debian, commit to maintaining, ... | 16:05 |
| directhex | persia, lone maintainers are debian's biggest problem | 16:05 |
| persia | Laney: I think that they just get mostly ignored, and we document that they can be expected to be ignored, and that those wishing to get their software into Ubuntu would do best to get it into Debian | 16:05 |
| persia | directhex: Yes, but even teams in Ubuntu don't have exclusivity. | 16:05 |
| Laney | we already do say that... | 16:06 |
| persia | directhex: Ubuntu permissions are all overlapping sets. | 16:06 |
| directhex | persia, true, but there's some expectations & etiquette | 16:06 |
| persia | Laney: Right, so let's just say it more, and update the NewPackages page to emphasise it. | 16:06 |
| persia | Laney: but I really think that there ought be a distro-wide team that thinks about this, to set some language that works for everyone, rather than making it too restrictive because MOTU doesn't want more junk. | 16:07 |
| persia | directhex: You just haven't been hit by an NBS swipe or security rebuild or ABI transition yet if you think that :) | 16:07 |
| persia | (and if you're nimble enough, you may be able to preserve the illusion) | 16:08 |
| directhex | persia, you didn't notice libgnome2.24-cil and all that fallout? ;) | 16:10 |
| Laney | directhex and sebner: Do you think a set for our stuff is a good idea? | 16:13 |
| alkisg | How do I depend on "web java plugin"? icedtea6-plugin doesn't exist on hardy... | 16:13 |
| Laney | set/sets | 16:13 |
| persia | directhex: You mean 2.24.1-6ubuntu1 or an earlier case? | 16:13 |
| persia | But that only underscores that there's no exclusivity :) | 16:13 |
| directhex | Laney, yes, but what's the crossover with stuff in the main distro? i haven't been paying close attention to the reorg stuff | 16:14 |
| sebner | Laney: we do everything regarding CLI in Debian and Ubuntu anyways so yes | 16:14 |
| Laney | tomboy and f-spot and deps will be also in the desktop set | 16:14 |
| persia | directhex: main/universe is unimportant from a packageset perspective (which makes sense). | 16:14 |
| Laney | I guess we will be allowed to touch them too, unless someone moans | 16:14 |
| directhex | persia, i mean from a "can directhex upload tomboy" perspective | 16:15 |
| persia | You can certainly ask. I suspect you'll end up with join responsibility. | 16:15 |
| Laney | dunno if it makes sense to follow the Debian structure | 16:15 |
| Laney | -mono -apps -libs | 16:15 |
| persia | directhex: That's up to the TB, not me :) But if the TB approves the concept of that package set, and outlines a set of criteria for being able to upload to it, and it includes tomboy, and you're a charter member, then you'd be able to upload tomboy. | 16:16 |
| persia | Laney: No. It makes sense to have *one* packageset for that stuff. The same people in Ubuntu are interested in all three. | 16:16 |
| * directhex signs form 2547(b) in triplicate | 16:16 | |
| directhex | Laney, i agree with persia | 16:16 |
| persia | Laney: You can break it up later if you need to because of social breakdown within the team. | 16:16 |
| Laney | sure | 16:16 |
| Laney | just puttin' it out there | 16:16 |
| persia | But social breakdown is precisely what we seek to avoid :) | 16:17 |
| directhex | IMHO free beer would help solve social breakdown | 16:18 |
| persia | directhex: You're offering? | 16:19 |
| directhex | nah, that's canonical's role! | 16:19 |
| kmdm | Don't suppose anyone can have a quick glance at http://www.pastebin.com/m2203de1e and tell me why when trying to install postgresql-7.4 from dapper onto karmic it thinks postgresql-common is not going to be installed yet apt-cache policy and infact installing that package look/work fine... :| | 16:19 |
| directhex | kmdm, what does apt-get install postgresql-common say? | 16:19 |
| kmdm | directhex: it installs and works fine... | 16:20 |
| kmdm | which is hence my confusion (although I know I'm doing something silly somewhere ;)) | 16:21 |
| nigelb | I copied an apport hook to debian folder and added a line "debian/source_rhythmbox.py usr/share/apport/package-hooks" in rhythmbox.install and pbuiler gives me the error http://pastebin.com/d228e0a6f I'm inside the pbuilder chroot, can someone help me figure out what went wrong? | 16:22 |
| Laney | pastebin "ls debian/" please | 16:23 |
| nigelb | http://pastebin.com/d17b29931 | 16:24 |
| Laney | huh, it is there | 16:26 |
| Laney | nigelb: can I see the install file? | 16:27 |
| nigelb | oh wait, you want that from inside chroot? | 16:27 |
| Laney | would be good | 16:27 |
| Laney | maybe you forgot to bzr add it | 16:27 |
| Laney | ;) | 16:27 |
| nigelb | oh oh | 16:27 |
| * nigelb headdesks | 16:28 | |
| nigelb | I did forget the bzr add | 16:28 |
| Laney | one of the gotchas of vcs packaging | 16:29 |
| Laney | been there, done that | 16:29 |
| nigelb | been doing this for past 1 hour | 16:29 |
| nigelb | ugh! | 16:29 |
| Laney | I'd like to say "at least you won't do that again", but ... | 16:29 |
| Laney | at least you'll remember to check this | 16:30 |
| nigelb | yea :) | 16:30 |
| nigelb | Laney: is there a wiki for vcs packaging? (if not, there should be!) | 16:30 |
| Laney | I dunno, I think my knowledge is kinda cobbled together | 16:30 |
| Laney | the docs for bzr-buildpackage are probably what you want | 16:31 |
| nigelb | (i'm using irc logs for vcs packing) | 16:31 |
| nigelb | but the docs include all the gotcha's ? ;) | 16:31 |
| Laney | it might be called bzr-builddeb | 16:31 |
| nigelb | yea, I looked into it earlier | 16:31 |
| sebner | directhex: free beer! *ACKed* | 16:34 |
| directhex | anyone know where UDS for murderous mongoose is gonna be? :p | 16:35 |
| nigelb | directhex: on the eu side of the pond i guess ;) | 16:36 |
| sebner | directhex: monkey! | 16:36 |
| jdong | directhex: can't we just bring banshee and tomboy back by default and call it monogamous monkey or something? | 16:36 |
| jdong | *ducks* | 16:37 |
| sebner | Laney: I sent my thoughts but it turned out a lot worse than I thought ¬_¬ | 16:37 |
| * sebner ^5 jdong for the monkey! | 16:37 | |
| jdong | :) | 16:37 |
| directhex | jdong, wait, "back"? tomboy's not in anymore? | 16:37 |
| jdong | directhex: oh I wasn't sure about that. I thought mono was kicked out due to CD space. never mind then :) | 16:38 |
| Laney | haha | 16:38 |
| jdong | directhex: FWIW there's plenty of mono on all my installs ;-) | 16:38 |
| Laney | now that would be a shock | 16:38 |
| directhex | jdong, mono's never been a disk space issue. infact lucid has 50% more mono apps than karmic | 16:38 |
| jdong | directhex: ah, cool. What's the new mono apps? | 16:38 |
| directhex | jdong, gbrainy | 16:38 |
| jdong | *nods* | 16:38 |
| * jdong feels borderline daring enough to upgrade this thing to lucid :) | 16:39 | |
| Laney | O_O | 16:39 |
| * Laney just saw that gbrainy is on ubuntu5 | 16:39 | |
| directhex | jdong, boot speed is incredible, but dunno if that applies to upgrades or fresh | 16:39 |
| jdong | directhex: yeah on radeonhd bootspeed was WHOA. | 16:39 |
| directhex | Laney, yeah, welcome to the ubuntu-default-apps land | 16:39 |
| jdong | mostly thanks to the lack of silly flickering | 16:39 |
| jdong | directhex: the problem is all the other lil hardware regressions to chase down.... | 16:40 |
| Laney | we managed to keep f-spot synced! | 16:40 |
| * sebner throws f-spot at jdong | 16:40 | |
| jdong | :) | 16:40 |
| kmdm | directhex: FYI... just noticed a Conflicts: postgresql-7.4 in postgresql-common, so that'd explain it ;-) | 16:40 |
| Laney | aptitude why-not might have told you that | 16:41 |
| directhex | i didn't know about why-not o_o | 16:44 |
| * sebner uses apt-get ftw! | 16:44 | |
| Laney | learn sumfink new | 16:46 |
| jdong | wow..... | 16:47 |
| jdong | avahi-daemon CHEWS CPU pretty badly when it sees upsetting network traffic. | 16:47 |
| kmdm | Laney: it does... thanks... I shall have to remember that command ;) | 16:48 |
| nigelb | Laney: it worked. Thanks for the big help in figuring out the small error ;) | 16:50 |
| Laney | no probs | 16:50 |
| arand | A bit confused regarding parted_1.8.8.git.2009.06.03.orig.tar.gz This is very far from what I get from a "git clone http://git.debian.org/git/parted/parted.git", (??) | 17:01 |
| persia | arand: Have you tried using pristine tar on that git branch? | 17:05 |
| hyperair | git buildpackage --git-pristine-tar | 17:06 |
| persia | arand: Also, you might want to ask in #ubuntu-installer, as those folk may have closer familiarity with that package | 17:06 |
| arand | hyperair: git doesn't seem to like "buildpackage" is that some separate packae I need to get? | 17:08 |
| hyperair | arand: yes. you need git-buildpackage | 17:08 |
| Laney | git-buildpackage | 17:09 |
| Laney | no space | 17:09 |
| arand | right | 17:09 |
| Laney | oh, that does work too(!) | 17:09 |
| hyperair | =) | 17:09 |
| hyperair | git automatically checks your PATH for git-<command> | 17:09 |
| Laney | git-<tab> 4eva | 17:09 |
| hyperair | git <tab> also works well | 17:09 |
| persia | That's a very amusing implementation. | 17:10 |
| hyperair | if you have bash-completion | 17:10 |
| persia | Or zsh completion or any completion, really (so long as it handles git) | 17:10 |
| sebner | git is _that_ cool :) | 17:10 |
| hyperair | ^_^ | 17:10 |
| hyperair | well git-core has /etc/bash_completion.d/git | 17:11 |
| hyperair | but not anything for zsh or anything | 17:11 |
| hyperair | so i don't support it'll be supported out of the box =\ | 17:11 |
| Laney | wfm | 17:11 |
| arand | git-* is unfortunately not in ubuntu e.g. git-clone doesn't exist, it's only git that's available (in path?) | 17:11 |
| Laney | zsh comes with git completion | 17:11 |
| hyperair | arand: you could add /usr/lib/git-core to PATH. | 17:12 |
| hyperair | Laney: even the space one? | 17:12 |
| Laney | the space what? | 17:12 |
| hyperair | git<space><tab> | 17:12 |
| Laney | yes, especially that | 17:13 |
| hyperair | hmm cool | 17:13 |
| hyperair | but i suppose packages can't extend zsh's completion? | 17:13 |
| Laney | http://orangesquash.org.uk/~laney/gitzsh.png | 17:14 |
| jpds | hyperair: They can. | 17:15 |
| * Laney is still using jpds's zshrc (substantially) :) | 17:16 | |
| arand | Hmm, seems like I need a debian/ for git-buildpackage... more confusiong (the cloned git obviously has no debian/, and the apt-get sourced "is not a git repository")... | 17:16 |
| persia | arand: Check which branches are available. debian/ is often in a separate branch. | 17:20 |
| * persia doesn't know the commands to find this out, but has read that somewhere | 17:20 | |
| Laney | git branch -a | 17:20 |
| kamalmostafa | hi motu's: please force a retry-build for: https://launchpad.net/ubuntu/+source/libticalcs/1.1.3+dfsg1-1ubuntu1 (its missing builddep has landed) | 17:21 |
| Laney | launchpad will do that automatically | 17:22 |
| randomaction | yep, it's a depwait | 17:22 |
| kamalmostafa | oh, i didn't realize that -- when will LP "realize" that its ready? | 17:22 |
| persia | Well, sometimes LP gets confused. If it still hasn't happened after about 4 hours, get someone to press the button. | 17:23 |
| arand | Laney: there's remotes/origin/stable-1.8.x but no debian.. | 17:23 |
| sistpoty|work | kamalmostafa: already pressed the button | 17:24 |
| kamalmostafa | the thing its waiting for (libtifiles-dev) has been ready for 10 hours now | 17:24 |
| persia | But the delay is usually build -> accepted, then a publisher run (this is 43-108 minutes, depending), and then a mirror pulse (maybe a couple of minutes), and then LP running a job (maybe another couple of minutes), and the DEPWAIT build going back into queue. | 17:24 |
| kamalmostafa | sispoty: thanks | 17:24 |
| Laney | I don't know how often LP tries to break depwaits | 17:24 |
| persia | Yeah, at 10 hours, pressing the button is the right thing to do. | 17:24 |
| * sistpoty|work actually just wanted to press the button since it's existence :) | 17:25 | |
| kamalmostafa | sispoty: glad I could be of service! ;-) | 17:25 |
| sistpoty|work | :) | 17:25 |
| persia | sistpoty|work: You've never previously done a give-back? It's most rewarding, isn't it? | 17:26 |
| sistpoty|work | persia: I think I actually once press it, but only for a selected architecture | 17:27 |
| sistpoty|work | persia: any yes, it's cool :) | 17:27 |
| kamalmostafa | can anyone point me to a recent "remove this package" bug -- I'd like to see what one looks like before filing mine. | 17:30 |
| Laney | Please remove xxx from yyy | 17:32 |
| Laney | <reasons> | 17:32 |
| Laney | <why the rdeps are going to be alright> | 17:32 |
| randomaction | bug 525408 | 17:32 |
| ubottu | Launchpad bug 525408 in numerix "[OCaml 3.11.2 transition][round 2/6] Please remove numerix from Ubuntu" [Undecided,Fix released] https://launchpad.net/bugs/525408 | 17:32 |
| kamalmostafa | Laney, randomaction: thank you | 17:32 |
| randomaction | a perfect bug would also say "remove source and binary package" | 17:32 |
| Laney | really? | 17:33 |
| sistpoty|work | kamalmostafa: libtifiles-dev is in binary new (https://launchpad.net/ubuntu/lucid/+queue), so an archive will need to denew it first | 17:34 |
| sistpoty|work | so I clicked the button all in vain *g* | 17:34 |
| kamalmostafa | sistpoty, persia: hmmm -- libticalcs for powerpc just failed ... oh you noticed too | 17:34 |
| kamalmostafa | sistpoty: but just think... once they "denew it" (whatever the heck that means!) you'll get to push the button for me *again*! :-) | 17:35 |
| randomaction | here's the guide: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing%20Packages | 17:35 |
| persia | Depends on the timing. If you fail to notice for a couple hours, LP might just do it anyway. | 17:35 |
| Laney | or alternatively, that explains why it didn't get de-depwaited | 17:35 |
| persia | Indeed. 10 hours is awfully long for the usual class of LP delay. | 17:36 |
| kamalmostafa | randomaction: thanks for the pointer. time for me to go read all of wiki.../UbuntuDevelopment/... from start to finish again. | 17:37 |
| persia | kamalmostafa: Don't worry. We only update it a few times a week, so there's a chance you can keep up :) | 17:38 |
| * sistpoty|work heads home... cya | 17:45 | |
| james_w | who was involved in the review and upload of squeak? | 18:02 |
| james_w | highvoltage: I see you were, have a few minutes to discuss it? | 18:03 |
| james_w | I mean scratch, not squeak | 18:05 |
| highvoltage | james_w: yes, I'm around | 18:16 |
| james_w | hi | 18:17 |
| james_w | first off, why multiverse? | 18:17 |
| persia | upstream requested that, because of bundled binaries. | 18:17 |
| james_w | yeah, that's my second question | 18:18 |
| highvoltage | james_w: I remember asking lightning that exact question and he explained something about the bundled binaries that made a lot of sense at the time, I'll try to summon him here... | 18:18 |
| james_w | highvoltage: also, did you have a freeze exception for this? | 18:25 |
| james_w | stgraber: is mirrorkit any different from ubumirror? | 18:26 |
| c_korn | revu down ? http://downforeveryoneorjustme.com/http://revu.ubuntuwire.com/ | 18:34 |
| c_korn | hm, now it works | 18:34 |
| stgraber | james_w: it seems similar though it's not actually reinventing the wheel, it's just a simpler way of managing debmirror and generating reports out of it | 18:49 |
| stgraber | james_w: you can see it as an abstraction layer on top of debmirror | 18:49 |
| stgraber | james_w: we got asked by mvo to push it to archive after we used it for years here at Revolution Linux (but never really took the time to package it) | 18:50 |
| james_w | so the difference from ubumirror would be that it generates reports, but doesn't mirror cdimage etc? | 18:51 |
| stgraber | right | 18:51 |
| stgraber | it also lets you setup a "transparent" proxy quite easily, if the files are in the mirror, it'll use it, if not, it'll use archive.ubuntu.com directly | 18:52 |
| stgraber | here we simply override archive.ubuntu.com with it and setup it to mirror the most used distro and architecture | 18:52 |
| arand | Laney persia hyperair: Thanks for the help earlier! Seems like the core cause was that the debian version git repo does a lot of fluff compared to the original parted, in addition to lagging behind a year or so.. | 18:54 |
| highvoltage | james_w: slangasek said that FF didn't apply until it's in the topic, so we were going to try to slip it in, I'm not sure where to contact lightnin at this moment, but I'll write a FFE and give you a ping if that is ok? | 18:55 |
| slangasek | beg pardon? I never said anything about the topic | 18:55 |
| * highvoltage checks logs to check whether he's imagining things | 18:55 | |
| slangasek | until it's /announced/; but it's announced on ubuntu-devel-announce | 18:56 |
| highvoltage | slangasek: it was probably someone else who mentioned the topic then, sorry! | 18:57 |
| highvoltage | 02:02 < sebner> persia: nahh!" As long as the topic isn't changed we are free to upload :P | 18:58 |
| highvoltage | ok at least I'm not completely demented :) | 18:59 |
| highvoltage | (it was way past my bedtime so that's my official excuse) | 18:59 |
| * Laney would take that with a bucket of salt | 18:59 | |
| slangasek | ah; sebner seems to be an unreliable source ;) | 18:59 |
| highvoltage | yes looking at it now I see it's clear that he was joking. at 2am things are a bit more warped | 19:00 |
| * sebner hides | 19:01 | |
| sebner | slangasek: I forgot to add "When slangasek sends out the stop mail" :) | 19:01 |
| sebner | highvoltage: I'm sorry :( | 19:01 |
| highvoltage | sebner: heh, it's not your fault | 19:05 |
| sebner | highvoltage: next time I'll add more smilies ... I promise! :D | 19:06 |
| highvoltage | sebner: and I'll read more carefully! | 19:07 |
| sebner | highvoltage: heh :) | 19:11 |
| james_w | highvoltage: I'll reject for now, if you get an FFe and my questions are answered you can easily re-upload | 19:21 |
| fabounet | Hi BlackZ, are you here ? | 19:24 |
| randomaction | How are component mismatches dealt with? E.g. libtest-script-perl (in main) build-depends on libprobe-perl-perl (in universe) and can't be built. | 19:56 |
| persia | randomaction: Either an MIR or a demotion bug. | 19:57 |
| persia | Check why libtest-script-perl is in main. | 19:57 |
| persia | Note that if libprobe-perl-perl source is in main, moving the binary is just a matter of nudging an archive-admin. | 19:57 |
| randomaction | How do you know it's in main? | 20:00 |
| persia | I don't, but rmadison does. | 20:00 |
| randomaction | my rmadison says that libprobe-perl-perl source is in universe | 20:01 |
| persia | One option is `rmadison $(apt-cache showsrc ${PACKAGE} | grep ^Package | cut -d\ -f2)` | 20:01 |
| persia | That needs an MIR or demotion bug then. | 20:02 |
| persia | Once in a while one finds a binary in universe with a source in main (because binaries are promoted only if needed), and can just nudge someone. | 20:02 |
| randomaction | Ah, I didn't see the "if" in one of your sentences :) | 20:03 |
| persia | Aha! Now your comment makes more sense :) | 20:03 |
| randomaction | Is there a tool to find out why a package is in main? (Like, it's a dependency of package X, which is seeded) | 20:04 |
| randomaction | And, on a related note, is there a tool to find which package sets a package belongs to? | 20:04 |
| \sh | RoAkSoAx: see comment on your post | 20:06 |
| Laney | edit_acl.py in lp:ubuntu-archive-tools | 20:06 |
| Laney | randomaction: ^^^ | 20:06 |
| \sh | RoAkSoAx: + integrating pacemaker into puppet for easy junior sysadm setup ;) | 20:06 |
| RoAkSoAx | \sh, :) | 20:07 |
| RoAkSoAx | \sh, well the thing now is migrating to pacemaker/openais or pacemaker/heartbeat ? | 20:07 |
| \sh | RoAkSoAx: from hb1/hb2 to pacemaker/openais | 20:08 |
| james_w | randomaction: for why a package is in main, check http://people.canonical.com/~ubuntu-archive/germinate-output/ though it's not the easiest thing to read | 20:08 |
| randomaction | Laney, james_w: thanks | 20:08 |
| \sh | RoAkSoAx: one of the setups we are talking about is hb1+ldir -> http://shermann.name/content/network-setup-freaks-me-out ;) | 20:09 |
| randomaction | Though I assume that packages in main which failed to build will receive some attention closer to the release. | 20:09 |
| RoAkSoAx | \sh, right, that's the plan for the Ubuntu CLuster Stack, to be able to provide that upgrade path, however, Linbit guys took the lead of Heartbeat for all of those who still want to stay in Hearbeat but use pacemaker as CRM instead of pacemaker/openais | 20:10 |
| RoAkSoAx | \sh, and for the Ubuntu Cluster Stack we decided to go for keepalived+ipvsadm for loadbalancing since, keepalived is much faster to failover | 20:10 |
| RoAkSoAx | however, I wanted to test pacemaker with ldirectord for loadbalancing | 20:11 |
| RoAkSoAx | and see how it goes :) | 20:11 |
| RoAkSoAx | scary network setup btw :) | 20:11 |
| \sh | RoAkSoAx: well, as we are dealing with ubuntu here, we decided to go the hard way :) we are running right now on jaunty (because of some nice tomcat6 packages), we will leave karmic out (because of the well known upstart + ifupdown problem) and will redeploy our production setup via FAI with zero downtime ;) | 20:12 |
| \sh | which will give me a heluva work but gives me 5 years of peace and enjoyment ;) | 20:13 |
| \sh | RoAkSoAx: fun part about this network setup...it worked out of the box in jaunty...in contrast to hardy ;) | 20:13 |
| RoAkSoAx | cool | 20:15 |
| RoAkSoAx | anyways, I guess I'll start testing ipvsadm in both pacemaker/openais and pacemaker/heartbeat to let people know their upgrade options | 20:16 |
| \sh | RoAkSoAx: ping me when you have some more insights :) | 20:16 |
| RoAkSoAx | RoAkSoAx, will do ;) | 20:16 |
| \sh | now it's time to go home...14 hours again | 20:19 |
| === Pricey_ is now known as Pricey | ||
| === azeem_ is now known as azeem | ||
| arand | When I've used dpatch-edit-patch, do I still need to manually add it to the 00list file? | 21:41 |
| persia | I think I remember having to do that before, yes. | 21:42 |
| persia | But try it and see :) | 21:43 |
| arand | So if nothing showed up there but I got a *.dpatch file, I should be editing it? | 21:44 |
| persia | Right. | 21:44 |
| rhpot1991 | jdstrand: ping, I'd like to talk about the hdhomerun-config-gui package if you have the time | 22:01 |
| jdstrand | rhpot1991: sure | 22:04 |
| rhpot1991 | jdstrand: unfortunately upstream only hosts up the latest source there, and they released a new version after this package was uploaded | 22:04 |
| rhpot1991 | the new version does not add anything to the linux version so it was decided to just use the version that was tested | 22:05 |
| rhpot1991 | perhaps you can just compare with what is on revu? | 22:05 |
| jdstrand | rhpot1991: well, I need to be able to verify the sum against the upstream source, to make sure nothing changed. can you update the package to use the new upstream tarball? did someone from REVU already review the sum? | 22:06 |
| rhpot1991 | jdstrand: fabricesp and superm1 ack'd it, you'd have to check with them to be sure | 22:10 |
| jdstrand | superm1: ^ did either of you verify the sums on the upstream source? | 22:12 |
| jdstrand | superm1: (for hdhomerun-config-gui) | 22:12 |
| rhpot1991 | jdstrand: I have the source here still, but cannot find it anywhere online | 22:15 |
| jdstrand | rhpot1991: right. I appreciate your dilemna, but as an archive admin I need to make sure the source is correct | 22:17 |
| rhpot1991 | jdstrand: what if I asked upstream if they could email it to you? | 22:17 |
| rhpot1991 | if they even still have a copy around | 22:17 |
| jdstrand | rhpot1991: well, if it was froma @silicondust.com I suppose I could. you said there were no changes in the new version with the old for linux-- can you just update your source package to use that instead? I was ready to accept it except for this issue | 22:20 |
| jdstrand | rhpot1991: if you update the source package, please test it a bit to be sure it is ok ;) | 22:20 |
| rhpot1991 | jdstrand: ok, I pinged someone upstream to see if thats an option, otherwise I'll upgrade the source | 22:30 |
| MTecknology | building packages gets messy on the system | 22:31 |
| jdstrand | rhpot1991: thanks | 22:32 |
| MTecknology | If I want to add a completely different section in a debain/rules file so I can keep my changes separate, is this ok? COMMON_CONFIG=$(COMMON_CONFIG) \ | 23:06 |
| MTecknology | quite today | 23:19 |
| MTecknology | quiet* | 23:19 |
| MTecknology | Any ideas what is wrong here? http://paste.ubuntu.com/381903/ | 23:21 |
| arand | I have this here pproblem when building virtualbox with pbuilder http://pastebin.ubuntu.com/381906/ (E: pbuilder-satisfydepends failed.) any idea s to cause/fix ? | 23:26 |
| christoph_debian | arand: try to only depend on packages that actually exist | 23:33 |
| arand | christoph_debian: this is virtualbox as I got it from apt-get source... What would I need to change? (and why is it "broken" from the beginning..?) | 23:35 |
| christoph_debian | probably some of the packages got removed | 23:36 |
| RAOF | arand: So, what release are you trying to build for, and do you have Universe enabled in the pbuilder? | 23:39 |
| arand | RAOF: trying for karmic, I don't know about the universe.. i would assume.. how to check that? | 23:40 |
| RAOF | arand: pbuilder login & check out /etc/apt/sources.list should do it. | 23:41 |
| arand | RAOF: Ok, that was it it seems, strange that I havent come across that issue before.. Cheers | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
