[11:01] <waveform> @pilot in
[14:10] <ahasenack> waveform: hi, pi4 question
[14:10] <ahasenack> waveform: I'm issuing a "reboot" remotely via ssh, but it's actually powering off. Have you seen that?
[14:11] <ahasenack> waveform: it's lunar, on 6.2.0-1012-raspi
[14:24] <waveform> ahasenack, no that's definitely odd -- let me try and reproduce here -- I assume we're talking about the server image and not desktop? (no idea why that would make a difference but just in case)
[14:24] <ahasenack> yes, server
[14:24] <ahasenack> I think it was dist-ugpraded ever since the first install
[14:25] <ahasenack> I also don't know what's happening in the console while it's "rebooting", maybe there is a clue
[14:30] <waveform> oh, and arm64?
[14:30] <ahasenack> yes
[14:30] <waveform> (good stuff, I had assumed but always good to check!)
[14:34] <teward> ddstreet: mapreri: email thread coming your way that will need your attention.  Not on the ML for reasons
[15:01] <waveform> @pilot out
[15:05] <waveform> ahasenack, seems to reboot happily for me (with "sudo reboot" over an SSH connection on a fully upgraded system running 6.2.0-1012-raspi), but interestingly it's failing to configure the ethernet after the reboot (or at least it's stuck in systemd-networkd-wait-online). Are you sure it's actually shutting down and it's not just rebooted but the networking has failed?
[15:06] <waveform> oh, but now it has managed to bring eth up ... I wonder what's going on.  That's doubly weird; typically when the Pi is shutdown the red power LED remains lit (there's a series of flashes on the green ACT LED to indicate shutdown, but the power LED remains on because in fact it's just going into an "interrupted reboot" where the boot firmware's waiting for an indication on the GPIO that it's time to wake up again)
[15:15] <waveform> hmm, and thanks for the indication on the wait-online ticket -- just switched out the Pi for one which I hadn't messed with the DHCP config and I'm seeing that timeout as well so I guess the Pi images are affected too
[15:18] <vorlon> @pilot in
[16:04] <seb128> !dmb-ping
[16:12] <teward> i'm late sorry seb128


[19:06] <shrini> godbyk: hai
[19:07] <shrini> you there?
[19:07] <shrini> I started to work with quickshots
[19:07] <shrini> for ubuntu 10.10
[19:22] <godbyk> Hey, shrini.
[19:22] <shrini> godbyk: hai
[19:22] <shrini> :-)
[19:23] <godbyk> Has it been working okay for you so far?
[19:23] <shrini> yes
[19:24] <shrini> http://flan.uguu.ca:5000/ump
[19:24] <shrini> here we can see the project file
[19:24] <shrini> it is not documented anywhere
[19:24] <shrini> will write a blog on this
[19:24] <shrini> but has many doubts
[19:24] <shrini> will ask in the list
[19:25] <godbyk> Good idea.
[19:25] <godbyk> We need to document it so that people can start using it.
[19:25] <shrini> es
[19:25] <shrini> yes


