[03:32] <vual> hey guys i tried to install LXLE on i686 and it wont let me it tells me to get right version for my CPU, but i can only find 64b and 32b i cant find i686 ??? any tips ??
[03:34] <ianorlin> the 32 bit is for i686 and LXLE isn't supported here
[03:36] <vual> oh this is lubuntu ?
[03:36] <vual> cause LXLE is better then lubuntu i just assumed it overtook lubuntu
[03:37] <vual> thanks for your help anyway you rude cunt :)
[07:03] <absk007> how to backup sources list & key certs?
[08:33] <Zenfu31> hi can anyone give me a url for setting up compiz on Lubuntu 14.04.1 desktop
[09:30] <Zenfu31> is this thing on???
[09:50] <ikonia> Zenfu31: it is
[10:17] <Zenfu31> okay, i see that lubuntu uses openbox
[10:18] <Zenfu31> i'm essentially looking to try the desktop cube
[10:18] <Zenfu31> but have no idea on how to go about it
[10:20] <Zenfu31> k, just found it
[10:20] <Zenfu31> under preferences
[10:24] <Zenfu31> okay, any help on remote desktop connection in lubuntu 14.04.1 ?
[14:45] <sheena1> when i try to run desktop preferences, i got a "Desktop manager is not active" error. i did some googling and attempted to reinstall pcmanfm, as that seemed to be a common solution. Now, pcmanfm doesn't run, I get the same popup error when I try to run it from gui or terminal. all i wanted to do was fix my suspend time out, and now i've broken things even more :(
[14:50] <testdr> sheena1: create a new user, - name it "test" and set password. Then logout and do a login with the new username and check if the desktop is broken there too. If its ok for the new user, then your usersettings are broken (misconfigured).
[14:51] <sheena1> ok.
[14:51] <sheena1> when i try to use user settings GUI, it is unresponsive when i click "add". is there a command line way to do this?
[14:53] <sheena1> testdr: when i open it with sudo users-admin, it just hangs and doesnt finish opening
[14:53] <testdr> sheena1: yes - shure there is - but it looks like you have more broken. You are shure you did a default installation of LUbunut-14.04? Do you have the install-system(live-system on CD/USB) to check the live-version?
[14:54] <sheena1> i did the default install. it worked fine half an hour ago, until i reinstalled pcman
[14:54] <testdr> sheena1: did you do a logout? And what is with the guest-user-account? Can you use this on login?
[14:55] <sheena1> i will reboot and beright back
[15:00] <sheena1> testdr: um, now things are really broken
[15:00] <sheena1> i have no taskbar, eveything is different/weird, ...
[15:01] <sheena1> the only way to open stuff is to right click my desktop to open a terminal emulator
[15:01] <testdr> sheena1: you are using 2 computers? One for this irc-channel?
[15:01] <sheena1> on the plus side, pcmanfm will oepn now!
[15:01] <sheena1> nope, i used the terminl to run pidgin, which is how i use IRC
[15:03] <testdr> sheena1: ok - same computer - if you have not already stored a lot (it was a new installation?), then you can in a terminal move your local config out of way - then logout (NOT reboot) and login again
[15:03] <sheena1> it was a clean install, but several months ago
[15:03] <sheena1> my home directory is separate
[15:03] <sheena1> im nto sure about the config?
[15:04] <sheena1> running lxpanel in terminal makes my panel come back
[15:04] <testdr> sheena1: any backups? Or can you now swith to the guest-user-account?
[15:04] <testdr> shwitch
[15:04] <testdr> switch
[15:05] <sheena1> when i went into the guest account, it was the same.. no panel, etc
[15:06] <testdr> sheena1: broken! Could be from no more space to other things. Have run the updates? Last time?
[15:07] <sheena1> no space? like, hard drive space?
[15:07] <sheena1> i just did update yeah
[15:07] <testdr> yep
[15:07] <testdr> when was the last update?
[15:08] <sheena1> 28gb free on my home partition, says disks
[15:09] <sheena1> 16gb free on my OS partition (root)
[15:09] <sheena1> maybe yesterday? im not sure
[15:09] <testdr> you can do following, you switch to terminal with hotkey  strg+alt+F1   and login there, thats no graphics and make a:  sudo  apt-get  update
[15:09] <testdr> sheena1: you may do it in the xterm
[15:10] <sheena1> its running
[15:10] <sheena1> i will not paste the output ;)
[15:10] <sheena1> it is done
[15:10] <sheena1> Fetched 838 kB in 8s (98.9 kB/s)
[15:10] <sheena1> Reading package lists... Done
[15:10] <sheena1> home@home:~$
[15:11] <testdr> its getting new paket-databases
[15:11] <testdr> sheena1: did you see same parts downloaded?
[15:11] <sheena1> same parts?
[15:11] <testdr> some
[15:11] <sheena1> yeah. i just ran a sudo apt-get update a few minutes ago, though
[15:12] <sheena1> when i was reinstalling pcman and everything broke :(
[15:12] <testdr> did you run:   sudo apt-get upgrade
[15:12] <sheena1> not yet
[15:13] <sheena1> i will do that now
[15:13] <testdr> apt-get update only gets the databases up-to-date -- it installs no pakets or updates those
[15:13] <sheena1> ok
[15:13] <sheena1> its installing now i thnk
[15:14] <sheena1> sorry. i have been using ubuntu for a few years now, but there are still things i dont fully understand
[15:14] <testdr> sheena1: you should see the downloading (traffic) and what it does for installing
[15:14] <sheena1> yep. i see it
[15:14] <sheena1> what should i dowhen its finished?
[15:14] <sheena1> log out? reboot? neither?
[15:15] <testdr> sheena1: did it install a new kernel? Only this is normaly the reason for a reboot.
[15:15] <sheena1> i am not sure how to tell
[15:15] <testdr> you should try now if the tool in the menu: system configuration --> User+Groups is working
[15:16] <sheena1> oh if it did, it will ask me to reboot, right?
[15:16] <sheena1> it is now preparing and unpacking
[15:16] <sheena1> soon it will be done
[15:16] <testdr> most times yes - but not allways
[15:16] <sheena1> i dont see any mention of kernel in the list of stuff it is installing
[15:17] <testdr> sheena1: you should be able to create a new user-account to get a clean user-setting and if this is working, then its possible to fix your primary-account
[15:18] <sheena1> it is still unpacking
[15:18] <sheena1> must have many things to install.. means i havent done this in a while maybe? oops
[15:18] <testdr> thats what i suspect - and is different what you told
[15:19] <sheena1> i see that :(
[15:19] <sheena1> i did not mean to lie to you!
[15:19] <sheena1> it seems stuck maybe
[15:19] <sheena1> oh no, its going now
[15:19] <testdr> i did not say this - computers are always the fault
[15:19] <sheena1> heh yes. blame the machine :)
[15:19] <sheena1> it never minds if you blame it. i did drop it hard on the floor a couple of days ago also, and ran some hard drive diagnostics, but that should not cause the software to work strangely i think
[15:20] <testdr> sheena1: did you never use synaptic (gui-tool) for updates and paket-installs?
[15:20] <sheena1> ok it is done
[15:20] <sheena1> i use the software updater gui. it comes up sometimes and i click "install" but im notsure if it is synaptic or not
[15:20] <testdr> thats not
[15:20] <sheena1> i have both User Accounts and Users and Groups now
[15:21] <testdr> running?
[15:21] <sheena1> i want users and groups?
[15:21] <sheena1> in useres and groups, it opens but when i click add, stil nothing happens
[15:21] <sheena1> manage groups opens a dialogue, but add and advanced settings do not
[15:22] <testdr> mmh -- maybe wait - maybe you do a logout and login and everything may work.  ---
[15:22] <sheena1> in user accounts, there is no response and an "unlock" buttont hat does nothing
[15:22] <sheena1> ok i will log out
[15:23] <sheena1> lol
[15:23] <sheena1> "log out command is not set"
[15:23] <sheena1> how do i do this in command line?
[15:23] <testdr> in commandline, in terminal enter: logout
[15:23] <testdr> or exit
[15:23] <sheena1> that just closes the terminal
[15:23] <sheena1> it hink
[15:24] <sheena1> To end all user processes and be sent back to the login screen, you can use:kill -9 -1
[15:24] <sheena1> i could do that?
[15:24] <testdr> sheena1: your gui-taskbar-icon for logout is not there?
[15:24] <sheena1> it is, but it pops up with the error "log out command is not set"
[15:25] <sheena1> i never log out, so maybe this is not a new problem. i dont think i have ever logged out since i installed, i just reboot if i need to.
[15:26] <sheena1> testdr: i am not sure what to do next
[15:26] <sheena1> i will try the kill -9 command?
[15:26] <testdr> sheena1:  in a terminal(xterm) enter to kill running LXDE-session:    killall  --SIGKILL lxsession
[15:26] <sheena1> that gives me a manual type page for killalll
[15:27] <testdr> sheena1: my keyboard - only one "-"
[15:27] <sheena1> home@home:~$ killall -SIGKILL lxsession
[15:27] <sheena1> lxsession: no process found
[15:28] <testdr> sheena1: you have LUbuntu? Without lxsession to start the Desktop? Or -- how you get it started?
[15:28] <sheena1> im sorry i dont know :(
[15:28] <sheena1> i have lubuntu, yes
[15:28] <sheena1> it usually just works? i turn it on and it works!
[15:29] <testdr> check in terminal if there is lxsession running:    ps xa | grep session
[15:29] <sheena1> home@home:~$ ps xa | grep session
[15:29] <sheena1>  2138 ?        Sl     0:00 lightdm --session-child 12 27
[15:29] <sheena1>  2210 ?        Ss     0:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/im-launch /usr/bin/openbox-session
[15:29] <sheena1>  2213 ?        S      0:00 /usr/bin/dbus-launch --exit-with-session /usr/bin/im-launch /usr/bin/openbox-session
[15:29] <sheena1>  2214 ?        Ss     0:00 //bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
[15:29] <sheena1>  2269 ?        Sl     0:00 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session
[15:29] <sheena1> 15705 pts/7    S+     0:00 grep --color=auto session
[15:30] <testdr> sheena1: you have no default LUbuntu -- you have mixed with gnome-session
[15:30] <sheena1> oh . how did that happen? can i fix it? is that the problem?
[15:33] <testdr> sheena1: i dont know -- if you are right about using LUbuntu-14.04,  you can do an:    sudo   apt-get install  lxde-common
[15:33] <sheena1> what is the comand to print out what OS i have installed etc?
[15:34] <testdr> uname -a
[15:34] <testdr> and:   lsb_release   -a
[15:34] <sheena1> home@home:~$ lsb_release -a
[15:34] <sheena1> No LSB modules are available.
[15:34] <sheena1> Distributor ID:	Ubuntu
[15:34] <sheena1> Description:	Ubuntu 14.04.1 LTS
[15:34] <sheena1> Release:	14.04
[15:34] <sheena1> Codename:	trusty
[15:35] <testdr> sheena1: dont paste multiple lines into irc -- use the pastebin and provide the link to the uploaded text (http://paste.ubuntu.com"
[15:36] <sheena1> sorry. do you want me to pastebin that output for you?
[15:36] <testdr> no - could read enough
[15:36] <sheena1> http://cdimage.ubuntu.com/lubuntu/releases/14.04.1/release/lubuntu-14.04.1-desktop-i386.iso    this is the file i used to install
[15:36] <sheena1> i made a live usb and used that
[15:36] <sheena1> so i dont know what happened?
[15:36] <sheena1> i did try to make shotwell work and installed some gnome things, maybe that broke something?
[15:36] <testdr> thats ok - but --ahaaa
[15:36] <sheena1> i dont want to do a clean install again if i dont have to :(
[15:37] <sheena1> that was months ago, the shotwell thing, and it worked ok after that?
[15:37] <testdr> you did install gnome - and pulled in parts of the gnome-desktop for your user-account.
[15:37] <sheena1> ok
[15:37] <sheena1> is it fixable?
[15:37] <sheena1> and will fixing it fix all the stuff that is wrong, or only some?
[15:39] <testdr> your user-account-mixed settings is not easy to fix. -- First there is the gnome-session running instead of lxsession. But i wonder if its the same for the guest-account and if so i dont know what everything else may be installed from gnome and taking over the command
[15:40] <sheena1> is a clean install going to fix it?
[15:40] <sheena1> i can dot hat if it is the best way
[15:42] <testdr> if your user-data is saved -- mailsettings, etc. then a clean new install would be the best and quickest thing and then you can install your saved user-date back -- but take care about   .config  in your home-directory, there may be some gnome-settings and this should be first not used.
[15:42] <sheena1> can i just rename .config to .config-broken and then do a clean install?
[15:43] <testdr> and for the future - create always a second user-account to do software tests or mixing the desktop-settings.
[15:43] <sheena1> thank you. i will try to do that next time. i never know what might break things :(
[15:43] <testdr> no -- if you will rename it - then you first should try to reboot and check if things work better -- you need a real backup if you do a fresh install
[15:44] <sheena1> real backup.. even though home directory is separate?
[15:45] <sheena1> i will rename it now and reboot, see what happens?
[15:45] <testdr> sheena1: i dont know if you have it really separate. People do a new install and overwrite whole disk and then even a not touched partition is gone.
[15:45] <sheena1> i have done installs with home separate befor
[15:46] <sheena1> i can show you if i can list my paritions?
[15:46] <sheena1> i know i must do it inside the installer carefully so it does nto overwrite /home
[15:46] <testdr> sheena1: you can do a install only to the root-partition and dont touch other partitions - but some people are to quick and press the button to do the full-install
[15:47] <testdr> sheena1: you understand? You have to read carefully and know the datasettings of your harddisk
[15:48] <sheena1> yes i understand. i have done this before several times
[15:48] <testdr> ok - then a fresh install is done in less than 1 hour (quick hardware only around 20-30 minutes).
[15:49] <sheena1> ok. should i try the rename .config first?
[15:49] <testdr> thats less than the time we used here
[15:50] <testdr> yes - thats quicker - and you know this is put aside with a different name
[15:50] <sheena1> ok. i will do that and then reboot and see what happens?
[15:50] <sheena1> sudo mv /home/home/.config /home/home/.config-broken ?
[15:51] <testdr> yes
[15:51] <sheena1> not mvdir?
[15:51] <testdr> no - its only a rename
[15:51] <sheena1> ok
[15:54] <sheena1> ok i rebooted
[15:54] <sheena1> no panel opened
[15:55] <sheena1> i right clicked desktop to open terminal, and ran pidgin, so i cando the same for my panel and check what works?
[15:55] <sheena1> users?
[15:55] <sheena1> this time lxpanel opened a different panel
[15:55] <sheena1> with my colour settings
[15:56] <sheena1> software updater opened and wants me to update 'Ubuntu base'
[15:56] <sheena1> looks like a kernel update
[15:58] <sheena1> testdr: are you here?
[16:02] <testdr> too late
[16:03] <testdr> re
[16:03] <sheena1> i missed some msgs
[16:04] <testdr> not much - was afk
[16:04] <sheena1> i made a new user through command line but now when i boot up, it does not even ask me which user i want
[16:04] <testdr> did you activate auto-login?
[16:04] <sheena1> i dont think so? if i did, it was an accident
[16:04] <sheena1> this morning, it would always ask me
[16:05] <sheena1> and now it does not
[16:05] <testdr> and you are logged in as this user? New or old one?
[16:05] <sheena1> home
[16:05] <sheena1> i cannot log in as new one
[16:05] <sheena1> i dont know how?
[16:05] <sheena1> if it does not ask me when i restart, i dont know how else to do it
[16:05] <sheena1> logout through GUI does not work
[16:05] <testdr> sounds like the login-manager is gone
[16:06] <sheena1> all gone :(
[16:06] <testdr> then its really the quickest way to do a fresh clean install from your live-usb-version
[16:06] <sheena1> throw it out and get a new pc ?
[16:06] <sheena1> ok
[16:06] <sheena1> i will find my usb stick
[16:06] <sheena1> i hope!
[16:06] <sheena1> is it bad to make a new one from this broken computer if i cannot find it?
[16:07] <sheena1> and there are now some things in .config again. should i rename it again before i install?
[16:07] <testdr> no - only the download has to work - with some kind of browser or wget -- but without an usb-stick?
[16:07] <sheena1> i have the iso file already on my laptop
[16:07] <sheena1> from before
[16:07] <sheena1> and i have many usb
[16:07] <sheena1> just not sure i have the boot one i made still
[16:07] <sheena1> i might have lost it or overwritten it
[16:08] <testdr> sheena1:  then plug in a usable usb and identify its device -- maybe its  /dev/sdb   and do a      dd  if=isoimage   of=/dev/sdb
[16:08] <kanzure> confirm it's /dev/sdb before dd
[16:08] <testdr> sheena1: if you have 2 harddisks it may be /dev/sdc
[16:09] <sheena1> i think i fount it
[16:09] <sheena1> it has .disk and boot nad casper.. etc
[16:09] <sheena1> seems like the right onw
[16:09] <sheena1> can i check it before i install from it?
[16:09] <testdr> the dd-command is:    --- then its probably your lost live-version
[16:10] <sheena1> and kanzure, can i access this from my android phone so i can stay in the room while im doing my reinstall?
[16:10] <kanzure> androchat
[16:10] <testdr> sheena1: you check it with reboot and select boot from this usb-drive (maybe you have to press F11 .. F12 or F2 at boot-time)
[16:10] <sheena1> ok bye for now!
[16:10] <kanzure> or androirc, rather.
[16:12] <sheena> Is it working?
[16:13] <sheena> Kanzure am i in the rigt place?
[16:24] <sheena> My wifi card isnt opening.
[16:24] <sheena> Seriously?
[16:46] <sheena1> testdr: i have reinstalled. how can i check that everything is back to nromal?
[16:47] <testdr> check the lookout - working tool - like user-config, openbox-config etc.
[16:49] <sheena1> open bo confg opens
[16:49] <sheena1> user config works, i made a test account!
[16:49] <sheena1> how can i change my system suspend settings? maybe i should get help with that before i break all the things agin!
[16:51] <testdr> first do an update  - suspend-settings like suspend-to-ram for an laptop? Thats part of powerconfiguration
[16:52] <testdr> check the tools in config and system-settings are working - there should be the tool for the power-settings
[21:43] <triplc> hi all
[21:43] <triplc> howto change colors of lxterminal ?
[21:44] <triplc> or it is only background & foreground color can be changed ?
[21:44] <triplc> no customized color scheme ?


[00:01] <thumper> lifeless: what have you done to edge?
[00:09] <wgrant> It exploded yesterday.
[00:09] <wgrant> Quite spectacularly.
[00:32] <lifeless> wgrant: please try to get a broken wadl now
[00:39] <wgrant> lifeless: I'm not sure this explains everything.
[00:39] <lifeless> wgrant: I'm not sure it explains anything
[00:39] <lifeless> wgrant: but, are the symptoms gone
[00:40] <wgrant> the last run succeeded. Doing it again to confirm...
[00:47] <poolie> lifeless: oh, did you land those flag scopes? or someone else?
[00:47] <poolie> either way, that's great
[00:48] <lifeless> I'm been extending it a little, yes.
[00:48] <lifeless> the pageid one will land today
[00:48] <lifeless> once we climb out of this downtime hole
[00:49] <lifeless> wgrant: ?
[00:52] <wgrant> lifeless: Seems happy now.
[00:52] <lifeless> great
[00:52] <wgrant> I can't say for sure, but three runs succeeded.
[00:52] <lifeless> so running edge on 2 appservers with a backlog of 160 requests is a bad idea
[00:52] <wgrant> Heh.
[00:52] <wgrant> Remarkable.
[01:06] <poolie> that's great
[01:06] <poolie> i hope to lower my queue enough to do the edit gui
[01:07] <poolie> it is in a branch though, if i don't get to it
[01:10] <lifeless> poolie: I filed a bug to track it; if you're not actively on it I can unassign you
[01:10] <lifeless> I needed a reference point for a code comment IIRC
[01:10] <poolie> i'm not actively on it but i feel i ought to close a few bzr bugs first
[01:11] <poolie> i'm hoping/aiming for quite a productive week here
[01:16] <wgrant> lifeless: I threw some example error messages on bug #636713.
[01:18] <lifeless> poolie: could you perhaps link your branch to the bug?
[01:18] <poolie> perhaps i could
[01:19] <lifeless> thanks:)
[01:21] <poolie> nice summary :)
[01:21] <poolie> i mean description
[01:21] <poolie> bug 636192
[01:22] <lifeless> poolie: ;)
[01:51] <poolie> no bot?
[01:53] <lifeless> _mup_: yo
[01:53] <lifeless> tumbleweeds
[02:26] <lifeless> wgrant: 41 /    9  Distribution:+search third top oops in prod
[02:29] <wgrant> lifeless: Is that hard/soft?
[02:30] <wgrant> So the third top OOPS only occurs 41 times a day? That's not bad.
[02:34] <lifeless> on sunday
[02:40] <wgrant> Ah.
[02:42] <lifeless> still, edge is ~ 13 seconds, time to shrink lpnet a little
[03:21] <lifeless> thumper: https://code.edge.launchpad.net/~lifeless/lp-production-configs/timeouts/+merge/35239
[03:41] <lifeless> thumper: ^ when you have a sec ;)
[03:48] <stub> thumper: So both the existing indexes *might* be useful - you can look up BranchRevision indexes by revision using the (branch, revision) index, but I think it is more efficient to look them up using the (revision, branch) index.
[03:49] <stub> thumper: It would be nice if we can drop both unique indexes and use just the primary key index though, as inserts will be faster and we save disk space. And maybe it will even be faster as we are more likely to have the index in PG shared memory.
[03:50] <stub> thumper: So if we drop both now, we can try adding one back later if there are read performance issues. Or we can leave things with two indexes for now, and try dropping one later.
[03:51] <stub> Do we ever need to see which branches a particular revision is in?
[03:55] <thumper> yeah...
[03:55] <thumper> stub: but this is one of the things I'm wanting to either factor out
[03:55] <thumper> stub: or find another way
[03:56] <stub> I'm thinking we should keep the patch as you have it, and just be aware that if Revision -> Branch traversal is slow we might be able to fix it with a new index.
[03:56] <thumper> stub: I hadn't thought of that reason for the constraint
[03:57] <stub> I can't really guess which will be fastest for reads, and no index is faster for inserts and saves disk
[03:57] <thumper> stub: *most* of the time we are going from the branch to the revisions
[04:24] <lifeless> \o/ less bare excepts
[05:05] <lifeless> stub: I just remembered I wanted to ask you about layer teardowns.
[05:05] <lifeless> stub: looks like zope.app.testing.functional/FunctionalTestSetup.tearDownCompletely() should let use teardown some more layers?
[05:07] <stub> Sounds like it would, yes. That didn't exist before.
[05:07] <lifeless> ok
[05:07] <lifeless> rs= you to do it ?
[05:07] <stub> Maybe make the whole fork-a-new-process thing unnecessary too
[05:07] <lifeless> yes
[05:07] <lifeless> thats a good 2 or more minutes per test run
[05:07] <lifeless> on its own
[05:07] <stub> rs=stub. If the tests pass, great.
[05:22] <wgrant> lifeless: Anything more to add to the bug?
[05:30] <lifeless> stub: could you do me a small favour
[05:31] <lifeless> ttps://devpad.canonical.com/~stub/dbr/last-3-hours.txt suggests to me that we've reduced load on the master DB post-rollout.
[05:31] <lifeless> or is it within the variation you've seen anyway
[05:42] <stub> lifeless: load seems less
[05:42]  * stub looks for the graph
[05:42] <lifeless> \o/
[05:47] <lifeless> brb
[05:53] <stub> lifeless: https://lpstats.canonical.com/graphs/DBCpuLoadAppServers/20100907/20100914/ -- doesn't seem much changed according to that
[05:58] <thumper> lifeless: have you filed a bug about the code import xmlrpc timeouts?
[06:07] <lifeless> yes
[06:07] <lifeless> search on the page id
[06:07] <lifeless> hmm, I thought I had
[06:11] <lifeless> stub: you did the session db schema change?
[06:11] <stub> lifeless: yes
[06:11] <lifeless> cool
[06:11] <lifeless> I doubt spm has the cycles
[06:12] <lifeless> but I'll see if Tom does, to move the cert deployment forward.
[06:12] <spm> me? doubt it. (cycles)
[06:31] <lifeless> how hard is it to batch a page ?
[06:31] <lifeless> is there a howto ?
[06:59] <lifeless> so
[06:59] <lifeless> batching
[06:59] <lifeless> I guess I need to dig myself.
[07:06] <stub> lifeless: Have you seen anything to suggest we should change our Storm cache sizes? Its available as a config parameter in launchpad-lazr.conf but we have never tuned it - just an initial guess.
[07:06] <lifeless> stub: I haven't seen anything saying we're thrashing in swap
[07:07] <lifeless> stub: and from a page layout perspective the storm cache is in principle unneeded anyway, once we finish structuring things right
[07:07] <lifeless> stub: but even so, no, I haven't seen any [obvious] cache thrashing
[07:07] <lifeless> once we get down to a sensible 10-20 queries per page that would be very obvious
[07:07] <stub> I wonder if we would benefit from a larger cache then? I don't think flushes are instrumented, so I don't know if we are needlessly reloading objects that could have been pulled from cache
[07:08] <lifeless> stub: I doubt we'd benefit - we flush the cache on transaction boundaries anyway
[07:08] <lifeless> stub: flushes aren't recorded AFAIK; but we'd see the loads as a series of single object loads at the end of the apge.
[07:09] <stub> I'm thinking about prejoin type stuff which by its design relies on objects remaining in the cache until they are needed.
[07:09] <stub> (as nothing is holding references to them)
[07:10] <stub> But I guess loading that many objects is the real problem, not how to ensure that we can access too_many objects efficiently.
[07:10] <lifeless> yeah
[07:10] <lifeless> I think theres a few angles to it
[07:10] <lifeless> firstly prejoin is not a complete enough eager-loading for us
[07:10] <lifeless> what we're starting to do in e.g. Person is sufficient
[07:11] <lifeless> secondly, if we are hitting a cache threshold, I think we'll see it very clearly when we look at an OOPS.
[07:11] <lifeless> stub: what is the cache size set to ?
[07:13] <stub> Oh - for the appserver it is 10k so I guess no problem there. Most batch jobs have it set to 500.
[07:13] <lifeless> ah
[07:13] <stub> All in schema-lazr.conf - nobody has ever overridden the defaults in the instance configs.
[07:13] <lifeless> batch jobs I'm not really scrutinising yet.
[07:14] <lifeless> 500 is possibly too small hyes.
[07:14] <lifeless> but OTOH
[07:14] <lifeless> batch jobs should be pretty darn precise with what they do compared with appserver pages which are all over the shop
[07:14] <lifeless> Intrinsically I mean; like 'show me all specs' is an appserver use case, for a batch job it would be 'email changes to specs' and thats time-bounded.
[07:20] <StevenK> Okay, fine. SQLObject I hate you.
[07:20] <lifeless> StevenK: you can return a storm ResultSet even while the class uses SQLBase, its easy and lets callers start depending on it.
[07:20] <StevenK> lifeless: That sounds like a good plan
[07:21] <lifeless> I did this to searchBugs, for instance.
[07:21] <lifeless> oh
[07:21] <lifeless> and for a relatively clean one - hahhaha -
[07:21] <lifeless> see Distribution.specifications
[07:23] <StevenK> lifeless: Right, which ends up using Store.of anyway
[07:23] <wgrant> Store.of is Storm...
[07:25] <lifeless> StevenK: thats the point, the guts of the function is still shitty hand-string-joined-sql
[07:25] <StevenK> Then I may as well just use IStore(IDistroSeries) ...
[07:25] <lifeless> StevenK: but it returns a perfectly cromulent storm result set
[07:26] <lifeless> StevenK: Store.of if you have an object is *important*
[07:26] <lifeless> StevenK: You want to match the store that the object came from
[07:27] <StevenK> lifeless: Or can I just call methods on the SQLObjectResultSet I get back?
[07:27] <lifeless> of course you can
[07:27] <lifeless> converting that to a storm ResultSet would be a good idea though.
[07:28] <lifeless> StevenK: perhaps you should explain whats up
[07:28] <StevenK> lifeless: My hidden question is "Will that involve more database roundtripping" ?
[07:28] <lifeless> StevenK: will whatr
[07:28] <StevenK> lifeless: Will calling methods on the SQLObjectResultSet result in more database roundtripping?
[07:29] <lifeless> if you call methods that do round trips.
[07:29] <lifeless> (sorry that thats the answer, but thats the situation)
[07:29] <lifeless> resultsets will do roundtrips when you call methods on them
[07:30] <lifeless> which methods cause roundtrips depends on the resultset type
[07:30] <StevenK> lifeless: To explain what's up: I'm writing a new method on IDistroSeries called deriveDistroSeries, and one of the arguments is the name of the distroseries. The method will look up if the distroseries exists, and if it does, use it, and if it doesn't, use it.
[07:30] <StevenK> I'm having trouble looking up if the distroseries exists.
[07:30] <mwhudson_> StevenK: i get the feeling that you are worrying about something that essentially shouldn't be worried about, but slightly over specific questions are masking the real issue
[07:31] <lifeless> StevenK: so
[07:31] <lifeless> StevenK: firstly, write the function taking a distroseries object not a name.
[07:31] <StevenK> mwhudson_: TBH, I suspect my problem is that getUtility(IDistroSeriesSet).findByName(name) doesn't return what I think it should
[07:31] <lifeless> StevenK: if you intend it to work in that way.
[07:32] <lifeless> StevenK: secondly, if you want a name-based version, add that as a trivial wrapper.
[07:32] <lifeless> don't conflate the two.
[07:32] <lifeless> you'll find it clearer and easier to test if you avoid magic like that.
[07:32] <wgrant> I can't see a reason to have it take a name.
[07:33] <lifeless> thirdly, if you are concerned about db round trips, *test it* - write tests, like those I've mentioned in perf tuesday emails, that check the number of db calls that go on.
[07:33] <wgrant> That's only good for things like components and sections.
[07:33] <lifeless> there is /nothing/ like tests for catching gotchas; I can help you ensure that the test is valid, once you have a sketch of it up.
[07:33] <lifeless> tests and bastard users AKA 'QA'
[07:34] <lifeless> wgrant: mwhudson_: any tips on how to 'batch a page'
[07:34] <lifeless> is there a howto
[07:34] <lifeless> or docs
[07:34] <wgrant> lifeless: I don't know of any.
[07:34] <stub> I tend to avoid the old crufty SQLObject era APIs on the FooSet utilities and use native Storm syntax. IStore(DistroSeries).find(DistroSeries, name='myname').one()
[07:34] <wgrant> I just grep.
[07:34] <lifeless> wgrant: do you know how to batch a page? if so, please be writing it up!
[07:35] <mwhudson_> lifeless: don't know of anything either
[07:35] <stub> But I'm not usually in browser code, which is supposed to go via the *Set for security issues.
[07:35] <StevenK> stub: This is API code
[07:35] <lifeless> the store objects we have are security proxied
[07:35] <lifeless> so they will wrap any objects returned
[07:35] <lifeless> the Sets don't add anything security wise.
[07:36] <StevenK> Just pain, misery and SQLObject
[07:36] <lifeless> unless I'm deeply confused.
[07:37] <stub> I didn't think our Store objects were security wrapped. Under the hood, they come from the IZStorm utility which is not registered as a secureutility IIRC.
[07:38] <lifeless> hmm
[07:38] <lifeless> then we should security wrap them
[07:38] <lifeless> because API's also need the security enforcement, and model code what APIs expose.
[07:39] <lifeless> I'll file a bug
[07:39] <stub> Just include 'may' in there - I'm not 100% on this.
[07:39] <wgrant> The security stuff here is a bit complicated.
[07:40] <wgrant> Even if those stores are proxied, Store.of isn't.
[07:40] <wgrant> I don't think IStoreSelector is secured.
[07:40] <lifeless> all in the big
[07:40] <lifeless> *bug*
[07:41] <lifeless> ok
[07:41] <lifeless> so whats a simple batched page
[07:41] <lifeless> branches?
[07:42] <wgrant> Bug listings, or possibly /people
[07:42] <wgrant>  /people used to be non-standard, but I think Curtis fixed that recently, so it might be a nice example.
[07:44] <StevenK> steven@liquified:~% du -ch /tmp/launchpadlib-cache-* | tail -n 1
[07:44] <StevenK> 225M	total
[07:44] <StevenK> For want of a test suite that doesn't do evil things to /tmp
[07:48] <lifeless> we need to fix up zope.app.testing first
[07:48] <lifeless> here, a blindness pull - zope.app.testing.functional.FunctionalTestSetup.__init__
[07:48] <lifeless> the first line.
[07:50] <StevenK> lifeless: TBH, I'm happy to accept it's a bug in Zope
[07:51] <lifeless> its not per se
[07:51] <lifeless> its a stack that needs cleaning up is all
[07:59] <lifeless> poolie: those scopes have now landed.
[08:02] <wgrant> Oh, nice.
[08:02] <lifeless> wgrant: ?
[08:03] <wgrant> pageid-based FF.
[08:03] <lifeless> yes
[08:03] <lifeless> in e2 atm is a FF memcache control
[08:03] <wgrant> So we can turn caching on and off with a flag?
[08:03] <lifeless> yes
[08:03] <lifeless> per pae
[08:03] <lifeless> per page
[08:05] <lifeless> next up after that is per pageid timeout control, the prerequisite for that should land overnight too
[08:18] <poolie> oh, great
[08:45] <adeuring> good morning
[08:58] <henninge> Is LP production running on python 2.6 now?
[08:58] <lifeless> partly
[08:59] <lifeless> AIUI rolling upgrades are still going on - check the wiki page if you care
[09:05] <mrevell> Hello
[09:05] <lifeless> hi
[09:16]  * mwhudson_ wonders how crazy running launchpad on arm would be
[09:16] <mwhudson_> i guess the lack of ram would be the killer
[09:16] <lifeless> 1TB should be fine
[09:16] <StevenK> Our current servers don't have that ...
[09:17] <mwhudson_> 256 megs might be enough to have an appserver limp along, i guess
[09:17] <elmo> 1000     21319 50.2 10.9 1022248 669056 ?      Sl   Sep09 2859:33 /usr/bin/python -S bin/run -i lpnet7
[09:17] <elmo> mwhudson: ^--
[09:17] <wgrant> You can just run a dev appserver and librarian in 512.
[09:17] <wgrant> But it's, er, painful.
[09:18] <lifeless> we should fix that
[09:18] <wgrant> There's also the issue of the PPA not building on armel.
[09:18] <wgrant> But apart from that it should work.
[09:19] <mwhudson_> elmo: i wasn't suggesting it for prod :)
[09:46] <lifeless> jml: welcome back
[09:47] <jml> lifeless, thank you.
[09:47] <mwhudson_> hello jml
[09:47] <jml> mwhudson_: hi
[10:11] <jtv> noodles775: hi there!  I'm working on displaying TranslationTemplatesBuild.  Ironically, it involves adding a view for TranslationTemplatesBuildJob so the builder displays can link to the TranslationTemplatesBuild.
[10:12] <noodles775> Huh, a view for the TTBuildJob? Do you mean for the TTBuild?
[10:13] <jtv> noodles775: no, that's the thing
[10:13] <wgrant> Along the lines of BuildFarmBuildJob?
[10:13] <jtv> I need the *-current.pt template to link to the build.
[10:13] <jtv> wgrant: exactly
[10:14] <jtv> and hi ;)
[10:14] <wgrant> hi.
[10:14] <jtv> But to stop me from getting it all wrong: how do I find the right BuildFarmJob for a given BuildQueue?
[10:14] <jtv> (I realize it's all going to change)
[10:15] <wgrant> You shouldn't need to know that.
[10:15] <wgrant> (and I forget)
[10:15]  * noodles775 would need to look at the code and see what soyuz/code does too.
[10:15] <jtv> Okay, then can I just replace the display of the current BuildQueue for a builder with a display of the ongoing build?
[10:15] <jtv> Or BuildFarmJob?
[10:16] <jtv> I guess I'll just steal from there then.  :)
[10:16] <wgrant> Stealing ideas from elsewhere is almost always the best idea.
[10:16] <wgrant> Since that code probably works...
[10:18]  * bigjools asks jtv to consider performance when writing this code
[10:18]  * jtv is happy consider performance, but getting the smegging thing working at all does come into play as well
[10:19] <jtv> Now, the soyuz builds seem to put all this into a link formatter.  Which one?
[10:19] <jtv> PackageBuildFormatterAPI?
[10:20] <wgrant> Watch out -- there are unobvious formatter specialisations which have caught me before.
[10:20] <wgrant> I don't remember details. But search for subclasses first.
[10:20] <wgrant> Or it gets very confusing.
[10:21] <jtv> Hmm what _is_ the context for soyuz's view there?  The build or the job?
[10:21] <wgrant> The +current view?
[10:21] <jtv> Yes, on that one?
[10:22] <jtv> Looks like it's still an IBuildFarmJob as before.
[10:23] <wgrant> BuildFarmBuildJob wraps the Build.
[10:23] <wgrant> Which is itself an IBuildFarmJob.
[10:23] <wgrant> But not an IBuildFarmJobOld.
[10:26] <jtv> So chances are that we'll want the same on BuildFarmBranchJob.
[10:27] <jtv> And perhaps that'll allow us to get rid of BuildFarmBuildJob and BuildFarmBranchJob, which after all were really only there to cover for the absence of a Build.
[10:28] <wgrant> Once Translations complies, we can do all sorts of mass deletions.
[10:29] <jtv> True—no particular need to fix that up now.
[10:32] <thumper> jml: https://dev.launchpad.net/Code/BranchRevisions
[11:09] <lifeless> \o/ memcache branch passed ec2
[11:27] <jtv> bigjools, noodles775: lib/lp/soyuz/browser/configure.zcml defines a browser:page (with name="+current") for lp.buildmaster.interfaces.buildqueue.IBuildFarmJob
[11:28] <jtv> I'm surprised that doesn't blow up, given that I don't see IBuildFarmJob in lp.buildmaster.interfaces.build*queue*
[11:31] <noodles775> jtv: it seems to have been added (or at least moved there) by you? I'm not sure why it was added (or perhaps just moved there from elsewhere).
[11:31] <jtv> noodles775: I guess it's just a dead page and I can delete it.  But WTF doesn't anything complain about it?
[11:32] <noodles775> Removing it and running the tests might show why... otherwise, not sure.
[11:33] <jtv> I think I know why it's there and it should indeed be a dead page.
[11:40] <jtv> wgrant: afaics I do need to know how to get from a BuildQueue to a BuildFarmJob because the UI seems to find my build as buildqueue.specific_job.build.  :/
[11:40] <jtv> The specific_job is TTBJ.
[11:41] <jtv> So the TTBJ needs to find the BuildFarmJob
[11:42] <jtv> (I get here because Builder.currentjob is the starting point for the rendering of builds and buildjobs, and that's a BuildQueue.)
[11:43] <jtv> noodles775: do you have any idea how I can find my BuildFarmJob given a BuildQueue?
[11:44] <noodles775> jtv: Do you mean other than how the soyuz/code parts do it?
[11:44] <jtv> (I also need to look at build histories, of course)
[11:44] <jtv> noodles775: they keep references to build objects in the db, don't they?
[11:45] <noodles775> Yep, they have linking tables (ie. BuildPackageJob)
[11:46] <noodles775> I don't know what you do and don't have in the DB... can you remind me what's different for translations?
[11:46] <jtv> That's hardly something I can do.  I guess I could move TTBJ over as some kind of view on TTB, but… yuck.
[11:46] <jtv> noodles775: there was never any build object.
[11:47] <jtv> And now the new infrastructure is at a point where it seems to require a build object in the obsolescent old-model classes.
[11:50] <noodles775> jtv: what is build_queue.job_type in your case? TRANSLATIONTEMPLATESBUILD?
[11:50] <jtv> yes
[11:55] <noodles775> jtv: and can you get a hold of your TTBJ based on the queue (ie. based on the job.id I assume)?
[11:55] <jtv> noodles775: yes, that's all linked together using the old model—BuildQueue.job == TTBJ.job == Job.id
[11:57] <jtv> The problem is getting from anywhere in the old model (BuildQueue, TTBJ, Job) to the new model (BuildFarmJob, TTB)
[11:58] <noodles775> jtv: I was going to ask why buildqueue.specific_job doesn't just work (or at least, why it can't just work if you hook up the utility), but then saw that TTBJ.getByJob() is returning a BranchJob.
[11:58] <jtv> Well TTBJ lives in the BranchJob table.
[11:59] <jtv> buildqueue.specific_job does just work, but it returns a TTBJ not a TTB.
[11:59] <jtv> If it needs to return a TTB, same problem: I have a BuildQueue and I need to find the corresponding TTB.
[11:59] <jtv> Or BJF.
[11:59] <jtv> *BFJ
[12:00] <wgrant> jtv: isn't the TTB accessible from the TTBJ?
[12:00] <jtv> wgrant: no—that's _exactly_ the problem I've been trying to solve.  :)
[12:01] <wgrant> In the other cases, the job exists to link the build and the buildqueue.
[12:01] <jtv> Yes, and the big problem we were going to solve with this new model was that TTBJ was not related to any build object.
[12:02] <wgrant> But it exists now.
[12:02] <wgrant> So TTBJ could link to it.
[12:02] <jtv> Exactly.  It's great, but I can't find it.
[12:02] <wgrant> Oh, right, it's a BranchJob arrgh.
[12:02] <noodles775> wgrant: TTBJ isn't a DB model...
[12:02] <noodles775> yep.
[12:02] <jtv> TTBJ could link to it _if_ I move the entire class to a new table, which will be lots and lots of work for an obsolescent class.
[12:03] <noodles775> jtv, wgrant: I wonder if this would be a good opportunity to start the transition. ie. jtv's branch could add the job attribute to BFJ. Then his TTBJ class could have a build attribute that just looks it up based on the job?
[12:04] <wgrant> Depending on how large the branch already is, that could be reasonable.
[12:04] <jtv> Will they be the same Job though?
[12:04] <wgrant> They probably could be.
[12:04] <noodles775> jtv: you'll need to make sure they are - no one else is using it yet (so it will be NULL for code/soyuz).
[12:04] <wgrant> I see no reason why the BuildQueue Job can't be made persistent.
[12:05] <wgrant> It shouldn't break anything.
[12:05] <jtv> flw :)
[12:05] <wgrant> You don't even need to start using its attributes yet, I guess.
[12:07] <jtv> I'm not going to be able to make this kind of change in my ongoing branch.  How about this:
[12:07] <wgrant> Adding and populating a simple BFJ.job FK shouldn't be troublesome.
[12:07] <wgrant> You don't have to do anything with it.
[12:07] <jtv> I make sure build histories can link to and render TTBs (they already render).
[12:08] <jtv> I get that change reviewed.
[12:08] <wgrant> Linking isn't that important. Not crashing is.
[12:08] <jtv> My branch can already render TTBs.
[12:08] <jtv> So I make sure build histories can link to and render TTBs without crashing,
[12:09] <jtv> get that change in together with a bunch of other ones I've already accumulated
[12:09] <jtv> (they're blocked on this branch),
[12:09] <noodles775> Sounds good.
[12:09] <jtv> land the lot of 'em,
[12:09] <jtv> then we twiddle the model further so that Builder.currentjob.specific_job.build works,
[12:09] <deryck> Morning, all.
[12:10] <jtv> and then (afaic in yet another branch) retire BuildFarmBranchJob and basically anoint BuildFarmBuildJob as the buildmaster-standard implementation for BuildFarmJobs.
[12:10] <wgrant> And then delete it.
[12:10] <noodles775> Yay.
[12:10] <jtv> Yes.
[12:10] <jtv> Kill.
[12:10] <jtv> Kill.
[12:10] <jtv> Kill.
[12:12] <jtv> This means that for now, the "Building [...]" display for a builder will _not_ link to the TTB yet, only to the branch.
[12:12] <jtv> That change comes in part (3).
[12:12] <jtv> Which leaves me free right now to worry about functional display of TTBs in builder _histories_
[12:13] <jtv> As an Orwell character might have put it, to fix the present we must first fix history.
[12:14] <jtv> Now, how _does_ the builder history get rendered?  Retrieve all BuildFarmJobs and for each, obtain & render the specific job?
[12:28] <jtv> noodles775: does BuildFarmJob play any role in rendering build histories yet?
[12:39] <jtv> danilos: my plan is this:
[12:39] <jtv>  * Finish & land my UI branch.
[12:39]  * danilos is all ears (well, /me is all ears anyway, but now especially so)
[12:40]  * jtv holds back nasty remark about huge nose
[12:41] <danilos> :)
[12:41] <jtv>  * Adjust the model so that we can find the new buildfarmjob class (the historic record, basically) where we need to from the old TTBJ class in the same way that the other old-model classes can.
[12:42] <jtv>  * Clean out the classes, interfaces & templates that we currently have to paper over this problem, using the new tie between the two models instead.
[12:43] <jtv> That last step eliminates our "special" position in the build-farm model afaics.
[12:43] <danilos> jtv, can we not have a simple adapter for TTBJ to IBuild if that's what we need? what exactly is missing?
[12:44] <jtv> What's missing is any kind of link between the objects in the old model and the objects in the new model.
[12:44] <jtv> Because the two are tied together only through the build objects that we never had.
[12:45] <danilos> jtv, right, so is it not simpler to add a link to TTBJ on the Build object then? (I assume Build object is part of the "new" model)
[12:45] <jtv> You assume right (although it's confusingly called BuildFarmJob)
[12:46] <danilos> jtv, ok, so that's what you mean with "adjust the model" step?
[12:47] <jtv> Doing it that way would still be very ugly.  But more to the point, that's all for the next step—which we should hammer out in detail with the Wellington crew.  There is a plan.
[12:48] <jtv> For the more distant future, the plan was to re-introduce Job which is so far completely missing from the new model.
[12:48] <jtv> In the old model, Job was what tied all of it together.
[12:48] <danilos> jtv, hum, so what kind of "adjusting" is needed in the first step? uglifying and then cleaning up later is ok by me :)
[12:49] <jtv> The first step is just making sure nothing blows up with what I already implemented, and landing it all.
[12:49] <danilos> jtv, right, then I mean second step
[12:50] <danilos> jtv, also, would what you implemented allow us to eg. generate stats based on the data in the DB and interrogate DB directly if we want to know more about any particular build?
[12:50] <jtv> The second step _as it looks now_ involves moving the re-introduction of Job forward.  We add a FK to Job to BuildFarmJob, and then I can use that to find our new build class ("derived" from BuildFarmJob, though in a separate table) from our old buildjob class.
[12:52] <jtv> danilos: it should yes, since it introduces creation of BuildFarmJobs for our job type.
[12:53] <danilos> jtv, right, so step 1 is golden for us, step 2 and 3 are basically interdependent as well?
[12:54] <danilos> jtv, also, what happens with TTBJ, where do we move the functionality it provides to?
[12:55] <jtv> danilos: step 1 should be a small one from where I'm standing (cross fingers), which would be great for reporting on our end.  And again as you say, 2 and 3 are interdependent in that 2 moves forward design and implementation work that step 3 is currently stuck on.
[12:56] <danilos> jtv, right, so let's do that, and then we can try to figure out the minimal stuff we need to do to unblock everybody else
[12:56] <jtv> danilos: TTBJ provides very little.  It gets replaced with TranslationTemplatesBuild, which fits neatly into the new model.
[12:57] <jtv> I think step 1 would unblock things for the others.  Which is one reason among many why I want to phase things this way.
[12:57] <danilos> jtv, right, if that's the case, let's get it done, and not worry about other things yet :)
[12:58] <danilos> jtv, though, I am a bit confused: wouldn't we need to introduce the link between the TTBJ and BFJ before we'd really unblock others?
[12:59] <danilos> jtv, also, why can't we simply introduce a new field on TTBJ that links directly to BFJ (TTBJ is going away anyway)
[12:59] <jtv> TTBJ lives in the BranchJob table, so we can't do that.
[13:00] <danilos> jtv, uhm, why not? (yes, it might be ugly, but wouldn't it be dirt cheap?)
[13:00] <jtv> I don't think we need to introduce a link in order to unblock others; what matters is that each of our jobs will have a representation in the new model.  Where the UI starts out in the old model and tries to navigate to the new model, our jobs simply don't exist just as things stand now.
[13:01] <danilos> jtv, ok, fair enough
[13:01] <danilos> jtv, but, how will the jobs be executed? will there be an interim phase where such link is needed for execution as well?
[13:02] <jtv> Exactly _how_ we link the two is part of step 2, and that's something to be discussed with the Wellington team.  How the jobs will be executed won't matter much, since our jobs will be present in both models simultaneously.
[13:03] <jtv> AIUI as soon as we start executing based on the new model, we also stop generating the old-model objects.
[13:03] <danilos> jtv, it does matter because I can easily think of a migration approach that would leave our jobs not running
[13:03] <danilos> jtv, but, since you seem confident, I'll trust you on that ;)
[13:04] <jtv> We're generating the same jobs in both the old and the new model.  They both contain the same information.
[13:05] <jml> I'm off to grab some lunch. Back soon.
[13:05] <danilos> jtv, ok, imagine a migration path like this: "we want to start using the new code, but from within the old model, just like UI: 1. get old model jobs, 2. get a link to new model jobs [just like UI, right], 3. if found, run the job"
[13:05] <jtv> Yes, we could do it wrong if we _really_ wanted to, but I don't really see the need.
[13:06] <danilos> jtv, it's not about a need, I actually find the above approach quite sane, especially considering that that's how UI migration seems to be getting done
[13:06] <jtv> Well what would happen if you tried it that way, things would blow up.
[13:06] <danilos> jtv, how come the UI doesn't blow up, yet it uses new model for all the other builds?
[13:06] <danilos> (or does it?)
[13:06] <jtv> Because that's builds, not jobs.
[13:06] <jtv> We execute jobs, not builds.
[13:07]  * danilos is now thoroughly confused
[13:07] <jtv> danilos: if you're thoroughly confused then at last you fully understand the model.
[13:07] <jtv> congratulations!
[13:07] <danilos> jtv, thank you :)
[13:08] <danilos> jtv, ok, so let's watch out for any weird migrations, I'll go watch out for some food, and not worry about much else right now other than landing the code you've got
[13:09] <jtv> I'm also past eod now, not just temporally but especially mentally.  :)
[13:09] <jtv> But I did want to appraise you of this before the heart attacks started.
[13:14] <danilos> jtv, sure, tty tomorrow
[13:15] <gmb> rockstar, Is it fair to assume you're not around for the next hour or so?
[13:16] <gmb> Heh. s/hour/3 hours/
[13:17] <gmb> deryck, Do you know if rockstar got anywhere with his wigety wizard wonderousness? ISTR seeing something fly across my screen about it late last week, but I didn't really pay it much heed at the time due to being RM-frazzled.
[13:17] <deryck> gmb, yeah, I worked with him on Friday to get his event bug fixed and unblocked him.
[13:18] <deryck> gmb, I suspect he may still be today or tomorrow wrapping that up still.
[13:19] <gmb> deryck, Okay. I'll find something smallish to do in the meantime.
[13:20] <gmb> Oh, I've got that bug import to do first. Win.
[13:24] <deryck> gmb, and there's really no bug in the story left that doesn't require the config widget, is there?
[13:25] <gmb> deryck, One or two, but no, not many.
[13:25] <gmb> It is something of a blocker.
[13:25] <deryck> yeah, I told rockstar to please ping you or I if he needed help, since we really need this.
[13:27] <gmb> deryck, Cool.
[13:28] <deryck> gmb, he did mention he was stopping at a two-step widget, since that's all he needed.  Do you need more steps?
[13:32] <deryck> gmb, maybe you should take a peak at lp:~~rockstar/lazr-js/wizard-widget to get an idea of what's coming to.
[13:32] <gmb> deryck, Well, yes and no. There are potentially up to 4 forms that could be show in one overlay in a given sequence, but they could be logically split across two widgets. I'll take a look at rockstar's branch this afternoon and see what the deal is.
[13:33] <gmb> (Also, there's always the chance that I could hack it to work the way I want, but that might not be TRTTD)
[13:33]  * jml back
[13:33] <jml> and my inbox is empty!
[13:34] <gmb> jml, Select all, delete?
[13:34] <jml> no. inbox zero style, instead of 1100 unread conversations in my inbox I know have about 100 flagged as @READ or @ANSWER
[13:35] <jml> s/know/now/
[13:52] <bac> welcome back jml
[13:52] <jml> bac, thanks.
[13:58] <sinzui> mrevell, ping
[13:59] <mrevell> hello sinzui
[13:59] <sinzui> mrevell, you may be interested in this question: https://answers.edge.launchpad.net/launchpad/+question/125165
[13:59]  * mrevell looks
[14:00] <mrevell> Thanks sinzui. Yes, that's right up my street. I shall deal with it.
[14:00] <sinzui> thanks
[14:00] <mrevell> In that I'll answer it and also write a blog post inviting nominations
[14:23] <matsubara> hey bigjools
[14:23] <bigjools> matsubara: hey dude
[14:24] <matsubara> bigjools, could you help me with a upload failure from a recipe? I created a recipe to create packages for bzr-pqm and put them in the ~launchpad PPA. It seems the source build step worked correctly but the upload failed
[14:25] <bigjools> matsubara: build URL?
[14:25] <matsubara> bigjools, this is the recipe URL: https://code.edge.launchpad.net/~matsubara/+recipe/bzr-pqm-launchpad-ppa/+build/2465
[14:25] <matsubara> I'll paste the failure email I got, just a sec
[14:25] <bigjools> matsubara: did you read the log? :)
[14:26] <bigjools> all will become clear when you do
[14:26] <matsubara> bigjools, yep. it says the versions already existed there but this was my first try AFAIK
[14:26] <matsubara> bigjools, normally I'd have to bump the version, right?
[14:26] <bigjools> yes
[14:27] <bigjools> it's the source that already exists, it was probably uploaded as a regular package already
[14:27] <matsubara> bigjools, and when I look here: https://edge.launchpad.net/~launchpad/+archive/ppa/+packages, looks like the package is there and published and everything seems to be alright
[14:27] <bigjools> there you go then
[14:28] <bigjools> matsubara: oh it's never been uploaded at all before?
[14:29] <matsubara> bigjools, not with that version number. there was a older bzr-pqm package in the ~launchpad PPA  uploaded by Gary some time ago
[14:29] <bigjools> yeah bzr72
[14:30] <matsubara> bigjools, btw, when I apt-get update && apt-get upgrade I get the new package (bzr 73) that I uploaded.
[14:30] <bigjools> matsubara: hmmm I'd check with one of the Code guys then, seems like it tried to upload itself twice
[14:30] <matsubara> so I'm confused by the email saying it failed to upload
[14:30] <matsubara> hmm
[14:31] <matsubara> bigjools, don't know if it helps, but here is the failure email: https://pastebin.canonical.com/37090/
[14:31] <bigjools> ok
[14:32] <bigjools> matsubara: no it doesn't help :(
[14:32] <matsubara> and the recipe page says (https://code.edge.launchpad.net/~matsubara/+recipe/bzr-pqm-launchpad-ppa/+build/2465) still says it failed to upload
[14:33] <matsubara> hmmm
[14:33] <matsubara> looking here: https://code.edge.launchpad.net/~matsubara/+recipe/bzr-pqm-launchpad-ppa I see there are two build records there
[14:35] <bigjools> matsubara: so 2 builds got created, which explains the error
[14:36] <bigjools> matsubara: I don't know what could cause that to happen
[14:36] <bigjools> but abentley might
[14:37] <matsubara> bigjools, maybe I set the daily build option and requested a build manually through the "request builds" link
[14:37] <matsubara> not sure, but looks like PEBKAC heh
[14:37] <bigjools> yeah that could be it
[14:37] <bigjools> :)
[14:38] <matsubara> thanks for your help!
[14:38] <bigjools> matsubara: it's a bug that it allows 2 builds for the same version though
[14:38] <matsubara> yep, I'll search/file a bug
[14:38] <bigjools> that should be caught earlier so that it doesn't waste build farm time
[14:38] <matsubara> bigjools, launchpad-code or soyuz?
[14:38] <bigjools> code
[14:38] <matsubara> okie. ta!
[14:39] <cr3> hi folks, I'm mapping some launchpad concepts externally for referential integrity purposes, so that my web app can refer to launchpad projects for example. my question is: should I name that particular concept as a "product" to remain true to launchpad or "project" because that's how it's exposed externally?
[14:40] <matsubara> bigjools, aha! https://bugs.edge.launchpad.net/launchpad-code/+bug/620248 the description and tim's comment describes exactly my situation
[14:40]  * cr3 is leaning towards remaining as close as possible to the launchpad core for consistency purposes
[14:41] <gmb> cr3, Project. The "product" moniker is archaic and should be taken out and shot, but it's got its tentacles into a lot of code.
[14:41] <gmb> (That and "Project Groups" are called "projects" in code, which is just weird)
[14:41] <cr3> gmb: that's the feeling I got from the launchpad code, but it doesn't seem like it's ever going to happen
[14:41] <gmb> cr3, I think it's a JFDI-when-we-have-breathing-room thing.
[14:41] <gmb> Because it has the potential to break tonnes of stuff.
[14:42] <cr3> gmb: breathing what? not in my vocabulary :)
[14:42] <bigjools> matsubara: yep!
[14:42] <gmb> Maybe we'll do it in the week before Xmas, when we have nothing major scheduled, just lots of code cleanup.
[14:42] <abentley> matsubara, bigjools,  it is expected behaviour that when you enable daily builds, it will always attempt a build, even if you have previously done a build.  One has no way of knowing whether the result will fail to upload without doing a build.
[14:42] <bigjools> abentley: I have deja vu about this fact :)
[14:42] <gmb> cr3, Breathing room... er... space to make the change and clean up all the breakages without making everything far to stressful.
[14:42] <cr3> gmb: that's much sooner than I had expected, I'll code for the future then. thanks for the advice!
[14:43] <gmb> cr3, np. But note: "Maybe" from me != "We will" from flacoste or thumper :)
[14:43] <cr3> gmb: as long as the intention is there, at least I can justify my naming decision. I will document that my concept of project maps to launchpad's concept of product though
[14:44] <matsubara> gmb, cr3: https://bugs.edge.launchpad.net/launchpad-code/+bug/109153
[14:45] <abentley> matsubara, bigjools: upload failures usually come from debversion, and some substituted values (e.g. {time} will always be different.
[14:45] <gmb> matsubara, Hurrah, saved me a job; thanks :)
[14:46] <matsubara> abentley, right. my case is that I think I set the daily build option and requested a manual build at the same time
[14:46] <matsubara> then I was confused by the failure email
[14:46] <matsubara> while the first request was successfully built
[14:46] <abentley> matsubara, I understand that.
[14:48] <abentley> matsubara, if you had requested the same build twice, that would have been rejected.  But the daily build would have been scheduled after your manual build completed.
[14:51] <matsubara> abentley, even if it completed successfully, hence bug 620248?
[14:52] <abentley> matsubara, even if it completed successfully, because there's no way to know that it wouldn't complete successfully again without attempting a build.  See above.
[14:52] <matsubara> right, makes sense
[14:53] <rockstar> gmb, skype?
[14:55] <gmb> rockstar, Sure. Let me get mah Skype rolling.
[14:57] <rockstar> gmb, I don't have your skype id already here, and apparently your name is not original enough.
[14:57] <gmb> rockstar, binnsgm. :)
[15:35] <rockstar> gmb, you'll want to bzr pull.
[15:35] <gmb> rockstar, Okay, doing so now ,thanks.
[15:36] <rockstar> gmb, you should have revno 187 (a bad omen)
[15:37] <gmb> rockstar, yep :)
[16:00] <jml> sinzui, we have a call now.
[16:00] <jml> sinzui, but I need a cup of tea first.
[16:04] <sinzui> jml, I am ready on mumble
[16:09] <jml> sinzui, me too!
[16:22] <bigjools> sinzui: I'm not sure, but I think this bug is registry?  https://bugs.edge.launchpad.net/launchpad/+bug/636151
[16:26] <sinzui> bigjools, yeah. That has no home. give it to registry. I think most of the objects are registry related.
[16:27] <bigjools> that's what I figured, thanks
[16:28] <bigjools> that question about featured projects probably belongs there too
[16:32] <bigjools> mrevell: did I see earlier that you were dealing with this? https://answers.edge.launchpad.net/launchpad/+question/125165
[16:33] <mrevell> bigjools, Yeah, I'll be on it.
[16:33] <bigjools> mrevell: ok mind if I assign to you?
[16:33] <mrevell> go for it
[16:34] <bigjools> ahhh questions needs some ajax love
[16:36] <sinzui> jml, UbuntuBeta, Ubuntu, 'Bitstream Vera Sans', 'DejaVu Sans', Tahoma, sans-serif;
[16:42] <gmb> bigjools, Questions needs some love from the Loving Hammer of Rectification, never mind AJAX.
[16:44] <gmb> Oh, no, wait, I'm thinking of blueprint.
[17:09] <james_w> some help with diagnosing bug 637323 would be welcome, as it is causing problems for the apport retracers in particular
[17:19] <EdwinGrubbs> Is there something I need to do besides put /++oops++ in the url to trigger an oops on launchpad.dev?
[17:43]  * bigjools EoDs, good evening all
[18:04] <mrevell> night all
[18:54]  * rockstar lunches
[19:11] <jelmer> rockstar: hi
[19:26] <lifeless> moin
[19:36] <lifeless> james_w: so
[19:37] <lifeless> james_w: bug:
[19:37] <lifeless>  - appserver revno differences cause PATCH error
[19:37] <lifeless>  - launchpadlib in stable Ubuntu points to edge
[19:37] <james_w> that's intended design in the current code
[19:38] <james_w> well, not exactly, but the revno changing the etag is
[19:38] <lifeless> so, we have to fix that.
[19:38] <lifeless> what else
[19:38] <lifeless> (if we don't fix it we cannot have a smooth upgrade of the server farm). Its a designed in error.
[19:39] <lifeless> oh, and the appserver 'name' should be present in responses so we can debug things remotely.
[19:55] <bdmurray> I've running into an error when running make run - "cannot import name SAFE_INSTRUCTIONS" from bzrlib.plugins.builder.recipe
[19:56] <lifeless> update your sourcecode
[19:56] <lifeless> utitilies/update-sourcecode
[20:02] <bdmurray> Updating dulwich to revision 424 (No change)2kB/s | Fetching revisions:Finishing stream
[20:02] <bdmurray> Exception AttributeError: "'NoneType' object has no attribute 'close'" in <bound method SmartSSHClientMedium.__del__ of SmartSSHClientMedium(bzr+ssh://brian-murray@bazaar.launchpad.net/)> ignored
[20:03] <lifeless> and cd to the download-cache and run bzr update
[20:06] <bdmurray> it is up to date at revision 183
[20:10] <lifeless> james_w: can we move the retracer to prod please?
[20:11] <james_w> lifeless: that's not what I was playing with, and I have no control over it
[20:11] <lifeless> ah ok
[20:18]  * maxb raises two eyebrows at finding an executing code import for a deactivated project
[20:21] <maxb> (lp:libs)
[20:24] <jelmer> maxb: There is more than one..
[20:24] <maxb> yes, my point is there shouldn't be :-)
[20:25] <jml> it's not that surprising when you think about it.
[20:25] <maxb> LP does at least does not forbid visibility of these
[20:47] <bdmurray> lifeless: did you have anymore ideas?
[20:47] <lifeless> sorry otp
[20:55] <jml> why do we need to compile templates to run tests?
[20:59] <jml> lifeless, are we having our scheduled call?
[21:04] <cr3> jml: welcome back! fyi, I've spent the last week or so implementing the results tracker: https://launchpad.net/launchpad-results
[21:04] <jml> cr3, thanks. I'm glad to hear it.
[21:04] <cr3> jml: following discussions with lifeless, we decided to impelement this new feature as a standalone web app which could eventually be folded into the core once it becomes stable
[21:04] <jml> a sound plan.
[21:05] <cr3> jml: that way, we can reach stability more quickly than if I implemented directly in the core, and we can make mistakes much more easily too
[21:05]  * cr3 usually gets things right on the third try on average :(
[21:05] <lifeless> jml: yes
[21:06] <cr3> jml: I already have a pretty neat web app pushed into a branch which integrates django, zope, storm and lazr. seems to work well so far
[21:06] <lifeless> jml: ran slightly over with statik
[22:02] <jml> g'night all
[22:02] <mwhudson> jml: g'night
[22:11] <lifeless> night
[22:37] <lifeless> sinzui: hi
[22:37] <lifeless> sinzui: I would like to learn aboot batching!
[22:38] <sinzui> hi lifeless
[22:39] <lifeless> sinzui: is now a good time for you?
[22:39] <sinzui> it is
[22:39] <lifeless> great
[22:39] <lifeless> so I was thinking mailing list moderation pages would be a good one for me to learn on
[22:40] <sinzui> Good choice
[22:40]  * sinzui looks at browser code
[22:40] <wallyworld_> morning
[22:42] <sinzui> lifeless I think we want to start by making held_messages a cachedproperty because we may reference it 3 times
[22:43] <lifeless> sinzui: ok. I'm just pushing current devel up to lp:~lifeless/launchpad/registry which is where I'll put this work
[22:43] <sinzui> okay
[22:43] <lifeless> so, I can do the cachedproperty change easily; can you tell me a little about how batching hangs together while I do that?
[22:45] <sinzui> lifeless: lets talk about this: http://pastebin.ubuntu.com/493322/
[22:45] <lifeless> sinzui: so held_messages won't benefit much by being a cachedproperty. we can come back to that
[22:46] <lifeless> ah, interesting
[22:46] <lifeless> so we wrap the result set
[22:46] <sinzui> lifeless, the BN holds the record set and does not realise it until we iterate over it. BEware of indexing it though. I recently discovered that that does not realise the data, we just call the DB 75 times
[22:48] <sinzui> lifeless our BN sets the default batch size to what we have in config.launchapd.default_batch_size (75?) you can pass size=20 if you believe we want a different size
[22:48] <lifeless> to the constructor ?
[22:49] <sinzui> lifeless correct. Subclasses of the BN may set different size rules or singular/plural headings so that we do not need to set the info in __init__
[22:49] <lifeless> http://paste.ubuntu.com/493324/
[22:50] <lifeless> thats obviously mostly your code
[22:50] <sinzui> lifeless, the request is very important. The BN will look for start and batch (size) params to control the slice. We will raise an BatchSizeError (?) if the user tries to exceed our hard limit
[22:51] <sinzui> ouch we were calling getReviewableMessages() twice for every page load?
[22:51] <lifeless> yes
[22:52] <lifeless> which is old school sqlobject in fact
[22:52] <lifeless> note that creating a resultset is pretty cheap in general because they are lazy: they don't do sql immediately
[22:52] <lifeless> brb guy at door
[22:55] <sinzui> lifeless: We often have navigation links before and after the batch we are iterating over: This is template code: http://pastebin.ubuntu.com/493327/
[22:55]  * sinzui looks for real template
[22:57] <sinzui> ah, that is nice, we are adapting the message in the template. This might be an easy addition
[22:59] <rockstar> mwhudson, is this better?
[22:59] <mwhudson> rockstar: i think so
[23:00] <mwhudson> rockstar: obviously there's no sql that can find the affected recipes
[23:00] <bdmurray> sinzui: did you have an idea about how to fix bug 636412?
[23:00] <rockstar> mwhudson, on the contrary.
[23:00] <mwhudson> rockstar: tbh, i'm tempted to suggest a bzr-builder change
[23:00] <sinzui> lifeless: in team-mailing-list-moderate.pt, I think we only require the navigation headers because the table is doing the right thing. This might be the final code for the template: http://pastebin.ubuntu.com/493328/
[23:00] <rockstar> http://pastebin.ubuntu.com/493314/
[23:00] <rockstar> mwhudson, ^^
[23:01] <mwhudson> rockstar: how do you know that there are no recipes with the same problem?
[23:01] <rockstar> mwhudson, a better query would be to find out where "." is the value of sourcepackagerecipedatainstruction.directory
[23:01] <mwhudson> yeah, that would work here i guess
[23:01] <rockstar> mwhudson, what would you bzr-builder change be?
[23:01] <mwhudson> rockstar: i'm tempted to say that bzr-builder should change so that it can return an invalid recipe from stringification, but tell you about it
[23:01] <mwhudson> so you can display a warning on the recipe's page
[23:01] <lifeless> sinzui: sorry for the interrupt
[23:01] <sinzui> bdmurray, since I cannot see how the user got to that page, I think we should consider that the view should handle the case of URL hacking...
[23:03] <bdmurray> sinzui: right, I haven't seen something like that before
[23:03] <rockstar> mwhudson, that would probably work longterm, yes.
[23:04] <rockstar> mwhudson, for the short term, to restore access to the recipe, does the SQL route sound fine?
[23:04] <mwhudson> rockstar: this would mean changing bzr-builder to not use __str__ to stringify recipes i guess, something i always hate a bit :)
[23:04] <mwhudson> rockstar: yeah
[23:04] <sinzui> bdmurray, the template could guard the form with a new view attr. Maybe view/can_subscribe. That view property does something like:
[23:04] <sinzui> return self.context is not getUtility(ILaunchpadCelebrities).ubuntu
[23:04] <mwhudson> rockstar: is it clear what the intent of the recipe is?
[23:04] <rockstar> mwhudson, maybe we could just modify __str__ to be a bit smarter?
[23:04] <mwhudson> that'd be possible too
[23:05] <rockstar> mwhudson, the recipe has two lines: the base branch and the nest command
[23:05] <sinzui> bdmurray, I suppose the form should also have a sentence for the ubuntu to explain we do not want the user to shoot himself in the foot
[23:05] <lifeless> sinzui: that seems very easy
[23:05] <lifeless> sinzui: whats the key thing in the tal:repeat that you looked for to make sure it wrks ?
[23:05] <sinzui> lifeless yes indeed
[23:06] <sinzui> That widget hack is rather convenient I think
[23:06] <lifeless> sinzui: I don't undertand whats going on there
[23:07] <lifeless> sinzui: what tests are normally added in a case like this?
[23:10] <sinzui> lifeless: I like to see a test to verify the view is returning a BN. Since the headers are set, we should test the bn.default_singular_heading and default_plural_heading
[23:11] <sinzui> lifeless: The template will have upper and lower batch ids to confirm that both navs are rendered. We can test by calling render() on the view or with a TestBrowser
[23:11]  * sinzui looks for existing tests
[23:11] <lifeless> sinzui: can you expand on what the 'widget hack' does?
[23:12] <sinzui> lifeless the adapted message is converted to a HTML fragment in lp/registry/templates/message-moderation.pt
[23:12] <lifeless> sinzui: is that the message/@@+moderation bit ?
[23:13] <sinzui> lifeless yes, but I now think there is one more change needed to the table...
[23:14] <sinzui> lifeless: I think we need to change the line before @@_moderation to
[23:14] <sinzui> tal:repeat="message view/held_messages/currentBatch"
[23:16]  * sinzui is still looking for existing tests for held_messages
[23:18] <sinzui> lifeless: I do not see any tests for the view that is generating the form. We really want one and I really think we have once because I recall reading a test to explain how to put messages into the expected state
[23:19] <lifeless> I'm adding one to test_team
[23:19] <lifeless> can consolidate later
[23:20] <lifeless> browser/tests/test_team, I mean
[23:20] <sinzui> lifeless look at stories/mailing-lists/moderation.txt which puts messages into the state
[23:20] <lifeless> thanks
[23:20] <lifeless> most of these tests don't need that, just the batch ids do, right?
[23:22] <sinzui> lifeless, yes. and we could check the batch ids in the moderation test since we have the template rendered. Lifeless I am a bit pedantic about verifying the batch ids because I discovered we had two upper navs before, or that one never rendered at the bottom of a very long list
[23:22]  * sinzui also added the singular/plural message support
[23:23] <lifeless> ok
[23:23] <lifeless> looking in moderation.txt for the batch ids
[23:23] <lifeless> Would this be a good point to check ?
[23:23] <lifeless> Foo Bar sees that there is one message waiting for approval.
[23:23] <sinzui> yes
[23:23] <lifeless> is there an example of checking this elsewhere?
[23:27] <sinzui> me thinks
[23:28] <thumper> sinzui: are you free for a call?
[23:29] <lifeless> thumper: sinzui is training me just now, should be finished soon.
[23:30] <thumper> lifeless: training you to do what?
[23:30] <lifeless> batch things
[23:30] <lifeless> just bringing all the bits together quickly
[23:30] <lifeless> I couldn't find a clear guide to batching-pages when I asked around yesterday.
[23:32] <sinzui> lifeless print find_tag_by_id(admin_browser.content, 'batchnav_first')['class'] should print first
[23:33] <sinzui> that does not look right, the upper class is missing from this template
[23:33] <lifeless> will it error if someone has doubled things up or something?
[23:33] <sinzui> yes
[23:35] <sinzui> lifeless, I think my days of checking upper and lower batches are over. The markup is rendered with html classes now: upper-batch-nav and lower-batch-nav
[23:36] <sinzui> lifeless, and the nav is only rendered if there is a batch! we need to exceed 5 messages (5 is the default batch size in test)
[23:38] <mwhudson> jelmer: around? http://launchpadlibrarian.net/55539932/vcs-imports-r-project-trunk.log is very odd
[23:38] <sinzui> I have just confirmed that the top and bottom navigators are rendering duplicate ids for the links :(
[23:39] <sinzui> Well That is why i wanted a test ;)
[23:39] <jelmer> mwhudson: It's happened on at least one other cscvs import as well
[23:39] <mwhudson> jelmer: but not all?
[23:39] <mwhudson> jelmer: could it be per-importd perhaps?
[23:39] <jelmer> mwhudson, it doesn't appear to occur that often for that
[23:39] <lifeless> sinzui:     self.assertEqual('message', navigator.default_singular_heading)
[23:39] <lifeless> AssertionError: not equal:
[23:39] <lifeless> a = 'message'
[23:39] <lifeless> b = 'result'
[23:40] <jelmer> mwhudson: actually, that reminds me
[23:40] <lifeless> current diff
[23:40] <lifeless> http://paste.ubuntu.com/493338/
[23:40]  * sinzui rechecks code
[23:40] <mwhudson> jelmer: well it will only happen when there is a new rev to import i guess?
[23:41] <sinzui> lifeless ._singular_heading and ._plural_heading.
[23:41] <jelmer> mwhudson: that's true I guess, but we've only seen 4 or so failures since the rollout. Are there really that few working and active CSCVS imports left?
[23:41] <sinzui> lifeless ^ did you see my discovery that we are generating duplicate ids for links in the upper and lower nav?
[23:42] <mwhudson> jelmer: don't know
[23:42] <lifeless> sinzui: hah!
[23:42] <lifeless> sinzui: fun.
[23:42] <mwhudson> jelmer: but if it was just pear, it would have to run on pear 5 times in a row
[23:42] <mwhudson> jelmer: that's fairly unusual
[23:43] <jelmer> mwhudson: ah, I hadn't considered that. it seems likely that's the cause then
[23:43] <mwhudson> losa ping time i guess
[23:43] <sinzui> The fix looks trivial...concatenate the view class for the nav to the like id in the template. The view/css_class will make them distinct by upper and lower.
[23:44]  * sinzui reports bug to explain
[23:44] <mbarnett> mwhudson: heya.
[23:44] <mwhudson> mbarnett: can you log into pear as importd and run "bzr whoami" pls?
[23:44] <mbarnett> importd@pear:~$ bzr whoami
[23:44] <mbarnett> Import Daemon <importd@pear>
[23:44] <mbarnett> importd@pear:~$
[23:45] <mwhudson> mbarnett: bzr --version?
[23:45] <mbarnett> http://pastebin.ubuntu.com/493339/
[23:46] <lifeless> BatchNavigator.count() is wrong
[23:46] <lifeless> need to find the right way to do that
[23:46] <jelmer> mwhudson: Perhaps not pear but one of the other ones?
[23:46] <mwhudson> mbarnett: can you try python /srv/importd.launchpad.net/production/launchpad/eggs/bzr-2.2.0-py2.6-linux-x86_64.egg/EGG-INFO/scripts/bzr whoami ?
[23:47] <mwhudson> mbarnett: pls modify path until it exists :)
[23:47] <mwhudson> jelmer: https://code.edge.launchpad.net/~vcs-imports/r-project/trunk <- looks like pear is the bad apple
[23:48] <jelmer> mwhudson: Ah, right
[23:48] <jelmer> mwhudson: also, I hadn't considered the bzr path
[23:48] <mwhudson> me neither until i saw that :)
[23:49]  * thumper upgrades to maverick
[23:50] <maxb> jelmer: I think I've figured out what's up with those slow KDE imports.... the bzr-svn logwalker doesn't incrementally commit the cachedb
[23:50] <mbarnett> mwhudson: it is fighting with me: http://pastebin.ubuntu.com/493348/
[23:50] <mbarnett> chmoding
[23:51] <mwhudson> mbarnett: that's why i put python first :)
[23:51] <lifeless> sinzui: so should we not test that here, for now ?
[23:51] <mwhudson> sorry for not using quotes, that would have been easier
[23:51] <mbarnett> mwhudson: ah, i missed the python
[23:52] <mwhudson> mbarnett: "/srv/importd.launchpad.net/production/launchpad/bin/py /srv/importd.launchpad.net/production/launchpad/eggs/bzr-2.2.0-py2.6-linux-x86_64.egg/EGG-INFO/scripts/bzr whoami" would be even more correct i guess
[23:52] <mbarnett> importd@pear:~$ /srv/importd.launchpad.net/production/launchpad/bin/py /srv/importd.launchpad.net/production/launchpad/eggs/bzr-2.2.0-py2.6-linux-x86_64.egg/EGG-INFO/scripts/bzr whoami
[23:52] <mbarnett> bzr: ERROR: Unable to determine your name.
[23:52] <mbarnett> Please, set your name with the 'whoami' command.
[23:52] <mbarnett> E.g. bzr whoami "Your Name<EMAIL_ADDRESS>[23:53] <lifeless> hmm, getting a LocationError from hold_count now
[23:53]  * lifeless puts it back as 'future'
[23:54] <sinzui> lifeless the fix is pretty easy, and I am sure there is no test for th default BN since I can see any attempt will fail.
[23:54] <sinzui> .me makes quick change
[23:55] <mwhudson> mbarnett: ok, that's good (ish, it confirms my expectation)
[23:55] <mwhudson> mbarnett: can you try the same on the other importds?
[23:55] <mbarnett> heh
[23:59] <lifeless> sinzui: yeah the test you gave blows up with NoneType in unsibscritable
[23:59] <lifeless> there are also some later failures
[23:59] <lifeless> like the Moderate button is missing?
[23:59] <mbarnett> mwhudson: same


