| === ebarretto_ is now known as ebarretto | ||
| === blue_penquin_ is now known as blue_penquin | ||
| DarkTrick | **Q**: What is a good way to migrate application settings from gconf to dconf? | 04:42 |
|---|---|---|
| DarkTrick | One specific problem: Ubuntu had a mapping layer for gconf-access, but it seems like the mapping differs between ubuntu versions. How do I tackle that? | 04:43 |
| utkarsh2102 | hello, is there a way to get udebs from a PPA? | 08:05 |
| utkarsh2102 | I tried using pull-ppa-udebs -a i386 --ppa utkarsh/multipath-tools-disable-fexceptions multipath-tools but that says no udebs found there, which probably means they're not built there in the first place? | 08:06 |
| utkarsh2102 | is there a way to ensure that udebs are built in a PPA? | 08:06 |
| xnox | utkarsh2102: for which release? | 08:55 |
| utkarsh2102 | xnox: impish | 08:58 |
| xnox | utkarsh2102: all ppa's inherit allow/block-lists of packages to build from the parent ubuntu distribution. by default impish does not build udebs. If you want to build udebs for multipath-tools in your ppa, you need to change debian/rules to export DEB_BUILD_PROFILES=!noudeb | 09:23 |
| xnox | see mentions about this in dpkg uploads | 09:23 |
| xnox | utkarsh2102: but note that this will still not quite result in having i386 d-i working at all..... may i ask what are you trying to achieve? cause for you to run i386 multipath-tools udeb i would expect you to rebuild it in a release that at least has i386 debian-installer.... like bionic | 09:24 |
| utkarsh2102 | xnox: the ultimate goal that we have is to drop the delta that we've been carrying; this one: https://git.launchpad.net/~utkarsh/ubuntu/+source/multipath-tools/commit/?h=merge-multipath-tools-impish&id=920df384351ddc43bdef435643c47d5742537360. | 09:28 |
| ubottu | Commit 920df38 in ~utkarsh/ubuntu/+source/multipath-tools "- Disable -fexceptions on multipath-udeb (LP 1489379): the flag causes" | 09:28 |
| utkarsh2102 | so to check that we wanted a udeb to test on. I'll use ppc64el instead of i386, thanks, again! | 09:28 |
| xnox | utkarsh2102: we do not make udebs in impish. | 09:31 |
| xnox | utkarsh2102: you should not be testing any udebs from impish =) | 09:31 |
| xnox | utkarsh2102: you can drop any delta that applies to udeb builds only..... since we don't build udebs anymore | 09:32 |
| utkarsh2102 | xnox: aah! gotcha! that is perfect :) | 09:32 |
| utkarsh2102 | cpaelzer^^ \o/ | 09:32 |
| xnox | utkarsh2102: we do not have d-i anymore.... | 09:33 |
| cpaelzer | xnox: legacy images stopped after focal right? | 09:35 |
| cpaelzer | or are they just better hidden and still needed? | 09:35 |
| xnox | cpaelzer: we have not built legacy images since 20.04.1. Even .2 release does not have them.... | 09:35 |
| cpaelzer | yep, ok that is what I see on the cdimage pages | 09:35 |
| xnox | cpaelzer: checkout rmadison and note the lack of multipath udebs being built or produced..... | 09:35 |
| cpaelzer | xnox: well, that for eample still existed in groovy | 09:36 |
| xnox | but not in hirsute, nor impish. | 09:37 |
| cpaelzer | which confuses a bit, but probably only as carry over from focal | 09:37 |
| xnox | it took us some time to remove them all properly. | 09:37 |
| cpaelzer | indeed | 09:37 |
| cpaelzer | thanks for the hints xnox | 09:37 |
| xnox | but since the .udeb is not there for two releases now, it is gone =) | 09:37 |
| cpaelzer | once = accident, twice = gone :-P | 09:37 |
| utkarsh2102 | indeed, multipath-udeb was last seen in groovy | 09:39 |
| utkarsh2102 | multipath-udeb | 0.8.4-4ubuntu2 | groovy/universe/debian-installer | 09:39 |
| utkarsh2102 | time to say bye-bye o/ | 09:39 |
| utkarsh2102 | thanks, xnox! | 09:39 |
| === sil2100_ is now known as sil2100 | ||
| LocutusOfBorg | hello, anybody wants to discuss a glibc change for the syslog function? | 12:59 |
| LocutusOfBorg | I have a process reading /dev/log, but what happens, if the process reading it, stops or crashes for whatever reason, the whole system becomes stuck because syslog becomes blocking when the queue is full | 12:59 |
| LocutusOfBorg | I changed the syslog glibc socket to NONBLOCK and I fixed the issue | 12:59 |
| LocutusOfBorg | I would like to discuss it with some glibc-savvy people | 13:00 |
| smoser | bdmurray: any chance that you could take a look at bug 1923232 today? just wondering what further is expected to mark it as 'verification-done'. I'd do it, but I don't want to step on toes. | 15:07 |
| ubottu | Bug 1923232 in lxc (Ubuntu Focal) "SRU of LXC 4.0.6 to focal (upstream bugfix release)" [High, Fix Committed] https://launchpad.net/bugs/1923232 | 15:07 |
| xnox | LocutusOfBorg: why do you think /dev/log has anything to do with glibc? =) | 15:43 |
| xnox | LocutusOfBorg: | 15:43 |
| xnox | $ ls -latr /dev/log | 15:43 |
| xnox | lrwxrwxrwx 1 root root 28 Jun 21 09:42 /dev/log -> /run/systemd/journal/dev-log | 15:43 |
| xnox | normally it is expected for it to be a blocking one, as otherwise you might loose log messages with is dataloss. It is expected to fill up, until something processes / forwards / stores all the messages. | 15:45 |
| xnox | on regular ubuntu system, that is systemd-journald, which in-turn forwards things to a classic syslog daemon, which then in default configuration stores things on disk. | 15:46 |
| xnox | if on the other hand /dev/log became non-blocking, it would appear that lots of services are writting logs to syslog.... and yet they go missing and get dropped on the floor. | 15:46 |
| xnox | LocutusOfBorg: so lets go to the beginning. why are you reading /dev/log directly? one should instead read `journalctl -f` or syslog | 15:47 |
| xnox | LocutusOfBorg: are you writing a syslog daemon (aka something that is drop in replacement for journald / syslog / syslog-ng) in that case you must adhere to the expectations of handling all messages correctly. not dropping them on the floor. and storing them. If need be, mark yourself to autorespawn on crashes & have a heartbeat to be restarted when getting "stuck". | 15:48 |
| LocutusOfBorg | xnox, where did I mention Ubuntu? XD | 16:20 |
| LocutusOfBorg | I'm doing a thing, an embedded system, with systemV and dev/log being read by a dlt-system daemon (dlt is a common logging system used in automotive industry) | 16:21 |
| LocutusOfBorg | problem is that if you fill up the /dev/log, even the init system gets stuck on the first write to syslog | 16:21 |
| LocutusOfBorg | so you can't reboot, launch scripts, log anything, the board is just stuck, for all processes doing a write to syslog | 16:21 |
| LocutusOfBorg | also journald,syslog,syslog-ng might one day have a bug with a deadlock, or something similar preventing the queue from being empty | 16:22 |
| LocutusOfBorg | I'm not alone btw https://www.endpoint.com/blog/2013/08/22/log-jam-be-careful-with-local-syslog | 16:25 |
| LocutusOfBorg | this happens when you redirect syslog into a slower device | 16:25 |
| LocutusOfBorg | https://lists.balabit.hu/pipermail/syslog-ng/2005-June/007588.html | 16:26 |
| xnox | LocutusOfBorg: where is `dlt-system daemon`? can you point me at it to read sources of that? | 16:45 |
| xnox | LocutusOfBorg: if your log daemon is crap, then yes your system is as reliable as that. Also note that good inits have protections against log jam, i.e. systemd does not fallover when journald stops responding. And there is a lot of failsafe built into journald with handling disks going readonly MIA etc. | 16:46 |
| xnox | LocutusOfBorg: also you say "systemV" ..... but which implementation in particular do you mean? there is about half a dozen of things that are "systemV" | 16:46 |
| xnox | some are better than others. | 16:47 |
| xnox | LocutusOfBorg: there are good implementations of inits & logging daemons that do not suffer from cloging up /dev/log. I'm not sure glibc upstream would be open of making it less reliable, in the common cases, for most systems, to accomodate less resilient implementations. | 16:48 |
| xnox | LocutusOfBorg: what you might find, is that lots of applications expect logging to be blocking; and if you change it to nonblocking lots of apps will start failing. | 16:51 |
| xnox | and assumptions about using Ubuntu is because this is #ubuntu-devel =) | 16:51 |
| xnox | not #glibc-devel | 16:51 |
| xnox | LocutusOfBorg: so you move bug from one place, to many new places. | 16:52 |
| xnox | make your init & logging daemon more reliable, and fix bugs in them. | 16:52 |
| xnox | laney: Libarchive 3.4.3 had many zstd improvements. I wonder if we it makes sense to rebuild the snap with libarchive 3.4.3 backport to focal and check if that "fixes everything" | 17:15 |
| xnox | laney: in launchpad there is a way to force using newer series too, on the snap via api one can set it to "please build it in hirsute" | 17:16 |
| laney | xnox: it's probably easiest for you to fork it and play with changes yourself | 17:23 |
| bdmurray | smoser: I'm just testing an upgrade from F to G given that 4.0.6 isn't in Groovy | 17:24 |
| smoser | bdmurray: thank you. | 17:25 |
| === lucas_ is now known as lucascastro | ||
| seb128 | LocutusOfBorg, hum, what was the point of that poppler sync? there is 0 change outside the debian/cjhangelog and it was on a revision that would autosync, also I did a new version upload today that is actually worth syncing and that I was going to sync once it's published... | 19:01 |
| diddledan | doko, I see you're listed as contact for openjdk-16 packages - it looks like focal builds have only been published for amd64 and i386, with all other architectures unaccounted for. I'm not sure where to look to find out whether the builds weren't attempted at all or have failed in some way - the PPA seemingly has the packages in question so something has gone awry in publishing to universe | 21:53 |
| diddledan | e.g. https://packages.ubuntu.com/focal/openjdk-16-jdk-headless | 21:54 |
| cjwatson | diddledan: Or packages.ubuntu.com is just wrong. | 22:53 |
| cjwatson | openjdk-16-jdk-headless | 16.0.1+9-1~20.04 | focal-updates/universe | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x | 22:53 |
| cjwatson | (rmadison openjdk-16-jdk-headless) | 22:53 |
| diddledan | odd | 22:53 |
| cjwatson | amd64 and i386 are the two architectures on archive.ubuntu.com (as opposed to ports.ubuntu.com), so maybe it's something to do with that | 22:54 |
| cjwatson | IDK; packages.u.c is maintained by a community member | 22:54 |
| cjwatson | Oh actually, try https://packages.ubuntu.com/focal-updates/openjdk-16-jdk-headless | 22:54 |
| cjwatson | packages.u.c's view here is very confusing. openjdk-16-jdk-headless isn't actually in the "focal" suite in terms of the archive at all; it's in focal-security and focal-updates | 22:55 |
| diddledan | I've been talking with someone in snapcrafters about a build failure they hit with seemingly unable to find non-x86 builds of the package | 22:55 |
| cjwatson | so I guess it must be looking at security.u.c and merging that into focal somehow ... | 22:56 |
| cjwatson | Anyway packages.u.c is probably a red herring for whatever you're investigating | 22:56 |
| cjwatson | Link to the build failure? | 22:56 |
| diddledan | https://launchpadlibrarian.net/544874175/buildlog_snap_ubuntu_focal_amd64_snapcraft-gradle-4ee03a_BUILDING.txt.gz | 22:58 |
| cjwatson | And that's on amd64 | 22:58 |
| cjwatson | The error there doesn't seem to be anything to do with not finding openjdk-16-jdk-headless? | 22:59 |
| cjwatson | + rm /build/snapcraft-gradle-4ee03a/parts/java/install/usr/lib/jvm/default-java/lib/security/cacerts | 22:59 |
| cjwatson | rm: cannot remove '/build/snapcraft-gradle-4ee03a/parts/java/install/usr/lib/jvm/default-java/lib/security/cacerts': No such file or directory | 22:59 |
| diddledan | yeah, I think they gave me the wrong log :-) | 22:59 |
| diddledan | aha, they've just updated me - they made a wrong assumption based on package.u.c not showing the arches | 23:00 |
| cjwatson | Right :) | 23:00 |
| diddledan | thanks for helping :-) | 23:01 |
| cjwatson | Unfortunately with snapcraft remote-build working the way it does I can't currently guess the build log URL for other architectures even given buildd-manager logs ... | 23:01 |
| cjwatson | I was going to suggest reporting a bug on packages.u.c, but I think this might be https://bugs.launchpad.net/pkg-website/+bug/1866833? | 23:02 |
| ubottu | Launchpad bug 1866833 in pkg-website "Looks like ports-security is not updated" [Undecided, New] | 23:02 |
| diddledan | yeah, finding the logs is a bit of a pain - even when you have access via snapcraft.io's build service they're not immediately sharable without inspecting the page to find the underlying frame's url | 23:02 |
| cjwatson | Slightly different manifestation but it's probably the same cause | 23:02 |
| diddledan | yeah that looks similar | 23:03 |
| cjwatson | I can't find the code/config to investigate | 23:06 |
| cjwatson | Suspect it needs Rhonda to dig | 23:07 |
| cjwatson | https://packages.ubuntu.com/about/ is very outdated and even correcting for the current git location of upstream webwml there's no "ubuntu-master" branch there | 23:08 |
| diddledan | https://salsa.debian.org/webmaster-team/packages/-/tree/ubuntu-master | 23:10 |
| cjwatson | Oh maybe ... just found that | 23:10 |
| cjwatson | By gratuitous guesswork in salsa :) | 23:11 |
| cjwatson | I think wrapping my brain round this is more than I can manage at this time of night though, good luck ... night | 23:12 |
| diddledan | nn | 23:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!