[07:44] <dholbach> Good morning!
[07:50] <bilalakhtar> Good morning dholbach !
[07:50] <dholbach> hey bilalakhtar
[10:20] <alkisg> If my package "Recommends: A", and a user installs it, and later on I change it to "Recommends: A, B", and the user dist-upgrades, will B be automatically installed?
[10:20] <alkisg> Or do I have to use "Depends:" for that to happen?
[10:21] <bilalakhtar> genupulas: you got what you wanted?
[10:21] <persia> Depends on the UI.  Generally the user won't get B.
[10:22] <genupulas> bilalakhtar, i am still in that problem
[10:22] <bilalakhtar> genupulas: describe, please
[10:24] <genupulas> chitti@ubuntu:~/hello-packaging/hello-2.6/debian$ debuild
[10:24] <genupulas> This package has a Debian revision number but there does not seem to be
[10:24] <genupulas> an appropriate original tar file or .orig directory in the parent directory;
[10:24] <genupulas> (expected one of hello_2.6.orig.tar.gz, hello_2.6.orig.tar.bz2,
[10:24] <genupulas> hello_2.6.orig.tar.lzma or hello-2.6.orig)
[10:24] <genupulas> continue anyway? (y/n) y
[10:24] <genupulas>  dpkg-buildpackage -rfakeroot -D -us -uc
[10:24] <genupulas> dpkg-buildpackage: set CFLAGS to default value: -g -O2
[10:24] <genupulas> dpkg-buildpackage: set CPPFLAGS to default value:
[10:24] <genupulas> dpkg-buildpackage: set LDFLAGS to default value: -Wl,-Bsymbolic-functions
[10:24] <genupulas> dpkg-buildpackage: set FFLAGS to default value: -g -O2
[10:24] <genupulas> dpkg-buildpackage: set CXXFLAGS to default value: -g -O2
[10:24] <genupulas> dpkg-buildpackage: source package hello
[10:24] <genupulas> dpkg-buildpackage: source version 2.6-1
[10:24] <genupulas> dpkg-buildpackage: source changed by Administrator<EMAIL_ADDRESS>[10:24] <genupulas> dpkg-buildpackage: host architecture i386
[10:24] <genupulas> dpkg-checkbuilddeps: Unmet build dependencies: autotools-dev
[10:24] <genupulas> dpkg-buildpackage: warning: Build dependencies/conflicts unsatisfied; aborting.
[10:24] <genupulas> dpkg-buildpackage: warning: (Use -d flag to override.)
[10:24] <genupulas> debuild: fatal error at line 1340:
[10:24] <bilalakhtar> !paste | genupulas
[10:24] <genupulas> dpkg-buildpackage -rfakeroot -D -us -uc failed
[10:24] <genupulas> bilalakhtar,  i am getting like this
[10:25] <bilalakhtar> genupulas: Install autotools-dev
[10:25] <bilalakhtar> genupulas: and also set your DEBEMAIL and DEBFULLNAME variables and then re-run dch -e
[10:26] <genupulas> ok
[10:28] <genupulas> bilalakhtar,  i got this in pastebin.com
[10:28] <genupulas> bilalakhtar, We are currently moving to a better server, to allow pastebin to grow more, posting will be allowed again in a minutes
[10:28] <ari-tczew> bilalakhtar: have you done prepared any merges? :>
[10:28] <genupulas> i must wait
[10:28] <bilalakhtar> genupulas: go to paste.ubuntu.com
[10:28] <bilalakhtar> ari-tczew: yes
[10:28] <bilalakhtar> ari-tczew: syncing a package right now
[10:28] <bilalakhtar> ah, synced
[10:28] <bilalakhtar> thanks to syncpackage :D
[10:29] <ari-tczew> bilalakhtar: just I finished work on epiphany-browser.
[10:29] <bilalakhtar> ari-tczew: cool
[10:29] <ari-tczew> bilalakhtar: hmm, but your package should stay in natty queue
[10:29] <bilalakhtar> ari-tczew: yes, it is staying there
[10:29] <ari-tczew> bilalakhtar: what's called?
[10:29] <bilalakhtar> ari-tczew: monotone
[10:30] <bilalakhtar> wait
[10:30] <bilalakhtar> it has not been picked up yet
[10:30] <ari-tczew> bilalakhtar: that;s right
[10:30] <bilalakhtar> ah, ari-tczew it is there now :)
[10:31]  * persia idly notes that traditionally at this point in the cycle merge-work consists of trying to ensure that packages don't need to be merged, rather than performing the merges.
[10:31] <genupulas> bilalakhtar,  done
[10:32] <bilalakhtar> persia: getting big merges tackled early in the cycle is a good task
[10:32] <bilalakhtar> 90% of the merges on M-o-M are new upstream releases
[10:32] <bilalakhtar> which we ignored when maverick reached FF
[10:32] <persia> bilalakhtar, Now, ask yourself, does Ubuntu need to vary?  Why?  What patch do we carry?  Why isn't it in Debian or upsteam?
[10:32] <alkisg> Thank you persia :)
[10:33] <bilalakhtar> persia: that's what! I am sending the patches as well. and just now I syncpackaged
[10:33] <ari-tczew> persia: we just getting changes from Debian. what's wrong?
[10:33] <persia> ari-tczew, There's nothing explicitly wrong, except that I fear for your goals.
[10:34] <persia> And there's rarely any point to an upload now if we have confidence that any variance will be fixed in Debian.
[10:34] <persia> So, for stuff where we *must* vary (like epiphany-browser, where there are branding changes), it makes sense to merge.
[10:34] <persia> for stuff where it's less clear why we vary, it would be better to try not to vary.
[10:34] <persia> Anyway, if you want cool stuff for natty, it's probably better to help Debian release squeeze rather than doing merges.
[10:35] <persia> There's a *very* high chance that everything that has a merge will have another new upstream version in Debian before natty releases.
[10:36] <ari-tczew> persia: I hope that you won't grab my upload access if I won't help Debian too much?
[10:36] <persia> Mind you, if you just want to do merges, that's OK too: I just want to indicate that it's probably worth putting in the effort to not have to merge, and to get the newer stuff for natty.
[10:36] <ari-tczew> my contribution to Debian is sending patches to bug tracker.
[10:36] <bilalakhtar> same case with me
[10:36] <bilalakhtar> that's the best way of forwarding
[10:37] <nigelb> why not check if its a QA package and upload
[10:37] <persia> ari-tczew, It's not like that.  It's that we're not going to get anything new for natty if squeeze doesn't release.
[10:37] <bilalakhtar> if you take over the bug and send an RFS for an NMU
[10:37] <ari-tczew> yea, so I don't understand what we are doing wrong.
[10:37] <nigelb> or ask the maintainer if he's okay with an NMU?
[10:37] <persia> So if we want new stuff, we want to get squeeze released.
[10:37] <bilalakhtar> NMU RFSs slow down in the sponsorship queue
[10:37] <bilalakhtar> on debian-mentors @lists.d.o
[10:37] <bilalakhtar> I had an NMU over there
[10:37] <persia> bilalakhtar, ari-tczew: If you don't want to work with Debian so much, I'll suggest that you'd find it more useful to tackle UEHS until squeeze does release and we get the dump of new stuff.
[10:38] <persia> There's ~1000 packages that need updates there.
[10:38] <persia> http://qa.ubuntuwire.com/uehs/
[10:38] <persia> http://qa.ubuntuwire.com/uehs/no_updated.html is 99 of them with an immediate update needed (please fix lintian, packaging, etc. stuff too)
[10:38] <ari-tczew> persia: I don't like Debian contributing system. Asking for NMU, then waiting for maintainer response, then looking for free DD,..
[10:39] <ari-tczew> sorry, I don't have time
[10:39] <persia> http://qa.ubuntuwire.com/uehs/no_watch.html is 500 that need investigation.
[10:39] <persia> ari-tczew, That's fine.  I'll encourage you to work on UEHS then.  It's not a general thing, but for this cycle Debian is frozen, and likely to unfreeze before we release, so concentration on merges early is likely to all be work that needs to be redone later.
[10:41] <ari-tczew> persia: if have forwarded a lot of patches from Ubuntu and not all were applied by maintainer. My work is done, I'm going to continue merging other packages.
[10:41] <persia> But we have hundreds of packages that need a merge with new upstream that aren't in Debian, and all of those are not likely to need to be done again during natty, so the work is more likely to be part of the release.
[10:42] <persia> ari-tczew, Would you please at least consider UEHS?  Not enough people work on it, and it doesn't require working with Debian, but it is basically all merges.
[10:45] <ari-tczew> persia: I prefer to grab changes from Debian instead packaging from scratch to Ubuntu. sorry. I'm not doing anything wrong and I'll continue my objectives.
[10:46] <persia> ari-tczew, UEHS isn't packaging from scratch: it's just new upstream versions.
[10:46] <ari-tczew> persia: you know that I mean
[10:46] <persia> And I won't tell you not to do that, I just suspect it will have to be redone later anyway.
[10:46] <ari-tczew> s/that/what
[10:47] <ari-tczew> persia: if we reduce a lot of merges this cycle, then we can quickly response to new merges in future.
[10:49] <persia> Sure.  I just don't think merge work done now makes any difference for merge count for natty for most packages.  I suspect large numbers of Debian folk are planning to upload something new once the freeze ends, and I expect that to happen before natty releases.
[10:49] <persia> There are exceptions, but in general.
[10:50] <persia> The main reason I suggest it's worth helping Debian release squeeze is to make that huge dump of uploads (likely thousands of packages) happen sooner, rather than later.
[10:52] <ari-tczew> persia: as I said, I've forwarded changes to Debian and with policy it's OK and enough. From my side, we can close our discussion, because I won't change my point-of-view.
[10:53] <persia> I just don't feel like you understand what I'm saying at all, but I'll stop trying if you prefer.
[10:56] <ari-tczew> would be nice
[11:02] <genupulas> bilalakhtar,  are you free
[11:05] <genupulas> ?
[11:05] <bilalakhtar> genupulas: yes
[11:06] <genupulas> bilalakhtar,  i am at final step
[11:06] <genupulas> may i paste the error here
[11:06] <bilalakhtar> genupulas: paste.ubuntu.com
[11:06] <genupulas> ok
[11:06] <genupulas> bilalakhtar,  wait i will do that
[11:07] <genupulas> bilalakhtar,  i did it ...check it out
[11:07] <bilalakhtar> genupulas: give me the link to the paste!
[11:08] <genupulas> bilalakhtar, http://paste.ubuntu.com/513015/
[11:08] <bilalakhtar> genupulas: What are your DEBEMAIL and DEBFULLNAME variables set to?
[11:08] <genupulas> my name and my mail id
[11:09] <genupulas> bilalakhtar, ^
[11:09] <bilalakhtar> then, paste your debian/changelog to paste.ubuntu.com and give link
[11:09] <genupulas> bilalakhtar,  not getting .please explain me clearly
[11:10] <bilalakhtar> genupulas: paste the content of the changelog file in debian folder to paste.ubuntu.com
[11:10] <genupulas> bilalakhtar, ok
[11:12] <genupulas> bilalakhtar,:http://paste.ubuntu.com/513028/
[11:13] <bilalakhtar> genupulas: run the command: echo $DEBEMAIL and check if the e-mail ID comes there or not
[11:14] <genupulas> coming nothing
[11:14] <genupulas> bilalakhtar, ^
[11:15] <bilalakhtar> genupulas: then run: export<EMAIL_ADDRESS>[11:15] <bilalakhtar> and same for debfullname
[11:16] <genupulas> I MADE IT AS U SADI
[11:16] <genupulas> AS U SAID
[11:17] <bilalakhtar> genupulas: run dch -e and then save and close
[11:17] <genupulas> bilalakhtar,  yes completed
[11:18] <bilalakhtar> genupulas: done? does it build now?
[11:18] <genupulas> bilalakhtar,  so i think next is 'debuild
[11:18] <bilalakhtar> genupulas: yes
[11:20] <genupulas> bilalakhtar,  failed
[11:21] <persia> Try `debuild -S -us -uc` to avoid messing with all the GPG bits for now.
[11:21] <bilalakhtar> persia: It will surely work, but I need to get this person sign that as well
[11:21] <genupulas> bilalakhtar, http://paste.ubuntu.com/513032/
[11:21] <persia> bilalakhtar, Why?
[11:22] <genupulas> persia,  is it for me
[11:22] <persia> genupulas, Sure, but I don't see much of a reason to sign packages except if one is distributing them.
[11:22] <bilalakhtar> genupulas: run debuild -us -uc
[11:23] <genupulas> bilalakhtar, when i am doing debuild i am getting like this
[11:23] <bilalakhtar> genupulas: run debuild -us -uc to get a deb
[11:23] <genupulas> bilalakhtar, chitti@ubuntu:~/hello-packaging/hello-2.6/debian$ debuild -us -uc
[11:24] <genupulas> This package has a Debian revision number but there does not seem to be
[11:24] <genupulas> an appropriate original tar file or .orig directory in the parent directory;
[11:24] <genupulas> (expected one of hello_2.6.orig.tar.gz, hello_2.6.orig.tar.bz2,
[11:24] <genupulas> hello_2.6.orig.tar.lzma or hello-2.6.orig)
[11:24] <genupulas> continue anyway? (y/n)
[11:24] <genupulas> bilalakhtar, ^
[11:24] <TeTeT> Hi, I stumbled over a package that fails to remove, gforge-plugin-mediawiki. I've added a debdiff to bug 435829, is there anything else I need to do to get this fixed eventually?
[11:24] <genupulas> bilalakhtar,  what i have to do
[11:25] <bilalakhtar> genupulas: You didn't follow my steps properly
[11:25] <bilalakhtar> genupulas: You should have renamed the file to hello_2.6.orig.tar.gz
[11:29] <persia> TeTeT, You'll want to subscribe "ubuntu-sponsors" to get someone to look at it for upload.
[11:30] <persia> TeTeT, But you want to rewrite your debdiff: we don't use dpatch to edit stuff under debian/ : just edit it normally.  We only use patch systems for patches to the upstream code, to ease communication with upstream about each patch.
[11:38] <genupulas> bilalakhtar,  i got it man
[11:39] <bilalakhtar> genupulas: okay, good
[11:39] <genupulas> bilalakhtar,  i am very happy about this
[11:39] <genupulas> bilalakhtar,  thank you very much
[11:39] <bilalakhtar> genupulas: you are welcome
[11:50] <TeTeT> persia: ok, will start again then
[11:55] <persia> TeTeT, don't start again :)  Just delete your dpatch (and the series entry), and apply your diff manually.  Re-run debuild -S, and create a new debdiff.  The postrm patch is almost certainly correct.
[11:57] <TeTeT> persia: too late, already done, new debdiff is up, will subscribe ubuntu-sponsors now
[12:00] <ari-tczew> TeTeT: why lucid?
[12:00] <ari-tczew> TeTeT: is it fixed in maverick?
[12:00] <persia> TeTeT, Looks better.  next: you're attempting to upload to lucid.  lucid is frozen.  You'll want to prepare *three* debdiffs: one for natty, one for maverick-proposed, and one for lucid-proposed.
[12:01] <TeTeT> ari-tczew: I doubt that it is fixed in maverick
[12:01] <persia> TeTeT, And you probably want to investigate why/how 4.8 AND 5.0 are in maverick and natty (so maybe 5 debdiffs, maybe 4 and a removal request for natty)
[12:02] <ari-tczew> TeTeT: in debian/changelog: s/Closes/LP
[12:02] <ari-tczew> Closes: is for closing Debian bugs and it's not working in Ubuntu. we use LP: #
[12:03] <persia> TeTeT, I realise this sounds like a lot: we'll keep telling you what to do until you either do it, or you say "Hey, that's too much".  If it's too much, we'll probably help run it through hoops, but we start from the assumption that you'd like to learn the processes as well as fix the bugs.
[12:03] <TeTeT> ari-tczew: ok, changing that
[12:06] <TeTeT> persia: not a problem. I think that it's an easy fix to make removal of the package work and I'm willing to do the debdiff for maverick as well, if it's broken there
[12:10] <TeTeT> hmm, on maverick installing gforge-plugin-mediawiki fails with this error: http://pastebin.ubuntu.com/513058/
[12:12] <ari-tczew> I suggest to remove depend on stricte 4.8 version
[12:12] <ari-tczew> in debian/control
[12:13] <ari-tczew> or require higher version, relatively to maverick's version
[12:29] <persia> ari-tczew, (>= 4.8) isn't strict.
[12:29] <persia> TeTeT, You've reached the fun part: for packages that aren't looked after, sometimes one finds more bugs than one expects :)
[12:31] <TeTeT> persia: he he, yeah. Given that I merely tried to help a guy that asked a question on the apt package how to remove the gforge-plugin-mediawiki, it turns out to be quite a ride
[12:32] <persia> If nothing else, one hopes you find it an educational and satisfying ride.  The results of your work are likely to reach many people indeed.
[12:33] <TeTeT> what I don't understand is why the dependency check fails. gforge-web-apache2 is version 5.0.1+svn10088-1 according to apt-cache show
[12:34] <persia> Might not be able to install that in combination with other stuff.
[12:34] <TeTeT> yeah, looks like it
[12:36] <TeTeT> wow, gforge-db-postgresql creates a random password as it surpresses the debconf question
[12:37] <TeTeT> I fear fixing this package in Maverick is beyond my skills and amount of time I can commit to it, sorry
[12:38] <persia> TeTeT, Unfortunately, policy dictates that we can't fix in Lucid until we've fixed in maverick and natty.
[12:39] <Laney> M too?
[12:39] <persia> Please put as much information as you do have time to discover into the bug.  Regarding skills, we're more than happy to help.
[12:39] <persia> Laney, Yep.
[12:40]  * sebner waves at Laney :)
[12:40]  * Laney roars at sebner
[12:41]  * nigelb rechristens as Simbha from Lion King
[12:41]  * nigelb rechristens Laney as Simbha from Lion King
[12:58] <TeTeT> will do, just fixed the install of gforge-db-postgresql and opened a bug for it
[12:58] <persia> Excellent!
[13:04] <TeTeT> any ideas how to resolve this:  python2.6-minimal (2.6.6-5ubuntu1) breaks gforge-web-apache2 (<< 5.0.1+svn10155) and is installed.
[13:06] <persia> TeTeT, drop 4.8 from natty (this requires a bug), and try to install 5.0.1+svn10088-1 which doesn't break.
[13:07] <persia> Oh, Urgh, it does.
[13:07]  * persia looks
[13:08] <persia> TeTeT, For natty, you probably want 5.0.2-2 from Debian
[13:08] <TeTeT> persia: so a sync request is needed?
[13:08] <persia> For maverick, I'm not sure how to sort that, unless one creates a fake package version that meets the requirement and includes the patch for 10155 which works with python2.6-minimal.
[13:08] <persia> No, it will autosync as long as we don't mess with it in natty.
[13:08] <TeTeT> ok
[13:09] <persia> But other bugs may still exist in 5.0.2-2: if they do, then you'd merge your changes into that version for natty.
[13:09] <TeTeT> sigh, knew that I will run out of time for this - need to prepare my UEC class now
[14:25] <juancito> hola alguno habla español
[14:26] <ari-tczew> juancito: we prefer english
[14:26] <juancito> oks algun canal de motu en español
[14:29] <juancito> hi speak spanish?
[14:36] <juancito> hi speak spanish?
[14:36] <ari-tczew> juancito: who?
[14:37] <ari-tczew> juancito: let's use http://translate.google.com
[14:40] <juancito> Hello my name is victor and I would learn how to package
[14:40] <juancito> to contribute to Ubuntu, where I can learn?
[14:42] <ari-tczew> juancito: hello victor. https://wiki.ubuntu.com/UbuntuDevelopment
[15:03] <persia> juancito, Are the documents making sense for you?  Do you want a few tasks just to get started?
[15:06] <shadeslayer> anyone around to do a universe SRU?
[15:06] <shadeslayer> bug 660537
[15:08] <persia> shadeslayer, 1) you want to subscribe "ubuntu-sponsors" to make the request.  2) There's none of the standard justifications for SRU there: why would it be accepted?  Most importantly, there's no TEST CASE for the verification team to use.
[15:08] <persia> !sru
[15:08] <persia> shadeslayer, And to be clear, I realise "completely broken" means we need to do something, and the new upstream is likely sanest, but still needs the process docs, etc.
[15:08] <shadeslayer> persia: ive written that the data engine now compiles to KDE 4.5.1 standards
[15:09] <shadeslayer> *complies
[15:09]  * persia expects both "complies" and "compiles" are accurate in this case
[15:09] <ari-tczew> shadeslayer: why you don't want ask Kubuntu's motu developers like debfx?
[15:10] <shadeslayer> ari-tczew: ah right debfx is now MOTU :D
[15:10] <persia> ari-tczew, Are you sure he didn't?  This is the place for *all* MOTU.
[15:10]  * persia generally discourages folks asking specific other folks anyway, so that the specific folks can sleep, etc.
[15:14] <RainCT> Who needs sleep anyway? ;)
[15:16] <persia> RainCT, Folks with insufficient etc., I'd guess.
[15:19] <persia> shadeslayer, Thanks for the test case: would you mind adding success and failure criteria (might be "it appears" vs. "it doesn't appear" or similarly trivial)
[15:19] <persia> (yes, I know it was uploaded, but it will still speed the next steps (SRU team approval, verification team verification) if you do this)
[15:19] <shadeslayer> persia: ok ..
[15:19] <shadeslayer> yes :)
[15:22] <persia> I've also unsubscribed the sponsors for now, as it's been pushed to maverick-proposed and natty is closed.  If you want to do a natty debdiff for pending upload, resubscribe: otherwise just get it sync'd from maverick-proposed after the archive opens.
[15:22] <shadeslayer> persia: success criteria is that weather data about that particular location is loaded
[15:22] <shadeslayer> ive added a step 4 describing when it faisl
[15:22] <shadeslayer> *fails
[15:23] <persia> Ah, OK.  It wasn't clear to me that step 3 was success.  Thanks.  Looks like everything is perfect, and just needs SRU team to push it in and can get verified.  Don't forget to get the solution into natty once the archive is open.
[15:23] <shadeslayer> of course
[15:35] <shadeslayer> is it possible to list all available packages from one repo?
[15:42] <persia> shadeslayer, Could you phrase that differently?  I know the answer is yes, but suspect that if I just point you at grep-dctrl you'll get frustrated.
[17:48] <shadeslayer> persia: ok so all packages are put into repos right? we have main, universe, multiverse, then we have PPA's and we also have extra repos from google and all. Is it possible to list all packages from a particular repo, for eg. all packages of Universe, or all packages from the google repo
[18:27] <cody-somerville> shadeslayer, Yes.
[18:27] <shadeslayer> cody-somerville: and the magic command is ..... ? :D
[18:31] <cody-somerville> shadeslayer, persia might have some fancy command to do it but if I had to do it real quick without looking such a command up, I'd download the Packages file from the repository and do: awk '/Package:/ { print $2 }' Packages
[21:58] <persia> shadeslayer, cody-somerville's command is great if you're looking for everything from a random repository.  If you're looking locally, you have all the Packages files in /var/lib/apt/lists : I think you'd have to write something more complex if you want to find out all the packages that would be selected from a certain repository (ignoring ones superceded by newer version somewhere else).  Quick'n'dirty method might be to use for and a
[21:58] <persia> pt-cache.  Richer method might be to use quinn-diff or mdt.
[22:04] <persia> If you're looking for richer filtering, grep-dctrl is designed for that and works against Packages files.
[23:30] <james_w> does someone have a stock kubuntu lucid lying around and can tell me if there is a dbus session bus running when you log in to such a system?