[21:41] <nagappan> ara, in Ubuntu 9.10, I'm seeing this warning when importing wnck in LDTPv2, http://pastebin.com/d3d7dbed5, request to look when free
[21:47] <ara> nagappan, you get the same when importing in interactive python. I guess you can file a bug against python-wnck package
[21:48] <ara> nagappan, gnome-python-desktop package, actually
[22:04] <nagappan> ara, sure, I get while importing in python prompt as well
[22:04] <nagappan> ara, I haven't noticed in Ubuntu 9.04
[22:20] <thekorn> nagappan, I think there is a bugreport about this on the gnome bugzilla, let me try to find it
[22:20] <thekorn> https://bugzilla.gnome.org/show_bug.cgi?id=590534
[22:20] <ubot4`> Gnome bug 590534 in general "gnome-python-desktop-2.26.0 libwnck binding breaks with libwnck-2.26.2 (works with libwnck-2.26.1)" [Critical,Resolved: fixed]


[02:53] -ubottu:#ubuntu-news- ::planet:: Ubuntu Blog: How a real-time kernel reduces latency in telco edge clouds @ https://ubuntu.com//blog/how-a-real-time-kernel-reduces-latency-in-telco-edge-clouds
[02:53] -ubottu:#ubuntu-news- ::planet:: Ubuntu Blog: Ubuntu AI Podcast: Episode 4 @ https://ubuntu.com//blog/ubuntu-ai-podcast-episode-4
[02:53] -ubottu:#ubuntu-news- ::planet:: Scarlett Gately Moore: KDE: KDE neon user edition updates! Debian updates, Snaps on hold. @ https://www.scarlettgatelymoore.dev/kde-kde-neon-user-edition-updates-debian-updates-snaps-on-hold/
[02:53] -ubottu:#ubuntu-news- ::planet:: Alan Pope: 95 bits per second @ https://popey.com/blog/2023/09/95-bits-per-second/
[12:47] -ubottu:#ubuntu-news- ::security:: Episode 209 @ https://ubuntusecuritypodcast.org/episode-209/
[14:04] -ubottu:#ubuntu-news- ::omg!ubuntu:: 10 Best Features in GNOME 45 @ https://www.omgubuntu.co.uk/2023/09/new-gnome-45-features


[01:41] <coathanger> What kind of response time can one normally expect on a billing inquiry?
[01:42] <jblount> coathanger: I think the person that goes through those tries to turn them around in one or two days, did you submit the form at https://one.ubuntu.com/support/account-assistance ?
[01:43] <coathanger> Yes, one on 7-10 and another on 7-20... similar issue.
[01:43] <jblount> coathanger: Wow! If you pm me your email I'll ask them to take a look at the queue.
[01:44] <coathanger> Getting billed multiple times.  Thanks, will do.
[01:44] <jblount> coathanger: Sorry about the wait, we're in the process of turning that into something three people deal with instead of one, but I'm sure we can get you fixed up.
[06:39] <nUboon2Age> kermiac: after i got networkmanager running again, all the files and folders got down to my desktop. :)
[06:40] <kermiac> nUboon2Age: That is good to hear mate :)
[06:40] <nUboon2Age> working!  :D
[06:41] <nUboon2Age> you gave me the clue.  what was it (forgotten now) it was a log file or something.  That said something about errors due to missing networkmanager.
[06:43] <nUboon2Age> oh yeah  ~/.cache/ubuntuone/log/syncdaemon-exceptions.log
[08:11] <mandel> vds, ping
[08:37] <vds> mandel: pong
[08:37] <mandel> vds, very good morning!
[08:37] <mandel> vds, how are u doing?
[08:37] <vds> mandel: good morning to you!
[08:37] <vds> mandel: not bad
[08:37] <vds> mandel: we need to investigate that problem with the service
[08:37] <mandel> vds, wanna try and see why you could not build the branch?
[08:38] <vds> yep
[08:38] <mandel> vds, yes, lets take a look
[08:38] <vds> mandel: ok, what's the plan?
[08:39] <mandel> vds, so,  my plan for today is: fix your issue with the service, and se if you can approve two diff branches
[08:39] <mandel> vds, integrate the selupdate with the ui and do a point to point test :D
[08:39] <mandel> vds, does that sound good to you?
[08:40] <vds> yep
[08:40] <vds> but my question was more
[08:40] <vds> how do we check why it is not working here?
[08:42] <mandel> vds, mm, lets start by getting the branch again
[08:42] <mandel> vds, once you do that, can you pastebin the build script?
[08:42] <mandel> vds, is the main.build file
[08:44] <vds> mandel: ok
[08:45] <mandel> vds, it is strange that your are not getting the build results, and is the build script that does that
[08:47] <Rhonda> I am a bit puzzled by the ubuntuone-ios-client. bzr cloning it gives me a LICENSE.txt stating that it's under the GNU Affero GPL. From my understanding that would be even more violated by the appstore because it would require the appstore to provide the source itself?
[08:48] <vds> mandel: I get the branch, I build, I bootstrap, and try to install the service
[08:49] <vds> mandel: is that correct?
[08:49] <mandel> vds, yes, if everything works ok that is the idea
[08:49] <vds> :)
[09:14] <vds> mandel: I did the build and the installer
[09:14] <vds> mandel: what should I have now?
[09:18] <Rhonda> Hmm, no, got that wrong, the appstore wouldn't have to provide the source because the binary doesn't run on the appstore. I still wonder about the opinion and approach that is taken here for the iPhone client in the light of recent compaints that the appstore regulations aren't GPL compatible.
[09:41] <mandel> vds,do you have a build_results folder in the install dir?
[09:42] <vds> mandel: nope
[09:47] <mandel> can you pastebin the main.build you have from that branch?
[10:05] <vds> mandel: http://pastebin.org/413010
[10:07] <mandel> vds, you are right, I'm stupid and told you tolook somewhere that is added by the other brach
[10:07] <mandel> vds, mea culpa
[10:07] <mandel> vds, you have to go to src\Canonical.UbuntuOne.ProcessDispatcher\bin\Debug
[10:08] <mandel> vds, I told you my brain was damaged lst night :P
[10:09] <vds> mandel: still the exe is not there
[10:10] <mandel> vds, there should be an .exe there, I'm 99% sure
[10:10] <mandel> vds, let me double check
[10:11] <vds> I did the build and the install and in src\Canonical.UbuntuOne.ProcessDispatcher\bin\Debug there is no .exe
[10:11] <mandel> vds, I'm doing it in that branch right now
[10:11] <mandel> vds, give me 20 s ;)
[10:12] <mandel> vds, are you using explorer to look at the folder?
[10:12] <vds> mandel: nope the shell
[10:13] <vds> mandel: I never use explorer even if the shell is awful
[10:13] <mandel> vds, and you do not have Canonical.UbuntuOne.ProcessDispatcher.exe?
[10:13] <mandel> vds, really?
[10:13] <vds> mandel: I have a bunch of dll and and two .pdb
[10:14] <vds> ans two xml
[10:14] <mandel> vds, do you know how to request remote assistance in windows 7??
[10:15] <mandel> vds, I want to take a look at your system :P
[10:16] <vds> mandel: not sure it works win the version on win I have
[10:16] <vds> mandel: but
[10:16] <vds> I nstalled ssh on it :D
[10:17] <mandel> vds, you are going to make me ssh? hehe you bastard, lets try :P
[10:17] <vds> mandel: let me setup the router
[10:17] <mandel> vds, ok
[10:27] <mandel> vds, I'm looking at your machine, and the .exe is there...
[10:27] <vds> mandel: ah
[10:27] <vds> there...where then?
[10:27] <mandel> dir C:\Users\vds\canonical\fix_gtk_installer\src\Canonical.UbuntuOne.P
[10:27] <mandel> rocessDispatcher\bin\Debug
[10:28] <vds> mandel: wrong dir
[10:28] <mandel> vds, sorry for the double line, copy paste from windows cmd is not good
[10:28] <mandel> vds, ups, true
[10:28] <vds> mandel: fix_null_pointer_start that's the branch :)
[10:29] <mandel> vds, ups...
[10:29] <mandel> vds, do you have a console open ?? I have a lock problem
[10:29] <mandel> probably you have a cmd in the bin/Debug dir
[10:30] <vds> mandel: try now
[10:30] <mandel> vds, thnx, it works now
[10:32] <mandel> vds, the .exe is there
[10:32] <vds> mandel: what did I do wrong?
[10:33] <mandel> vds, no idea, which command did u use?
[10:33] <mandel> vds, it was installer, not bootstrapper
[10:33] <vds> mandel: yep, that's what I used
[10:33] <vds> build and installer
[10:34] <mandel> vds, mm strange, I've touched nothing
[10:34] <vds> where do you see the .exe?
[10:34] <vds> mandel: ^^
[10:35] <mandel> vds, I'm clenaning the solution, can you execute the command?
[10:35] <vds> in src/Canonical.UbuntuOne.Client/bin/Debug I don't see it
[10:35] <mandel> vds, got a lock issue, I guess you are in the dir.... DOS sucks big time
[10:35] <mandel> vds, I just deleted everything hehe
[10:35] <vds> ah
[10:36] <vds> mandel: try again
[10:36] <mandel> I wanted to do a clean and let you execute it to see hwat you were doing
[10:36] <mandel> vds, where are you in the tree?
[10:37] <vds> C:\Users\vds\canonical\fix_null_pointer_start\src\Canonical.UbuntuOne.Client\ now
[10:37] <vds> mandel: ^^
[10:37] <mandel> vds, can you move to src?
[10:38] <mandel> vds, now, execute build
[10:39] <vds> mandel: I have to move one level up to do the build
[10:39] <mandel> vds, yes, sorry
[10:39] <mandel> vds, I tould you to move to src to get you out of the way of what I was doing hehe
[10:39] <vds> mandel: np, actually was more a question :)
[10:39] <vds> building
[10:39] <mandel> vds, uh, then yes ;)
[10:40] <vds> mandel: built
[10:40] <mandel> vds, okk, dont move! ;)
[10:40]  * vds frezees
[10:40] <mandel> vds, is there :D
[10:41] <mandel> src/Canonical.UbuntuOne.ProcessDispatcher/bin/Debug
[10:41] <mandel> vds ^
[10:41] <vds> arg
[10:41] <vds> mandel: in Dispatcher
[10:41] <vds> not in Client
[10:41] <mandel> vds, hahaha
[10:42] <mandel> vds, yes, well, no problem we know we can work with ssh ;)
[10:42] <mandel> vds, it happens to the best of us!
[10:48] <vds> mandel: are you still on ssh?
[10:48] <mandel> vds, no
[10:48] <vds> mandel: ssh please :)
[10:48] <mandel> vds, ok
[10:49] <vds> mandel: is returning a quite obscure error message
[10:49] <mandel> vds, doing what?
[10:49] <vds> mandel: I'm afraid it's the same problem muffinresearch had\
[10:50] <mandel> vds, ahh that is easy to solve
[10:50] <lalejand> Hi everyone, if there is a U1 developer here, can he/she check this bug report please ? https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/608011?comments=all
[10:50] <ubot4> Launchpad bug 608011 in ubuntuone-client (Ubuntu) "errors in syncdaemon.log (affects: 1) (heat: 10)" [Undecided,Confirmed]
[10:50] <mandel> vds, go to panel control, and in the search box, type services
[10:50] <lalejand> syncdaemon is using 95% of my CPU since 3 days
[10:50] <mandel> vds, one of the results should say something about local services
[10:51] <vds> mandel: yep I have the table in front of me
[10:51] <mandel> vds, look for the Ubuntu One service
[10:51] <mandel> vds, right click and properties
[10:52] <mandel> vds, in the properties, second tab (Log on)
[10:53] <vds> mandel: must be a different issue, I don;t see any service
[10:54] <mandel> vds, you did use InstallUtil, right?
[10:54] <vds> mandel: yes but it says it rolled back
[10:54] <mandel> vds, ahh, that is another issue then
[10:54] <vds> mandel: feel free to ssh
[10:54] <mandel> vds, are u root or whatever is called on windows?
[10:55] <vds> I don't think so
[10:55] <mandel> vds, I'll not be able to move to admin over ssh :(
[10:55] <mandel> vds, you have to start a console as root
[10:55] <mandel> vds, I know, major pain in the ass
[10:55] <vds> mandel: ah interesting, how do I do it?
[10:55] <vds> apart from googling for it :)
[10:56] <mandel> vds, I always right click on the cmd icon on the start menu and choose run as admin
[10:56] <mandel> vds, there must be a better way, but that is how i rulez :P
[10:58] <vds> mandel: ok, done
[10:59] <vds> mandel: now what happens?
[10:59] <mandel> vds, then you have to do what I told you to fix the issue that muffinresearch had
[10:59] <mandel> vds, you know, control panel, local services, find the ubuntu one
[11:00] <mandel> vds, properties -> logon and select local system account
[11:00] <mandel> vds, after thar, start service and stop it
[11:02] <vds> mandel: should I change the login and pwd info?
[11:02] <vds> and the user?
[11:03] <mandel> vds, you can use your user to test, or select local service account
[11:03] <mandel> vds, as you wish
[11:03] <vds> mandel: localservice account is checked
[11:03] <mandel> ok, now try to start and stop it
[11:03] <vds> but if I start it like it is I get a security error 5
[11:04] <vds> mandel: wait
[11:04] <mandel> vds, hug? try with your user, is probably becasue we used InstallUtil
[11:04] <vds> I'm wrong
[11:04] <mandel> :D
[11:04] <vds> does it need to interact with the desktop?
[11:04] <mandel> vds, not with the current code
[11:06] <vds> mandel: worked
[11:07] <vds> mandel: other ways I can test it?
[11:07] <mandel> vds, well there is nothing beside that right now hehe, we have not python to talk with ;)
[11:07] <mandel> but once you have that, you can stop it and uninstall
[11:08] <mandel> vds, use InstallUtil /u process.exe
[11:08] <mandel> vds, after that you can test the next branch that does all the installutil etc for you in the msi :)
[11:10] <vds> mandel: service removed
[11:10] <mandel> vds, cool, now the anoying things... you need to reboot to reinstall it :(
[11:10] <mandel> vds, major pain in the ass, you know windows...
[11:10] <vds> mandel: of course you have to close the service window and open it again to see it is not there because it doesn;t refresh it automatically and the manual refresh does nothing
[11:11] <vds> mandel: wooooo? to reinstall a service you have to reboot?
[11:11] <mandel> vds, didn;'t you hear me in mumble comlaining about that?
[11:11] <mandel> vds, I rebooted the bloody thing like 50/60 times....
[11:12] <mandel> vds, I nearly gave up
[11:12] <vds> nope I didn't hear that :)
[11:13] <mandel> vds, I complained and mentioned I expect a pay raise ;)
[11:13] <vds> ahahah :)
[11:13] <vds> mandel: I guess you'll desrve it if you find a way to avoid all the reboots :P
[11:14] <mandel> vds, that would be hard... but is the Os that is crap...
[11:15] <mandel> vds, anyways, reboot and try the other branch, does the same but with the msi :D
[11:15] <vds> mandel: really? :)
[11:15] <vds> on it already
[11:15] <mandel> vds, yes, really, is the os, nothing we can do about it :(
[11:16] <vds> mandel: really was about "crap" :)
[11:16] <mandel> vds, ahh hehe
[11:16] <mandel> vds, you have to understand the irony of what we are doing ;)
[11:30] <lalejand> Hi, I have a problem : syncdaemon is using 95% of my CPU since 3 days
[11:31] <rodrigo_> nessita, fixed my branch, the tests got broken with the last merge from trunk, so please review again
[11:31] <vds> mandel: in the wiki is not clear when to use installer and when to use bootstrapper
[11:31] <mandel> lalejand, let me see if I can get some one to help you
[11:31] <mandel> vds, ok, I'll fix the wiki
[11:31] <mandel> vds, did you create the installer for the second branch
[11:31] <nessita> rodrigo_: sure!
[11:31] <vds> mandel: for example for the last branch I'd say I should use bootstrapper and test the whole installation...
[11:31] <vds> right?
[11:32] <mandel> vds, whcih branch?
[11:32] <lalejand> mandel, thanks
[11:32] <lalejand> everything is here : https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/608011?comments=all
[11:32] <mandel> rodrigo_, do you know who can help lalejand ?? rye is not here :(
[11:32] <ubot4> Launchpad bug 608011 in ubuntuone-client (Ubuntu) "errors in syncdaemon.log (affects: 1) (heat: 10)" [Undecided,Confirmed]
[11:32] <lalejand> but I have no news
[11:32] <vds> mandel: install_service_wix
[11:33] <rodrigo_> nessita, also this one -> https://code.edge.launchpad.net/~rodrigo-moya/ubuntuone-client/grey-hint-text/+merge/30745 please
[11:33] <mandel> vds, nop, just installer
[11:33] <rodrigo_> mandel, lalejand: looking...
[11:33] <mandel> vds, the bootstrapper creates a setup exe, but it installs the content of s3
[11:33] <mandel> vds, so you need to create the installer
[11:34] <vds> ah ok
[11:34] <rodrigo_> lalejand, verterok should know, I'll ping him (or do it yourself) when he wakes up, in 2/3 hours
[11:35] <mandel> vds, ideally we will automate our build server to post the new msi every time we have a new release
[11:35] <rodrigo_> lalejand, but just in case, your internet connection works ok, right?
[11:35] <lalejand> mandel, rodrigo_ : thanks guys, ok.
[11:35] <rodrigo_> I ask because of the Connection failed: DNS lookup failed: address 'fs-1.one.ubuntu.com' not found: [Errno -5] No address associated with hostname. line
[11:35] <lalejand> rodrigo_ : yes, I'm using the web interface to talk with you
[11:36] <rodrigo_> lalejand, ok
[11:37] <lalejand> rodrigo_ : and during the last 3 days (since the problem occurred) my internet connection has been ok
[11:44] <rodrigo_> hey alecu
[11:46] <alecu> hola rodrigo_! me desperte temprano para hablar con nessita, si es que anda por aca
[11:46] <nessita> alecu: acá estoy
[11:46] <nessita> oops
[11:46] <rodrigo_> alecu, si, anda por acá, o andaba hace un segundo :)
[11:46] <nessita> here I am
[11:46] <alecu> nessita, here you are!
[11:46] <nessita> english crowd!
[11:46] <rodrigo_> oh, yeah, English here :)
[11:47] <alecu> nessita, I need you to review the NM branch...
[11:47] <nessita> sure!
[11:47] <alecu> nessita, let me find the link...
[11:47] <alecu> https://launchpad.net/~alecu/ubuntu-sso-client/split-nm/+merge/30727
[11:48] <alecu> looks like somebody has already asked for comments
[11:51] <rodrigo_> alecu, yes, me :)
[11:51] <alecu> nessita, anyway: it would be best if you also reviews it, to see if I'm missing something.
[11:52] <alecu> rodrigo_, I see :-)
[11:52] <nessita> alecu: john added some comments, that's what you mean? :-)
[11:53] <alecu> nessita, no: rodrigo asked for more info
[11:53] <alecu> rodrigo_, regarding "Shouldn't this include the changes in auth.py to use the new networkstate object?"
[11:54] <alecu> rodrigo_, I believe nessita is refactoring the sso bits, so a very well tested Network State detection code is what she asked me to do.
[11:54] <rodrigo_> ah, ok
[11:54] <nessita> alecu: Chipaca asked for some fixes as well
[11:54] <nessita> so if you can add those it will be awesome :-)
[11:54] <alecu> nessita, yes, I'm fixing those
[11:54] <rodrigo_> alecu, then fix what Chipaca said, and I'll approve it, ok?
[11:54] <nessita> then I'll review
[11:55] <alecu> nessita, Chipaca just asked for a very small try/finally in a test binary, so go ahead and review
[11:56] <nessita> alecu: yeah, thing is I have 2 more ongoing reviews for rodrigo_ :-/
[11:56] <nessita> and lunch in 4 minutes
[11:56] <alecu> nessita, ok, don't review
[11:57] <nessita> alecu: I'll do it!
[11:57] <alecu> nessita, but at least take a look at the api
[11:57] <nessita> but after lunch, that's all I'm seeing
[11:57] <nessita> saying*
[11:57] <alecu> nessita, no prob
[11:57] <alecu> nessita, I need to get a bit more sleep as well :-)
[11:57] <nessita> rodrigo_: how can I test the first review on nautilus?
[11:57] <nessita> alecu: bien sur, go ahead
[11:57] <rodrigo_> which one is the 1st one? :)
[11:57] <nessita> I'll be here when you wake up (I think? )
[11:57] <nessita> rodrigo_: the share something?
[11:58] <nessita> "check-before-disabling"
[11:58] <alecu> nessita, also: please tell me if I can help you with another bit of sso
[11:58] <rodrigo_> nessita, can't test it, there's a bug on syncdaemon that doesn't share a folder on udf's
[11:58] <nessita> alecu: well yes, I'd need you to take chad's assignment
[11:58] <alecu> nessita, ok, cool.
[11:58] <nessita> alecu: he seems a bit blocked about that, I think that rodrigo_ can fill you in?
[11:58] <rodrigo_> nessita, so only way to test is to run the tests, to test the new API added to libsyncdaemon
[11:58] <nessita> rodrigo_: what about in nautilus? not yet?
[11:59] <alecu> ok, I'll ping them later.
[11:59] <rodrigo_> nessita, no, the code checks the path of the share to check it, and syncdaemon never sets it
[12:02] <nessita> ok then
[12:02] <nessita> I'll approve and then review the second one
[12:02] <nessita> I have lunch waiting for me!
[12:02] <nessita> rodrigo_: done, see ya in a bit
[12:02] <vds> mandel: the installer of tha last branch only installs ubuntu one client
[12:03] <vds> mandel: not gtk# tomboy etc etc...
[12:03] <mandel> vds, yes, because the msi does not do that, that is the bootstrapper
[12:03] <vds> mandel: ok
[12:03] <mandel> vds, we have an msi for tomboy, for gtk and ubuntuone
[12:03] <vds> so it works...
[12:03] <mandel> vds, and you need a bootstrapper to concatenate them
[12:04] <vds> tests are ok too
[12:04] <mandel> vds, cool
[12:04] <vds> mandel: approved
[12:05] <mandel> vds, thnx, I'll merge then :D
[12:06] <vds> mandel: you need one more review for that branch
[12:06] <mandel> vds, agg true, do you know who to ask?
[12:07] <vds> mandel: nope... let's see if anyone volunteers
[12:07] <mandel> vds, try muffinresearch he is the windows expert ;)
[12:08] <vds> rodrigo_ muffinresearch jdobrien: hoe about a review? :)
[12:08] <rodrigo_> vds, a review of what?
[12:09] <vds> rodrigo_: https://code.edge.launchpad.net/~mandel/ubuntuone-windows-installer/install_service_wix/+merge/30685
[12:10] <vds> rodrigo_: a read_only review is ok
[12:10] <mkarnicki> Hey guys. Any maintanance undergoing currently? Authentication takes way too long.
[12:10] <mkarnicki> aquarius: duanedesign: ^
[12:11] <aquarius> mkarnicki, not as far as I'm aware :(
[12:11] <rodrigo_> vds, ok
[12:11] <mkarnicki> aquarius: too bad :<. Client authenticate() takes over 2 minutes, and it still didn't fetch volume list (no exceptions/errors thrown yet)
[12:12] <aquarius> that's weirdly slow
[12:12] <aquarius> lucio_, is authentication to filesync being slow for everyone?
[12:12] <aquarius> (lucio won't be up yet, but hopefully he'll see this when he is)
[12:14] <mkarnicki__> sorry aquarius, having problems with remote session. I hope it's a temporary server load or something, not another Client problem
[12:15] <mkarnicki__> aquarius: it's interesting is that it's waiting for server responses, it didn't get any error or throw any exception
[12:20] <rodrigo_> vds, mandel: approved
[12:20] <mandel> rodrigo_, thx
[12:26] <jdobrien> mkarnicki that normally happens very quickly
[12:28] <jdobrien> aquarius, authentication is almost instant for me
[12:28] <jdobrien> aquarius, I wonder if we have a dns issue or something
[12:29] <mkarnicki__> jdobrien: normally it takes up to 3-4 seconds with ubuntuone-java-storageprotocol client
[12:29] <jdobrien> mkarnicki__, I am not familiar with that client
[12:29] <mkarnicki__> jdobrien: it took me 2 min 7 secs, and still didn't retrieve volume list (when I tried forcing that, it said it wasn't authenticated, as if it didn't finish)
[12:29] <jdobrien> I use a python one
[12:29] <mkarnicki__> jdobrien: I see.
[12:30] <jdobrien> mkarnicki we upgraded out protocol buffers
[12:30] <mkarnicki__> jdobrien: thanks anyway. it may be that client issue then.
[12:30] <mkarnicki__> jdobrien: when was that jdobrien ?
[12:30] <jdobrien> mkarnicki__, lemme check
[12:30] <mkarnicki__> jdobrien: auth worked perfectly up till 1 AM UTC today
[12:31] <mkarnicki__> jdobrien: so if it wasn't today, I have to ping verterok
[12:31] <jdobrien> mkarnicki__, nothing changed during that time
[12:31] <mkarnicki__> jdobrien: thanks. I'll get in touch with verterok then.
[12:31] <jdobrien> mkarnicki__, our last upgrade was tuesday
[12:31] <mkarnicki__> jdobrien: gotcha
[12:43] <vds> rodrigo_: thx!
[12:44] <duanedesign> morning all
[12:44] <jdobrien> hi duanedesign
[12:52] <facundobatista> mkarnicki__, you're implementing the client in java, right? or I'm totally confused?
[12:56] <lalejand> hi jdobrien, we talked here about my bug two days ago : https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/608011?comments=all can I do anything in order to help discover what's happening ?
[12:56] <mkarnicki> hi duanedesign :)
[12:56] <ubot4> Launchpad bug 608011 in ubuntuone-client (Ubuntu) "errors in syncdaemon.log (affects: 1) (heat: 10)" [Undecided,Confirmed]
[12:56] <aquarius> facundobatista, yep -- the Android client is java, and it uses verterok's java implementation of the storage protocol
[12:56] <mkarnicki> facundobatista: verterok wrote the java implementation of the protocol
[12:56] <mkarnicki> facundobatista: exactly what aquarius wrote ;)
[12:57] <jdobrien> lalejand, yeah I just replied to it :)
[12:57] <facundobatista> mkarnicki, nice!
[12:57] <lalejand> jdobrien, oh, ok
[12:57] <jdobrien> lalejand, can you do without syncing that Documents folder?
[12:57] <jdobrien> at least for now?
[12:58] <facundobatista> mkarnicki, I just wanted to mention that it's useful to have timeouts in everything related to network, so it starts reconnecting if something goes wrong
[12:58] <mkarnicki> facundobatista: thanks :) details here: https://launchpad.net/androidu1
[12:58] <mkarnicki> facundobatista: good point, I'll have them implemented soon :)
[12:58] <facundobatista> mkarnicki, I can point you to (and help you with) how the Python client States are designed
[12:59] <mkarnicki> facundobatista: that would be lovely!
[12:59] <facundobatista> mkarnicki, you can steal^H^H^Hreuse that
[12:59] <mkarnicki> facundobatista: I could mimic at least part of the behaviour
[12:59] <mkarnicki> ^_^
[12:59] <facundobatista> mkarnicki, do you have the Python client around?
[12:59] <mkarnicki> facundobatista: Android application lifecycle is pretty fscked, but we can try ! :)
[12:59] <mkarnicki> facundobatista: I should have, lemme see
[13:00] <mkarnicki> facundobatista: yes, ubuntuone-client-1.1.91
[13:00] <facundobatista> mkarnicki, I meant the sources
[13:00] <mkarnicki> facundobatista: exactly, I meant that too =)
[13:01] <mkarnicki> I have them ready to rumble
[13:01] <facundobatista> mkarnicki, nice, check in the Docs directory of the project
[13:01] <mkarnicki> facundobatista: yup
[13:01] <mkarnicki> facundobatista: awesome!!! :D
[13:02] <facundobatista> mkarnicki, states_manager.svg is the one
[13:02] <mkarnicki> facundobatista: I have been reading some of client sources, but I must admit - I'm stupid enough not to have seen those svg's before!
[13:02] <facundobatista> mkarnicki, that describes how States work
[13:03] <facundobatista> the name of the states and signals should be pretty descriptive
[13:03] <facundobatista> mkarnicki, you have the source, and me to ask, if you don't understand anything :)
[13:04] <mkarnicki> facundobatista: great, these might be really helpful, thank you facundobatista
[13:04] <facundobatista> mkarnicki, in any case... after we get connected and before we get into ServerRescan, all operations to the network have a timeout
[13:04] <facundobatista> if not, an event is raised, SYS_HANDSHAKE_TIMEOUT
[13:04] <mkarnicki> facundobatista: got it
[13:04] <facundobatista> ok
[13:04] <lalejand> jdobrien, "can you do without syncing that Documents folder?", you mean in order to make a test ? --> yes, or you mean forever ? --> hmmm, I would like to sync it some day :/
[13:05] <mkarnicki> facundobatista: =) great, thanks
[13:05] <facundobatista> mkarnicki, my pleasure
[13:05] <jdobrien> lalejand, I mean for now while it has those folders that it can't handle
[13:06] <mkarnicki> facundobatista: although mobile client will be more leightweight (in sense of little as possible CPU/battery consumption), we probably won't be doing server rescan. I'm caching what the user has explored for now. we may introduce server rescan though, at some point in time.
[13:06] <lalejand> jdobrien, yes
[13:07] <lalejand> jdobrien : I try to delete a folder as you told in launchpad, but I think it will do it once it finishes local_rescan which means in 10 hours. Is there a way to stop it ?
[13:09] <jdobrien> hmm
[13:09] <jdobrien> lalejand, im afraid verterok is going to have to answer that one
[13:09] <lalejand> jdobrien, ok
[13:51] <Chipaca> Ubuntu One Desktop+ kanban walkthrough starting in 10 minutes
[13:52] <mkarnicki> Chipaca: may I ask what kanban is :)?
[13:52] <jblount> mkarnicki: http://en.wikipedia.org/wiki/Kanban
[13:53] <jblount> mkarnicki: Although in this case, Chipaca is talking about walking through our kanban board that lists tasks on it. It's a web app using http://leankitkanban.com
[13:53] <mkarnicki> jblount: oh, thanks.. I googled that but thought it didn't mean that ;)
[13:53] <mkarnicki> jblount: ah! so I was somewhat right :D thanks jblount
[13:53] <jblount> mkarnicki: :)
[13:54] <mkarnicki> jblount: neat :)
[13:55] <Chipaca> mkarnicki: it's a lean/agile way of organizing a team's work with very low overhead and very good visibility both to the developers themselves and the other stakeholders
[13:56] <mkarnicki> Chipaca: uhum! just read that on that eye-canty slideshow on their website =) thanks! I'm glad you're using nice tools to support workflow.
[13:56] <Chipaca> mkarnicki: :) it's not quite as good as a real-life physical kanban board, but probably as close as it gets
[13:56] <mkarnicki> Chipaca: aha! ^_^
[15:11] <lalejand> hi verterok, I have a problem with U1 (https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/608011?comments=all), syncdeamon is using 96% of my CPU, jdobrien told me to delete the folders (u1sdtool --delete-folder). But nothing happens, as it is doing a local_rescan I suppose that it will delete the folder after rescaning, which means in more than 10h. Is there a way to stop rescaning ?
[15:11] <ubot4> Launchpad bug 608011 in ubuntuone-client (Ubuntu) "errors in syncdaemon.log (affects: 1) (heat: 10)" [Undecided,Confirmed]
[15:27] <jdobrien> lalejand, sorry, I don't think verterok is going to be available much today
[15:28] <lalejand> jdobrien, ok
[15:28] <jdobrien> lalejand, is there anyway you can move the offending folder out of Documents?
[15:28] <jdobrien> lalejand, if you stop the client, move the folder, then restart it, your local rescan will speed up a lot
[15:28] <jdobrien> lalejand, its very slow the first time it has to scan that many files
[15:29] <lalejand> jdobrien, I don't know if there is an offending folder in Documents, and which one it would be
[15:29] <lalejand> jdobrien, how do I stop rescaning ?
[15:29] <jdobrien> lalejand, u1sdtool -q
[15:30] <jdobrien> lalejand, you have a folder with directories and files that have unicode issues that break pynotifiy
[15:30] <lalejand> jdobrien, ok I'll try & try to see where the client is making problem
[15:30] <lalejand> jdobrien, and how do I launch it again ?
[15:31] <jdobrien> lalejand, u1sdtool -c
[15:32] <lalejand> jdobrien, I tried 3 times u1sdtool -q, and it says : ubuntuone-syncdaemon still running.
[15:32] <lalejand> Ah, now it stopped
[15:32] <jdobrien> lalejand, :)
[15:38] <lalejand> jdobrien, is it long to delete a synced folder ?
[15:38] <verterok> lalejand: hi, there is no way to stop the rescan :(
[15:38] <jdobrien> verterok, not even u1sdtool -q?
[15:39] <lalejand> verterok, jdobrien, ARGH !
[15:39] <verterok> jdobrien: yes, but you can't "skip" a local rescan
[15:40] <jdobrien> verterok, the idea is, stop the rescan, move the directory with the Unicode errors, and restart it
[15:41] <verterok> jdobrien: and that should work :)
[15:41] <lalejand> verterok, jdobrien : ok, so I have to u1sdtool -q, then u1sdtool -c, then u1sdtool --deleteMyFolder, and just let it do its stuff for those 10h ?
[15:41] <jdobrien> lalejand, after -q, move the folder
[15:41] <lalejand> verterok, jdobrien : the file with the unicode error has already been removed
[15:41] <verterok> yes, what jdobrien said :)
[15:41] <jdobrien> lalejand, you have directories with problems, not just one file :(
[15:42] <jdobrien> lalejand, did you get that directory from a windows machine?
[15:42] <lalejand> verterok, jdobrien : but I don't know which directory has an error
[15:42] <jdobrien> lalejand, start with the root folder of that web site content
[15:42] <lalejand> jdobrien : from windows, it's possible
[15:44] <lalejand> jdobrien : which website content are you talking about ? where do you see errors ?
[15:45] <lalejand> jdobrien : in Documents, I have several website contents
[15:46] <lalejand> verterok, jdobrien : anyway, I'm going to move every single thing in Documents, maybe I will find where is the problem
[15:47] <jdobrien> lalejand, sorry for all this trouble, it's a very strange error
[15:49] <lalejand> jdobrien : I'll try to find out the problem and tell you
[15:50] <lalejand> jdobrien : If I manage to stop syncdaemon ;)
[15:51] <rodrigo_> alecu, CardinalFang: 3 branches for review please -> https://code.edge.launchpad.net/~rodrigo-moya/ubuntuone-client/grey-hint-text , https://code.edge.launchpad.net/~rodrigo-moya/ubuntuone-client/check-before-disabling and https://code.edge.launchpad.net/~rodrigo-moya/ubuntuone-client/dont-connect-when-ready
[15:52] <lalejand> jdobrien : can't stop it ! Should I kill the process ?
[15:53] <alecu> rodrigo_, ok, my pleasure :-)
[15:54] <rodrigo_> alecu, :)
[16:09] <rodrigo_> alecu, CardinalFang: so is alecu then going to take over the dbus thing for ubuntu-sso then?
[16:10] <CardinalFang> rodrigo_, alecu, okay.
[16:11] <rodrigo_> CardinalFang, you mentioned you had a branch without tests, so can you push it so that alecu works from there?
[16:11] <CardinalFang> Sure.
[16:11] <rodrigo_> alecu, ^^
[16:12] <alecu> CardinalFang, would you like to tell me a bit about it? The only thing I know is nessita telling me I should help with that, since you had to work on something else :-)
[16:13] <lalejand> jdobrien : can't stop it. Should I kill the process ?
[16:14] <jdobrien> verterok, ^^
[16:15] <verterok> lalejand: yes
[16:15] <lalejand> ok
[16:15] <CardinalFang> alecu, currently there's a Login class, when we really need some SSO-Login.  We need both for right now, but Login should be deprecated soon.
[16:17]  * vds is away: Ci vediamo...
[16:30] <lalejand> verterok, jdobrien : I moved almost everything out of Documents, launched syncdaemon, as usual it uses 95% CPU, and I can't ask him to do anything : http://pastebin.com/9H89kEJm
[16:30] <lalejand> verterok, jdobrien : I suppose I will have to wait my 10h right ?
[16:31] <verterok> lalejand: it's probably loading the metadata
[16:31] <verterok> lalejand: not 10h
[16:31] <jdobrien> verterok, I think it will have to load the metadata then clean it up based on the deleted files right?
[16:32] <verterok> jdobrien: yes, it will cleanup the metadata during local rescan
[16:32] <verterok> that should be a lot faster without all those files
[16:32] <lalejand> verterok : in tail ~/.cache/ubuntuone/log/syncdaemon.log I see things like http://pastebin.com/Tfh9bHvS
[16:34] <verterok> lalejand: u1sdtool -s works now?
[16:34] <lalejand> verterok : no. Still trying
[16:41] <CardinalFang> alecu, I hope this is useful:  lp:~cmiller/ubuntu-sso-client/replace-login-with-ssologin
[16:41] <alecu> CardinalFang, great, thx
[18:53] <Franxesk> hi everyone, i was wondering in which project should i report a bug about the web ui?
[18:54] <statik> hi there Franxesk, you can report it on https://launchpad.net/ubuntuone-servers
[18:54] <statik> thanks for the bug report
[18:57] <Franxesk> statik: thanks! :)
[19:00] <duanedesign> hello Franxesk
[19:02] <duanedesign> oop, i see statik got your question answered. :)
[19:02] <jblount> duanedesign: statik is very quick, you've got to watch out for him.
[19:03] <duanedesign> even stealthier on my computer. His nick is almost the same color as my terminal background color
[19:06] <mandel> guys, have a good weekend, my brain aint working any more :P
[19:16] <dobey> spaniards... :P
[19:19] <Franxesk> is there already a bug about making searches through the u1's web ui?
[19:20] <dobey> you mean for searching your own files?
[19:20] <Franxesk> yes
[19:21] <dobey> i think there might be
[19:22] <Franxesk> ok, thanks :)
[19:23] <Franxesk> btw, sorry for my bad english :$
[19:24] <Franxesk> i was trying to find a specific file in "My Storage" and i couldn't find a way to do it through the web ui
[19:26] <dobey> yeah we don't have file content searching yet, because it's a touch and very difficult subject to get right. not sure how hard it would be to search for filenames, though
[19:28] <Franxesk> ok
[19:32] <dobey> we've been working on somewhat more important things for now, like performance. :)
[19:36] <Franxesk> performance come first, there is no doubt about that :)
[19:40] <Franxesk> i haven't got a lot of files in my u1's account so, i could try to find the file manually, it's not a big deal anyway.
[19:53] <Fosfat> Does sombody know in what country Ubuntuone is hosted?
[19:54] <BlackZ> Fosfat: it's hosted by canonical
[19:55] <duanedesign> Fosfat: Canonical is registered in The Isle Of Man
[19:56] <Fosfat> Ok... I was wandering because where I live there is unlimited domestic download but I must pay for download from overseas
[19:57] <duanedesign> its main offices in London, support office in Montreal and OEM team in Lexington, Massachusetts, USA and Taipei, Taiwan
[19:57] <Fosfat> Thanks
[19:57] <statik> the main ubuntu one servers for downloading data are in the seattle EC2 region
[19:57] <duanedesign> Fosfat: the servers for the repositories are all over
[19:57] <duanedesign> ohhh
[19:57] <statik> but the webservers are in london
[19:58] <Fosfat> so there may even be a  server in Iceland?
[19:58] <duanedesign> I am sorry I did not see Ubuntu One in your question :P
[19:58] <duanedesign> Fosfat: sorry I thought you were asking about Ubuntu ingeneral
[20:00] <duanedesign> Fosfat: statik  has the accurate information on Ubuntu One servers
[20:00] <Fosfat> well... for me its more expensive to buy 50 GB bandwith quota from my ISP than Ubuntu charges for the 50 GB sceeme...
[20:01] <Fosfat> I was just wandering what the total cost would be for me
[20:01] <Fosfat> thanks
[20:01] <duanedesign> np
[20:53] <leonel> no plans yet for ubuntuone to work without graphical interfase .. like  a remote server ?
[20:54] <duanedesign> hello leonel
[20:54] <karni> verterok: (mkarnicki here) I lost connection to my IRC session few hours ago. Did you reply to my msg about authentication http://paste.ubuntu.com/468051/ ? line 25 never executes
[20:55] <karni> verterok: and I don't know if this webchat has priv chat capability ;D
[20:55]  * karni uses freenode webchat for time being
[21:06] <verterok> karni: hi, no I wasn't able to take a look to the code
[21:30] <duanedesign> these bugs where U1 is syncing Dropbox folders are puzzling. I installed Dropbox and have not been able to reproduce it.
[21:49] <duanedesign> When putting a UDF in your trash(locally) it unsubscribes the folder instead of deleting it. Is this the expected behavior?
[22:06] <mkarnicki> verterok: now I lost the link to the paste. in authenticateClient() it never reaches callback after Client.authenticate(...).getDeferred() runs (if it runs at all..)


[06:16] <duflu> Morning seb128
[06:39] <didrocks> good morning
[06:40] <duflu> Hi didrocks
[06:43] <didrocks> hey duflu
[06:45] <seb128> hey duflu didrocks (and bbiab, dropping kid for the day)
[06:45] <jibel> Good morning
[06:46] <didrocks> salut jibel
[06:49] <duflu> Morning jibel
[06:55] <jibel> duflu, about bug 1775743, ubuntu is the only OS on the machine ?
[06:55] <duflu> jibel, yes I've tried 3 different laptops. All completely wiped each time
[06:56] <jibel> could you attach the logs from /var/log/installer?
[06:56] <duflu> jibel, next time :)
[06:56] <duflu> It's a very time consuming bug
[06:56] <jibel> I know :)
[06:57] <duflu> jibel, if you have older images handy I can probably bisect it down to an exact image by tomorrow
[06:59] <sil2100> duflu: hey! As mentioned on the bug, last week we did release a new grub2 package which potentially might have regressed something
[06:59] <sil2100> Since there were some architectural changes there
[06:59] <sil2100> duflu: but what worries me is that I cannot reproduce it on a VM
[06:59] <sil2100> jibel: when you tested this on a VM, did you install -desktop as well?
[07:00] <duflu> That doesn't worry me. I wouldn't be able to do most of my job if I was confined to VMs. So many hardware issues
[07:00] <sil2100> It worries me since I don't have an easy way to reproduce it, and the fact that it works on my VM makes it even harder to explain
[07:01] <sil2100> Since the changes we did should either work for a setup or not
[07:01] <jibel> sil2100, I've no problem with cosmic on VMs
[07:01] <jibel> and yes I tried desktop, it's the only image I use
[07:04] <sil2100> hm, I suppose it might be a bit difficult to create a one-off image with all the grub2 bits reverted, especially since there's the signed bits
[07:07] <sil2100> Since most of the logic changes were in shim-signed and grub2-signed
[07:07] <jibel> duflu, is secure boot enabled?
[07:08] <jibel> sil2100, which version of grub introduced these changes?
[07:08] <duflu> jibel, usually no. Because these machines I only use for Ubuntu. But sometimes yet
[07:08] <duflu> yes
[07:11] <seb128> hey again desktopers :)
[07:11] <jibel> hey again seb128
[07:11] <seb128> lut jibel, how are you?
[07:12] <jibel> seb128, I'm fine, thanks.
[07:12] <jibel> and you?
[07:12] <seb128> I'm good thanks
[07:12] <sil2100> jibel: grub2-signed 1.96 and shim-signed 1.36
[07:13] <jibel> sil2100, 1.96 only affects efi systems?
[07:14] <sil2100> Potentially these changes should only affect UEFI installations, yes
[07:16] <jibel> okay, let me try in a vm with uefi then
[07:21] <sil2100> I only tried server on both BIOS and UEFI on a VM and they worked, so maybe you'll have more luck with desktop
[07:22] <sil2100> hmmm
[07:26] <jibel> sil2100, I confirm it's reproducible in a uefi vm
[07:26] <sil2100> Might not be grub indeed as per what duflu mentioned, looks like it got broken a bit earlier
[07:26] <jibel> sil2100, with latest cosmic desktop image
[07:26] <sil2100> jibel: thanks
[07:26] <sil2100> Strange I didn't have the issues with the subiquity server image, but maybe I need to re-test
[07:27]  * sil2100 will do that now
[07:27] <jibel> sil2100, for you or foundations?
[07:28] <jibel> sil2100, subiquity uses a different method of installation afaik
[07:28] <sil2100> jibel: yeah, I'll try both subiquity and regular debian-installer based server now, maybe it's not related to grub but something touching the installer?
[07:29] <sil2100> I would really not want my first ever grub2 landing to cause big issues as such
[07:29] <sil2100> ;)
[07:30] <jibel> sil2100, I bet you can reproduce with d-i
[07:37]  * didrocks realizes we didn't talk about git at the team meeting and documentation
[07:37] <didrocks> I'll handle it I guess, finding one exemple like gnome-session, and writing docs on it, like how to update, how to apply a patch, udpate a patch…
[07:38] <didrocks> basing on debian's doc and how to convert for us in launchpad
[07:38] <seb128> didrocks, right, I remembered after the meeting yesterday, we were already busy discussing some other aob with the theme and the gnome-shell update
[07:38] <seb128> thanks didrocks!
[07:38] <didrocks> yw seb128 ;)
[07:39] <seb128> Laney, ^ if you want to help him a bit
[07:42] <Nafallo> morning
[07:43] <didrocks> hey Nafallo
[07:51] <seb128> duflu, just as a fyi I'm still dealing with post-holidays catching up and performance reviews&co and don't have anything for the bluetooth meeting so I'm going to skip that one
[07:51] <didrocks> I have a question on bluetooth! but unrelated to your meeting :)
[07:51] <seb128> haha
[07:51] <seb128> ask!
[07:51] <duflu> seb128, yes I was about to say that. I have been away 4 days, and koza is an "unknown" on the invite
[07:51] <seb128> duflu, let's skip
[07:51] <didrocks> is there a way to create a rule or so so that you rfcomm bind automatically when a particular device is connected?
[07:52] <didrocks> like, avoiding "sudo rfcomm bind …"
[07:52] <didrocks> which requires root
[07:52] <duflu> seb128, on that note though I do have bluez 5.50 awaiting sponsorship some time
[07:52] <didrocks> (and then, there is the bug duflu triaged that /dev/rfcomm* doesn't have correct permissions)
[07:53] <duflu> didrocks, I don't know that command myself. What bug do you mean?
[07:54] <didrocks> duflu: bug #1014992
[07:54] <ubot5`> bug 1014992 in bluez (Ubuntu) "Cannot use rfcomm as regular user. Permission denied." [Medium,Confirmed] https://launchpad.net/bugs/1014992
[07:54] <didrocks> and I would like to avoid "sudo" in rfcomm connect 1 <addrr>
[07:55] <didrocks> their fix is to disable modemmanager, but doesn't cover the create a /dev/rfcomm part as non root
[07:57] <duflu> jibel, it sounds like we are skipping the meeting
[07:58] <duflu> Morning willcooke. We ere about to skip the meeting unless you want it?
[07:58] <duflu> +w
[07:58] <willcooke> morning, +1
[07:58]  * willcooke isnt really with it yet anyway
[07:59] <seb128> hey willcooke, how are you?
[07:59] <seb128> able to speak today? ;)
[07:59] <willcooke> :)
[07:59] <willcooke> Bit better today, still a bit achey, but fine
[08:00] <didrocks> hey willcooke
[08:00] <willcooke> but I slept funny and now my neck /.shoulder is playing uop
[08:00] <willcooke> up
[08:00] <willcooke> it's an old injury and flares up every now and then
[08:00] <willcooke> Don't get old kids, it sucks
[08:02] <Laney> hi
[08:02] <willcooke> morning Laney
[08:02] <seb128> hey Laney, how are you?
[08:02] <Laney> hi willcooke seb128
[08:03] <didrocks> hey Laney
[08:03] <Laney> alright thanks, been potting some new houseplants
[08:03] <Laney> hey didrocks
[08:03] <Laney> what's up homies?
[08:03] <didrocks> nothing special, yourself?
[08:05] <Laney> not a lot!
[08:06] <sil2100> jibel: as expected, I was able to install and boot with subiquity on UEFI no problem - but of course I could reproduce it with the d-i installer for server
[08:06] <sil2100> jibel: so yeah
[08:06] <sil2100> At least I know what was wrong with my testing
[08:20] <duflu> didrocks, I can't add any expertise to that bug other than if it needs progressing then upstream reports go in https://bugzilla.kernel.org/enter_bug.cgi?product=Drivers&component=Bluetooth
[08:20] <didrocks> duflu: ok, thanks for looking!
[08:20] <didrocks> weird that we can't pair RFCOMM bluetooth device via g-c-c
[08:22] <Laney> didrocks: https://wiki.ubuntu.com/DesktopTeam/git I just added some basic thing about converting a repo for the first time
[08:23] <Nafallo> morning willcooke :-)
[08:23] <willcooke> o/
[08:23] <Nafallo> morning Laney
[08:23] <Laney> hey Nafallo
[08:23] <seb128> duflu, oh, I just saw your mention of bluez waiting for sponsoring, I can have a look to that today
[08:23] <didrocks> ok, I'll edit those as needed
[08:24] <jibel> sil2100, good, I'll let this bug with you then since you broke the image ;)
[08:24] <seb128> didrocks, talk to Bastien? :p
[08:24] <duflu> seb128, yeah it was in the status report I didn't send due to leave yesterday. No hurry so I didn't push the point
[08:24] <didrocks> seb128: yeah ;)
[08:24]  * jibel notes the testing gap and to add uefi to automated installer tests
[08:25] <duflu> didrocks, and no bluez is not a kernel component. It only shares the kernel tracker
[08:25] <sil2100> jibel: I did not! As per duflu's comment it was broken before my upload! ;p
[08:25]  * duflu shrugs
[08:25]  * duflu shrugs at didrocks at least
[08:25] <didrocks> argh :p
[08:27] <duflu> sil2100, over the coarse of my long weekend that actually wasn't the most annoying installation bug I found. There is also bug 1776578 :)
[08:27] <ubot5`> bug 1776578 in linux (Ubuntu) "Ubuntu installation stuck at "Installing the 'grub2' package..." every time. Kernel crash every time." [High,Incomplete] https://launchpad.net/bugs/1776578
[08:27] <duflu> -coarse +course
[08:34] <seb128> k, changing location, bbiab
[09:08] <willcooke> didrocks, hey!  I just noticed that on my x270 I can enabled over-amplification, but the slider doesnt allow me to go > 100%.  If I plug headphones in, then I can.  Is that expected?
[09:09] <willcooke> Likely something funny in the drivers here, since dock audio is a bit funny anyway
[09:15] <didrocks> willcooke: it's only if the output allows to have over amplifications, some don't
[09:16] <willcooke> didrocks, so would you expect it to be greyed out if not supported (the on/off button that is)  - or -  it would be there, but do nothing?
[09:16] <didrocks> willcooke: the thing is that the option is global
[09:16] <didrocks> so, if you have multiple output devices, it will impact them all
[09:16] <willcooke> got it, thanks didrocks
[09:16] <didrocks> in the proposed set of patches, I tried to ahve it per device
[09:17] <didrocks> that was nacked by upstream
[09:17] <didrocks> (it complexifies the logic a lot ofc, you ahve to track devices…)
[09:17] <willcooke> kk, nw
[09:17] <didrocks> yeah, not the best UI :/
[09:44] <didrocks> Laney: is there any reason why we push upstream/latest to launchpad? Do you know if this is used to rebuild the tarball which is in pristine-tar or should we just keep it locally?
[09:45] <Laney> well the upstream tags are made with reference to commits on this branch
[09:45] <Laney> so the next person to do work needs to be working from the same place
[09:47] <didrocks> ah right, for further cherry-picking
[09:47] <didrocks> so, it's more to get everything in one place
[09:47] <Laney> it'll go onto the upstream branch, merge the git tag and then the delta from the tarball, and make an upstream/x.y.z tag out of that
[09:48] <Laney> so you need it around to make that work
[09:48] <didrocks> yeah, that's what I meant by "help reconstructing the tarball"
[09:48] <Laney> righto
[09:49] <Laney> but I think that it probably actually uses the tags for that
[09:49] <Laney> not that I've looked :-)
[09:49] <didrocks> yeah
[09:49] <didrocks> ok, sounds good
[09:53] <didrocks> we should try to pull and push from different locations automatically for that branches
[09:54]  * didrocks looks if we can set that in config
[09:54] <Laney> you can do that somehow
[09:54] <Laney> so that git push <branchname> works
[09:54] <didrocks> yeah, I saw a global config
[09:54] <didrocks> trying to find a local one or one we can add to the repository
[10:05] <didrocks> ahah! branch.<name>.pushRemote sounds promising
[10:06] <Laney> it's local config though I think
[10:06] <didrocks> I think it's in .git
[10:06] <didrocks> let me try
[10:06] <Laney> I'm sort of OK with that - if you `git push -u' then it'll set it up for you
[10:06] <didrocks> as long as we don't have to manually git push for upstream/latest, I'm fine
[10:07] <didrocks> or we will never have it updated
[10:07] <Laney> why not?
[10:07] <didrocks> because people will pull from matest to update upstream/latest
[10:07] <didrocks> and will never think about updating the launchpad upstream/latest branch
[10:07] <Laney> git push lp ubuntu/master upstream/latest pristine-tar ubuntu/<tag> upstream/<tag>
[10:07] <Laney> that's my muscle memory
[10:08] <didrocks> maybe yours, I doubt everyone will :) git push should just DTR I think
[10:08] <seb128> +1
[10:08] <seb128> those syntaxs are chinese to me at least :p
[10:08] <Laney> ffs
[10:09] <seb128> well if there is no other way and that people have to learn long/complex commands that's the way it is
[10:09] <seb128> but if we can do simple things to just work that's better
[10:09] <seb128> imho
[10:10] <Laney> please
[10:10] <Laney> PLEASE
[10:10] <Laney> move away from asserting this is some insanely complex system
[10:10] <Laney> didrocks: look into push.default in git-config
[10:10] <Laney> probably you want "matching"?
[10:10] <didrocks> Laney: nope, doesn't work as it's different remote
[10:10] <didrocks> not different branch
[10:10] <didrocks> but pushremote works
[10:11] <Laney> how does that make a no argument "git push" work?
[10:11] <seb128> Laney, I'm not saying that, just that a 2 arguments command is easier to remember than a 8 arguments one
[10:11] <didrocks> git push origin -> push every tracking branch to origin repo
[10:11] <didrocks> so, you end up with:
[10:11] <didrocks> [branch "upstream/latest"]
[10:11] <didrocks>         remote = upstream
[10:11] <didrocks>         merge = refs/heads/master
[10:11] <didrocks>         pushremote = origin
[10:12] <didrocks> for instance
[10:12] <Laney> ok, not no argument, I thought that's what you wanted
[10:12] <didrocks> well, you have to define the origin you push to
[10:13] <didrocks> but at least, we'll have the upstream/latest and pristine-tar branches push with your changes
[10:13] <didrocks> without being out of sync and so on
[10:13] <Laney> When the command line does not specify where to push with the <repository> argument, branch.*.remote
[10:13] <didrocks> (and as it's a local config, people can opt-in or not)
[10:13] <Laney>        configuration for the current branch is consulted to determine where to push. If the configuration is
[10:13] <Laney>        missing, it defaults to origin.
[10:13] <Laney> maybe this works already
[10:14] <didrocks> it does
[10:14] <didrocks> just tried :)
[10:14] <didrocks> so, maybe we should add that as well
[10:14] <didrocks> let's see, anyway, I think people will try/review and we'll iterate on the workflow
[10:14] <Laney> k
[10:17] <didrocks> however:
[10:17] <didrocks> $ git branch -vv
[10:17] <didrocks> * upstream/latest 0bd90ca34 [upstream/master] region: Show scrollbars if needed
[10:17] <didrocks> doesn't show the push remote, can be a first patch to git! :p
[10:20] <Laney> :>
[10:21] <Laney> what is "git push" pushing with your configuration if there are changes on multiple branches?
[10:21] <Laney> all of them or just the current one?
[10:22] <didrocks> all of them
[10:22] <Laney> Trevinho: I just uploaded your gdm, do you want to handle the merge? (for practice)
[10:22] <didrocks> well, all of them which is tracking the default remote
[10:23] <Trevinho> Laney: yeah, ok
[10:23] <Trevinho> Thanks
[10:23] <Trevinho> Laney: have you seen the nux thing too?
[10:23] <didrocks> I'll try with additional new untracked branches and so on to confirm
[10:25] <seb128> good morning Trevinho!
[10:26] <Laney> Trevinho: the bug?
[10:27] <Trevinho> seb128: hi
[10:27] <didrocks> yes, it doesn't add any untracked branch
[10:27] <Trevinho> Laney: https://bugs.launchpad.net/ubuntu/+source/nux/+bug/1768610
[10:27] <ubot5`> Ubuntu bug 1768610 in nux (Ubuntu) "leftover conffile forces GNOME is software rendering" [High,In progress]
[10:28] <Laney> Trevinho: yeah, that, is Andrea going to review or?
[10:28] <Trevinho> Laney: I've also prepared sru branches and bileto tickets, but I will update them
[10:29] <Trevinho> Laney: well, since it's 99% debian change I would go with you
[10:30] <Trevinho> I wanted to ask him yesterday, but I thought it was more for you
[10:30] <Laney> /o\
[10:30] <Laney> you always add some random extra thing in :P
[10:32] <Trevinho> Laney: of course... I don't like partial solutions
[10:33] <Laney> like renaming the conffile
[10:33] <Trevinho> Laney: removing and the renaming it
[10:34] <Trevinho> That's optional of course, but since it's not a conf file there's no point of treating it like that
[10:34] <Laney> right, is that correct?
[10:34] <Laney> why not a mv_conffile?
[10:34] <Laney> oh a symlink?
[10:34] <Laney> wtf
[10:34] <Laney> I don't think you can hack the policy in that way really
[10:34] <Trevinho> Laney: that's that guidelines say... Not me
[10:37] <Laney> my laptop just froze long enough to type 1198 "i"s
[10:38] <Trevinho> Mh, I get freezes too, but I wasn't able to get anything from gdb
[10:39] <Laney> and there's loads of Jun 13 11:35:21 nightingale org.gnome.Shell.desktop[3732]: Key repeat discarded, Wayland compositor doesn't seem to be processing events fast enough!
[10:40] <Laney> Trevinho: ok, where's this policy reference? :-)
[10:41] <Laney> 10.7.2
[10:41] <Trevinho> Debian maintainer guide 5.3
[10:41] <Trevinho> I mentioned in the commit msg I thought, no?
[10:42] <Laney> dunno, I'm looking at the diff
[10:43] <Laney> If the program you're packaging requires every user to modify the configuration files in the /etc directory
[10:43] <Laney> hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
[10:55] <Laney> ok that time it crashed completelyy
[10:56] <Laney> Jun 13 11:51:18 nightingale org.gnome.Shell.desktop[3732]: Key repeat discarded, Wayland compositor doesn't seem to be processing events fast enough!
[10:56] <Laney> Jun 13 11:51:18 nightingale org.gnome.Shell.desktop[3732]: (EE)
[10:56] <Laney> Jun 13 11:51:18 nightingale org.gnome.Shell.desktop[3732]: Fatal server error:
[10:56] <Laney> Jun 13 11:51:18 nightingale org.gnome.Shell.desktop[3732]: (EE) Error sending request: Resource temporarily unavailable
[10:56] <Laney> Jun 13 11:51:18 nightingale org.gnome.Shell.desktop[3732]: (EE)
[11:09] <Trevinho> Laney: well it talks about editing that, but that's the way to make sure that an /etc file is not a conffile, as in this case should not be at all
[11:11] <Laney> why not?
[11:12] <Laney> I mean I don't see why this one is different to any of the others in there
[11:12] <Trevinho> Laney: in fact I think they're all wrong
[11:12] <Trevinho> Laney: it's a distro-provided file not to be broken or changed by the user
[11:13] <Laney> this isn't really a policy to fix randomly in one SRU
[11:13] <Trevinho> those are scripts which are sourced, and while in some cases they might change settings, in this specific case it's not
[11:15] <Trevinho> Laney: not "randomly", anyway if you prefer I can not SRU that bit, but it's a matter of principle to me
[11:15] <Trevinho> for not being a conffile
[11:16] <Laney> well fine, but I think you should take this up with the X maintainers then
[11:17] <Trevinho> mh, well, I see the point for having Xsession.d in etc, and both for historic reason this can't be changed, but... Also because it could be used for user configurations, so it's fine to be in /etc to me, what's is wrong is the distro to threating it wrongly
[11:20] <Laney> maybe you want to ask for a way to put files in /usr
[11:20] <Trevinho> nope, since otherwise the order is compromised
[11:21] <Trevinho> I mean, that's an option too.. but
[11:22] <Laney> not necessarily, the order could be sorted by filename for example
[11:22] <Laney> anyway this is not a debate for me to have
[11:23] <Laney> sorry :(
[11:24] <Trevinho> I know it's nothing crucial, but I don't like the status quo and this is a clean way to fix it imho
[11:24] <Trevinho> considering we can't really change the wold, but we can change a package
[11:24] <Trevinho> world* (x11)
[11:25] <Laney> It's a hack, it's against policy and it's changing just one package when the alleged issue applies to more
[11:25] <Laney> soryr Marco
[11:25] <Laney> If you want to try to get someone else to approve it instead of me, you can feel free
[11:27] <Trevinho> Laney: it's not against the policy... it is based on the policy. An hack is what they propose too (as no other tools are provided to do things in a cleaner way). And while they mention a different scenario is, it has to be interpreted and can totally applied to this scope.
[11:28] <Laney> I don't really want to argue about this any more
[11:28] <Trevinho> but as I said, doing a bzr uncommit won't be a problem, but I wanted to point out this to underline where the issue is, and that we can have it fixed also don't worry about this later (if might happen)
[11:32] <Trevinho> hey :), it's just talking eh,  but while I was aware and pretty expecting you didn't like :-D, I wanted to propose it anyway for some discussion, in a productive way. As to me this would be the way to go for all those files, and just starting from one (that is coincidentally  causing troubles)
[11:37]  * Laney thinks that was supposed to be a PM :P
[11:37]  * Laney hugs Trevinho
[11:38] <Trevinho> Laney: ahah, no, just to underline there's no drama :-D
[11:38] <Trevinho> or maybe to make it for the interested audience
[11:38] <Laney> ohohoh
[11:39] <Trevinho> we could actually start fighting for "real", as any reality tv show, just in order to get people watching it :-D
[11:40] <Laney> jelly wrestling at the sun sprint
[11:40] <Laney> that's already on my list
[11:47] <Trevinho> ahaha
[11:47] <Trevinho> Laney: in the mean time I've updated https://code.launchpad.net/~3v1n0/ubuntu/+source/gdm3/+git/gdm3/+merge/347812
[11:48] <Laney> 😘
[11:50] <Laney> looks nice, thanks, /me test builds
[11:50] <Trevinho> don't spoil me now, eh... i still believe that my crusade against the conffile was right :-D
[11:50]  * Trevinho that's for the audience
[11:51] <Laney> :( trolled
[11:55]  * Nafallo muches popcorn
[12:23] <Trevinho> Laney: I also reverted the nux commit...
[12:24] <Trevinho> the SRU test case would be complicated though...
[12:24] <Trevinho> I don't know how people can test this upgrade at all
[12:24] <Trevinho> removing the file was quite easier to check :)
[12:43] <seb128> Trevinho, the SRU test case is easy
[12:43] <seb128> - install xenial
[12:43] <seb128> - upgrade to bionic
[12:43] <seb128> - sudo apt-get remove nux-tools
[12:43] <seb128> - log into your session
[12:43] <seb128> - check glxinfo (or other equivalent)
[12:44] <Trevinho> seb128: eh, no... that's too generic
[12:44] <seb128> ?
[12:44] <seb128> that's how the people who reported the bug got the issue
[12:44] <Trevinho> ah, wait... ok.
[12:44] <seb128> and a valid wait to test it
[12:44] <seb128> the test case doesn't need to be the most minimalistic way to test
[12:44] <seb128> just one way to confirm the problem is fixed
[12:44] <Trevinho> yeah, that's fine... I was thinking to the case of unity+gnome installed
[12:44] <Trevinho> but, that's just a consequence of the fix
[12:45] <seb128> ?
[12:45] <seb128> the bug report is "GNOME session uses software rendering"
[12:45] <seb128> the fix purpose is to make sure that doesn't happen when not necessary
[12:45] <Trevinho> yes. That could happen also in the case that unity has not been removed, but that tool fails
[12:45] <Trevinho> for any reason, thus leading to the same situation
[12:46] <seb128> right
[12:46] <seb128> well you can add another testcase if you wish
[12:46] <seb128> like rm the binary :p
[12:46] <Trevinho> so, I've also covered that case
[12:46] <seb128> or edit it in vim to corrupt it
[12:46] <seb128> or whatever
[12:46] <seb128> but that's not needed by the SRU process
[12:46] <seb128> what I described is good enough for the SRU
[12:46] <Trevinho> ok, fine
[12:46] <Trevinho> all bileto tickets are running
[12:48] <Laney> BI LE TOOOOOOOOOOOOO
[12:48]  * Trevinho is missing was missing it
[12:48]  * Trevinho was missing to hit ctrl+backspace too
[12:51] <Laney> SRU team hates reviewing bileto SRUs btw
[12:51] <Laney> ;-)
[12:52] <Laney> Trevinho: do you have an idea for handling people that already removed it without purging?
[12:53] <Trevinho> Laney: eh, as they don't have the tools, but I think fixed a bit
[12:53] <Trevinho> Laney: the only thing I was thinking is doing a purge from another package that is going to be installed instead, but not that I like the solution...
[12:54] <Trevinho> I mean the symlink thing was gold compared to this :)
[12:54] <Laney> I don't think there is a good solution :(
[12:54] <Laney> actually asked in #debian-devel about that earlier and nobody had a good idea
[12:54] <Laney> rm_conffile from like mesa or something would be OK as long as the file is put back if they reinstall nux-tools later on
[12:55] <Trevinho> Laney: that's why I also wanted to get rid of the conffile at all
[12:55] <Trevinho> Laney: in this way there won't be such problem either
[12:56] <Laney> stop engaging me in this argument please
[12:58] <Trevinho> ahaha, that's just I'm saying the rationale behind it (https://wiki.debian.org/ConfigPackages this also mentions something)... And don't keep it hard.  It's just we're in a land of cases where clean solutions aren't always feasible, thus...
[12:59] <Trevinho> Laney: anyway doing a purge from postinst of ubuntu-desktop (or any other choice) for example would work, but really I don't like it
[13:00] <Laney> I don't think there *is* a good solution
[13:00] <Laney> I only say mesa because that's the pkg that is going to have (most) problems with this
[13:00] <Laney> i.e. you have a problem because you have this installed
[13:09] <Trevinho> Laney: true, I was thinking higher level like ubuntu-desktop since it's something that as a desktop we want it to be fixed when ubuntu-desktop is there, while we don't care if the user has other broken config.
[13:09] <Trevinho> Laney: anyway... thanks for approvals
[13:09] <Trevinho> but, I moved the a, b branches to another one since they don't include the m4 change
[13:09] <Laney> I just did the ones that were linked from the bug
[13:10] <Trevinho> Laney: yeah, you did wel.... I didn't update it yet as I was waiting for bileto results
[13:10] <Trevinho> Laney: I can self-approve btw as they're just the same - the m4 change
[13:10] <Trevinho> https://code.launchpad.net/~3v1n0/nux/x11-conffile-on-unity-only-ab/+merge/347867
[13:11] <Laney> sure if you link to the one where I approved for reference
[13:11] <Trevinho> yep
[13:11] <Trevinho> that was the plan
[13:19] <Trevinho> Laney: when you've a sec, feel free to publish https://bileto.ubuntu.com/#/active?search=1768610
[13:24] <seb128> Laney, Trevinho, that's what they did for upstart but they had an easier job that the package has been removed from the archive
[13:25] <Laney> seb128: that being?
[13:25] <seb128> http://launchpadlibrarian.net/358113353/xorg_1%3A7.7+19ubuntu4_1%3A7.7+19ubuntu5.diff.gz
[13:25] <seb128> DOH, sorry :)
[13:26] <Laney> thx!
[13:26] <seb128> np!
[13:26] <Laney> yeah I think you have to like check if the thing is removed
[13:26] <Laney> because it's still around
[13:26] <Laney> bit more complex as you say
[13:26] <andyrock> morning all
[13:26] <Laney> same idea though
[13:26] <Laney> hey andyrock, how's it going?
[13:27] <seb128> hey andyrock
[13:27] <andyrock> Laney: I'm good thanks you?
[13:27] <Laney> top
[13:27] <Laney> top QUALITY!
[13:28]  * Laney checks Trevinho's diffs carefully ;-)
[13:30] <didrocks> ah, it wasn't me adding it as a conffiles
[13:30]  * didrocks started to become crazy
[13:30] <didrocks> I added it for lightdm to check (but as a non file in /etc)
[13:31] <didrocks> then, it's all Lukasz's fault adding it to Xsession.d :p
[13:31] <didrocks> (but TBH, not real other alternatives)
[13:32] <didrocks> and yeah, +1 on the issue for non real conffiles, but not something to change in a SRU ;)
[13:32] <didrocks>  /end-arg ;)
[13:33] <Laney> all published
[14:28] <didrocks> pristine-tars is going to be interesting vs merging vs debian
[14:28] <didrocks> I wonder how much they will match the same hash, how we are going to document merging from debian (reimporting current debian pristine-tar branch)
[14:29] <Laney> git will probably merge it ok
[14:31] <didrocks> yeah, needs experimenting
[14:38] <Trevinho> didrocks: happy you agree on that, right not to SRU it, I was fine to do it for cosmic, since it was thee though, but not really relevant. :)
[15:50] <didrocks> Laney: something is probably fishy in my config
[15:51] <didrocks> Laney: gpb import-orig ../tarball created a commit in upstream/latest as well
[15:51] <didrocks> with a tag upstream/3.28.2
[15:51] <didrocks> which it then imported in the ubuntu/master branch
[15:51] <didrocks> so, up to latest commit
[15:52] <didrocks> it's like it couldn't match the upstream tag and import only what was required
[15:53] <didrocks> ah, tag format for upstream is tag: GNOME_CONTROL_CENTER_3_28_1
[15:53] <didrocks> I guess that's why the match didn't happen and it just took latest and went nuts
[15:54] <didrocks> I'm surprised that upstream/latest is | | | | Author: Michael Biebl
[15:54] <didrocks> | * |   commit 83b100dc96d318975a1db465ac955c49ba4bf22b (tag: upstream/3.28.1, debian/upstream/latest)
[15:54] <didrocks> upstream/latest isn't supposed to be pure upstream repo?
[15:54] <didrocks> and track upstream/master?
[15:55] <didrocks> it seems that it's always an additional commit, I guess it's linked to how pristine-tar is working
[15:56] <Laney> that's the delta between the tag and the tarball
[15:56] <Laney> upstream/* branches reflect the tarball's contents
[15:56] <didrocks> the delta is not in pristine-tar?
[15:56] <Laney> if you look you'll see merge commits
[15:57] <didrocks> I thought upstream/latest was upstream/master for instance
[15:57] <Laney> pristine-tar tells you how to get from a git object to a tarball
[15:57] <Laney> no it's not
[15:57] <didrocks> and pristine-tar is the delta between upstream/latest and tarball
[15:57] <Laney> it's the upstream release artifacts
[15:57] <Laney> it *contains* all of the upstream commits
[15:57] <Laney> but it is not identical to the branch upstream has
[15:58] <Laney> because tarballs often contain generated files and those are stored in there
[15:58] <didrocks> yeah, that's what I thought was in pristine-tar, but ok
[15:58] <didrocks> so basically, you merge upstream/master into upstream/latest?
[15:58] <didrocks> instead of being in sync?
[15:58] <Laney> I never touch upstream/ branches manually
[15:58] <Laney> gbp does that
[15:59] <didrocks> how can gbp knows upstream repo thus?
[15:59] <didrocks> it didn't invente those upstream commits
[15:59] <Laney> it knows what format to look for tags in
[15:59] <Laney> because it knows what version it's trying to import
[16:00] <Laney> this doesn't always work though, and in those cases you can pass --upstream-vcs-tag to tell it
[16:00] <Laney> jbicha has been asking upstreams to use consistent tag naming to make this work automatically in more cases
[16:00] <didrocks> hum
[16:00] <Laney> with some success
[16:00] <didrocks> but on https://code.launchpad.net/~ubuntu-desktop/ubuntu/+source/gnome-terminal/+git/gnome-terminal/+ref/upstream/latest
[16:00] <didrocks> you have like 47a9491... by Christian Persch<EMAIL_ADDRESS>on 2018-05-02
[16:01] <didrocks> which is an upstream commit
[16:01] <didrocks> I wonder how come it knows the upstream remote repo url
[16:01] <didrocks> and from what branch it's pulling from
[16:02] <Laney> so you go gbp import-orig ../gnome-terminal-3.28.2.tar.xz
[16:02] <didrocks> yep
[16:02] <Laney> or probably gbp import-orig --uscan
[16:02] <Laney> gbp can figure out the version from that
[16:02] <didrocks> sure
[16:03] <Laney> and then it goes and looks at all the tags it has in the repository
[16:03] <Laney> finds the 3.28.2 one and uses that
[16:03] <didrocks> how can it find the 3.28.2, from where does he fetch from?
[16:03] <Laney> you did git fetch upstream before
[16:03] <didrocks> ahhh, you mean, it's looking at the remote you added locally
[16:03] <didrocks> but not in a local branch
[16:03] <didrocks> ok, I got it
[16:03] <didrocks> then, it's doing the magic on upstream/latest and pristine-tar
[16:03] <Laney> right, you can have commits around but not on any local branch
[16:04] <didrocks> (upstream/latest is quite a misleading name)
[16:04] <Laney> just "known" to git
[16:04] <Laney> ok, well that's what dep14 specifies
[16:04] <didrocks> yeah, it's weird that's it's upstream/, and not something not really coming from upstream :)
[16:05] <Laney> it makes more sense if you think of the tarballs
[16:05] <didrocks> yeah, I can see that, however, the goal is to easily cherry-pick as well :)
[16:05] <didrocks> but ok, I think I got it
[16:05] <Laney> you can still do that
[16:06] <didrocks> I guess gbp import-orig fetch on all origins, before importing correct?
[16:06] <Laney> that happens in the <distro>/ namespace though
[16:06] <Laney> I don't think so
[16:06] <didrocks> ok, so if you don't fetch
[16:06] <didrocks> or the tag is invalid
[16:06] <didrocks> and it doesn't find it
[16:06] <didrocks> it's taking silently latest commit
[16:06] <Laney> from where?
[16:07] <didrocks> ah no, it won't, it's just that my setup was skewed by tracking upstream/latest on usptream/master
[16:07] <didrocks> as it was my understanding at the time :)
[16:07] <Laney> aha
[16:07] <Laney> not actually sure what happens if it can't find the tag, hopefully gives an error
[16:08] <didrocks> I'll give it some tries
[16:08] <didrocks> but ok, I need to change some of the repo layout I tried to explain :)
[16:08] <didrocks> btw, dep14, does you have a link?
[16:08] <didrocks> http://dep.debian.net/deps/dep14 is 404
[16:10] <Laney> looks like it moved to https://dep-team.pages.debian.net/deps/dep14/
[16:11] <didrocks> thanks, google wasn't my friend
[16:11] <didrocks> ok, more of that tomorrow I guess! :)
[16:11] <didrocks> time to sign off
[16:11] <Laney> think this pages.debian.net stuff happened recently with the salsa move
[16:11] <Laney> see you!
[16:11] <didrocks> yeah, I guess related to salsa move
[16:11] <didrocks> bye ;)
[18:47] <willcooke_> night all
[19:18] <tsimonq2> Hey, so I'm going through Qt 4 removal bugs and autopilot-qt came up. Is this something that's still used, needed, or wanted?
[19:19] <tsimonq2> It would be great if someone could comment on bug 1757600 either asking for its removal or clarifying the status of it going forward.
[19:19] <ubot5`> bug 1757600 in autopilot-qt (Ubuntu) "Please port your package away from Qt 4" [Undecided,New] https://launchpad.net/bugs/1757600


