[02:02]  * RAOF continues to not be an archive admin.
[02:02]  * RAOF continues to need to resolve that situation.
[03:08] <mwhudson> yes please, an AA in my timezone (ish) would be useful at times :-)
[05:27] <Mirv> thanks doko. yes still some problem somewhere..
[05:30] <Mirv> RAOF: right, sounds familiar to me from some months ago..
[06:20] <Mirv> seb128: morning! if you're about, please try if you can find some time to get this Qt & KDE transition through.. we're now down to very small selection of update_output.txt I think
[06:21] <Mirv> not counting eg amd64 list that lists some kde language packs, the update_output.txt claims for example i386: camitk-actionstatemachine, camitk-imp, itksnap, jacktrip, kde-spectacle, kubuntu-desktop, kubuntu-full, libcamitk4, libcamitk4-dev, lubuntu-qt-desktop, lxqt-config, nifti2dicom, nifti2dicom-dbg, nomacs, plasma-discover, qnifti2dicom, reminders-app
[06:23] <Mirv> it's starting to be really hard for me to see any problems with those, but for reminders-app I believe it should be removed as I asked in bug #1606531 - it's the only package still depending on transitional package qtdeclarative5-quicklayouts-plugin removed in yakkety-proposed
[06:23] <Mirv> others have picked up Qt 5.6 dependency during build time so they'd need to migrate too, but I don't see any problems with them
[06:39] <Mirv> lxqt-config needed rebuild to transition to libkf5screen7 from libkf5screen6
[06:39] <Mirv> lubuntu-desktop refuses to install because of some (weird?) problem in installing usb-modeswitch, but I can't see why lubuntu-desktop itself would be required to migrate at the same time
[06:40] <Mirv> maybe that's noise in update_output, I've never been good in parsing that file
[06:40] <Mirv> but reminders-app (source and binaries) needs to be removed from yakkety, so please do that
[07:11] <Mirv> we'd definitely need a more eastern archive admin..
[07:18] <Ukikie> Mirv: Howdy.
[07:19] <Mirv> Ukikie: oh hi!
[07:52] <Mirv> ok, so Lubuntu and Kubuntu seeds need to be updated to not depend on obsolete packages
[07:52] <Mirv> meanwhile, archive admins still please remove reminders-app from yakkety
[07:54] <sil2100> We still had that in the archives?
[07:59] <Mirv> sil2100: yes, I've asked for its removal at bug #1606531
[08:18] <Mirv> I have updated Kubuntu and Lubuntu meta packages and plasma-discover's erronous transitional packages.
[08:19] <Mirv> I'm still worried about the remaining packages in update_output.txt and would welcome help in understanding the list and if any of it is serious or not
[09:28] <cjwatson> LocutusOfBorg: Thanks for dealing with Haskell.
[09:28] <LocutusOfBorg> cjwatson, please wait for it to finish before thanking me ;)
[09:29] <cjwatson> LocutusOfBorg: Are you working in order on http://people.canonical.com/~ubuntu-archive/transitions/ghc.html ?  Some surprisingly high-up red there.
[09:29] <cjwatson> LocutusOfBorg: Oh, it normally takes a week or so, I wasn't rushing you :)
[09:29] <LocutusOfBorg> actually I took a different approach
[09:29] <LocutusOfBorg> see in update_excuses what was uninstallable
[09:30] <LocutusOfBorg> and rebuild them
[09:30] <cjwatson> I find that inordinately hard on my brain.
[09:30] <LocutusOfBorg> now, I'm sorting the unbuildable packages and retrying them in the right order
[09:30] <cjwatson> The transition tracker is a much easier format.
[09:30] <LocutusOfBorg> yes, I know thanks, but I prefer to see logs, and understand them this time
[09:30] <LocutusOfBorg> next time for sure I'll see the tracker and trust it ;)
[09:31] <LocutusOfBorg> the main goal is to understand things now
[09:31] <cjwatson> It is true that there are a couple of things on the tracker that you have to know to ignore.
[09:32] <cjwatson> agda* on some architectures and xcffib (due to lack of versioned-provides support in that ben instance) IIRC.
[09:33] <LocutusOfBorg> actually I could build-and-retry-build until stuff is sorted out I guess
[09:33] <LocutusOfBorg> each time waiting for dinstall
[09:33] <LocutusOfBorg> but I prefer the slow "check-each-package" method
[09:34] <LocutusOfBorg> BTW the graphic might have one single big "retry all builds" button instead of clicking on each architecture
[09:34] <cjwatson> I just use ubuntu-build for that.
[09:34] <LocutusOfBorg> and also one "no change rebuild and upload" :)
[09:34] <cjwatson> And a script for that :)
[09:34] <LocutusOfBorg> yep me too
[09:34] <cjwatson> LocutusOfBorg: The problem with not going in order by layers is that you can end up duplicating builds if something in a higher layer fails on some architectures.
[09:34] <LocutusOfBorg> but it might unify the "rebuild messages"
[09:35] <cjwatson> I don't care about that.
[09:35] <cjwatson> LocutusOfBorg: e.g. there's a lot of noise from haskell-vector failing to build on a few arches, which needs to be sorted out before rebuilding anything that b-ds on it
[09:35] <LocutusOfBorg> true
[09:36] <cjwatson> Exciting that it manages to run out of memory on the big arches.
[09:36] <Mirv> cjwatson: can you remove src:reminders-app and its binaries from yakkety?
[09:37] <cjwatson> sorry, I know you're looking around desperately for an AA but I think that's more phone context than I have time to import into my brain at the moment ...
[09:37] <cjwatson> well, maybe this one is simple, moment
[09:38] <Mirv> cjwatson: it is simple, no reverse depends and has lived only in click space since 2014
[09:39] <Mirv> has an old transitional dependency being dropped, so it would be time to get rid of it for good
[09:39] <cjwatson> Mirv: ok, done that one but I'm not going to look at the rest of that bug at the moment
[09:40] <Mirv> cjwatson: no problem, none of that other is urgent
[09:41] <Mirv> and sorry for sounding desperate, it's just because I am :)
[09:41] <Mirv> but making progress too
[09:41] <cjwatson> LocutusOfBorg: you probably want to chase up haskell-vector with #debian-haskell if you haven't already; the discrepancy in which arches it manages to succeed on between Debian and Ubuntu is odd, but maybe it needs to be just a whitelist of arches with good enough compiler support or something instead
[09:43] <LocutusOfBorg> actually I'm retrying them
[09:43] <LocutusOfBorg> lets see how they go
[09:43] <cjwatson> I doubt that will make any difference, but ICBW.
[09:48] <LocutusOfBorg> moved to #-haskell
[10:38] <Mirv> when some archive admin reads the whole today's backlog, I'd like to add I don't know if there's any fix for fulfilling camitk's powerpc dependency which fails to build in proposed due to something not related to these landings: https://launchpad.net/ubuntu/+source/camitk/4.0.0~beta-2build1 -> https://launchpad.net/ubuntu/+source/insighttoolkit4/4.10.0-dfsg1-2ubuntu1
[10:39] <Mirv> so I'd like to ask considering any measures needed for getting the transition done regardless
[10:40] <LocutusOfBorg> camitk is not a blocker for the transition I guess
[10:40] <LocutusOfBorg> Mirv, do you have another opinion? AFAIR I did the rebuilds correctly, and they wre stuck because of qt transition
[10:41] <LocutusOfBorg> no need to retry itk4
[10:41] <Mirv> LocutusOfBorg: well they show up in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt , and I noticed it built in release pocket but not in proposed, so it would block
[10:41]  * Mirv needs to go for 45mins now
[10:42] <Mirv> LocutusOfBorg: but yes I think the release pocket camitk should work fine and I have it installed on my yakkety-proposed, I'm just wondering about the update_output.txt
[10:42] <Mirv> so maybe that's noise
[10:42] <LocutusOfBorg> they show up there, because the qt is not over
[10:44] <LocutusOfBorg> for sure you don't need to remove powerpc, since it is already removed, neither retry itk4 there
[10:44] <LocutusOfBorg> a no change rebuild against qt for every arch might be needed, but please talk to qt folks
[10:45] <LocutusOfBorg> I can say, from *my* itk4 side, everything should be good and in place
[10:46] <Mirv> LocutusOfBorg: there's no qt folks but me
[10:46] <LocutusOfBorg> oh... ok :)
[10:46] <Mirv> LocutusOfBorg: ok, I'll try to fix everything else and see if that keeps visible in the output.txt or not in the easy autohinter section
[10:47] <LocutusOfBorg> thanks, but AFAIK you might need a  no-change rebuild for it and itksnap
[10:47] <LocutusOfBorg> and nifti2dicom
[10:48] <LocutusOfBorg> (I didn't try the above, I don't know how you uploaded the transition and which packages needs rebuilds)
[11:41] <Mirv> why is btw publisher runs taking >1h nowadays at times? and almost never the 15-20mins it used to be
[12:00] <Laney> Mirv: looks like there are quite some issues remaining
[12:04] <acheronuk> Mirv: a package for frameworks backport took 3hrs to publish on LP yesterday. despite people saying it's fine, it's clear there is some big issue with the publisher
[12:06] <Mirv> Laney: yep, help would be welcome fixing those. many are being fixed, but there is for example /usr/bin/ld.gold: --secure-plt: unknown option on powerpc that comes from GCC6, and I don't know how to even workaround that https://launchpadlibrarian.net/277744096/buildlog_ubuntu-yakkety-powerpc.ubuntu-ui-toolkit_1.3.2030+16.10.20160726.4_BUILDING.txt.gz
[12:07] <Mirv> acheronuk: ack.
[12:07] <Mirv> Laney: and I don't know what would be actually wrong with many of the packages that LocutusOfBorg mentioned, I'm trying a no-change rebuild now even though I can't find anything wrong with the packages and I have them installed on my yakkety-proposed
[12:09] <Mirv> acheronuk: I think it's been getting worse and worse, but there has been some amount of issues for weeks
[12:10] <Laney> Mirv: camitk is the new insighttoolkit4 no?
[12:11] <Laney> Mirv: And the previous one didn't build on powerpc/ppc64el either, so that shouldn't matter
[12:11] <LocutusOfBorg> my transition is fine
[12:12] <acheronuk> Mirv: definitely. that was just an extreme example yesterday, but indeed it's been frequently > 1hr for many weeks now and even perhaps degrading more
[12:12] <LocutusOfBorg> at least AFAICT
[12:12] <Laney> LocutusOfBorg: Which one?
[12:12] <LocutusOfBorg> insighttoolkit4 rebuilds
[12:12] <Mirv> Laney: it build depneds on libinsighttoolkit4. so yes I think those shouldn't matter, but can you explain why they are shown in the update_output.txt among with packages that actually have installibility problems? in the Trying easy from autohinter section.
[12:13] <Mirv> LocutusOfBorg: for better or no change, now the rebuilds (I did in a silo) are copied over.
[12:13] <LocutusOfBorg> ok
[12:14] <Laney> I think this ffmpeg is going to clear out some of them (libwebp5 -> 6)
[12:14] <Mirv> ok, and we're getting the kde langpack updates right now too. but that leaves that one powerpc problem preventing ubuntu-ui-toolkit rebuild to fix a s390x problem that would prevent the whole promotion, at minimum
[12:15] <Mirv> ..unless you could force ubuntu-ui-toolkit-autopilot/s390x uninstallability (coming from the upstart problem and newest removals for s390x for it) to get this inch forward before world breaks again
[12:16] <cjwatson> acheronuk: What package name?
[12:16] <Mirv> cjwatson: for example https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-073/+sourcepub/6786564/+listing-archive-extra
[12:16] <Mirv> that's probably 1.5h by now
[12:16] <Mirv> since build finished
[12:16] <cjwatson> I want specifically acheronuk's example from yesterday.
[12:16] <Mirv> ok
[12:17] <cjwatson> Anyway, the thing is normally that it isn't anything very specific, it's death by a thousand cuts.
[12:20] <acheronuk> cjwatson:  kxmlgui in https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging-frameworks I think?
[12:22] <acheronuk> maybe LP rounds to hrs after a point, but it did clearly say when still unpublished "Finished 3 hours ago (took 3 minutes, 48.5 seconds)"
[12:22] <cjwatson> The >1hr run just recently seems to have been mostly due to some very large libreoffice publications which took a long time to shift around internally.
[12:26] <acheronuk> seems quite consistently closer to the 1hr than the old 20 (ish) mins nowadays. i.e. when it publishes in the 20 mins or so it used to, it's a surprise, rather than the norm
[12:28] <cjwatson> The Kubuntu PPAs are some of our largest, so you're going to see a somewhat skewed view.
[12:29] <cjwatson> Looking for the kxmlgui case.
[12:29] <acheronuk> cjwatson: yes, I know is a perception thing as well
[12:31] <cjwatson> acheronuk: As I suspected, the kxmlgui case is an anomaly.  There's a weekly window where we do more time-consuming cleanup and when the normal publisher doesn't run, and you happened to run into that.
[12:31] <cjwatson> Starts at 0559 on Sundays and normally takes a few hours.
[12:32] <cjwatson> Unrelated to Mirv's question.
[12:32] <acheronuk> cjwatson: understood, and I except things like can/do happen. just that on top of the quite clear degrading of the times over the last few weeks/months made that one stand out!
[12:33] <cjwatson> Anyway, as far as I can tell there are no easy fixes.  We do have a plan to restructure things so that we can scale much better, but it is quite a large piece of work so no timescale yet.
[12:34] <cjwatson> That's "diskless PPAs", so we'd start serving files out of the cloud and wouldn't have to rely so much on shifting lots of files onto a single giant system.
[12:35] <acheronuk> cjwatson: again, understood. sometimes there is a simple cause and a simple fix. sometimes, like this as it sounds, it's not that easy.
[12:37] <acheronuk> it's just a tad frustrating when trying to build anything together with a complicated/long dependency tree
[12:37] <cjwatson> Definitely.
[12:37] <cjwatson> This is a case of suffering from our own success.
[12:37] <cjwatson> And I don't mind looking into it because sometimes there is an obvious cause.
[12:38] <cjwatson> I would love to get time for diskless PPAs.  With any luck it will be months not years ...
[12:55] <ogra_> can someone bump the score on https://code.launchpad.net/~ogra/+snap/kernel-test-snap/+build/2573 ? it tells me it will start in 20min since about 3h now ... (and i'm having the same issue with all arm builds since friday)
[13:07] <cjwatson> ogra_: done
[13:07] <ogra_> thanks ... is there an archive rebuild going on ?
[13:07] <cjwatson> no
[13:08] <ogra_> (since this happens since friday already)
[13:08] <ogra_> (also for arm64)
[13:08] <cjwatson> arm64 and armhf are the same builder pool.
[13:08] <ogra_> ah
[13:11] <cjwatson> Maybe we need to make another attempt to get approval for more Moonshot hardware now that we're actually using it.
[13:12] <ogra_> +1
[13:17] <ogra_> well, something changed since friday, before my arm builds were rather fast
[13:17] <ogra_> ARGH ... and i forgot to bzr push before triggering the build ... sigh
[13:21] <cjwatson> ogra_: Just looks like more builds happening really.
[13:22] <ogra_> hmm, k
[13:22] <ogra_> cjwatson, could you bump https://code.launchpad.net/~ogra/+snap/kernel-test-snap/+build/2575 too ? sorry, the firt one was actually wasted
[13:23] <ogra_> *first
[13:23] <cjwatson> See, now you're not stuck in traffic, you *are* traffic ;-)
[13:23] <cjwatson> done
[13:23] <ogra_> haha
[13:28] <LocutusOfBorg> cjwatson, do you happen to know what is going on there? https://launchpad.net/ubuntu/+source/haskell-http-link-header/1.0.1-1build3/+build/10569477
[13:29] <cjwatson> LocutusOfBorg: Nope.
[13:29] <cjwatson> LocutusOfBorg: You could try cancelling it and seeing if it works on a different builder; sagari has somewhat different hardware from the others.
[13:30] <LocutusOfBorg> that was my wondering.
[13:30] <LocutusOfBorg> rescheduling, but I can't force a particular builder
[13:30] <cjwatson> No, but you have an 8/9 chance
[13:31] <LocutusOfBorg> fair enough :p thanks
[13:31] <cjwatson> (I can force it if I have to, but it's cumbersome so I'd rather not bother)
[13:32] <LocutusOfBorg> nah, it is fine
[13:36] <Mirv> can someone figure out why usb-modeswitch refuses to install on yakkety-proposed? it's a real mystery to me.
[13:37] <Mirv> oh, ok, the -data has Breaks on usb-modeswitch << 2.4.0
[13:38] <Mirv> so that breaks installing lubuntu-qt-desktop, shown also in update_output.txt but should be noise since it's not related to Qt and KDE upgrading
[13:39] <Mirv> does anyone know, that if update_output.txt does list eg lubuntu-qt-desktop there as being uninstallable, will it need manual intervention from archive admin via hints if I'd like Qt & KDE to migrate?
[13:40] <Mirv> oh, but, new lubntu-qt-desktop is required so that its erronous dependencies on obsolete KDE packages would be dropped :(
[13:40] <Mirv> cyphermox: would it be a really quick job for you to update usb-modeswitch in Ubuntu, ie sync with Debian, so that ^ blocker for Qt and KDE transition would be gone?
[13:41] <Mirv> it starts to seems I need to fix all of proposed for all packages before this is going to work :(
[13:41] <cyphermox> most definitely not a quick job right now
[13:41] <Mirv> hmm, I wonder if I could revert usb-modeswitch-data then
[13:41] <cyphermox> and I really don't understand why it's a blocker for anything, it really shouldn't be, especially not Qt/KDE stuff
[13:42] <Mirv> cyphermox: because lubuntu-qt-desktop depends on installability of usb-modeswitch, and lubuntu-qt-desktop needs to be updated to drop KDE dependencies that are broken
[13:42] <Mirv> so if lubuntu-qt-desktop cannot be installed, update_output.txt claims it's Qt's / KDE's fault
[13:43] <Mirv> also lubuntu-qt-desktop could temporarily lose its usb-modeswitch dep, that'd be another workaround
[13:43] <Mirv> I'll just go and do something if no-one wants to help
[13:47] <xnox> ..
[13:47] <xnox> please remove dbus-cpp... should be for yakkety
[13:48] <cyphermox> Mirv: I would suggest you revert -data, it's the best thing to do
[13:50] <Laney> Is it intentional that component-mismatches wants to promote the first alternative of an or-ed dependency group if one of the others is in main already?
[13:50] <Laney> i.e. should I fix the report or the package?
[13:52] <Mirv> cyphermox: ok, thank you
[13:53] <cjwatson> Laney: component-mismatches doesn't care what's already in main; it does a from-scratch analysis with germinate
[13:53] <cjwatson> Laney: making it care about the current component overrides would produce weird hysteresis, I think
[13:54] <cjwatson> (and would be difficult anyway ...)
[13:54] <Laney> cjwatson: Righto.
[14:42] <Mirv> still not anyone willing to decipher the update_output.txt remaining problems? so I was interested in why in the autohinter section eg camitk / itksnap would be listed, and also if there's any possibility of ignoring s390x installability issue of ubuntu-ui-toolkit-autopilot for one time if it seems the real fix would take another week or so.
[14:43] <Mirv> throughout the day I've been able to progress on my own though in many places, but it may be I'm at the end of the road now
[14:44] <Laney> Mirv: I uploaded ffmpeg and some other bits to progress it somewhat (should fix camitk)
[14:45] <Mirv> Laney: ok, thank you. what was the problem with it?
[14:45] <Laney> webp transition
[14:46] <Mirv> oh so probably somewhere from the depths of that libinsighttoolkit
[14:46] <Laney> I forgot the chain, but something in there was depending on libwebp5
[14:47] <Laney> No doubt there are one or two other bits left for that one; didn't check
[14:47] <Mirv> anyway, it may be that the UITK s390x issue would be the last one after things settle, but I can't rebuild UITK because of powerpc GCC6 issue, and I can't seem to find a workaround to force it. a real fix would probably be something in qtbase, updating of which would relaunch thousands of autopkgtests and probably find both flaky tests and gcc6 issues, postponing this migration by another week or
[14:47] <Mirv> three
[14:47] <Laney> which hint block are you looking at?
[14:48] <Mirv> Laney: easy: 260+0: a-56:a-31:a-31
[14:48] <Laney> ok, let's see
[14:49] <jbicha> if you need webp first, more uploads are needed https://people.canonical.com/~ubuntu-archive/transitions/html/auto-libwebp.html
[14:49] <Laney> just need a minute to set up the script on snakefruit, since my PC is out of reach
[14:49] <Laney> yep
[14:49] <jbicha> bug 1610066
[15:24] <Mirv> now search for "easy: 245+0: a-47:a-30:a" but actually just search for qtbase in reverse, the last hit is the best looking hint block
[15:24] <Mirv> I need to rest now.
[15:59] <Laney> Mirv: I think the plasma-discover depends on packagekit >= 1.0 is going to cause you trouble
[16:05] <seb128> not close to see the end of that transition...
[16:06] <seb128> Laney, did you get a reply from the unity8 team about click and yakkety?
[16:07] <Laney> No.
[16:07] <Laney> Nothing useful
[16:07] <seb128> :-/
[16:07] <Laney> I'm not happy about this being pushed back again after it was agreed
[16:09] <seb128> I don't think any agreement was changed
[16:09] <seb128> the phone team is not planning devices on yakkety and is fine getting that to regress
[16:10] <seb128> the issue is the new usecase of our (desktop) team wanting unity8 on the default install this cycle now
[16:10] <Laney> So a new requirement is making the previous agreement insufficient
[16:10] <seb128> yes
[16:11] <seb128> well it's up to us
[16:11] <seb128> we can declare that we don't need click
[16:11] <seb128> it's just that today we only have click as a working package installer in unity8
[16:11] <Laney> We have to either do it, or undo what's happened in proposed
[16:11] <seb128> no gnome-software working nor snaps dash integration
[16:12] <Laney> Assuming this plasma dependency is legitimate, that implies some work there
[16:12] <seb128> willcooke, ^ we need to make a call on that
[16:14] <willcooke> seb128, on what exactly?  Your "no g-s working.." comment has confused me
[16:15] <seb128> willcooke, read the backlog from 16:59 on
[16:15] <willcooke> I did, I'm still not sure what you're asking
[16:16] <willcooke> is it "do we move to PK 1.0" in 16.10?
[16:16] <seb128> willcooke, but summary is that the pkgkit 1.0 transition in yakkety-proposed blocks other things including qt/kde stack
[16:16] <seb128> yes
[16:16] <willcooke> in which case, yes
[16:16] <willcooke> yes we move
[16:16] <willcooke> end of
[16:16] <seb128> k
[16:16] <willcooke> tedg is hoping to land support in u8 by EOW
[16:16] <seb128> so no way to install packages today under unity8-desktop
[16:16] <seb128> which is fine
[16:16] <seb128> k
[16:16] <Laney> if it generates pressure to get the work done faster
[16:16] <Laney> ;-)
[16:16] <seb128> dobey said it was some thousand lines of code to review and was probably not going to be that easy
[16:17] <seb128> but let's see
[16:17] <Laney> it's the right call for our team imho
[16:17] <Laney> thanks!
[16:17]  * Laney gives Mirv a shoulder massage
[16:17] <seb128> Laney, either that, or it creates pressure on our team to fix things that we broke
[16:17] <Laney> sorry
[16:17] <willcooke> attent_e looked at what was needed to get g-s working under u8 too
[16:17] <seb128> but yeah, I agree we should do it
[16:18] <seb128> just be ready to get some heat for breaking things
[16:18] <willcooke> but if ted_g is working on a u8 native option, so much the better
[16:18] <seb128> and have to figure a way out
[16:18] <Laney> It's not as if there hasn't been an interminable amount of warning about this problem
[16:18] <seb128> right
[16:18] <seb128> well as said we (desktop) are in charge now of seeding that new session and getting it to work
[16:18] <willcooke> Laney, +1 - we've been talking about it from before this cycle even started
[16:18] <seb128> so it's selftwarning at this point
[16:19] <seb128> but we haven't really been on top of that work (yet)
[16:19] <seb128> anyway the session is what it is
[16:19] <seb128> then we can start discussing bugs between unity8 team and us
[16:29] <seb128> Laney, willcooke, thanks for pushing and acking, I think landing it now is the right thing, we delayed enough
[16:29] <Laney> seb128: merci
[16:29] <seb128> the number of transitions/work that still need to land start being a bit concerning but I guess we can sort out after feature freeze starts
[17:40] <wxl> infinity: a member of our lubuntu team has created merge proposals to implement qt-driven images for lubuntu. this is the future of lubuntu, so it would be really great to have. what's the timeline on this? https://code.launchpad.net/~tsimonq2/ubuntu-cdimage/lubuntu-next-image/+merge/301203 https://code.launchpad.net/~tsimonq2/livecd-rootfs/lubuntu-next-image/+merge/301202
[20:25] <bdmurray> tjaalton: Could you have a look at bug 1610434?
[22:30] <doko_> we need somebody to track the OpenGLes build failures on arm64 ... and remove the packages which don't build anymore
[22:30] <doko_> this is a blocker for transitions, e.g. https://launchpad.net/ubuntu/+source/tulip/4.8.0dfsg-2build4


[02:15] <kdef> help
[02:15] <bazhang> with what
[02:16] <kdef> I want to buy a keyboard with additional language on the keys.... only cheap one I found is a wireless bluetooth one...
[02:16] <kdef> it would be ideal but I don't know if bluetooth works well in ubuntu or not
[02:16] <kdef> any idea?
[02:19] <bazhang> which version
[02:20] <bazhang> this channel is for support of 13.10
[02:31] <kdef> I don't know... I keep updating but
[13:12] <BluesKaj> Hey folks
[15:02] <smallfoot-> Why there is no openness and transparency? You can see no details on what's new in Ubuntu alpha
[15:02] <smallfoot-> there are no news, notes, or anything
[15:03] <smallfoot-> Also why can't you search for saucy packages on packages.ubuntu.com?
[15:06] <IdleOne> packages.ubuntu.com only shows released versions. people using saucy should be experienced enough to know they can use apt-cache search to search for packages.
[15:06] <wilee-nilee> smallfoot- The developments do not reach there until release
[15:08] <IdleOne> as far as release notes goes. Saucy is in alpha, things may work great or they can all explode in a moment.
[15:08] <smallfoot-> but why doesn't anyone fix packages.ubuntu.com so it works with unreleased versions too? any reason?
[15:09] <bazhang> thats not something that needs fixing
[15:09] <smallfoot-> I understand saucy is alpha, but in prior Ubuntu versions, there were always more information and release notes even on alphas
[15:09] <IdleOne> yes, because then users with less experience might start using saucy packages in raring
[15:09] <IdleOne> which is a bad idea
[15:09] <smallfoot-> why is that such a bad idea?
[15:09] <bazhang> release notes? release means...
[15:10] <smallfoot-> I remember 12.10 used to have release notes on alphas
[15:10] <IdleOne> smallfoot-: mixing packages from different versions can cause unexpected behaviour and bugs
[15:10] <smallfoot-> IdleOne, then I think saucy packages should still be browsable, but it should be a
Mixing packages form a different version can cause unexpected behaviour and bugs
 on the page
[15:11] <IdleOne> smallfoot-: or experienced users can use the package managers and we don't have to risk users ignoring warnings
[15:12] <smallfoot-> If users ignore warnings, then that is their fault
[15:12] <IdleOne> I'll remember that next time you ask a support question :)
[15:13] <smallfoot-> Anyone running saucy ? How does it work?
[15:13] <IdleOne> you can download the iso and test it.
[15:15] <ikonia> it's currently full of holes and all over the place. I'd advise you only play with it if you are very confident
[15:16] <smallfoot-> Yeah, but I was wondering if anyone can say "Noooo!! don't do it! don't even think about it, it crashes every hour" or say "I've been using it for months, its rock-solid"
[15:16] <smallfoot-> ikonia, I see! thanks! :)
[15:16] <IdleOne> There is a big warning on the wiki that says " It works but may explode" <-paraphrasing
[15:17] <IdleOne> also you have been testing +1 long enough to stop asking these questions every 6 months
[15:17] <rymate1234> hey guys
[15:17] <smallfoot-> hey, do you know who i am? :D
[15:18] <smallfoot-> hiya! :)
[15:18] <rymate1234> trying to get my wireless drivers from here https://code.google.com/p/realtek-8188cus-wireless-drivers-3444749-ubuntu-1304/ compiled on 13.10
[15:18] <smallfoot-> IdleOne, sometimes I've ran the alpha and beta and it been pretty bad, other times I've run and its been solid
[15:18] <rymate1234> however compiling nets me this error http://pastebin.com/28WYFHfp
[15:18] <rymate1234> how do I fix?
[15:20] <ikonia> thats not going to work with your current kernel at this time
[15:20] <rymate1234> meh
[15:20] <rymate1234> what's the issue?
[15:21] <ikonia> looks like quite a lot of issues, the main one I see is a reference to a function in a header that's different to what it expects
[15:21] <ikonia> but there are a few other errors that maybe worse (but no obvious) and a few warnings which may cause problems
[15:21] <rymate1234> so I just have to wait for a fix?
[15:22] <ikonia> well, not-ones going to fix it unless you feed back to it
[15:22] <rymate1234> I have done
[15:22] <rymate1234> was just wondering if there was a way to fix iy
[15:22] <rymate1234> *it
[15:22] <rymate1234> ah well
[15:23] <ikonia> if you understand how it hooks into the kernel, it probably won't be that bad to change the reference it's making,
[15:23] <ikonia> but that will need to be done either upstream or patched in the ubuntu kernel (doubtful)
[15:23] <ikonia> it could be worse though as I'm only just glancing through your paste
[15:24] <rymate1234> ok
[15:24] <rymate1234> so could I potentially downgrade kernel?
[15:24] <rymate1234> or not
[15:25] <ikonia> errr why would you do that ?
[15:25] <ikonia> I'm not aware of 13.10 offering lower kernel versions
[18:19] <DreamPCs> Hey guys, anyone know how I can change the screen timeout settings (when it blanks the display) in Ubuntu 13.10?
[18:22] <Ampelbein> DreamPCs: "Ctrl-A :" "idle off"
[18:25] <brainwash> Ampelbein: are you sure he is talking about (gnu) screen?
[18:26] <Ampelbein> brainwash: oh. My word, I think you are right. Heh.
[18:28] <DreamPCs> In a terminal?
[18:29] <Ampelbein> DreamPCs: I was thinking you were talking about the program "screen".
[18:30] <DreamPCs> Oh sorry, no I mean X (or I guess Mir in Ubuntu 13.10
[18:30] <Ampelbein> DreamPCs: I guess it depends on the desktop environment.
[18:30] <DreamPCs> Unity
[18:31] <Ampelbein> Don't know then.
[18:31] <DreamPCs> Ok, thanks.
[18:33] <Ampelbein> DreamPCs: A bit of googling unearthed http://askubuntu.com/questions/177348/how-do-i-disable-the-screensaver-lock-in-12-04 - does that work in 13.10 still?
[18:33] <DreamPCs> Damn that was it! Thanks Ampelbein
[18:34] <DreamPCs> I thought it was related to Mir and not Unity, I guess that's why I couldn't find any info on it.
[18:40] <FernandoMiguel> bRoas
[21:43] <joshlegs> hi!


[00:00] <RainCT> ryanakca: it has some little differences... like the h and the r being excanged
[00:00] <azeem> lfaraone: both are orthogonal
[01:50] <binarymutant> I was wondering if it was okay to contact upstream about including gpl info into the source code, and if getting the okay, including a patch with the package?
[02:03] <nhandler> binarymutant: If upstream agrees about having the GPL info in the source (like it should be), I would try and get them to make the changes themself. That way, we don't even need to patch it.
[02:04] <binarymutant> nhandler, I just didn't want to wait for another release to have those gpl paragraphs included in the source code :/
[02:04] <NCommander> directhex, ping
[02:05] <nhandler> binarymutant: It all depends on upstream. Some upstream developers have no issue relasing new versions of the application that only fix minor issues (like the GPL one)
[02:05] <directhex> NCommander, sleepy pong
[02:05] <NCommander> directhex, I have a patch for mono on armel, where do you want it?
[02:05] <binarymutant> thanks nhandler for the info
[02:05] <directhex> NCommander, bugs.debian.org. or if you prefer<EMAIL_ADDRESS>[02:06] <directhex> NCommander, actually, maybe upstream wants it? i could bridge it into novell bugzilla tomorrow
[02:06] <NCommander> directhex, ok, ping me tommorow
[03:13] <persia> nhandler, Note that we're note supposed to patch the license while packaging, which it probably a stronger argument for doing/not doing than most others.
[03:15] <nhandler> persia: Thanks for clarifying. I knew it wasn't commonly done. I also knew it wasn't recommended. However, I wasn't sure if it wasn't allowed.
[03:16] <persia> nhandler, Essentially, the licensing is the license extended to the packager.  Such a license (WTFPL) generally doesn't permit the user to modify the license while not altering the attribution when distributing.
[03:17] <persia> s/WTFPL/WTFPL excepted)
[03:17] <persia> nhandler, So, if you take licensed code, and modify it a bit, and create something different, you can do license cleanup.
[03:17] <persia> (to a limited degree, depending on the license).
[03:18] <persia> If you're just packaging, and claiming that this is upstream source, with upstream licensing, you generally can't.
[03:18] <persia> (again, WTFPL excepted)
[03:19] <persia> (note: for those seeking a definition of "free" that goes well beyond anarchy, the WTFPL is a good choice)
[03:26] <jsmidt> If anyone has time, could you look at the buildlogs for herwigpp in my ppa: https://launchpad.net/~jsmidt/+archive
[03:26] <jsmidt> The build isn't working
[03:27] <jsmidt> It has this error: dh_shlibdeps: command returned error code 512
[03:28] <jsmidt> I'm new at packaging and I am trying to figure out what exactly is going wrong.
[05:41] <edajai> hi
[05:42] <dholbach> good morning
[05:42] <edajai> morning
[05:43] <edajai> i'am confused... i want to contribute to ubuntu project ..but i dunno where to start
[05:43] <edajai> i thought of packaging
[05:43] <dholbach> edajai: what are you interested in?
[05:43] <dholbach> ah great
[05:43] <edajai> programming
[05:43] <dholbach> check out https://wiki.ubuntu.com/MOTU/GettingStarted
[05:44] <edajai> i know c++
[05:44] <dholbach> it links to a lot or resources like the packaging guide, tutorials, videos, etc
[05:44] <edajai> i thought MOTU was for packaging only
[05:44] <dholbach> we fix a lot of bugs too :)
[05:44] <dholbach> so knowing a programming language or two definitely helps
[05:44] <edajai> oh..nice
[05:45] <fabrice_sp> Hi dholbach :-)
[05:45] <edajai> can u please provide me links to relatively less complex bugs that can be easily fixed
[05:45] <dholbach> once you feel like you've played with the toys^Wtools a bit, there's also lists of bugs that might be easy to start with on the wiki page I gave you
[05:45] <nellery> hi dholbach :)
[05:45] <dholbach> hi fabrice_sp
[05:45] <dholbach> hi nellery
[05:45] <edajai> toys^Wtools???
[05:45] <dholbach> tools
[05:46] <edajai> k
[05:46] <edajai> which IDE would u recommend?
[05:47] <dholbach> regarding "^w": http://en.wikipedia.org/wiki/%5EW
[05:47] <fabrice_sp> I need some help with a watch file. I have this line inside: http://sf.net/dvdstyler/DVDStyler-(.*)\.tar\.bz2
[05:47] <dholbach> edajai: just go with any editor you're familiar with for now
[05:47] <fabrice_sp> but I'm getting DVDStyler-1.7.1b1.tar.bz2 as newer than DVDStyler-1.7.1.tar.bz2, when b1 is neta
[05:47] <fabrice_sp> s/neta/beta/
[05:48] <edajai> k
[05:48] <fabrice_sp> How can I get that 1.7.1 is newer than 1.7.1b1 ?
[05:48] <dholbach> fabrice_sp:
[05:48] <dholbach> daniel@lovegood:~$ dpkg --compare-versions 1.7.1b1 gt 1.7.1 && echo TRUE
[05:48] <dholbach> TRUE
[05:48] <dholbach> daniel@lovegood:~$
[05:48] <dholbach> seems that upstream's to blame
[05:49] <dholbach> wow... we're at bug 299776 now
[05:49] <fabrice_sp> dholbach: that's what I thought :-)
[05:49] <fabrice_sp> thanks
[05:49] <dholbach> I guess today we'll get to bug 300000
[05:49] <dholbach> ubottu: not yet
[05:50] <fabrice_sp> do we have stats on bugs/versions? Just curious :-)
[05:50] <dholbach> we should have, if you ask me :)
[05:50] <fabrice_sp> lol
[05:51] <edajai> just curious.. is there any work being done on delta deb upgrades??
[05:52] <persia> fabrice_sp, You might want to look at uversionmangle in the uscan manpage.  changing the 'b' to "~b" might do it.
[05:53] <persia> fabrice_sp, If you do that, you probably also want to adjust 'a' in case upstream releases an alpha, rather than a beta.
[05:54] <fabrice_sp> persia: there have been alpha, so I'll have a look at that! Thanks!
[06:19] <fabrice_sp> It worked! Thanks persia for the solution! This is the line I put: opts=uversionmangle=s/b/~b/;s/a/~a/
[06:20] <persia> fabrice_sp, Would you mind adding some documentation on that hint, and the specific regex to the wiki page on creating watch files?
[06:20] <persia> This is the second or third time I've seen the question, and I think maybe the uscan manpage language isn't accessible to some people.
[06:21] <persia> fabrice_sp, Also, you might consider something like /([a-z])/~$1/ (if I remember perl correctly) to generalize rather than calling two match expressions.
[06:28] <fabrice_sp> persia: I'll have a look at the wiki, but that's true that as it's perl regex, it's not so easy :-)
[06:29] <persia> fabrice_sp, If you can't get the perl syntax right, that's fine.  Just the hint for 'a' and 'b' will probably save a lot of people pain.
[06:31] <fabrice_sp> I'm used to vi, so I know this kind of regex, but as it's perl, it's a bit different. For sure it's not simple :-)
[06:31] <fabrice_sp> Anyway, I'll update the wiki :-)
[06:40] <Hobbsee> rainct: oh, thanks.
[08:38] <slytherin> geser: FYI ... about 20 jboss related packages have entered 'NEW' queue in Debian main. Let's hop our build failures will get solved this time.
[08:43] <eMerzh> if someone can review  my package http://revu.ubuntuwire.com/details.py?package=sqliteman ....
[09:05] <bain> can somebody help me and review http://revu.ubuntuwire.com/details.py?package=teamgit
[09:10] <geser> slytherin: that would be awesome
[09:16] <iulian> bain: It seems that is something like git-cola. http://cola.tuxfamily.org/screenshots.php.
[09:16] <iulian> bain: I will have a look at it when I get back home from school.
[09:16] <bain> iulian, yes its something like git-cola but with different ultimate goals
[09:16] <iulian> Looks interesting, I wonder what it can do.
[09:16] <iulian> OK.
[09:17] <bain> iulian, thanks, is it a bad thing to have two packages doing similar thigns?
[09:18] <iulian> bain: I believe not. But IMHO we should keep the one which is the best.
[09:18] <bain> iulian, teamgit will be the best ;-) (hint i am the author :p )
[09:19] <iulian> Yes, I saw :)
[10:43] <joaopinto> Hello
[10:44] <joaopinto> any MOTUs around ?
[10:46] <persia> Probably about half of the active ones.  Better to ask a specific question, as it collects more interest.
[10:47] <joaopinto> the usual approach I had to ask that specific question every 10 joins or so, without much results, I am trying a new approach
[10:47] <joaopinto> can someone advocate http://revu.ubuntuwire.com/details.py?package=amoebax ? Thanks
[10:48] <persia> Oh.  Yeah.  That question doesn't tend to collect much interest except on REVU days, unless someone is particularly bored.
[10:48] <persia> Also, it's probably better to ask for a review than an advocation.
[10:48] <joaopinto> I already got enough reviews, I believe its the proper time for advocation
[10:49] <joaopinto> 4 months reviewing should be sufficient
[10:49] <persia> Well, a review will result in an advocation if it's ready.
[10:49] <RAOF> Unless you've already got one advocate; once you've got one, advertising the fact is a good idea.
[10:49] <persia> Also, there were only one or two REVU days during intrepid, so it's really only been about 3 weeks that the queue has been being processed much.
[10:50] <persia> RAOF, Good point.
[10:50]  * persia usually looks for one-advocate packages with problems.
[10:50] <joaopinto> persia, the package was already reviewed before intrepid, that counts because the package was not started from scratch
[10:52] <joaopinto> I am confident on the package status, that is why I am asking for someone with the ability to advocate
[10:53] <persia> joaopinto, Where can I get the originals for the art?  Or where is this stated?  I don't see it from my quick look so far, but it appears to be a requirement of the license.
[10:54] <joaopinto> which originals ? The art is contained on the source
[10:54] <persia> joaopinto, The license for the art requires that the recipient be provided with information to collect the originals.
[10:54] <persia> I don't know where the originals live, or anything about them.  If you also don't, I think you've a bit of investigation to do.
[10:55] <joaopinto> "the originals" are contained on the source
[10:56] <persia> Surely that's the distributed copy.
[10:56]  * persia reads the license again
[10:56] <persia> Also, in the ,desktop file, why drop the category "LogicGame", and why add "StartupNotify=true"?
[10:58] <persia> No, it clearly states "You can freely distribute the copies of these works, modified or not, whatever their medium, wherever you wish, for a fee or for free, if you observe all the following conditions: ... specify to the recipient where he will be able to access the originals  (original and subsequent)."
[10:59] <persia> From my reading, it just needs a URL somewhere.  Maybe it's in the README (haven't gotten to that file yet).
[10:59] <joaopinto> persia, that statement applies to derivated/modificated work, the artwork distributed is the "originals"
[10:59] <persia> "modified or not"
[11:00] <joaopinto> persia, the download link is on the top of the copyright, that covers the "originals" availability requirement
[11:00] <joaopinto> regarding startupnotify, what is wrong on using it ?
[11:00]  * persia refuses to argue, but will need to find a link somewhere to advocate with that license
[11:01] <persia> If the application doesn't support it, it hangs a process for 120 seconds.
[11:02] <joaopinto> how is that checked, exit code ?
[11:03] <persia> I'm not 100% sure, but my understanding is that it's a window manager hint callback that the application can use to say "I've started cleanly".  There's a hardcoded 120 second timeout to stop the "Starting application" pointer if it's not supported, but it's best to only use it when it is supported.
[11:03] <joaopinto> persia, be more specific, what link do you need related to the license, there is a link which points to the page from where you can get the original art..
[11:03] <joaopinto> ok, I will update the desktop patch
[11:03] <persia> joaopinto, Yes.  I'll be looking at that.  I've not gotten to it yet.
[11:07] <persia> joaopinto, Your watchfile doesn't work for me.
[11:09] <joaopinto> persia, please post the comments on revu, I will only be able to fix the package later today :\
[11:09] <persia> joaopinto, Oh, sure.  No problem.
[11:16] <eMerzh> persia, if you are in a reviewing mood , please consider watching my pkg (http://revu.ubuntuwire.com/details.py?package=sqliteman) .. thanks a lot!
[11:28] <persia> eMerzh, I'll take a quick look, but am still running the processing for the amoebax review.
[11:28] <persia> eMerzh, No point mentioning debian/patches/00list in the changelog.
[11:29] <persia> Be good to have a README.source
[11:29] <eMerzh> oki thanks persia
[11:29] <eMerzh> ok
[11:30] <persia> Better to use /usr/share/cdbs/1/rules/dpatch.mk than the mess you have in debian/rules
[11:31] <persia> ALso, make triple-sure README isn't ending up in the binary package, as it's useless for end-users, but CDBS might try to include it by default.
[11:31] <persia> Nothing else obvious from glancing through debian/
[11:49] <eMerzh> persia, what should be in the README.source?
[11:52] <persia> eMerzh, http://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource but ideally you want to point at common shared instructions for dpatch.
[12:08] <slytherin> eMerzh: https://wiki.ubuntu.com/README.sourceHowTo
[12:09] <persia> (note especially the note on the top of the page that it is becoming obsolete)
[12:10] <eMerzh> ah ok, thanks slytherin ...how should i point to /usr/share/doc/dpatch/README.source.gz ?
[12:16] <slytherin> eMerzh: no idea. persia, can you please help with that question ^^?
[12:16] <eMerzh> :)
[12:20] <persia> Just some informal text.  Something like "This package uses dpatch for patch management.  Please see usr/share/doc/dpatch/README.source.gz for usage details" or something.
[15:19] <directhex> hm. how much pain and/or stabbing is involved in bundling a non-final RC or pre-RC of something into a release, then SRUing the hell out of it ASAP?
[15:20] <persia> directhex, Heaps.  SRUs should be cherrypicks, except when there is a *very* convincing reason.
[15:20] <jdong> the latter part will be a pain, the former part will not.
[15:27] <directhex> monodevelop has been ancient and crap for ages - but upstream have been warning us not to try and use a pre-release alpha tarball as something to support for months on end. the next major release is due in 3-4 months
[15:29] <persia> Right.  Push to Jaunty,  Track upstream, and get final in the release.
[15:29] <persia> backport final to intrepid/hardy.  Let the cruft remain otherwise.
[15:29]  * persia isn't on the SRU team, but is opinionated
[15:30] <slytherin> directhex: is the situation similar to how it was for FF 3.0 beta in hardy?
[15:30] <directhex> persia, i wasn't actually talking about intrepid/hardy (it needs a new mono stack, so won't happen officially). i really meant for jaunty, since it's likely to miss assorted freezes
[15:30] <directhex> slytherin, AFAIK yes
[15:31] <persia> directhex, If you want to pre-check with MOTU release, send mail to<EMAIL_ADDRESS>describing the plan,and asking for MOTU release acceptance in advance.
[15:32] <directhex> persia, as someone who isn't on the SRU team, but is opinionated, would you back a hardy-ff3-style plan?
[15:32] <slytherin> directhex: You might also consider freeze exception depending on when the final release comes out.
[15:33] <persia> directhex, If you're not SRUing, it's not an SRU decision: it's a Release decision.  Personally, I don't like to see snapshots in releases, but if you're sure you can get a real release for e.g. beta, I'd think it was good (but it's really a MOTU Release decision).
[16:16] <kirkland> nixternal: geser: hey guys ...  would you mind voting on my core-dev application sometime soon?  thanks, cheers.
[16:19] <nixternal> kirkland: I voted a while back
[16:23] <directhex> persia, there we go, ML mailed. i hope i've described the situation adequately
[16:24] <persia> directhex, Cool.
[16:24] <kirkland> nixternal: hey, hmm, i don't see it, in my inbox, or in the threaded archive
[16:24] <kirkland> nixternal: i have your vote for my MOTU, back in September
[16:25] <kirkland> nixternal: this is for core-dev, https://lists.ubuntu.com/archives/motu-council/2008-October/001725.html
[16:29] <nixternal> kirkland: you are right, I sent it to persia only...I just resent it to the list...I apologize for that
[16:30] <persia> So this is why I was sure you'd voted :)
[16:30] <kirkland> nixternal: awesome, thanks ;-)
[16:31] <nixternal> persia: hehe, ya :)
[16:41] <geser> kirkland: I try to get it done today, actually I just wanted to start on it
[16:41] <frafu> Hello, I am trying to add a gconf schemas file to a debian source python debian package, but there remains an entry in the gconf database after uninstalling the package. I described the problem in the following thread: http://ubuntuforums.org/showthread.php?t=984014 Could anybody please tell me where the problem?
[16:57] <kirkland> geser: great, thanks!
[17:08] <frafu> What I don't understand is why "gconf-schemas --unregister onboard.schemas" does not delete everything in the gconf database!? What could be the reason? If somebody has an idea that would be great.
[17:20] <JonReagan> is there any order to the REVU process?
[17:20] <JonReagan> like, the first packages in are the ones that get reviewed first?
[17:22] <mok0> JonReagan: not really
[17:22] <JonReagan> ah, thx
[17:22] <mok0> JonReagan: although we are trying to work through the backlog
[17:23] <JonReagan> ah, lol... yeah I noticed there were quite a few
[17:24] <JonReagan> good problem to have i guess
[17:24] <mok0> It overwhelming
[17:24] <JonReagan> yeah... sorry.  I uploaded mine this morning ;)
[17:24] <mok0> JonReagan: except not everyone who uploads has the stamina to keep going
[17:25] <JonReagan> ah
[17:25] <mok0> So there's a lot of wasted time and effort
[17:25] <JonReagan> ah, that's not good
[17:25] <mok0> And many MOTUs don't really want new software in Universe
[17:26] <JonReagan> ah
[17:26] <JonReagan> well, I'm dedicated on working on my package, so at least that's one not to be worried about.
[17:26] <JonReagan> :)
[17:26] <mok0> JonReagan: There's > 1000 packages to maintain
[17:26] <JonReagan> !
[17:27] <mok0> JonReagan: what package?
[17:27] <JonReagan> openproj
[17:27] <JonReagan> version 1.4, to be exact
[17:27] <JonReagan> it's my first package upload to revu
[17:27] <mok0> JonReagan: I'll take a quick look
[17:27]  * JonReagan does happy dance
[17:28] <JonReagan> oh, thank you so much!
[17:28] <JonReagan> http://revu.ubuntuwire.com/details.py?package=openproj - here's the link
[17:28] <mok0> JonReagan: you've been maintaining this for your own use?
[17:29] <JonReagan> for my own use?
[17:30] <JonReagan> I was hoping that it would find it's way into some repo for Ubuntu, either universe or multiverse
[17:30] <mok0> JonReagan: it's not been in a distro
[17:30] <JonReagan> not included in one yet
[17:31] <JonReagan> Ubuntu will be the first one
[17:31] <mok0> ok
[17:32] <mok0> JonReagan: you need to take the debian/ dir out of the tarball
[17:32] <mok0> JonReagan: since this is not a native package.
[17:32] <JonReagan> ah, ok
[17:33] <JonReagan> to upload the tarball after I have removed the debian folders, is there anything different from uploading the package with dput?
[17:33] <mok0> JonReagan: (I also make a comment on revu)
[17:33] <JonReagan> ah, thanks
[17:34] <mok0> JonReagan: lets get to that later
[17:34] <JonReagan> k
[17:36] <mok0> JonReagan: in debian/changelog, you have to trim it down to the latest version. We are only interested in what happens after Ubuntu submission
[17:36] <JonReagan> ok
[17:37] <mok0> distribution is jaunty not GA
[17:37] <JonReagan> k
[17:38] <JonReagan> just so I'll know... these changes need to be made in the original tarball and then recompiled for upload to revu?
[17:38] <mok0> JonReagan: and version will be (1.4-0ubuntu1)
[17:38]  * JonReagan writes it down
[17:39] <mok0> JonReagan: I am pasting my comments to REVU  as well
[17:39] <JonReagan> thanks!
[17:39] <mok0> JonReagan: did you create a needs-packaging bug on LP?
[17:40] <JonReagan> yes I did... it got marked as a duplicate, however
[17:40] <JonReagan> the other bug was a request for openproj that I had made a year ealier
[17:40] <JonReagan> *earlier
[17:40] <JonReagan> and the request was for an old version
[17:40] <mok0> JonReagan: you need to close the LP bug in the changelog
[17:40] <JonReagan> ok
[17:42] <mok0> JonReagan: debian/control now
[17:43] <eMerzh> after compiling and installing, my package at "dpkg-genchanges: failure: cannot read files list file: No such file or directory" .... anyone has an idea how to fix it? google don't help me much on this....
[17:43] <eMerzh> i change arch from any to all , but always the same pbm
[17:44] <JonReagan> do I need to place a link to the new lp bug in the changelog and debian/control?
[17:44] <mok0> JonReagan: Maintainer is:  Ubuntu MOTU Developers<EMAIL_ADDRESS>[17:44] <mok0> JonReagan: you will be XSBC-Original-Maintainer:
[17:44] <JonReagan> ah, wondered about that... thanks
[17:45] <mok0> JonReagan: Standards-Version is 3.8.0 now
[17:45] <JonReagan> ah... k
[17:45] <mok0> Is there a homepage for this app?
[17:46] <JonReagan> openproj.org
[17:47] <mok0> JonReagan: You need to work more on the long description. Look at the hints in the Debian Maintainers Guide
[17:47] <JonReagan> ok
[17:48] <mok0> JonReagan: Lemme just see if I can find a link for that
[17:49] <JonReagan> oh, thanks... I was hittin up google now
[17:50] <NCommander> AHAHAH
[17:50] <NCommander> I got bug #3000000
[17:50] <NCommander> I got bug #300000
[17:50] <NCommander> :-P
[17:51] <jdong> IT'S OVER 3000000!!!!!
[17:51] <jdong> (sorry :D)
[17:53] <JonReagan> mok0:  I found it
[17:53] <mok0> http://www.debian.org/doc/maint-guide/
[17:53] <JonReagan> thx
[17:54] <mok0> I think this is where I've seen the instructions on how to write a proper long description
[17:55] <iulian> jdong: That should be a bad things, isn't it?
[17:55] <iulian> s/things/thing/
[17:55] <bain> iulian, I fixed the teamgit package according to your comments
[17:56] <mok0> JonReagan: OK I have submitted a comment for your package, which will now appear in the "needs work" section... :-)
[17:56] <JonReagan> ah, thank you so much! :D
[17:56] <JonReagan> you have been a ton of help!
[17:56] <mok0> JonReagan: when you "dput" your changes file next time, it should include a diff.gz file that contains the debian/ dir (and nothing else)
[17:57] <mok0> JonReagan: glad to be of help :-)
[17:57] <iulian> bain: OK, will have a look at it again in a moment.
[17:57] <JonReagan> ah, k thx
[17:57] <mok0> JonReagan: I am not good at Java packages, so I have skipped some things for now
[17:58] <JonReagan> ok, I know some java folks who might be able to help me out on those
[17:58] <mok0> OK, dinnertime :-P
[17:58] <JonReagan> lunchtime for me ;)
[17:58] <mok0> JonReagan: it's more about Ubuntu policy
[17:58] <iulian> JonReagan: You might want to talk to slytherin or geser. They are good at Java packaging.
[17:59] <mok0> JonReagan: where to place things etc.
[17:59] <mok0> Bon appetit! hehe
[17:59] <bain> iulian, judging from mok0's comments my diff.gz contains few files that are not correct
[17:59] <JonReagan> ah, ok.  Thanks!  I will get to work on the stuff you recommended
[17:59] <bain> iulian, will fix and report back here
[17:59] <mok0> iulian: just saw your PM... I'll be back later
[18:00] <JonReagan> ooh, after I finish the fixes, do I need to recompile the original source file?
[18:01] <eMerzh> someone could help me to remove the README from the installed file?
[18:02] <iulian> JonReagan: Build the package and upload it again.
[18:03] <JonReagan> ah, thanks!
[18:03] <iulian> eMerzh: Upstream's README?
[18:03] <JonReagan> thank you so much everyone!
[18:06] <bain> iulian, did the fix please review it whenever possible thanks
[18:06] <eMerzh> iulian, yep the readme about how to compile ,...
[18:08] <iulian> eMerzh: You can remove it from the debian/docs file. Sometimes README files are very useful but sometimes aren't, please double check when you remove it.
[18:08] <iulian> bain: OK, I'm looking at it now.
[18:14] <iulian> bain: I see that it's a native package. Do you want to ship the debian/ dir in the original tarball?
[18:14] <iulian> Or it's just a mistake?
[18:14] <slytherin> geser: do you mind if I work on libjdic-java merge/sync?
[18:14] <bain> iulian,  no i do want to ship it
[18:14] <iulian> bain: Then please remove it.
[18:15] <iulian> Ahh, you do want.
[18:15] <iulian> Sorry, misread.
[18:15] <eMerzh> iulian, i don't have it in a debian/docs ....i haven't a docs file :)
[18:17] <iulian> bain: Remove -0 from the version since it's a native package.
[18:17] <bain> iulian, ok should i do it now or wait for more of your comments
[18:18] <iulian> bain: What's with that debian/clean file? Please add that in the clean target in debian/rules.
[18:19] <bain> iulian, actually i did that acting on your comment "Please merge rm -rf into dh_clean."
[18:20] <bain> i obviously misunderstood
[18:20] <iulian> bain: I didn't tell anything about creating a debian/clean file :)
[18:21] <bain> so i should just add the listing in the rules file in front of dh_clean?
[18:23] <geser> slytherin: no, please go ahead
[18:24] <iulian> bain: $(MAKE) clean should do it for you.
[18:24] <geser> kirkland: done
[18:24] <iulian> bain: Please rename that to [ ! -f Makefile ] || $(MAKE) clean
[18:26] <bain> iulian, make clean does not get rid of these files
[18:26] <bain> i use qmake for generating makefiles and can't figure out how to do that
[18:27] <iulian> bain: Well, I've never worked with qmake so I can't give you any advice about it.
[18:28] <iulian> Perhaps someone from this channel knows?
[18:29] <bain> iulian, ok make distclean will do it, can i change to that?
[18:30] <iulian> bain: If it does, yes.
[18:30] <iulian> In the end we're trying to get rid of unwanted files.
[18:40]  * iulian is going to school to take his notebook.
[18:40] <iulian> I obviously forgot about it.
[18:40] <bain> iulian, ok i have almost fixed all the things you told so far, thanks for your help
[18:41] <bain> iulian, review whenever you get time next chao
[18:42] <iulian> bain: OK, good. Will review it again when I get back home. School is not so far.
[18:43] <bain> iulian, i won't be on irc as this is past midnight here in india please leave a comment ... thanks again for your help
[19:33] <serialorder> anyone around?
[19:34] <geser> depends on what you need
[19:36] <serialorder> well then you are probably not around =)
[19:37] <serialorder> I am interested in contributing, I have read quite a bit of the documentation on the MOTU wiki but the process still seems rather opaque to me
[19:37] <geser> where are you stuck?
[19:39] <serialorder> a lot of the technical parts are pretty clear, retrieving a source, applying a change, rebuilding etc...
[19:40] <serialorder> the hard part is actually finding something that needs to be done, I have looked in launchpad and that is just a bit overwhelming
[19:42] <geser> have you a software/package where are you interested in? if yes, you could check their bugs for example
[19:43]  * geser checks if there are some bitesize tagged bugs
[19:45] <geser> you could also check the pending merges (if you're interested) and work on them (after coordinating with the previous uploader)
[19:46] <serialorder> im going to look around for that
[19:49] <geser> there are many tasks so I often have problems to point people to one specific task as it depends on what someone is interested in
[19:52] <serialorder> I guess I am also not sure of exactly what my interests are, as funny as that sounds
[19:53] <serialorder> sadly, there is not one package that I am absolutely enamored with or anything
[19:53] <serialorder> just sort of want to help fix things
[19:58] <NCommander> hey geser
[19:59] <geser> Hi NCommander
[19:59] <NCommander> geser, how goes it?
[20:00] <geser> good, just to much work has accumulated in the past and this doesn't actually increase my motivation to work on it :(
[20:01] <nixternal> anyone have a good link for docs that would help me setup my own local buildd here at work?
[20:02] <nixternal> would love to have a setup similar to what we have now, where people will upload (dput), and then I have to approve or deny the packages
[20:03] <geser> nixternal: iirc NCommander has already set one buildd up
[20:04] <nixternal> NCommander: you better help me then :)
[20:04] <NCommander> nixternal, aka, you want something with a NEW queue, right?
[20:04] <nixternal> don't want to spend a lot of time doing it, but would like to get it up soon so I can start working on a migration path for our appliances here
[20:04] <nixternal> NCommander: yes
[20:04] <NCommander> nixternal, then you want dak
[20:04] <NCommander> Which kills the "don't want to spend a lot of time doing it" requirement
[20:05] <nixternal> hehe
[20:05] <nixternal> figures
[20:05] <NCommander> It's not that bad
[20:05] <NCommander> WHen do you want it by?
[20:05] <nixternal> next few weeks
[20:05] <NCommander> actually
[20:05] <NCommander> WHere are you in the world nixternal ?
[20:05] <nixternal> I have time to spend on it, just didn't :)
[20:05] <nixternal> Chicago silly
[20:05] <NCommander> right
[20:05] <NCommander> Well
[20:05] <NCommander> Two choices
[20:05] <NCommander> We do it at UDS
[20:05] <NCommander> You give me the couch and I drive to Chicago
[20:06] <nixternal> that could be a viable option actually
[20:09] <NCommander> whihc nixternal which one?
[20:14] <NCommander> nixternal, I can come to Chicago a week and a half from now
[20:14] <ScottK> nixternal: Careful.  He'll do it.
[20:15] <NCommander> ScottK, you know me too well :-P
[20:16] <NCommander> ports.u.c just went down ...
[20:16] <NCommander> bah
[20:18] <NCommander> nixternal, ?
[20:22] <shay> hello
[20:22] <shay> anyone here involved with Xen support on Ubuntu?
[20:26] <nixternal> NCommander: get together at UDS possibly
[20:26] <geser> shay: try #ubuntu-kernel or contacting zul
[20:27] <NCommander> nixternal, you need a build machine the same architecture(s) you want, a machine to run wanna-build and wanna-persue on, and all buildds must be able to send email
[20:27] <shay> thanks geser
[20:27] <nixternal> ya, looking at that now
[20:45] <leonel> ScottK: not all the patches you sent   can be applied
[20:45] <leonel> ScottK: still working
[21:06] <ScottK> leonel: It doesn't suprise me not all of them are relevant to 0.92.1.  Thanks for working on this.  I know it's a lot.
[21:11] <directhex> NCommander, did you file that armel bug yet, or am i not getting mail from bugs.debian.org?
[21:11] <NCommander> I hadn't filed the bug yet
[21:11] <kirkland> geser: cheers!  thanks.
[21:22] <ryanakca> RainCT: ah... he means to stick some # comments in the patchfile ... ## patch_name.diff by Me<EMAIL_ADDRESS>## <Description of patch>
[21:40] <jdong> asac: drive-by: How serious is xulrunner about breaking yelp < 2.22.1-0ubuntu<IP_ADDRESS>? I'm guessing backports should rebuild a yelp.
[21:46] <serialorder> anyone available to answer a quick question?
[21:46] <directhex> no
[21:46] <directhex> nobody
[21:46] <serialorder> its an easy one
[21:46] <serialorder> i think
[21:46] <serialorder> I have performed my first merge
[21:47] <serialorder> I created a new dsc, verified it works with pbuilder and hav created two debdiffs one between the new dsc and the debian dsc and another between the new dsc and the previous ubuntu dsc
[21:47] <serialorder> Basically I followed this guide: https://wiki.ubuntu.com/UbuntuDevelopment/Merging
[21:47] <serialorder> problem is I dont know what to do to get it accepted now
[21:54] <directhex> serialorder, well, file a merge bug on launchpad. that's a good step
[22:06] <geser> serialorder: now the usual sponsorship process applies, see https://wiki.ubuntu.com/SponsorshipProcess
[22:08] <serialorder> apparently launchpad is offline for maintenance right now
[22:10] <savvas> "Launchpad is down from until 23:59 UTC for a code update"
[22:10] <serialorder> im trying to figure out which files i need to attach in launchpad
[22:11] <serialorder> when it comes back online fo course
[22:14] <NCommander> -_-;
[22:20] <NCommander> emgent, poke
[22:20] <directhex> bugs.debian.org isn't down though
[22:23] <NCommander> Now that LP is down ...
[22:24] <binarymutant> does bugs.debian.org publish their uprecords somewhere?
[22:36] <ethana2> I wish bugs were things we could just brutally murder with our own bare hands
[22:37] <ethana2> if my machine sometimes fails to suspend, how do I find out why it did?
[22:38] <ethana2> Meh, back to figuring out what a watch file is..
[22:42] <NCommander> etank, a watch file is a file that check against upstream, and notifies Ubuntu Developers when a new updated release is made available
[22:54] <Yasumoto> so if I've attached a debdiff to a bug
[22:55] <Yasumoto> is there typically anything else I should do to get it in jaunty/backported to intrepid?
[22:55] <Yasumoto> (it includes a testcase in the description)
[22:56] <savvas> I think you have to subscribe the ubuntu sponsors to the bug
[22:56] <savvas> not sure though
[22:56] <savvas> and you'll have to wait, since launchpad is down for maintenance :)
[22:57] <Yasumoto> yeah, haha
[22:57] <Yasumoto> Otherwise I would have added the link
[22:57] <Yasumoto> It's a fix for a program called "xournal" which tablet pc users apparently use a lot
[22:58] <savvas> it will probably make it in jaunty, but as I've seen from other bug reports, it has to stay a bit in jaunty before it gets backported
[22:59] <Yasumoto> yeah, for sure
[23:00] <Yasumoto> thanks savvas :)
[23:01] <savvas> n/p Yasumoto - of course, you can always build a "test" package for intrepid through Launchpad's PPA ;)
[23:01] <Yasumoto> ah
[23:01] <Yasumoto> I totally forgot about PPA
[23:01] <Yasumoto> good idea, that should help a lot :)
[23:02] <Yasumoto> there's a lot of noise on the bug, some people have added .deb's they've made as attachments
[23:06] <etank> NCommander: ok??
[23:07] <etank> oh i see. that was for ethana2 not me
[23:09] <directhex> NCommander, minor tweak needed to apply against 2.0.1
 debian-pkg-mono: directhex-guest * r3774 /mono/trunk/debian/ (changelog patches/00list patches/armel-glibc-2.8.dpatch): Fix armel FTBFS on glibc 2.8
