[03:26] <Legendario> I'm trying to figure out which is my @ubuntu.com alias going to be but I can't figure out what is my launchpad username
[03:26] <Legendario> does anyone know exactly what it is?
[03:28] <wgrant> Legendario: In the top right corner of each Launchpad page you'll see your details formatted as "Display Name (username)"
[03:28] <wgrant> The bit in the parentheses is your username
[03:29] <wgrant> You can also see and change it at https://launchpad.net/~/+edit
[03:42] <Legendario> wgrant, well i tried to send an email to this username@ubuntu.com but didn't get it
[03:42] <Legendario> do I have to change something else?
[03:42] <Legendario> my contact address to username@ubuntu.com too
[03:42] <Legendario> ?
[03:44] <wgrant> Legendario: Have you read through https://wiki.ubuntu.com/UbuntuEmail?
[03:44] <wgrant> It can take a couple of days for an alias to be created or changed.
[03:44] <wgrant> Your preferred/contact address must *not* be @ubuntu.com.
[03:44] <wgrant> If the alias still doesn't work after a couple of days, email rt@ubuntu.com as described on that page.
[03:50] <Legendario> wgrant, I'll try that since it has been a while. thanks a lot
[03:52] <Legendario> wgrant, just saw i did that november, 13th with no answer so far. Any idea?
[03:53] <wgrant> Legendario: Perhaps ask in #canonical-sysadmin.
[03:58] <hloeung> Legendario: replied to your ticket
=== philipballew is now known as philip
=== Logan_ is now known as Guest61371
=== Logan__ is now known as Logan_
[10:01] <xnox> Is there a way to query / view _all_ workitems for myself? (past / present / future / done / unapproved blueprints)
[15:01] <dpm> hi all, could someone give me a hand figuring out why I get a failure to upload for saucy/i386 here? https://code.launchpad.net/~ubuntu-touch-coreapps-drivers/+recipe/signon-plugin-oauth2-daily
[15:23] <dobey> dpm: https://launchpadlibrarian.net/157658819/upload_593246_log.txt isn't descriptive enough?
[15:24] <dpm> dobey, I couldn't quite understand it, hence the question. Not sure why the uploaded version has different contents, as this is a package built from a daily recipe, not uploaded manually, and it uploaded fine for the other arches
[15:27] <dobey> dpm: arch is irrelevant. source packages don't have an arch. but the same version already exists in that PPA and was uploaded on Nov 15
[15:27] <dobey> oh the i386 build failed then though. and it happened before whatever is required for Launchpad to show the "retry this build" link
[15:28] <dobey> so someone with appropriate privs will need to trigger the rebuild
[15:28] <dobey> (i don't have them)
[15:28] <dobey> cjwatson: ^^ do you have perms to trigger rebuild of https://code.launchpad.net/~ubuntu-touch-coreapps-drivers/+archive/daily/+build/5234666 ?
[15:29] <dpm> dobey, I've retriggered a rebuild for saucy, and I got the "Could not be uploaded correctly" on https://code.launchpad.net/~ubuntu-touch-coreapps-drivers/+recipe/signon-plugin-oauth2-daily from 49 minutes ago
[15:30] <dobey> dpm: no, you rebuilt the recipe, not the i386 binary build
[15:30] <dpm> ah, ok
[15:30] <dobey> dpm: you can't upload the same version twice to a PPA
[15:30] <cjwatson> dobey: done, though I haven't checked whether it'll actually help
[15:30] <dobey> dpm: which is why the upload failed
[15:30] <cjwatson> oh, yeah, retriggering the recipe build was a mistake
[15:30] <cjwatson> recipe builds emit source packages
[15:31] <dpm> ok
[15:32] <dpm> thanks dobey, cjwatson
[15:39] <cjwatson> seems built now
=== bencer_ is now known as bencer
[17:40] <shadeslayer> hey, I was wondering, does anyone know of a way to get a list of maintained packages from a team object in the launchpad API?
[17:42] <shadeslayer> https://launchpad.net/~kubuntu-members/+maintained-packages
[17:42] <shadeslayer> kind of like that ^^
[17:45] <dobey> shadeslayer: for ppa in team.ppas_collection: ppa.getPublishedSources() ?
[17:46] <dobey> don't recall if the _collection is necessary or not in launchpadlib
[17:46] <dobey> shadeslayer: oh, nevermind. you want packages that are *in* ubuntu?
[17:47] <shadeslayer> correct
[17:50] <shadeslayer> what I'm trying to do : A bunch of KDE packages seem to fail on arm64 with the error "The bug is not reproducible, so it is likely a hardware or OS problem."
[17:50] <shadeslayer> I wanted to write a script to get a list of packages maintained by kubuntu-members, fetch the arm64 buildlog, parse the log to check if this line exists, if it does, rebuild the pacakge
[17:54] <cjwatson> you don't really need to bother - I do that in bulk across the whole archive
[17:54] <shadeslayer> oh
[17:54] <shadeslayer> :D
[17:54] <dobey> shadeslayer: distro_series.main_archive.getBuildRecords() and filter the result set down to ones that have arm64 as the arch, and filter that result set to ones maintained by kubuntu-members. you'll probably have to get the source and check the control file to get the maintainer
[17:54]  * cjwatson kicks off a run
[17:54] <dobey> or just don't do it :)
[17:55] <cjwatson> it's not Kubuntu-specific so there's no point in everyone reinventing this
[17:55] <shadeslayer> agreed :)
[17:55] <shadeslayer> cjwatson: thanks :)
[17:55] <cjwatson> (I currently do it by way of parsing http://qa.ubuntuwire.org/ftbfs/arm64.html as the crude least-effort option)
[17:55] <dobey> that's probably much easier than doing it via the api, indeed
[17:56] <cjwatson> though I probably *could* do it via the API now that DistroArchSeries.getBuildRecords exists
[17:56] <cjwatson> but meh, haven't bothered to rewrite that script
[17:57] <dobey> yeah, if you're doing it for the whole archive, getBuildRecoreds would be enough
[18:00] <shadeslayer> dobey: cjwatson though there's no way to get the maintained-packages list from the launchpad API?
[18:00] <shadeslayer> useful for other status pages
[18:01] <dobey> shadeslayer: no. i don't think the data in debian/control is coerced into db entries in the lp database directly
[18:01] <shadeslayer> oh interesting, I thought that since the ui shows it, the data would be coerced somewhere
[18:02] <dobey> at least, i don't see any API to do that directly. you'd have to get each individual source control file and parse it to get the Maintainer field
[18:02] <dobey> shadeslayer: well there might be something that parses Maintainer to create that link in launchpad. i don't know exactly. lp source is pretty complex and trying to figure it out isn't something i want to do :)
[18:03] <shadeslayer> likewise ^^
[18:04] <cjwatson> Person:getLatestMaintainedPackages isn't exported, unfortunately
[18:04] <cjwatson> Not necessarily hard to fix
[18:05] <cjwatson> (Though it isn't my itch and I should avoid getting sidetracked from current work)
[18:05] <cjwatson> It'd be in lib/lp/registry/interfaces/person.py, search for getLatestMaintainedPackages, it'd probably want @export_read_operation plus tests
[18:06] <cjwatson> And probably similar for nearby related methods
=== Logan_ is now known as Guest1674
=== Logan__ is now known as Logan_
=== thomi_ is now known as thomi
=== Kyle_ is now known as Kyle