[02:13] <gunny26> Does anyone know a way to get Ubuntu quiet on the disc ? tried everything on http://www.agol.dk/quietlinux/ but its not enough.
[11:09] <lucu_> ciao a tutti!!
[11:59] <zucaritas> hey I just upgraded from Dapper to Edgy on myAcer 5003 laptop and I can't configure the wireless card
[11:59] <zucaritas> anyone can help?
[12:00] <Nailor> What card?
[12:03] <zucaritas> it'sthe BMC4318


[19:02] <alkisg> tomreyn: e.g. suppose one has an old ubuntu pc around and just needs python3 to do a quick homework for a day,
[19:02] <alkisg> do you think it's OK to tell him how to get it, or is it better to set "we don't help with unsupported releases, period" as a channel rule? (I'm asking, I don't know the answer...)
[19:02] <tomreyn> thanks for joining, alkisg
[19:02] <alkisg> Of course, after giving proper notification about the security issues involved, and also the advice to upgrade asap
[19:03] <tomreyn> personally, i'd say it's fine to help anyone who runs an outdated ubuntu release to take the steps needed to replace their current release by a supported one, through either backup and fresh install, or upgrading.
[19:04] <tomreyn> that's my opinion on #ubuntu - i have less of an opinion on other channels
[19:04] <tomreyn> i was looing for guidelines on this earlier, but did not see anything specific
[19:05] <alkisg> OK, so me mentioning that "it's possible to install python3 in 12.04" wasn't against the rules or something...
[19:05] <tomreyn> we have the general guidelines at https://wiki.ubuntu.com/IRC/Guidelines and the supporters guide at https://wiki.ubuntu.com/IRC/SupportersGuide
[19:05] <tomreyn> alkisg: i'm saying that i don't think there are rules on this, so i was just stating my personal POV.
[19:06] <tomreyn> you could maybe say that #ubuntu is about ubuntu support only (that for sure), and that what is unsupported is outside of support
[19:07] <alkisg> E.g. "reminding them PPA's are not officially supported (!ppa) on the channel(s) but by their maintainers."
[19:07] <tomreyn> i think others have taken this stance before. i would prefer it being explicitly stated in thouse guidelines, though.
[19:07] <alkisg> I think that's similar; it doesn't say "PPAs are not officially supported so they can't be discussed in #ubuntu:matrix.org
[19:07] <alkisg> (from https://wiki.ubuntu.com/IRC/SupportersGuide)
[19:10] <tomreyn> hmm, maybe pointing out "what you are doing is a bad idea" can be sufficient. but effectively it does not seem to be. there are people who just ignore these notices repeatedly and do themselves a disservice. just like samfire, who has ignored this suggestion many times.
[19:13] <tomreyn> this would probably need to be discussed on mailing lists to reach an agreement and extend the guidelines. i'm not sure i want to spend the energy on that. i'd rather prefer spending some energy and, if needed, some money, on getting sam and others in this situation a way forward (because just upgrading a 32-bit system toto 18.04 really isn't much of a way forward)
[19:14] <tomreyn> if anyone else has opinions on this, i'd be delighted to hear those
[19:15] <alkisg> In some cases, an ubuntu pc around isn't the "main device", they launch it e.g. once per month. I wouldn't want to spend the energy to get THAT pc to an updated state. Of course I would advice the user to do it, but if the user doesn't care, he may have a reason...
[19:16] <alkisg> I wouldn't mind helping a user to find a way to get his homework done though
[19:16] <alkisg> If #ubuntu doesn't mind me doing so, that's what I would personally prefer to do...
[19:18] <alkisg> E.g. in Greece there are probably 500 computer labs with Ubuntu 12.04. Of course I put a lot of pressure on teacher that want my support to get them updated, but I don't refuse helping them just because it's not officially supported
[19:19] <alkisg> Thank you for your thoughs tomreyn , much appreciated! :)
[19:19] <tomreyn> that's great of you. but i'd say that your personal take on when you're willing to support others does not have to be identical with that of the official ubuntu support channel
[19:21] <tomreyn> but, yes, there do't seem to be *specific* rules on supporting EOL releases for #ubuntu now, for all i can tell.
[19:21] <tomreyn> helping with homework assignments does not seem to be on topic, though
[19:21] <tomreyn> I also thank you for sharing your opinion, alkisg!
[19:22] <tomreyn> (and I very much like that you dedicate a lot of your time on supporting education in Greece)
[19:22] <alkisg> Of course my thoughts doesn't need to be the same as the support channel guidelines. I believe that the community members that do the support should be able to voice their preference, then the community (which also involves canonical, but not only canonical) should decide about the rules, and when they're set, everyone should respect them
[19:23] <alkisg> Helping with homework certainly isn't on topic, but helping with ubuntu would be, even if the user just wants to do a homework later on
[19:24] <alkisg> I.e. "how to install python", not "how can I solve my homework"
[19:25] <tomreyn> Oh, of course, that would be on topic.
[19:27] <tomreyn> if there won't be others voicing their opinions here and there won't be a general consensus on this, i'll try to hold back on asking others not to support this in #ubuntu for now.
[19:28] <tomreyn> (though i think i can still suggest not to do so, but should point this out as a personal POV)
[19:49] <alkisg> 👍


[17:52] <hellboy195> Hi, folks
[17:53] <hellboy195> I wanted to send you a mail with the next MOTU Meeting reservation. but my mail gets rejected because my mail adress is unknown!?
[18:27] <mdke> hellboy195: are you writing to<EMAIL_ADDRESS>[18:34] <hellboy195> mdke: yes
[19:20] <mdke> hellboy195: that's odd, the list is open to anyone
[19:21] <hellboy195> mdke: I'll to my 3rd try now :)
[19:21] <mdke> hellboy195: maybe try another address - is there anything unusual about your address?
[19:21] <hellboy195> mdke: gmailo
[19:21] <hellboy195> -o
[19:23] <hellboy195> hmm
[19:23] <hellboy195> not working
[19:23] <hellboy195> Your email has been rejected because you posted with an unrecognized
[19:23] <hellboy195> email address. Please contact us on IRC on #ubuntu-fridge on
[19:23] <hellboy195> irc.freenode.net
[19:23] <hellboy195> So here I am ^^
[19:24] <mdke> you're sure you're not writing to the Launchpad address?
[19:25] <hellboy195> To:
[19:25] <hellboy195><EMAIL_ADDRESS>[19:25] <mdke> weird
[19:25] <mdke> email me and I'll forward it
[19:25] <hellboy195> mdke: would you mind doing it?
[19:25] <mdke> mdke at ubuntu
[19:25] <hellboy195> mdke: thx :)
[19:26] <hellboy195> sent
[19:31] <mdke> hellboy195: forwarded
[19:32] <hellboy195> mdke: Thank you very much :)
[19:35] <hellboy195> Have a nice evening :) bye


