[00:43] I've followed the instructions at https://dev.launchpad.net/Running and also https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally however I have no idea how to make launchpad know about arm so that I can register my armel launchpad-buildd from the web interface. anyone have any ideas? [00:44] trying to put an arm chroot into the librarian like in the soyuz page just tells me that that arch does not exist and kicks me back to the shell. [00:46] Does https://launchpad.dev/ubuntu/natty/+addport give you an ARM processor option? [00:46] wschaub: ^^ [00:49] wgrant: let me try that. [00:50] yes. [00:52] wschaub: Add a new armel DistroArchSeries to your desired series using that form. [00:52] wschaub: And you should see an ARM option on https://launchpad.dev/builders/+new [00:54] great I will let you know if I have any more problems. I just want to get to the point where I can start throwing things at a bunch of builders (Efika MX smarttops) [00:55] wschaub: I tried using my smartbook as a builder a few months ago... it sort of wasn't very happy about it, but I didn't try very hard. [00:55] It was very slow :( [00:55] Unsurprisingly. [00:55] But OMAP4 devices are a bit happier. [00:57] i must have done something wrong https://launchpad.dev/builders/+new doesnt have arm in the dropdown. [00:58] do I have to restart launchpad or something? [00:58] wschaub: Are you using the DB with sampledata, or a fresh one bootstrapped using one of my scripts? [00:59] (HowToUseSoyuzLocally uses sampledata) [00:59] most likely the sampledata. [00:59] Ah, I see, the sampledata doesn't actually have an ARM processor, just a processor family. [01:00] INSERT INTO processor (family, name, title, description) VALUES (5, 'armel', 'ARM', 'ARM'); [01:00] Then it should appear on /builders/+new [01:02] any other pitfalls I'm likely to run into? (working with the database now) [01:03] You'll need to use ports.ubuntu.com instead of archive.ubuntu.com in the external dependencies field of your PPA. [01:03] But that's about it. [01:08] I've been using pbuilder up to this point and havent done anything with launchpad yet (until now) [01:10] sweet well its registered and the librarian took my chroot tarball. [01:10] now I just need to feed it something. [01:11] wschaub: Great. I wrote most of that page, so can probably clarify anything for you. [01:11] you meantioned a bootstrap script should I be using that to set up launchpad/soyuz instead? [01:11] Right, as you've probably noticed the default DB has lots of sample data in it. [01:12] Which is often not desired. [01:13] lp:~wgrant/launchpad/bootstrap-db-from-scratch has scripts to bootstrap an empty DB into a state where Ubuntu exists and PPAs are usable. [01:13] Without all the extra cruft. [01:13] will that clear out the current database that I got by running make schema? [01:14] The branch changes make schema to create an empty DB. So you'll need to rerun make schema. [01:14] It also probably doesn't work any more. Let's see. [01:28] so what format do I use for the add ppa depdendency field? [01:29] to get ports.ubuntu.com added in to a new ppa? [01:29] wschaub: On +admin, not +edit, you'll see an "External dependencies" textarea warning that it is to only be used by OEM migrations. [01:29] Add something like 'deb http://ports.ubuntu.com/ubuntu-ports %(series) main restricted universe multiverse' [01:33] wschaub: lp:~wgrant/launchpad/bootstrap-db-from-scratch works again now. make schema, utilities/bootstrap-lp-db $YOURUSERNAME, utilities/populate-ubuntu-from-scratch.py, then make run and you can log in as $YOURUSERNAME@example.com:test. [01:33] You probably want to alter populate-ubuntu-from-scratch to add armel too. [01:33] start-dev-soyuz is OK to use, but don't try soyuz-sampledata-setup after you've run this :) [01:41] I'm also not too familar with bzr how to i change my branch to yours? [01:41] bzr merge lp:~wgrant/launchpad/boostrap-db-from-scratch [01:42] cool. I will try that in just a moment. I'm trying to upload bc to a PPA and see if it will successfully build. [01:43] Yes, the launchpad build farm is back. nice. :) [01:49] great. now I'm running into problems with gpg. is there anyway to turn that off? (or a quick way to set up the correct stuff so I can upload to a PPA and get this over with?) [01:50] wschaub: Where'd you get the error? [01:51] uploading to the ppa with dput, hrm wait a moment, its using launchpad.net [01:51] I guess I have to use something other than ppa: [01:51] to hit the local launchpad. [01:52] See 'Upload a source to the PPA' on HowToUseSoyuzLocally. [01:52] You'll see -C absolutely-anyyhing in the process-upload commandline there -- that accepts unsigned uploads. [02:00] Ok, looks like the soyuz services werent running, now it says its successfully uploaded and i get a traceback that says that /var/tmp/poppy/incoming/.lock no such file or directory. [02:10] wschaub: Did you follow the first instruction in 'Upload a source to the PPA' -- running process-upload.py before you upload? [02:14] I missed that one.. [02:17] trying again. [02:19] grrr. now the vm seems to have frozen just a mo. [02:19] Heh. === fta` is now known as fta === kenvandine_ is now known as kenvandine [02:30] ok so its back up now. but it thinks I've uploaded that package already. [02:31] Add the -f option to dput. [02:34] ok, no traceback. now to run the other scripts. [02:34] I'm guessing I can run those in cron or something every so often to have this happen automatically ? [02:35] Right. [02:39] witing for the first script to finish, this is really slow on my athlon X2. [02:40] hrm or maybe its just decided to not respond again... I guess could be running out of memoory in the Vm or something. [02:40] its only got like 512MB of ram allocated to it. [02:41] I mean I cant even get anything on the virtualbox console. [02:41] this is the only way I have to test this stuff currently. [02:42] wschaub: 512 is painfully small for Launchpad [02:43] how much do I need? more than 1GB? [02:47] all right round 3 with 1380MB allocated to the VM which is about all I can do. I will see if I can get some extra swap on as well. [02:49] wschaub: natty? try enabling zram [02:53] wschaub: i386 or amd64? [02:53] You can probably get away with 1GB on i386, just. [02:53] amd64 will need more. [02:53] its i386. [02:54] You could also kill the test keyserver to free up a bit of RAM. [02:54] I have an ancient second hand desktop running lucid + virtualbox a smarttop and a smartbook to test with and thats about it. [02:54] Ah. [02:55] I think its a 1gz atholn X2 with maybe 2GB of ram. [03:02] ok now about to run scripts/process-upload.py /var/tmp/poppy -C absolutely-anything -vvv hopefully it will work this time. [03:03] didn't lock up. trying the last few steps. [03:04] hopefully my efika will come to life. [03:07] steev: zram? [03:09] crap. [03:09] let me find someplace to paste what I got. [03:09] I'm guessing I set up the PPA wrong or something. [03:09] wschaub: http://pastebin.ubuntu.com/ [03:10] http://pastebin.com/sHrSJ8hz [03:10] sorry already pasted it there. [03:11] I can repaste to pastebin.ubuntu.com if thats required. [03:11] No, it's fine. [03:11] Your upload path isn't right [03:12] The path itself determines where your upload is targetted -- name16/foo means the foo release of the name16 distribution -- and name16 doesn't exist as a distribution. [03:13] ok so its not the same as the ppa path then. [03:13] what would be a more correct path for that then? [03:13] the page for the ppa just says "dput ppa:name16/foo " [03:13] on the launchpad.dev [03:14] I think you're missing a ~ [03:14] Ah, yeah, I wrote the lpdev dput.cf target to work for anything, not just PPAs. [03:14] ppa:~name16/foo/ubuntu [03:14] So you need the ~ [03:14] (see HowToUseSoyuzLocally) [03:16] which all ppas should need, honestly. [03:16] lifeless: This is a locally-hosted instance [03:18] StevenK: Even so. [03:18] The ppa upload target should be ppa:~user/ppa, so we can actually have project PPAs at some point. [03:21] http://pastebin.ubuntu.com/603958/ [03:28] wschaub: Hm, did you use soyuz-sampledata-setup? [03:29] will it break anything any more if i do that and then re-run that last command? [03:29] You should not run it twice. [03:30] I hope it doesnt remove the arm stuff from the db. 9I may not have run it pretty sure I didn't run it, I assumed make schema took care of that) [03:34] crap, Ok so I think its puking because I tried to set up natty in the launchpad UI earlier. [03:34] quick way to just nuke the database and start over from scratch? [03:34] Right. You probably want to wipe it all and start again (maybe with my branch to get a clean dB) [03:34] worth a shot since things are totally fubar now. [03:34] The sampledata is designed for testing the web UI, not for using in a real Soyuz environment. [03:38] so run bzr merge lp:~wgrant/launchpad/boostrap-db-from-scratch and then run make schema and I have a fresh db? [03:38] or do I have to go through and drop all the postgres databases by hand? [03:38] wschaub: Yes. That bootstrap-lp-db and populate-ubuntu-from-scratch [03:38] s/That/Then/ [03:39] make schema will drop them for you. [03:43] http://pastebin.ubuntu.com/603961/ [03:43] thats from trying to do the merge. [03:44] wschaub: s/boostrap/bootstrap/ [03:45] thats better. [03:48] so now run make schema and then /utilities/populate-ubuntu-from-scratch.py ? [03:48] bootstrap-lp-db needs to be run before populate-ubuntu-from-scratch [03:48] So: make schema, bootstrap-lp-db, populate-ubuntu-from-scratch [03:49] ok, I assume I have to insert into that table to make it know arm exists as well. [03:49] at the end of all that. [03:49] wschaub: Edit populate-ubuntu-from-scratch. [03:49] wschaub: You can see where it adds amd64. [03:49] Add armel there too. === mwhudson_ is now known as mwhudson [03:57] http://pastebin.ubuntu.com/603966/ that look kosher ? [03:58] or do i have armel in the wrong place. [03:59] wschaub: You need to create a new ProcessorFamily, Processor, and then call newArch. [04:01] sso that + later on where we have parent.newArch('amd64', x64, True, ubuntu.owner, True) [04:02] the same thing with 'armel', arm ... [04:02] Right. [04:03] The only name that really matters is the first argument to newArch, which must be 'armel'. [04:03] isnt the second argument the object we created earlier? [04:03] It is. [04:03] But I mean, you can call them all 'arm' or 'armel' or whatever. [04:04] As long as you get the architecturetag in the first argument of newArch to match what Ubuntu wants, which is 'armel'. [04:04] ok I will go ahead and add that extra line then. [04:06] that section of the python script now looks like this http://pastebin.ubuntu.com/603967/ [04:06] wschaub: As long as you're also creating a ProcessorFamily, looks good. [04:07] what you see is all I changed. [04:07] Like 5 has 'family=arm', but you've not created the arm family yet. [04:08] sigh. s/Like/Line/ [04:08] Ok I see it just a bit further above. [04:12] http://pastebin.ubuntu.com/603968/ [04:12] ok hopefully thats all of the bits that matter in the paste this time. [04:12] wschaub: Looks fine. [04:13] guess we will find out. [04:15] no errors, now to run LP and log in. [04:20] yeah, and the logging in part is a problem. [04:20] what does this thing use as the default login? [04:20] USERNAME@example.com:test [04:20] Where USERNAME is what you gave to bootstrap-lp-db. [04:21] yep works. [04:21] That's the sole user in the system, and it's a member of ~admins. [04:21] So it has full power. [04:22] so now I create a ppa under that account, register a builder and restart the running soyuz locally ommiting the sample data stuff. [04:22] You'll need to add a chroot too. [04:26] right, thats the librarian step, I have an arm chroot for that. [04:26] havent gotten that far yet. [04:31] ok, chroot added (at least I think so, it didn't complain) [04:34] dput -u lpdev:~wschaub/ppa bc_1.06.95-2_armel.changes ? [04:34] _armel? Do you mean _source? [04:36] thats the only changes file I have, I ran the bc package through pbuilder and I'm working on what it spit out in the result directory. [04:36] Ah. You need to use 'debuild -S -sa' in the package source dir. [04:36] You need to upload a source, not binaries. [04:45] right, just have to prepare that. [04:48] ok uploaded [04:48] running scripts/process-upload.py /var/tmp/poppy -C absolutely-anything -vvv [04:50] http://pastebin.ubuntu.com/603969/ [04:51] wschaub: Your changelog says 'unstable', which isn't an Ubuntu series name. [04:53] so change it to natty and re-upload? [04:53] Yes. [04:53] ok. [04:55] format 1.0 is not permitted in natty. [04:56] any way to just do this with a .dsc file instead? [04:57] wschaub: Why do you say that? [04:58] (format 1.0) [04:58] bc_1.06.95-2.dsc: format '1.0' is not permitted in natty. [04:58] thats what the script bombs out on. [04:58] I can paste the whole thing. [04:58] Source format 1.0 is allowed. [04:58] That's not the actual problem. [04:59] http://pastebin.ubuntu.com/603970/ [05:03] I'm not familiar with LP internals, so I've no idea about that, but the assertion that source format 1.0 is not allowed in Natty is incorrect. [05:04] * wschaub pulls out more hair. [05:06] I didn't even want to use launchpad, someone else wants me to set up a builder image that works with launchpad though. I would have been just fine with a perl script that called pbuilder. [05:08] either way I've spent too much time on this to quit now. [05:11] First rule of project management is that sunk costs are irrelevant. [05:11] Probably not what you want to hear right now though. [05:12] not really, (what I want to hear is "ok, go ahead and write that perl script instead") [05:13] until then I have to find a way to get this up and running. [05:16] I suspect you need to take a step back and make sure you understand the process for preparing and uploading manually better, but that's just me. [05:19] I suspect the bootstrapping has missed a table [05:24] I'd go with StevenK's suspicion over mine. [05:26] It's been an awfully long time since I thought about source format rules in the codebase ... [05:27] StevenK: anything I can do about that? I'm guessing youve been following the discuession so far. [05:28] I'm having trouble remembering the runes [05:28] wschaub: INSERT INTO sourcepackageformatselection (distroseries, format) SELECT id, 0 FROM distroseries; [05:29] Oh, and 0 is a DBItem for 1.0? [05:30] Yes. [05:30] 1 is 3.0 (quilt), 2 is 3.0 (native). [05:30] just a mo while I do that. hopefully you can fix your script to take care of that. my goal is to document how to set this all up, not just get it working on my vm once. [05:31] Yeah, I'll add that and armel to the scrip.t [05:31] It was written before sourcepackageformatselection eixsted. [05:32] Would be glad to share the document too once I have it all verified working. (no reason for someone else to pull their hair out) [05:34] ok, done [05:34] now to try again. [05:36] ok didnt choke like before but I think its my fault now. "cant build requested arch any" [05:37] That normally means the chroot is missing. [05:37] You added it to the right series? [05:38] I used scripts/ftpmaster-tools/manage-chroot.py -s natty -a armel add -f ~/chroot-ubuntu-natty-armel.tar.bz2 [05:39] And you're uploading to natty? [05:39] Ah, I see the problem. [05:40] https://launchpad.dev/ubuntu/natty/armel/+admin -- check 'PPA support available' [05:41] yep was unchecked. [05:41] The armel/sourcepackageformatselection is now in my branch. [05:44] http://pastebin.ubuntu.com/603980/ is this success? [05:45] wschaub: That is success. [05:45] I'm gussing I run scripts/publish-distro.py -C next [05:45] You should see a build in the queue. [05:45] Or on the builder. [05:45] ./scripts/publish-distro.py -vv --ppa [05:45] No need for -C for PPAs. [05:48] says its waiting to build. [05:48] the command you gave me bombed though. [05:48] pasting now. [05:48] What was the error? [05:48] Ah. [05:49] http://pastebin.ubuntu.com/603981/ [05:49] Heh, no publisher config [05:49] Ahh, no PublisherConfig. That was added a couple of months ago. [05:49] Yeah. [05:50] * wgrant finds the right paths. [05:50] https://launchpad.dev/ubuntu/+pubconf [05:50] root directory should be /var/tmp/archive [05:50] base URL http://archive.launchpad.dev/ [05:50] Copy base URL also http://archive.launchpad.dev/ [05:52] ok. re-running the script after updating on that page. [05:54] looking better http://pastebin.ubuntu.com/603982/ [05:55] Success. If you look in http://ppa.launchpad.dev/ you should see your PPA. [05:56] And populate-ubuntu-from-scratch now adds the publisher config automatically. [05:57] the builder is still idle though. [05:58] That's upsetting. [05:58] Is the builder set to be virtual? [05:59] Check the 'Virtualized' flag, and enter any garbage for the host field, since it's not a real virtualised host. [05:59] But PPAs want something that at least looks like it's virtualised. [06:00] yeah i unchecked virtual thinking that would be a problem. [06:00] The dev config replaces the usual virt reset command with echo. [06:00] In production it SSHs into the host to kill and restart the VM. [06:00] So the VM host field doesn't matter in a dev instance, as long as it's set to something. [06:02] ok so I set it to virtual and set the hostname as foo for the vm host. [06:02] I think I will check the log on the builde to see what if anything has been said to it. [06:03] tail -f /var/tmp/development-buildd-manager.log [06:03] (buildd-manager is started by start-dev-soyuz, and is the thing that talks to the slaves) [06:04] ok I will paste that in a second. /var/log/launchpad-buildd/default.log doesnt seem to have much useful info in it. [06:05] other than a bunch of post requests with no ral info. [06:06] They should be every 15 seconds, and still happening now? [06:08] waiting. nope. [06:08] Maybe buildd-manager died after the multitude of DB drops. [06:09] Is it still running? [06:09] Production sort of doesn't have to cope with DB drops very often :) [06:09] what can I grep for with ps -ef ? [06:09] grep buildd-manager [06:10] yeah not running. [06:10] ps aux | grep keyserver [06:10] ps aux | grep poppy [06:10] (those two and buildd-manager are what start-dev-soyuz runs... best to kill all three and run start-dev-soyuz again) [06:12] ok killed the last two (buildd-manger was dead already) and its re-starting now. === Ursinha is now known as Ursinha-afk [06:15] the hell, buildd-mangager didnt come up. [06:16] Anything in its logs? [06:17] nothing in the log saying it ever started either. [06:17] It might spew errors everywhere, but it should at least start... [06:17] let me paste what I have. [06:17] it has some odler stuff about builder bob in there form earlier but nothing about crashing. [06:17] thre is no builder bob now and it says nothing abotu efikamx. [06:18] bin/twistd --logfile /var/tmp/development-buildd-manager.log --pidfile /var/tmp/development-buildd-manager.pid -y daemons/buildd-manager.tac [06:18] Does that do anything? [06:19] says another twistd server is running. [06:20] except [06:20] there is no pid 1752 like it says [06:21] let me rm the pid file. [06:21] hopefully that will kick it back into running. [06:22] launchpad-buildd is getting stuff now. [06:22] lets check the status page. [06:22] 1 package building. [06:23] It will probably explode saying it can't find the librarian or archive.launchpad.dev or something like that. [06:23] Because it's on another host, and there's no DNS to help it. [06:26] where would I see it explode? it says its not building now. [06:26] and its idle again. [06:26] but nothing in the ppa looking like a built package. [06:28] http://pastebin.ubuntu.com/603987/ [06:28] where would I even see stuff like this in the web interface? [06:29] 2011-05-06 01:22:39-0400 [HTTPPageDownloader,client] ***** efikamx is CHROOTWAIT ***** [06:30] wschaub: https://launchpad.net/~USERNAME/+archive/PPA/+packages [06:30] so, I need to make this thing visible from outside and point launchpad.dev at it. [06:30] on the builder. [06:30] https://dev.launchpad.net/Running/RemoteAccess [06:31] I normally do that. [06:31] Or something like it. [06:31] Then, in the builder's /etc/hosts, add archive.launchpad.dev, ppa.launchpad.dev, launchpad.dev pointing to the VM's IP address. [06:31] is there a way to tell it to attempt to re-build the package without re-uploading it once I have that set up? [06:32] Yes, you can give it back [06:32] wschaub: You'll see a nice red X on the PPA page. There'll be a link around there, and behind that a Retry link. [06:34] I see it. [06:35] brb after I take the dog out. I will try and get the remote access stuff set up and retry the build. [06:49] lots of editing.. hang on. [06:54] would be nice to have a script for this bit, tempted to do just that. [06:54] later. [07:18] ok i think I have it ticking over, re-submitting the build. [07:18] I have a local dnsmasq so I just added everything to it and reloaded. [07:21] now I have to give the launchpad-buildd a valid ntp server, no biggie. [07:24] bzip2 is running on the builder [07:24] so i guess it got its tarball. [07:24] good sign so far. [07:27] wschaub: Great. [07:27] wschaub: You might get a 404 about archive.launchpad.dev [07:27] In which case try './scripts/publish-distro.py -C' to create the initial local Ubuntu tree. [07:28] http://pastebin.ubuntu.com/603991/ [07:28] new problem. [07:28] but thats probably something to do with my ppa. [07:28] I'm guessing thats what you just said. [07:29] dunno if there is enough space on the VM's disk to hold all those packages (if its going to mirror everything) [07:29] It's not. [07:29] It's just going to create an empty tree. [07:29] Well, it will create a tree with empty indices. [07:30] That's why you need to set an external dependency on ports.ubuntu.com: you don't have the whole Ubuntu archive locally. [07:35] ok, giving it another go. [07:38] now it says its failed because of dependency wait. [07:39] http://pastebin.ubuntu.com/603993/ [07:40] Did you readd the external dependency after you rebuilt the DB? [07:40] It appears not. [07:41] I have this set up in the ppa. [07:41] deb http://ports.ubuntu.com/ubuntu-ports %(series) main restricted universe multiverse [07:41] under https://launchpad.dev/~wschaub/+archive/ppa/+admin [07:44] Oh. [07:44] A typo on my side. %(series)s, not %(series) [07:44] And you are uploading to that same PPA? [07:45] yes. [07:45] thats the ppa I'm submitting the package builds from. [07:45] So, try fixing the typo and retrying, I guess. But I would have expected that to produce a dispatch failure, not a build failure. [07:45] so its "deb http://ports.ubuntu.com/ubuntu-ports %(series)s, main restricted universe" [07:46] ? [07:46] "deb http://ports.ubuntu.com/ubuntu-ports %(series)s main restricted universe" [07:46] And probably with a " multiverse" at the end, but it's unlikely you'll use that. [07:48] ok, done retrying build. [07:51] seems to be working, its actually loading depends according to the log. [07:51] Great. [07:53] running autoconf. [07:54] getting compiler lines in the log now. [07:56] now it says uploading build. [07:59] I dont see it in my pool though. [07:59] I'm guessing theres more scripts to run. [08:01] scripts/process-upload.py -vvv --builds -C buildd /var/tmp/builddmaster [08:01] scripts/process-accepted.py -vv --ppa ubuntu [08:01] scripts/publish-distro.py -vv --ppa [08:01] right? [08:04] yup! its in my pool. [08:04] awesome. [08:05] OK, I'm going to bed just going to save this irc log, save the VM state and see if I can re-create this all tomorrow. and document it. [08:06] wschaub: Great! If you need any help at all, give me a poke. [08:06] will do, thanks for your amazing patience with this. [08:07] I remember when I was first working out how to do it. [08:07] before there were docs :/ [08:07] At all :/ [08:07] doe syour new script have the arm stuff in itor will I have ot edit that part again? [08:07] It has the ARM and PublisherConfig and SourcePackageFormatSelection stuff. [08:07] You'll still have to flip the "PPA support available" flag, though. [08:07] thats not so bad. [08:08] A bit better than SQL :) [08:10] the ppa stuff might not even be necessary the way this thing might be used. (rebuilding natty bits) I just figured a simple upload/build of bc to a ppa would be the easist way to see it working. [08:15] anyway time to pass out. [08:15] Night. === Guest832 is now known as lag === lag is now known as Guest57644 [09:00] I've been trying to upload a package to my ppa using dput. update is successful, but i never get a reply from launchpad. any idea? [09:00] i'm using sftp method === henninge changed the topic of #launchpad to: https://launchpad.net/ | Help contacts: henninge | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ [09:11] aviksil: you are referring to a reply via email? [09:12] henninge: no. i'm seeking help [09:13] aviksil: you said you "never get a reply from launchpad" [09:13] aviksil: I meant if you are expecting a reply via email? [09:13] henninge: oh ok. misunderstood. yes, i'm referring to reply via email [09:14] aviksil: I have not used ppas much myself so I wasn't sure if that is the expected behavior. [09:15] aviksil: there has been work on reducing emails sent by Launchpad. Maybe you need to explicitly subscribe to such notifications now. [09:15] aviksil: Did you sign the package properly? [09:15] henninge: ok. actually i tried ftp method earlier. but it stalled while uploading the *source.changes file [09:16] aviksil, wgrant: I understood that the actual upload went fine? [09:16] then i moved to sftp method with login = aviksil [09:16] henninge: emails from soyuz were not part of the recent structural subscription wpork [09:16] I see [09:16] https://answers.edge.launchpad.net/launchpad/+faq/227 [09:16] wgrant: yes, it was signed properly [09:17] aviksil: please read the FAQ [09:17]