=== tedg_ is now known as tedg === davidcalle_ is now known as davidcalle === Dmitrii-Sh_ is now known as Dmitrii-Sh === FourDollars_ is now known as FourDollars [06:06] good morning [06:15] Morning didrocks [06:19] hey duflu [06:19] I made a great discovery yesterday. But so far am being met with skepticism and criticism. Maybe more people should test it: https://gitlab.gnome.org/GNOME/mutter/merge_requests/168 [06:20] GNOME issue (Merge request) 168 in mutter "clutter: Remove input lag and cursor stutter [performance]" (comments: 4) [Opened] [06:27] good morning desktopers [06:33] hey seb128 [06:35] Morning seb128 [06:35] hey didrocks, duflu [06:35] how are you today? [06:36] seb128, not great. Awake since 5am for some reason. You? [06:37] I'm good, up at 6:10 today but I don't feel too tired [06:38] it's somewhat nice, I already clear my emails backlog, dropped the kid to childcare, had coffee and it's only 8:30 [06:38] seb128, yeah days like today I appreciate having time for pilates [06:38] and not just rushing to my desk [06:39] you do pilates in the morning? [06:39] seb128, only when I have time. Not often mid week any more [06:39] * seb128 is not a morning person, I've difficulties doing any sort of exercice in the first hour after I wake up [06:39] Stretching doesn't raise the heartrate [06:40] Unless you're in fear of over stretching [06:44] I've not really flexible, even less in the morning :p [06:44] like I would be able to touch my knee with my hand, maybe my ankle but not my foot [06:46] seb128, yeah I was the same a few years ago. Still not great only doing it once or twice a week. But daily seemed to cause more problems than it solved === pstolowski|afk is now known as pstolowski [07:30] good morning desktoppers [07:31] didrocks, can you add me to the team so that I can assign myself communitheme bugs? see https://github.com/ubuntu/communitheme/issues/350#issuecomment-406173316 [07:31] ubuntu issue 350 in communitheme "libreoffice not opening properly on communitheme.snap" (comments: 18) [Snap, Closed] [07:31] unless this is a restricted team for active contributors to the theme only [07:33] oSoMoN: done! [07:33] et salut ;) [07:36] Hi oSoMoN [07:39] morning [07:39] Hi Trevinho [07:41] hey Trevinho [07:42] Trevinho, Buongiorno [07:52] merci didrocks [07:52] de rien ;) [07:52] hey duflu, Trevinho, seb128 [07:52] lut oSoMoN, en forme ? [07:53] (and brb, changing location) [08:00] seb128, didrocks Bonjour [08:01] Et oSoMoN [08:01] Hi duflu [08:01] vatz up [08:02] hey Laney [08:03] Hi Laney [08:03] i tink datz all vatz up [08:18] hoi [08:18] I guess Laney arrived while I was moving, hey Laney :) [08:18] hey seb128 (didrocks & duflu) [10:06] hum, new meson doesn't like the symlinks on g-i-s.desktop: https://launchpadlibrarian.net/379093344/buildlog_ubuntu-cosmic-amd64.ubuntu-settings_18.10_BUILDING.txt.gz [10:11] confirming it's 0.47 introducing this regression [10:23] could somebody look at https://launchpadlibrarian.net/379210467/buildlog_ubuntu-cosmic-i386.goffice_0.10.41-1_BUILDING.txt.gz ? blocks a few packages [10:23] Laney: ciao amico! [10:24] https://github.com/mesonbuild/meson/issues/3914 [10:24] mesonbuild issue 3914 in meson "Symlinks can't be copied by install_subdir() since 0.47.0" (comments: 0) [Open] [10:24] same on debian [10:26] Laney: as for the upstream tags thing I was asking few days ago... I think csoriano might make a release for nautilus today... if he does, that would be a case where if I import the orig in ubuntu first (and then debian does), would cause some troubles, no? Well, in this case probably it's just better to ask you to merge my PR for the pristine-tar in debian and then going with ubuntu, but well... what would be better? :) [10:26] ahah, the code has a "# FIXME: what about symlinks?" [10:26] for meson [10:26] yeah, "thx" ;) [10:27] Trevinho: just propose the upstream stuff to salsa [10:27] that's fine, I only need to have you around :) [10:27] one day you can get access there [10:28] if it involves bureaucracy probably not :-D [10:28] less than getting gnome commit rights [10:29] doko: not sure what that has to do with this channel? [10:31] Laney: for me that one was really easy... I said can I have push access? Done. :D [10:31] O_O [10:31] well then it's the same [10:32] good new point releases for mutter and shell ready... [10:32] * Trevinho prepares branches [10:32] these people skipping the process [10:32] RULES [10:32] I LOVE RULES [10:33] Cages you love cages! [10:33] I put rules, I don't respect them though... Classic italian way :-D [10:34] (ERROR: ERROR:../../../../../testsuite/gtk/defaultvalue.c:45:check_property: Property GtkFontChooserWidget.tweak-action: NULL != ((GSimpleAction*) 0x5619ca8c6800) [10:34] now what is this trying to tell me [11:06] * Laney finds the commit that fixes that [11:28] Laney: https://salsa.debian.org/gnome-team/mutter/merge_requests/3 and https://salsa.debian.org/gnome-team/gnome-shell/merge_requests/2 [11:28] GNOME issue (Merge request) 3 in mutter "New upstream release 3.28.3" (comments: 0) [Opened] [11:28] GNOME issue (Merge request) 2 in gnome-shell "New upstream release 3.28.3" (comments: 0) [Opened] [11:28] yeah, it emails me [11:28] are you going to do the debian/master bits too? [11:29] since I was there... altough... I'm seeing something weird in the diffs :o [11:31] Laney: as updating pristine-tar only would involve passing an upstream/x.y.z tag or i could use the actual x.y.z tag from upstream only? [11:33] I mean gitlab shows also debian/* files which I didn't touch as changes, while local git diff salsa/debian/master doesnt [11:35] * Trevinho updates ubuntu too (time to create a branch for mutter ubuntu/bionic I guess, as I wanted that anyway) [11:36] what changes are needed there over cosmic? [11:40] Laney: nothing, but to track at least the changelog and stuff... And not to have to deal with debdiffs :-P [11:40] and we eventually we'll need one anyway, so... [11:40] technically we've already forked (as if just for changelog) [11:45] in any case, in this scenario without having g-s on salsa to have the upstream/foo tag udpating also ubuntu g-s would be problematic I guess, as if debian wouldn't want to update (for example) we'd ended up in redefining a new upstream/version tag which then debian will overwrite... If cases like this would happen (hypotetically now), wouldn't be just better to use a different upstream tagging option? (like upstream-ubuntu/version) [11:45] I'd rather we stop coming up with problems that don't exist yet [11:49] what's the issue? us updating before Debian? [11:50] there is no reason the pristine-tar/gnome content should be different even if we do update on our side and they do it later on their right? like merging should just work, and the tags are different since the versions are different? [11:51] seb128: yes, that case... [11:51] the upstream tags will be different [11:52] I can't be bothered to fight over these details every day [11:52] so I just go with whatever you propose [11:52] so when you import the origin, as per our gbp.conf we get upstream/x.y.z tag, while debian might have the same later [11:52] ah [11:52] what do you propose to do for those cases? [11:52] 😂 win for stressing :-D [11:53] Well, I though that in such cases we could change the debian/gbp.conf to use something like upstream-ubuntu/x.y.z tagging then, when we merge back get it back to upstream/foo [11:54] not that is a solution I like, but it's the only one that comes up to my mind not to have to have clashing tags [11:54] anyway Laney in this case just merge and I'm happy :-P [11:55] but there will be cases, I know, when we can't proceed this way [11:56] Trevinho, https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1718931 has been fixed in g-s 3.28.3 if you want to list it in the changelog [11:56] Ubuntu bug 1718931 in gnome-shell (Ubuntu) "No VPN autoconnect" [High,In progress] [11:56] seb128: yeah, also others thanks... but I've not prepared the g-s for ubuntu yet as I'm not sure if I can reuse the tag I just done for upstream until it gets merged to debian [11:57] (to merge with that) [12:01] k, well that discussion is a bit over me and I feel like it's a sensitive topic for Laney and I don't want to piss off anyone so I'm going to step out and let you guys deal with it [12:01] just "we can't update because Debian didn't update yet" isn't an answer, how we get the update I don't care about [12:02] either by doing ourself in Debian, doing it first and dealing with tags issues or whatever you guys prefer [12:02] I've not actually any strong opinion in how [12:02] I only want to know how... [12:02] just pick one and go with it then [12:02] seems nobody is going to tell you that [12:03] both Laney and I bailed out from replying to that question [12:03] eh, but I don't want to go back later, so I ask [12:03] so do what you think makes sense [12:03] what is the actual problem that happens rather than a theoretical concern? [12:03] and if someone disagrees with what you did we can discuss [12:03] Laney, from what I understood Trevinho thinks we are going to have the upstream/3.28.3 tag on a different commit than Debian [12:04] unsure if that's a problem? [12:04] I understand that [12:04] I don't understand what the real problem that happens as a result is [12:04] Well, now might not be the case, as I've prepared the branches [12:04] seems like guessing / assumption to me [12:04] I don't understand git enough [12:04] can the same tag be defined twice? [12:04] or can we diverge? [12:04] no, but does it even matter? [12:04] or what tags mean [12:04] you merge the commit into the packaging branch [12:04] then it has multiple parents [12:04] but.... imagine we want to switch to any package first than debian... as for some reaason they want to stick to older version [12:04] even if one of them isn't named as a tagged revision [12:05] so does it really actually matter if you don't have the tags at all? [12:05] I think this is guesswork and nobody has actually tried it to see what the problem is [12:05] k, as I said I don't understand git enough to understand what consequences a mismatch is the tagging has [12:06] I can merge with actual upstream branch and that's fine... [12:06] I'm happy to talk about *real* problems [12:06] but yeah, I'm fine ignoring the issue until it creates a problem in practice, then we can fix if needed [12:06] that have *actually* happened [12:06] but discussing abstract things, not so much [12:06] but the fact is that if you don't have the upstream-tag set, gbp complains no? [12:06] Trevinho, import-orig would tag upstream no? [12:06] Laney: I need you more philosopher :) [12:07] seb128: eh, yes... but we can't do that or that tag will be on debian too later.. .so [12:07] Laney, fine, but if we *know* that we are doing something stupid that is going to blow up we might as well discuss how to fix it before it bites us ... which from the backlog I now understand it doesn"t seem to be the case there and we don't know if it would create any problem [12:07] this is the case where instead of using import-orig, you actually git merge with origin / branch [12:07] so yeah, let's stop arguing and just do the work then [12:07] seb128: yes, so if you think there's a problem [12:07] then demonstrate that it exists [12:08] agreed [12:08] Laney: I think we already had a clashing tag issue... [12:08] Trevinho, ^ let's get the tag first and see what it leads to when debian does the update [12:08] Trevinho, what was the impact? [12:08] if that's "none visible" let's not care? [12:08] you still have a reference to the commit, even if you don't have the tag by name [12:09] so the problem would only be if gbp is trying to use it by name and it ends up being different and that breaks [12:09] yeah, that's fine... but we'll have 2 new upstream release tag.. and at that point we've to --delete our tag, and keep debian? [12:09] or we don't care [12:09] that tag exists twice [12:09] and? [12:09] in our repo will be different than salsa [12:09] and? [12:09] or we just at that point --force push the new tag [12:09] to point to debian [12:10] if that happens we'll have a diverged upstream branch anyway [12:11] that's ok, nothing really hurting to me, but since I thought we didn't want to play with force or anything, I thought it was just saner to use our upstream tagging if we do upstream code before or different from debian, and then go back when we merge again [12:11] what I really want to avoid is making this thing really complicated [12:12] so I'm pushing back against adding more weird steps [12:12] now if something breaks, fine, we can't avoid it [12:12] but if it's no problem in reality then I would rather not make it harder [12:12] I see the point, I just expect that simplifying this could make things harder to fix [12:13] but I like to think in advance [12:13] that's fine [12:13] (only in computer stuff, not really in life :D) [12:13] but you can go experiment if you want to and find out what actually happens [12:14] go gbp import something in two repositories and play with merging between them [12:14] Laney: if would be possible to only push the upstream/{latest,foo} branches in salsa in case, is just enough though [12:14] as they will anyway need those [12:14] it is fine [12:14] it's always fine to push upstream and pristine-tar [12:14] and then they just merge when needed instead of using import-orig [12:14] those are objective things [12:15] ok, so let's define this rule... Propose any changes to `upstream/xxxx` branches and to `pristine-tar` always mandatory to be proposed to salsa too [12:15] not sure it simplifies (for who has no salsa write access) but at least, does the job [12:16] speaking of which Laney please pull there my ones for mutter and shell 💋 [12:16] (debian/master are done too, but... I can wait) [12:16] I will, don't stress [12:17] trying to get a build of gtk 3.23 [12:18] Trevinho, the less work is to do the update in Debian and just sync/merge from them, that systems is working for Laney's goal to have us doing the work there :) [12:18] ahaha, yeah... :) [12:18] 😎 [12:18] well, that's fine for me, and I agree in doing it. Well `debian/master` is another thing, so not sure I'll always do that :-D [12:19] I'm fine doing the work in Debian, I'm unsure how I feel about pushing/uploading things without testing them on the target distro though [12:19] but I guess we can push without the tagging/upload that's most of the work [12:19] well, if you only push upstream and pristine-tar branches you don't affect them [12:19] right [12:19] and that's safe [12:19] but I mean for quite some package we have no diff [12:19] so it would make sense to update in Debian and direct sync [12:19] ah, sure [12:20] like we do for mutter right now [12:20] but then do you test that build on cosmic and assume it's working on Debian? [12:20] I don't like much assuming it's fine [12:20] ah, indeed [12:20] no I run the things [12:20] but I don't have enough installs to be using Debian [12:20] already having Ubuntu current, current stable, LTS [12:20] yeah, it's quite a lot of chroots [12:20] you can fire a VM and do a "log in, it works, ship" [12:20] it's a bit of work and not proper testing though [12:21] what do you do for testing for cosmic? [12:21] I usually boot the version of Ubuntu I'm currently working on [12:21] it's fine to break debian.... It's the purpose of "sid" :) [12:21] e.g the days I do cosmic update I boot that [12:22] the days I work on SRUs I boot my bionic disk/partition [12:22] but I already reboot too much to my taste [12:22] but it's probably mostly testing along those same lines? [12:22] I don't want a 3rd Debian install [12:22] install it, play a bit, ship it [12:22] well I'm usually doing full days [12:22] so I dput mid-day after having used a bit the session [12:23] but yeah, no perfect system [12:23] it's just more complicated to target several distributions/series [12:23] and the more you add the more complex it gets [12:23] well, in any case I'm quite sure if there are not huge packaging changes if it works in cosmic, works in debian [12:23] no magical way around it sadly [12:23] ok, well, as you wish [12:23] there's no new argument here [12:24] either you want to do some work to make it happen in debian, and then nobody has to duplicate the packaging work [12:24] In any case, I'm fine to work on debian as much we can... [12:24] or not, and someone does, but maybe a higher chance someone catches a bug [12:24] Trevinho, yeah, that makes sense [12:24] for apps I'm confident enough [12:25] In fact... for gnome-shell I already had some sync-with-debian work done that I should prepare for cosmic [12:25] not likely to behave differently between distros and not the end of the world if there is an issue in the image viewer [12:25] but the shell is a bit trickier [12:25] although we still have our patches, but at least rebase on that [12:26] for mutter is fine, although I'd like some more freedom, but normally we add to it only stuff that is anyway proposed to upstream, so even debian guys are fine normally [12:27] people can do what they think is best [12:27] that said, I'm going to update g-s on ubuntu... Using my tag. :) [12:27] it's been this way for years with only a couple of us doing the updates on the debian side [12:27] not going to destabilise anything if this doesn't change [12:28] I like to propose things there, I just don't want to slow down even more the work... as you know, I already I've to pass through the desktop sponsor, later will be debian sponsor + sync. I'm ok to do it, but indeed slows things down a bit (especially if you have to reiterate) [12:29] but since all this git thing happened, working with both debian and ubuntu and upstream is a looooooot more easier and productive [12:29] so happy to put more bits at the very source [12:31] seb128: for nautilus.. our MPs are approved, let me know if you want to wait a bit more (i'd say eod) for rebase this on next upstream release if Carlos can do it, or we can proceed with these [12:34] seb128: ah, also for bionic maybe I should use different different versioning? [12:34] like 0ubuntu0? [12:35] Hi all - I have a patch/SRU request outstanding for the last couple of months - anyone got a bit of time to sponsor it? https://bugs.launchpad.net/ubuntu/+source/gnome-menus/+bug/1765799 [12:35] Ubuntu bug 1765799 in gnome-menus (Ubuntu) "Applications menu does not get populated with recently installed apps using apt" [Medium,New] [12:37] fossfreedom__: can you propose a MP against https://code.launchpad.net/~ubuntu-desktop/ubuntu/+source/gnome-menus/+git/gnome-menus ? :) [12:39] Trevinho: sure ... any instructions available on how this is now done with the new launchpad git system? [12:39] fossfreedom__: https://wiki.ubuntu.com/DesktopTeam/git [12:40] Trevinho, right, nautilus is on my todo for today, morning was a bit busy but I do that in a bit [12:41] so gbp clone that repo, gbp pq import add your patch (in this case you can use git apply probably), then, gbp pq export, edit changelog, stage changes (avoid committing index updates, if not in a different commit) [12:41] Trevinho, versioning, https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging [12:41] oh, that's the wiki I was looking for, thanks [12:42] fossfreedom__, sorry about this one, I though jbicha would handle it/I wanted to talk to him since he's the one who introduced the bug, but I was busy and he vanished then [12:43] seb128: as for version for SRU (before you review it), should be 3.26.3.1-0ubuntu0.18.04.1 then [12:43] fossfreedom__, I've already too much on my todo for today and I'm having a day off tomorrow but I have a look next week for sure if nobody beats me, if you get a git mr up by then it should be all good :) [12:43] while for mutter we used the ~ubuntu18.04.1 way [12:43] (i like that more I think :P) [12:43] not sure then [12:44] Trevinho, sounds like it ... I had a case of where I used ~18.04 recently which was rejected and reupload by the SRU team with another version, depends who is reviewing it [12:44] k [12:44] but yeah, ~serie is right as well [12:52] seb128: ta. Will try to get my head around this. I'm used to the github fork and graphical merge process - this launchpad method looks nothing like that. [12:53] fossfreedom__, well, it's basically "push to git, click on the submit merge request button" similar to what you did with bzr in launchpad [12:53] just the vcs commands changing and the url in launchpad to get/push/browse [12:54] ah - in that case, more happy [13:10] seb128: things for loving git even more https://stackoverflow.com/a/44754855/210151 :-D [13:10] I was trying with `git show --theirs` but, noooo... [13:11] lol [13:12] 1, 2, 3... easy :) [13:12] * Trevinho wonders how to alias these [13:13] I was just having a git rage that it was telling me my branch was up to date when trying to merge with debian [13:14] ...I was typing the wrong branch name [13:14] 😭 [13:29] sigh [13:29] * willcooke needs new glasses [13:29] I shouldnt have got a laptop with a 1080 13" screen [13:30] * willcooke <-- old [13:39] * Laney nelson laugh [13:48] Laney: I love raging laney :-D [13:49] ;_; [13:54] ahhhhhhhhhhhhhhhhhhhhh [13:54] a new gtk 3.23 release just as I was about to do the other one [13:54] new release, new testsuite failures /o\ [13:58] * didrocks reboots with gdm debug log on [13:58] gdm doesn't find a session in /usr/local [14:13] * czajkowski passes Laney a 99 to cool on down :) [14:13] yessss [14:13] 🍦 [14:13] that would be good actually, this room is currently 27.7C [14:18] ok, so: [14:18] 1. GDM doesn't have /usr/local in its env var, that's why I think it's not picking up things in /usr/local [14:19] 2. GNOME Shell doesn't like mode names with upper letters [14:19] * didrocks will file moar bugs today [14:23] didrocks, Laney, seb128: I've updated this section https://wiki.ubuntu.com/DesktopTeam/git#Merge_a_new_upstream_version including the thing we discussed earlier about push-back to salsa the pristine-tar/upstream branches changes, how to proceed if the tag is already there and how to deal with rebasing patches [14:24] didrocks: you can pass XDG env to gdm now, not in 3.28 though [14:24] I fixed that as I needed it to get gdm working from jhbuild [14:27] Trevinho: yeah, my issue is bionic [14:27] didrocks: eh, there's a patch to cherry-pick if you want [14:27] :) [14:28] Trevinho: unsure it worthes it right now, but we'll see. At least, no need to open a bug on that one :) [14:33] a last reboot, hopefully :) [14:42] mh, when gnome-shell was pushed to ~ubuntu-desktop, the tags where not pushed... [14:43] also the release is missing a tag... [14:45] while ubuntu/3.28.2-0ubuntu1 is wrong... [15:00] didrocks: we miss tags on gnome-shell, could you push and pull them from my remote? [15:00] err pull and push :-P [15:04] and actually before pushing fix ubuntu/3.28.2-0ubuntu1 as that should be for 65d8e54e48028903b626117d6f19a4aab42353fa (current git head) [15:04] Trevinho: who did push your g-s word and why did we miss tags? [15:04] cause tags were not pushed I guess [15:04] I don't remember, is it me transforming the branch? [15:05] might be, if you didn't just changed ownership from lp ui that might have happened [15:05] Trevinho: ah, you did the transform [15:05] not an issue, although I think I deleted the ~canonical-deskop-team branch so... let me seee [15:05] Trevinho: and I confirm I don't have the tags locally, so you didn't push them in your script :p [15:05] no, no I pushed... they are in my remote [15:05] well, remote from when? ;) [15:06] and same in the all the other canonical remotes, so... should be there [15:06] can you give me the remote url so that I don't have to search for it and just push the tags? [15:06] lp:~3v1n0/ubuntu/+source/gnome-shell [15:06] thx! [15:06] let me check though as that should be a bit different now, but just try to get tags from that and see if they apply [15:07] plus you nee to git tag the desktop-team heaad with ubuntu/3.28.2-0ubuntu1 [15:07] Already up to date. [15:07] hum, how do we fetch the tags only? [15:08] git fetch --tags [15:08] argh, missing s :/ [15:08] but actually these two branches might be a bit different, so let see if they apply, otherwise I need to go manual way [15:08] actually, the tag ubuntu/3.28.2-0ubuntu1 already exits [15:08] but on a commit you unreferenced [15:08] yeah, but it's wrong [15:09] yep [15:09] why would it be different, you changed it again? :/ [15:10] no, I think we messed up things, as it was in the ~canonical-desktop-team and I removed the repo probably, while you imported from lp:~3v1n0 so they were different I think [15:10] anyway, I just retag tip with ubuntu/3.28.2-0ubuntu1, deleting the old one [15:10] yeah, need to do that [15:10] and yeah, I can't push because of tag conflicts [15:11] so -f? :/ [15:11] also a36941c3b739d907eeaf8a17bd73e7dca5988ab7 should be ubuntu/3.28.1-0ubuntu2-bzr to match old behavior [15:11] you can push -f on tag or [15:11] it's 65d8e54e48028903b626117d6f19a4aab42353fa [15:11] push --delete tag and then push again [15:11] which is tip [15:11] yeah, but people already having the branch would have conflicts [15:11] anyway… I'll tell them to talk to you, I don't want to waste more time on this :p [15:12] the other tags were already on the remote [15:12] it's only the commit you tweaked which wasn't [15:13] andyrock, hey, I uploaded bug #1781996 to cosmic and bionic, unsure if you have a better testcase than watching error reports, if you do please update the bug info :) [15:13] bug 1781996 in gnome-software (Ubuntu) "/usr/bin/gnome-software:11:g_date_time_to_instant:g_date_time_to_unix:gs_plugin_refine_app:gs_plugin_loader_call_vfunc:gs_plugin_loader_run_refine_filter" [Medium,Fix committed] https://launchpad.net/bugs/1781996 [15:13] Trevinho: so, everything should be pushed [15:13] Trevinho, I'm sorry but I didn't manage to look at nautilus today and I need to call it a day early, going to France for the w.E and having tomorrow off [15:13] didrocks: tags aren't here https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gnome-shell/refs/ [15:13] but I might do an hour or so in the morning tomorrow and look at it then [15:14] ubuntu/3.28.1-0ubuntu2 [15:14] ubuntu/3.28.2-0ubuntu0.18.04.1 [15:14] seb128: mh, ok... carlos will do a release soon though, so i'll rebase on it [15:14] ubuntu/3.28.2-0ubuntu1 [15:14] $ git push --tags [15:14] Everything up-to-date [15:14] didrocks: the old ones I mean [15:14] mhmhmh [15:14] ah, wait I've them locally [15:14] :/ [15:14] seriously… [15:14] not sure, I pulled them from remote before [15:14] https://www.irccloud.com/pastebin/CBzR5rhA/ [15:15] So they should be no remote [15:15] didrocks: ahhhhhhhhhhh [15:15] need to od this [15:15] what git tag -l 'ubuntu/*' points to you? [15:15] Trevinho, well, let's see tomorrow [15:16] maybe the delay is helping in that regard :) [15:16] seb128: I'll prepare everything tonight if he gets it ready [15:16] thx [15:16] Trevinho: the 3 commits I gave ^ that's what I wrote [15:18] didrocks: this is weird... why when I fetched from my remote I had the tags there, while you didn't? :o [15:19] Trevinho: I just refetched again from your repo, and this time I got 50Mg + the tags… :/ [15:19] mh and I didn't push nothing [15:19] launchpad snaffu? [15:19] I'm repushing your tags and content [15:20] only tags [15:20] well, git push --tags do both [15:20] mhmhm wait then :) [15:20] too late [15:20] but errored out [15:20] because of tag conflicts [15:21] soooo... this [15:21] git tag | grep -E '^ubuntu/|^debian/|^upstream/' | xargs --no-run-if-empty git push origin --force [15:21] this will only push tags [15:22] Everything up-to-date [15:22] ack [15:22] as for content, good that it didn't update [15:22] it did [15:22] I think it only errored out on the tip tag [15:22] which isn't part of the transaction [15:22] so your 60M or so are now in the ~ubuntu-desktop branch [15:23] lovely data [15:23] well I would have only pushed the tags as before, reducing a bit the things, but... [15:23] ok, so I need to fix manually the tip tag [15:23] could you tag also a36941c3b739d907eeaf8a17bd73e7dca5988ab7 as ubuntu/3.28.1-0ubuntu2-bzr for consistency [15:23]