[10:08] <WebVisitor-0> hi to all
[10:09] <WebVisitor-0> i've just a simple question
[10:09] <WebVisitor-0> i bought a logitech wireless touchpad
[10:09] <WebVisitor-0> and i'm looking for a way to use gestures :)
[10:10] <WebVisitor-0> is it supported by somthing? i find it is using synaptic driver


[08:05] <sil2100> seb128: hey! We still get build errors, we might need to get the 20.04 track recreated?
[08:05] <sil2100> Fetching snap "gnome-3-38-2004"
[08:05] <sil2100> error: cannot download snap "gnome-3-38-2004": no snap revision available as specified
[08:07] <seb128> sil2100, yes, sounds like we need stable/ubuntu-20.04 created for gnome-3-38-2004
[08:12] <seb128> sil2100, I did that now, could you retry a build?
[09:02] <sil2100> seb128: will do! One moment o/ Thanks a lot!
[09:03] <seb128> sil2100, np!
[09:41] <juliank> genii-core:
[09:41] <juliank> Oops sorry
[09:41] <juliank> Autocomplete + typo
[09:42] <GunnarHj> Hi juliank, will you handle the libnet-ssleay-perl merge (bug #1951993)?
[09:43] <juliank> GunnarHj: that seems to be part of the openssl transition that schopin is working on
[09:44] <GunnarHj> juliank: Ok, so we can just wait a bit then?
[09:44] <juliank> Sorry for the delay, my laptop is busy and I went to the chromebook, but it's just resumed and slow too
[09:44] <schopin> ... and I'm in need of a sponsor for #1952208
[09:44] <juliank> schopin: I can sponsor that shortly if nobody beats me to it
[09:45] <juliank> laptop is just recording a screencast for Google atm (build log crashing chrome), so can't interfere there
[09:46] <juliank> Now
[09:46] <schopin> To be clearer : bug #1952208 is the resolution for the libnet-ssleay-perl woes :)
[09:47] <GunnarHj> schopin: Is a sync from experimental all that needs? Is the existing patch not needed any longer? In that case I can do that.
[09:48] <schopin> Yes, no, and nice!
[09:48] <juliank> Already on it
[09:48] <juliank> Already synced
[09:49] <schopin> Some patches wait months for sponsors, while I have two competing for the same bug \o/
[09:49] <juliank> schopin: openssl transition is top priority :D
[09:51] <schopin> Any taker for bug #1945768 ? :)
[09:52] <GunnarHj> You beat me juliank. :/
[09:56] <GunnarHj> schopin: As regards 1945768, why didn't you subscribe ubuntu-sponsors?
[09:58] <schopin> I forgot it wasn't. For the initial patch, I deliberately didn't subscribe because I was waiting for us to be ready to upload OpenSSL3, and...
[09:58] <GunnarHj> schopin: Ok. Let me sponsor it.
[09:58] <schopin> Thanks!
[10:14] <GunnarHj> schopin: Done.
[10:15] <schopin> \o/
[10:21] <seb128> sil2100, build worked :)
[10:23] <sil2100> Yaay
[10:49] <GunnarHj> schopin: Did you see this:
[10:49] <GunnarHj> https://launchpadlibrarian.net/570712076/buildlog_ubuntu-jammy-riscv64.erlang_1%3A24.1.5+dfsg-1ubuntu1_BUILDING.txt.gz
[10:50] <schopin> 'checking whether the C compiler works... no' Well. That's a problem allright.
[10:51] <schopin> xypron: does this kind of failure ring any bell? ^
[10:56] <GunnarHj> schopin: I just retried the riscv64 build.
[11:34] <GunnarHj> schopin: Looks like that error didn't repeat itself in the retried build.
[12:33] <doko> mitya57: any idea about https://paste.ubuntu.com/p/NPg4N9vPmH/ ? there's no reference to clipboard.min.js in the sources, only in the generated docs
[12:39] <mitya57> doko: I'm away from my laptop now, but wild guess: it's coming from sphinx-copybutton and our package has this patch: https://sources.debian.org/src/sphinx-copybutton/0.4.0-2/debian/patches/system-clipboard-js.patch
[12:40] <mitya57> So try symlinking it manually to /usr/share/javascript/clipboard.js/clipboard.js
[12:41] <mitya57> dh_sphinxdoc simply tries to make sure that all files included in <script> tags really exist.
[12:43] <doko> looking ...
[13:23] <schopin> Looking for a sponsor, another openssl3 related upload: bug #1945764
[13:23] <schopin> Perhaps someone from the kernel team would like to take a look?
[13:39] <doko> looking ...
[13:49] <doko> ... and uploaded
[15:15] <xnox> juliank:  update-initramfs: Generating /boot/initrd.img-5.13.0-19-generic
[15:15] <xnox> No lz4 in /usr/bin:/sbin:/bin, using gzip => is odd in autopkgtests in jammy on s390x, because initrd should be using zstd compression in like hirsute and jammy.
[15:15] <xnox> juliank:  as if the base image needs to be rebuilt form scratch / did not get upgraded correctly to the latest initramfs-tools config.
[15:16] <juliank> xnox: no, we override the compression
[15:16] <xnox> juliank:  /o\ without installing lz4?!
[15:16] <juliank> xnox: apparently
[15:16] <xnox> juliank:  cause initramfs-tools dropped lz4 dep, when i changed it to zstd. Yeah, if you want lz4 for speed, then yeah, it needs to be installed as well.
[15:16] <juliank> xnox: we should really fix the zstd compressino level to be usable
[15:17] <juliank> I think -15 was 10% larger but compressed a couple times faster
[15:17] <juliank> Right now, it's slower than xz at compressing
[15:17] <juliank> or sameß
[15:18] <juliank> I think installing lz4 is probably not a good idea vs just using gzip
[15:18] <juliank> but I don't know, I haven't really measured how much the speed difference is
[15:20] <juliank> I mean, we now boot like 0.1s faster but need a couple minutes more to install kernel upgrades
[15:20] <juliank> so anyway, I guess installing lz4 works too, it will make image builds slightly slower, but initrd rebuidls in tests faster
[15:22] <xnox> juliank:  i can see the point of tweaking initrd compression level especially the ones that are built on the end user machine.
[15:22] <juliank> should we have different levels for pre-built kernels vs initrd built on upgrade?
[15:22] <xnox> the initrds that we prebuild can be set to infinity (i.e. the ones created during livecd-rootfs)
[15:22] <juliank> I think that would work
[15:22] <juliank> well
[15:23] <juliank> you want -19 on those
[15:23] <juliank> -20, -21, the --ultra levels are slower to decompress too
[15:23] <xnox> right, cdimage/livecd-root/ubuntu-core-initrd should be using -19
[15:23] <xnox> whilst initramfs-tools default for end user systems should be like -15
[15:23] <xnox> would be nice if we could autodetect that somehow, or export the right env variable somewhere. I bet we'd have to patch this in 7+ places
[15:24] <juliank> when building in a chroot -> build at -19
[15:24] <juliank> otherwise -> build at -15
[15:24] <juliank> hacky whacky idea
[15:24] <juliank> I can recompress my initrd at all levels and make a level, speed, size table
[15:25] <juliank> then we can see how those stack up
[16:15] <xnox> but our installers run in a chroot, so when subiquity/ubiquity chroot /target update-initramfs => should that be -19 or -15?
[16:15] <xnox> i err on the side of -15
[16:15] <xnox> (aka like the subsequent updates will be)
[16:25] <juliank> xnox: doesn't matter much at install time
[16:25] <juliank> xnox: in terms of relative time use
[16:25] <juliank> I think
[16:26] <juliank> more concerned with ugliness of it all
[16:26] <juliank> adding an option for the compression level and then override in conf.d where we wnat it to be 19 might be a good idea
[16:27] <juliank> But as you mentioned it needs a lot of places
[20:21] <mwhudson> anyone have thoughts on my plans for testing the glibc 20.04 sru? https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1951033
[20:23] <mwhudson> i care about the compression level during installs :)
[22:12] <RAOF> mwhudson: I think you should explicitly call out testing *graphical* snaps on a variety of drivers/hardware (mesa, amdpro, nvidia), as that's been troublesome in the past.
[22:13] <mwhudson> RAOF: ok, do you have any idea how to formalize that? :)
[22:14] <RAOF> Oh, no!
[22:14] <mwhudson> i should probably email ubuntu-devel about this
[22:15] <mwhudson> added a note to the bug
[22:17] <RAOF> I might try and dump some thoughts there, too.
[22:19] <mwhudson> thanks
[22:22] <sergiodj> RAOF: hey, could you please reject two uploads for me?
[22:22] <sergiodj> RAOF: ubuntu-advantage-tools on Impish and Hirsute
[22:23] <RAOF> sergiodj: Sure!
[22:23] <sergiodj> thank yoU!
[22:24] <RAOF> Done.
[22:24] <sergiodj> RAOF: thank you very much
[22:24] <sergiodj> I'll fix and reupload them soon
[22:41] <RAOF> tjaalton: What sort of support does the proprietary amdgpu stack have from us? I don't have a workstation GPU, so it's hard to check :)
[22:57] <mwhudson> hm i can't reproduce https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1926379
[23:13] <mwhudson> i hope some of the fixes in this glibc update are worth the stress :)
[23:14] <mwhudson> sarnold: hiya, did you ever understand what was going on in https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1926379 ?
[23:15] <mwhudson> sarnold: i'm trying to work up if upgrades from the dodgy 0ubuntu9.3 to a planned 0ubuntu9.4 really need to be prevented
[23:15] <mwhudson> *work out
[23:35] <amurray> mwhudson: speaking of glibc, is this https://twitter.com/jer_s/status/1463709224697950210 something we should try and avoid/detect/automatically handle in affected packages (ie somehow trigger postgres to automatically rebuild indexes or somesuch on upgrades of glibc?)
[23:37] <mwhudson> amurray: it's something we and our users need to be aware of for sure
[23:37] <mwhudson> amurray: not sure about triggering index rebuilds on updates, that sounds _fairly_ hair raising
[23:38] <mwhudson> shout out to first replier for boomer energy
[23:40] <mwhudson> amurray: i have _very carefully_ checked that the C.utf8 locale that is now upstream collates the same way as the one we currently ship, fwiw :)
[23:40] <amurray> awesome - thanks, so does that mean going forward it should be less of a problem?
[23:41] <mwhudson> not necessarily
[23:41] <mwhudson> people do, for some reason, use locales other than C :)
[23:41] <amurray> oh..
[23:42] <amurray> ah right.. of course - so then I wonder if we should have an autopkgtest to try and detect changes so that we can then warn users on upgrades which we know could be problematic?
[23:44] <mwhudson> ... maybe? autopkgtests in general are not good for detecting changes betwen versions
[23:49] <amurray> I guess I was thinking we could generate a set of known data from the current version, and then do the same in the test and check it still matches or somesuch


[20:56] <Unit193> micahg: Can't remember who it was, but #ubuntu+1 was reopened for discussions of Quantal Quetzal in case you didn't already know. :/
[20:56] <micahg> Unit193: I'm there ;)
[20:56] <Unit193> Wasn't sure if the other looking was, but alright.