[10:21] <ricotz> tseliot, hi
[10:22] <ricotz> tseliot, I assume you already prepared 361.45.11?
[10:29] <tseliot> ricotz: not yet, but I can have a look
[10:30] <ricotz> tseliot, I have a tarball and ppa packages for x and y
[10:30] <ricotz> so I could just push those
[10:31] <ricotz> tseliot, I assumed you left 361 out on purpose while this release was coming
[10:31] <tseliot> ricotz: if you haven't pushed them yet, I can upload the tarball from here, as soon as I'm done with the patching (which should be very quick)
[10:31] <tseliot> 361 in the archive is patched
[10:31] <ricotz> I dont think so
[10:32] <ricotz> 361.42-0ubuntu2
[10:33] <tseliot> so I didn't push 361... err...
[10:33] <ricotz> 361.45.11 should be ready for 4.6 already
[10:34] <tseliot> well, I've just pushed the old 361
[10:34] <tseliot> since I did the work for it
[10:34] <tseliot> now I'll have a look at the new 361
[10:35] <tseliot> I can test quickly here
[10:35] <ricotz> tseliot, ok, so I will wait for your tarball
[10:36] <tseliot> ok
[10:36] <ricotz> as usual don't push it to the ppa with transitionals
[10:37] <ricotz> regarding the armhf failure of 367.18 I have ignored it on purpose since it seems like a mistake by nvidia to drop vulkan support files
[10:37] <ricotz> tseliot, ^
[10:39] <tseliot> ricotz: I'm going to push that to the archive first, then I'll get rid of the transitional packages
[10:39] <tseliot> as for 367, I haven't checked it yet but yes, it's ok to ignore armhf for now. I can report the problem to NVIDIA
[10:40] <ricotz> ok, pushing it to the archive is enough from your side
[10:40] <tseliot> all right
[10:41] <ricotz> basically "nvidia_icd.json" is missing in armhf
[10:42] <tseliot> ok, thanks
[11:27] <tseliot> ricotz: the new nvidia builds fine against 4.6. I'm going to upload it now
[11:32]  * tseliot -> lunch


