=== Ursinha is now known as Ursinha-afk
[01:25] <foresto> Hi, all. I'm trying to build a kernel module package that works fine on my local system, but on Launchpad's PPA builder the build scripts fail when checking for the current kernel's header files. Turns out that Build-Depends: linux-headers-generic causes the 2.6.38-8-generic package to be installed, but Launchpad's build server apparently runs kernel 2.6.24-29, so the build script fails. Suggestions, please?
[01:29] <wgrant> foresto: For kernel modules you probably want to look at dkms.
[01:30] <wgrant> foresto: They need to be rebuilt often for security updates, so external modules tend to ship source to users in packages, and then build them on the user's machine with dkms.
[01:31] <foresto> Actually, I already packaged it for dkms. The upstream script that unpacks the source and generates the Makefile (which dkms needs) still checks for header files that match the running kernel, though.
[01:32] <wgrant> Hmm. You'll have to patch that out, I suppose.
[01:32] <wgrant> It certainly can't be necessary.
[01:32] <foresto> I'm hoping not to have to patch the upstream scripts just to make this thing build on launchpad. It builds fine on my local machine and in pbuilder.
[01:33] <wgrant> We build for hardy->precise. We can't very well be switching kernels depending on which sort of build we're doing :)
[01:33] <wgrant> The upstream build scripts certainly can't correctly *require* matching headers at source build time.
[01:33] <foresto> How about installing the header files that match the running kernel, then?
[01:33] <foresto> I agree that the upstream script is stupid.
[01:34] <wgrant> There's no way to do that :(
[01:34] <wgrant> Possibly fortunate, since it discourages upstream stupidity like this :)
[01:34] <foresto> Heh... way to look on the bright side.
[01:35] <wgrant> That's one of the great things about distributions: they encourage upstreams to be sensible.
[01:35] <wgrant> To make their software practically buildable...
[01:36] <foresto> Of course, that assumes upstream listens or cares.
[01:36] <foresto> Which, in this case, they may not. I guess I'll see if I can find a receptive contact at Marvell.
[01:58] <wgrant> foresto: Ah, didn't realise it was that sort of package :(
[01:58] <wgrant> foresto: That's unfortunate.
[02:22] <CarlFK> "PPA exceeded 95 % of its size limit (2040.00 of 2048.00 MiB). Ask a question in https://answers.launchpad.net/soyuz/ if you need more space."
[02:23] <CarlFK> I don't need more space, I need to purge some extra files that accedently got uploaded
[02:23] <wgrant> CarlFK: Which files?
[02:23] <wgrant> Delete them and they should go away within an hour or so.
[02:24] <CarlFK> *.dv (doh)
[02:25] <wgrant> Hm? You can't upload such files directly.
[02:25] <wgrant> If they're contained in some other package, you'll need to delete and replace that package.
[02:26] <CarlFK> how do I delete anything?  I don't see a delete optoin on https://launchpad.net/~carlfk/+archive/ppa/+packages
[02:26] <wgrant> "Delete packages"
[02:26] <wgrant> Top right.
[02:27] <CarlFK> oh lookie there :)
=== jtv is now known as jtv-eat
[07:05] <odin_> it is possible to use: Build-Depends: foo (>= 2.4) [ubuntu-natty]  ?   what are the valid labels where "ubuntu-natty" is ?
[07:07] <wgrant> odin_: No. [] is for selecting architectures.
[07:07] <wgrant> eg. [i386] or [linux-any] or [kfreebsd-i386]
[07:10] <odin_> is there anyway to maintain a single debian/** tree but with different debian/control that is auto selected ?   like debian/control.ubuntu.oneiric
[07:10] <odin_> or maybe "m4" process it ?
[07:13] <odin_> maybe I can make the debian/control executable ?
[07:13] <odin_> and have it spit config on stdout ?
[07:15] <lifeless> is it possible? Yes. Is it debian policy compliant? Usuaully not.
[07:15] <lifeless> debian policy (and Ubuntu policy which tweaks that) is desirable because the policy encodes things that work well, give us reliable builds, avoid linking issues etc (it covers a wide range of things)
[07:16] <odin_> policy compliance isn't something I seek right now, as the term is meaningless to me
[07:16] <odin_> reliable builds isn't important either, if they were reliable there would not be a need for a package maintainer (a robot could do it)
[07:17] <lifeless> reliability isn't a boolean
[07:17] <odin_> the unreliability of a build system is due to other peoples changes
[07:17] <lifeless> if you want whatever you are packaging to be in Ubuntu, policy compliance is a requirement.
[07:18] <lifeless> odin_: thats an interesting assertion, but not one I agree with
[07:18] <odin_> not really PPA is fine, some other person can decide to take up the work if they want it to be in ubuntu, maybe someone who is paid to do it
[07:18] <micahg> odin_: you can make it so if you regenerate the control file, it changes the dependencies, you can't however have that done on the builders, you'd have to do that locally, alternatively, with recipies, you could have a separate branch for each series
[07:19] <odin_> yes the branching is a horrid way
[07:19] <lifeless> odin_: Ubuntu is mainly the result of volunteer work, so I'm not sure why paid would be relevant
[07:19] <odin_> I want a single tree, nice an simple that works for all versions, all important control files can be generated and fixed into source package
[07:20] <odin_> well I only have so much time to be concerned with ubuntu package management, I'm much more interested in doing other stuff in my life than this chose
[07:20] <odin_> *chore
[07:21] <odin_> I don't want to make new branch/config every time
[07:21] <odin_> I just need to switch in an out a few dependencies and it should build for every debian based system
=== jtv-eat is now known as jtv
[08:00] <odin_> everytime I call "bzr dailydeb ..." here the output files end up with another "~0~{revno}" added to them like  foobar_1.2.3~0~3080~0~3080~0~3080~0~3080
[08:02] <odin_> if I delete the output directory first I only get a single ~0~3080 on the end, but it causes a re-download of bzr data everytime
[08:27] <odin_> I have dependencies that don't seem to work, in oneiric there is   ant-contrib  1.0~b3+svn177-3  and I use "Build-Depends: ant-contrib (>= 1.0~b3)"
[08:27] <odin_> is there any reason why it is not able to be installed by pbuilder ?
[08:35] <maxb> That question is more on topic in #ubuntu-packaging than here, but in any case, "not able to be installed" is sufficiently vague that it's not possible to guess the problem
[08:36] <maxb> odin_: ^
[08:38] <odin_> I don't think it is "too vague" if I am using "pbuilder" its pretty obvious to anyone skilled in the art of debian package management that an installation problem relates to Build-Depends
[08:40] <odin_> even removing the version from the Build-Depends yields the same problem, yet on oneiric shell session "apt-get install ant-contrib" works fine, I have ~/.pbuilderrc set with COMPONENTS="main universe ..." and this package is from there
[08:40] <odin_> anyhow thanks for the tip on the other channel
[08:48] <lifeless> odin_: there are many ways an install can fail; unpack error; postinst error; conflict error; dep error; maintainer script error;
[08:49] <lifeless> odin_: presuming that we can determine which of those (some execute arbitrary code so can have any output at all) from the statement that it wasn't able to be installed is erroneous
[08:49] <wgrant> Download error, not existing error, erasing your filesystem error...
[08:50] <odin_> Depends: ant-contrib but it is not installable
[08:50] <odin_> apt-cache show ant-contrib  # looks good
[08:50] <micahg> odin_: is universe enabled?
[08:50] <odin_> I have ~/.pbuilderrc set with COMPONENTS="main universe ..."
[08:51] <odin_> other packages from universe are resolvable
[08:51] <odin_> like "ant" itself
[08:52] <odin_> no "ant" is not in universe
[08:52] <odin_> I have /home/user/.pbuilderrc set with COMPONENTS="main universe ..."
[08:52] <odin_> but I sudo for running pbuilder, is this a problem ?
[08:53] <odin_> does it need to be "export COMPONENTS="...."
[08:55] <odin_> I followed wiki  help.launchpad.net/Packaging/SourceBuilds/GettingStarted
[09:12] <odin_> is there no way to request Source only builds ?  or cancel queued builds ?
[09:14] <gnuoy> dpm, jtv, that translations export for oneiric seemed to complete successfully
[09:18] <odin_> ok I re did "pbuilder create" and it seems to work locally, I think there was a typo in the original .pbuilderrc at the time I ran "pbuilder create" the 1st time
[09:19] <Pegasus_RPG> Hello. How can I effect a 'bzr launchpad-logout' command and bind the branch back to the anonymous http variant?
[09:23] <Pegasus_RPG> nvm, I found %appdata%\Bazaar and deleted authentication.conf and bazaar.conf. That seems to have done the trick since I can now bzr bind http://blah.
[09:27] <jtv> gnuoy: thanks, glad to hear it
[09:53] <odin_> is there anyway to control the version number generation during the Source package building ?
[09:55] <odin_> how do I cancel a Pending Build ?
[09:56] <odin_> I would have thought such controls would be available (to save on resources)
[10:26] <bigjools> odin_: you can't cancel a build, although I am working on it
[10:27] <odin_> asking for "Source build only" would also be useful (to limit unnecessary builds), this places the binary builds in a needing manual start mode
=== jtv changed the topic of #launchpad to:  https://launchpad.net/ | Help contact: - | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support: https://answers.launchpad.net/launchpad
[11:56] <danhg> jsackett, are you around?
[11:57] <danhg> flascoste; are you here?
[11:57] <danhg> flacoste even...
[12:00] <soren> odin_: What do you mean by a source only build?
[12:02] <odin_> just the top level item to make the source package (but not automatically cascade to include binary packages that need it)
[12:08] <soren> odin_: So you want to be able to upload a source package and have the build infrastructure rebuild your source package?
[12:10] <odin_> yes to revalidate configuration across all releases
[12:11] <soren> "Revalidate configuration"
[12:11] <soren> ?
[12:11] <soren> What does that mean?
[12:11] <odin_> you modify information in debian/** for one release, test it, it works, upload it
[12:12] <odin_> have all ubuntu release rebuild with that change
[12:12] <odin_> but initially only the source package needs to be built
[12:12] <odin_> once all have green light, then think about binary releases for all
[12:13] <odin_> in short, better controls to limit the about of work the builders will do, while testing/checking/verifying configuration (of the builders)
[12:16] <odin_> s/about/amount/   my package already support windows/macos/linux, so supporting a few (like all 6 up on launchpad.net) releases of ubuntu should be a "piece of cake"
[12:17] <soren> What sort of stuff do you expect to catch by simply rebuilding the source package?
[12:21] <arand> Is there a scheduled maintenance of the buildds at the moment?
[12:22] <wgrant> There's an unscheduled interruption that should be sorted out in just a few minutes.
[12:23] <arand> Ok :)
[12:49] <james_w> I can't directly find out a user's openid identity URL can I?
[12:50] <bigjools> it's hidden IIRC
[12:50] <bigjools> but the user can find out on their page
[12:50] <wgrant> Anyone can get it.
[12:50] <wgrant> But it's only *shown* to the user.
[12:51] <wgrant> I don't think it's exposed through the API, but let me check.
[12:52] <wgrant> Indeed, not through the API. But you can extract it from the delegation information on https://launchpad.net/~someuser
[12:52] <wgrant> Or possibly from the XRDS.
[12:52] <james_w> aha, thanks
[12:52] <wgrant> eg.         <link rel="openid.delegate"
[12:52] <wgrant>               href="https://login.launchpad.net/+id/4tLsDY8" />
[12:52] <wgrant> The XRDS may be prettier to parse.
=== jtv is now known as jtv-eat
=== zyga is now known as zyga-afk
=== Ursinha-afk is now known as Ursinha
[13:26] <czajkowski> hmm no mrevell
[13:33] <flacoste> hi danhg
=== jtv-eat is now known as jtv
=== epsy is now known as \u03b5
=== yofel_ is now known as yofel
=== zyga-afk is now known as zyga
[15:33] <doko> https://code.launchpad.net/~ams-codesourcery/gcc-linaro/merge-from-fsf-gcc-4.6.2
[15:33] <doko> is there anything wrong with it? needs a few minutes, but pending since 2h?
[15:34] <odin_> soren, "What sort of stuff do you expect to catch by simply rebuilding the source package?" check that for each dependency is resolve and there is no issues with being able be ready to build binaries
=== beuno is now known as beuno-lunch
[16:27] <ahasenack> is there a way in the UI to list all bugs that have no milestone in a project?
[16:31] <ahasenack> ok, answer is no, found the bug: https://bugs.launchpad.net/launchpad/+bug/70709
[16:31] <ahasenack> quite old
[16:31] <ubot5> Ubuntu bug 70709 in Launchpad itself "Can't search for bugs with no assigned milestone" [High,Triaged]
[16:31]  * ahasenack subscribes to it
[16:35] <odin_> are are git imports managed ?  are they configurable by us ?  and where in launchpad might the controls be ?
[16:37] <roxdragon> hi all
[16:38] <roxdragon> i have a problem. I uploaded yesterday a source...
[16:39] <roxdragon> Today I deleted the source, but I always see the control panel compiled on hold
[16:40] <roxdragon> waiting
[16:40] <bigjools> roxdragon: it'll superseded it eventually
[16:40] <bigjools> supersede*
[16:41] <bigjools> odin_: do you have a particular branch in mind?
[16:41] <roxdragon> Rejected:
[16:41] <roxdragon> File arduinocontrol_0.1.tar.gz already exists in roxdragon, but uploaded version has different contents
[16:41] <bigjools> roxdragon: https://answers.launchpad.net/launchpad/+faq/990
[16:41] <roxdragon> in the repository dosen't exist any files
[16:42] <odin_> yes currently lp:~akoskm/qtjambi/trunk is some kind of alias to lp:~qtjambi-community/qtjambi/master
[16:43] <odin_> the user akoskm is the super-maintainer (or whatever you call it, owner) of the group "qtjambi-community"
[16:44] <odin_> and I trying to confirm that all things inside qtjambi-community are owned by the group account / project account
[16:45] <odin_> I have kind of changed (put in my input) on how the project is managed on ubuntu, as akoskm has done the best he can so far
[16:46] <odin_> the new configuration is much more simple (IMHO) I hope we have 1 pure GIT mirror [lp:~qtjambi-community/qtjambi/master]  (where no changes should ever be commited into bzr) and then we have 1 pure BZR tree [lp:~qtjambi-community/qtjambi/generic] (which contains the debian/** folder)
[16:47] <odin_> all changes to the main tree are patched from debian/** and the folder holds enough information to configure for any ubuntu version (maybe any debian based project version)
[16:48] <odin_> since we continue to re-release new versions even to old versions of Ubuntu, so Lucid, Maverick, etc...  continue to get updates
[16:49] <odin_> maybe lp:~akoskm/qtjambi/trunk  is a clone of lp:~qtjambi-community/qtjambi/master ?  I find it hard to understand via web UI
[16:50] <odin_> what I need to get to, is the project version for lp:~qtjambi-community/qtjambi/master would ideally be the last GIT "commit date" in UTC in the same format as {time}
[16:50] <roxdragon> we have a guide for building sorces for Launhpad?
[16:51] <bigjools> odin_: the ~akoskm/qtjambi/trunk branch is a personal branch for akoskm
[16:51] <bigjools> roxdragon: https://help.launchpad.net/Packaging/PPA/Uploading
[16:51] <odin_> bigjools, thanks for the clarification, so I don't need to worry about that, this is that users "sandbox" and won't affect the main project
[16:52] <bigjools> odin_: correct
[16:52] <bigjools> odin_: the way branches are structured is that you can attach them to a project, that is what he has done
[16:53] <bigjools> roxdragon: actually this is a better page https://help.launchpad.net/Packaging
[16:53] <roxdragon> thank u
[16:56] <odin_> how is the version set ?  {debupstream} I think is not set
[16:56] <odin_> and I'd like to revised it from the git commit date: date -u -d $(git log -n1 --pretty="@%ct") "+%Y%m%d%H%M%S"
[16:56] <bigjools> odin_: what version?
[16:56] <odin_> that might not be 100% but its close
[16:56] <odin_> 20110930161611
[16:57] <odin_> is the version only set in the comment line at the start if the recipe ?  no other way to derive it ?
[16:58] <bigjools> I don't know, recipes are not my forte.  Pop on to #bzr and ask for jelmer
[16:58] <odin_> ok thanks I ask there
[17:10] <roxdragon> this is my repo https://launchpad.net/~roxdragon/+archive/roxdragon
[17:10] <roxdragon> but need build?
[17:12] <arand> roxdragon: Look like it: https://launchpad.net/~roxdragon/+archive/roxdragon/+builds?build_text=&build_state=all
=== beuno-lunch is now known as beuno
[17:15] <roxdragon> Start in 9 hours O________O
[17:17] <roxdragon> arand, Build details
[17:17] <roxdragon> Source:
[17:17] <roxdragon> arduinocontrol - 0.1
[17:17] <roxdragon> i deleted...
[17:18] <roxdragon> version 0.1
=== epsy is now known as \u03b5
[17:49] <roxdragon> Currently 0 packages building and 2 packages waiting to build.
[17:49] <roxdragon> why? i deleted arduinocontro-0.1
[17:49] <roxdragon> but i have on my repo only 0.2
[17:49] <roxdragon> https://launchpad.net/~roxdragon/+archive/roxdragon
=== zyga is now known as zyga-afk
[18:26] <odin_> https://code.launchpad.net/~qtjambi-community/qtjambi/generic  "Stacked on: lp:qtjambi"  I did I init/add/commit/push incorrectly ?  I am thinking it is a standalone tree
[18:35] <soren> odin_: You shouldn't really be able to tell the difference. It's informational.
[19:45] <doko> lifeless, is there currently anything wrong with branch updates? https://code.launchpad.net/~ams-codesourcery/gcc-linaro/merge-from-fsf-gcc-4.6.2
[19:56] <lifeless> doko: Nothing seems wrong on that page
[19:56] <lifeless> doko: why do you ask ?
[20:11] <doko> lifeless: for six hours now, it says it will be available in a few minutes
[20:11] <lifeless> ah, ok. so it failed to scan.
[20:11] <lifeless> there is a bug about big branches doing htat - taking up too much memory
[20:11] <lifeless> try pushing to it again (no change, just a push)
[20:12] <doko> ok, I'll tell ams_cs
[20:46] <Kaleo> sinzui: ping
[20:46] <sinzui> Kaleo, hi
[20:46] <Kaleo> sinzui: thumper said to talk to you about private teams and branches
[20:46] <Kaleo> sinzui: does it work?
[20:46] <Kaleo> (these are his words ;))
[20:47] <sinzui> Kaleo, private teams may have private branches on projects they have been given a policy for
[20:48] <sinzui> Kaleo, this means that they cannot have private branches on a project they do not own or were not granted permission to work with
[20:48] <sinzui> the latter case implies that the team was also subscribed to that project's private branch which is probably private
[20:48] <Kaleo> sinzui: makes sense
[20:52] <TheEvilPhoenix> sinzui:  how do you get a private team/group if you know?
[20:52]  * TheEvilPhoenix was curious about them
[20:52] <sinzui> I do know how to create private teams
[20:55] <sinzui> TheEvilPhoenix, They are not very useful yet. We do not let them do things like subscribe to bug because that would permit them to spy on others.
[20:56] <sinzui> TheEvilPhoenix, private teams can get private archives and mailing lists. They can maintain projects, though that is awkward since Lp wants their name to be visible
[20:57] <sinzui> TheEvilPhoenix, We expect to solve the semi-public relationship issue in a few months so that they can be used in many places in Lp,only revealing the team's existence to users that need to know
[20:58] <TheEvilPhoenix> i see
[21:03] <sinzui> TheEvilPhoenix, sorry, I was distracted. We offer private teams with the purchase of a commercial subscription for a project
[21:03] <sinzui> We create new team most of the time because Lp will not permit the team to become private if it is in a public relationship
[21:12] <tmus> Hi there - Is it possible to delete a package from my ppa on launchpad? uploaded by mistake and it's not going to build/work properly...
[21:12] <tmus> it's not been built yet
[21:12] <bigjools> tmus: upload a newer version
[21:12] <TheEvilPhoenix> sinzui:  indeed.  that's what i thought.  :P
[21:13] <tmus> bigjools, is that all? I allready did that, but the /bad/ package looks like it's still going to be built
[21:14] <bigjools> tmus: no, it'll get superseded before then
[21:14] <tmus> bigjools, aah - that's good to know... Thanks a lot
[21:14] <bigjools> np
[21:15] <bigjools> for builds, they only get considered for superseding right at dispatch time
[21:15] <tmus> bigjools, makes sense - and already build packages are superseded more often?
[21:16] <bigjools> yep
[21:16] <tmus> first package - lots of details to figure out, the the documentation does a really good job... thanks again :-)
[21:17] <bigjools> thanks for the feedback!
=== zyga-afk is now known as zyga
[21:45] <GTRsdk> Is something wrong with Launchpad?
[21:49] <TheEvilPhoenix> GTRsdk:  how so?
[21:49] <TheEvilPhoenix> its working fine for me
[21:54] <GTRsdk> It looks like it wants me to change my password
[21:56] <sinzui> GTRsdk, launchpad does not have passwords. You may be seeing the Ubuntu SSO impersonating Lp
[21:57] <GTRsdk> sinzui: I am at https://login.launchpad.net/+edit and can't click on my name to get to my page
[21:57] <sinzui> GTRsdk, yep, that is not launchpad. That is Ubuntu SSO lying again
[21:58] <sinzui> GTRsdk, Visit login.ubuntu.com and see it it behaves correctly
[21:58] <GTRsdk> but how could I have gotten there fron launchpad.net ?
[21:59] <sinzui> GTRsdk, login.launchpad.net is a skin on Ubuntu. It is managing your identity, not Launchpad. So if that site is acting odd, try the real site
[22:00] <GTRsdk> yay I'm back in
[22:01] <GTRsdk> sinzui: thanks
=== joey is now known as zz_joey