Re: Fatal glibc error: cannot get entropy for arc4random
On 19.07.2024 20:00, Arkadiusz Miśkiewicz via pld-devel-en wrote: > On 19/07/2024 12:48, Elan Ruusamäe wrote: > > openssh is unable startup > > > > # service sshd restart > > Fatal glibc error: cannot get entropy for arc4random > > Aborted > > > > # rpm -q glibc openssh-server > > glibc-2.39-6-th.x86_64 > > openssh-server-9.8p1-1-th.x86_64 > > > > # uname -r > > 3.13.0-32-generic > > > > from quick internet search 3.15 kernel is needed? but not specified in > > .spec? > > Hm, why 3.15? > > Looking at the arc4random code it fallbacks to /dev/random and /dev/urandom > if syscall is not available (getrandom syscall was introduced in 3.17). Actually glibc-2.39-6 does not fallback to /dev/*random due to bug in arc4random fallback logic (return value checked for ENOSYS instead of errno). It was fixed on Jul 8 (glibc 2.40 does not suffer from it): https://sourceware.org/git/?p=glibc.git;a=commit;h=184b9e530e6326e668709826903b6d30dc6cac3f > > Maybe sshd is not allowing access to these at that point? > > strace could tell us something. > > -- > Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) > ___ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Fatal glibc error: cannot get entropy for arc4random
On 23.07.2024 10:57, Arkadiusz Miśkiewicz via pld-devel-en wrote:
On 22/07/2024 17:16, Elan Ruusamäe wrote:
cannot get entropy for arc4random
Try maybe this code to see if it works (+ strace for it).
It blocks getrandom syscall (ENOSYS) on x86_64 with seccomp.
strace of that program
# strace ./seccomp-test
execve("./seccomp-test", ["./seccomp-test"], 0x7fff233e1f50 /* 39 vars
*/) = 0
brk(NULL) = 0x15a6000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=32151, ...}) = 0
mmap(NULL, 32151, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f7873452000
close(3) = 0
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20b\2\0\0\0\0\0"...,
832) = 832
pread64(3,
"\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784,
64) = 784
fstat(3, {st_mode=S_IFREG|0755, st_size=1966536, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f787345
pread64(3,
"\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784,
64) = 784
mmap(NULL, 2018704, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f7873263000
mmap(0x7f7873287000, 1441792, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x24000) = 0x7f7873287000
mmap(0x7f78733e7000, 352256, PROT_READ,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x184000) = 0x7f78733e7000
mmap(0x7f787343d000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d9000) = 0x7f787343d000
mmap(0x7f7873443000, 52624, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f7873443000
close(3) = 0
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f787326
arch_prctl(ARCH_SET_FS, 0x7f7873260740) = 0
set_tid_address(0x7f7873260a10) = 22077
set_robust_list(0x7f7873260a20, 24) = 0
rseq(0x7f7873261060, 0x20, 0, 0x53053053) = -1 ENOSYS (Function not
implemented)
mprotect(0x7f787343d000, 16384, PROT_READ) = 0
mprotect(0x403000, 4096, PROT_READ) = 0
mprotect(0x7f787348d000, 8192, PROT_READ) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024,
rlim_max=RLIM64_INFINITY}) = 0
munmap(0x7f7873452000, 32151) = 0
prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) = 0
prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, {len=7,
filter=0x7fffb093fd90}) = 0
fstat(1, {st_mode=S_IFCHR|0622, st_rdev=makedev(0x88, 0x5), ...}) = 0
getrandom(0x7f7873448178, 8, GRND_NONBLOCK) = -1 ENOSYS (Function not
implemented)
brk(NULL) = -1 ENOSYS (Function not
implemented)
brk(0x15c7000) = -1 ENOSYS (Function not
implemented)
Testing arc4random() after blocking getrandom syscall:
write(1, "Testing arc4random() after block"..., 55) = -1 ENOSYS
(Function not implemented)
writev(2, [{iov_base="Fatal glibc error: cannot get en"...,
iov_len=53}], 1Fatal glibc error: cannot get entropy for arc4random
) = 53
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f7873459000
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
gettid() = 22077
getpid() = 22077
tgkill(22077, 22077, SIGABRT) = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=22077, si_uid=0} ---
+++ killed by SIGABRT +++
Aborted
i also updated libseccomp. it didn't change a thing
U libseccomp-(2.5.1 => 2.5.5)-1.x86_64
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Fatal glibc error: cannot get entropy for arc4random
On 22/07/2024 17:16, Elan Ruusamäe wrote:
cannot get entropy for arc4random
Try maybe this code to see if it works (+ strace for it).
It blocks getrandom syscall (ENOSYS) on x86_64 with seccomp.
--
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#ifndef __NR_getrandom
#define __NR_getrandom 318
#endif
int main() {
struct sock_filter filter[] = {
BPF_STMT(BPF_LD + BPF_W + BPF_ABS, offsetof(struct seccomp_data, arch)),
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, AUDIT_ARCH_X86_64, 1, 0),
BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_KILL),
BPF_STMT(BPF_LD + BPF_W + BPF_ABS, offsetof(struct seccomp_data, nr)),
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, __NR_getrandom, 1, 0),
BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ALLOW),
BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ERRNO | ENOSYS),
};
struct sock_fprog prog = {
.len = (unsigned short)(sizeof(filter) / sizeof(filter[0])),
.filter = filter,
};
if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
perror("prctl(PR_SET_NO_NEW_PRIVS)");
return 1;
}
if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, )) {
perror("prctl(PR_SET_SECCOMP)");
return 1;
}
printf("Testing arc4random() after blocking getrandom syscall:\n");
unsigned int random_value = arc4random();
printf("arc4random() returned: %u\n", random_value);
return 0;
}
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Fatal glibc error: cannot get entropy for arc4random
On 19.07.2024 21:00, Arkadiusz Miśkiewicz via pld-devel-en wrote:
On 19/07/2024 12:48, Elan Ruusamäe wrote:
openssh is unable startup
# service sshd restart
Fatal glibc error: cannot get entropy for arc4random
Aborted
# rpm -q glibc openssh-server
glibc-2.39-6-th.x86_64
openssh-server-9.8p1-1-th.x86_64
# uname -r
3.13.0-32-generic
from quick internet search 3.15 kernel is needed? but not specified
in .spec?
Hm, why 3.15?
Looking at the arc4random code it fallbacks to /dev/random and
/dev/urandom if syscall is not available (getrandom syscall was
introduced in 3.17).
Maybe sshd is not allowing access to these at that point?
strace could tell us something.
# strace /usr/sbin/sshd -D
...
getrandom(0x7f12e109d270, 48, 0) = -1 ENOSYS (Function not
implemented)
getrandom(0x7f12e109d270, 48, 0) = -1 ENOSYS (Function not
implemented)
shmget(0x72, 1, 000) = 0
shmat(0, NULL, SHM_RDONLY) = 0x7f12df674000
openat(AT_FDCWD, "/dev/urandom", O_RDONLY) = 7
fstat(7, {st_mode=S_IFCHR|0644, st_rdev=makedev(0x1, 0x9), ...}) = 0
read(7,
"`\16\373H\261\343\331\203\231\262\376\263\251\31f\2051\0\212D98\177'\313P\254LT{,\v"...,
48) = 48
getrandom(0x7fff4f092bd0, 48, 0) = -1 ENOSYS (Function not
implemented)
writev(2, [{iov_base="Fatal glibc error: cannot get en"...,
iov_len=53}], 1Fatal glibc error: cannot get entropy for arc4random
) = 53
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f12df673000
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
gettid() = 3681
getpid() = 3681
tgkill(3681, 3681, SIGABRT) = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=3681, si_uid=0} ---
+++ killed by SIGABRT +++
Aborted
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Fatal glibc error: cannot get entropy for arc4random
On 19/07/2024 12:48, Elan Ruusamäe wrote: openssh is unable startup # service sshd restart Fatal glibc error: cannot get entropy for arc4random Aborted # rpm -q glibc openssh-server glibc-2.39-6-th.x86_64 openssh-server-9.8p1-1-th.x86_64 # uname -r 3.13.0-32-generic from quick internet search 3.15 kernel is needed? but not specified in .spec? Hm, why 3.15? Looking at the arc4random code it fallbacks to /dev/random and /dev/urandom if syscall is not available (getrandom syscall was introduced in 3.17). Maybe sshd is not allowing access to these at that point? strace could tell us something. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ssh configuration on builders [Re: [all] builder queue problem]
On Mon, 01 Jul 2024, Jakub Bogusz wrote: > openssh 9.8p1 dropped DSA keys support by default (could be brought back > by --enable-dsa-keys), so "+ssh_dss" (which apparently exists in current > configuration) became invalid. > > So either these options should be removed from builder configuration or > DSA keys support restored in openssh.spec. Disabled DSA on ep09. > On Mon, Jul 01, 2024 at 05:10:17PM +, PLD all builder wrote: > > there were problems sending files from queue > > /home/pld/builderth/pld-builder.new/spool/ftp: > > problems: > > [src: > > /home/pld/builderth/pld-builder.new/spool/ftp/3f092c05-a1fe-410a-adca-148f6352e974] > > > > Executing: program /usr/bin/ssh host ep09.pld-linux.org, user pldth, > > command sftp > > OpenSSH_9.8p1, OpenSSL 3.3.1 4 Jun 2024 > > debug1: Reading configuration data /etc/ssh/ssh_config > > debug1: /etc/ssh/ssh_config line 55: Applying options for * > > /etc/ssh/ssh_config line 65: Bad key types '+ssh-dss'. > > /etc/ssh/ssh_config line 66: Bad key types '+ssh-dss'. > > /etc/ssh/ssh_config: terminating, 2 bad configuration options > > scp: Connection closed [...] -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
ssh configuration on builders [Re: [all] builder queue problem]
openssh 9.8p1 dropped DSA keys support by default (could be brought back by --enable-dsa-keys), so "+ssh_dss" (which apparently exists in current configuration) became invalid. So either these options should be removed from builder configuration or DSA keys support restored in openssh.spec. On Mon, Jul 01, 2024 at 05:10:17PM +, PLD all builder wrote: > there were problems sending files from queue > /home/pld/builderth/pld-builder.new/spool/ftp: > problems: > [src: > /home/pld/builderth/pld-builder.new/spool/ftp/3f092c05-a1fe-410a-adca-148f6352e974] > > Executing: program /usr/bin/ssh host ep09.pld-linux.org, user pldth, command > sftp > OpenSSH_9.8p1, OpenSSL 3.3.1 4 Jun 2024 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 55: Applying options for * > /etc/ssh/ssh_config line 65: Bad key types '+ssh-dss'. > /etc/ssh/ssh_config line 66: Bad key types '+ssh-dss'. > /etc/ssh/ssh_config: terminating, 2 bad configuration options > scp: Connection closed > > [src: > /home/pld/builderth/pld-builder.new/spool/ftp/d87c4b67-5928-4a38-a62c-ff51f3e968a0] > > Executing: program /usr/bin/ssh host ep09.pld-linux.org, user pldth, command > sftp > OpenSSH_9.8p1, OpenSSL 3.3.1 4 Jun 2024 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 55: Applying options for * > /etc/ssh/ssh_config line 65: Bad key types '+ssh-dss'. > /etc/ssh/ssh_config line 66: Bad key types '+ssh-dss'. > /etc/ssh/ssh_config: terminating, 2 bad configuration options > scp: Connection closed > > [src: > /home/pld/builderth/pld-builder.new/spool/ftp/bd8c22ad-70ad-4a80-83f0-dfa0deb2d425] > > Executing: program /usr/bin/ssh host ep09.pld-linux.org, user pldth, command > sftp > OpenSSH_9.8p1, OpenSSL 3.3.1 4 Jun 2024 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 55: Applying options for * > /etc/ssh/ssh_config line 65: Bad key types '+ssh-dss'. > /etc/ssh/ssh_config line 66: Bad key types '+ssh-dss'. > /etc/ssh/ssh_config: terminating, 2 bad configuration options > scp: Connection closed > > [src: > /home/pld/builderth/pld-builder.new/spool/ftp/f0fba842-a9ad-4361-800b-aa21fe6b419b] > > Executing: program /usr/bin/ssh host ep09.pld-linux.org, user pldth, command > sftp > OpenSSH_9.8p1, OpenSSL 3.3.1 4 Jun 2024 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 55: Applying options for * > /etc/ssh/ssh_config line 65: Bad key types '+ssh-dss'. > /etc/ssh/ssh_config line 66: Bad key types '+ssh-dss'. > /etc/ssh/ssh_config: terminating, 2 bad configuration options > scp: Connection closed > > [src: > /home/pld/builderth/pld-builder.new/spool/ftp/fabdfca0-2c08-47ed-aab9-a5e4d0483346] > > Executing: program /usr/bin/ssh host ep09.pld-linux.org, user pldth, command > sftp > OpenSSH_9.8p1, OpenSSL 3.3.1 4 Jun 2024 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 55: Applying options for * > /etc/ssh/ssh_config line 65: Bad key types '+ssh-dss'. > /etc/ssh/ssh_config line 66: Bad key types '+ssh-dss'. > /etc/ssh/ssh_config: terminating, 2 bad configuration options > scp: Connection closed > > [src: > /home/pld/builderth/pld-builder.new/spool/ftp/8b0b4f93-ee8b-4595-99ea-f02e23663838] > > Executing: program /usr/bin/ssh host ep09.pld-linux.org, user pldth, command > sftp > OpenSSH_9.8p1, OpenSSL 3.3.1 4 Jun 2024 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 55: Applying options for * > /etc/ssh/ssh_config line 65: Bad key types '+ssh-dss'. > /etc/ssh/ssh_config line 66: Bad key types '+ssh-dss'. > /etc/ssh/ssh_config: terminating, 2 bad configuration options > scp: Connection closed > > [src: > /home/pld/builderth/pld-builder.new/spool/ftp/d27e529e-a7eb-427b-a08a-700a971586b2] > > Executing: program /usr/bin/ssh host ep09.pld-linux.org, user pldth, command > sftp > OpenSSH_9.8p1, OpenSSL 3.3.1 4 Jun 2024 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 55: Applying options for * > /etc/ssh/ssh_config line 65: Bad key types '+ssh-dss'. > /etc/ssh/ssh_config line 66: Bad key types '+ssh-dss'. > /etc/ssh/ssh_config: terminating, 2 bad configuration options > scp: Connection closed > > [src: > /home/pld/builderth/pld-builder.new/spool/ftp/3dd5e745-df9a-4552-996c-698bdc3112b2] > > Executing: program /usr/bin/ssh host ep09.pld-linux.org, user pldth, command > sftp > OpenSSH_9.8p1, OpenSSL 3.3.1 4 Jun 2024 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 55: Applying options for * > /etc/ssh/ssh_config line 65: Bad key types '+ssh-dss'. > /etc/ssh/ssh_config line 66: Bad key types '+ssh-dss'. > /etc/ssh/ssh_config: terminating, 2 bad configuration options > scp: Connection closed > > [src: > /home/pld/builderth/pld-builder.new/spool/ftp/4e2ab5ad-9845-47a8-bede-2d23ce0fd430] > > Executing:
Re: The horrible mess called PHP
On Sun, 16 Jun 2024, Arkadiusz Miśkiewicz via pld-devel-en wrote: [...] > > But you did disable dependency generator for PEAR > > Author: Jan Rękorajski > Date: Sat Oct 17 10:02:30 2020 +0200 > - disable php pear dependency generators - ver 1.753 > > and that causes now that rebuilding pear packages produce new packages > that do not provide things that existing packages want. > > If you disabled this to get rid of pear specific deps then all pear > packages need to be rebuild. I think I know why I disabled it back then. With rpm5, the dependency generators could be selected by hand in the spec, this is not the case with rpm.org. Now, that dependency generator is run on every package, it picks up a lot of BS that has to be excepted with _noautoreq_pear - see latest updates to zabbix and occ packages. -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: The horrible mess called PHP
On Sun, 16 Jun 2024, Jan Rękorajski wrote: > On Sun, 16 Jun 2024, Arkadiusz Miśkiewicz via pld-devel-en wrote: > [...] > > > > But you did disable dependency generator for PEAR > > > > Author: Jan Rękorajski > > Date: Sat Oct 17 10:02:30 2020 +0200 > > - disable php pear dependency generators - ver 1.753 > > > > and that causes now that rebuilding pear packages produce new packages > > that do not provide things that existing packages want. > > > > If you disabled this to get rid of pear specific deps then all pear > > packages need to be rebuild. > > Hah, good point. I might have disabled it because of dependency problems > seteaming from constant installs/removals of the php runtime. > > I'm going to reenable that and test if it still works. Ok, we have two dependency generators for php pear. One written in perl and that one seem to work, and the second in php that seems to be completely broken: Runtime version 7.4. First: PHP Warning: require_once(PHP/CompatInfo.php): failed to open stream: No such file or directory in /usr/lib/rpm/php.req.php on line 123 PHP Fatal error: require_once(): Failed opening required 'PHP/CompatInfo.php' (include_path='.:/usr/share/pear:/usr/share/php') in /usr/lib/rpm/php.req.php on line 123 After installing php-pear-PHP_CompatInfo: PHP Parse error: syntax error, unexpected 'new' (T_NEW) in /usr/share/pear/Event/Dispatcher.php on line 249 I'll reenable the old one and we'll deal with the problems as they appear. -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: The horrible mess called PHP
On Sun, 16 Jun 2024, Arkadiusz Miśkiewicz via pld-devel-en wrote:
> On 15/06/2024 22:34, Jan Rękorajski wrote:
>
> > TL;DR Make PHP packaging sustainable or all versioned php packages will
> > be deleted and replaced by a single php package tracking head.
>
> I'm using almost all old PHPs, including old 4 one. DON'T delete these.
>
> (I'm using few pear packages, too)
>
> >
> > The current model of packaging PHP runtime is not sustainable. >
> > The dependencies are a complete mess, packages (build)require
> > php-something, but none of the versioned phpXY-something provides
> > this.
>
> Be more specific and I'll try to fix things related to php packages. Now
> I have to guess what are you talking about.
$ builder -bi -R php-pear-PEAR.spec
[...]
Install dependencies: php-pcre php-xml
Loading [pndir]th-test...
Loading [pndir]th-test...
Loading [pndir]th-ready...
Loading [pndir]th-ready...
Loading [pndir]th...
Loading [pndir]th...
34536 packages read
Removed 2036 duplicate packages from available set
error: php-pcre: no such package
error: php-xml: no such package
Because spec:
%define php_name php%{?php_suffix}
[...]
BuildRequires: %{php_name}-pcre
Basically you need to set %php_suffix manually. This should be automated
at the spec level. Maybe something akin to what I did for kernel
packages. Or maybe "pick the latest runtime if not overriden" at macro
definition level.
And to make it better, all php runtimes should be parallel-installable,
including devel, excluding /usr/bin/php link.
> > This leads to a lot of manual labor when rebuilding php-pecl
> > packages (run this magical command for managing installed deps
> > and pray it works).
> >
> > This also leades to even worse mess for PEAR packages. The dependency
> > generator needs /usr/bin/php and it gets a random one,
>
> Does output that it produces depend on php version? AFAIK any php is ok
> for it to produce the same output.
I have no idea, never used PHP. The script looks pretty generic, tho.
> > if it gets
> > anything at all.
>
> But you did disable dependency generator for PEAR
>
> Author: Jan Rękorajski
> Date: Sat Oct 17 10:02:30 2020 +0200
> - disable php pear dependency generators - ver 1.753
>
> and that causes now that rebuilding pear packages produce new packages
> that do not provide things that existing packages want.
>
> If you disabled this to get rid of pear specific deps then all pear
> packages need to be rebuild.
Hah, good point. I might have disabled it because of dependency problems
seteaming from constant installs/removals of the php runtime.
I'm going to reenable that and test if it still works.
--
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: The horrible mess called PHP
On 15/06/2024 22:34, Jan Rękorajski wrote: TL;DR Make PHP packaging sustainable or all versioned php packages will be deleted and replaced by a single php package tracking head. I'm using almost all old PHPs, including old 4 one. DON'T delete these. (I'm using few pear packages, too) The current model of packaging PHP runtime is not sustainable. > The dependencies are a complete mess, packages (build)require php-something, but none of the versioned phpXY-something provides this. Be more specific and I'll try to fix things related to php packages. Now I have to guess what are you talking about. This leads to a lot of manual labor when rebuilding php-pecl packages (run this magical command for managing installed deps and pray it works). This also leades to even worse mess for PEAR packages. The dependency generator needs /usr/bin/php and it gets a random one, Does output that it produces depend on php version? AFAIK any php is ok for it to produce the same output. if it gets anything at all. But you did disable dependency generator for PEAR Author: Jan Rękorajski Date: Sat Oct 17 10:02:30 2020 +0200 - disable php pear dependency generators - ver 1.753 and that causes now that rebuilding pear packages produce new packages that do not provide things that existing packages want. If you disabled this to get rid of pear specific deps then all pear packages need to be rebuild. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: freshness report not updating
On 11.06.2024 09:41, Jan Rękorajski wrote: > On Sat, 08 Jun 2024, Jan Rękorajski wrote: > > > On Sun, 05 May 2024, Jan Palus wrote: > > > > > Looks like new entries don't appear in freshness report > > > (http://ep09.pld-linux.org/~pldth/qa.php?q=freshness) although > > > interestingly old items that made it to the list disappear after they > > > were sent to builders. > > > > The problem is that SPECS pseudorepo has not been updated since May 1st, > > probably due to disk space issues. I'll see if I can do something with > > it. > > Took me a while, but problem solved. > > The SPECS repo had a stale lock preventing it from being updated (－‸ლ) > > There was a second issue, the Refs repo had (i) grown to enormous size > and (ii) has been badly damaged to the point that git gc consistently > failed. Since Refs.git is just a tracker of all refs in packages repos, > I could and did recreate it from scratch saving 25G of space > (free went up from 3.7G to 32G). > > Since we only really care about the HEAD state of Refs.git it would ge > good to prune it more regularly, so that we don't end up in this state > again. Thanks! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: freshness report not updating
On Sat, 08 Jun 2024, Jan Rękorajski wrote: > On Sun, 05 May 2024, Jan Palus wrote: > > > Looks like new entries don't appear in freshness report > > (http://ep09.pld-linux.org/~pldth/qa.php?q=freshness) although > > interestingly old items that made it to the list disappear after they > > were sent to builders. > > The problem is that SPECS pseudorepo has not been updated since May 1st, > probably due to disk space issues. I'll see if I can do something with > it. Took me a while, but problem solved. The SPECS repo had a stale lock preventing it from being updated (－‸ლ) There was a second issue, the Refs repo had (i) grown to enormous size and (ii) has been badly damaged to the point that git gc consistently failed. Since Refs.git is just a tracker of all refs in packages repos, I could and did recreate it from scratch saving 25G of space (free went up from 3.7G to 32G). Since we only really care about the HEAD state of Refs.git it would ge good to prune it more regularly, so that we don't end up in this state again. -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: freshness report not updating
On Sun, 05 May 2024, Jan Palus wrote: > Looks like new entries don't appear in freshness report > (http://ep09.pld-linux.org/~pldth/qa.php?q=freshness) although > interestingly old items that made it to the list disappear after they > were sent to builders. The problem is that SPECS pseudorepo has not been updated since May 1st, probably due to disk space issues. I'll see if I can do something with it. -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: DISTFILES: kicad: ERRORS: kicad-packages3D-8.0.2.tar.bz2
On Mon, 29 Apr 2024, Jan Rękorajski wrote: > On Mon, 29 Apr 2024, Jakub Bogusz wrote: > > > What happens here? > > ENOSPC? > > > > Offending file is ~700MB big. > > Yeah, cvs/git vm is out of disk space (that's where the files are > fetched): > > /dev/mapper/cvs-cvs xfs45G 45G 316M 100% /cvs/root > > Who can run lvextend/xfs_resize there? Answering myself. I can and added 1G. We may need to get that PV/VG bigger tho, 90% of repo space is taken by Refs.git that tracks individual package repos history. > > > On Mon, Apr 29, 2024 at 09:04:51PM +0200, qboosh wrote: > > > Request by: qboosh > > > > > > FATAL: cannot move ./upload/kicad-packages3D-8.0.2.tar.bz2 to > > > ./tmp/87b03bfe-24d2-4f8c-bd46-d36c7fcaba9b > > > ERROR: cannot write > > > ./tmp/87b03bfe-24d2-4f8c-bd46-d36c7fcaba9b/kicad-packages3D-8.0.2.tar.bz2.link > > > > > > Files fetched: 0 > > > > > > ALREADY GOT: > > > https://gitlab.com/kicad/code/kicad/-/archive/8.0.2/kicad-8.0.2.tar.bz2 > > > 957ba90492d8bf60f4ff55b3910f1cbd kicad-8.0.2.tar.bz2 > > > ALREADY GOT: > > > https://gitlab.com/kicad/services/kicad-doc/-/archive/8.0.2/kicad-doc-8.0.2.tar.bz2 > > > 5c1b5dc997be84b08d59d78a5a9fcd3e kicad-doc-8.0.2.tar.bz2 > > > ALREADY GOT: > > > https://gitlab.com/kicad/libraries/kicad-symbols/-/archive/8.0.2/kicad-symbols-8.0.2.tar.bz2 > > > 060c52586965f15b867ee0683aa642ae kicad-symbols-8.0.2.tar.bz2 > > > ALREADY GOT: > > > https://gitlab.com/kicad/libraries/kicad-footprints/-/archive/8.0.2/kicad-footprints-8.0.2.tar.bz2 > > > c9537b5ccaa9581ff32d157837a13c38 kicad-footprints-8.0.2.tar.bz2 > > > ALREADY GOT: > > > https://gitlab.com/kicad/libraries/kicad-templates/-/archive/8.0.2/kicad-templates-8.0.2.tar.bz2 > > > 20932897d55d49386a1e2431a2aeef5f kicad-templates-8.0.2.tar.bz2 > > > > > > > > > -- > > > Virtually Yours: distfiles. > > > ___ > > > pld-cvs-commit mailing list > > > pld-cvs-com...@lists.pld-linux.org > > > http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit > > > > -- > > Jakub Boguszhttp://qboosh.pl/ > > ___ > > pld-devel-en mailing list > > pld-devel-en@lists.pld-linux.org > > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > > -- > Jan Rękorajski| PLD/Linux > SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ > ___ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: DISTFILES: kicad: ERRORS: kicad-packages3D-8.0.2.tar.bz2
On Mon, 29 Apr 2024, Jakub Bogusz wrote: > What happens here? > ENOSPC? > > Offending file is ~700MB big. Yeah, cvs/git vm is out of disk space (that's where the files are fetched): /dev/mapper/cvs-cvs xfs45G 45G 316M 100% /cvs/root Who can run lvextend/xfs_resize there? > On Mon, Apr 29, 2024 at 09:04:51PM +0200, qboosh wrote: > > Request by: qboosh > > > > FATAL: cannot move ./upload/kicad-packages3D-8.0.2.tar.bz2 to > > ./tmp/87b03bfe-24d2-4f8c-bd46-d36c7fcaba9b > > ERROR: cannot write > > ./tmp/87b03bfe-24d2-4f8c-bd46-d36c7fcaba9b/kicad-packages3D-8.0.2.tar.bz2.link > > > > Files fetched: 0 > > > > ALREADY GOT: > > https://gitlab.com/kicad/code/kicad/-/archive/8.0.2/kicad-8.0.2.tar.bz2 > > 957ba90492d8bf60f4ff55b3910f1cbd kicad-8.0.2.tar.bz2 > > ALREADY GOT: > > https://gitlab.com/kicad/services/kicad-doc/-/archive/8.0.2/kicad-doc-8.0.2.tar.bz2 > > 5c1b5dc997be84b08d59d78a5a9fcd3e kicad-doc-8.0.2.tar.bz2 > > ALREADY GOT: > > https://gitlab.com/kicad/libraries/kicad-symbols/-/archive/8.0.2/kicad-symbols-8.0.2.tar.bz2 > > 060c52586965f15b867ee0683aa642ae kicad-symbols-8.0.2.tar.bz2 > > ALREADY GOT: > > https://gitlab.com/kicad/libraries/kicad-footprints/-/archive/8.0.2/kicad-footprints-8.0.2.tar.bz2 > > c9537b5ccaa9581ff32d157837a13c38 kicad-footprints-8.0.2.tar.bz2 > > ALREADY GOT: > > https://gitlab.com/kicad/libraries/kicad-templates/-/archive/8.0.2/kicad-templates-8.0.2.tar.bz2 > > 20932897d55d49386a1e2431a2aeef5f kicad-templates-8.0.2.tar.bz2 > > > > > > -- > > Virtually Yours: distfiles. > > ___ > > pld-cvs-commit mailing list > > pld-cvs-com...@lists.pld-linux.org > > http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit > > -- > Jakub Boguszhttp://qboosh.pl/ > ___ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: DISTFILES: kicad: ERRORS: kicad-packages3D-8.0.2.tar.bz2
What happens here? ENOSPC? Offending file is ~700MB big. On Mon, Apr 29, 2024 at 09:04:51PM +0200, qboosh wrote: > Request by: qboosh > > FATAL: cannot move ./upload/kicad-packages3D-8.0.2.tar.bz2 to > ./tmp/87b03bfe-24d2-4f8c-bd46-d36c7fcaba9b > ERROR: cannot write > ./tmp/87b03bfe-24d2-4f8c-bd46-d36c7fcaba9b/kicad-packages3D-8.0.2.tar.bz2.link > > Files fetched: 0 > > ALREADY GOT: > https://gitlab.com/kicad/code/kicad/-/archive/8.0.2/kicad-8.0.2.tar.bz2 > 957ba90492d8bf60f4ff55b3910f1cbd kicad-8.0.2.tar.bz2 > ALREADY GOT: > https://gitlab.com/kicad/services/kicad-doc/-/archive/8.0.2/kicad-doc-8.0.2.tar.bz2 > 5c1b5dc997be84b08d59d78a5a9fcd3e kicad-doc-8.0.2.tar.bz2 > ALREADY GOT: > https://gitlab.com/kicad/libraries/kicad-symbols/-/archive/8.0.2/kicad-symbols-8.0.2.tar.bz2 > 060c52586965f15b867ee0683aa642ae kicad-symbols-8.0.2.tar.bz2 > ALREADY GOT: > https://gitlab.com/kicad/libraries/kicad-footprints/-/archive/8.0.2/kicad-footprints-8.0.2.tar.bz2 > c9537b5ccaa9581ff32d157837a13c38 kicad-footprints-8.0.2.tar.bz2 > ALREADY GOT: > https://gitlab.com/kicad/libraries/kicad-templates/-/archive/8.0.2/kicad-templates-8.0.2.tar.bz2 > 20932897d55d49386a1e2431a2aeef5f kicad-templates-8.0.2.tar.bz2 > > > -- > Virtually Yours: distfiles. > ___ > pld-cvs-commit mailing list > pld-cvs-com...@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: builders->ftp uploads defunct
On 22/04/2024 20:58, Jakub Bogusz wrote: Since Saturday new packages don't appear in th-test. Could it be fixed? ENOSPC on ftp disk and stale locks... fixed. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/xz] Revert back to 5.4.6 as 5.6.x are BACKDOORED! https://www.openwall.com/lists/oss-security/2024/03/29
Dnia Sat, Mar 30, 2024 at 01:57:22PM +0100, Jan Palus napisał(a):
> On 30.03.2024 01:49, arekm wrote:
> > commit b369fe78b7b4a02e900fb6fe7ac035a9bba39436
> > Author: Arkadiusz Miśkiewicz
> > Date: Fri Mar 29 23:50:59 2024 +0100
> >
> > Revert back to 5.4.6 as 5.6.x are BACKDOORED!
> > https://www.openwall.com/lists/oss-security/2024/03/29/4
> >
> > xz.spec | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> > ---
> > diff --git a/xz.spec b/xz.spec
> > index a36b5df..8094d11 100644
> > --- a/xz.spec
> > +++ b/xz.spec
> > @@ -19,8 +19,8 @@ Summary: LZMA Encoder/Decoder
> > Summary(pl.UTF-8): Koder/Dekoder LZMA
> > Name: xz
> > Version: 5.4.6
> > -Release: 1
> > -Epoch: 1
> > +Release: 2
> > +Epoch: 2
> > License: LGPL v2.1+, helper scripts on GPL v2+
> > Group: Applications/Archiving
> > Source0:
> > https://github.com/tukaani-project/xz/releases/download/v%{version}/%{name}-%{version}.tar.bz2
>
> Some notes from what I've gathered so far from a rather lengthy HN
> thread:
>
> - main backdoor appears to affect /usr/sbin/sshd on x86_64 with liblzma
> being pulled in as an indirect dependency. liblzma can be loaded by
> libsystemd if sshd was built with additional systemd patches which PLD
> does not use (unlike Debian and Fedora). So _possibly_ PLD is not
> affected
>
> - despite that some claims start to surface that going back to 5.4.6
> might not be enough so let's see how this drama develops
Hi there,
I checked manually that the 5.6.1 version from this build [1] seems not
to be vulnerable (I verified it using the signature provided in the original
post [2]).
My suspicion regarding why it was not activated is due to the failure of the
following check on the build machine. The check is a part of the malicious
script which decides if backdoor should be planted.
[...]
if test "x$CC" != 'xgcc' > /dev/null 2>&1;then
exit 0
fi
[...]
The condition fails because CC set during the build is different:
'CC=x86_64-pld-linux-gcc' However, please note that there might be additional
components within the package unknown to us at present.
Regards,
Mateusz
[1]
http://buildlogs.pld-linux.org//index.php?dist=th=x86_64=1==50=0=xz=0a127d4c-eda2-4f14-aedf-4a69d79b5b80=text
[2] https://seclists.org/oss-sec/2024/q1/268
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/xz] Revert back to 5.4.6 as 5.6.x are BACKDOORED! https://www.openwall.com/lists/oss-security/2024/03/29
On 30.03.2024 01:49, arekm wrote:
> commit b369fe78b7b4a02e900fb6fe7ac035a9bba39436
> Author: Arkadiusz Miśkiewicz
> Date: Fri Mar 29 23:50:59 2024 +0100
>
> Revert back to 5.4.6 as 5.6.x are BACKDOORED!
> https://www.openwall.com/lists/oss-security/2024/03/29/4
>
> xz.spec | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> ---
> diff --git a/xz.spec b/xz.spec
> index a36b5df..8094d11 100644
> --- a/xz.spec
> +++ b/xz.spec
> @@ -19,8 +19,8 @@ Summary:LZMA Encoder/Decoder
> Summary(pl.UTF-8): Koder/Dekoder LZMA
> Name:xz
> Version: 5.4.6
> -Release: 1
> -Epoch: 1
> +Release: 2
> +Epoch: 2
> License: LGPL v2.1+, helper scripts on GPL v2+
> Group: Applications/Archiving
> Source0:
> https://github.com/tukaani-project/xz/releases/download/v%{version}/%{name}-%{version}.tar.bz2
Some notes from what I've gathered so far from a rather lengthy HN
thread:
- main backdoor appears to affect /usr/sbin/sshd on x86_64 with liblzma
being pulled in as an indirect dependency. liblzma can be loaded by
libsystemd if sshd was built with additional systemd patches which PLD
does not use (unlike Debian and Fedora). So _possibly_ PLD is not
affected
- despite that some claims start to surface that going back to 5.4.6
might not be enough so let's see how this drama develops
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/python3] python points to python3 now
On 25/03/2024 10:22, Jan Palus wrote:
On 25.03.2024 11:05, arekm wrote:
commit d073fb40c26996aedc0c52fdea5af8b596e4f395
Author: Arkadiusz Miśkiewicz
Date: Mon Mar 25 09:58:15 2024 +0100
python points to python3 now
python3.spec | 4
1 file changed, 4 insertions(+)
---
diff --git a/python3.spec b/python3.spec
index 503d98b..686f876 100644
--- a/python3.spec
+++ b/python3.spec
@@ -669,6 +669,9 @@ install -p Tools/patchcheck/reindent.py
$RPM_BUILD_ROOT%{_bindir}/pyreindent%{py
%{__mv} $RPM_BUILD_ROOT%{py_incdir}/pyconfig.h
$RPM_BUILD_ROOT%{py_libdir}/config-%{py_platform}/pyconfig.h
%{__sed}
-e's#@PREFIX@#%{_prefix}#g;s#@PY_VER@#%{py_ver}#g;s#@PY_ABI@#%{py_platform}#g'
%{SOURCE1} > $RPM_BUILD_ROOT%{py_incdir}/pyconfig.h
+# python points to python3 now
+ln -s python3 $RPM_BUILD_ROOT%{_bindir}/python
+
I guess all those packages that still meet `ipoldek what-requires
/usr/bin/python`
might not be happy about it.
I'm not sending these changes to builders to see what other devs will say.
(the intention was to break these packages and get them dropped (or
fixed) on case by case basis, if problems occur)
--
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/python3] python points to python3 now
On 25.03.2024 11:05, arekm wrote:
> commit d073fb40c26996aedc0c52fdea5af8b596e4f395
> Author: Arkadiusz Miśkiewicz
> Date: Mon Mar 25 09:58:15 2024 +0100
>
> python points to python3 now
>
> python3.spec | 4
> 1 file changed, 4 insertions(+)
> ---
> diff --git a/python3.spec b/python3.spec
> index 503d98b..686f876 100644
> --- a/python3.spec
> +++ b/python3.spec
> @@ -669,6 +669,9 @@ install -p Tools/patchcheck/reindent.py
> $RPM_BUILD_ROOT%{_bindir}/pyreindent%{py
> %{__mv} $RPM_BUILD_ROOT%{py_incdir}/pyconfig.h
> $RPM_BUILD_ROOT%{py_libdir}/config-%{py_platform}/pyconfig.h
> %{__sed}
> -e's#@PREFIX@#%{_prefix}#g;s#@PY_VER@#%{py_ver}#g;s#@PY_ABI@#%{py_platform}#g'
> %{SOURCE1} > $RPM_BUILD_ROOT%{py_incdir}/pyconfig.h
>
> +# python points to python3 now
> +ln -s python3 $RPM_BUILD_ROOT%{_bindir}/python
> +
I guess all those packages that still meet `ipoldek what-requires
/usr/bin/python`
might not be happy about it.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/gobject-introspection] - updated to 1.80.0; added bootstrap bcond for glib 2.78->2.80 transition
On Sun, Mar 10, 2024 at 10:56:22AM +0100, Jan Palus wrote: > Shouldn't it be the other way around -- "bootstrap" bcond in glib2 for > building without introspection? Currently while gobject-introspection > does not build-time depend on glib2-devel >= 2.80, it does runtime > depend on glib2 >= 2.80 (both in rpm deps and linked dynamic library) > which cannot be satisfied to build glib2 2.80. Oh, I wasn't aware of g-ir-scanner dependency to build introspection files in glib2 (I had gobject-introspection-devel 1.78 installed). So now I added "introspection" bcond to glib2.spec to allow bootstrapping from scratch. Previously I added "bootstrap" bcond in gobject-introspection as a way to cleanly build+upgrade on existing system (it's not possible to cleanly upgrade glib2 built with introspection without removing or upgrading to 1.80 existing gobject-introspection 1.78 package due to files conflict). So I could build whole glib2 2.80 and gobject-introspection 1.80 and upgrade them both simultaneously. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/gobject-introspection] - updated to 1.80.0; added bootstrap bcond for glib 2.78->2.80 transition
On 09.03.2024 22:33, qboosh wrote:
> commit a0c12f9cf03d0222dbb6357f6da0f70e72260664
> Author: Jakub Bogusz
> Date: Sat Mar 9 22:31:00 2024 +0100
>
> - updated to 1.80.0; added bootstrap bcond for glib 2.78->2.80 transition
>
> gobject-introspection.spec | 55
> +-
> 1 file changed, 35 insertions(+), 20 deletions(-)
> ---
> diff --git a/gobject-introspection.spec b/gobject-introspection.spec
> index 0055356..4719aa3 100644
> --- a/gobject-introspection.spec
> +++ b/gobject-introspection.spec
> @@ -2,27 +2,30 @@
> # Conditional build:
> %bcond_without cairo # cairo support
> %bcond_without apidocs # API documentation
> +%bcond_with bootstrap # bootstrap from glib < 2.80
>
> Summary: Introspection for GObject libraries
> Summary(pl.UTF-8): Obserwacja bibliotek GObject
> Name:gobject-introspection
> -Version: 1.78.1
> +Version: 1.80.0
> Release: 1
> -License: LGPL v2+ (giscanner) and GPL v2+ (tools)
> +License: LGPL v2+ (libraries, giscanner) and GPL v2+ (tools)
> Group: Libraries
> -Source0:
> https://download.gnome.org/sources/gobject-introspection/1.78/%{name}-%{version}.tar.xz
> -# Source0-md5: da2677e6b9c91b33c036d2233a96cec3
> +Source0:
> https://download.gnome.org/sources/gobject-introspection/1.80/%{name}-%{version}.tar.xz
> +# Source0-md5: 003cc22c45be5edf91911050bbcfbde6
> +Source1: https://download.gnome.org/sources/glib/2.80/glib-2.80.0.tar.xz
> +# Source1-md5: 3a51e2803ecd22c2dadcd07d9475ebe3
> URL: https://wiki.gnome.org/Projects/GObjectIntrospection
> BuildRequires: automake
> BuildRequires: bison
> %{?with_cairo:BuildRequires: cairo-gobject-devel}
> BuildRequires: flex
> BuildRequires: gcc >= 5:3.2
> -BuildRequires: glib2-devel >= 1:2.78.0
> +%{!?with_bootstrap:BuildRequires:glib2-devel >= 1:2.80.0}
> BuildRequires: glibc-misc
> %{?with_apidocs:BuildRequires: gtk-doc >= 1.19}
> -BuildRequires: libffi-devel >= 3.0.0
> -BuildRequires: meson >= 0.60.0
> +BuildRequires: libffi-devel >= 7:3.4
> +BuildRequires: meson >= 1.2.0
> BuildRequires: ninja >= 1.5
> BuildRequires: pkgconfig
> BuildRequires: python3 >= 1:3.6
> @@ -36,7 +39,8 @@ BuildRequires: rpmbuild(macros) >= 1.752
> BuildRequires: tar >= 1:1.22
> BuildRequires: xz
> BuildRequires: zlib-devel
> -Requires:glib2 >= 1:2.78.0
> +Requires:glib2 >= 1:2.80.0
Shouldn't it be the other way around -- "bootstrap" bcond in glib2 for
building without introspection? Currently while gobject-introspection
does not build-time depend on glib2-devel >= 2.80, it does runtime
depend on glib2 >= 2.80 (both in rpm deps and linked dynamic library)
which cannot be satisfied to build glib2 2.80.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/kf5-attica] - updated to 5.249.0; rel 0.1
On Sun, Feb 04, 2024 at 03:04:21PM +0100, Witold Filipczyk via pld-devel-en wrote: > Dnia Sat, Feb 03, 2024 at 08:56:25PM +0100, Jakub Bogusz napisał(a): > > On Sat, Feb 03, 2024 at 08:39:39PM +0100, witekfl wrote: > > > commit 3b3013be1262989c7a7df78ffab6d797766b6486 > > > Author: Witold Filipczyk > > > Date: Sat Feb 3 20:24:04 2024 +0100 > > > > > > - updated to 5.249.0; rel 0.1 > > > > > > kf5-attica.spec | 41 - > > > 1 file changed, 20 insertions(+), 21 deletions(-) > > > > Shouldn't these (kf5-* 5.249.0) be kf6-*.spec now? > > OK. What to do with plasma (now kp5-*) and KDE Gear (now ka5-*) ? No idea about starting prefix (should "kp" and "ka" be preserved or changed), but AFAICS files/dirs are getting "6" suffix now, so IMO number should be updated (or dropped, if KDE 6 is going to instantly replace KDE 5). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: TEST build ERRORS: test.spec
On 05/02/2024 02:02, Jan Palus wrote: I've tried to replicate the env (i686 VM, XFS) but without success. Not sure if it's block device driver? XFS? or something else? Can't do much more without ability to reproduce. Any ideas are welcome. All builders run on the same physical machine as VMs under proxmox 8.1: pve-manager/8.1.4/ec5affc9e41f1d79 (running kernel: 6.5.11-8-pve) Each builder uses two physical SSD disks (crucial: x32 - mx200, i686 - mx300, x86_64 - mx500). SSD are available to VMs as passthru. VMs have soft RAID1 setup inside, xfs fs on top of that. It's basically old hardware setup migrated from 3 different physical machines into one with proxmox. Providing disk directly to VM seems to be a key to reproduce the problem (as I was unable to reproduce it on the same machine when VM visible disk was backed by just qcow2 file). Disks used default options (so no cache, no discard, no io thread, no skip replication, async io - io_uring). Virtio interface. But I noticed that enabling discard on these hard disks (in proxmox->VM->Hardware->Hard disk) makes problem go away. So enabled on all builders. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: TEST build ERRORS: test.spec
On 05.02.2024 00:50, PLD th-i686 builder wrote: > test.spec (cryptsetup-debug): FAILED ... > + test cafa743b687f1581b71a20ebfc068f9fe12653e945c417311b861c9217e66adf '=' > 06e2f159d6d541169da75222a7f0bedd0fc700502d63809f577b48f41eace335 Something concerning is going on i686/x32 builders. All started with cryptsetup tests failing there without any clear root cause. Code involved in failing test is pretty straightforward and has no issues as far as I can tell. Managed to narrow it down to: - happens only on PLD builders - happens only on 32-bit archs - happens only when direct io (O_DIRECT) is involved The concerning part is that writing with O_DIRECT produces non-sense result. Parts of write might be missing or they might be scattered in different places even though they should be contiguous. Simple reproducer is currently present in test package on cryptsetup-debug branch. I've tried to replicate the env (i686 VM, XFS) but without success. Not sure if it's block device driver? XFS? or something else? Can't do much more without ability to reproduce. Any ideas are welcome. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/kf5-attica] - updated to 5.249.0; rel 0.1
Dnia Sat, Feb 03, 2024 at 08:56:25PM +0100, Jakub Bogusz napisał(a): > On Sat, Feb 03, 2024 at 08:39:39PM +0100, witekfl wrote: > > commit 3b3013be1262989c7a7df78ffab6d797766b6486 > > Author: Witold Filipczyk > > Date: Sat Feb 3 20:24:04 2024 +0100 > > > > - updated to 5.249.0; rel 0.1 > > > > kf5-attica.spec | 41 - > > 1 file changed, 20 insertions(+), 21 deletions(-) > > Shouldn't these (kf5-* 5.249.0) be kf6-*.spec now? OK. What to do with plasma (now kp5-*) and KDE Gear (now ka5-*) ? > > > -- > Jakub Boguszhttp://qboosh.pl/ > ___ > pld-devel-pl mailing list > pld-devel...@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/kf5-attica] - updated to 5.249.0; rel 0.1
On Sat, Feb 03, 2024 at 08:39:39PM +0100, witekfl wrote: > commit 3b3013be1262989c7a7df78ffab6d797766b6486 > Author: Witold Filipczyk > Date: Sat Feb 3 20:24:04 2024 +0100 > > - updated to 5.249.0; rel 0.1 > > kf5-attica.spec | 41 - > 1 file changed, 20 insertions(+), 21 deletions(-) Shouldn't these (kf5-* 5.249.0) be kf6-*.spec now? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: New packages not available on ftp
On 02/02/2024 00:14, Jan Palus wrote: None of packages built today on builders is available on ftp. Can someone check? Something bad happened on ep09 machine (which is main ftp machine; doesn't let ssh in; disconnects). No idea who else beside RMF has access to console on this VM. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/pam] - add triggers for removed modules
On Fri, 05 Jan 2024, Jan Palus wrote:
> On 23.12.2023 10:53, baggins wrote:
> > commit 201cb6739a14557a0ec8bf7c3dd171b4fc06afeb
> > Author: Jan Rękorajski
> > Date: Sat Dec 23 09:24:52 2023 +0100
> >
> > - add triggers for removed modules
> >
> > pam.spec | 10 +-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> > ---
> > diff --git a/pam.spec b/pam.spec
> > index 8daeb42..a333ab9 100644
> > --- a/pam.spec
> > +++ b/pam.spec
> > @@ -413,7 +413,15 @@ if [ "$1" != 1 ]; then
> > fi
> > exit 0
> >
> > -%triggerpostun -- %{name} < 1:1.1.5-8
> > +%triggerpostun -- %{name} < 1:1.5.3
> > +# removed in 1.5.3
> > +if grep -qs pam_tally /etc/pam.d/system-auth; then
> > + %{__sed} -i -e '/pam_tally/d' /etc/pam.d/system-auth
> > +fi
> > +if grep -qs pam_cracklib /etc/pam.d/system-auth; then
> > + %{__sed} -i -e '/pam_cracklib/ s/pam_cracklib/pam_pwquality/; s/$/
> > use_authtok/' /etc/pam.d/system-auth
>
> ^
>
> What's the reason for "use_authtok" exactly? There is no module left to
> prompt for password now and passwd just fails:
>
> # passwd
> passwd: Authentication token manipulation error
> passwd: password unchanged
I'd swear I've been following the module docs, but it does not indeed
make sense. I'll fix it asap.
--
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/pam] - add triggers for removed modules
On 23.12.2023 10:53, baggins wrote:
> commit 201cb6739a14557a0ec8bf7c3dd171b4fc06afeb
> Author: Jan Rękorajski
> Date: Sat Dec 23 09:24:52 2023 +0100
>
> - add triggers for removed modules
>
> pam.spec | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
> ---
> diff --git a/pam.spec b/pam.spec
> index 8daeb42..a333ab9 100644
> --- a/pam.spec
> +++ b/pam.spec
> @@ -413,7 +413,15 @@ if [ "$1" != 1 ]; then
> fi
> exit 0
>
> -%triggerpostun -- %{name} < 1:1.1.5-8
> +%triggerpostun -- %{name} < 1:1.5.3
> +# removed in 1.5.3
> +if grep -qs pam_tally /etc/pam.d/system-auth; then
> + %{__sed} -i -e '/pam_tally/d' /etc/pam.d/system-auth
> +fi
> +if grep -qs pam_cracklib /etc/pam.d/system-auth; then
> + %{__sed} -i -e '/pam_cracklib/ s/pam_cracklib/pam_pwquality/; s/$/
> use_authtok/' /etc/pam.d/system-auth
^
What's the reason for "use_authtok" exactly? There is no module left to
prompt for password now and passwd just fails:
# passwd
passwd: Authentication token manipulation error
passwd: password unchanged
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: DISTFILES: ccache: ERRORS: ccache-4.9.tar.xz
On 31.12.2023 13:10, atler wrote: > Request by: atler > > scp problems: scp -pr -B -q > ./tmp/a3fa32b0-8779-4bcb-a2b9-de2c39648f88/6eeab51025bb3492aa197d7d32be3184/ > pldd...@distfiles.pld-linux.org:ftp//by-md5/6/e: > scp: Connection closed > > The command has exited with a non-zero status. > > Files fetched: 0 Same issue twice in a row, no space left perhaps? Can someone have a look? ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/mysql] Started work on 8.1.0 upgrade and also started making this package coinstallable with other mysql/ma
On Fri, Oct 20, 2023 at 07:01:56PM +0200, arekm wrote:
> commit 616994dbf9872356085c234c4c1efaa050d74ce3
> Author: Arkadiusz Miśkiewicz
> Date: Fri Oct 20 19:01:24 2023 +0200
>
> Started work on 8.1.0 upgrade and also started making this package
> coinstallable with other mysql/mariadb/percona servers
> +%define majorver81
> +Name:mysql%{majorver}
Please, use "8.1" (and similar scheme) not "81" in such cases.
If they e.g. start using 24.x as version number next year, our suffixes would
go crazy.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/shared-mime-info] fix build with doc; rel 2
On Mon, Oct 09, 2023 at 02:59:52PM +0200, atler wrote: > commit dabbd0362fbd2a2345f450a5efceb62eb321741b > Author: Jan Palus > Date: Mon Oct 9 14:11:26 2023 +0200 > > fix build with doc; rel 2 > > replace unicode apostrophe with ascii one. from: > https://gitlab.freedesktop.org/xdg/shared-mime-info/-/merge_requests/254 We can also use: SP_ENCODING=utf-8 \ db2html data/shared-mime-info-spec.xml to build with Unicode. But yes, using Unicode for just single apostrophe is excessive... -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: i3lock - spec file
On 12.07.2023 17:10, Mateusz Kocielski wrote: > Dnia Wed, Jul 12, 2023 at 01:22:08PM +0200, Jan Palus napisał(a): > > > > Override pam configuration shipped with i3lock with custom one that has: > > > > auth include system-auth > > > > just like (all?) other screensavers/lockers and it should be fine. > > > > Other than this > > > > 1. Fix case in Summary: > > 2. Update required macros according to linked BuildRequires.txt (for > >%ninja_* macros) > > 3. Clone empty pld repository for i3lock or just create a local git > >repo, commit the spec and pam file and attach output of > >`git format-patch -1` so authorship will be preserved correctly when > >applying. > > All done, thanks for reviewing it! Thanks. Applied and now available in th-test. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: i3lock - spec file
Dnia Wed, Jul 12, 2023 at 01:22:08PM +0200, Jan Palus napisał(a):
>
> Override pam configuration shipped with i3lock with custom one that has:
>
> auth include system-auth
>
> just like (all?) other screensavers/lockers and it should be fine.
>
> Other than this
>
> 1. Fix case in Summary:
> 2. Update required macros according to linked BuildRequires.txt (for
>%ninja_* macros)
> 3. Clone empty pld repository for i3lock or just create a local git
>repo, commit the spec and pam file and attach output of
>`git format-patch -1` so authorship will be preserved correctly when
>applying.
All done, thanks for reviewing it!
Regards,
Mateusz
>From 54d6ec043900d3b74fb9d22f314d7145d545af16 Mon Sep 17 00:00:00 2001
From: Mateusz Kocielski
Date: Wed, 12 Jul 2023 19:04:44 +0200
Subject: [PATCH] Initial version of i3lock spec
Prepared with helping hand from Jan Palus
---
i3lock.pam | 1 +
i3lock.spec | 49 +
2 files changed, 50 insertions(+)
create mode 100644 i3lock.pam
create mode 100644 i3lock.spec
diff --git a/i3lock.pam b/i3lock.pam
new file mode 100644
index 000..2a1bcd9
--- /dev/null
+++ b/i3lock.pam
@@ -0,0 +1 @@
+authinclude system-auth
diff --git a/i3lock.spec b/i3lock.spec
new file mode 100644
index 000..34d323b
--- /dev/null
+++ b/i3lock.spec
@@ -0,0 +1,49 @@
+Summary: Improved screen locker
+Name: i3lock
+Version: 2.14.1
+Release: 1
+License: BSD
+Group: Applications
+Source0: https://i3wm.org/i3lock/%{name}-%{version}.tar.xz
+# Source0-md5: 33d4bc8256a1566fbac911e405e53fdd
+Source1: %{name}.pam
+URL: https://i3wm.org/i3lock/
+BuildRequires: cairo-devel >= 1.14.4
+BuildRequires: libev-devel
+BuildRequires: libxcb-devel
+BuildRequires: meson >= 0.45.0
+BuildRequires: ninja
+BuildRequires: pam-devel
+BuildRequires: pkgconfig
+BuildRequires: rpmbuild(macros) >= 1.736
+BuildRequires: xcb-util-devel
+BuildRequires: xcb-util-image-devel
+BuildRequires: xcb-util-xrm-devel
+BuildRequires: xorg-lib-libxkbcommon-x11-devel
+Requires: cairo >= 1.14.4
+BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n)
+
+%description
+Minimalist screen locker based on slock.
+
+%prep
+%setup -q
+
+%build
+%meson build
+%ninja_build -C build
+
+%install
+rm -rf $RPM_BUILD_ROOT
+%ninja_install -C build
+install %{SOURCE1} $RPM_BUILD_ROOT/etc/pam.d/i3lock
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files
+%defattr(644,root,root,755)
+%doc LICENSE CHANGELOG
+%config(noreplace) %verify(not md5 mtime size) /etc/pam.d/i3lock
+%attr(755,root,root) %{_bindir}/i3lock
+%{_mandir}/man1/i3lock.1*
--
2.41.0
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: i3lock - spec file
On 11.07.2023 20:30, Mateusz Kocielski wrote:
> Dnia Tue, Jul 11, 2023 at 03:59:41PM +, Mateusz Kocielski napisał(a):
> > > That's peculiar -- what screen locker needs suid bit for? Why wheel
> > > group?
> >
> > Wheel group is taken from my BSD heritage I guess, fixed it. :) It requires
> > PAM for an authentication.
> >
> > > > %{_mandir}/man1/i3lock.1*
>
> Hi,
>
> those suid privileges were bothering me and I did my homework, it seems that
> on Linux i3lock can work without them because of the unix_chkpwd(8) utility.
> On the FreeBSD (which uses OpenPAM) however SUID is necessary [1]. The reason
> why I couldn't get it work without root privileges was /etc/pam.d/login
> file which is installed with u-r permission by default. I guess there's no
> need to keep it that way since PAM configuration rather not contain any
> secrets. I attached fixed version of the spec file and patch against
> util-linux to set u+r permissions. Thanks for your suggestions!
Override pam configuration shipped with i3lock with custom one that has:
auth include system-auth
just like (all?) other screensavers/lockers and it should be fine.
Other than this
1. Fix case in Summary:
2. Update required macros according to linked BuildRequires.txt (for
%ninja_* macros)
3. Clone empty pld repository for i3lock or just create a local git
repo, commit the spec and pam file and attach output of
`git format-patch -1` so authorship will be preserved correctly when
applying.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: i3lock - spec file
Dnia Tue, Jul 11, 2023 at 03:59:41PM +, Mateusz Kocielski napisał(a):
> > That's peculiar -- what screen locker needs suid bit for? Why wheel
> > group?
>
> Wheel group is taken from my BSD heritage I guess, fixed it. :) It requires
> PAM for an authentication.
>
> > > %{_mandir}/man1/i3lock.1*
Hi,
those suid privileges were bothering me and I did my homework, it seems that
on Linux i3lock can work without them because of the unix_chkpwd(8) utility.
On the FreeBSD (which uses OpenPAM) however SUID is necessary [1]. The reason
why I couldn't get it work without root privileges was /etc/pam.d/login
file which is installed with u-r permission by default. I guess there's no
need to keep it that way since PAM configuration rather not contain any
secrets. I attached fixed version of the spec file and patch against
util-linux to set u+r permissions. Thanks for your suggestions!
[1] -
https://cgit.freebsd.org/ports/tree/deskutils/i3lock/Makefile?id=924204922ac441410520f46695dd91a87c001ee9#n27
Regards,
Mateusz
>From 1e9086102e3c09827475a221ecba2745b519b2e6 Mon Sep 17 00:00:00 2001
From: Mateusz Kocielski
Date: Tue, 11 Jul 2023 22:11:18 +0200
Subject: [PATCH] Add u+r for /etc/pam.d/ configuration files
---
util-linux.spec | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/util-linux.spec b/util-linux.spec
index aeb33fa..e84b4f0 100644
--- a/util-linux.spec
+++ b/util-linux.spec
@@ -1344,10 +1344,10 @@ fi
%attr(755,root,root) /bin/runuser
%attr(755,root,root) /sbin/runuser
%attr(4755,root,root) /bin/su
-%attr(640,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/runuser
-%attr(640,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/runuser-l
-%attr(640,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/su
-%attr(640,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/su-l
+%attr(644,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/runuser
+%attr(644,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/runuser-l
+%attr(644,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/su
+%attr(644,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/su-l
%{_mandir}/man1/runuser.1*
%{_mandir}/man1/su.1*
%lang(cs) %{_mandir}/cs/man1/su.1*
@@ -2240,7 +2240,7 @@ fi
%files -n login
%defattr(644,root,root,755)
-%attr(640,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/login
+%attr(644,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/login
%attr(640,root,root) %config(noreplace) %verify(not md5 mtime size) /etc/security/blacklist.login
%attr(755,root,root) /bin/login
%{_mandir}/man1/login.1*
--
2.41.0
Summary:improved screen locker
Name: i3lock
Version:2.14.1
Release:1
License:BSD
Group: Applications
Source0:https://i3wm.org/i3lock/%{name}-%{version}.tar.xz
# Source0-md5: 33d4bc8256a1566fbac911e405e53fdd
URL:https://i3wm.org/i3lock/
BuildRequires: cairo-devel >= 1.14.4
BuildRequires: libev-devel
BuildRequires: libxcb-devel
BuildRequires: meson >= 0.45.0
BuildRequires: ninja
BuildRequires: pam-devel
BuildRequires: pkgconfig
BuildRequires: rpmbuild(macros) >= 1.726
BuildRequires: xcb-util-devel
BuildRequires: xcb-util-image-devel
BuildRequires: xcb-util-xrm-devel
BuildRequires: xorg-lib-libxkbcommon-x11-devel
Requires: cairo >= 1.14.4
BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n)
%description
Minimalist screen locker based on slock.
%prep
%setup -q
%build
%meson build
%ninja_build -C build
%install
rm -rf $RPM_BUILD_ROOT
%ninja_install -C build
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(644,root,root,755)
%doc LICENSE CHANGELOG
%config(noreplace) %verify(not md5 mtime size) /etc/pam.d/i3lock
%attr(755,root,root) %{_bindir}/i3lock
%{_mandir}/man1/i3lock.1*
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: i3lock - spec file
Dnia Tue, Jul 11, 2023 at 01:36:19PM +0200, Jan Palus napisał(a):
> Hi,
>
> thanks for contributing! Overall looks good. Some comments below.
>
Hello,
thanks for your helpful comments, below my comments and fixed version of the
spec.
> > Summary:improved screen locker
>
> Start summary with capital letter unless it starts with a name that goes
> lower case.
>
It seems that's convention that developers made, so I kept it. Other example
is here: https://github.com/pld-linux/i3/blob/master/i3.spec#L1 . OTOH maybe
it should be changed in both places.
> > Name: i3lock
> > Version:2.14.1
> > Release:1
> > License:BSD
> > Group: Applications
> > Source0:https://i3wm.org/i3lock/%{name}-%{version}.tar.xz
> > # Source0-md5: 33d4bc8256a1566fbac911e405e53fdd
> > URL:https://i3wm.org/i3lock/
> > BuildRequires: cairo-devel
>
> cairo is required with version at least 1.14.4.
Fixed, thanks.
> > BuildRequires: libev-devel
> > BuildRequires: libxcb-devel
> > BuildRequires: meson >= 0.45.0
> > BuildRequires: ninja
> > BuildRequires: pam-devel
> > BuildRequires: pkgconfig
> > BuildRequires: xcb-util-devel
> > BuildRequires: xcb-util-image-devel
> > BuildRequires: xcb-util-xrm-devel
> > BuildRequires: xorg-lib-libX11-devel
>
> Can't see direct dependency on xorg-lib-libX11-devel.
You're right, removed. Did you catch that manually?
> > BuildRequires: xorg-lib-libxkbcommon-x11-devel
> > BuildRequires: rpmbuild(macros) >= 1.726
>
> Keep it sorted and use tabs instead (run adapter script).
That's interesting, I ran this script before sending it to the mailing list.
I'll investigate it later, for now I fixed it manually.
> > Requires: libxcb
> > Requires: pam
> > Requires: xcb-util
> > Requires: xcb-util-image
> > Requires: xcb-util-xrm
> > Requires: xorg-lib-libxkbcommon-x11
>
> No need to give explicit Requires: for libraries linked to main binary
> unless specific version is required (like in case of cair).
>
Makes sense, fixed.
> > BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n)
> >
> > %description
> > Minimalist screen locker based on slock.
> >
> > %prep
> > %setup -q
> >
> > %build
> > %meson build
> > %ninja_build -C build
>
> For additional BuildRequires: check:
>
> http://cvs.pld-linux.org/cgi-bin/viewvc.cgi/cvs/PLD-doc/BuildRequires.txt
> >
> > %install
> > rm -rf $RPM_BUILD_ROOT
> > %ninja_install -C build
> >
> > %clean
> > rm -rf $RPM_BUILD_ROOT
> >
> > %files
> > %defattr(644,root,root,755)
>
> LICENSE states it needs to be distributed with binaries so include it in
> %doc.
>
Good catch, thanks! Fixed.
> > %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/i3lock
> > %attr(4755,root,wheel) %{_bindir}/i3lock
>
> That's peculiar -- what screen locker needs suid bit for? Why wheel
> group?
Wheel group is taken from my BSD heritage I guess, fixed it. :) It requires
PAM for an authentication.
> > %{_mandir}/man1/i3lock.1*
Thanks,
Mateusz
Summary:improved screen locker
Name: i3lock
Version:2.14.1
Release:1
License:BSD
Group: Applications
Source0:https://i3wm.org/i3lock/%{name}-%{version}.tar.xz
# Source0-md5: 33d4bc8256a1566fbac911e405e53fdd
URL:https://i3wm.org/i3lock/
BuildRequires: cairo-devel >= 1.14.4
BuildRequires: libev-devel
BuildRequires: libxcb-devel
BuildRequires: meson >= 0.45.0
BuildRequires: ninja
BuildRequires: pam-devel
BuildRequires: pkgconfig
BuildRequires: rpmbuild(macros) >= 1.726
BuildRequires: xcb-util-devel
BuildRequires: xcb-util-image-devel
BuildRequires: xcb-util-xrm-devel
BuildRequires: xorg-lib-libxkbcommon-x11-devel
Requires: cairo >= 1.14.4
BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n)
%description
Minimalist screen locker based on slock.
%prep
%setup -q
%build
%meson build
%ninja_build -C build
%install
rm -rf $RPM_BUILD_ROOT
%ninja_install -C build
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(644,root,root,755)
%doc LICENSE CHANGELOG
%config(noreplace) %verify(not md5 mtime size) /etc/pam.d/i3lock
%attr(4755,root,root) %{_bindir}/i3lock
%{_mandir}/man1/i3lock.1*
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: i3lock - spec file
Hi,
thanks for contributing! Overall looks good. Some comments below.
On 11.07.2023 10:29, Mateusz Kocielski wrote:
> Hi there,
>
> I've prepared spec file to build i3lock [1]. This is my first spec file, so
> please review it carefully. The software requires suid to be able to verify
> password provided by user.
>
> [1] - https://i3wm.org/i3lock/
>
> Thanks,
> Mateusz
> Summary: improved screen locker
Start summary with capital letter unless it starts with a name that goes
lower case.
> Name: i3lock
> Version: 2.14.1
> Release: 1
> License: BSD
> Group:Applications
> Source0: https://i3wm.org/i3lock/%{name}-%{version}.tar.xz
> # Source0-md5:33d4bc8256a1566fbac911e405e53fdd
> URL: https://i3wm.org/i3lock/
> BuildRequires:cairo-devel
cairo is required with version at least 1.14.4.
> BuildRequires:libev-devel
> BuildRequires:libxcb-devel
> BuildRequires:meson >= 0.45.0
> BuildRequires:ninja
> BuildRequires:pam-devel
> BuildRequires:pkgconfig
> BuildRequires:xcb-util-devel
> BuildRequires:xcb-util-image-devel
> BuildRequires:xcb-util-xrm-devel
> BuildRequires:xorg-lib-libX11-devel
Can't see direct dependency on xorg-lib-libX11-devel.
> BuildRequires:xorg-lib-libxkbcommon-x11-devel
> BuildRequires: rpmbuild(macros) >= 1.726
Keep it sorted and use tabs instead (run adapter script).
> Requires: libxcb
> Requires: pam
> Requires: xcb-util
> Requires: xcb-util-image
> Requires: xcb-util-xrm
> Requires: xorg-lib-libxkbcommon-x11
No need to give explicit Requires: for libraries linked to main binary
unless specific version is required (like in case of cair).
> BuildRoot:%{tmpdir}/%{name}-%{version}-root-%(id -u -n)
>
> %description
> Minimalist screen locker based on slock.
>
> %prep
> %setup -q
>
> %build
> %meson build
> %ninja_build -C build
For additional BuildRequires: check:
http://cvs.pld-linux.org/cgi-bin/viewvc.cgi/cvs/PLD-doc/BuildRequires.txt
>
> %install
> rm -rf $RPM_BUILD_ROOT
> %ninja_install -C build
>
> %clean
> rm -rf $RPM_BUILD_ROOT
>
> %files
> %defattr(644,root,root,755)
LICENSE states it needs to be distributed with binaries so include it in
%doc.
> %config(noreplace) %verify(not md5 mtime size) /etc/pam.d/i3lock
> %attr(4755,root,wheel) %{_bindir}/i3lock
That's peculiar -- what screen locker needs suid bit for? Why wheel
group?
> %{_mandir}/man1/i3lock.1*
> ___
> pld-devel-en mailing list
> pld-devel-en@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Wrong time (Re: DISTFILES: freetype: freetype-2.13.1.tar.xz freetype-doc-2.13.1.tar.xz ft2demos-2.13.1.tar.xz)
On 26.06.2023 10:38, Arkadiusz Miśkiewicz via pld-devel-en wrote: > On 26.06.2023 10:31, atler wrote: > > On 26.06.2023 11:24, atler wrote: > > > Request by: atler > > > > > > > > > Files fetched: 1 > > > > > > ALREADY GOT: > > > https://download.savannah.gnu.org/releases/freetype/freetype-2.13.1.tar.xz > > > e4c3f0d8453a2a7993ae784912d6f19a freetype-2.13.1.tar.xz > > > STORED: > > > https://download.savannah.gnu.org/releases/freetype/freetype-doc-2.13.1.tar.xz > > > 9eaaf193b0493297d92cd435cd850598 freetype-doc-2.13.1.tar.xz > > > Size: 2173864 bytes > > > ALREADY GOT: > > > https://download.savannah.gnu.org/releases/freetype/ft2demos-2.13.1.tar.xz > > > d76ec9572d018591a502bfdce312010f ft2demos-2.13.1.tar.xz > > > > > Not that it bothers me much but looks like it was "11:24 CEST" > > somewhere while it should have been "10:17 CEST": > > Fixed date (on cvs...) Looks like there is still some issue: Received: from cvs.pld-linux.org (cvs.pld-linux.org [217.73.31.16]) by lists.pld-linux.org (Postfix) with ESMTPS for ; Fri, 30 Jun 2023 09:29:39 +0200 (CEST) ^^ Received: from git by cvs.pld-linux.org with local (Exim 4.96) (envelope-from ) id 1qF9gp-0008Hm-0m for pld-cvs-com...@lists.pld-linux.org; Fri, 30 Jun 2023 10:41:15 +0200 ^^^ To: pld-cvs-com...@lists.pld-linux.org From: atler Subject: [packages/php] icu rebuild ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Wrong time (Re: DISTFILES: freetype: freetype-2.13.1.tar.xz freetype-doc-2.13.1.tar.xz ft2demos-2.13.1.tar.xz)
On 26.06.2023 10:31, atler wrote: On 26.06.2023 11:24, atler wrote: Request by: atler Files fetched: 1 ALREADY GOT: https://download.savannah.gnu.org/releases/freetype/freetype-2.13.1.tar.xz e4c3f0d8453a2a7993ae784912d6f19a freetype-2.13.1.tar.xz STORED: https://download.savannah.gnu.org/releases/freetype/freetype-doc-2.13.1.tar.xz 9eaaf193b0493297d92cd435cd850598 freetype-doc-2.13.1.tar.xz Size: 2173864 bytes ALREADY GOT: https://download.savannah.gnu.org/releases/freetype/ft2demos-2.13.1.tar.xz d76ec9572d018591a502bfdce312010f ft2demos-2.13.1.tar.xz Not that it bothers me much but looks like it was "11:24 CEST" somewhere while it should have been "10:17 CEST": Fixed date (on cvs...) -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Wrong time (Re: DISTFILES: freetype: freetype-2.13.1.tar.xz freetype-doc-2.13.1.tar.xz ft2demos-2.13.1.tar.xz)
On 26.06.2023 11:24, atler wrote: > Request by: atler > > > Files fetched: 1 > > ALREADY GOT: > https://download.savannah.gnu.org/releases/freetype/freetype-2.13.1.tar.xz > e4c3f0d8453a2a7993ae784912d6f19a freetype-2.13.1.tar.xz > STORED: > https://download.savannah.gnu.org/releases/freetype/freetype-doc-2.13.1.tar.xz > 9eaaf193b0493297d92cd435cd850598 freetype-doc-2.13.1.tar.xz > Size: 2173864 bytes > ALREADY GOT: > https://download.savannah.gnu.org/releases/freetype/ft2demos-2.13.1.tar.xz > d76ec9572d018591a502bfdce312010f ft2demos-2.13.1.tar.xz > Not that it bothers me much but looks like it was "11:24 CEST" somewhere while it should have been "10:17 CEST": > Received: from cvs.pld-linux.org (cvs.pld-linux.org [217.73.31.16]) > by lists.pld-linux.org (Postfix) with ESMTPS > for ; > Mon, 26 Jun 2023 10:17:03 +0200 (CEST) > Received: from dfadm by cvs.pld-linux.org with local (Exim 4.96) > (envelope-from ) id 1qDiSo-00048g-2T > for pld-cvs-com...@lists.pld-linux.org; > Mon, 26 Jun 2023 11:24:50 +0200 ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Inconsistent repo metadata
On Sat, 24 Jun 2023, Jan Palus wrote: > $ dnf clean all > $ dnf download rpm-whiteout > PLD Linux (Th) - Architecture specific > 16 MB/s | 17 MB 00:01 > PLD Linux (Th) - Architecture independent > 13 MB/s | 17 MB 00:01 > Last metadata expiration check: 0:00:05 ago on sob, 24 cze 2023, 20:55:11. > [MIRROR] rpm-whiteout-1.41-4.noarch.rpm: Interrupted by header callback: > Inconsistent server data, reported file Content-Length: 4738, repository > metadata states file length: 4610 (please report to repository maintainer) > [MIRROR] rpm-whiteout-1.41-4.noarch.rpm: Interrupted by header callback: > Inconsistent server data, reported file Content-Length: 4738, repository > metadata states file length: 4610 (please report to repository maintainer) > [MIRROR] rpm-whiteout-1.41-4.noarch.rpm: Interrupted by header callback: > Inconsistent server data, reported file Content-Length: 4738, repository > metadata states file length: 4610 (please report to repository maintainer) > [MIRROR] rpm-whiteout-1.41-4.noarch.rpm: Interrupted by header callback: > Inconsistent server data, reported file Content-Length: 4738, repository > metadata states file length: 4610 (please report to repository maintainer) > [FAILED] rpm-whiteout-1.41-4.noarch.rpm: No more mirrors to try - All mirrors > were already tried without success Weird. I had to delete repodata and regenerate it from scratch. Works now. -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: remmina not working after llvm upgrade
On 26.05.2023 02:18, Jan Palus wrote: On 25.05.2023 15:41, Krzysztof Mrozowicz via pld-devel-en wrote: Dnia 2023-05-25, o godz. 14:59:56 Jan Palus [1] napisal/(a): Yes, that's after reboot. Could be Mesa, it's upgraded too.. Do you mind sharing output (remmina.strace) of: strace -o remmina.strace -f -e '/open.*' -z remmina I observe a similar problem on my computer. The strace file can be found at [2]https://pastebin.com/KuXzXaYP Thank you both for sharing strace output. Can you try upgrading SPIRV-LLVM-Translator* spirv-tools* and Mesa* and see if it helps? Works Thanks! Now I can log into my favorite OS ;-) -- Andrzej Zawadzki References 1. mailto:at...@pld-linux.org 2. https://pastebin.com/KuXzXaYP ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: remmina not working after llvm upgrade
On 25.05.2023 15:41, Krzysztof Mrozowicz via pld-devel-en wrote: > Dnia 2023-05-25, o godz. 14:59:56 > Jan Palus napisał(a): > > > > > > >Yes, that's after reboot. Could be Mesa, it's upgraded too.. > > > > Do you mind sharing output (remmina.strace) of: > > > > strace -o remmina.strace -f -e '/open.*' -z remmina > > I observe a similar problem on my computer. The strace file can be > found at https://pastebin.com/KuXzXaYP Thank you both for sharing strace output. Can you try upgrading SPIRV-LLVM-Translator* spirv-tools* and Mesa* and see if it helps? ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: remmina not working after llvm upgrade
Dnia 2023-05-25, o godz. 14:59:56 Jan Palus napisał(a): > > > >Yes, that's after reboot. Could be Mesa, it's upgraded too.. > > Do you mind sharing output (remmina.strace) of: > > strace -o remmina.strace -f -e '/open.*' -z remmina I observe a similar problem on my computer. The strace file can be found at https://pastebin.com/KuXzXaYP Regards -- Krzysiek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: remmina not working after llvm upgrade
On 25.05.2023 13:14, Andrzej Zawadzki wrote: >On 25.05.2023 12:35, Jan Palus wrote: > > On 25.05.2023 12:04, Andrzej Zawadzki wrote: > >Hi! > >$ remmina >** Message: 11:54:59.423: Remmina does not log all output statements. >Turn on more verbose output by using "G_MESSAGES_DEBUG=all" as an >environment variable. >More info available on the Remmina wiki at: >[1][1]https://gitlab.com/Remmina/Remmina/-/wikis/Usage/Remmina-debugging >Load modules from /usr/lib64/remmina/plugins >Remmina plugin glibsecret (type=Secret) has been registered, but is not >yet initialized/activated. The initialization order is 2000. >The glibsecret secret plugin has been initialized and it will be your >default secret plugin >(org.remmina.Remmina:9625): Gtk-WARNING **: 11:55:00.227: >gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem >: CommandLine Error: Option 'use-dbg-addr' registered more than once! >LLVM ERROR: inconsistency in registered CommandLine options >Aborted (core dumped) >Rebuild needed? > > Works fine for me. I doubt Remmina has anything to do with LLVM > directly so rebuild wouldn't change anything. Judging by Google results > this could possibly be coming from a Mesa driver. Did you restart your > GUI session (X/Wayland) after an upgrade to make sure new driver is > running? > >Yes, that's after reboot. Could be Mesa, it's upgraded too.. Do you mind sharing output (remmina.strace) of: strace -o remmina.strace -f -e '/open.*' -z remmina ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: remmina not working after llvm upgrade
On 25.05.2023 12:35, Jan Palus wrote: On 25.05.2023 12:04, Andrzej Zawadzki wrote: Hi! $ remmina ** Message: 11:54:59.423: Remmina does not log all output statements. Turn on more verbose output by using "G_MESSAGES_DEBUG=all" as an environment variable. More info available on the Remmina wiki at: [1][1]https://gitlab.com/Remmina/Remmina/-/wikis/Usage/Remmina-debugging Load modules from /usr/lib64/remmina/plugins Remmina plugin glibsecret (type=Secret) has been registered, but is not yet initialized/activated. The initialization order is 2000. The glibsecret secret plugin has been initialized and it will be your default secret plugin (org.remmina.Remmina:9625): Gtk-WARNING **: 11:55:00.227: gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem : CommandLine Error: Option 'use-dbg-addr' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options Aborted (core dumped) Rebuild needed? Works fine for me. I doubt Remmina has anything to do with LLVM directly so rebuild wouldn't change anything. Judging by Google results this could possibly be coming from a Mesa driver. Did you restart your GUI session (X/Wayland) after an upgrade to make sure new driver is running? Yes, that's after reboot. Could be Mesa, it's upgraded too.. -- Andrzej Zawadzki References 1. https://gitlab.com/Remmina/Remmina/-/wikis/Usage/Remmina-debugging ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: remmina not working after llvm upgrade
On 25.05.2023 12:04, Andrzej Zawadzki wrote: >Hi! > >$ remmina >** Message: 11:54:59.423: Remmina does not log all output statements. >Turn on more verbose output by using "G_MESSAGES_DEBUG=all" as an >environment variable. >More info available on the Remmina wiki at: >[1]https://gitlab.com/Remmina/Remmina/-/wikis/Usage/Remmina-debugging >Load modules from /usr/lib64/remmina/plugins >Remmina plugin glibsecret (type=Secret) has been registered, but is not >yet initialized/activated. The initialization order is 2000. >The glibsecret secret plugin has been initialized and it will be your >default secret plugin >(org.remmina.Remmina:9625): Gtk-WARNING **: 11:55:00.227: >gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem >: CommandLine Error: Option 'use-dbg-addr' registered more than once! >LLVM ERROR: inconsistency in registered CommandLine options >Aborted (core dumped) >Rebuild needed? Works fine for me. I doubt Remmina has anything to do with LLVM directly so rebuild wouldn't change anything. Judging by Google results this could possibly be coming from a Mesa driver. Did you restart your GUI session (X/Wayland) after an upgrade to make sure new driver is running? ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Qt packaging
On Fri, Jul 22, 2022 at 11:03:54AM +0200, Jan Rękorajski wrote: > Can someone explain why are we using split sources/packages for Qt? Beside build time and space requirements, I see one more reason now: rebuilding after dependent package soname change is more painful. Current case: jasper 3.x. Split case: just qt5-qtimageformats.spec to rebuild Monolithic case: whole qt6.spec to rebuild -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: GitHub key needs an update
On 24.03.2023 12:42, Jan Palus wrote: That's expected and GitHub host key needs an update, see: https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/ Updated. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm-pld-macros] Add _metainfodir, rev 2.023
On 22.02.2023 21:38, Jan Palus wrote:
On 22.02.2023 19:55, glen wrote:
commit fa6a978633bd3fbae3c510fb6299ddb67af8da00
Author: Elan Ruusamäe
Date: Wed Feb 22 20:54:40 2023 +0200
Add _metainfodir, rev 2.023
- https://src.fedoraproject.org/rpms/redhat-rpm-config/c/67e46b630d5d0bc74188b2ea5aa36eff5117ddc9?branch=f27
...
--- a/macros.pld
+++ b/macros.pld
@@ -25,6 +25,8 @@
%_lispdir %{_datadir}/emacs/site-lisp
%_initddir%{_sysconfdir}/rc.d/init.d
+%_metainfodir %{_datadir}/appdata
Shouldn't this point to non-legacy %{_datadir}/metainfo instead?
https://freedesktop.org/software/appstream/docs/chap-Metadata.html#spec-component-location
changed:
-
https://github.com/pld-linux/rpm-pld-macros/commit/d242d4da01feb055dbbc7187712e200e07022488
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm-pld-macros] Add _metainfodir, rev 2.023
On 22.02.2023 19:55, glen wrote:
> commit fa6a978633bd3fbae3c510fb6299ddb67af8da00
> Author: Elan Ruusamäe
> Date: Wed Feb 22 20:54:40 2023 +0200
>
> Add _metainfodir, rev 2.023
>
> -
> https://src.fedoraproject.org/rpms/redhat-rpm-config/c/67e46b630d5d0bc74188b2ea5aa36eff5117ddc9?branch=f27
...
> --- a/macros.pld
> +++ b/macros.pld
> @@ -25,6 +25,8 @@
> %_lispdir%{_datadir}/emacs/site-lisp
> %_initddir %{_sysconfdir}/rc.d/init.d
>
> +%_metainfodir%{_datadir}/appdata
Shouldn't this point to non-legacy %{_datadir}/metainfo instead?
https://freedesktop.org/software/appstream/docs/chap-Metadata.html#spec-component-location
Perhaps _appdatadir for legacy locations.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/texlive/TEXLIVE_20080816] fix "sh: syntax error: unexpected '('" during file processing
On 30.01.2023 14:26, atler wrote: -%define_noautoreq 'perl(path_tre)' +%define_noautoreq perl\\(path_tre\\) just use _noautoreq_perl ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: lists test
W dniu wt., 7.02.2023 o 21:37 Arkadiusz Miśkiewicz via pld-devel-en < pld-devel-en@lists.pld-linux.org> napisał(a): > 123... Nope, doesn't work. -- Łukasz [Deejay1] Jernaś ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: lists test
Dnia wtorek, 7 lutego 2023 21:37:29 CET Arkadiusz Miśkiewicz via pld-devel-en pisze: > 123... Seems to work. -- Łukasz Maśko_o) Lukasz.Masko(at)ipipan.waw.pl /\\ Registered Linux User #61028 _\_V Ubuntu: staroafrykańskie słowo oznaczające "Nie umiem zainstalować Debiana" ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rust on carme-x32
On 20.01.2023 22:04, Jakub Bogusz wrote: On Thu, Jan 19, 2023 at 09:14:51AM +0100, Arkadiusz Miśkiewicz via pld-devel-en wrote: On 18.01.2023 16:08, Jakub Bogusz wrote: Could rust be installed on carme-x32? I'd like to (try to) fix mozjs102 build (required for new gjs), but I cannot install rust myself because of x86_64 packages requirements. Should be available now. I need cargo as well (requires 64-bit curl, libgit2 and openssl libs). Installed. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rust on carme-x32
On Thu, Jan 19, 2023 at 09:14:51AM +0100, Arkadiusz Miśkiewicz via pld-devel-en wrote: > On 18.01.2023 16:08, Jakub Bogusz wrote: > >Could rust be installed on carme-x32? > > > >I'd like to (try to) fix mozjs102 build (required for new gjs), but > >I cannot install rust myself because of x86_64 packages requirements. > > > > > > Should be available now. I need cargo as well (requires 64-bit curl, libgit2 and openssl libs). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rust on carme-x32
On 18.01.2023 16:08, Jakub Bogusz wrote: Could rust be installed on carme-x32? I'd like to (try to) fix mozjs102 build (required for new gjs), but I cannot install rust myself because of x86_64 packages requirements. Should be available now. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: x32 builder has network access
On 18.01.2023 16:48, Jakub Bogusz wrote: > On Wed, Jan 18, 2023 at 01:02:34PM +0100, Arkadiusz Miśkiewicz via > pld-devel-en wrote: > > On 18.01.2023 09:56, Jan Palus wrote: > > >On 18.01.2023 07:54, Arkadiusz Miśkiewicz via pld-devel-en wrote: > > >>On 17.01.2023 12:23, Jan Palus wrote: > > >>>Noticed during build of kodi-addon-inputstream-adaptive that contrary to > > >>>x86_64 and i686, x32 builder downloaded external sources successfully: > > >> > > >>bind was installed there and seems that even if there is no access to > > >>/etc/resolv.conf glibc fallbacks to querying 127.0.0.1:53 > > >> > > >>Uninstalled. > > >> > > >>The best would be to change UID of "builder" user used inside of chroot > > >>and drop all outgoing packets coming from it at iptables level. > > > > > >Or perhaps modify pld-builder to make each rpmbuild invocation in a new > > >network namespace via `unshare -n -c`. That would effectively cut whole > > >network for the process. > > > > We can try that... commited. > > i686 and x86_64 say: > "unshare: unshare failed: Operation not permitted" Unfortunately it appears it's not possible to create user namespaces in a chroot: EPERM (since Linux 3.9) CLONE_NEWUSER was specified in flags and the caller is in a chroot environment (i.e., the caller's root directory does not match the root directory of the mount namespace in which it resides). ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: x32 builder has network access
On Wed, Jan 18, 2023 at 01:02:34PM +0100, Arkadiusz Miśkiewicz via pld-devel-en wrote: > On 18.01.2023 09:56, Jan Palus wrote: > >On 18.01.2023 07:54, Arkadiusz Miśkiewicz via pld-devel-en wrote: > >>On 17.01.2023 12:23, Jan Palus wrote: > >>>Noticed during build of kodi-addon-inputstream-adaptive that contrary to > >>>x86_64 and i686, x32 builder downloaded external sources successfully: > >> > >>bind was installed there and seems that even if there is no access to > >>/etc/resolv.conf glibc fallbacks to querying 127.0.0.1:53 > >> > >>Uninstalled. > >> > >>The best would be to change UID of "builder" user used inside of chroot > >>and drop all outgoing packets coming from it at iptables level. > > > >Or perhaps modify pld-builder to make each rpmbuild invocation in a new > >network namespace via `unshare -n -c`. That would effectively cut whole > >network for the process. > > We can try that... commited. i686 and x86_64 say: "unshare: unshare failed: Operation not permitted" Still waiting for x32 (seems busy with openjdks). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: x32 builder has network access
On 18.01.2023 09:56, Jan Palus wrote: On 18.01.2023 07:54, Arkadiusz Miśkiewicz via pld-devel-en wrote: On 17.01.2023 12:23, Jan Palus wrote: Noticed during build of kodi-addon-inputstream-adaptive that contrary to x86_64 and i686, x32 builder downloaded external sources successfully: bind was installed there and seems that even if there is no access to /etc/resolv.conf glibc fallbacks to querying 127.0.0.1:53 Uninstalled. The best would be to change UID of "builder" user used inside of chroot and drop all outgoing packets coming from it at iptables level. Or perhaps modify pld-builder to make each rpmbuild invocation in a new network namespace via `unshare -n -c`. That would effectively cut whole network for the process. We can try that... commited. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: x32 builder has network access
On 18.01.2023 07:54, Arkadiusz Miśkiewicz via pld-devel-en wrote: > On 17.01.2023 12:23, Jan Palus wrote: > > Noticed during build of kodi-addon-inputstream-adaptive that contrary to > > x86_64 and i686, x32 builder downloaded external sources successfully: > > bind was installed there and seems that even if there is no access to > /etc/resolv.conf glibc fallbacks to querying 127.0.0.1:53 > > Uninstalled. > > The best would be to change UID of "builder" user used inside of chroot > and drop all outgoing packets coming from it at iptables level. Or perhaps modify pld-builder to make each rpmbuild invocation in a new network namespace via `unshare -n -c`. That would effectively cut whole network for the process. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: x32 builder has network access
On 17.01.2023 12:23, Jan Palus wrote: Noticed during build of kodi-addon-inputstream-adaptive that contrary to x86_64 and i686, x32 builder downloaded external sources successfully: bind was installed there and seems that even if there is no access to /etc/resolv.conf glibc fallbacks to querying 127.0.0.1:53 Uninstalled. The best would be to change UID of "builder" user used inside of chroot and drop all outgoing packets coming from it at iptables level. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: udev-core R >= 4.15
On 22.12.2022 11:49, Arkadiusz Miśkiewicz via pld-devel-en wrote: > udev-core change: > > -Requires: uname(release) >= 3.13 > +Requires: uname(release) >= 4.15 > > > Is this true requirement? This R: was updated purely based on very first entry in release notes for 251: Backwards-incompatible changes: * The minimum kernel version required has been bumped from 3.13 to 4.15, and CLOCK_BOOTTIME is now assumed to always exist. If it actually works with lower kernel versions feel free to adjust. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: DISTFILES: qt6: ERRORS: qt-everywhere-src-6.3.2.tar.xz
On 30.10.2022 18:08, Jan Palus wrote: On 24.10.2022 09:17, Jan Palus wrote: On 24.10.2022 09:13, atler wrote: Request by: atler wget -nv --no-iri --user-agent=PLD/distfiles -O ./tmp/c988e5de-3fbe-4f8d-9c0e-892a6cc71ea2/bc928a9897698ec397b11c3dbff40e53/qt-everywhere-src-6.3.2.tar.xz https://download.qt.io/official_releases/qt/6.3/6.3.2/single/qt-everywhere-src-6.3.2.tar.xz: Cannot write to ???./tmp/c988e5de-3fbe-4f8d-9c0e-892a6cc71ea2/bc928a9897698ec397b11c3dbff40e53/qt-everywhere-src-6.3.2.tar.xz??? (Success). Can someone have a look what's that about? Noticed it before for larger sources like firefox but usually retry succeeded. qt6 on the other hand fails consistently. Also fails with `dropin` script after transferring ~264M: firefox-106.0.2.source.tar.xz54% 264MB 5.1MB/s 00:42 ETA scp: write remote "./firefox-106.0.2.source.tar.xz": Failure scp: failed to upload file firefox-106.0.2.source.tar.xz to . dropin is on cvs and there was no free space there. Added some. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: DISTFILES: qt6: ERRORS: qt-everywhere-src-6.3.2.tar.xz
On 24.10.2022 09:17, Jan Palus wrote: > On 24.10.2022 09:13, atler wrote: > > Request by: atler > > > > wget -nv --no-iri --user-agent=PLD/distfiles -O > > ./tmp/c988e5de-3fbe-4f8d-9c0e-892a6cc71ea2/bc928a9897698ec397b11c3dbff40e53/qt-everywhere-src-6.3.2.tar.xz > > > > https://download.qt.io/official_releases/qt/6.3/6.3.2/single/qt-everywhere-src-6.3.2.tar.xz: > > Cannot write to > > ???./tmp/c988e5de-3fbe-4f8d-9c0e-892a6cc71ea2/bc928a9897698ec397b11c3dbff40e53/qt-everywhere-src-6.3.2.tar.xz??? > > (Success). > > Can someone have a look what's that about? Noticed it before for larger > sources like firefox but usually retry succeeded. qt6 on the other hand > fails consistently. Also fails with `dropin` script after transferring ~264M: firefox-106.0.2.source.tar.xz54% 264MB 5.1MB/s 00:42 ETA scp: write remote "./firefox-106.0.2.source.tar.xz": Failure scp: failed to upload file firefox-106.0.2.source.tar.xz to . ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: DISTFILES: qt6: ERRORS: qt-everywhere-src-6.3.2.tar.xz
On 24.10.2022 09:13, atler wrote: > Request by: atler > > wget -nv --no-iri --user-agent=PLD/distfiles -O > ./tmp/c988e5de-3fbe-4f8d-9c0e-892a6cc71ea2/bc928a9897698ec397b11c3dbff40e53/qt-everywhere-src-6.3.2.tar.xz > > https://download.qt.io/official_releases/qt/6.3/6.3.2/single/qt-everywhere-src-6.3.2.tar.xz: > Cannot write to > ???./tmp/c988e5de-3fbe-4f8d-9c0e-892a6cc71ea2/bc928a9897698ec397b11c3dbff40e53/qt-everywhere-src-6.3.2.tar.xz??? > (Success). Can someone have a look what's that about? Noticed it before for larger sources like firefox but usually retry succeeded. qt6 on the other hand fails consistently. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: pfa-signpkg resets tty echo after failed password input:
> On 20. Oct 2022, at 15:37, Elan Ruusamäe wrote: > > > > pldth@ep09-pld SRPMS/.metadata$ pfa-signpkg test *pecl* > Checking signatures of 164 files from 17 packages > 164/164 > /home/pld/admins/th/ftp/test/x86_64/debuginfo/php82-pecl-xmlrpc-debugsource-1.0.0-1.RC3.1.x86_64.rpm > Total 164 files to sign > Enter signing password: > Signing 164 files > /home/pld/admins/th/ftp/test/SRPMS/RPMS/php80-pecl-redis-5.3.7-1.src.rpm: > gpg: signing failed: Bad passphrase > gpg: signing failed: Bad passphrase > error: gpg exec failed (2) > /home/pld/admins/th/ftp/test/x86_64/debuginfo/php80-pecl-redis-debuginfo-5.3.7-1.x86_64.rpm: > Enter passphrase: lala Also aborted sign leaves temp files around: pldth@ep09-pld SRPMS/.metadata$ pfa-signpkg test *pecl* Checking signatures of 164 files from 17 packages 164/164 /home/pld/admins/th/ftp/test/x86_64/debuginfo/php82-pecl-xmlrpc-debugsource-1.0.0-1.RC3.1.x86_64.rpm Total 164 files to sign Enter signing password: Signing 164 files /home/pld/admins/th/ftp/test/SRPMS/RPMS/php80-pecl-redis-5.3.7-1.src.rpm: /home/pld/admins/th/ftp/test/x86_64/debuginfo/php80-pecl-redis-debuginfo-5.3.7-1.x86_64.rpm: File '/home/pld/admins/th/ftp/test/x86_64/debuginfo/php80-pecl-redis-debuginfo-5.3.7-1.x86_64.rpm.sig' exists. Overwrite? (y/N) y And then it seems it’s stuck, no idea what’s going on: pldth@ep09-pld SRPMS/.metadata$ lsp gpg www USER PID LXC PGRP STARTED TT VSZ RSS STAT CMD pldth28850 -28847 Thu Oct 20 15:37:55 2022 pts/5 8920 5124 SL+ gpg --no-verbose --no-armor --no-secmem-warning -u e4f1bc2d -sbo /home/pld/admins/th/ftp/test/x86_64/debuginfo/php80-pecl-redis-debuginfo-5.3.7-1.x86_64.rpm.sig - pldth@ep09-pld SRPMS/.metadata$ l /home/pld/admins/th/ftp/test/x86_64/debuginfo/*.sig -rw-r--r-- 1 pldth pldth 0 Oct 20 15:36 /home/pld/admins/th/ftp/test/x86_64/debuginfo/php80-pecl-redis-debuginfo-5.3.7-1.x86_64.rpm.sig ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/python3-git-filter-repo] - new, separated from git-filter-repo.spec (now with python metadata, required for e.g. b4)
On Mon, Oct 17, 2022 at 09:14:27PM +0300, Elan Ruusamäe wrote: > wth. how is this any good? > > just add the -n python3-git-filter-repo to main git-filter-repo package! > > with your package split and the require-line in old spec, you force us > to keep two .spec files up todate with each release of git-filter-repo, > additionally deal with sending to builders, and in proper order as well. > > why? github package doesn't contain metadata for python package (or data to generate them). pypi package doesn't contain docs for git side. Alternative solution could be single spec with both sources. But I didn't know the direction in which the distribution of this package would evolve, the last release so far was almost year ago. Now I see there is 2.38.0, I'll check it in few days. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/python3-git-filter-repo] - new, separated from git-filter-repo.spec (now with python metadata, required for e.g. b4)
wth. how is this any good?
just add the -n python3-git-filter-repo to main git-filter-repo package!
with your package split and the require-line in old spec, you force us
to keep two .spec files up todate with each release of git-filter-repo,
additionally deal with sending to builders, and in proper order as well.
why?
On 08.10.2022 21:51, qboosh wrote:
commit 61919f8f6ee682327311dfb153d2fb5474d1e622
Author: Jakub Bogusz
Date: Sat Oct 8 20:51:52 2022 +0200
- new, separated from git-filter-repo.spec (now with python metadata,
required for e.g. b4)
python3-git-filter-repo.spec | 53
1 file changed, 53 insertions(+)
---
diff --git a/python3-git-filter-repo.spec b/python3-git-filter-repo.spec
new file mode 100644
index 000..b402d05
--- /dev/null
+++ b/python3-git-filter-repo.spec
@@ -0,0 +1,53 @@
+Summary: Quickly rewrite git repository history
+Summary(pl.UTF-8): Szybkie przepisywanie historii repozytorium
+Name: python3-git-filter-repo
+Version: 2.34.0
+Release: 1
+License: MIT
+Group: Libraries/Python
+#Source0Download: https://pypi.org/simple/git-filter-repo/
+Source0:
https://files.pythonhosted.org/packages/source/g/git-filter-repo/git-filter-repo-%{version}.tar.gz
+# Source0-md5: 14825e3c78de704a0244092600bf1fdc
+URL: https://pypi.org/project/git-filter-repo/
+BuildRequires: python3-modules >= 1:3.5
+BuildRequires: python3-setuptools
+BuildRequires: python3-setuptools_scm
+BuildRequires: rpm-pythonprov
+BuildRequires: rpmbuild(macros) >= 1.714
+Requires: git-core >= 2.24.0
+Requires: python3-modules >= 1:3.5
+Conflicts: git-filter-repo < 2.34.0-2
+BuildArch: noarch
+BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n)
+
+%description
+git filter-repo is a versatile tool for rewriting history.
+
+%description -l pl.UTF-8
+git filter-repo to wszechstronne narzędzie do przepisywania historii.
+
+%prep
+%setup -q -n git-filter-repo-%{version}
+
+# fix #!/usr/bin/env python -> #!/usr/bin/python:
+%{__sed} -i -e '1s,/usr/bin/env python3,%{__python3},' git_filter_repo.py
+
+%build
+%py3_build
+
+%install
+rm -rf $RPM_BUILD_ROOT
+
+%py3_install
+
+%{__rm} $RPM_BUILD_ROOT%{_bindir}/git-filter-repo
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files
+%defattr(644,root,root,755)
+%doc README.md
+%{py3_sitescriptdir}/git_filter_repo.py
+%{py3_sitescriptdir}/__pycache__/git_filter_repo.cpython-*.py[co]
+%{py3_sitescriptdir}/git_filter_repo-%{version}-py*.egg-info
gitweb:
http://git.pld-linux.org/gitweb.cgi/packages/python3-git-filter-repo.git/commitdiff/61919f8f6ee682327311dfb153d2fb5474d1e622
___
pld-cvs-commit mailing list
pld-cvs-com...@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: freshness report not fresh
On Sat, 24 Sep 2022, Jan Palus wrote: > For some time now freshness report at > http://ep09.pld-linux.org/~pldth/qa.php?q=freshness does not seem to be > updated. Can someone have a look? Fixed. Leftover lock in SPECS repo :/ -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %_usrlibrpm macro gone
On Mon, Sep 19, 2022 at 6:08 PM Elan Ruusamäe wrote:
>
> rpm-4.17.1.1-1.x86_64
>
> dokuwiki* packages don’t build due that:
>
> ```
>
> + %{_usrlibrpm}/dokuwiki-find-lang.sh
> /home/users/glen/tmp/dokuwiki-20180422c-x86_64-root-glen dokuwiki.lang
> /home/users/glen/tmp/rpm-tmp.oRtxaL[82]: %{_usrlibrpm}/dokuwiki-find-lang.sh:
> inaccessible or not found
> ```
>
> What’s the replacement? Should it be restored instead?
>
%_rpmconfigdir is the official macro that points to /usr/lib/rpm.
--
真実はいつも一つ！/ Always, there's only one truth!
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: KDE - all form test
On 14.09.2022 10:29, Andrzej Zawadzki wrote: >On 14.09.2022 01:40, Krzysztof Mrozowicz via pld-devel-en wrote: > > Dnia 2022-09-13, o godz. 16:15:06 > Andrzej Zawadzki [1] napisal/(a): > > >Qt 5.15.6 - similar problem. For example kwallet doesn't work with >NetworkManager. > >Downgrade help, so looks like after Qt upgrade rebuild off all kde5 >packages will help. > > I sent all ka5 and kp5 packages to rebuild. They should be done over > the night. Kf5 were done earlier today due to their update. > > >Works now. > >But... should KDE be strictly dependent on the Qt version? > >Second time when Qt update broke my KDE environment. Ideally KDE should not have strict Qt version dependency as I suppose Qt should not be breaking compatibility between patch releases. That's the theory though. For example keepassxc was broken after upgrade as well due to some missing symbol related to qt concurrent. Either Qt broke ABI compatibility or keepassxc misused Qt API, whichever is more likely. I didn't bother to investigate deeper. Unless someone investigates what and why is broken in KDE and rebuilds just affected packages, I suppose the best way forward is indeed rebuild everything each time Qt is upgraded. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: KDE - all form test
Dnia 2022-09-14, o godz. 10:29:58 Andrzej Zawadzki napisał(a): > Works now. > > But... should KDE be strictly dependent on the Qt version? > > Second time when Qt update broke my KDE environment. As a non-programmer, I'm guessing that KDE expects that all its components will be build with the same QT version. The problem is that the particular components, ka5, kf5, kp5 appear for upgrades at different times, so if between upgrading let's say kf5 packages and kp5 packages the QT version gets changed, then the problem occurs. I guess every QT5 upgrade should trigger rebuilding of all ka5, kf5 and kp5 packages... -- Krzysiek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: KDE - all form test
On 14.09.2022 01:40, Krzysztof Mrozowicz via pld-devel-en wrote: Dnia 2022-09-13, o godz. 16:15:06 Andrzej Zawadzki [1] napisal/(a): Qt 5.15.6 - similar problem. For example kwallet doesn't work with NetworkManager. Downgrade help, so looks like after Qt upgrade rebuild off all kde5 packages will help. I sent all ka5 and kp5 packages to rebuild. They should be done over the night. Kf5 were done earlier today due to their update. Works now. But... should KDE be strictly dependent on the Qt version? Second time when Qt update broke my KDE environment. -- Andrzej Zawadzki References 1. mailto:zawa...@gmail.com ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: KDE - all form test
Dnia 2022-09-13, o godz. 16:15:06 Andrzej Zawadzki napisał(a): >Qt 5.15.6 - similar problem. For example kwallet doesn't work with >NetworkManager. > >Downgrade help, so looks like after Qt upgrade rebuild off all kde5 >packages will help. I sent all ka5 and kp5 packages to rebuild. They should be done over the night. Kf5 were done earlier today due to their update. -- Krzysiek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: KDE - all form test
On 1.07.2022 19:22, Peri Noid wrote: Dnia piatek, 1 lipca 2022 14:31:04 CEST Andrzej Zawadzki pisze: OK Qt5 was to fresh. I found in logs: *plasmashell[2012]: Cannot mix incompatible Qt library (5.15.4) with this library (5.15.5)* Hmm, rebuild is needed? I did a full downgrade of Qt5 to 5.15.4 and it works - so yes, the problem is somewhere there. We're still missing some of Qt5 packets in thre 5.15.5 version to be able to upgrade everything to this version. At least now. Hi! Qt 5.15.6 - similar problem. For example kwallet doesn't work with NetworkManager. Downgrade help, so looks like after Qt upgrade rebuild off all kde5 packages will help. -- Andrzej Zawadzki ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm-build-tools] builder: don't bother going back to original $(pwd) at the end of script
> On 31. Aug 2022, at 13:21, Jan Rękorajski wrote: > > On Wed, Aug 31, 2022 at 11:41 AM Arkadiusz Miśkiewicz via pld-devel-en > wrote: >> >> On 31.08.2022 11:27, Jan Rękorajski wrote: >>> Where will it land now? If you want to protect against landing in >>> non-existing directory you can use '[ -d "$__PWD" ] && cd "$__PWD"' >>> I really prefer to be staying in the same directory where I launched >>> the script in. >> >> Do you include (via source/dot) this script in some other script? > > No, command line. > My common workflow is cd $package; hack spec; builder ... (often with > --short-circuit) and back to hacking. So the working dir restore is irrelevant. As it’s in builder script, doesn’t affect any external shell. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm-build-tools] builder: don't bother going back to original $(pwd) at the end of script
On Wed, Aug 31, 2022 at 11:41 AM Arkadiusz Miśkiewicz via pld-devel-en wrote: > > On 31.08.2022 11:27, Jan Rękorajski wrote: > > Where will it land now? If you want to protect against landing in > > non-existing directory you can use '[ -d "$__PWD" ] && cd "$__PWD"' > > I really prefer to be staying in the same directory where I launched > > the script in. > > Do you include (via source/dot) this script in some other script? No, command line. My common workflow is cd $package; hack spec; builder ... (often with --short-circuit) and back to hacking. -- Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/ bagginspld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm-build-tools] builder: don't bother going back to original $(pwd) at the end of script
On 31.08.2022 11:27, Jan Rękorajski wrote: Where will it land now? If you want to protect against landing in non-existing directory you can use '[ -d "$__PWD" ] && cd "$__PWD"' I really prefer to be staying in the same directory where I launched the script in. Do you include (via source/dot) this script in some other script? -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm-build-tools] builder: don't bother going back to original $(pwd) at the end of script
On 31.08.2022 11:27, Jan Rękorajski wrote:
> Where will it land now? If you want to protect against landing in
> non-existing directory you can use '[ -d "$__PWD" ] && cd "$__PWD"'
> I really prefer to be staying in the same directory where I launched
> the script in.
I considered doing `test -d` but since this new old $PWD doesn't affect
any other command I've just dropped it entirely. I will bring it back
with test then.
> On Wed, Aug 31, 2022 at 12:59 AM atler wrote:
> >
> > commit b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22
> > Author: Jan Palus
> > Date: Wed Aug 31 00:55:46 2022 +0200
> >
> > builder: don't bother going back to original $(pwd) at the end of script
> >
> > no real use for it as far as I can tell and ditching it avoids error if
> > original working directory does not exist anymore (because ie it
> > happened to be $RPM_BUILD_ROOT)
> >
> > builder.sh | 1 -
> > 1 file changed, 1 deletion(-)
> > ---
> > diff --git a/builder.sh b/builder.sh
> > index 058d0de..68bb875 100755
> > --- a/builder.sh
> > +++ b/builder.sh
> > @@ -2756,6 +2756,5 @@ esac
> > if [ -f "`pwd`/.${SPECFILE}_INSTALLED_PACKAGES" -a
> > "$REMOVE_BUILD_REQUIRES" != "" ]; then
> > rm "`pwd`/.${SPECFILE}_INSTALLED_PACKAGES"
> > fi
> > -cd "$__PWD"
> >
> > # vi:syntax=sh:ts=4:sw=4:noet
> >
> >
> > gitweb:
> >
> > http://git.pld-linux.org/gitweb.cgi/packages/rpm-build-tools.git/commitdiff/b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22
> >
> > ___
> > pld-cvs-commit mailing list
> > pld-cvs-com...@lists.pld-linux.org
> > http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
>
>
>
> --
> Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
> bagginspld-linux.org
> ___
> pld-devel-pl mailing list
> pld-devel...@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm-build-tools] builder: don't bother going back to original $(pwd) at the end of script
Where will it land now? If you want to protect against landing in
non-existing directory you can use '[ -d "$__PWD" ] && cd "$__PWD"'
I really prefer to be staying in the same directory where I launched
the script in.
On Wed, Aug 31, 2022 at 12:59 AM atler wrote:
>
> commit b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22
> Author: Jan Palus
> Date: Wed Aug 31 00:55:46 2022 +0200
>
> builder: don't bother going back to original $(pwd) at the end of script
>
> no real use for it as far as I can tell and ditching it avoids error if
> original working directory does not exist anymore (because ie it
> happened to be $RPM_BUILD_ROOT)
>
> builder.sh | 1 -
> 1 file changed, 1 deletion(-)
> ---
> diff --git a/builder.sh b/builder.sh
> index 058d0de..68bb875 100755
> --- a/builder.sh
> +++ b/builder.sh
> @@ -2756,6 +2756,5 @@ esac
> if [ -f "`pwd`/.${SPECFILE}_INSTALLED_PACKAGES" -a "$REMOVE_BUILD_REQUIRES"
> != "" ]; then
> rm "`pwd`/.${SPECFILE}_INSTALLED_PACKAGES"
> fi
> -cd "$__PWD"
>
> # vi:syntax=sh:ts=4:sw=4:noet
>
>
> gitweb:
>
> http://git.pld-linux.org/gitweb.cgi/packages/rpm-build-tools.git/commitdiff/b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22
>
> ___
> pld-cvs-commit mailing list
> pld-cvs-com...@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
--
Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
bagginspld-linux.org
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: glibc 2.36 *.o files debug extraction broken
On 16.08.2022 21:53, Jakub Bogusz wrote: > On Tue, Aug 16, 2022 at 09:28:58PM +0200, Jan Palus wrote: > > On 16.08.2022 20:31, Jakub Bogusz wrote: > > > In glibc 2.36 build debuginfo extraction process removes .note.GNU-stack > > > section: > > > > ... > > > > > For now only i686 builds are affected because x86_64 and x32 glibc-devel > > > packages > > > haven't been updated on builders. > > > > > > > > > Any guesses what changed? > > > > I believe to be responsible for this, specifically with this debugedit > > commit: > > > > commit bd392272c04d608257eb999670d85261d5125d93 > > Author: Jan Palus > > Date: Tue Jun 7 11:39:01 2022 > > > > bring back patch from rpm 4.16 for no exe bit when searching debuginfo; > > rel 2 > > > > which now considers non-executable object file matching pattern > > found in `find-debuginfo`: ^\(.*\):[ ]*.*ELF.*, not stripped.* > > > > Which in turn causes object file to be passed to `eu-strip` directly > > responsible for stripping .note.GNU-stack section. > > > > Fix proposals: > > > > 1. modify `find-debuginfo` pattern to include ELF.*\(executable\|shared > > object\) > > 2. modify macros to invoke `find-debuginfo` with `--keep-section > > .note.GNU-stack` > > 3. both 1 and 2 > > I think it would be safer to revert to not touching *.o files (by > default). For the time being implemented 1. not to regress packages initial fix was done for. > BTW, why find-debuginfo removes .note.GNU-stack from *.o and doesn't remove > from *.a/*.so? To be precise it's eu-strip that find-debuginfo invokes. Regarding actual question these are two different things: object files (*.o) hold information for linker in .note.GNU-stack section of ELF file. Linker uses this information when creating shared objects (*.so) or executables to construct GNU_STACK program header in output ELF file. GNU_STACK is in turn used by kernel. eu-strip does not touch ELF program headers at all so it's plain copy. It only operates on ELF sections. So that's why executable/so files are not affected. (note that mentioned archives (*.a) are not considered for debuginfo extraction). I see a comment in elfutils strip code that intention was to keep all ELF notes, which while implemented, does not affect .note.GNU-stack. Most notes appear to be of type SHT_NOTE (that's what implementation relies on) however .note.GNU-stack is of type SHT_PROGBITS (ref elf(5)). I will raise a question to elfutils whether this is intended. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: glibc 2.36 *.o files debug extraction broken
On Tue, Aug 16, 2022 at 09:28:58PM +0200, Jan Palus wrote: > On 16.08.2022 20:31, Jakub Bogusz wrote: > > In glibc 2.36 build debuginfo extraction process removes .note.GNU-stack > > section: > > ... > > > For now only i686 builds are affected because x86_64 and x32 glibc-devel > > packages > > haven't been updated on builders. > > > > > > Any guesses what changed? > > I believe to be responsible for this, specifically with this debugedit > commit: > > commit bd392272c04d608257eb999670d85261d5125d93 > Author: Jan Palus > Date: Tue Jun 7 11:39:01 2022 > > bring back patch from rpm 4.16 for no exe bit when searching debuginfo; > rel 2 > > which now considers non-executable object file matching pattern > found in `find-debuginfo`: ^\(.*\):[ ]*.*ELF.*, not stripped.* > > Which in turn causes object file to be passed to `eu-strip` directly > responsible for stripping .note.GNU-stack section. > > Fix proposals: > > 1. modify `find-debuginfo` pattern to include ELF.*\(executable\|shared > object\) > 2. modify macros to invoke `find-debuginfo` with `--keep-section > .note.GNU-stack` > 3. both 1 and 2 I think it would be safer to revert to not touching *.o files (by default). BTW, why find-debuginfo removes .note.GNU-stack from *.o and doesn't remove from *.a/*.so? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: glibc 2.36 *.o files debug extraction broken
On 16.08.2022 20:31, Jakub Bogusz wrote: > In glibc 2.36 build debuginfo extraction process removes .note.GNU-stack > section: ... > For now only i686 builds are affected because x86_64 and x32 glibc-devel > packages > haven't been updated on builders. > > > Any guesses what changed? I believe to be responsible for this, specifically with this debugedit commit: commit bd392272c04d608257eb999670d85261d5125d93 Author: Jan Palus Date: Tue Jun 7 11:39:01 2022 bring back patch from rpm 4.16 for no exe bit when searching debuginfo; rel 2 which now considers non-executable object file matching pattern found in `find-debuginfo`: ^\(.*\):[ ]*.*ELF.*, not stripped.* Which in turn causes object file to be passed to `eu-strip` directly responsible for stripping .note.GNU-stack section. Fix proposals: 1. modify `find-debuginfo` pattern to include ELF.*\(executable\|shared object\) 2. modify macros to invoke `find-debuginfo` with `--keep-section .note.GNU-stack` 3. both 1 and 2 Comments welcome. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Qt packaging
On 08.08.2022 23:34, Jan Rękorajski wrote: > On Mon, 08 Aug 2022, Jan Palus wrote: > > > On 08.08.2022 08:32, Jan Rękorajski wrote: > > > On Fri, 22 Jul 2022, Jan Palus wrote: > > > > > > > On 22.07.2022 11:03, Jan Rękorajski wrote: > > > > > Can someone explain why are we using split sources/packages for Qt? > > > > > > > > > > I want to add Qt6 and building from the monolythic source is s > > > > > much > > > > > easier. No need for bootstrap, no intertwined build dependencies, just > > > > > configure -> build -> build docs -> install. > > > > > > > > > > And unless there is a _very_ good reason to use split sources I'm > > > > > just going > > > > > to add a single qt6 package that builds everything (we can still > > > > > subpackage > > > > > bineries as we want them). > > > > > > > > As long as each component is bcondized and there are no "to the exact > > > > release" dependencies then I guess it's fine. Doing qtwebengine (and all > > > > the other components) rebuild each time qtbase needs a small packaging > > > > adjustment would be tough on arm, though I'd understand if nobody cared > > > > about my use case. > > > > > > FYI build time on builders is 1.5 hour without qtwebengine and 7 hours > > > with qtwebengine. > > > > > > I don't know how it looks on arm, but IMHO no-webengine bcond should be > > > enough? > > > > Multiply it by ~4 and it's roughly result for arm. The first part I > > mean, qtwebengine is so heavy that I build it in AWS. > > > > Anyway no worries, if needed I can add more bconds myself. And thanks a > > lot for working on qt6! > > Thanks, it's a slow and painful process, and we'll end up with less > granularity, at least at the beginning. What I want now, is a MVP to be able > to build current calibre :/ > > Out of curiosity, would webengine even build on arm? What I see it > building is full blown blink/chromium engine. And this thing has lots > of fancy dependencies, both software and hardware. Just to be clear when I said "arm" I really meant "aarch64", 32-bit version of qtwebengine is of not much interest to me. And at least qtwebengine 5.x builds just fine for aarch64 and using it daily as my primary web browsing engine. I don't expect qt6 to be much different but haven't tried to build it so far. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Qt packaging
On Mon, 08 Aug 2022, Jan Palus wrote: > On 08.08.2022 08:32, Jan Rękorajski wrote: > > On Fri, 22 Jul 2022, Jan Palus wrote: > > > > > On 22.07.2022 11:03, Jan Rękorajski wrote: > > > > Can someone explain why are we using split sources/packages for Qt? > > > > > > > > I want to add Qt6 and building from the monolythic source is s much > > > > easier. No need for bootstrap, no intertwined build dependencies, just > > > > configure -> build -> build docs -> install. > > > > > > > > And unless there is a _very_ good reason to use split sources I'm just > > > > going > > > > to add a single qt6 package that builds everything (we can still > > > > subpackage > > > > bineries as we want them). > > > > > > As long as each component is bcondized and there are no "to the exact > > > release" dependencies then I guess it's fine. Doing qtwebengine (and all > > > the other components) rebuild each time qtbase needs a small packaging > > > adjustment would be tough on arm, though I'd understand if nobody cared > > > about my use case. > > > > FYI build time on builders is 1.5 hour without qtwebengine and 7 hours > > with qtwebengine. > > > > I don't know how it looks on arm, but IMHO no-webengine bcond should be > > enough? > > Multiply it by ~4 and it's roughly result for arm. The first part I > mean, qtwebengine is so heavy that I build it in AWS. > > Anyway no worries, if needed I can add more bconds myself. And thanks a > lot for working on qt6! Thanks, it's a slow and painful process, and we'll end up with less granularity, at least at the beginning. What I want now, is a MVP to be able to build current calibre :/ Out of curiosity, would webengine even build on arm? What I see it building is full blown blink/chromium engine. And this thing has lots of fancy dependencies, both software and hardware. -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Qt packaging
On 08.08.2022 08:32, Jan Rękorajski wrote: > On Fri, 22 Jul 2022, Jan Palus wrote: > > > On 22.07.2022 11:03, Jan Rękorajski wrote: > > > Can someone explain why are we using split sources/packages for Qt? > > > > > > I want to add Qt6 and building from the monolythic source is s much > > > easier. No need for bootstrap, no intertwined build dependencies, just > > > configure -> build -> build docs -> install. > > > > > > And unless there is a _very_ good reason to use split sources I'm just > > > going > > > to add a single qt6 package that builds everything (we can still > > > subpackage > > > bineries as we want them). > > > > As long as each component is bcondized and there are no "to the exact > > release" dependencies then I guess it's fine. Doing qtwebengine (and all > > the other components) rebuild each time qtbase needs a small packaging > > adjustment would be tough on arm, though I'd understand if nobody cared > > about my use case. > > FYI build time on builders is 1.5 hour without qtwebengine and 7 hours > with qtwebengine. > > I don't know how it looks on arm, but IMHO no-webengine bcond should be > enough? Multiply it by ~4 and it's roughly result for arm. The first part I mean, qtwebengine is so heavy that I build it in AWS. Anyway no worries, if needed I can add more bconds myself. And thanks a lot for working on qt6! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Qt packaging
On Mon, 08 Aug 2022, Neal Gompa wrote: > On Mon, Aug 8, 2022 at 2:32 AM Jan Rękorajski wrote: > > > > On Fri, 22 Jul 2022, Jan Palus wrote: > > > > > On 22.07.2022 11:03, Jan Rękorajski wrote: > > > > Can someone explain why are we using split sources/packages for Qt? > > > > > > > > I want to add Qt6 and building from the monolythic source is s much > > > > easier. No need for bootstrap, no intertwined build dependencies, just > > > > configure -> build -> build docs -> install. > > > > > > > > And unless there is a _very_ good reason to use split sources I'm just > > > > going > > > > to add a single qt6 package that builds everything (we can still > > > > subpackage > > > > bineries as we want them). > > > > > > As long as each component is bcondized and there are no "to the exact > > > release" dependencies then I guess it's fine. Doing qtwebengine (and all > > > the other components) rebuild each time qtbase needs a small packaging > > > adjustment would be tough on arm, though I'd understand if nobody cared > > > about my use case. > > > > FYI build time on builders is 1.5 hour without qtwebengine and 7 hours > > with qtwebengine. > > > > I don't know how it looks on arm, but IMHO no-webengine bcond should be > > enough? > > > > The reason most distros don't use the monolithic source is that it's a > pain to apply patches to it. Qt doesn't actually get developed that > way, and backporting fixes is more of a pain if you use the monolithic > build. Well, we don't have resources to play with backporting changes. Besides I saw have ex. Fedora packages qt and it is IMO a joke. They don't build docs, they don't build internal deps, so yeah, it's easy, but it's half of the functionality. I'd rather have a package without the backports, but with all bells and whistles, that is easy to build, rather than either build pain on half baked. -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Qt packaging
On Mon, Aug 8, 2022 at 2:32 AM Jan Rękorajski wrote: > > On Fri, 22 Jul 2022, Jan Palus wrote: > > > On 22.07.2022 11:03, Jan Rękorajski wrote: > > > Can someone explain why are we using split sources/packages for Qt? > > > > > > I want to add Qt6 and building from the monolythic source is s much > > > easier. No need for bootstrap, no intertwined build dependencies, just > > > configure -> build -> build docs -> install. > > > > > > And unless there is a _very_ good reason to use split sources I'm just > > > going > > > to add a single qt6 package that builds everything (we can still > > > subpackage > > > bineries as we want them). > > > > As long as each component is bcondized and there are no "to the exact > > release" dependencies then I guess it's fine. Doing qtwebengine (and all > > the other components) rebuild each time qtbase needs a small packaging > > adjustment would be tough on arm, though I'd understand if nobody cared > > about my use case. > > FYI build time on builders is 1.5 hour without qtwebengine and 7 hours > with qtwebengine. > > I don't know how it looks on arm, but IMHO no-webengine bcond should be > enough? > The reason most distros don't use the monolithic source is that it's a pain to apply patches to it. Qt doesn't actually get developed that way, and backporting fixes is more of a pain if you use the monolithic build. -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Qt packaging
On Fri, 22 Jul 2022, Jan Palus wrote: > On 22.07.2022 11:03, Jan Rękorajski wrote: > > Can someone explain why are we using split sources/packages for Qt? > > > > I want to add Qt6 and building from the monolythic source is s much > > easier. No need for bootstrap, no intertwined build dependencies, just > > configure -> build -> build docs -> install. > > > > And unless there is a _very_ good reason to use split sources I'm just going > > to add a single qt6 package that builds everything (we can still subpackage > > bineries as we want them). > > As long as each component is bcondized and there are no "to the exact > release" dependencies then I guess it's fine. Doing qtwebengine (and all > the other components) rebuild each time qtbase needs a small packaging > adjustment would be tough on arm, though I'd understand if nobody cared > about my use case. FYI build time on builders is 1.5 hour without qtwebengine and 7 hours with qtwebengine. I don't know how it looks on arm, but IMHO no-webengine bcond should be enough? -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Qt packaging
On 22.07.2022 11:03, Jan Rękorajski wrote: > Can someone explain why are we using split sources/packages for Qt? > > I want to add Qt6 and building from the monolythic source is s much > easier. No need for bootstrap, no intertwined build dependencies, just > configure -> build -> build docs -> install. > > And unless there is a _very_ good reason to use split sources I'm just going > to add a single qt6 package that builds everything (we can still subpackage > bineries as we want them). As long as each component is bcondized and there are no "to the exact release" dependencies then I guess it's fine. Doing qtwebengine (and all the other components) rebuild each time qtbase needs a small packaging adjustment would be tough on arm, though I'd understand if nobody cared about my use case. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: RFC: shell completions policy change?
On 14.07.2022 16:38, Jakub Bogusz wrote:
> As more and more packages are getting bash/zsh completions, separate
> completions packages are becoming useless (harder to find, even not
> suggested).
>
> My proposal:
> 1) add %{bash_compdir}, %{zsh_compdir} and maybe %{fish_compdir} (and upper
> level) dirs to filesystem package and package bash/zsh[/fish] completion
> files just with commands (existing bash-/zsh-[/fish-] packages to be merged
> and
> obsoleted). [preferred]
> Fortunately completion files don't have shebangs, which would generate
> bash/zsh dependencies.
Never had an issue with finding completions but I'm all for less
subpackages so +1.
> 2) at least add Suggests for completions packages in packages with
> commands to complete
>
>
> --
> Jakub Boguszhttp://qboosh.pl/
> ___
> pld-devel-en mailing list
> pld-devel-en@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: RFC: shell completions policy change?
On Thu, 14 Jul 2022, Jakub Bogusz wrote:
> As more and more packages are getting bash/zsh completions, separate
> completions packages are becoming useless (harder to find, even not
> suggested).
>
> My proposal:
> 1) add %{bash_compdir}, %{zsh_compdir} and maybe %{fish_compdir} (and upper
> level) dirs to filesystem package and package bash/zsh[/fish] completion
> files just with commands (existing bash-/zsh-[/fish-] packages to be merged
> and
> obsoleted). [preferred]
> Fortunately completion files don't have shebangs, which would generate
> bash/zsh dependencies.
+1
Yes, it's a pain to find those subpackages.
--
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: RFC: shell completions policy change?
On 14.07.2022 16:38, Jakub Bogusz wrote:
As more and more packages are getting bash/zsh completions, separate
completions packages are becoming useless (harder to find, even not suggested).
My proposal:
1) add %{bash_compdir}, %{zsh_compdir} and maybe %{fish_compdir} (and upper
level) dirs to filesystem package and package bash/zsh[/fish] completion
files just with commands (existing bash-/zsh-[/fish-] packages to be merged and
obsoleted). [preferred]
Fortunately completion files don't have shebangs, which would generate
bash/zsh dependencies.
+1
2) at least add Suggests for completions packages in packages with
commands to complete
-1
--
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: your mail
My bad , I meant PLD English section My mind is stuck with poldek so I wrote poldek by mistake On Tue, Jul 12, 2022, 7:44 PM Saleem Ceann Khan Marwat wrote: > Sorry if I posted it in wrong place but I thought I posted it in poldek > English section > > And strangely now there is no more kernel 5.18 available on th , it has > disappeared from packages available for upgrade > > So I'm currently on 5.17 > > Thanks > > On Tue, Jul 12, 2022, 7:41 PM Jan Palus wrote: > >> On 12.07.2022 19:26, Saleem Ceann Khan Marwat wrote: >> > Thanks but that did not help either >> > >> > as can be seen from this log >> > poldek:/all-avail> upgrade * >> > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package >> > error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package >> > error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package >> > error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held >> package >> > Nothing to do >> > poldek:/all-avail> install kernel-5.18.5-1.x86_64 >> > kernel-drm-5.18.5-1.x86_64 kernel-headers-5.18.5-1.x86_64 >> > kernel-sound-alsa-5.18.5-1.x86_64 >> > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package >> > error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package >> > error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package >> > error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held >> package >> > Nothing to do >> > poldek:/all-avail> install kernel-5.18.5-1.x86_64 >> > >> > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package >> > Nothing to do >> >> And please do post such questions on pld-users-en. Thanks. >> >> > On Fri, Jul 8, 2022 at 2:32 PM Jan Rękorajski >> > wrote: >> > >> > > On Thu, Jul 7, 2022 at 7:46 PM Saleem Ceann Khan Marwat >> > > wrote: >> > > > >> > > > Hello, >> > > > >> > > > I am having issue with kernel upgrade to 5.18 due to held packages >> > > > >> > > > I tried --nodeps --force but still can not upgrade any of the kernel >> > > > related packages. >> > > > >> > > > How to fix this? >> > > >> > > Use install instead of upgrade for held (kernel in this case) >> packages. >> > > >> > > The hold in poldek was added to prevent a case when a new kernel would >> > > have problems starting. Upgrade could possibly leave you without a >> > > working kernel. >> > > Hold will not prevent uninstalling, but make sure that new kernel >> > > boots before doing so :) >> > > >> > > -- >> > > Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/ >> > > bagginspld-linux.org >> > > ___ >> > > pld-devel-en mailing list >> > > pld-devel-en@lists.pld-linux.org >> > > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en >> > > >> > >> > >> > -- >> > Dr.Saleem Khan Marwat >> > Abbottabad >> > Khyber-Pakhtunkhwa >> > Pakistan >> > Cell # +92333-5393854 >> > WhatsApp # +92333-5393854 >> > Email: drmar...@gmail.com >> > Web: http://saleem-khan.blogspot.com >> > Registered GNU/Linux User # 413133 >> > Since Aug 2003 >> > ___ >> > pld-devel-en mailing list >> > pld-devel-en@lists.pld-linux.org >> > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en >> ___ >> pld-devel-en mailing list >> pld-devel-en@lists.pld-linux.org >> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en >> > ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: your mail
Sorry if I posted it in wrong place but I thought I posted it in poldek English section And strangely now there is no more kernel 5.18 available on th , it has disappeared from packages available for upgrade So I'm currently on 5.17 Thanks On Tue, Jul 12, 2022, 7:41 PM Jan Palus wrote: > On 12.07.2022 19:26, Saleem Ceann Khan Marwat wrote: > > Thanks but that did not help either > > > > as can be seen from this log > > poldek:/all-avail> upgrade * > > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package > > error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package > > error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package > > error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held > package > > Nothing to do > > poldek:/all-avail> install kernel-5.18.5-1.x86_64 > > kernel-drm-5.18.5-1.x86_64 kernel-headers-5.18.5-1.x86_64 > > kernel-sound-alsa-5.18.5-1.x86_64 > > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package > > error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package > > error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package > > error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held > package > > Nothing to do > > poldek:/all-avail> install kernel-5.18.5-1.x86_64 > > > > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package > > Nothing to do > > And please do post such questions on pld-users-en. Thanks. > > > On Fri, Jul 8, 2022 at 2:32 PM Jan Rękorajski > > wrote: > > > > > On Thu, Jul 7, 2022 at 7:46 PM Saleem Ceann Khan Marwat > > > wrote: > > > > > > > > Hello, > > > > > > > > I am having issue with kernel upgrade to 5.18 due to held packages > > > > > > > > I tried --nodeps --force but still can not upgrade any of the kernel > > > > related packages. > > > > > > > > How to fix this? > > > > > > Use install instead of upgrade for held (kernel in this case) packages. > > > > > > The hold in poldek was added to prevent a case when a new kernel would > > > have problems starting. Upgrade could possibly leave you without a > > > working kernel. > > > Hold will not prevent uninstalling, but make sure that new kernel > > > boots before doing so :) > > > > > > -- > > > Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/ > > > bagginspld-linux.org > > > ___ > > > pld-devel-en mailing list > > > pld-devel-en@lists.pld-linux.org > > > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > > > > > > > > > -- > > Dr.Saleem Khan Marwat > > Abbottabad > > Khyber-Pakhtunkhwa > > Pakistan > > Cell # +92333-5393854 > > WhatsApp # +92333-5393854 > > Email: drmar...@gmail.com > > Web: http://saleem-khan.blogspot.com > > Registered GNU/Linux User # 413133 > > Since Aug 2003 > > ___ > > pld-devel-en mailing list > > pld-devel-en@lists.pld-linux.org > > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > ___ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
