[00:21] <ScottK> lifeless: would that affect build status on the web u/i?
[00:22] <lifeless> build logs and build progress tails
[01:09] <broder> would the LP networking issues keep me from being able to do a maverick -> natty upgrade?
[01:11] <james_w> broder, probably not
[01:11] <james_w> broder, were you seeing issues, or just asking before you did it?
[01:11] <broder> james_w: do-release-upgrade -d is claiming "No new release found"
[01:11] <james_w> hmm
[01:11] <james_w> is there a debug mode?
[01:12] <james_w> finding out which url it is hitting would be useful
[01:12] <broder> not that i've found yet
[01:12] <broder> looks like it's something on changelogs.ubuntu.com
[01:12] <broder> which is...not responding for me
[01:12] <james_w> that sounds right
[01:15] <broder> my path to changelogs.u.c looks very similar to my path to bazaar.launchpad.net, so i'm going to assume it's the same outage
[01:16] <james_w> broder, confirmed
[01:16] <james_w> I'd guess it would be sorted soon
[01:16] <lifeless> it should be plugined in again soon
[01:17] <broder> no worries; it just means my timing is amazing :)
[01:23] <sladen> broder: update-manager -c -d   isn't it?
[01:23] <sladen> broder: force a check && force checking for development version
[01:38] <broder> sladen: possibly. i've just always done it with do-release-upgrade from the console. either way, i'm pretty sure they both try to hit changelogs.u.c
[02:03] <sladen> broder: yes  http://changelogs.ubuntu.com/meta-release IIRC, bug changelogs.u.c appears to be down
[02:09] <psusi> so it looks like dconf is a replacement for gconf, and it looks like it's libraries are now installed by default, so why are the gconf xml files still around?
[02:09] <TheMuso> psusi: Because there are still lots of components of the desktop that use gconf, i.e because they were left at their GNOME 2.32 versions.
[02:10] <smoser> is it known that changelogs.ubuntu.com is down ?
[02:10] <psusi> TheMuso, so dconf isn't a drop in replacement?  the apps have to be modified?
[02:13] <broder> smoser: yes. see twitter.com/launchpadstatus - it's affected by that, afaik
[02:13] <TheMuso> psusi: Correct.
[02:14] <TheMuso> Dconf is a backend for glib's gsettings framework.
[02:14] <TheMuso> I believe gsettings can have multiple backends, even gconf, but I am not sure if that backend is maintained any more, very likely not.
[02:15] <psusi> that's what I thought, so apps use gsettings and gsettings can be switched from gconf to dconf as the backend can't it?
[02:26] <TheMuso> yes, don't know how its done though.
[02:26] <TheMuso> And yes so far as I understand things.
[02:29] <ohsix> i miss my changelogs
[03:54] <freeflying> hi guys, I'm wondering if its possible to remove an upload from repository
[03:54] <ScottK> freeflying: It's extremely difficult and virtually never done.
[03:55] <ScottK> The only time I'm aware of it having been done was when the package turned out to be illegal to ship.
[03:55] <micahg> freeflying: what's the reason?
[03:56] <freeflying> micahg: ubuntu-chinese-meta is being generated from ubuntu-chinese.natty seeds automatically, but its been modified manually
[03:58] <micahg> freeflying: so, it should just be fixed in the seeds in reuploaded, no?
[03:59] <micahg> freeflying: and ScottK did those uploads, so I'd suggest some communication if there were problems :)
[04:00] <ScottK> freeflying: The content of the packages is exactly what's in the seeds.  All I did was stop trying to build armel and powerpc packages that would inevitably fail.
[04:00] <ScottK> freeflying: The parts I changed aren't automatically generated.
[04:52] <poolie> hi guys, just to let you know, because of fallout from the switch failure launchpad is apparently not processing apport reports at the moment (bug 760393)
[06:38] <freeflying> micahg: I have talked with ScottK, and he made the revert upload, but it make me a littlte bit hard to generate it from seeds
[07:01] <freeflying> micahg: need to modify changelog everytime, thats why I'm asking for a remove :)
[07:17] <siretart> kees: libav seems to be me (and I'm following the development pretty closely) the clearly better branch to follow, so we've switched to libav
[07:31] <siretart> kees: or are you talking about the libav-source package? that's to avoid the source code and therefore patch duplication issue with libav-extra
[07:44] <pitti> Good morning
[08:06] <robert_ancell> Is anyone else getting issues doing a dput?
[08:06] <mok0> robert_ancell: yes
[08:06] <pitti> robert_ancell: see http://identi.ca/launchpadstatus
[08:06] <robert_ancell> mok0, gpg errors?
[08:06] <pitti> LP still being fixed
[08:07] <mok0> robert_ancell: it reported a problem with my GPG signature, but accepted the pacakge anyway :-/
[08:07] <robert_ancell> ah, nasty
[08:10] <ricotz> robert_ancell, you mean an error about the changes-file?
[08:10] <dholbach> good morning
[08:11] <didrocks> good morning
[08:12] <mvo> robert_ancell: looks like various other machines are down as well (changelogs.ubuntu.com for a start)
[08:13] <robert_ancell> ricotz, "Changes file must be signed with a valid GPG signature: Verification failed 3 times: ['General error', 'General error', 'General error'] : Permission denied"
[08:14]  * robert_ancell is glad he's not a sysadmin
[08:14] <dholbach> could it be that Launchpad is not allowing new ubuntu bugs via apport in?
[08:14] <elmo> dholbach: yes
[08:14] <dholbach> thanks elmo
[08:15] <ricotz> robert_ancell, exactly what i got, but the upload worked anyway ;)
[08:20] <trojanware> which dbus service broadcasts info whenever a friend logs in?
[08:21] <trojanware> using empathy
[08:49] <pitti> Daviey, smoser: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt recently grew an universe->main for lxc; seems this was seeded recently? seems a little late now?
[09:12] <ttx> pitti: afaik it's needed so that you can use uec-images directly as an LXC container (so lxc is installed by default on it)
[09:13] <ttx> pitti: (not judging if the feature is worth the lateness or not)
[09:54] <pitti> cjwatson, ev: what's the condition for installing the PAE kernel?
[09:55] <elmo> pitti: the 32-bit server kernel is PAE
[09:55] <pitti> right, I mean desktop
[09:55] <elmo> so that's one condition
[09:55] <pitti> I want to document bug 759804 for the release notes
[09:56] <pitti> but as only few people get it, I suppose it only installs that if you have more than e. g. 4 GB of RAM?
[09:57] <ev> pitti: 32-bit system with more than 3GB of RAM
[09:57] <pitti> ev: thanks
[09:57] <ev> sure thing
[09:58]  * popey hugs kees 
[09:58] <popey> kees: glad it's not just me that misses FFM in unity :(
[10:03] <ev> pitti: I stand corrected.  It used to be 3GB, it's 4 now.
[10:03] <pitti> ev: thanks for checking
[10:03] <ev> (lp:~ubuntu-core-dev/base-installer/kernel/i386.sh:32)
[10:03] <ev> no problem
[10:09] <soren> popey: You're not alone at all. I managed to coerce compiz into doing ffm, but the globalmenu makes it a bit annoying.
[10:09] <popey> it does
[10:09] <ev> simulating a machine with nvidia and > 4GB of RAM now to test the fix
[10:21] <tjaalton> https://blueprints.launchpad.net/sprints/uds-o only shows ten blueprints, and https://blueprints.launchpad.net/ubuntu/oneiric shows nine
[10:21] <tjaalton> surely there are others already?
[10:22] <tjaalton> oh, the rest are just proposed
[10:28] <pitti> TheMuso: still awake by any chance?
[10:28] <pitti> who usually tests ubuntustudio images? LP is back up, and the uninstallability is fixed on the latest images
[10:28] <pitti> posted to the tracker
[10:32] <smoser> pitti, regarding lxcguest in uec seed. that is bug 727200.
[10:32] <smoser> fwiw, lxcguest has been in the images since before beta1.
[10:33] <smoser> it was just added via build command rather than seed.
[10:33] <pitti> smoser: ah, good
[10:34]  * pitti promotes
[10:40] <pitti> ogra_: linux-tools-omap4 wants  to go to universe, is that ok?
[10:40] <mdz> I just rebooted and logged into a fresh session, and got a "you have logged in using a different language" dialog suggesting replacing "/home/mdz" with "/home/mdz/Downloads"
[10:41] <ogra_> pitti, heh, good question
[10:41] <pitti> mdz: hm, xdg-user-dirs should perhaps check if a particular dir is now your $HOME instead of a subdir..
[10:41] <pitti> mdz: apparently you set the downloads folder to ~ at some point
[10:41] <mdz> pitti, perhaps, yes
[10:41] <pitti> ogra_: we can also just seed it to supported
[10:42] <jibel> TheMuso, ping
[10:43] <seb128> mdz, those checks usually happen when you change your locale, did you do that?
[10:43] <mdz> seb128, no
[10:44] <mdz> at least not intentionally or knowingly
[10:44] <seb128> mdz, the directories are in .config/user-dirs.dirs
[10:44] <mdz> seb128, I clicked "update" and that file has the /Downloads path now as expected
[10:44] <seb128> ok, weird
[10:45] <seb128> it's supposed to compare .config/user-dirs.locale with your locale and do those checks only if you changed locale
[10:45] <seb128> it's to rename the directory to whatever words they are in the local you use
[10:46] <null1> hai people
[10:48] <pitti> ogra_: so perhaps we should just seed it then; not much harm having it in main, I guess?
[10:48] <ogra_> pitti, i have to find out what it adds over linux-tools
[10:48] <jibel> hey all, natty beta 2 candidates on powerpc need smoke testing, anyone ?
[10:48] <ogra_> but yeah, seeding to supported is probably safe in any case
[10:48] <jibel> if you want to help, the images are on the tracker http://iso.qa.ubuntu.com/qatracker/build/all/notcompleted
[10:52] <pitti> ogra_: oh, hang on
[10:52] <pitti> ogra_: linux-tools-omap4 is shown as uninstallable in http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html
[10:52] <pitti> ogra_: so I guess it actually should live in universe
[10:54] <ogra_> grmbl, the description of the packages is really pointelss to decide it
[10:54]  * ogra_ grumbles towards the kernel team
[10:54] <pitti> ogra_: do you mind if I demote it? then c-m is empty and done for natty
[10:55] <pitti> and it'll fix the uninstallability, too
[10:55] <ogra_> pitti, well, it might be needed for something, i'd really like to hear from the kernel team first
[10:55] <ogra_> apw, ^^^ any comment ?
[10:55] <pitti> ogra_: nothign in main depends on it, anyway, but sure
[10:56] <apw> ogra_, wassup ?
[10:57] <ogra_> apw, linux-tools-omap4, whats that and what for do we need it ?
[10:57] <ogra_> i.e. does it provide anything linux-tools doesnt provide and is what it provides essential enough to have the package in main
[10:57] <apw> it is the package which is used to get the kernel version tied tools for omap4, it in theory should pull in the perf tool
[10:58] <apw> it is the version of the tools for omap4, rather than for regualr arm, as the kerenel is variant and the tools are variant specific
[10:58] <apw> it cirtainly is not world ending if it is in universe
[10:58] <ogra_> k
[10:58] <apw> it is a debugging thing, not on any criticial path
[10:58] <ogra_> pitti, go ahead then
[10:58] <ogra_> apw, thanks !
[10:58] <pitti> good
[10:58] <pitti> thanks
[10:58] <ogra_>  This package provides the architecture dependant parts for kernel
[10:58] <ogra_>  version locked tools for version 2.6.38-1207 on
[10:58] <ogra_>  DESC.
[10:59] <apw> heh nice, hopeless, sigh
[10:59] <ogra_> apw, i think there is a bug in the scripts creating the description
[10:59] <apw> yeah does look like it doesn't it.
[10:59] <pitti> linux-ti-omap4-tools-2.6.38-1207 is uninstallable, too
[10:59] <apw> i am looking at the mess that is that tree so, i'll have a look at the same time
[10:59] <ogra_> be careful afaik cooloney is in the middle of rebasing it
[11:00] <ogra_> or at least he tries to
[11:00] <ogra_> pitti, well, thats the actual binary, the former one was just the meta
[11:00] <ogra_> pitti, drop it too
[11:01] <pitti> that's being held in main, though
[11:01] <pitti> hmm
[11:01] <pitti> only by linux-tools-omap4
[11:02] <pitti> ok, demoting
[11:02] <ogra_> yeah
[11:19] <mok0> Will we have beta2 today?
[11:20] <ogra_> thats what the scedule says
[11:23] <Daviey> pitti: just saw your message.  Yes, it is my understanding that it has already been included in the cloud images.
[11:23] <Daviey> Has been for some weeks now.
[11:23] <pitti> Daviey: all good now, MIR was approved, and I promoted it
[11:24] <Daviey> pitti: yeah, kees approved it a few days ago?
[11:43] <TheMuso> pitti,jibel pong
[11:44] <pitti> TheMuso: jibel is already testing the studio ones
[11:44] <TheMuso> pitti: I am no longer involved with studio. I still help from time to time, but am no longer a primary contributor.
[11:44] <pitti> ah, ok
[11:46] <jibel> TheMuso, hi, any chance to smoke test the latest builds on powerpc ?
[11:46] <TheMuso> jibel: I have already tested ubuntu powerpc alternate and desktop.
[11:46] <jibel> TheMuso, Ubuntu Alternate and Desktop
[11:47] <TheMuso> jibel: THose tests should show up as done, unless there has been a rebuild...
[11:47] <jibel> TheMuso, I know but it's been rebuild yesterday, and we'd like to ensure that there no regression
[11:47]  * TheMuso sighs
[11:47] <TheMuso> I'm on it.
[11:47] <jibel> TheMuso, awesome! thanks
[11:52] <TheMuso> Well I know that the desktop tasks will fail already, since I filed a bug about an install error which has not yet been fixed...
[12:01] <ogra_> TheMuso, can you remove the maverick omap4 config files from alsa-libs ? do you need a bug for that ?
[12:01] <TheMuso> ogra_: Don't think so. What files are you referring to exactly?
[12:01] <ogra_> the init files
[12:01] <TheMuso> you mean alsa-utils? Sure, why don't you need them?
[12:01] <ogra_> i'm pretty sure they get in our way with UCM
[12:02] <TheMuso> ah ok.
[12:02] <ogra_> they were for the hacked up kernel in maverick
[12:02] <TheMuso> Right. Maybe for the sake of paperwork if you could file a bug if possible accessing launchpad, please do.
[12:02] <ogra_> k, no prob
[12:03] <ogra_> TheMuso, we also noticed that on our headless images the initialization seems to work fine on natty ... but not on the netbook ones
[12:03] <TheMuso> ogra_: no idea there, same code.
[12:03] <ogra_> (headless doesnt ship any userspace audio stuff)
[12:03] <TheMuso> still no idea.
[12:04] <TheMuso> ogra_: What hardware?
[12:04] <ogra_> omap4 pandaboard
[12:04] <ogra_> (arm)
[12:04] <TheMuso> hrm ok
[12:04] <TheMuso> so lets remove those files from alsa-utils and see how things go I guess.
[12:04] <ogra_> the funny thing is that headless doesnt ship any alsa packages by default ... dmesg shows the asoc devices properly initializing
[12:05] <ogra_> on netbook we ship alsa-libs/-utils and there the kernel fails to initialize the devices
[12:05] <TheMuso> How does it fail?
[12:06] <ogra_> dmesg shows messages about "no backend routing" for all devices iut tries to init
[12:06] <ogra_> i need to collect logs and will attach them to the bug
[12:06] <TheMuso> ok
[12:06] <ogra_> its just very intresting that it seems to work fine without any userspace intervention
[12:06] <TheMuso> yep
[12:06] <TheMuso> Have you tried manually removing the init files?
[12:08] <ogra_> not yet, will do so
[12:08] <TheMuso> thanks.
[12:28] <ogra_> TheMuso, bug 760571
[12:29] <TheMuso>  ogra_ thanks
[12:34] <Riddell> @pilot out
[12:38] <TheMuso> ogra_: Ok in the queue, it was a simple patch so it was easy to remove.
[12:39] <diwic> ogra_, TheMuso, hi - anything you need me for? I was ill yesterday so couldn't do much.
[12:39] <TheMuso> diwic: Nothing other than my PPA has been updated with the udev patch you recommended. Only thing is with the lp issues in the last 12 hours or so, I am not sure if its actually published/built.
[12:39] <diwic> TheMuso, ok
[12:40] <ogra_> diwic, make sound work please :P
[12:40] <ogra_> nothing beyond that *g*
[13:01] <juliank> Aren't bug 676790 and bug 675641 virtually the same bug?
[13:02] <juliank> Having both affecting APT isn't that useful, we could reassign  675641 to synaptic, or mark one as a duplicate of the other
[13:06] <cjwatson> it only needs a synaptic task if synaptic needs a change in order to fx it (IMO)
[13:08] <cjwatson> juliank: bug 135284 - Kickstart certainly is used, why close the bug?
[13:08] <cjwatson> I mean, maybe it's not sensible to fix it in apt, but it shouldn't be closed just because it's old, especially if part of that reasoning is a misconception that Kickstart isn't used
[13:08] <juliank> cjwatson: I close bugs older than 3 years first, instead of doing an Incomplete->Invalid ping-pong.
[13:09] <cjwatson> then can I reopen with no reasoning?
[13:09] <juliank> cjwatson: Is it reproducible?
[13:09] <cjwatson> honestly, closing for that reason is pretty frustrating to me.
[13:09] <cjwatson> I have no idea, IMO the onus is on the person closing the bug ...
[13:10] <cjwatson> it's pretty clearly described
[13:10] <juliank> cjwatson: I've run some fairly large apt-get install command lines and never experienced any problems.
[13:10] <juliank> (certainly more than 10)
[13:10] <cjwatson> if the reason is that it's been fixed, then that's a good reason to close it
[13:11] <cjwatson> but I've reopened because "this bug is old" isn't
[13:11] <tkamppeter> pitti, hi
[13:12]  * cjwatson will try to set up a reproducer
[13:14] <juliank> cjwatson: The correct procedure would be "This bug is very old and hasn't seen recent updates. Can you still reproduce this issue?" and setting to Incomplete. But given the amount of changes we had in the last 4 years, it's not reproducible in 99% of the cases, so going to Invalid and asking to reopen if it can be reproduced saves a lot of time
[13:14] <tkamppeter> mvo, hi
[13:15] <juliank> And yes, our package argument handling is fairly rewritten compared to 4 years ago IIRC
[13:15] <mvo> hi tkamppeter
[13:15] <cjwatson> I have no problem with people closing bugs because "we've completely rewritten this part of the code and believe it's probably fixed".  That's completely different from "this bug is four years old and has gone mouldy"
[13:16] <tkamppeter> mvo, it is about aptdaemon and the Lintian checks, bug 712377, an additional relaxiong is needed. See https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/712377/comments/36
[13:16] <mvo> tkamppeter: ok, I have a look
[13:16] <tkamppeter> mvo, currently installation of manufactutrer-suypplied printer drivers with software-center is blocked.
[13:16] <cjwatson> in this case, it's filed on an installer component too, and apt/Invalid + pkgsel/Triaged means "apt is doing just fine, this is an installer bug"
[13:17] <mvo> tkamppeter: thats fine
[13:17] <tkamppeter> mvo, can that get fixed for the final Natty? Thanks.
[13:17] <mvo> tkamppeter: yes
[13:17] <mvo> hey axp2 :)
[13:17] <axp2> hi
[13:17] <axp2> how are you mvo?
[13:18] <tkamppeter> mvo, Note that these packages are LSB-based packages so they depend only on "lsb" which is supposed to pull in all needed dependencies.
[13:19] <juliank> cjwatson: Well yes, it should definitely be doable on the APT side without problems. I kept the pkgsel side open, as that's completely not my territory
[13:20] <juliank> But no problem.
[13:20] <cjwatson> juliank: how would one best pass a very large number of arguments to APT, when it goes over the system command-line length limit?
[13:20] <cjwatson> APT doesn't provide a "read list from file" option, and using dpkg --set-selections as mvo suggests is ... clunky
[13:20] <juliank> cjwatson: Well, that's a complete different topic. The solution for this is to pass the selections to dpkg and run apt-get install -f
[13:20] <cjwatson> pkgsel has no realistic way to know how to split up the list in a way that'll work
[13:21] <cjwatson> juliank: that's the topic of the bug, now that I've read it in more detail
[13:21] <cjwatson> not completely different at all
[13:22] <juliank> cjwatson: The problem was that it was below the system limit; that is, a bug in APT, preventing it from working correctly with the maximum number of arguments
[13:23] <cjwatson> would it not be a reasonable wishlist to have it take the list from a file?  I'm concerned that dpkg + install -f wouldn't be quite the same - for example, wouldn't apt-get be entitled to remove one of the packages you set to install in order to fix it?
[13:23] <juliank> The other thing would be a feature request
[13:24] <juliank> cjwatson: Just tell me what format you want, and I'll write it (we could also just support a format where each command-line argument is on a single line)
[13:25] <juliank> cjwatson: And apt-get seems to handle apt-get install $(apt-cache pkgnames) quiet well
[13:26] <juliank> 32941 arguments
[13:26] <juliank> I mean it does not install anything, but it parses the command-line correctly and finds the broken packages
[13:27] <cjwatson> hm, OK, perhaps the system length limit is higher than I thought!
[13:27] <pitti> hey tkamppeter, how are you?
[13:27] <cjwatson> I'm just setting up a Kickstart file to install everything on the server CD, to see what it dodes
[13:27] <cjwatson> *does
[13:27] <cjwatson> juliank: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/135284/comments/8
[13:32] <juliank> cjwatson: Actually, once you remove all depends/conflicts/etc, it seems to hang before the files should be downloaded. But there's another bug about Acquire being very very slow somewhere that explains this
[13:33] <juliank> And it continues after some time
[13:34] <tkamppeter> pitti, fine, I have found a proble which needs to eb solved for Natty, https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/712377/comments/36 software-center does not install prionter drivers. I have informed mvo and he is looking into that.
[13:35] <juliank> "252 upgraded, 32574 newly installed, 0 to remove and 0 not upgraded."
[13:36] <juliank> cjwatson: Works perfectly, takes some time to get to download, but download starts and proceeds normally.
[13:39] <cjwatson> juliank: great, thanks - glad to hear it
[13:40] <cjwatson> if it works in pkgsel, we should be able to just close it, since there'll be no need for the new feature
[13:42] <juliank> cjwatson: Agreed
[13:44] <tkamppeter> pitti, another problem is that clicking arch-independent DEB files in Firefox (_all.deb) are considered as unknown file format (no association with software center). This should also be fixed for Natty.
[13:45] <tkamppeter> mvo, ^^^
[13:45] <juliank> I need to reboot now, I have about 230 mount points that I can't unmount.
[13:46] <cjwatson> juliank: 'umount -l' can sometimes help ...
[13:46] <cjwatson> too late
[13:46] <Jerub> i was going to suggest fuser
[13:49] <fabbione> hey guys
[13:49] <fabbione> does anybody remember Daniel Stone irc nick name by any chance?
[13:49] <ogra_> daniels
[13:49] <pitti> hey fabbione
[13:49] <fabbione> ogra_: thanks
[13:49] <fabbione> hey pitti
[13:49] <ogra_> :)
[13:56] <tkamppeter> pitti, mvo, I have reported bug 760644 on the fact that for architecture-independent .deb files Software Center does not get opened when clicking them in firefox, did I select the correect packages?
[13:57] <mvo> thanks tkamppeter, sounds like something for chrisccoulson if its firefox
[13:58] <tkamppeter> mvo, I do not know whether the file type/program associations are in Firefox.
[13:59] <juliank> If anyone wants to debug something with pselect(), take a look at bug 341777
[14:02] <juliank> (I'm not a select() and signals freak)
[14:03] <chrisccoulson> mvo / tkamppeter - firefox is using gio to lookup the default handler
[14:04] <tkamppeter> chrisccoulson, what does it mean for the package assignment of bug 760644?
[14:07] <cjwatson> juliank: OK, closed now, sorry for doubting you :-)
[14:10] <juliank> cjwatson: I'm on a magic close/merge mission this week, as we just have way too many open bugs to even start working on them. (python-apt had 40, now has about 7, out of which 3 are unfixed; apt had about 40 bugs closed, merged, or reassigned)
[14:10] <juliank> Thus in total, we went from 300 to 200 bugs this week.
[14:11] <juliank> mvo: ^
[14:11] <mvo> nice
[14:13] <ogra_> scary, you will make us all jobless !
[14:19] <tkamppeter> mvo, see also comments #41 and #44 on bug 712377.
[14:19] <zul> pitti: hi there is a regression in the last samba lucid  sru with winbindd segfaulting i just uploaded a fix for it, its waiting to be accepted
[14:20] <pitti> zul: ah, thanks
[14:20] <zul> pitti: np
[14:25] <chrisccoulson> mvo - is application/x-deb actually registered with shared-mime-info?
[14:29] <mvo> chrisccoulson: it should be, haven't checked, but gdebi was using it as well
[14:29] <kiwinote> mvo: it seems to be a consequence of http://bazaar.launchpad.net/~software-store-developers/software-center/trunk/revision/1535.1.16 (there's a bug open on apturls in firefox too) - I recall testing it quite well, so either I over looked a corner case, or I had some local config or so
[14:30] <chrisccoulson> yeah, it seems to be
[14:30] <chrisccoulson> hmmm
[14:41] <mvo> kiwinote: ohhh, thanks
[14:42] <chrisccoulson> mvo / tkamppeter - i'll have a look at this issue. for some reason, firefox thinks that the content type isn't registered (according to glib)
[14:43] <chrisccoulson> mvo - do you know who looks after apt.ubuntu.com too?
[14:46] <mvo> chrisccoulson: IS is all I know, sorry
[14:46] <chrisccoulson> mvo - thanks
[14:56] <juliank> jibel: I still can't see the APT portion in bug 513460 - DescURI() for a local package (obsolete) should be empty
[14:57] <juliank> mvo: We're now actually at 178 bugs in apt, starting from about 250 this morning
[15:01] <jibel> juliank, IIRC all the calls to DescURI() after the obsolete package returns an empty record. should verify if it still exists and retitle the report or file another one.
[15:03] <jibel> Tm_T, hi, the latest builds for Kubuntu on powerpc are untested. Could you smoke test them and ensure that nothing broke since the previous builds ?
[15:40] <janimo> pitti, regarding bug 760431 I subscribed ubuntu-release as the freeze exception wiki page indicates
[15:40] <janimo> I uploaded last night
[16:07] <maco> Laney: ewww gmail is merging all the application processing threads into one lump :(   <3 kmail in this instance
[16:07] <Laney> heh
[16:07] <Laney> gmail: because nobody ever uses the same subject for different converstaions!
[16:09] <Laney> anyway, yeah, please pitch in with questions :-)
[16:12] <sconklin> @patch in
[16:12] <udevbot> Error: "patch" is not a valid command.
[16:12] <maco> sconklin: pilot i think
[16:13] <sconklin> maco: thanks
[16:13] <sconklin> @pilot in
[16:47] <Daviey> sconklin, I had a dog called patch once.
[16:47] <sconklin> my mom had a dog named patches
[16:47] <sconklin> I've had plenty of patches that were dogs
[16:55]  * dholbach hugs sconklin
[17:27] <pitti> hallyn: hey
[17:27] <bdrung> mdeslaur: re bug #760685 - do you want debdiff for maverick and lucid from me?
[17:28] <pitti> hallyn: I reject your libvirt maverick uploads; http://launchpadlibrarian.net/68469973/libvirt_0.8.3-1ubuntu15_source.changes has a typo in the changelog (two #), and http://launchpadlibrarian.net/68475451/libvirt_0.8.3-1ubuntu16_source.changes isn't built with including the previous changelog
[17:28] <mdeslaur> bdrung: I just published updates for lucid, maverick and natty
[17:28] <tkamppeter> pitti, I have severe problems with CUPS and I want to ask you for help. It segfaults rather often and Apport is not able to create symbolic stack traces. Bug 751770.
[17:29] <bdrung> mdeslaur: yes, i should read all my mails before asking questions :)
[17:29] <pitti> hallyn: so either please reupload as 15 with a merged changelog, or as ubuntu16 with building with -v0.8.3-1ubuntu14.1
[17:29] <bdrung> mdeslaur: natty too? i uploaded 1.1.9-1ubuntu1 to natty
[17:29] <tkamppeter> pitti, also bug 754567, it seems that it crashes at different points in DBus library functions.
[17:30] <mdeslaur> bdrung: ah, well your package will supersede mine
[17:31] <hallyn> pitti: I reject your rejection!
[17:31] <hallyn> pitti: will do, thanks :)
[17:32] <hallyn> hm, hopefully launchpadlibrarian can give me the source back, bc i've deleted the bzr trees
[17:34] <hallyn> pitti: is there any way for you to check whether there are pending upates for lucid's libvirt?
[17:35] <hallyn> pitti: i thought iw as waiting for two lucid-proposed updates, but now i'm wondering whether i thought the maverick ones were for lucid, and i should have just gone ahead with my next lucid-proposed libvirt push
[17:35] <debfx> ScottK: it might be a good idea to add bug reporting guidelines for the *-backports launchpad projects stating what is needed for a request to be approved
[17:36] <ScottK> debfx: I'm a little busy today.  If you can propose text, I'd be glad to copy/paste it in.
[17:47] <pitti> hallyn: http://people.canonical.com/~ubuntu-archive/pending-sru.html doens't show a libvirt for lucid
[17:47] <hallyn> pitti: thanks
[17:47] <pitti> hallyn: however
[17:47] <pitti> hallyn: there is one in the review queue which hasn't been accepted into -proposed yet: https://launchpad.net/ubuntu/lucid/+queue?queue_state=1
[17:48] <pitti> hallyn: should I review that, or do you want to update that as well with another change? (then it's better to have just one upload instead of two)
[17:49] <hallyn> how do i update that with another change?
[17:49] <pitti> hallyn: I reject the upload, you add the extra stuff and reupload
[17:49] <hallyn> pitti: the only problem with that is, as with this maverick one, that i lost my bzr trees
[17:50] <hallyn> pitti: so it'd be easier to have that go through to the -proposed bzr tree so I can build on top of that
[17:51] <pitti> hallyn: you can also download the source from that queue page if you want
[17:52] <pitti> hallyn: but I'm fine with reviewing/accepting it, then we test that first, and update again once it's in -updates
[17:52] <hallyn> pitti: let's go that route while i figure out how to undo my mess with the maverick version
[17:52] <hallyn> pitti: thanks
[17:52] <pitti> hallyn: ack, will do
[17:52] <tomreyn> hi
[17:52] <tomreyn>  according to https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/737137 cmake in natty should be able to find the libraries in /usr/lib64/x86_64-linux-gnu since cmake 2.8.3-3ubuntu4. I'm on cmake 2.8.3-3ubuntu7 and it does not seem to find them here...
[17:53] <tomreyn> i'm not really a developer, though, so I may be misinterpreting things.
[17:55] <tomreyn> My real issue is that I run into errors like "No rule to make target `/usr/lib/libz.so', needed by `source/game/glestadv'.  Stop." on natty when I did not run into these on maverick. And this seem to be because the libraries are not found by cmake in /usr/lib64/x86_64-linux-gnu
[17:56] <ScottK> slangasek: ^^^
[17:56] <tomreyn> ...and because they no longer exist in /usr/lib (where they did exist on maverick)
[17:57] <pitti> tkamppeter: I'll have a look
[17:58] <hallyn> pitti: given http://launchpadlibrarian.net/68469973/libvirt_0.8.3-1ubuntu15_source.changes, how can I get the source?  I've tried dget'ing the .dsc with several prepended launchpadlibrarion urls, but haven't gotten it right yet
[17:58] <pitti> hallyn: open the expander on the queue page, there you see the .dsc, .diff.gz, etc.
[18:00] <debfx> tomreyn: sounds like either the libz path is hardcoded and not checked or (more likely) cmake has cached the old path
[18:00] <slangasek> tomreyn: cmake itself can find libraries in the multiarch directory, but there may be upstream-specific or library-specific cmake rules that are looking for a hard-coded path
[18:01] <slangasek> for instance, bug #751940
[18:01] <hallyn> pitti: got it, thanks
[18:05] <slangasek> tomreyn: at a glance, I don't see anything in /usr/share/cmake-2.8/Modules/FindZLIB.cmake that should break with the current zlib packages; can you point me to the source you're trying to build, so I can test here?
[18:07] <dpm> hi allison_, all set for your appdeveloper week session later on?
[18:09] <pitti> zul: are these landscape-client SRUs ok to go after the currently -proposed ones? if so, I'll just keep them in the queue until they got verified
[18:09] <pitti> zul: if not, they'd need to be reuploaded with -v to include the previous proposed update
[18:09] <zul> pitti: *sigh* ok ill do that
[18:10] <tomreyn> slangasek: i'm sorry, in the case of libz it was indeed my mistake, not having deleted the local cmake cache. but i ran into this issue with other libraries lately. let me see if this still happens.
[18:10] <pitti> zul: i. e. the current -proposed pacakges shouldn't be released like that?
[18:10] <slangasek> tomreyn: ok - if you are seeing problems after the cache flush, please let us know so we can get those addressed
[18:10] <zul> pitti: there was  a bug fix in the last ones i uploaded they were the .1 packages
[18:11] <pitti> zul: ok, I'll reject them then, to clear the way for your reuploads?
[18:11] <zul> pitti: ok thanks
[18:12] <tomreyn> slangasek: i must have installed the cmake update since i last flushed the cache, it no longer happens now. sorry to have wasted your time.
[18:12] <bdrung> bryceh_: re bug #755841: what's the fastest way to reload the -intel driver? log out and sysrq+k?
[18:12] <slangasek> tomreyn: not a waste, thanks for the input :)
[18:14] <pitti> mvo: your apt-clone upload drops the .bzr-builddeb/ dir, is that really intended?
[18:27] <pitti> hm, seb128 uploaded shared-mime-info which fixes the b-deps, but drops the Multiarch: field
[18:27] <pitti> I guess that's not right
[18:27] <pitti> slangasek: ^
[18:28] <slangasek> it is not right :/
[18:28] <slangasek> need me to fix?
[18:28] <pitti> I'll reject it then
[18:28] <pitti> slangasek: I think seb128 can handle it; probably some bzr vs. other bzr fight here :)
[18:30] <slangasek> well, the package has no Vcs-Bzr field
[18:30] <pitti> or he just downloaded a previous version and forgot about your's or so
[18:45] <mvo> pitti: its a side effect of bzr-buildpackage I believe, I think the previous upload was done differently, its still in bzr
[18:49] <pitti> mvo: ah, ok
[18:49] <pitti> accepting then
[18:49] <mvo> thanks!
[19:35] <bryceh_> bdrung, if it's just the xserver-xorg-video-intel driver, then just logging out and back in is sufficient (I usually do sudo service gdm restart, though)
[19:36] <bryceh_> bdrung, if you need to reload the kernel intel drm driver, then rebooting is probably the simplest way, although you could also remove and reload the kernel module (maybe)
[19:42] <SpamapS> pitti: ping, trying to figure out if this diff is flawed because it makes the version lower than a previous rejected proposed upgrade: http://launchpadlibrarian.net/69370270/vsftpd_2.2.2-3ubuntu7.1_2.2.2-3ubuntu6.2.diff.gz
[19:44] <Tm_T> jibel_: about ppc testing, just got home so about to download and give them a test run (:
[19:51] <ohsix> hrm just actually tried the kinetic scrolling; that's great
[19:53] <pitti> SpamapS: right, that's hard to read; I think in this case it's better to download the current version from archive and the version from the queue and debdiff it
[19:58] <bdrung> bryceh_: thanks
[20:02] <SpamapS> pitti: roger.
[20:10] <shadeslayer> btw i don't see UDS Oneric Ocelot in the Android app for Conventionist ( refer http://summit.ubuntu.com/mobile/ )
[20:15] <Daviey> pitti, trying to get an idea of where the inconsistency of that SRU is...  is it merely the -proposed bzr branch being including a nuked upload?  or archive -proposed pocket (approved or unapproved)?
[20:16] <Daviey> I was sure i checked the unapproved queue before uploading, which is causing me great confusion.
[20:17] <bigcx2> hey all, i have a question about bumping a package version in natty
[20:18] <bigcx2> i have a package i got via apt-get source
[20:18] <bigcx2> i made some changes to it
[20:18] <bigcx2> and ran dch -i
[20:18] <bigcx2> which gave me:
[20:18] <bigcx2> dch warning: no orig tarball found for the new version.
[20:19] <bigcx2> and then when i go to build with dpkg-buildpackage
[20:19] <bigcx2> it errors with:
[20:19] <bigcx2>  dpkg-source: error: can't build with source format '3.0 (quilt)': no orig.tar file found
[20:19] <bigcx2> what gives??
[20:22] <slangasek> bigcx2: you've bumped the upstream version number but you haven't provided a new upstream tarball to go with it
[20:25] <bigcx2> slangasek: if i copy the old orig.tar.gz to the new version # should that be sufficient?
[20:25] <slangasek> it would solve the error but would be a wrong change
[20:25] <slangasek> you shouldn't change the upstream version number in debian/changelog unless there's a new upstream version
[20:26] <slangasek> what are the previous and new version numbers?
[20:26] <bigcx2> this is just for a "in-house" use package
[20:26] <bigcx2> i'm moving from 0.1 to 0.2
[20:27] <slangasek> "0.1" and "0.2" are not version numbers that would trigger this error
[20:28] <slangasek> because they're native version numbers, so 3.0 (quilt) would cause a different error message entirely ;)
[20:28] <Daviey> pitti, If it was just the LP generated diff, It looks like it was a case of bug 680911.
[20:29] <bigcx2> slangasek: hm, either way that's what i'm getting lol
[20:29] <bigcx2> if i copy the old tarball to the new version
[20:29] <bigcx2> it stops complaining
[20:29] <bigcx2> and it seems to do the right thing...but i added a script in the new package, and i get this now:
[20:29] <slangasek> bigcx2: the version number in debian/changelog should have an upstream part and a "Debian revision" part, separated by a dash; changing the part before the dash causes this error, changing the part after the dash is safe and what you want to be doing if there isn't actually a new upstream version
[20:30] <bigcx2> slangasek: ok
[20:30] <bigcx2> executable mode 0755 of 'test.sh' will not be represented in diff
[20:30] <slangasek> right
[20:31] <bigcx2> i'm glad it makes sense to you :)
[20:31] <slangasek> if you need it executable, you need to set the execute bit at package build time, via debian/rules or a change to an upstream makefile
[20:32] <bigcx2> hm, things have certainly changed last time i built a package !
[20:32] <bigcx2> it's just a script i'm installing with dh_install
[20:32] <bigcx2> so there is no makefile
[20:33] <bigcx2> so just chmod in debian/rules?
[20:33] <slangasek> ok, then it's fine that it's not executable in the diff - you just need to make sure you're setting the permissions you want via debian/rules when installing, yes
[20:34] <bigcx2> dh_fixperms?
[20:36] <slangasek> bigcx2: yes, if it's installed to /usr/bin, dh_fixperms is sufficient
[20:41] <bigcx2> slangasek: thanks!
[20:48] <speakman> Is there any "GNU Autotools to .deb" utility available?
[20:48] <speakman> Or; how to make a .deb out of a GNU Autotools project?
[20:50] <cjwatson> for autotools, debian/rules can normally just be /usr/share/doc/debhelper/examples/rules.tiny
[20:50] <cjwatson> and construct the rest of debian/ as usual
[20:51] <cjwatson> in fact, with the current version of dh_make in natty (not older releases), 'dh_make' should do it
[20:52] <cjwatson> (dh-make package)
[20:54] <speakman> oh, sounds awesome! too bad I'm not on natty :(
[20:55] <cjwatson> well, autotools is very packaging-friendly, so just about any auto-package-this tool will do it.  an older version of dh_make should be fine, it just won't automatically use the nice minimal rules format
[20:55] <speakman> ok
[20:56] <cjwatson> you can always replace it with /usr/share/doc/debhelper/examples/rules.tiny, 'echo 7 >debian/compat', and make sure you're build-depending on debhelper (>= 7)
[20:56] <cjwatson> that kind of little niggle should disappear once we stop needing to worry about lucid :)
[20:57] <speakman> what's the best docs about debhelper?
[20:57] <cjwatson> its man pages
[20:57] <speakman> ok
[20:57] <speakman> how do I specify configure rules?
[20:58] <cjwatson> with the tiny rules format:
[20:58] <cjwatson> override_dh_auto_configure:
[20:58] <speakman> ok
[20:58] <cjwatson>         dh_auto_configure --with-blah
[20:58] <cjwatson> (that's a hard tab at the start, this being a makefile)
[20:58] <slangasek> isn't that -- --with-blah?
[20:58] <speakman> I guess it's only --prefix which dh_make probably sets correctly anyway?
[20:58] <cjwatson> you don't need it for basic stuff like --prefix, though - that's figured out for you
[20:58] <cjwatson> slangasek is as usual correct
[20:58] <speakman> great, thanks :)
[20:59] <cjwatson> also, if you use override targets, build-depend on debhelper (>= 7.0.50)
[21:00] <speakman> hm, why isn't dh_make a part of debhelper?
[21:00] <cjwatson> it's maintained and developed independently
[21:00] <azeem> different author
[21:01] <cjwatson> and it's not needed at build time, only for people wanting to use it to create initial packaging
[21:02] <speakman> ok
[21:03] <speakman> Do I have to ./configure the package prior to dh_make ?
[21:03] <slangasek> no
[21:03] <cjwatson> no.  dh_make just gives you template packaging; you edit it to give yourself a source package; you then build that source package
[21:04] <cjwatson> (and you then forget about dh_make)
[21:04] <cjwatson> most people just copy from the last package they did once they've done a few, rather than using dh_make. :-)
[21:05] <cjwatson> but it cuts down on how much you need to absorb at first
[21:07] <speakman> Hm. It always get my email address wrong. Where does it get it from?
[21:08] <cjwatson> http://manpages.ubuntu.com/manpages/natty/en/man8/dh_make.8.html and search for e-mail
[21:08] <speakman> and what about these .ex files? emacsen? manpage? I've got neither
[21:08] <cjwatson> delete them if they aren't necessary
[21:09] <cjwatson> dh_make spits out a *template* - you're supposed to edit it
[21:09] <speakman> ok, is there a good newbie site how to build deb packages using db_make? :)
[21:09] <cjwatson> probably but I have no idea where it might be. :-)
[21:09] <speakman> (very old-time debian and later ubuntu user, but never done any packaging :D )
[21:10]  * cjwatson last used dh_make in 1999
[21:10] <speakman> ok
[21:10] <speakman> doing manually is better?
[21:10] <cjwatson> I'm not making a value judgement - I do it manually because I've been doing it for 12 years and find it easier that way, but I'm sure it isn't easier to do it manually if you're new to the business
[21:11] <speakman> i see
[21:11] <speakman> rm *.EX && rm *.ex did the trick ;)
[21:11] <speakman> http://www.debian-administration.org/articles/337
[21:11] <cjwatson> some folks around here have been working on some simpler auto-packaging tools, but I'm afraid I don't have links to hand
[21:12] <speakman> ok, sounds neat though :)
[21:12] <ion> Also, be sure to use dh7-style debian/rules.
[21:12] <speakman> ok?
[21:12] <speakman> so, where to read about debian/rules styles? :D
[21:12] <cjwatson> that debian-administration guide seems not unreasonable in general outline; some details have changed in the last five years, of course, but that essentially amounts to having to do less work
[21:13] <cjwatson> man dh
[21:13] <ion> See /usr/share/debhelper/dh_make/debiann/rules.dh7
[21:13] <ion> That’s what you’ll want to start with.
[21:13] <speakman> thanks!
[21:13] <cjwatson> ion: (see above where I pointed speakman to /usr/share/doc/debhelper/examples/rules.tiny already.)
[21:14] <ion> Ah :-)
[21:14] <speakman> debian/compat is set to 7 by dh_make
[21:14] <speakman> hm can I examine my newly built .deb file somehow? :D
[21:15] <cjwatson> debc
[21:15] <speakman> (without ar-extracting it and so on..)
[21:15] <speakman> oh, devscripts took it's space...
[21:17] <speakman> debc: can't ready mypackage_1.0-1_amd64.changes!
[21:18] <cjwatson> read its man page, think, work out what you missed
[21:18] <speakman> dpkg -c mypackage....deb did the trick ;)
[21:18] <cjwatson> sounds like you did 'cd ..' before running debc.  don't.
[21:18] <cjwatson> (perhaps.)
[21:18] <speakman> hm?
[21:19] <speakman> I'm in the source tree, not debian/
[21:19] <cjwatson> well, in that case you must have run 'debian/rules build && fakeroot debian/rules binary', rather than 'debuild -b'
[21:19] <cjwatson> (briefly, the latter is the same as the former except that it also generates a .changes file, which is useful for tools like debc)
[21:20] <cjwatson> again, read man pages - all the commands I'm mentioning have good ones)
[21:20] <speakman> debuild -b made debc work also
[21:21] <speakman> Section: unknown - is that ok for a "non-public" package?
[21:21] <cjwatson> doesn't matter for that
[21:21] <speakman> ok
[21:22] <speakman> Thanks alot guys, I think I know enought for creating my own packages :)
[21:22] <cjwatson> you're welcome
[21:22] <speakman> How well does alien convert it to rpm?
[21:22] <speakman> does RH based system has the same paths?
[21:22] <speakman> (not really sure it will be running on ubuntu or rh)
[21:23] <maxb> I'm running a natty upgrade, and something very weird is happening in the "Calculating the changes" phase. It's taking ages, and by tailing /var/log/dist-upgrade/apt.log, I can see it appears to be visibly writing its output character by character.
[21:23] <speakman> and to make a new "version" I just edit debian/changelog right?
[21:23] <speakman> and then debuild -b again?
[21:23] <speakman> and one final thing; can I make i386 binaries on a amd64 machine?
[21:25] <speakman> do you guys use pbuilder?
[21:25] <speakman> https://wiki.ubuntu.com/PackagingGuide/Complete#Prerequisites
[21:29] <maxb> I think nearly everyone who does serious packaging work uses pbuilder, unless they've chosen to assemble a full sbuild setup instead
[21:30] <OdyX> "full sbuild" isn't very hard…
[21:31] <speakman> https://wiki.ubuntu.com/PackagingGuide/Complete is *really* good btw!
[21:34] <speakman> If I'm the maintainer of the project I'm packaging, should I keep the debian/* files in the GIT repo?
[21:35] <maco> usually its recommended to have a separate branch for that
[21:35] <speakman> oh good point
[21:35] <maco> https://code.launchpad.net/gally <-- see i have a code branch & packaging branch
[21:35] <speakman> rebasing it or merge when new changes are available?
[21:35] <maco> and then i get daily builds from lp by having a recipe that drops the packaging branch inside the code one for during the build
[21:36] <maco> i'm upstream
[21:36] <maco> regarding i386 (really i686 in ubuntu) on amd64:  yes, you can make a 32bit pbuilder
[21:37] <speakman> maco: thanks alot, that was helpful :)
[21:38] <maco> speakman: have you seen pbuilder-dist?
[21:40] <speakman> no? where?
[21:40] <speakman> is CDBS to prefer?
[21:59] <Tm_T> jibel: Kubuntu PPC runs as expected
[22:00] <Riddell> Tm_T: great
[22:01] <jibel> Tm_T, Nice! did you test desktop, alternate or both ?
[22:01] <Tm_T> only live
[22:02] <Tm_T> I can try if alternate boots and jazz, if needed
[22:04] <Tm_T> actually, I'll see if it boots ->
[22:06] <ScottK> barry: Bug #761131 looks like something up your alley.
[22:07] <barry> ScottK: let me see if i can whip something up
[22:08] <sconklin> @pilot out
[22:09] <speakman> no orig.tar found when running pdebuild
[22:11] <speakman> How do I tell pdebuild the package is native and doesn't have any orig.tar.gz ?
[22:18] <maxb> speakman: um, you should not need to - it should be defined correctly in the .dsc
[22:28] <speakman> maxb: but how do I create a dsc?
[22:31] <speakman> thought it was made by "debuild -S" but that failed due to lacking orig.tar (which is odd, since this is a "native" package - there is no "upstream" tar gz really)
[22:31] <maco> speakman: what version did you put in changelog?
[22:31] <maco> a native package has no "-"
[22:32] <speakman> 1.0-1
[22:32] <maco> yeah, no
[22:32] <maco> just 1.0
[22:32] <maco> -1 would imply it has an upstream and that this is a debian package of it
[22:32] <maco> as opposed to distro-IS-upstream (which is what native is for)
[22:33] <speakman> oh
[22:34] <speakman> ok, now there is no -1 anymore. But still missing .orig.tar file when debuild -S
[22:35] <maco> is this source format 3?
[22:35]  * speakman has no idea what source format is :D
[22:35] <maco> do you have a source directory with a file inside it named "format"?
[22:35] <speakman> but it says "3.0 (quilt)"
[22:35] <maco> there ya go!
[22:35] <speakman> :)
[22:36] <speakman> is that wrong
[22:36] <speakman> +
[22:36] <barry> ScottK: https://code.launchpad.net/~barry/ubuntu/natty/winpdb/bug-761131/+merge/57787
[22:36] <maco> http://wiki.debian.org/Projects/DebSrc3.0
[22:36] <maco> speakman: ^
[22:36] <maco> speakman: this is part of the "debian has a new packaging format that results in everybody forgetting at least one step for the first year they use it" thing ;-)
[22:37] <speakman> maco: should i change to 3.0 (native) ?
[22:37] <maco> if it is truly a native package
[22:37] <speakman> what is a truly native package? :D
[22:37] <maco> what is it you're packaging, anyway?
[22:37] <speakman> correct
[22:37] <speakman> It's a  miniproject
[22:37] <ScottK> barry: I'm out the door, so you'll need to find a different sponsor.
[22:37] <maco> well like i said, native is just for if the distro is the upstream
[22:38] <speakman> I'm the maintainer and so on, there is no "upstream" or any tarballs or such
[22:38] <maco> well you'd be upstream then ;-)
[22:38] <barry> ScottK: no worries.  ~ubuntu-branches should see it
[22:38] <maco> is it ubuntu-specific?
[22:38] <speakman> it ALL worked when changed to "native"
[22:38] <speakman> not very, it's a simple C program
[22:39] <speakman> no dependencies or anything
[22:39] <speakman> pure libc :)
[22:40] <maco> if it's something thatd make sense to include in other distros, then that sounds like you are the upsteam maintainer of your own project and the packages for it in each distro into which it's included would be regular packages instead of native ones
[22:40] <speakman> and finally pdebuild worked too :)
[22:40] <speakman> now wonder where it put its results... hmmm
[22:41] <maco> ~/pbuilder i think
[22:41] <speakman> nope
[22:42] <speakman> this particular project will never be incorperated into any distros :D
[22:44] <speakman> /var/cache/pbuilder/result/ seems to be where to find the builds :)
[22:44] <ohsix> hm https://bugs.launchpad.net/ubuntu/+source/evince/+bug/661732 this is still happening on natty; what can be done
[23:08] <speakman> 64
[23:08] <speakman> no, 42. sry
[23:47] <chrisccoulson> tkamppeter, i figured out what's causing bug 760644 btw
[23:48] <chrisccoulson> this code is so fragile in firefox, and nobody wants to touch it with a barge-pole though ;)
[23:49] <chrisccoulson> the issue is that the link there has an unregistered mimetype, and it falls back to looking up a handler using the file extension, and that is completely broken :(