| meebey | can I trigger a "BinNMU" on launchpad PPA without a sourceful re-upload? | 06:12 |
|---|---|---|
| meebey | I have changed the PPA dependencies and thus I only need to trigger a rebuild + package version bump, not sure if this is support | 06:13 |
| RAOF | meebey: Nope, not supported sorry. | 06:23 |
| _val_ | Hi everyone. On ubuntu 14.04.5 LTS I want to install this version of open-vm-tools: https://github.com/vmware/open-vm-tools/releases Could someone create a .deb package for version 10.1.5 or 10.1.0 | 07:28 |
| sarnold | _val_: the backportpackage command from the ubuntu-dev-tools package may be able to rebuild the zesty version on trusty for you | 07:41 |
| _val_ | sarnold: I come from a RH background.. I've no idea how ubuntu/debian does things | 07:43 |
| _val_ | I'm not sure what tools I need etc.. etc.. to build the package. Would be awesome if someone could build the package for 14.04.5 LTS | 07:43 |
| sarnold | _val_: http://manpages.ubuntu.com/manpages/trusty/en/man1/backportpackage.1.html | 07:46 |
| sarnold | _val_: I'm thinking here, you create a launchpad account, create a ppa that can build for trusty, and then run something like 'backportpackage -u ppa:val/ppa open-vm-tools' --- if the package is 'easy' to rebuild on trusty, then launchpad should build it for you | 07:47 |
| sarnold | _val_: of course there's always the chance that too much has changed and the build won't Just Work | 07:47 |
| sarnold | _val_: doing 'clean' local builds is enough of a pain that if you can get launchpad to do it for you it's probably worth the trouble of creating an account :) | 07:48 |
| ricotz | sarnold, pbuilder-dist is not hard to use ;) | 07:49 |
| _val_ | sarnold: thanks for the link. Having a loop there | 07:52 |
| _val_ | s/loop/look | 07:52 |
| === zyga_ is now known as zyga | ||
| apw | we have two cases where (we think) update-manager asked apt-daemon to install linux-image-4.4.0-77-generic and linux-signed-4.4.0-77-generic directly ... leading to a broken machine | 10:15 |
| juliank | apw: That leads me to the idea that maybe we should have metadata indicating purely-automatic packages, that is, stuff you normally should not install manually. | 11:42 |
| apw | juliank, it would be nice to be able to say, really this is not a package you want to install ever | 11:43 |
| apw | (we believe we have found teh cause of that behaviour and it is now understood0 | 11:44 |
| rbasak | How about an update-motd snippet that checks for known dodgy manually installed packages and warns you? | 11:45 |
| rbasak | "You have linux-XXX marked as manually installed, which may cause problems with automatic kernel updates" | 11:46 |
| rbasak | or just "which may cause problems with kernel updates" | 11:46 |
| rbasak | (as it'll happen even if not automatic) | 11:46 |
| infinity | rbasak: Wouldn't have done any good in this case, those packages were marked automatic. | 12:21 |
| infinity | (And, I'm not sure what good it would ever really do, except to annoy people who intentionally install a kernel manually to test things) | 12:21 |
| jbicha | rbasak: will you be doing zesty SRUs today? I'm interested in the GNOME 3.24.1 and gjs updates | 12:33 |
| rbasak | I'll try, but I'm not sure I'll manage it. I've got quite a bit at the top of my list which is mostly unblocking other people :-/ | 12:35 |
| jbicha | np, maybe someone will get to it by tomorrow then :) | 12:37 |
| rbasak | jbicha: is there anything I can help with that should be quick for me (easy and obvious, etc)? | 12:41 |
| jbicha | rbasak: I'm just interested in my zesty SRUs that have fully aged now | 12:43 |
| rbasak | Just Zesty? gnome-* and gjs? Does that include gnome-shell-extension-autohidetopbar? | 12:44 |
| jbicha | yes if you can, and mutter too | 12:45 |
| * rbasak is looking | 12:50 | |
| rbasak | jbicha: your detailed comments made it very easy for me. Thank you. Let me know if I missed anything. | 12:55 |
| rbasak | I'm not sure whether to recommend one way or the other, but breaking the updates down into multiple isolated bugs helped too in this case. Less lining up and checking of things needed. | 12:57 |
| jbicha | I probably should have split mutter & gnome-shell into separate bugs since they were actually independently upgradable this time | 13:02 |
| rbasak | Two I can keep in my head at once :-) | 13:02 |
| rbasak | bluesabre: around? About your lightdm-gtk-greeter merge. | 13:25 |
| rbasak | (else I'll review in the bug) | 13:25 |
| rbasak | fossfreedom: around? ^ | 13:52 |
| nacc | cpaelzer: i'm around if you want to debug your `usd tag` issue | 14:14 |
| cpaelzer | nacc: hiho | 14:15 |
| cpaelzer | nacc: so far I just dumped it to the bug to not forget | 14:16 |
| cpaelzer | I haven't checked anything in detail | 14:16 |
| nacc | cpaelzer: ok, it's starnge the other tags worked | 14:16 |
| nacc | it's a common code path | 14:16 |
| nacc | for all the tags, that is | 14:17 |
| cpaelzer | ok will do the local diff, just a sec | 14:17 |
| nacc | cpaelzer: which srcpkg? | 14:17 |
| nacc | cpaelzer: ah dovecot ok | 14:17 |
| cpaelzer | dovecot | 14:17 |
| cpaelzer | ha on ntp it worked | 14:17 |
| cpaelzer | I had assumed it would generally be broken | 14:18 |
| nacc | cpaelzer: yeah it's strange | 14:18 |
| nacc | cpaelzer: i've not seen that in a case where `git status` isn't also showing some output | 14:18 |
| nacc | cpaelzer: it's possibly pygit's status() is broken, but seems somewhat unlikely | 14:18 |
| nacc | cpaelzer: would need to see the output after the diff i suggested | 14:18 |
| nacc | and maybe also | 14:18 |
| nacc | print(self.local_repo.status()) in the same if | 14:19 |
| cpaelzer | the diff is broken, I'm repairing atm | 14:19 |
| cpaelzer | (no run there) | 14:19 |
| nacc | cpaelzer: shot | 14:20 |
| nacc | cpaelzer: from usd.run import run at the top | 14:20 |
| cpaelzer | sure already there | 14:20 |
| nacc | cpaelzer: sorry about that | 14:22 |
| cpaelzer | nacc: the status command is still considering it clean | 14:23 |
| cpaelzer | nacc: the local_repo.status output is new to me maybe you read it faster | 14:23 |
| cpaelzer | nacc: I updated the bug | 14:23 |
| nacc | cpaelzer: thanks | 14:23 |
| cpaelzer | nacc: http://paste.ubuntu.com/24505508/ for here | 14:24 |
| nacc | cpaelzer: http://www.pygit2.org/working-copy.html#status | 14:25 |
| nacc | cpaelzer: what does `git status --ignored` say? :) | 14:29 |
| nacc | cpaelzer: per libgit2 src 2^14 is GIT_STATUS_IGNORED | 14:29 |
| nacc | cpaelzer: did the new upstream add a .gitignore by any chance? | 14:30 |
| cpaelzer | nacc: git status --ignored is also clean and there is no .gitignore in the current branch (merge-artful) | 14:49 |
| nacc | cpaelzer: well, the local_repo.status() says those files are ignored | 14:53 |
| nacc | cpaelzer: not sure why | 14:53 |
| cpaelzer | nacc: that merge has a MP, can you clone the MP and reproduce on that? | 14:53 |
| nacc | cpaelzer: sure | 14:54 |
| nacc | cpaelzer: i don't get an error | 14:57 |
| cpaelzer | hrm very interesting nacc | 14:58 |
| cpaelzer | nacc: did you commit anything to usd the last 48 hours that might be related | 14:58 |
| cpaelzer | I haven't updated since then | 14:59 |
| nacc | cpaelzer: not that i know of? | 15:05 |
| xnox | cjwatson, i am preparing sru to fix https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1686618 in zesty only. Whilst it is in sync with Debian at the moment, and this code path is affected in Debian too, it is not as severe. | 15:30 |
| ubottu | Launchpad bug 1686618 in openssh (Ubuntu Zesty) "ssh connection attempts fail if hw crypto support on s390x is enabled on 17.04" [High,Triaged] | 15:30 |
| xnox | because debian does not ship the necessory userspace component to enable hw crypto support (openssl-ibmca is not packaged there yet) | 15:30 |
| xnox | hence in practice it's much harder to fall into that trap there. | 15:30 |
| xnox | it's just two small upstream cherry-picks. | 15:30 |
| xnox | already part of 7.5 in experimental. | 15:31 |
| xnox | (and artful) | 15:31 |
| cjwatson | xnox: sure, go ahead | 15:34 |
| cjwatson | xnox: IIRC the seccomp sandbox was refactored between 7.4 and 7.5, in which case you'll have to be careful to get the cherry-picks right | 15:35 |
| xnox | cjwatson, tah. | 15:38 |
| cjwatson | (but if that's the case it'll be obvious due to conflicts) | 15:38 |
| xnox | looks like my cherry-picks are before the refactor that got rid of macros substituition; but i think i will need the missing header zcrypt now. | 15:45 |
| rbasak | nacc: thank you for "usd build-source --for-merge". Nice :) | 16:32 |
| rbasak | We might want -sa in a few other cases. Like an Ubuntu-native native package perhaps. | 16:33 |
| rbasak | Uh | 16:33 |
| rbasak | An Ubuntu-native non-native package? | 16:33 |
| rbasak | Though perhaps I should have an orig locally in that case. | 16:33 |
| nacc | rbasak: yeah there are probably a few other cases to consider | 16:47 |
| juliank | xnox: I want to release apt 1.4.2 soon (today/tomorrow), and I think I'll go with my locking in the script idea. | 17:10 |
| xnox | juliank, i have tested it out, it does work as intended. | 17:12 |
| xnox | juliank, we may need more indicators as to what is happening though in the future =) | 17:12 |
| xnox | on boot i opened terminal and typed apt-get update, and got bamboozled why everything is locked, only to realise that apt-daily[-upgrade] are running =) | 17:12 |
| * xnox ponders if we need desktop notifications, and/or command line notications | 17:13 | |
| xnox | apt database locked by: | 17:13 |
| xnox | automated daily-ugprade | 17:13 |
| xnox | user foobar | 17:13 |
| xnox | whatnot | 17:13 |
| juliank | xnox: Ah, yes. We need to look who locked the database | 17:13 |
| xnox | to be honest, non-root messages from apt are ugly and look like debug messages | 17:13 |
| xnox | not able to lock /var/lib/apt/foo/bar/something/rather/lists is a pointless message | 17:14 |
| juliank | Yes, but if it says: | 17:14 |
| juliank | Not able to lock lists directory: Already in used by .... | 17:14 |
| juliank | or something, that might be better | 17:14 |
| xnox | Error: Lacking priviledges to access apt directories. Are you root? use -v to see debug messages | 17:15 |
| juliank | We do actually want to have the path somewhere, in case you use different options | 17:15 |
| xnox | Error: Unable to lock apt database. Already in use by: apt-daily.service | 17:15 |
| juliank | But that can be N | 17:15 |
| juliank | (notice) | 17:15 |
| xnox | imho those paths should be hidden by default, it's way too debuging | 17:15 |
| xnox | imho those paths should be hidden by default, it's way too debuggy | 17:15 |
| juliank | I don't really disagree | 17:16 |
| juliank | The question is how to get a descriptive string for the lock | 17:16 |
| xnox | >_< o_O ah | 17:16 |
| juliank | s/the lock/the entity holding the lock/ | 17:16 |
| xnox | well, i would say apt by default should wait for the lock, and print who is using the lock, with a timeout. | 17:17 |
| xnox | but that is a nasty change of behaviour. | 17:17 |
| juliank | Waiting is nice for apt | 17:17 |
| xnox | because people expect apt to be non-blocking on locks. | 17:17 |
| juliank | not good for apt-get | 17:17 |
| xnox | yeah | 17:17 |
| juliank | There's some issue figuring out who holds the lock though | 17:18 |
| xnox | twats like me expect apt to be human friendly, and apt-get have nasty barking on stderr of cryptic paths. | 17:18 |
| juliank | You could display the cgroup, that gets you reasonably far for the timers | 17:18 |
| xnox | juliank, well we our selfs should leave hints as to what is holding locks. | 17:18 |
| xnox | or yeah, do smart inspections like that. | 17:18 |
| juliank | But that needs more locking or is (a bit) racy. | 17:18 |
| xnox | hints do not need to be accurate or with locking | 17:19 |
| juliank | So, if we acquire the lock, just leave a message in the lock file. | 17:19 |
| xnox | i do not know who, but somebody is holding a lock, is the status quo. With better wording alone it will be better. | 17:19 |
| juliank | If other clients are waiting, there might be a race if they get processed in order, but that's not terribly problematic | 17:20 |
| xnox | well you want to leave a structured message in the lock file, because i18n | 17:20 |
| juliank | Oh, we can also leave the pid in there and then just check against the pid that really locked the file (which we can get via fcntl) | 17:24 |
| hjd | Hi all :) I see that http://qa.ubuntuwire.org/ftbfs/ still lists Zesty build failures. When can I expect it (and semi-related pages) to start displaying artful issues? | 17:25 |
| juliank | And a fancy countdown maybe | 17:25 |
| juliank | Waiting for lock. Cancelling in <...> seconds. Press Ctrl+C to cancel now. | 17:25 |
| xnox | hjd, i guess wgrant might adjust that ubuntuwire page for artful? Or maybe somehow magically make it work against $devel ? | 17:28 |
| xnox | please =) | 17:28 |
| * wgrant does so | 17:29 | |
| wgrant | Sorry, been busy lately | 17:29 |
| hjd | wgrant: cool, thank you :) (you're probably aware, but the http://qa.ubuntuwire.org/multidistrotools/ tables also compares with zesty) | 17:35 |
| wgrant | Yep,working on that | 17:35 |
| wgrant | xnox, hjd: Should all be artful now | 17:45 |
| xnox | wgrant, so artsy =) | 17:47 |
| hjd | nice :) | 17:50 |
| === JanC is now known as Guest52042 | ||
| === JanC_ is now known as JanC | ||
| cousin_luigi | Greetings. | 18:54 |
| jamespage | anyone give me a clue why python-amqp is stuck in proposed? | 20:07 |
| jamespage | http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-amqp | 20:07 |
| jamespage | vine seems installable to me at least | 20:07 |
| ginggs | jamespage: python-amqp is in main, vine is not | 20:11 |
| jamespage | ginggs: ah yes | 20:19 |
| jamespage | that was kinda obvious now you point to it | 20:20 |
| Unit193 | ginggs: I don't suppose you'll do an upload to fix #1680943? | 20:38 |
| ginggs | i will if someone tests the version in my ppa | 20:40 |
| Unit193 | Oh, you never got feedback? Hrm. I did, it works. | 20:44 |
| Unit193 | ginggs: There ya're. | 21:12 |
| ginggs | Unit193: thanks, but what is wrong with just putting 'QT_QPA_PLATFORMTHEME= telegram-desktop' in telegramdesktop.desktop ? | 21:16 |
| ginggs | the user, that is, as a workaround | 21:17 |
| Unit193 | ginggs: It'd work, sure. Just doesn't work to launch it from the terminal without unsetting the var first. And of course, as all workarounds, not ideal. That is to say, package updates will either overwrite it, or if you place it in ~/.local/ then updates to the desktop file aren't taken into account. | 21:18 |
| Unit193 | Also since you applied that patch, I figured I'd just address that. | 21:19 |
| ginggs | Unit193: I take it you actually want this in Zesty? | 21:37 |
| bluesabre | rbasak: hello! | 21:43 |
| === sgclark_sleeping is now known as sgclark | ||
| Unit193 | ginggs: But I'm fine PPA'ing the backport. | 22:48 |
| ginggs | Unit193: if you take care of the SRU process, I'll upload to artful and sponsor your SRU to zesty | 22:50 |
| Unit193 | ginggs: Ah sorry, I got to doing something. Eh, I think going forward is fine. As long as the fix is in, then people can use a workaround until they get it. | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!