| LeePen | I have just pushed a new version of cups-filters to git@git.devuan.org:LeePen/cups-filters.git with a much better Devuan test page provided by golinux. | 10:54 |
|---|---|---|
| amesser | hi LeePen | 10:57 |
| KatolaZ | hi LeePen | 10:57 |
| amesser | LeePen, regarding the tag naming, the point here is, that when we import the upstream into the devuian package repo, the upstream tags <tagname> will not import as upstream/<tagname> but just as <tagname>. Maybe there is an git option which can be used to automate this | 10:59 |
| KatolaZ | amesser: it's in gbp.conf | 11:04 |
| amesser | no, i mean you have to make "git fetch" to import upstream tags as "upstream/<tagname>" and not "<tagname>". Otherwise one has to do it manually | 11:05 |
| amesser | i think it is possible, need to manually edit .git/config | 11:06 |
| KatolaZ | amesser: you just need to fetch the tag and tag the upstream branch | 11:06 |
| KatolaZ | then you specify how the upstream branch is tagged in debian/gbp.conf | 11:07 |
| KatolaZ | no need to re-tag | 11:07 |
| amesser | hmm | 11:07 |
| KatolaZ | just use "upstream-branch= v(%version)s | 11:07 |
| KatolaZ | in gbp.conf | 11:07 |
| amesser | yep, i know | 11:07 |
| KatolaZ | (that's just an example) | 11:07 |
| KatolaZ | (if I have got your point correctly) | 11:08 |
| amesser | not really :-) | 11:09 |
| KatolaZ | :D | 11:09 |
| KatolaZ | sorry then :) | 11:09 |
| amesser | I would like to see the following tag structure for the git repo: | 11:09 |
| amesser | "devuan/<package-version>" for devuan package tags | 11:09 |
| amesser | and "upstream/<upstream tag name>" for the upstream source tags | 11:10 |
| KatolaZ | amesser: there is no policy about that | 11:10 |
| KatolaZ | not even in Debian :) | 11:10 |
| amesser | yep, but i like structure :-) | 11:10 |
| KatolaZ | :D | 11:10 |
| amesser | i have found debian package where it is the same :-) | 11:10 |
| amesser | in binutils you have it like that | 11:10 |
| KatolaZ | yeah, but I have found tons of debian packages where this is not the case | 11:10 |
| KatolaZ | and you have all sorts of tag structures | 11:11 |
| amesser | that is true | 11:11 |
| KatolaZ | the most common is version-debversion for debian packages | 11:11 |
| KatolaZ | and just "version" for upstream | 11:11 |
| KatolaZ | or "v$version" for upstream | 11:11 |
| amesser | yes, because it is the easiest way | 11:11 |
| KatolaZ | it's more because you just don't retag from upstream | 11:11 |
| KatolaZ | (meaning that you don't need to do that) | 11:12 |
| amesser | the point here is, when upstream is added as a remote to the local copy of the repo, then when you fetch the latest stuff from upstream, the tags are automatically imported just with there names | 11:12 |
| amesser | and this is simple, but i'm afraid about conflicts | 11:13 |
| KatolaZ | there cannot be conflicts | 11:14 |
| KatolaZ | since debian packages are tagged with version-debversion | 11:14 |
| amesser | i mean when upstream in future decides to use a naming - scheme similar to debian versions, well it will become a mess in the package repo | 11:14 |
| KatolaZ | devuan ones are tagged with version-deb-version+devuan-version | 11:14 |
| KatolaZ | it can't | 11:14 |
| amesser | yep | 11:14 |
| KatolaZ | :) | 11:14 |
| KatolaZ | I mean it can't become a mess | 11:15 |
| KatolaZ | if it happens, you start retaggin for that particular package | 11:15 |
| KatolaZ | IMHO | 11:15 |
| amesser | anyway, its not a critical point. but since i'm a physicist, i like structure and symmetry :-) | 11:16 |
| amesser | the elogind packaging from leepen looks very good already. | 11:16 |
| KatolaZ | amesser: I asked him to liaise with you and the other guys who have been working on it | 11:17 |
| KatolaZ | him=LeePen | 11:17 |
| amesser | I'm planning to merge his changes to "master" branch when he's ready and then create the "suites/unstable" from it | 11:17 |
| KatolaZ | ok | 11:17 |
| KatolaZ | great | 11:17 |
| KatolaZ | :) | 11:17 |
| amesser | Unfortunately, next two eekends are full with family meeting, this year is really horrible regarding spare time for Devuan. Nevertheless i'll setup a VM for beowulf | 11:18 |
| KatolaZ | don't mention it amesser, please :D | 11:18 |
| KatolaZ | just don't mention time | 11:19 |
| KatolaZ | (let alone "spare"...) | 11:19 |
| amesser | next week or so, this is just "unstable" suite from deb.devuan.org? | 11:19 |
| KatolaZ | uh? | 11:19 |
| KatolaZ | beowulf is beowulf | 11:19 |
| KatolaZ | (i.e., corresponding to testing) | 11:19 |
| KatolaZ | unstable is ceres | 11:19 |
| amesser | sorry, always messing up the code names :-) | 11:20 |
| KatolaZ | heheheh | 11:20 |
| amesser | so then ceres | 11:20 |
| KatolaZ | yeah | 11:20 |
| KatolaZ | I will be working on d-i components in the next few days | 11:21 |
| KatolaZ | to build an installer for beowulf | 11:21 |
| amesser | ok | 11:21 |
| KatolaZ | and ease the path for people willing to help with ceres | 11:21 |
| KatolaZ | (who could just dist-upgrade form a beowulf image) | 11:21 |
| amesser | that would be nice. currently can i use debbootstrap to install ceres? | 11:22 |
| KatolaZ | yes | 11:23 |
| KatolaZ | debootstrap has been fixed | 11:23 |
| amesser | fine | 11:24 |
| amesser | Besides that, i'm looking forward to receive my Libre M development kit from puri.sm. Libre M is an ARM 64 bit based mobile phone. I'll gona try to run Devuan on it | 11:27 |
| golinux | LeePen: Thanks for doing that! Those pages have been on hold for quite some time. | 16:47 |
| fsmithred | ping parazyd - can't upgrade eudev in ceres | 16:47 |
| KatolaZ | fsmithred: ? | 16:47 |
| KatolaZ | fsmithred: what do you mean? | 16:48 |
| fsmithred | error message says I need a kernel with certain features | 16:48 |
| KatolaZ | o_O | 16:48 |
| fsmithred | and the running kernel already has those features | 16:48 |
| KatolaZ | which kernel do you have? | 16:48 |
| fsmithred | 4.18.0-2 | 16:48 |
| fsmithred | can't find anything newer than that | 16:49 |
| KatolaZ | which version are you trying to upgrade to? | 16:49 |
| KatolaZ | maybe that's the problem | 16:49 |
| fsmithred | 3.2.5-1 | 16:49 |
| fsmithred | State: installed (3.2.2-13), upgrade available (3.2.5-1) | 16:49 |
| KatolaZ | 3.2.5 works well with the ascii kernel | 16:49 |
| fsmithred | AT YOUR OWN RISK, you can force the installation of this version of udev | 16:50 |
| fsmithred | WHICH DOES NOT WORK WITH YOUR RUNNING KERNEL AND WILL BREAK YOUR SYSTEM | 16:50 |
| fsmithred | AT THE NEXT REBOOT by creating the /etc/udev/kernel-upgrade file. | 16:50 |
| fsmithred | There is always a safer way to upgrade, do not try this unless you | 16:50 |
| fsmithred | understand what you are doing! | 16:50 |
| KatolaZ | I am upgrading the ceres kernel to 4.18.2 now | 16:50 |
| KatolaZ | fsmithred: does it says which symbol is missing? ( | 16:53 |
| KatolaZ | (it's the preinst script) | 16:53 |
| fsmithred | yeah, I'm looking at the script | 16:54 |
| fsmithred | no message about symbols, just kernel configs | 16:54 |
| KatolaZ | yeah, I mean config | 16:54 |
| fsmithred | looks like preinst is set to reject anything less that 2.6 kernel | 16:54 |
| fsmithred | - inotify(2) (CONFIG_INOTIFY_USER) | 16:54 |
| fsmithred | - signalfd(2) (CONFIG_SIGNALFD) | 16:54 |
| fsmithred | - accept4(2) | 16:54 |
| fsmithred | - open_by_handle_at(2) (CONFIG_FHANDLE) | 16:54 |
| fsmithred | - timerfd_create(2) (CONFIG_TIMERFD) | 16:54 |
| fsmithred | - epoll_create(2) (CONFIG_EPOLL) | 16:54 |
| KatolaZ | yep | 16:55 |
| fsmithred | every one of those CONFIGs is a =y | 16:55 |
| KatolaZ | it's working fine after reboot with the 4.18.0-2 kernel | 16:55 |
| fsmithred | not here. Is dbus required for this? | 16:56 |
| KatolaZ | now if I try to reinstall it it bails out | 16:56 |
| KatolaZ | (reinstall eudev) | 16:56 |
| KatolaZ | I don't have dbus | 16:56 |
| KatolaZ | (minimal testing image) | 16:56 |
| fsmithred | ok, so mine should be ok, too | 16:57 |
| fsmithred | I tried adding set -x to preinst but I didn't get any more output | 16:57 |
| KatolaZ | yeah I guess oyu should be OK | 16:57 |
| KatolaZ | but we should find which check fails | 16:57 |
| fsmithred | check_kernel_features() has that message | 16:58 |
| fsmithred | [ -e /etc/udev/kernel-upgrade ] && return 0 | 16:58 |
| fsmithred | that looks like a way to bypass it. The message suggested creating that file... | 16:59 |
| fsmithred | only if I know what I'm doing | 16:59 |
| KatolaZ | it's the check | 17:00 |
| KatolaZ | nono | 17:00 |
| KatolaZ | it's the check on symbols | 17:00 |
| KatolaZ | on needed_symbols | 17:00 |
| fsmithred | egrep -q "^[a-fA-F0-9]+ T \.?sys_${symbol}$" /proc/kallsyms | 17:01 |
| fsmithred | oh, duh | 17:01 |
| KatolaZ | yep | 17:01 |
| KatolaZ | if you try that one, it fails on the 4.18.0-2 | 17:01 |
| fsmithred | I tried that, but I forgot to define $symbols | 17:02 |
| KatolaZ | try with inotify_init instead of ${symbol} | 17:02 |
| fsmithred | nothing | 17:03 |
| KatolaZ | yep | 17:03 |
| KatolaZ | the check does not work | 17:03 |
| KatolaZ | 'cause the symbols are called differently, I guess | 17:03 |
| KatolaZ | now they seem to be separate by arch | 17:04 |
| KatolaZ | fsmithred: | 17:04 |
| KatolaZ | there are __x86_sys_inotify_init | 17:04 |
| fsmithred | what do you mean? | 17:04 |
| KatolaZ | that the symbol name has changed | 17:05 |
| KatolaZ | fsmithred: look for sys_inotify_init | 17:05 |
| fsmithred | yeah, I have a whole list of them I grepped | 17:05 |
| KatolaZ | fsmithred: you should only consider the entried with a leading "T " | 17:06 |
| fsmithred | how do you find the new names? | 17:06 |
| KatolaZ | s/entried/entries | 17:06 |
| fsmithred | x64 and ia32 | 17:06 |
| KatolaZ | yep | 17:06 |
| fsmithred | should x64 be amd64? | 17:06 |
| KatolaZ | nope | 17:06 |
| KatolaZ | the kernel has always used x64 | 17:07 |
| KatolaZ | (the support was ready before the actual amd64 spec came out :D) | 17:07 |
| fsmithred | not surprised | 17:07 |
| KatolaZ | linux was the first kernel ever to support amd64 | 17:07 |
| KatolaZ | the software was ready before the hardware was available for sale | 17:07 |
| KatolaZ | :D | 17:07 |
| fsmithred | wow | 17:08 |
| KatolaZ | fsmithred: I will have a look at the latest eudev upstream | 17:12 |
| KatolaZ | but I guess we could just amend the check to reflect the new names | 17:13 |
| KatolaZ | we should just be sure that the change is consistent across architectures | 17:13 |
| KatolaZ | fsmithred: I think I have a fix | 17:52 |
| fsmithred | cool | 17:53 |
| KatolaZ | fsmithred: building now | 17:57 |
| KatolaZ | fsmithred: will try to build it later | 18:02 |
| KatolaZ | there is currently a breakage in sid in libglib-object-introspection-perl | 18:03 |
| fsmithred | ok | 18:03 |
| fsmithred | I'm busy with other stuff anyway. Let me know when to try again. | 18:03 |
| KatolaZ | oki | 18:04 |
| KatolaZ | the fix is pretty straightforward, and works on previous kernel versions as well | 18:04 |
| fsmithred | I'm confused by the regex | 18:04 |
| KatolaZ | why? | 18:04 |
| fsmithred | the \.? | 18:04 |
| fsmithred | \.?sys_${symbol}$" | 18:05 |
| KatolaZ | the new one is | 18:05 |
| fsmithred | escaping the dot means there must be a dot in the pattern? | 18:05 |
| KatolaZ | "^[a-fA-F0-9]+ T .*sys_${symbol}$" | 18:05 |
| KatolaZ | yes | 18:05 |
| fsmithred | dot means one char in that one? | 18:06 |
| KatolaZ | zero or more | 18:06 |
| fsmithred | * is zero or more | 18:06 |
| fsmithred | isn't .* one or more? | 18:06 |
| KatolaZ | nope | 18:06 |
| KatolaZ | it's not shell glob | 18:06 |
| KatolaZ | it's ERE | 18:07 |
| fsmithred | ok, I need to re-learn regex | 18:07 |
| KatolaZ | oh sorry, didn't mean that | 18:07 |
| Irrwahn | KatolaZ new version is quite lenient, but I suppose that's fine given the context it's used in | 18:09 |
| KatolaZ | yea Irrwahn | 18:09 |
| KatolaZ | the correct one would probably be | 18:09 |
| Irrwahn | you could presumably also go for sth like (__.+_)?${symbol}$ | 18:11 |
| KatolaZ | "^[a-fA-F0-9]+ T (__.*_)*sys_${symbol}$" | 18:11 |
| Irrwahn | Almost. :D | 18:11 |
| Irrwahn | + and ? would be a bit more restrictive compared to * | 18:11 |
| KatolaZ | Irrwahn: but we don't know what there can be before sys | 18:12 |
| Irrwahn | Yeah, that's true, I was merely making an educated guess. So your first, lenient version should be fine. :) | 18:13 |
| Irrwahn | "I once had a problem. I tried to solve it using regular expressions. Now I have two problems." | 18:14 |
| KatolaZ | Irrwahn: I think yours is actually better | 18:16 |
| Irrwahn | Well, mine narrows it down to an optional (__SOMETHING_) pattern preceding the ${symbol}, but we don't know if that's the only prefix pattern that may occur. | 18:18 |
| KatolaZ | we need to keep "sys_" nevertheless | 18:19 |
| KatolaZ | since all syscalls symbols will start with "sys_" | 18:19 |
| KatolaZ | or with "__ARCH_sys_" | 18:19 |
| Irrwahn | Err, yes, forgot that one | 18:20 |
| KatolaZ | mmmhhh | 18:20 |
| Irrwahn | So make it: "^[a-fA-F0-9]+ T (__.+_)?sys_${symbol}$" ??? | 18:20 |
| Irrwahn | Or even: "^[a-fA-F0-9]+ T (__[a-zA-Z0-9]+_)?sys_${symbol}$" ? | 18:21 |
| Irrwahn | As it'd be unlikely for an arch tag to be non-aplhanumeric. | 18:22 |
| KatolaZ | maybe the best is: "^[a-fA-F0-9]+ T (_+.*_)?sys_${symbol}$" | 18:22 |
| Irrwahn | Hm, another nice variation to the song. | 18:23 |
| KatolaZ | which matches any prefix to "sys" which starts with "__", has anything in between, and a "_" before sys | 18:23 |
| KatolaZ | (well, even something that starts with a single "_" would match | 18:24 |
| Irrwahn | yep, as long as we don't care it also matches __sys | 18:24 |
| KatolaZ | we shouldn't care I guess | 18:24 |
| Irrwahn | nope, would need at least two _, because of the + | 18:24 |
| KatolaZ | oh sure | 18:24 |
| KatolaZ | I have written a couple of them | 18:24 |
| KatolaZ | :D | 18:24 |
| Irrwahn | Right, lets not be too pedantic for a simple install time kernel symbol check. It won't trigger with any De(bi|vu)an stock kernel after all. | 18:25 |
| Irrwahn | BTW: why didn't I see it complain during debootstrap, but it triggers during a eudev reinstall? | 18:27 |
| fsmithred | I just tried (_+.*_)?sys_${symbol}$" and it failed again | 18:30 |
| KatolaZ | uh? | 18:31 |
| KatolaZ | I have tried it now | 18:31 |
| KatolaZ | "^[a-fA-F0-9]+ T (_+.*_)?sys_${symbol}$" | 18:31 |
| fsmithred | not working here | 18:34 |
| fsmithred | same error | 18:34 |
| KatolaZ | fsmithred: what are you trying exactly? | 18:34 |
| Irrwahn | WorksForMe[TM]: egrep "^[a-fA-F0-9]+ T (_+.*_)?sys_inotify_init$" /proc/kallsyms | 18:35 |
| fsmithred | I'm replacing that string in preinst and then trying to install libeudev1 and eudev again | 18:35 |
| KatolaZ | fsmithred: but they would be re-unpackaged... | 18:35 |
| KatolaZ | I am just trying: egrep -q "^[a-fA-F0-9]+ T (_+.*_)?sys_${symbol}$" /proc/kallsyms ; echo $? | 18:36 |
| fsmithred | no, the file is not being overwritten | 18:37 |
| fsmithred | 1 | 18:37 |
| fsmithred | with your command | 18:38 |
| KatolaZ | I get a zero | 18:38 |
| KatolaZ | o_O | 18:38 |
| Irrwahn | fsmithred: did you define the symbol variable? | 18:38 |
| fsmithred | lol, not lately | 18:39 |
| fsmithred | just realized that | 18:39 |
| Irrwahn | :D | 18:39 |
| KatolaZ | hold on | 18:39 |
| KatolaZ | the symbol symbol is defined in the 'for symbol in $needed_symbols' | 18:39 |
| fsmithred | needed_symbols='inotify_init signalfd accept4 open_by_handle_at timerfd_create epoll_create' | 18:40 |
| fsmithred | egrep -q "^[a-fA-F0-9]+ T (_+.*_)?sys_${symbol}$" /proc/kallsyms ; echo $? | 18:40 |
| fsmithred | 1 | 18:40 |
| fsmithred | aha! | 18:40 |
| fsmithred | symbols/symbol | 18:40 |
| fsmithred | got it! | 18:43 |
| fsmithred | 0 | 18:43 |
| Irrwahn | export needed_symbols='inotify_init signalfd accept4 open_by_handle_at timerfd_create epoll_create'; for symbol in $needed_symbols ; do egrep -q "^[a-fA-F0-9]+ T (_+.*_)?sys_${symbol}$" /proc/kallsyms ; echo $? ; done | 18:43 |
| Irrwahn | gives a bunch of zeros, should be fine. | 18:43 |
| fsmithred | for i in inotify_init signalfd accept4 open_by_handle_at timerfd_create epoll_create ; do egrep -q "^[a-fA-F0-9]+ T (_+.*_)?sys_${i}$" /proc/kallsyms ; echo $? ; done | 18:43 |
| fsmithred | yup | 18:43 |
| KatolaZ | if ! egrep -q "^[a-fA-F0-9]+ T (_+.*_)?sys_inotify_init$" /proc/kallsyms; then echo NO; fi | 18:45 |
| KatolaZ | fsmithred: ^^ | 18:45 |
| KatolaZ | you should see nothing | 18:45 |
| fsmithred | that works, too | 18:46 |
| KatolaZ | ok | 18:47 |
| KatolaZ | I have pushed to suites/unstable | 18:49 |
| KatolaZ | will try to build as soon as the dep issue is solved in Debian | 18:49 |
| Irrwahn | KatolaZ: By any chance, do you know if the debian-init-diversity list is heavily moderated? I registered, but my posts won't show up. | 18:53 |
| KatolaZ | Irrwahn: don't think so | 18:54 |
| KatolaZ | it's not moderated, AFAIK | 18:54 |
| Irrwahn | mmmhh | 18:54 |
| KatolaZ | just email Jan | 18:54 |
| Irrwahn | Yeah, will do that tomorrow, if the status quo doesn't change until then. | 18:55 |
| golinux | Irrwahn: There is usually a confirmation email. Did you get that and complete your registration? | 19:30 |
| KatolaZ | yes | 19:31 |
| KatolaZ | I got a confirmation email | 19:31 |
| KatolaZ | and replied | 19:31 |
| KatolaZ | it's mailman | 19:31 |
| Irrwahn | golinux: Yes, I got that email and followed the link to confirm. I can login and see me listed on the subscribers page. Just my postings seem to get stuck, they didn't even bounce. | 19:43 |
| Irrwahn | Gonna try to contact Matthew who apparently runs the list. | 19:45 |
| Irrwahn | The To: address I must've gotten correct, as I replied to one of KatolaZ' messages. And sending signed mails shouldn't be an issue, as other posters do that too. | 19:48 |
| KatolaZ | Irrwahn: dunno, it's better to ask the administrator | 19:49 |
| Irrwahn | Will do. | 19:49 |
| golinux | They might have new posters in moderation as default. That's what I had to do to DNG after Mikee's last outburst. | 19:52 |
| golinux | Works out OK as there aren't that many new people trying to register. | 19:53 |
| Irrwahn | Yeah, could be. I'll wait till tomorrow, then contact the admin. | 19:53 |
| Irrwahn | Oh, and don't forget to follow golden rule #1: Don't read the comments! | 20:01 |
| Irrwahn | Argh, wrong window, sorry. -.- | 20:02 |
| golinux | KatolaZ: I think it would be a good idea to add a link to pkginfo.d.o. on the nav bar of bugs.d.o. | 20:19 |
| golinux | I'd just call it Packages | 20:19 |
| golinux | I'm going to add that to the forum nav also | 20:20 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!