[12:02] <StudioUser55> The applications menu uses an extremely small font.  Changing the windows scale factor up or font size has no effect on the applications menu.  Can anyone help me with this?
[12:11] <BinarySavior> hello, intermittently (maybe 20% of the time) I boot into ubuntu studio, some unexpected behavior occurs:  Once I reach the login page, either 1) the password field is not focused and mouse and keyboard are unresponsive or 2) the password field is focused and when I type, I see a few characters appear but then it loses focus and I cannot regain focus (unresponsive mouse and keyboard). The only workaround I could find is to
[12:11] <BinarySavior> enter TTY using CRTL+ALT+F2 and then reboot with CRTL+ALT+DELETE and cross my fingers it doesn't happen again
[12:12] <BinarySavior> this has been going on since I installed the OS closer to the beginning of 2023
[12:13] <BinarySavior> and I'm using Ubuntu Studio 22.04.1
[12:38] <BinarySavior> Could this be due to another application grabbing the keyboard & mouse before I log in?
[12:44] <BinarySavior> this sounds very similar to the issues I've been experiencing: https://ubuntuforums.org/showthread.php?t=2479936
[12:44] <BinarySavior> could be TMP issue
[14:51] <Eickmeyer> BinarySavior: Here's the good news about the login screen: the password field doesn't have to be focused to be receiving input (not a bug but a feature in sddm). Also, not something we can solve in Ubuntu Studio as we didn't even theme it in that release.
[14:51] <Eickmeyer> sddm is commonly used by Ubuntu Studio, Kubuntu, and Lubuntu to handle login.
[16:36] <BinarySavior> Eickmeyer, but I press keys on the keyboard and the password dots are not showing up in the password field
[16:45] <Eickmeyer> BinarySavior: Doesn't matter, it still reads them.
[16:45] <Eickmeyer> It's a weird "quirk" of the display manager in this case.
[16:56] <BinarySavior> ok if it happens again I will try to type my password & hit enter & wait for desktop to start up
[17:20] <StudioUser44> How do i factory rest ubuntu. was givin a computer and its locked by the administrator
[17:26] <Eickmeyer> StudioUser44: You'd want to download an .iso image. https://ubuntustudio.org/download
[17:27] <Eickmeyer> Unless you want Ubuntu. https://ubuntu.com/download
[18:37] <bacteriummourner> hi, i just tried upgrading to mantic. and i'm getting "Generating grub configuration file ...
[18:37] <bacteriummourner> /etc/grub.d/09_lowlatency: 1: version_find_latest: not found
[18:37] <bacteriummourner> run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 127
[18:37] <bacteriummourner> dpkg: error processing package linux-image-6.5.0-9-lowlatency (--configure):
[18:37] <bacteriummourner>  installed linux-image-6.5.0-9-lowlatency package post-installation script subprocess returned error exit status 1"
[18:37] <bacteriummourner> anyone else getting similar?
[18:38] <Eickmeyer> Did it completely break? I fixed that.
[18:40] <bacteriummourner> i think so. says upgrade has been aborted. your system could be in an unusable state. a reocvery will now run. and then the recovery fails
[18:40] <Eickmeyer> bacteriummourner: It looks like you, at one point in time, removed ubuntustudio-lowlatency-settings but did not *purge* it, which left /etc/grub.d/09_lowlatency in place.
[18:40] <bacteriummourner> oh
[18:41] <bacteriummourner> so i apt purge *something* ?
[18:41] <bacteriummourner> ubuntustudio-lowlatency-settings
[18:41] <Eickmeyer> I don't know *why on earth you would remove that*.
[18:42] <Eickmeyer> Let me think. You're in a pickle.
[18:43] <Eickmeyer> Ok, the damage has been done. What happens if you run `sudo apt purge ubuntustudio-lowlatency-settings`?
[18:43] <bacteriummourner> i don't recall ever removing ubuntustudio-lowlatency-settings. i just went to check, and my desktop didn't have it either (it does now)
[18:44] <Eickmeyer> Ok, don't purge it now.
[18:44] <bacteriummourner> says unable to locate package on my laptop though
[18:45] <bacteriummourner> derp
[18:45] <bacteriummourner> typoed
[18:45] <Eickmeyer> That means, for whatever reason, it was removed. You can safely `sudo rm /etc/grub.d/09_lowlatency` then `sudo chmod +x /etc/grub.d/10_linux` and try the upgrade process again.
[18:46] <bacteriummourner> ok, will give it a try, thanks
[18:46] <Eickmeyer> yw
[18:54] <bacteriummourner> worked great! rebooted fine, and just installed ubuntustudio-lowlatency-settings. do i need to do anything re: 10_linux or am i good?
[18:55] <Eickmeyer> bacteriummourner: run lsb_release and see what it tells you you're on.
[18:56] <bacteriummourner> says no LSB modules are available
[18:56] <Eickmeyer> Ope, my bad. `lsb_release -a`
[18:57] <bacteriummourner> desc: ubuntu 23.10, release 23.10, codename: mantic - guessing it's a success?
[18:57] <Eickmeyer> Looks like it! Do me a favor and run `sudo update-grub` just to make sure it doesn't error.
[18:57] <Eickmeyer> The new version doesn't have 09_lowlatency.
[18:58] <bacteriummourner> no error, looks good. thanks again so much. you're the best!
[18:58] <Eickmeyer> You're welcome!
[22:06] <Iammotrethanjust> anyone have an idea of how to use blue yeti with ubuntustudio?
[22:07] <Eickmeyer> Iammotrethanjust: It should be plug-and-play, but if using JACK you might have to patch it with a patchbay.
[22:07] <Iammotrethanjust> ah
[22:07] <Iammotrethanjust> so i was on the right track trying to patch with carla
[22:07] <Eickmeyer> Yep.
[22:08] <Iammotrethanjust> its kinda stopped being plug and play as soon as that studio control opened
[22:08] <Iammotrethanjust> so jack is blocking
[22:09] <Iammotrethanjust> stereo appears not to work well out of the box
[22:10] <Eickmeyer> Ok, one thing you need to know is that Studio Controls just runs a daemon called Autojack. It's a frontend for that, nothing more. So, if you leave JACK in a state and shut down or log out, Autojack puts it back in that state when you restart it. Studio Controls does nothing else but check that when you open it.
[22:11] <Eickmeyer> Studio Controls takes a moment to find out what state JACK is in, so if it looks like thing are weird at first, that's why.
[22:11] <Eickmeyer> But if everything is working for you, that's great.
[22:12] <Iammotrethanjust> its just me your right
[22:13] <Iammotrethanjust> so if i get it working to where i can use it - should be good - it will remember
[22:13] <Eickmeyer> Correct.
[22:14] <Iammotrethanjust> fun and games i will invite the kids over
[22:14] <Eickmeyer> hehe
[22:14] <Iammotrethanjust> thanks erick
[22:14] <Eickmeyer> No prob
[22:14] <Iammotrethanjust> good thing i am not using my name on this channel
[22:15] <Iammotrethanjust> gord not gordon for me
[22:15] <Iammotrethanjust> sheesh
[22:15] <Iammotrethanjust> that was the name I got when i was in trouble
[22:15] <Eickmeyer> Meh, everybody knows who I am anyways. I receive my share of death threats and the police know to check with me before swatting me. :)
[22:15] <Iammotrethanjust> your name is familiar
[22:16] <Eickmeyer> I'm the leader of Ubuntu Studio, Erich Eickmeyer.
[22:16] <Iammotrethanjust> i have been around a few years
[22:16] <Eickmeyer> Ah, cool.
[22:16] <Iammotrethanjust> you see? i do read...
[22:16] <Eickmeyer> Yep!   My uncle used to be not only a radio DJ and announcer but also a station manager. He'd laugh at 'em.
[22:20] <Iammotrethanjust> until they show up in the parking lot
[22:20] <Eickmeyer> Well, this was the 80s in Eastern Washington where if someone did that they'd probably get shot first.
[22:21] <Iammotrethanjust> i am a Canadian  we would only make you listen to east coast music
[22:21] <Eickmeyer> Ah, yeah, I see. Some people these days get butthurt about that.
[22:22] <Iammotrethanjust> people get hurt about many things,  we Canadians tend not to sue each other though
[22:23] <Eickmeyer> True. Us down stateside tend to either 1) shoot first and sue later, or 2) sue first and shoot later. 🙄
[22:23] <Eickmeyer> (only kidding)
[22:23] <Eickmeyer> I'd never.
[22:24] <Eickmeyer> Anyhow, gotta look at a bug that's calling my name.
[22:25] <Iammotrethanjust> thanks again


