[02:30] <lifeless> why isn't there a linux-image-generic package on armhf ?
[02:39] <mwhudson> lifeless: what would that be?
[02:39] <mwhudson> lifeless: currently kernels are soc-specific
[02:42] <lifeless> mwhudson: maybe a placeholder.
[02:42] <lifeless> mwhudson: I thought the Linaro project was to make the soc-specificness go away?
[02:42] <mwhudson> it's working on it
[02:42] <mwhudson> far from done yet aiui
[02:44] <mwhudson> and will probably never make a kernel that boots on all boards currently supported by ubuntu afaik
[02:44] <mwhudson> more future focused
[03:37] <cpatrick08>  I was wondering if there has any new info on the rolling development, how to activate it.
[06:08] <pitti> Good morning
[06:16] <ion> that
[06:44] <dholbach> good morning
[06:46] <ion> that
[09:47] <mlankhorst> could someone approve xorg-server?
[09:48] <mlankhorst> in raring
[09:48] <pitti> tjaalton: FYI, PPA mesa has run here since the morning
[09:49] <mlankhorst> \o/
[09:49] <pitti> tjaalton: I didn't notice any regression yet, except that bringing up the dash is very slow
[09:49] <pitti> but TBH I don't remember how slow it was with the current raring mesa
[09:49] <mlankhorst> it's slow on llvmpipe too
[09:49] <pitti> slow == I see about 5 "slides" which last ~ 0.2 s each
[09:50] <pitti> so it's far from a proper fading effect
[09:50] <smb> You won't know how slow until you try llvmpipe on an atom... :-P
[09:50] <pitti> smb: oh, I do
[09:50] <pitti> I'm talking about my X201 here (intel arrandale)
[09:50] <smb> pitti, but that is i915 isn't it? That would not be llvmpipe?
[09:51] <mlankhorst> smb: which I did? :P
[09:51] <pitti> smb: yes; I meant that I know how unity feels on llvmpipe on an arm or netbook as well
[09:51] <smb> mlankhorst, Yeah, me too ... unfortunately did not realize the new poulsbro trap
[09:52] <mlankhorst> some old asus eee with pineview graphics, i tried software fallback for giggles
[09:52] <smb> pitti, Ah yeah
[09:55] <smb> mlankhorst, That box is an Intel Atom with gma500 (2D only integrated). By the time anything happens one already things the keypress/mouseclick did not get accepted. There is not really a way around the slowness but having fad-in and -outs for everything does not help either. ;-P
[09:56] <mlankhorst> yeah unity needs to disable whatever is causing the slowness (blur, I guess?) for llvmpipe and slower laptops
[09:58] <seb128> mlankhorst, it does disable it
[09:58] <seb128> on llvmpipe at least
[10:01] <smb> Not sure it would be visible there, in ccsm it "dash blur" was set. But disabling it did not change anything either.
[10:07] <tjaalton> pitti: thanks for testing!
[10:07] <tjaalton> pitti: about the slowness; is it any worse than before?
[10:07] <pitti> tjaalton: would it be helpful to downgrade to raring again, and compare?
[10:07] <pitti> ah, snap :)
[10:07] <tjaalton> yeah
[10:07] <pitti> tjaalton: ok, will do
[10:07] <tjaalton> libgl1-mesa-dri, -glx should do
[10:08] <tjaalton> hmm or not
[10:08] <pitti> I'll just use ppa-purge
[10:08] <tjaalton> ah, right
[10:31] <mpt> A crash in apport-retrace? That must mean I win a prize of some sort.
[10:31] <mpt> Now, will that crash itself be retraced...
[10:32] <pitti> mpt: no need to retrace Python crashes :)
[10:41] <pitti> tjaalton: dash reveal/hide is a lot faster with raring's mesa
[10:43] <tjaalton> pitti: bah
[10:43] <tjaalton> so it's gen5 too..
[10:43] <tjaalton> gen6%7 got fixed
[10:44] <tjaalton> the regression that is
[10:58] <mitya57> pitti: any news about https://code.launchpad.net/~mitya57/debian/sid/calibre/remove-embedded-libraries/+merge/157195 ?
[11:00] <pitti> mitya57: still on my list; last week was too short (holidays) and too busy (psql security update), sorry
[11:02] <mitya57> thanks pitti!
[11:02] <mitya57> Maybe I'll look at some of the "Known issues" this week
[11:05] <tjaalton> pitti: do you think the performance is so bad that it would block the update? anholt isn't online so can't ask how long it would take to get fixed
[11:36] <Riddell> jtaylor: you added a patch to pyqt?
[11:36] <pitti> tjaalton: it's certainly bearable, but it looks quite ugly
[11:36] <Riddell> jtaylor: I think it's making pykde fail
[12:13] <dpm> Hi all, I don't seem to be able to properly boot my laptop anymore on raring: I get this error - "mountall: could not mount filesystem: /boot"
[12:14] <dpm> Any ideas on what I could do or look at to fix it?
[12:14] <dpm> I've ran fsck and it complains about "ext2" filesystem not recognized
[12:16] <cjwatson> ext2 might be modular and for some reason missing or unloaded
[12:18] <dpm> cjwatson, I'm not sure. For some reason, if I skip the prompt to load /boot, the system boots to lightdm, I can then log in, but there is no network
[12:21] <dpm> I've now removed the hard disk, plugged it into my desktop, and after entering the encryption passphrase nautilus tells me it cannot mount it due to an unrecognized file system
[12:25] <dpm> does anyone know how I can mount the encrypted volume from the command line? That might give me more of a clue what the error is
[12:41] <pitti> dpm: udisksctl unlock -b /dev/sdXXX; udisksctl mount -b /dev/mapper/XXX ?
[12:44] <dpm> let me try
[12:45] <pitti> dpm: oh, this won't work in an initramfs shell, if you meant that
[12:45] <pitti> (just read some backscroll)
[12:51] <dpm> pitti, I've got the disk attached to my desktop PC now, I thought I'd run fsck over it. I've tried to mount it with nautilus and it fails after entering the encryption passphrase. I'm trying to mount it manually now. I tried these instructions: http://askubuntu.com/a/63598/9781 but the "sudo mount /dev/mapper/my_encrypted_volume /media/my_device" step fails with "mount: unknown filesystem type 'LVM2_member'"
[12:51] <dpm> so shall I try your commands now, as in "udisksctl unlock -b /dev/sdb5; udisksctl mount -b /dev/mapper/5" (where sdb5 is the encrypted partition)
[12:56] <dpm> pitti, I'm poking a bit in the dark here, so I'm not sure I did it right, but here's what I did: http://paste.ubuntu.com/5689323/
[13:01] <pitti> dpm: what does sudo blkid -p /dev/mapper/luks-9cf37a83-e84a-4b85-9bba-7bcbaba8058e say?
[13:03] <dpm> pitti, $ sudo blkid -p /dev/mapper/luks-9cf37a83-e84a-4b85-9bba-7bcbaba8058e
[13:03] <dpm> /dev/mapper/luks-9cf37a83-e84a-4b85-9bba-7bcbaba8058e: UUID="d7SXgb-eMNG-0jiA-E3EA-L0M2-VsSJ-3r5Xmo" VERSION="LVM2 001" TYPE="LVM2_member" USAGE="raid"
[13:03] <mlankhorst> can some sru admin approve xserver-xorg-video-nouveau in quantal-proposed?
[13:03] <dpm> I believe it trips on the LVM2_member bit, which is where the other instructions I tried where failing
[13:03] <pitti> dpm: oh, so it's partition-on-lvm-on-luks
[13:04] <pitti> I had expected our dmsetup/udev rules to automatically create the LVs for those
[13:05] <dpm> pitti, I've no idea what it is, that's what the installer created when I installed (I think) quantal on that hard disk
[13:05] <dpm> is there a way to mount it, so that I can try to recover my data?
[13:06] <pitti> dpm: is that your only PV?
[13:06] <dpm> what's a PV?
[13:06] <pitti> dpm: recent dmesg output might help to see what went on
[13:06] <pitti> "physical volume", i. e. the bits a VG (volume group) is built from
[13:08] <pitti> dpm: wait, /dev/mapper/ubuntu-root, was that created by the udisksctl unlock command, or is that your desktop's LVM?
[13:10] <xnox> dholbach: can you RT my twitter status to ubuntudev and collect answers? =) https://twitter.com/tdlk/status/321248213959069696
[13:10] <xnox> dholbach: webteam is pondering how to convey the answers to those questions in less than 140 characters ;-)
[13:10] <xnox> (as that's the space we have on the website for such text)
[13:10] <dholbach> xnox, I collect answers?
[13:11] <xnox> dholbach: just retweet it on the @ubuntudev to get exposure.  I will monitor the replies =)
[13:11] <dholbach> ah ok - sure :)
[13:11] <dpm> pitti, to the first question: here's what the laptop disk I'm trying to recover looks like partitionwise: http://pastebin.ubuntu.com/5689356/
[13:11] <xnox> dholbach: I'm not "popular" on twitter =)
[13:12] <dholbach> xnox, we could do the same on G+? there might be even more replies there
[13:12] <pitti> dpm: I meant, are you using full disk encryption on your desktop (i. e. the machine you just plugged this in)?
[13:12] <pitti> dpm: i. e. is /dev/mapper/ubuntu-root from your current host, or actually from the plugged in device?
[13:13] <pitti> dpm: it might be that /dev/mapper/ubuntu-root is just the one you want to mount
[13:13] <pitti> dpm: sorry, back in 45 mins; I hope someone else can jump in in the meantime
[13:13] <dpm> pitti, I don't use full encryption on my desktop, just home directory encryption IIRC
[13:13] <xnox> dholbach: sure =) but please add "In less than 3 sentences." Cause G+ allows one to write essays......
[13:13] <pitti> dpm: otherwise, I'll need the contents of /dev/mapper/ before "unlock" and dmesg after
[13:13] <dpm> pitti, no worries, thanks for all your help
[13:13] <dpm> ok
[13:13] <pitti> dpm: ok, so udisksctl mount -b /dev/mapper/ubuntu-root it is
[13:14] <dpm> pitti, it worked! \o/
[13:15] <dpm> pitti, ok, now I'll save all data first, and then will try to find out what's going on. Is there any extra step I need to do to unmount the encrypted volume?
[13:50] <Pjotr> Hello, I have a question about the Ubuntu download page
[13:51] <Pjotr> Perhaps it's a good idea to present the LTS version as the primary eye-catching download option. Not as a "mere"second option. So that beginners with Ubuntu, will usually pick the LTS.
[13:51] <Pjotr> Reason: as we know, starting with Raring, support for intermediate ("standard") releases will be halved to nine months.
[13:51] <Pjotr> As Mark Shuttleworth said: "Our working assumption is that the latest interim release is used by folks who will be involved, even if tangentially, in the making of Ubuntu, and LTS releases will be used by those who purely consume it." http://www.markshuttleworth.com/archives/1246
[13:51] <Pjotr> The main issue here is support period, I think. It's not nice for a beginner to be forced to upgrade very quickly...
[13:51] <Pjotr> What do you think?
[13:54] <jcastro> I believe there's a bug open to change the page to default to LTS
[13:54] <jcastro> I know I've seen it, I just don't have it handy
[14:05] <stokachu> is there a "mentor" irc channel for someone like bug 1165927
[14:07] <dobey> stokachu: #ubuntu-bugs maybe? (is that even a channel?)
[14:08] <stokachu> ah looks to be the closest thing
[14:08] <stokachu> thanks dobey
[14:09] <pitti> dpm: \o/
[14:09] <dobey> i'd mark it invalid with a note that they need to be filed separately. if one doesn't have the time to file bugs separately, i haven't got time to sort through the crap and fix them either :)
[14:09] <pitti> dpm: eject it in nautilus, or udisksctl unmount -b /dev/mapper/
[14:09] <stokachu> dobey: agreed
[15:00] <dpm> pitti, thanks!
[15:00] <dpm> dobey, sorry it took a while, approved the e-mail now
[15:04] <dobey> dpm: thanks
[15:16] <dholbach> barry, thanks
[15:18] <barry> dholbach: sure thing
[15:34] <doko> DktrKranz, could you have a look at https://launchpadlibrarian.net/136234437/buildlog_ubuntu-raring-armhf.pyexiv2_0.3.2-5ubuntu1_FAILEDTOBUILD.txt.gz ? looks like scons does add the arch specific include path only
[15:41] <doko> jodh, cking: $ apt-cache -n search smatch
[15:41] <doko> $
[15:42] <DktrKranz> doko: probably not before the weekend, unfortunately
[15:49] <jodh> doko: it's not in the archive, apparently as it specifies no license.
[15:49] <stokachu> dobey: hopefully these new patches dont suck
[15:50] <zaytsev> cjwatson: hi colin, could you please be so kind to tell me if scripts/casper-bottom/25adduser runs with set -e or set +e? there is nothing at the top of the script. the reason why i'm asking is that i'd like to know whether everything will break if i just delete /usr/share/applications/ubiquity-gtkui.desktop or it will work still
[15:51] <zaytsev> cjwatson: the reason why i'm looking for a solution as simple as deleting the file is that i want to avoid rebuilding the ram disk if at all possible
[15:51] <stokachu> dobey: didn't see your attachment until now :\
[15:51] <stokachu> dobey: fortunately it is the same as yours
[15:52] <dobey> stokachu: it is not the same :)
[15:53] <dobey> stokachu: you applied my changes to the packages from the wrong pocket
[15:54] <stokachu> i pulled from whats out in the archive
[15:54] <dobey> you pulled from the release pocket, not from proposed
[15:55] <stokachu> damnit
[15:56] <cjwatson> zaytsev: +e, although you do need to make sure that the last command in the script exits 0
[15:56] <cjwatson> zaytsev: (but that should be fine here)
[15:57] <zaytsev> cjwatson: thank you very much! it seems to work
[16:05] <infinity> BenC: *nudge*
[16:06] <infinity> BenC: I can haz linux-ppc rebase?
[16:12] <stokachu> dobey: do you mind looking over my precise debdiff now?
[16:13] <zyga> xnox: ping
[16:14] <zyga> xnox: I've got most of the data now ready, I will probably have the first version of the new data file for raring x86 amd64 this evening
[16:14] <xnox> awesome.
[16:14] <zyga> xnox: if my mirror is not finished on time I will have evetything by tomorrow
[16:14] <zyga> xnox: I had a look at the new data
[16:14] <zyga> xnox: I will need to go through some manual cases (currently about 200 of them) to manually extract alternative updates
[16:15] <zyga> xnox: but it looks better than old data already
[16:15] <xnox> hmmm...
[16:15] <xnox> zyga: if it has upstart-monitor in it, I will be happy =)
[16:15] <zyga> xnox: with the exception of certain packages that are in the manual section (like vim or emacs)
[16:15] <zyga> xnox: let me check :)
[16:15] <zyga> xnox: althouh u- is far in the mirror, I'm earlier than that :)
[16:16] <zyga> xnox: unlike the old solution this one is very correct
[16:16] <zyga> xnox: and should have no false positives
[16:16] <xnox> cool.
[16:16] <zyga> xnox: and absolutely no missing items
[16:16] <zyga> xnox: I wrote a post about c-n-f just now, it's on planet ubuntu
[16:16] <zyga> xnox: so maybe there will be more interest in fixing the actual user experience for remote uers
[16:17] <zyga> users
[16:17] <xnox> =)
[16:21] <t1mp> mhall119: ping
[16:28] <jbicha> hi, could someone from the SRU team take a look at bug 1128804? it's been sitting in the quantal queue for 6 weeks now
[16:37] <infinity> jbicha: Can you do me a favour and nudge me about that again in ~3h?  I have a series of poking and prodding appointments to get to today, but will be SRUy when I get back.
[16:39] <jbicha> infinity: sure, thanks
[16:40] <mhall119> t1mp: pong
[16:40] <t1mp> mhall119: I was just reading http://mhall119.com/2013/04/building-an-ubuntu-sdk-app-rev-1/
[16:40] <t1mp> mhall119: nice post. But I noticed something with the header that I though I might help with
[16:41] <t1mp> mhall119: the spacing between the header and first list item is a bit too big. If you do not set anchors for Page/PageStack/Tabs, it should all be automatic for you.
[16:41] <t1mp> mhall119: but since I pinged you I noticed 2 things: 1. You use a custom header in newer revisions, and 2. In raring archives is 0.1.38 of the ui-toolkit and I fixed some header behavior/spacing in 0.1.39.
[16:42] <cking> doko, you're most welcome to package up smatch ;-)
[16:44] <t1mp> t1mp: so my comments may not be that valid anymore.  But if you want to use the SDK header you can always ping me if there are issues with it. :)
[16:44] <t1mp> mhall119: ^
[16:46] <BenC> infinity: Yep, will do within some hours
[16:47] <mhall119> t1mp: reading and eating at the same time, I'll be a bit slow
[16:47] <t1mp> mhall119: ok :)
[16:47] <mhall119> t1mp: yeah, the header's behavior changed between when I wrote that code and when I went back for a screenshot
[16:48] <t1mp> mhall119: if you want to try stuff with the SDK header, make sure you have qtdeclarative5-ubuntu-ui-toolkit-plugin version 0.1.40 because since 0.1.38 some issues were fixed.
[16:49] <mhall119> t1mp: ok, do we have updated docs I can push to developer.u.c/api/?
[16:49] <mhall119> some things there look out of date too
[16:49] <t1mp> yes! we have updated docs.
[16:50] <t1mp> it is out of date, but I don't know the process to get it from our bazaar repository to the website
[16:50] <mhall119> where?
[16:50] <t1mp> the documentation is automatically generated from the source with qdoc.
[16:51] <t1mp> mhall119: if you check out lp:ubuntu-ui-toolkit there is a documentation/generate_html.sh that creates the html.
[16:51] <mhall119> dpm: ^^ can we automate that on developer.u.c?
[16:52] <t1mp> mhall119: there are big changes with a bunch of new examples for pagestack, page, mainview, tabs
[16:53] <t1mp> ^+ToolbarActions
[16:53] <mhall119> t1mp: and there are all in the PPA for quantal, as well as the archives for raring?
[16:55] <t1mp> mhall119: no, I just discovered that they are not.
[16:55] <t1mp> mhall119: they are in our ppa https://launchpad.net/~ubuntu-sdk-team/+archive/ppa/+packages but not in the raring archives
[16:55] <t1mp> mhall119: but I'll check with Mirv tomorrow to figure out how to get it in the raring archives automatically
[16:56] <dpm> t1mp, mhall119, yeah, we can automate it when the Ubuntu theme is integrated into the documentation for the SDK. I've got a merge proposal I sent quite a while ago for that. If someone could help with getting that in, it'd be a lot less painful to update the documentation on d.u.c -> https://code.launchpad.net/~dpm/ubuntu-ui-toolkit/developer-style-api-docs/+merge/152564
[16:57] <t1mp> greyback: you were reviewing that. Is there still something that needs to be fixed?
[16:59] <greyback> t1mp: see the last comment I made. Those were my thoughts at the time
[16:59] <t1mp> dpm: I get the same warnings as greyback mentioned.
[16:59] <t1mp> dpm: some css files are missing
[16:59] <t1mp> greyback: ok thanks
[17:00] <dpm> t1mp, greyback I haven't looked at that branch in a while, let me do it now
[17:00] <t1mp> dpm: thanks
[17:01] <greyback> dpm: I'm still not liking that you integrate the whole theme into the SDK's repo. I'm surprised there isn't some server-side magic to add standard headers & footers to a bunch of HTML
[17:01] <t1mp> dpm: can you bzr merge lp:ubuntu-ui-toolkit to avoid problems with merging?
[17:01] <greyback> dpm: it'll do, of course. It just means lots of duplicate code spread around
[17:01] <dpm> t1mp, greyback, how are you getting those warnings? I'm running the generate_html.sh script and it does not give me any warnings
[17:02] <t1mp> dpm: maybe you need to add the css files to bzr because we don't have them.
[17:02] <dpm> timp, I've just checked out the branch to /tmp, they are in bzr
[17:02] <greyback> dpm: run the 'qmake' command. It's the build system we're using. Some file paths specified in the qdoconf files are not correct
[17:02]  * t1mp otp
[17:03] <t1mp> brb
[17:03] <dpm> greyback, from the top of the source tree, or on the documentation/ folder?
[17:03] <greyback> dpm: top
[17:03] <dpm> ok, trying that now
[17:03] <mhall119> greyback: in the future I would like to import qdoc output into a Django site that will add the theming
[17:04] <dpm> greyback, in terms of server magic, I don't know of any way, so I'm open to any suggestions. In the future, as Mike is saying, we want to generate documentation differently
[17:04] <greyback> mhall119: sounds great!
[17:04] <greyback> dpm: ok
[17:05] <mhall119> greyback: but I'm going to need some qdoc expert help
[17:05] <greyback> mhall119: we'll be happy to help
[17:06] <mhall119> cool, thanks
[17:10] <jtaylor> Riddell: re pyqt, yes how does pyqt fail?
[17:11] <jtaylor> Riddell: I doubt its the patch but the change that forced as to add the patch
[17:14] <dobey> stokachu: better :)
[17:14] <Riddell> jtaylor: it was the patch, I've fixed it now
[17:14] <jtaylor> Riddell: have you forwarded it then?
[17:14] <jtaylor> Riddell:  its a patch from upstream
[17:17] <Riddell> jtaylor: yes, fix from upstream
[17:18] <jtaylor> good
[17:19] <jtaylor> somewhat bad that we have 4.10 in raring as it so buggy :/
[17:19] <jtaylor> + the usual 10 version issues in other softare
[17:20] <tedg> If I've got a binary package that another package has a build dep on it.  Will that package stick around until that build dep is changed?  Or does the non-purge only happen for binary deps?
[17:24] <bdmurray> Where does software-properties get the list of mirrors from?
[17:38] <cjwatson> tedg: it'll stick around in general, although if the package *version* changes such that the build-dep isn't satisfied any more then we probably won't notice that until the next test rebuild
[17:38] <cjwatson> removals are all manual though and we check both runtime and build dependencies for those
[17:52] <dobey> doh, dpm is gone already?
[17:53]  * dobey wonders if anyone else has moderator access to ubuntu-translators@
[17:56] <stokachu> dobey: cool thanks man
[18:06] <tedg> cjwatson, Ah, cool.  We were curious about API transitions, how quickly we have to update.  For instance if the next branch landed has to have the update.  It sounds like no, which makes our lives easier.  Thank you.
[18:07] <stokachu> jodh: ping
[18:08] <stokachu> jodh: unping, roaksoax: ping
[18:22] <jtaylor> doko: we should update numpy in raring, it has some bad bugs, I can probably do so this weekend
[18:22] <jtaylor> to 1.7.1 bugfix release
[18:29] <doko> jtaylor, will this include a scipy update?
[18:30] <jtaylor> why?
[18:30] <jtaylor> there is no bugfix release for scipy in raring so far I know
[18:30] <jtaylor> we don't want 0.12 yet
[18:30] <jtaylor> it has major changes = high regression change
[18:30] <doko> please check that the scipy inraring builds with the updated numpy
[18:31] <jtaylor> it does
[18:31] <jtaylor> its only a bugfix release, no api changes
[18:31] <jtaylor> also we got autopkgtests for scipy
[18:32] <doko> ok
[18:33] <tjaalton> pitti: can you open a new bug about the arrandale mesa regression upstream on bugs.fd.o?
[18:34] <tjaalton> or maybe just lp, I can forward it
[20:12] <cjwatson> tedg: it has to be soon after; by default, a transition that involves changing library names won't land in raring (as opposed to -proposed) until all reverse-(build-)dependencies have transitioned
[20:13] <cjwatson> tedg: so the "no automatic removal" thing doesn't mean that this is something that can be put off - incomplete transitions become blockers for other people's work
[20:15] <tedg> cjwatson, So what gets blocked?  New versions of the lib or new versions of the apps using the lib?
[20:20] <cjwatson> tedg: yes
[20:20] <cjwatson> sets of packages entering raring must form a coherent whole that doesn't regress installability; by default (though it can be forced with a very good excuse), this includes assuming that all no-longer-built-from-source binary packages are removed from the archive
[20:21] <tedg> cjwatson, Okay, so if someone was developing the package they'd still have the old versions until the trunk of their package updated.  So that works for my use-case.
[20:41] <bdmurray> slangasek: any ideas about bug 1163920?
[20:44] <slangasek> bdmurray: hmm, nope.
[20:45] <slangasek> bdmurray: if update-notifier didn't also generate a traceback, then I think the only way to debug it is to get a reproducer case first
[22:27] <Plouj> hi
[22:28] <Plouj> How can I check if a package in my personal repository is signed correctly?
[22:28] <Plouj> Also, what kind of a check can I perform on my repository if I get a BADSIG error all the time, like this: http://askubuntu.com/questions/1877/what-is-the-easiest-way-to-resolve-apt-get-badsig-gpg-errors ?
[22:33] <sarnold> Plouj: from that question, the answers that show how to delete the lists and remove those lists from any cachers you may be using, looked the most useufl
[22:35] <Plouj> sarnold: that doesn't work for me because I've tried those steps, and it actually happens on a clean Lucid install
[22:35] <Plouj> _and_ I'm the owner of the repo in question so I'm sure it's my fault, not some caching funkyness
[22:36] <Plouj> I don't use any cachers that I know of
[22:39] <sarnold> Plouj: aha.. hrm. I think you ought to be able to compare the md5/sha1 sums of packages against that in the package lists using standard md5sum and sha1sum programs...
[22:39] <sarnold> Plouj: I _think_ only sources actually get signed; the binary packages are protected by having their hashes in the lists, and then the lists are signed
[22:40] <sarnold> Plouj: perhaps your list signing operation is broken? is that key expired?
[22:42] <cjwatson> while source packages are signed for the purposes of upload, as far as apt etc. is concerned they're verified in exactly the same way as binary packages, not by checking the signature on the .dsc
[22:48] <Plouj> humm, the files listed in Release have the right md5sum sums
[22:51] <Plouj> and I don't see an expiration on the key
[22:51] <cjwatson> Probably best to check all the sums, not just md5 - I'd hope apt would prefer the stronger ones
[22:51] <cjwatson> Also check the downloaded versions in /var/lib/apt/lists/
[22:51] <cjwatson> (Sorry, don't have time to debug this fully, just a few suggestions in passing)
[22:52] <sarnold> cjwatson: re: apt and md5 and other hashes, It's Complicated: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1098738
[22:53] <cjwatson> Sources isn't likely to be relevant here
[22:53] <sarnold> cjwatson: thanks for filling in some of my weaker understanding with the source packages handled the same as the binaries
[22:54] <cjwatson> I mean, unless we're specifically talking about source packages rather than that being something that came up in passing
[22:54] <sarnold> hrm, I thought that bug had grown to include more than just Sources
[22:54] <cjwatson> Ah, didn't read it I'm afraid :)
[22:54] <sarnold> it's been a while for me, too :) hehe
[23:07] <Plouj> I don't get why, after running 'do-release-upgrade', which fails with: Error authenticating some packages and apt-get update starts showing "W: GPG error: ... The following signatures were invalid: BADSIG..."
[23:07] <Plouj> no such problems before apt-get update
[23:09] <Plouj> that's the main problem I'm trying to solve here
[23:13] <sarnold> Plouj: can you validate the listst manually, using something like this? for f in *.gpg ; do gpg --verify $f ${f%.gpg}; done
[23:39] <Plouj> sarnold: do you mean in /var/lib/apt/lists/ ?
[23:39] <Plouj> I don't seem to have a Release.gpg for my particular repo in that directory
[23:40] <sarnold> Plouj: hrm. does your archive have the .gpg files?
[23:41] <Plouj> I do have Release.gpg in /var/lib/apt/lists/partial/ ...
[23:42] <Plouj> sarnold: yes, the repo serves Release.gpg among others
[23:43] <sarnold> Plouj: can you verify the files from the repo?
[23:43] <Plouj> yup, it verifies
[23:44] <sarnold> Plouj: how about the one in partial/ ?
[23:45] <Plouj> it currently doesn't verify on the client because of: gpg: Can't check signature: public key not found
[23:45] <Plouj> but sudo apt-key list shows the key....
[23:46] <sarnold> Plouj: wget the file and diff them?
[23:47] <Plouj> where is apt's truststore?
[23:47] <Plouj> I mean keyring
[23:48] <Plouj> found it
[23:48] <sarnold> I think /var/lib/apt/keyrings
[23:48] <Plouj> yeah, it say bad signature
[23:50] <Plouj> humm, so Release.gpg matches what's on the server, but Release doesn't
[23:52] <Plouj> umm
[23:52] <Plouj> diff shows:
[23:52] <Plouj> +-----BEGIN PGP SIGNED MESSAGE-----
[23:52] <Plouj> +Hash: SHA1
[23:52] <Plouj> +
[23:53] <Plouj> I wonder if gpg was upgraded on the server causing it to put the signature into the file itself...
[23:55] <Plouj> I might have something to go on. Thanks sarnold
[23:55] <sarnold> Plouj: good luck :)
[23:57] <slangasek> arges: ping