[23:21] <NCommander> directhex, ah, I didn't check to see if it cleanly applied ;-)
[23:21] <directhex> NCommander, there's a platform test in there for iphone
[23:21] <directhex>  #if !defined(PLATFORM_MACOSX)
[23:22] <NCommander> Ah
[23:22] <NCommander> No problem
[23:36] <asac> jdong: gutsy?
[23:40] <jdong> asac: correct
[23:43] <asac> jdong: does it cause issues?
[23:44] <asac> jdong: imo it doesn't interfere with gutsy yelp
[23:49] <jdong> asac: ok, I think you might be right, the check is probably extraneous
[23:49] <jdong> I will do some virtual machine testing and see
[23:49] <jdong> if that's the case then I'll remove that conflicts.
[23:49] <asac> jdong: what conflict?
[23:49] <asac> oh ... the conflict came from the hardy package?
[23:49] <kirkland> kees: ping
[23:50] <jdong> asac: correct
[23:50] <asac> yeah. should be dropped in backport then
[23:50] <asac> all conflicts
[23:50] <kirkland> kees: i'm working with mikeowens on that bogosec package
[23:50] <jdong> asac: ok, thanks
[23:50] <asac> well ... alls app conflicts
[23:50] <kirkland> kees: i wanted to explain one thing here, regarding your questions about rpm and dpkg-dev ....
[23:50] <kees> kirkland: ponng
[23:50] <kees> kirkland: I'm all ears :)
[23:50] <kirkland> kees: those two utilities are required *only* if you want to use bogosec to scan source packages (.src.rpm's or .dsc files)
[23:51] <kirkland> kees: that's why i set them as suggests
[23:51] <kirkland> kees: it'll continue to operate just fine on exploded source trees, and tarballs
[23:51] <kirkland> kees: perhaps Recommends might be better?
[23:51] <kirkland> kees: but i don't think Depends is right
[23:52] <kees> kirkland: fair enough.  it seems like it fails pretty unexpectedly if they're not installed.
[23:52] <kees> I would agree not Depends.  Recommends might be a better idea.
[23:52] <kirkland> kees: yeah, i think i might handle that in the source code itself, do a 'which', and explain the situation
[23:52] <kirkland> kees: coolio, thanks.
[23:52] <kirkland> kees: also, meet mikeowens ;-)
[23:53] <mikeowens> kees: hey kees
[23:53] <kirkland> kees: he's been doing some good work on this one, and conmux;  has a unique interest in packaging things from scratch :-D
[23:54] <kees> heya mikeowens!  :)
[23:54] <mikeowens> kees: thanks for the input
[23:54] <mikeowens> kees: dustin's been great (patient)
[23:55] <kees> I'm looking forward to getting bogosec in -- I like the idea of keeping a time-line of its output for the other packages.  :)
[23:55] <kees> mikeowens: cool!  :)


[20:17] <balloons> ping stgraber you about?
[20:18] <stgraber> yep
[20:19] <balloons> bah -- sorry, I pinged wrong channel -- see #ubuntu-release
[20:19] <balloons> I'm looking for help on the ubuntu-core images