| === Noldorin_ is now known as Noldorin | ||
| sentix | Hello, for anyone that is awake, I was curious if launchpad is completely a Bream web app or mixed zope 2 and something else? | 03:01 |
|---|---|---|
| wgrant | sentix: Launchpad is based on ZTK plus a few other bits that used to make up Zope 3, but it doesn't use BlueBream. | 03:16 |
| wgrant | sentix: No Zope 2 at all. | 03:16 |
| sentix | wgrant: Not totally surprising but wikipedia claims launchpad uses Bream. Currently just wandering through the devel launchpad checkout to figure out how things work. | 03:18 |
| wgrant | sentix: I suspect that somebody went through Wikipedia and did s/Zope 3/BlueBream/ | 03:18 |
| wgrant | I suppose a few of the Zope3-but-not-ZTK libraries that we use may now be maintained mostly by the BlueBream people, but we're really not a BlueBream app. | 03:19 |
| === Handsalsa is now known as Guest41674 | ||
| === head_v is now known as head_victim | ||
| mirrakor | hi there, I wanted to upload a package but it is rejected because apparently I choose the wrong section ("education") is there a list of available sections? | 08:09 |
| jelmer | mirrakor: hi | 08:16 |
| jelmer | mirrakor: http://packages.ubuntu.com/precise/ | 08:16 |
| mirrakor | jelmer: it returns an empty page?! :/ | 09:04 |
| mirrakor | oh, hm.. in rekonq it doesn't | 09:05 |
| mirrakor | Can I ask questions about ppa's and the process of packaging in here too? | 09:20 |
| jelmer | mirrakor: PPA questions are fine, packaging questions are probably more appropriate for #ubuntu-packaging | 09:22 |
| mirrakor | when a build failed and I upload it again with added dependencies, do I have to restart the build process by hand? | 09:39 |
| mirrakor | hm.. ok, it get's rejected because one because the file already exists in <location> but uploaded version has different contents .. I updated the debian/control file and run debuild -S and then tried it again with dput | 09:45 |
| jelmer | mirrakor: you'll need to update the version in debian/changelog if you've changed the package | 09:58 |
| mirrakor | ah right, it's a debian system after all :D thanks for your help jelmer it really is appreciated :) | 09:59 |
| chrysn | i was just going through a recipe build log on launchpad and noticed it installs the whole build-depends, although it only needs to build a source package. | 11:33 |
| chrysn | would it be interesting from a launchpad point of view to have more fine-grained dependency descriptions in the debian/control file? | 11:33 |
| jelmer | chrysn: it needs all the build-depends since it runs ./debian/rules clean | 11:34 |
| chrysn | (debian policy mentions there was never a need for a Build-Depends-Arch at http://www.debian.org/doc/debian-policy/footnotes.html#f55, but building recipes could just make such a case) | 11:34 |
| jelmer | chrysn: that would indeed help, although another solution would be to build the binary package along with the source package | 11:35 |
| jelmer | chrysn: so the build dependnecies only get installed once | 11:35 |
| jelmer | (well, once per arch we build on of course) | 11:35 |
| chrysn | well, at least the -indep wouldn't have to be installed on every other arch | 11:37 |
| chrysn | is there a particular resaon this is now split in two steps? (not that i don't like having things cleanly split) | 11:37 |
| jelmer | chrysn: that doesn't happen anyway, as the source package only gets built on a single arch | 11:37 |
| jelmer | chrysn: I don't think building the source package and the binary package in one go would necessarily be unclean | 11:38 |
| jelmer | chrysn: the main reason it happens the way it does is because that's the simplest | 11:38 |
| chrysn | ok, thanks for the info. i'm not too deeply into the package building process myself, just noticed it and wanted to be sure launchpad people are aware of this, but not surprisingly, you already are :-) | 11:40 |
| jmehdi | Hi, I'm trying to copy packages in my ppa, and I get this error: OOPS-2129CF71 | 18:26 |
| ubot5 | https://lp-oops.canonical.com/oops.py/?oopsid=2129CF71 | 18:26 |
| lifeless | jmehdi: try copying less packages:( | 19:41 |
| lifeless | jmehdi: its a timeout in Archive:+copy-packages | 19:41 |
| jmehdi | lifeless: ok, thanks, it works | 20:04 |
| glen | hey, how to make random people doing invalid actions on bugs, like here: https://bugs.launchpad.net/eventum/+bug/825514 | 20:09 |
| ubot5 | Ubuntu bug 825514 in Eventum "little path error in check_permissions.php" [Low,In progress] | 20:09 |
| glen | i mean people who aren't part of the team shouldb't be able assign bugs to them | 20:09 |
| glen | user probably clicked some wrong button or something that he's not even aware of | 20:10 |
| tumbleweed | glen: I don't think you can, but I can't say I've ever noticed that being a problem. People don't tend to assign themselves bugs without reason. Generally the best thing tod o is to reply and say "assigning it to yourself means you intend to work on it" | 20:16 |
| tumbleweed | IIRC the first time you assign someone a bug in a project, it pops up a message saying "did you mean to do this?" | 20:17 |
| glen | well. i think, in this specific case, user thought "i have same problem" and clicked "assing to me" thinking it's same as "i have same problem". happens with very poor english knowledge :) | 20:19 |
| lifeless | glen: it happens, but fairly rarely. | 20:24 |
| lifeless | glen: locking it down would add a barrier to entry; its hard to say whats wrose | 20:25 |
| lifeless | bah, my fingers are broken this morning :) | 20:25 |
| lifeless | *worse* | 20:25 |
| lifeless | I believe bugzilla etc allow uesrs to assign to themselves | 20:26 |
| glen | it's that users first and only activity, no idea what is he up to :D | 20:26 |
| === Noldorin_ is now known as Noldorin | ||
| SqRt7744 | I'm in a bit of trouble, an open source project I'm working on hasn't been building on launchpad recently, and I'm at a bit of a loss as to why. It builds fine locally, and *used* to build on launchpad, up to version 0.7... the "failed to build" log is here, maybe someone could give me a pointer? https://launchpad.net/~prhone-gmail/+archive/zams-official/+build/2890389/+files/buildlog_ubuntu-oneiric-i386.zams_0.9-1ubuntu0_FAIL | 22:18 |
| SqRt7744 | EDTOBUILD.txt.gz | 22:18 |
| SqRt7744 | https://launchpad.net/~prhone-gmail/+archive/zams-official/+build/2890389/+files/buildlog_ubuntu-oneiric-i386.zams_0.9-1ubuntu0_FAILEDTOBUILD.txt.gz | 22:18 |
| wgrant | SqRt7744: The log suggests that there are x86_64 binaries in the source tarball. | 22:23 |
| * wgrant looks. | 22:23 | |
| wgrant | $ tar tf zams_0.9.orig.tar.gz | grep '\.o$' | wc -l | 22:24 |
| wgrant | 62 | 22:24 |
| wgrant | zams-0.9/zams/.obj/scrollarea.o | 22:24 |
| wgrant | zams-0.9/zams/.obj/gotodialog.o | 22:24 |
| wgrant | zams-0.9/zams/.obj/moc_updatenotifier.o | 22:24 |
| wgrant | zams-0.9/zams/.obj/moc_sqltreemodel.o | 22:24 |
| wgrant | etc. | 22:24 |
| wgrant | Those binaries should probably not be in a source tarball :) | 22:24 |
| geser | SqRt7744: your .orig.tar.gz is not clean, it contains compiled .o files (for amd64) which get reused on i386 instead of getting rebuild -> failure | 22:25 |
| SqRt7744 | ah ok, i was wondering about that. I'll look into this, thanks | 22:26 |
| SqRt7744 | is there anyway to reupload the same version? Usually if I try it gives me a message about the same version already being there and fails... | 22:26 |
| geser | not really, append something like "+repack1" to the upstream version | 22:29 |
| SqRt7744 | thanks for tips geser and wgrant | 22:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!