[14:58] <schopin> o/
[14:58] <ginggs> o/
[14:59] <jawn-smith> o/
[14:59] <dbungert> o/
[14:59] <slyon> o/
[14:59] <jawn-smith> o[14:59] <bdrung> \o
[14:59] <jawn-smith> oops, didn't leave my sword by the door
[15:00] <sil2100> o/
[15:00] <jawn-smith> #startmeeting Weekly Ubuntu Foundations team
[15:00] <meetingology> Meeting started at 15:00:41 UTC.  The chair is jawn-smith.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[15:00] <ogayot> o/
[15:00] <juliank> o/
[15:00] <meetingology> Available commands: action, commands, idea, info, link, nick
[15:00] <jawn-smith> #topic Lightning Round
[15:01] <jawn-smith> The status is here: https://discourse.ubuntu.com/t/foundation-team-updates-thursday-30-june-2022/29123/10
[15:01] <jawn-smith> Let's all take a few minutes to read and ask questions
[15:01] <jawn-smith> sil2100: It says you reviewed the --until/--thru PR
[15:01] <jawn-smith> should I merge it?
[15:02] <sil2100> Aaaah, didn't press the button
[15:02] <ginggs> jawn-smith: i saw your libdigidoc fix, that package is orphaned in debian (QA maintained).  if you're interested in getting an upload into debian, i'd be happy to sponsor
[15:02] <sil2100> jawn-smith: done now o/
[15:03] <jawn-smith> ginggs, sil2100 thanks! I did submittodebian the patch I created
[15:03] <schopin> libdigidoc? Isn't that obsoleted upstream too?
[15:03] <jawn-smith> should it be removed from Debian/Ubuntu then?
[15:04] <schopin> I'd be all for it, but that's mostly because I get spammed any time someone clicks the rebuild button on LP as I'm TIL
[15:04] <jawn-smith> well, now I'm TIL :)
[15:04] <schopin> \o/
[15:05] <jawn-smith> No reverse dependencies...
[15:05] <mclemenceau> o/
[15:05] <jawn-smith> Okay I'll investigate filing a removal bug as part of my +1 shift this week
[15:06] <schopin> Have a look at my initial RM bug, there should be some pointers there.
[15:06] <ginggs> libdigidoc-tools might still be useful
[15:07] <jawn-smith> I'll have a look this afternoon
[15:07] <jawn-smith> and ping ginggs if we decide it should stay, then we can remove the diff from Debian
[15:07] <jawn-smith> Any other questions?
[15:08] <slyon> enr0n: I didn't receive this oomd email, is it stuck in moderation?
[15:08] <enr0n> slyon: oof, possibly, let me check the list archive
[15:09] <enr0n> This one I think: https://lists.ubuntu.com/archives/ubuntu-devel/2022-June/042159.html
[15:10] <jawn-smith> The missing email has been found
[15:10] <slyon> thx, it went through after all :)
[15:10] <jawn-smith> Any other questions?
[15:11] <jawn-smith> #topic Release incoming bugs
[15:11] <jawn-smith> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-kk-incoming-bug-tasks.html#foundations-bugs
[15:11] <jawn-smith> bug 1980348
[15:12] <jawn-smith> gcc is kinda important
[15:12] <doko> I figured that out an hour ago
[15:12] <doko> just closing
[15:12] <jawn-smith> oh excellent
[15:12] <jawn-smith> Thanks!
[15:12] <jawn-smith> Are you closing for both gcc-10 and gcc-12?
[15:14] <jawn-smith> Sounds like it's still building for both, so we'll discuss it next week if it comes back
[15:14] <jawn-smith> bug 1980195
[15:14] <jawn-smith> Looks like a potential dependency/import issue?
[15:14] <jawn-smith> bdrung: Do you have an opinion?
[15:15] <bdrung> jawn-smith, that was a regression in apport, but already fixed with the latest kinetic version
[15:16] <jawn-smith> Excellent, thanks. Can you close the LP bug please?
[15:16] <bdrung> i'll do the paperwork and close it
[15:16] <jawn-smith> Thanks!
[15:16] <ginggs> could we have a look at LP: #1979297 and see if it's something we want carded please?
[15:17] <jawn-smith> xypron: Thoughts on carding this?
[15:21] <jawn-smith> We've agreed to let the removal go ahead, and therefore this does not need a card
[15:21] <jawn-smith> That's it for kk
[15:21] <jawn-smith> #link https://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-jj-incoming-bug-tasks.html#foundations-bugs
[15:21] <jawn-smith> bug 1979951
[15:21] <slyon> I tagged that one
[15:21] <jawn-smith> Is filed against both netplan.io and systemd
[15:22] <slyon> it's a regression, probably introduced by netplan switching to the "networkctl reload" command (instead of hard restart of sd-networkd)
[15:22] <slyon> I think we should double check the situation on NetworkManager vs sd-networkd backends
[15:22] <jawn-smith> Based on your last comment it seems this should be fixed in systemd, not netplan.io? Or do both need work?
[15:22] <slyon> and then probably apply the upstream fix to systemd that's mentioned in the bug
[15:22] <slyon> most probably systemd only
[15:22] <slyon> so +1 for carding it
[15:22] <jawn-smith> enr0n: Do you have the bandwidth to look into this?
[15:23] <enr0n> jawn-smith: Yeah I should now
[15:23] <jawn-smith> Okay so let's card it since someone has bandwidth to look into it. mclemenceau do you mind doing the carding?
[15:24] <mclemenceau> Ok
[15:24] <schopin> Do we want proper lo support in netplan, too? It does seem kinda hacky to use the ethernet type for it?
[15:24] <slyon> schopin: we have a feature-request/bug report about "dummy" devices, which would be a better match for loopback
[15:24] <slyon> we'll get to that eventually
[15:25] <xnox> it would help with default resolved configs of dns too.
[15:25] <schopin> nice, thanks :)
[15:25] <xnox> (to set that on lo)
[15:25] <jawn-smith> Okay excellent. It will be carded and the priority can be figured out in the future
[15:25] <jawn-smith> bug 1978125
[15:25] <jawn-smith> we discussed this last week but I don't remember where we landed
[15:25]  * jawn-smith reads logs
[15:25] <schopin> carded already
[15:26] <jawn-smith> Okay so let's just remove the tag from the LP bug
[15:26] <jawn-smith> I'll do that real quick
[15:26] <ogayot> in iproute2, dummy and loopback type both exist
[15:26] <jawn-smith> tag removed
[15:27] <jawn-smith> rls-ii is empty
[15:27] <jawn-smith> rls-ff only has the <IP_ADDRESS> bug
[15:28] <jawn-smith> #topic Team proposed-migration report
[15:28] <jawn-smith> #link https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#foundations-bugs
[15:28] <jawn-smith> no v_orlon today so I'll do this
[15:28] <jawn-smith> ubuntu-meta is still with desktop
[15:29] <slyon> we should probably ignore the systemd failures, as we've uploaded v251 today and all systemd related tests are currently re-run
[15:29] <jawn-smith> python3-stdlib-extensions was with doko I believe
[15:29] <jawn-smith> Any updates?
[15:30] <jawn-smith> slyon: ack, thanks. Will ignore systemd
[15:31] <jawn-smith> doko will look at python-bayespy and bdrung will look at apport. Thanks!
[15:31] <jawn-smith> usb-creator is waiting on an MIR
[15:31] <jawn-smith> mutt is also waiting on an MIR (which is waiting on security)
[15:31] <jawn-smith> systemd, skip
[15:31] <doko> is anybody working on these MIRs?
[15:31] <ginggs> i think python-bayespy just needs a retry with the new version
[15:32] <slyon> doko: yes, those are in progress
[15:32] <doko> ta
[15:32] <jawn-smith> doko: Yes, at least the two mutt related MIRs are waiting on security review
[15:33] <schopin> alexghiti is the one driving them from our side
[15:33] <jawn-smith> openssl
[15:33] <schopin> on it
[15:33] <jawn-smith> schopin: hooray, thanks
[15:33] <jawn-smith> llvm-toolchain-14
[15:34] <schopin> missing builds are for the same reason as gcc, I believe.
[15:34] <jawn-smith> Excellent. Does i386 need to be re-triggered?
[15:35] <ginggs> jawn-smith: do it!
[15:35] <jawn-smith> done!
[15:35] <doko> and the autopkg test failure is a kill -9
[15:35] <jawn-smith> the autopkgtests for this fenics-dofinx package look flakey
[15:36] <doko> so try on a machine with more memory?
[15:36] <schopin> there was a sigkill in the test suite, oom?
[15:36] <jawn-smith> Does it need to be added to big-packages?
[15:36] <jawn-smith> Anyone want to volunteer to look into that?
[15:36] <ginggs> i'll have a look at fenics-dofinx and add it to big_packages
[15:37] <jawn-smith> thanks!
[15:37] <ginggs> now, that I can :)
[15:37] <jawn-smith> moving on
[15:37] <jawn-smith> lintian appears to need MIR investigation
[15:37] <slyon> yay! new lintian depends. they're being introduced faster than we can process them :)
[15:37] <jawn-smith> or possibly just binary package demotion if we're lucky?
[15:37] <slyon> I'll do the initial investigation for lintian
[15:37] <jawn-smith> slyon: thanks!
[15:38] <jawn-smith> apport is with bdrung
[15:38] <jawn-smith> python-httplib2. One of those is apport and therefore already covered
[15:38] <jawn-smith> then python-httplib2 itself has an armhf regression
[15:38] <ogayot> I think the python-httplib2 vs apport needs a retry
[15:38] <jawn-smith> anyone here an expert in both python and the armhf architecture....?
[15:39] <waveform> erm...
[15:39] <jawn-smith> waveform: do you have bandwidth to look at that test?
[15:39] <waveform> yeah, I'll take that one
[15:39] <ogayot> E   ModuleNotFoundError: No module named 'cryptography'
[15:39] <jawn-smith> Thanks!
[15:40] <jawn-smith> well that should be an easy fix
[15:40] <jawn-smith> moving on, curl is missing builds on quite a few architectures
[15:40] <jawn-smith> I'll take that one
[15:40] <waveform> don't jinx it...
[15:40] <jawn-smith> pygments
[15:41] <jawn-smith> has an excuses bug already
[15:41] <jawn-smith> waiting on a new version of pytest
[15:42] <jawn-smith> so we can ignore that for now
[15:42] <jawn-smith> everything else is 0 days old so that's it for proposed migration
[15:42] <bdrung> https://tracker.debian.org/pkg/pytest shows a lot of regressions
[15:42] <jawn-smith> #topic AOB
[15:43] <jawn-smith> Monday is a US holiday
[15:43]  * xnox 0/
[15:44] <xnox> a few ubiquity uploads to jammy & kinetic are missing from lp:ubiquity. Does anybody want to push their git tags / uploads? or should i synthesize those?
[15:44] <xnox> i.e. uploads from bdrung bdmurray and external person.
[15:46] <bdrung> the commits are here: https://code.launchpad.net/~ubuntu-installer/ubiquity/+git/ubiquity/+ref/master
[15:49] <xnox> bdrung:  and tags? git push --tags
[15:49] <xnox>  22.10.3
[15:49] <xnox> 22.04.16
[15:49] <xnox> 22.04.15
[15:50] <xnox> https://git.launchpad.net/ubiquity?h=master => tags and jammy branch are missing.
[15:50] <xnox> i can tag 22.04.16 and push it to jammy branch, if that's what we are ok with.
[15:51] <xnox> but want to check if something unexpected happened.
[15:51] <xnox> also tsimonq2 upload is nowhere to be seen in git
[15:51] <bdrung> it's probably fine to add the missing tags (after checking that this tag actually is identical to the uploaded dsc)
[15:52] <xnox> also http://launchpadlibrarian.net/607553669/ubiquity_22.10.2_22.10.3.diff.gz chagnes the icon, which is not documented, and not expected?
[15:53] <xnox> i'll query that separately.
[15:57] <jawn-smith> This conversation seems to be resolved, so
[15:57] <jawn-smith> #endmeeting
[15:58] <meetingology> Meeting ended at 15:57:59 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-06-30-15.00.moin.txt
[16:03] <bdrung> for the apport autopkgtest failure we have https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1980390 now