Re: rpm plan (Re: rpm-build pulls perl)
On Mon, Mar 30, 2020 at 2:14 AM Elan Ruusamäe wrote: > > On 3/29/20 11:52 AM, Jan Rękorajski wrote: > > >> i think the pear dependency generator should be disabled by default, > >> pear is considered dead in php world. > > ` > > Then disable it, or even better, delete the scripts and config. > what is the rpm4/rpm5 plan again? i'd rather do this only once, not both > branches. These php PEAR dependency generator scripts are gone in rpm.org codebase anyway... -- 真実はいつも一つ！/ 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
rpm plan (Re: rpm-build pulls perl)
On 3/29/20 11:52 AM, Jan Rękorajski wrote: i think the pear dependency generator should be disabled by default, pear is considered dead in php world. ` Then disable it, or even better, delete the scripts and config. what is the rpm4/rpm5 plan again? i'd rather do this only once, not both branches. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm-build pulls perl
On Sun, 29 Mar 2020, Elan Ruusamäe wrote: > On 3/24/20 11:16 PM, Jan Rękorajski wrote: > > > On a side note, this is exactly why we should not have all those weird > > hacks in deps generators and just run them always. To chatch stuff like > > this. > > > this enabled pear dependencies breaks packages that does not want them > (bundles everything, handles in package deps). Good. This will finally allow us to catch all the breakage and either fix dependencies or packages. > i think the pear dependency generator should be disabled by default, > pear is considered dead in php world. ` Then disable it, or even better, delete the scripts and config. -- 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: rpm-build pulls perl
On 3/29/20 10:20 AM, Elan Ruusamäe wrote: On 3/29/20 9:17 AM, Elan Ruusamäe wrote: On 3/29/20 9:07 AM, Elan Ruusamäe wrote: On 3/24/20 11:16 PM, Jan Rękorajski wrote: On a side note, this is exactly why we should not have all those weird hacks in deps generators and just run them always. To chatch stuff like this. this enabled pear dependencies breaks packages that does not want them (bundles everything, handles in package deps). i think the pear dependency generator should be disabled by default, pear is considered dead in php world. it was controlled earlier with include pear.req, i guess now we need a define no_pear_dependencies? ``` error: eventum-sphinx-3.8.9-1.noarch: req pear(/usr/share/eventum/init.php) not found error: eventum-3.8.9-1.noarch: req pear(../../init.php) not found error: eventum-3.8.9-1.noarch: req pear(../library/HTMLPurifier.auto.php) not found error: eventum-3.8.9-1.noarch: req pear(../library/HTMLPurifier/Bootstrap.php) not found error: eventum-3.8.9-1.noarch: req pear(../tests/path2class.func.php) not found error: eventum-3.8.9-1.noarch: req pear(Exception/InvalidArgumentException.php) not found error: eventum-3.8.9-1.noarch: req pear(HTMLPurifier.autoload.php) not found error: eventum-3.8.9-1.noarch: req pear(HTMLPurifier.includes.php) not found ... ``` with current macros, every package that was *not* removed %include pearprov should have now: %define _noautoprov_pear .* this no longer works either... update: 1. added test: https://github.com/pld-linux/test/tree/test/peardeps 2. the macro i was looking is _noautoreq_pear shouldn't there be announcement or changelog posted of (breaking) changes? ➔ rpm -q rpm rpm-5.4.15-57.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: rpm-build pulls perl
On 3/29/20 9:17 AM, Elan Ruusamäe wrote: On 3/29/20 9:07 AM, Elan Ruusamäe wrote: On 3/24/20 11:16 PM, Jan Rękorajski wrote: On a side note, this is exactly why we should not have all those weird hacks in deps generators and just run them always. To chatch stuff like this. this enabled pear dependencies breaks packages that does not want them (bundles everything, handles in package deps). i think the pear dependency generator should be disabled by default, pear is considered dead in php world. it was controlled earlier with include pear.req, i guess now we need a define no_pear_dependencies? ``` error: eventum-sphinx-3.8.9-1.noarch: req pear(/usr/share/eventum/init.php) not found error: eventum-3.8.9-1.noarch: req pear(../../init.php) not found error: eventum-3.8.9-1.noarch: req pear(../library/HTMLPurifier.auto.php) not found error: eventum-3.8.9-1.noarch: req pear(../library/HTMLPurifier/Bootstrap.php) not found error: eventum-3.8.9-1.noarch: req pear(../tests/path2class.func.php) not found error: eventum-3.8.9-1.noarch: req pear(Exception/InvalidArgumentException.php) not found error: eventum-3.8.9-1.noarch: req pear(HTMLPurifier.autoload.php) not found error: eventum-3.8.9-1.noarch: req pear(HTMLPurifier.includes.php) not found ... ``` with current macros, every package that was *not* removed %include pearprov should have now: %define _noautoprov_pear .* this no longer works either... shouldn't there be announcement or changelog posted of (breaking) changes? ➔ rpm -q rpm rpm-5.4.15-57.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: rpm-build pulls perl
On 3/29/20 9:07 AM, Elan Ruusamäe wrote: On 3/24/20 11:16 PM, Jan Rękorajski wrote: On a side note, this is exactly why we should not have all those weird hacks in deps generators and just run them always. To chatch stuff like this. this enabled pear dependencies breaks packages that does not want them (bundles everything, handles in package deps). i think the pear dependency generator should be disabled by default, pear is considered dead in php world. it was controlled earlier with include pear.req, i guess now we need a define no_pear_dependencies? ``` error: eventum-sphinx-3.8.9-1.noarch: req pear(/usr/share/eventum/init.php) not found error: eventum-3.8.9-1.noarch: req pear(../../init.php) not found error: eventum-3.8.9-1.noarch: req pear(../library/HTMLPurifier.auto.php) not found error: eventum-3.8.9-1.noarch: req pear(../library/HTMLPurifier/Bootstrap.php) not found error: eventum-3.8.9-1.noarch: req pear(../tests/path2class.func.php) not found error: eventum-3.8.9-1.noarch: req pear(Exception/InvalidArgumentException.php) not found error: eventum-3.8.9-1.noarch: req pear(HTMLPurifier.autoload.php) not found error: eventum-3.8.9-1.noarch: req pear(HTMLPurifier.includes.php) not found ... ``` with current macros, every package that was *not* removed %include pearprov should have now: %define _noautoprov_pear .* ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm-build pulls perl
On 3/24/20 11:16 PM, Jan Rękorajski wrote: On a side note, this is exactly why we should not have all those weird hacks in deps generators and just run them always. To chatch stuff like this. this enabled pear dependencies breaks packages that does not want them (bundles everything, handles in package deps). i think the pear dependency generator should be disabled by default, pear is considered dead in php world. it was controlled earlier with include pear.req, i guess now we need a define no_pear_dependencies? ``` error: eventum-sphinx-3.8.9-1.noarch: req pear(/usr/share/eventum/init.php) not found error: eventum-3.8.9-1.noarch: req pear(../../init.php) not found error: eventum-3.8.9-1.noarch: req pear(../library/HTMLPurifier.auto.php) not found error: eventum-3.8.9-1.noarch: req pear(../library/HTMLPurifier/Bootstrap.php) not found error: eventum-3.8.9-1.noarch: req pear(../tests/path2class.func.php) not found error: eventum-3.8.9-1.noarch: req pear(Exception/InvalidArgumentException.php) not found error: eventum-3.8.9-1.noarch: req pear(HTMLPurifier.autoload.php) not found error: eventum-3.8.9-1.noarch: req pear(HTMLPurifier.includes.php) not found ... ``` ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm-build pulls perl
On Tue, 24 Mar 2020, Elan Ruusamäe wrote: > i would not like bunch of perl deps in base package. > > i think these dependencies are new due recent updates in the repo > > > ``` > > [root@4195c311335e /]# rpm -q rpm-build --requires|grep perl > /usr/bin/perl > perl(Carp) > perl(Config) > perl(Cwd) > perl(File::Basename) > perl(File::Copy) > perl(File::Path) > perl(File::Temp) > perl(Getopt::Long) > perl(LWP::UserAgent) > perl(POSIX) > perl(XML::LibXML) > perl(strict) > perl(warnings) > > [root@4195c311335e /]# rpm -q rpm-build > > rpm-build-5.4.15-57.x86_64 > > [root@4195c311335e /]# > > ``` > > > perhaps just remove the shebang or chmod -x to make the deps optional > (if they must stay in rpm-build package) > > but i think they should be moved to `rpm-perlprov` package I just removed those scripts, they are just junk. On a side note, this is exactly why we should not have all those weird hacks in deps generators and just run them always. To chatch stuff like this. -- 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: libc 2.31/i686: operation not permitted for preserving timestamps
On 24.03.2020 21:20, Elan Ruusamäe wrote: > does i686 even work for someone really? > > > some errors here and there FWIW my up-to-date i686 VM (QEMU) used for package testing purposes works fine. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: libc 2.31/i686: operation not permitted for preserving timestamps
On Tue, Mar 24, 2020 at 09:20:19PM +0200, Elan Ruusamäe wrote: > On 3/16/20 11:46 PM, Elan Ruusamäe wrote: > >i've got reports that cp -a (or just cp --preserve=timestamps) fails > >on i686 and glibc 2.31 > does i686 even work for someone really? Which kernel and fs? I don't see such problems, glibc 2.31 on 4.19.x, xfs. -- 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: libc 2.31/i686: operation not permitted for preserving timestamps
On 3/16/20 11:46 PM, Elan Ruusamäe wrote:
i've got reports that cp -a (or just cp --preserve=timestamps) fails
on i686 and glibc 2.31
from strace i've grabbed such error:
utimensat_time64(4, NULL, [{tv_sec=1584393052, tv_nsec=0} /*
2020-03-16T23:10:52+0200 */, {tv_sec=1584393052, tv_nsec=0} /*
2020-03-16T23:10:52+0200 */], 0) = -1 EPERM (Operation not permitted)
i believe it's related to large inode on fd=4 and glibc just reports
it incorrectly
```
+ ls -ldi locale-archive
/var/tmp/glibc-localedb-2.30.0-root-root/usr/lib/locale
790264 drwxr-xr-x 2 root root 4096 Mar 16 2020
/var/tmp/glibc-localedb-2.30.0-root-root/usr/lib/locale
4379091441 -rw-r--r-- 1 root root 13754080 Mar 16 2020 locale-archive
+ cp '--preserve=timestamps' locale-archive
/var/tmp/glibc-localedb-2.30.0-root-root/usr/lib/locale
cp: preserving times for
'/var/tmp/glibc-localedb-2.30.0-root-root/usr/lib/locale/locale-archive':
Operation not permitted
```
does i686 even work for someone really?
some errors here and there
rpmdb: clock_gettime: Operation not permitted
66 rpmdb:
BDB0061 PANIC: Operation not permitted
67 ==>
rpmdbe_event_notify(0xcf70440, PANIC(0), 0xffd25864) app_private (nil)
[root@321bc6bed681 rpm]# poldek -u glibc
clock_gettime: Operation not permitted
BDB0061 PANIC: Operation not permitted
here's full build log attemting to build base image:
https://gitlab.com/pld-linux/pld/-/jobs/480110124
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/poldek] - up to 0.42.1 - turn off tests running
On Mon, Mar 16, 2020 at 10:15:33PM +0100, mis wrote: > commit 651f3f75747a091b5c3df9f9ac9fc8a93734cf8c > Author: mis > Date: Mon Mar 16 22:13:04 2020 +0100 > > - up to 0.42.1 > - turn off tests running > > FIXME: some tests use internal, non-exported libpoldek symbols > (undefined reference to `poldek_conf_sections', etc errors). We have > to build with -O0 to make them linkable and then build again for > production use. Or link tests with static libpoldek? -- 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: th-x32 builder stuck
On Tue, Mar 10, 2020 at 09:25:12PM +0100, Arkadiusz Miśkiewicz wrote: > On 10/03/2020 19:01, Jakub Bogusz wrote: > > What happened to th-x32? > builder 13256 199 19.3 4190584 3974900 ? Rl Mar08 6045:49 ^^^ ^^^ > /tmp/B.Cfmfdm/BUILD/gegl-0.4.22/build/tools/gegl-tester --all -o > > some database load loop? ...or 32-bit pointers? -- WBR, Michael Shigorin / http://altlinux.org -- http://opennet.ru / http://anna-news.info ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: th-x32 builder stuck
On 10/03/2020 19:01, Jakub Bogusz wrote: > What happened to th-x32? > > builder 13256 199 19.3 4190584 3974900 ? Rl Mar08 6045:49 /tmp/B.Cfmfdm/BUILD/gegl-0.4.22/build/tools/gegl-tester --all -o /tmp/B.Cfmfdm/BUILD/gegl-0.4.22/build/docs/ophtml -d /tmp/B.Cfmfdm/BUILD/gegl-0.4.22/docs/images -e alpha-inpaint|box-blur|box-percentile|buffer-cache|buffer-source|clone|convert-format|disc-percentile|dropshadow|exp-combine|exr-load|hstack|image-compare|integral-image|introspect|jpg-load|kuwahara|layer|line-profile|load|magick-load|mandelbrot|matting-global|nop|open-buffer|pixbuf|png-load|remap|snn-percentile|stretch-contrast|svg-load|v4l2|warp some database load loop? > Thread 1 (Thread 0xf6910300 (LWP 13256)): > #0 0xf72a12b6 in ?? () from /libx32/libc.so.6 > #1 0xf72ac64a in ?? () from /libx32/libc.so.6 > #2 0xf72ae063 in ?? () from /libx32/libc.so.6 > #3 0xf72ae142 in ?? () from /libx32/libc.so.6 > #4 0xf72ae6a0 in ?? () from /libx32/libc.so.6 > #5 0xf72afc17 in regcomp () from /libx32/libc.so.6 > #6 0xef98ffea in lfLens::GuessParameters() () from > /usr/libx32/liblensfun.so.1 > #7 0xef990179 in lfLens::Check() () from /usr/libx32/liblensfun.so.1 > #8 0xef98f65c in ?? () from /usr/libx32/liblensfun.so.1 > #9 0xf74b9a1a in ?? () from /usr/libx32/libglib-2.0.so.0 > #10 0xf74ba824 in g_markup_parse_context_parse () from > /usr/libx32/libglib-2.0.so.0 > #11 0xef98dbfb in lfDatabase::Load(char const*, char const*, unsigned int) () > from /usr/libx32/liblensfun.so.1 > #12 0xef98dd2c in lfDatabase::Load(char const*) () from > /usr/libx32/liblensfun.so.1 > #13 0xef98de02 in lfDatabase::LoadDirectory(char const*) () from > /usr/libx32/liblensfun.so.1 > #14 0xef98dee3 in lfDatabase::Load() () from /usr/libx32/liblensfun.so.1 > #15 0xefba1bdc in find_make_lens (boundary=..., o=0x23c9800, lens= pointer>) at ../operations/workshop/external/lens-correct.c:229 > #16 process (operation=, input=, > output=, result=, level=) at > ../operations/workshop/external/lens-correct.c:446 > #17 0xf76d3b41 in thread_process (area=, data=) > at ../gegl/operation/gegl-operation-filter.c:146 > #18 0xf7685bfd in gegl_parallel_distribute_area_func (i=, > n=, data=) at ../gegl/gegl-parallel.c:319 > #19 0xf7685e0f in gegl_parallel_distribute (max_n=, > func=func@entry=0xf7685b30 , > user_data=user_data@entry=0xffa38260) at ../gegl/gegl-parallel.c:196 > #20 0xf76865c2 in gegl_parallel_distribute_area (area=area@entry=0x2205f40, > thread_cost=, split_strategy=, > split_strategy@entry=GEGL_SPLIT_STRATEGY_AUTO, func=func@entry=0xf76d3b00 > , user_data=user_data@entry=0xffa382b0) at > ../gegl/gegl-parallel.c:376 > #21 0xf76d3a98 in gegl_operation_filter_process (operation=, > context=, output_prop=, result=, > level=) at ../gegl/operation/gegl-operation-filter.c:201 > #22 0xf76d8629 in gegl_operation_process (operation=, > context=, output_pad=, result=, > level=0) at ../gegl/operation/gegl-operation.c:172 > #23 0xf76da505 in gegl_graph_process (path=, > level=level@entry=0) at ../gegl/process/gegl-graph-traversal.c:486 > #24 0xf76d9670 in gegl_eval_manager_apply (self=self@entry=0x23c83a0, > roi=roi@entry=0xffa38430, level=level@entry=0) at > ../gegl/process/gegl-eval-manager.c:128 > #25 0xf76c3615 in gegl_node_blit_buffer (self=self@entry=0x23c6988, > buffer=buffer@entry=0x218e0e0, roi=roi@entry=0x23a6ca0, level=level@entry=0, > abyss_policy=abyss_policy@entry=GEGL_ABYSS_NONE) at > ../gegl/graph/gegl-node.c:1144 > #26 0xf76c3e48 in gegl_node_blit (self=, scale=1, > roi=roi@entry=0x23a6ca0, format=format@entry=0x1fd7f10, > destination_buf=destination_buf@entry=0x0, rowstride=3200, rowstride@entry=0, > flags=flags@entry=GEGL_BLIT_CACHE) at ../gegl/graph/gegl-node.c:1220 > #27 0xf76db7f6 in render_rectangle (processor=0x218d5c8) at > ../gegl/process/gegl-processor.c:513 > #28 gegl_processor_render (progress=0x0, rectangle=0x218d5dc, > processor=0x218d5c8) at ../gegl/process/gegl-processor.c:647 > #29 gegl_processor_work (processor=processor@entry=0x218d5c8, > progress=progress@entry=0x0) at ../gegl/process/gegl-processor.c:781 > #30 0xf76c37ea in gegl_node_process (self=) at > ../gegl/graph/gegl-node.c:1856 > #31 0x00401eac in standard_output (op_name=0x20c7140 "gegl:lens-correct") at > ../tools/gegl-tester.c:140 > #32 process_operations (type=) at ../tools/gegl-tester.c:246 > #33 0x0040187a in process_operations (type=) at > ../tools/gegl-tester.c:281 > #34 0x0040142f in main (argc=, argv=) at > ../tools/gegl-tester.c:328 -- 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: migrating pld /var/run to /run (and related dirs)
On Sun, Feb 09, 2020 at 10:13:37 +0100, Jan Rękorajski wrote: > What about plugging all this symlinking into geninitrd / dracut? > This way we would have everything sorted before we even start booting to > the filesystem in question. Won't work on systems without initrd, won't be functional without regenerating images on systems using it. But it should be possible to make this as systemd unit itself. -- Tomasz Pala ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: The proliferation of kernel packages (plan to drop nopae, 4.4 and 4.14)
On Sun, 26 Jan 2020, Marcin Krol wrote: > On 23-Jan-20 12:36, Jan Rękorajski wrote: > > I want to drop nopae, 4.4 and 4.14 kernels from Th, > > leaving us with longterm releases 4.9 (the last kernel that supports > > vserver), > > 4.19, 5.4 and a latest stable. > > > > Thoughs? Cons? > > 4.14 has longest planned support - up to Jan 2024 while 4.19 will EOL on > Dec 2020 and 5.4 will EOL on Dec 2021. It may be a good idea to keep > 4.14. Of course these date may change in future. Good point. That said, I will soon drop 4.4, 4.19 and nopae kernel. And disable PAE on i686 kernel on head. https://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-about-pae/ -- 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: migrating pld /var/run to /run (and related dirs)
On Thu, 06 Feb 2020, Arkadiusz Miśkiewicz wrote: > > Hi. > > We need to finally do this while still keeping sysvinit compatibility > (using symlinks). > > Migrate > > /var/run to /run and keep /var/run -> /run symlink > /var/lock to /run/lock and /var/lock -> /run/lock symlink > /run/shm -> /dev/shm symlink > (any other?) > > I wonder what is the best approach to do that on live servers. > > Debian: https://wiki.debian.org/ReleaseGoals/RunDirectory > > I guess migration needs to be in rc.sysinit. After rootfs and /var mount do: > - create /run dirs and convert old dirs to symlinks > - add /run* tmpfs mounting entries to /etc/fstab if not existent, so > next time migration logic via rc.sysinit will not be needed at all. /run should already be a dir. Looks at FHS.spec. I see one problem with your rc.sysinit proposal, what about systemd systems? You do need to do the convertsion, and you don't have that file. What about plugging all this symlinking into geninitrd / dracut? This way we would have everything sorted before we even start booting to the filesystem in question. -- 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: migrating pld /var/run to /run (and related dirs)
On Sat, 08 Feb 2020, Jacek Konieczny wrote: > On 2/8/20 6:52 PM, Tomasz Pala wrote: > > On Thu, Feb 06, 2020 at 19:20:26 +0100, Arkadiusz Miśkiewicz wrote: > > > >> We need to finally do this while still keeping sysvinit compatibility > >> (using symlinks). > > > > Why do we need to do this? Legacy SysVinit uses /var/run and works, > > while systemd systems are already handled well (tmpfiles etc.) in /run. > > New systemd won't even boot properly when /run is a symlink. And many Do we even have that anywhere (/run as symlink)? poldek:/all-avail> desc -ll FHS | grep /run modesizename drwxr-xr-x 6/run drwxr-xr-x 6/var/run/ And FHS.spec commit 4e9a06c31d tells me it was so from the very start. Our current systemd package has var-run.mount bind mounting /run there, so in this case is just a matter of removing that file and symlinking /var/run on next boot. Don't know how it looks for SysVinit running systems, but can't be more complicated IMHO. -- 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: migrating pld /var/run to /run (and related dirs)
On Sat, Feb 08, 2020 at 20:00:47 +0100, Jacek Konieczny wrote: > New systemd won't even boot properly when /run is a symlink. And many How about mount --bind? > That is why the /var/run -> /run symlink should be provided. Yes, what is I'm afraid is that our rpm doesn't handle dir->symlink transition. We still need to clean /var/run at system start as long as we support kernels without tmpfs. -- Tomasz Pala ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: migrating pld /var/run to /run (and related dirs)
On 2/8/20 6:52 PM, Tomasz Pala wrote: > On Thu, Feb 06, 2020 at 19:20:26 +0100, Arkadiusz Miśkiewicz wrote: > >> We need to finally do this while still keeping sysvinit compatibility >> (using symlinks). > > Why do we need to do this? Legacy SysVinit uses /var/run and works, > while systemd systems are already handled well (tmpfiles etc.) in /run. New systemd won't even boot properly when /run is a symlink. And many system components rely on /run and /var/run contents to be the same, especially when they are supposed to run on SysVinit and systemd systems with the same default config. > In other words: what problem are you going to solve and in which > scenarios? IMHO the /etc/init.d/ scripts should be kept as they are. That is why the /var/run -> /run symlink should be provided. Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: migrating pld /var/run to /run (and related dirs)
On Thu, Feb 06, 2020 at 19:20:26 +0100, Arkadiusz Miśkiewicz wrote: > We need to finally do this while still keeping sysvinit compatibility > (using symlinks). Why do we need to do this? Legacy SysVinit uses /var/run and works, while systemd systems are already handled well (tmpfiles etc.) in /run. In other words: what problem are you going to solve and in which scenarios? IMHO the /etc/init.d/ scripts should be kept as they are. -- Tomasz Pala ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Request for two packages
On Wed, Feb 05, 2020 at 07:57:59PM +0100, Tomasz Pala wrote: > On Wed, Feb 05, 2020 at 14:23:07 +, Saleem Khan wrote: > > Can we have following packages added to the repositories please? > > 1 ) Bleachbit > > 2 ) Stacer > Unless someone provides spec files, I doubt such programs would land in > PLD anytime soon. Both seem of little use for properly managed system. Saleem has already asked for bleachbit in ALT, here it is: http://git.altlinux.org/gears/b/bleachbit.git?p=bleachbit.git;a=tree http://bugzilla.altlinux.org/23106 Hope the already-tested package helps :-) -- WBR, Michael Shigorin / http://altlinux.org -- http://opennet.ru / http://anna-news.info ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Request for two packages
Hello, On Wed, Feb 05, 2020 at 14:23:07 +, Saleem Khan wrote: > Can we have following packages added to the repositories please? > > 1 ) Bleachbit > 2 ) Stacer Unless someone provides spec files, I doubt such programs would land in PLD anytime soon. Both seem of little use for properly managed system. -- Tomasz Pala ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/shadow] - shadow puts everything into /bin and /sbin - that's ok but provide symlinks for old (pwdutils) loc
On 1/9/20 12:32 PM, Elan Ruusamäe wrote: On 1/7/20 6:58 PM, Arkadiusz Miśkiewicz via pld-devel-en wrote: To goal is not to diverge from upstream. upstream reverted the change: - https://github.com/shadow-maint/shadow/pull/197 and it's released now: - https://github.com/shadow-maint/shadow/releases/tag/4.8.1 ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [projects/template-specs] - stop including perl macros, it's not needed, rpm does this on its own
On Sun, Jan 26, 2020 at 06:55:19PM +0100, Jan Rękorajski wrote:
> On Sun, 26 Jan 2020, Jakub Bogusz wrote:
>
> > On Sat, Jan 25, 2020 at 02:06:07PM +0100, baggins wrote:
> > > commit f75adea6b3f6c1343989e98a27167605ed55b780
> > > Author: Jan Rękorajski
> > > Date: Sat Jan 25 14:03:53 2020 +0100
> > >
> > > - stop including perl macros, it's not needed, rpm does this on its
> > > own
> >
> > I wonder how to specify dependency on rpm(-build) which includes
> > perl/php/* macros now.
> >
> > Currently building e.g. perl-* module with 1 month old rpm succeeds, but
> > results
> > in missing perl() reqs/provs.
>
> Only if you don't have rpm-*perlprov package. And it still wouldn't work
> even if you had that include, since it's just a bunch of macros from
> rpm-build package. Macros, that have been loaded automagically since $YEARS.
Oh, I was wrong about the way it works.
The perl/etc. macro files were indeed included, but until recent changes
%__perl_{provides,requires} macros were redefined to %{nil} in macros.build.
Then manual inclusion of macros.perl etc. in .spec redefined
%__perl_{provides,requires}
macros again to proper scripts.
After these commits:
e821f14cac60b7f9bf62abcbb848e114a92abc2f
cdc9189ebe27f76cf935f813eb75c89ec246604f
%__{perl,php,mono}_{provides,requires} macros are always defined to point to
actual scripts, so the manual inclusion of macros.{mono,perl,php} in specs is
obsolete since cdc9189ebe27f76cf935f813eb75c89ec246604f, first packaged as
rpm-pld-macros-build-1.744-3.
So it looks like after removal of manual provides the rpmbuild(macros)
dependency
should be bumped to 1.745 (after version bump in rpm-pld-macros).
(if I haven't missed something... after "solving" 4 boxes of Ikea
puzzles I'm a bit tired)
--
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: [projects/template-specs] - stop including perl macros, it's not needed, rpm does this on its own
On Sun, 26 Jan 2020, Jakub Bogusz wrote:
> On Sat, Jan 25, 2020 at 02:06:07PM +0100, baggins wrote:
> > commit f75adea6b3f6c1343989e98a27167605ed55b780
> > Author: Jan Rękorajski
> > Date: Sat Jan 25 14:03:53 2020 +0100
> >
> > - stop including perl macros, it's not needed, rpm does this on its own
>
> I wonder how to specify dependency on rpm(-build) which includes
> perl/php/* macros now.
>
> Currently building e.g. perl-* module with 1 month old rpm succeeds, but
> results
> in missing perl() reqs/provs.
Only if you don't have rpm-*perlprov package. And it still wouldn't work
even if you had that include, since it's just a bunch of macros from
rpm-build package. Macros, that have been loaded automagically since $YEARS.
> Maybe change rpm-*prov Provides to "= 1:%{version}" and bump
> rpm-*prov dependencies to 1:1.745?
> This would force upgrade to new rpm macros packaging/processing due to
> name changes (just remember not to provide rpm-build-macros in new macros
> packages to
> ensure they won't satisfy older rpm-build dependencies).
I believe that the P/O I added to new packages should be enough, but if
you think we need some more, please fell free to add them.
> The other thing is that some packages intentionally didn't include
> macros.perl or macros.php to avoid unwanted perl() / pear() dependencies
> autogeneration, but can be handled by _noautoreq_{perl,pear} now.
Dependency generation has nothing to do with macros, but all with
rpm-*prov packages. Even if you "skip" loading macros but you have the
generator package you'll have deps generated.
--
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 proliferation of kernel packages (plan to drop nopae, 4.4 and 4.14)
On 23-Jan-20 12:36, Jan Rękorajski wrote: I want to drop nopae, 4.4 and 4.14 kernels from Th, leaving us with longterm releases 4.9 (the last kernel that supports vserver), 4.19, 5.4 and a latest stable. Thoughs? Cons? 4.14 has longest planned support - up to Jan 2024 while 4.19 will EOL on Dec 2020 and 5.4 will EOL on Dec 2021. It may be a good idea to keep 4.14. Of course these date may change in future. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [projects/template-specs] - stop including perl macros, it's not needed, rpm does this on its own
On Sat, Jan 25, 2020 at 02:06:07PM +0100, baggins wrote:
> commit f75adea6b3f6c1343989e98a27167605ed55b780
> Author: Jan Rękorajski
> Date: Sat Jan 25 14:03:53 2020 +0100
>
> - stop including perl macros, it's not needed, rpm does this on its own
I wonder how to specify dependency on rpm(-build) which includes
perl/php/* macros now.
Currently building e.g. perl-* module with 1 month old rpm succeeds, but results
in missing perl() reqs/provs.
Maybe change rpm-*prov Provides to "= 1:%{version}" and bump
rpm-*prov dependencies to 1:1.745?
This would force upgrade to new rpm macros packaging/processing due to
name changes (just remember not to provide rpm-build-macros in new macros
packages to
ensure they won't satisfy older rpm-build dependencies).
The other thing is that some packages intentionally didn't include
macros.perl or macros.php to avoid unwanted perl() / pear() dependencies
autogeneration, but can be handled by _noautoreq_{perl,pear} 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: poldek - strange orphans processing [Re: OK: COMMAND]
On Thu, 2020-01-16 at 17:54 +0100, Jakub Bogusz wrote: > I asked to greedy remove itk. > It removed itk-devel by dependency, as it should, but why it removed > itcl-devel too??? > > mark itk-4.1.0-1.i686 > > Processing dependencies... > > itk-4.1.0-1.i686 marks itk-devel-4.1.0-1.i686 (req itk = 4.1.0-1) > > itk-devel-4.1.0-1.i686 marks orphaned itcl-devel-4.1.1-1.i686 (req > > itcl-devel >= 4.1) > > There are 3 packages to remove (2 marked by dependencies): > > R itk-4.1.0-1.i686 > > D itcl-devel-4.1.1-1.i686 itk-devel-4.1.0-1.i686 Looks like poldek greedy mode is on? Without greedy it works as expected for me. itcl-devel is removed because itk-devel requires itcl-devel _and_ itcl-devel is not required by anyone else; "orphaned" message is misleading here, any ideas how to name it? ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
poldek - strange orphans processing [Re: OK: COMMAND]
I asked to greedy remove itk. It removed itk-devel by dependency, as it should, but why it removed itcl-devel too??? On Thu, Jan 16, 2020 at 04:45:38PM +, PLD th-i686 builder wrote: > COMMAND (): OK > > --- COMMAND:: > Build-Time: user:0.70s sys:0.21s real:1.16s (faults io:0 non-io:62263) > > > > *** buildlog for COMMAND > mark itk-4.1.0-1.i686 > Processing dependencies... > itk-4.1.0-1.i686 marks itk-devel-4.1.0-1.i686 (req itk = 4.1.0-1) > itk-devel-4.1.0-1.i686 marks orphaned itcl-devel-4.1.1-1.i686 (req > itcl-devel >= 4.1) > There are 3 packages to remove (2 marked by dependencies): > R itk-4.1.0-1.i686 > D itcl-devel-4.1.1-1.i686 itk-devel-4.1.0-1.i686 > This operation will free 226.5KB of disk space. > Running pm-command.sh --erase --root /... > Begin-PLD-Builder-Info > Build-Time: user:0.70s sys:0.21s real:1.16s (faults io:0 non-io:62263) > > End-PLD-Builder-Info > -- 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/apr] - up to 1.7.0
On Sat, Jan 11, 2020 at 10:00:30PM +0100, arekm wrote:
> commit 48dac5e93206c31066f91484526df2e4c2c29480
> Author: Arkadiusz Miśkiewicz
> Date: Sat Jan 11 22:00:22 2020 +0100
>
> - up to 1.7.0
>
> apr.spec | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
> ---
> diff --git a/apr.spec b/apr.spec
> index 90514c4..9ccc5e3 100644
> --- a/apr.spec
> +++ b/apr.spec
> @@ -5,17 +5,18 @@
[...]
> Patch1: %{name}-libtool.patch
> # disable some things that require recent kernel
> Patch2: %{name}-disable-features.patch
> +Patch3: x
Missing in repo.
--
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/shadow] - shadow puts everything into /bin and /sbin - that's ok but provide symlinks for old (pwdutils) loc
On 1/7/20 6:58 PM, Arkadiusz Miśkiewicz via pld-devel-en wrote: To goal is not to diverge from upstream. upstream reverted the change: - https://github.com/shadow-maint/shadow/pull/197 ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/shadow] - shadow puts everything into /bin and /sbin - that's ok but provide symlinks for old (pwdutils) loc
On Tue, Jan 07, 2020 at 05:58:46PM +0100, Arkadiusz Miśkiewicz via pld-devel-en
wrote:
> On 07/01/2020 17:06, Jakub Bogusz wrote:
> > On Tue, Jan 07, 2020 at 01:36:44PM +0100, arekm wrote:
> >> commit 2bb4da0ffecbbc08e6e25336b3e1e012b7cd61a5
> >> Author: Arkadiusz Miśkiewicz
> >> Date: Tue Jan 7 13:36:34 2020 +0100
> >>
> >> - shadow puts everything into /bin and /sbin - that's ok but provide
> >> symlinks for old (pwdutils) locations
> > [...]
> >> +# compatibility with old locations (and pwdutils)
> >> +install -d $RPM_BUILD_ROOT%{_bindir}
> >> +for f in chage chfn chsh expiry faillog gpasswd newgrp newgidmap passwd
> >> newuidmap sg; do
> >> + ln -s /bin/${f} $RPM_BUILD_ROOT%{_bindir}/${f}
> >> +done
> >> +install -d $RPM_BUILD_ROOT%{_sbindir}
> >> +for f in chgpasswd chpasswd groupadd groupdel groupmems groupmod grpck
> >> grpconv grpunconv logoutd newusers pwck pwconv pwunconv useradd userdel
> >> usermod vigr vipw; do
> >> + ln -s /sbin/${f} $RPM_BUILD_ROOT%{_sbindir}/${f}
> >> +done
> >> +
[...]
> >> +%attr(755,root,root) /sbin/groupmems
> >> %attr(755,root,root) %{_sbindir}/groupmems
> >> +%attr(755,root,root) /sbin/groupmod
> >> %attr(755,root,root) %{_sbindir}/groupmod
> > [...]
> >
> > Uhhh, please, no.
>
> It's ugly but I don't see any other solution that would work.
>
> > Either go traditional way and distribute binaries over directories (like
> > in coreutils),
>
> To goal is not to diverge from upstream.
Upstream installs everything to prefix given to configure.
Or /bin + /sbin, if it's told so to %configure in spec.
> or maybe it's time to go merged-/usr distro-wide?
> >
> > Are there still any profits from using local / with network or host shared
> > /usr?
>
> Does it matter for this case?
Debian moved to merged /usr too, in such case both paths work regardless
of actual install paths.
--
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/shadow] - shadow puts everything into /bin and /sbin - that's ok but provide symlinks for old (pwdutils) loc
On 07/01/2020 17:06, Jakub Bogusz wrote:
> On Tue, Jan 07, 2020 at 01:36:44PM +0100, arekm wrote:
>> commit 2bb4da0ffecbbc08e6e25336b3e1e012b7cd61a5
>> Author: Arkadiusz Miśkiewicz
>> Date: Tue Jan 7 13:36:34 2020 +0100
>>
>> - shadow puts everything into /bin and /sbin - that's ok but provide
>> symlinks for old (pwdutils) locations
> [...]
>> +# compatibility with old locations (and pwdutils)
>> +install -d $RPM_BUILD_ROOT%{_bindir}
>> +for f in chage chfn chsh expiry faillog gpasswd newgrp newgidmap passwd
>> newuidmap sg; do
>> + ln -s /bin/${f} $RPM_BUILD_ROOT%{_bindir}/${f}
>> +done
>> +install -d $RPM_BUILD_ROOT%{_sbindir}
>> +for f in chgpasswd chpasswd groupadd groupdel groupmems groupmod grpck
>> grpconv grpunconv logoutd newusers pwck pwconv pwunconv useradd userdel
>> usermod vigr vipw; do
>> + ln -s /sbin/${f} $RPM_BUILD_ROOT%{_sbindir}/${f}
>> +done
>> +
> [...]
>> +%attr(4755,root,root) /bin/chfn
>> %attr(4755,root,root) %{_bindir}/chfn
>> +%attr(4755,root,root) /bin/chsh
>> %attr(4755,root,root) %{_bindir}/chsh
>> +%attr(4755,root,root) /bin/expiry
>> %attr(4755,root,root) %{_bindir}/expiry
>> +%attr(4755,root,root) /bin/gpasswd
>> %attr(4755,root,root) %{_bindir}/gpasswd
>> +%attr(4755,root,root) /bin/passwd
>> %attr(4755,root,root) %{_bindir}/passwd
>> +%attr(4755,root,root) /bin/chage
>> %attr(4755,root,root) %{_bindir}/chage
>> +%attr(755,root,root) /bin/faillog
>> %attr(755,root,root) %{_bindir}/faillog
>> +%attr(4755,root,root) /bin/newgrp
>> %attr(4755,root,root) %{_bindir}/newgrp
>> +%attr(755,root,root) /bin/sg
>> %attr(755,root,root) %{_bindir}/sg
>> +%attr(755,root,root) /sbin/chgpasswd
>> %attr(755,root,root) %{_sbindir}/chgpasswd
>> +%attr(755,root,root) /sbin/chpasswd
>> %attr(755,root,root) %{_sbindir}/chpasswd
>> +%attr(755,root,root) /sbin/groupadd
>> %attr(755,root,root) %{_sbindir}/groupadd
>> +%attr(755,root,root) /sbin/groupdel
>> %attr(755,root,root) %{_sbindir}/groupdel
>> +%attr(755,root,root) /sbin/groupmems
>> %attr(755,root,root) %{_sbindir}/groupmems
>> +%attr(755,root,root) /sbin/groupmod
>> %attr(755,root,root) %{_sbindir}/groupmod
> [...]
>
> Uhhh, please, no.
It's ugly but I don't see any other solution that would work.
> Either go traditional way and distribute binaries over directories (like
> in coreutils),
To goal is not to diverge from upstream.
or maybe it's time to go merged-/usr distro-wide?
>
> Are there still any profits from using local / with network or host shared
> /usr?
Does it matter for this case?
The only goal of symlinks it to have this package working in current PLD
which has hardcoded /usr paths to some of these binaries.
--
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/shadow] - shadow puts everything into /bin and /sbin - that's ok but provide symlinks for old (pwdutils) loc
On Tue, Jan 07, 2020 at 01:36:44PM +0100, arekm wrote:
> commit 2bb4da0ffecbbc08e6e25336b3e1e012b7cd61a5
> Author: Arkadiusz Miśkiewicz
> Date: Tue Jan 7 13:36:34 2020 +0100
>
> - shadow puts everything into /bin and /sbin - that's ok but provide
> symlinks for old (pwdutils) locations
[...]
> +# compatibility with old locations (and pwdutils)
> +install -d $RPM_BUILD_ROOT%{_bindir}
> +for f in chage chfn chsh expiry faillog gpasswd newgrp newgidmap passwd
> newuidmap sg; do
> + ln -s /bin/${f} $RPM_BUILD_ROOT%{_bindir}/${f}
> +done
> +install -d $RPM_BUILD_ROOT%{_sbindir}
> +for f in chgpasswd chpasswd groupadd groupdel groupmems groupmod grpck
> grpconv grpunconv logoutd newusers pwck pwconv pwunconv useradd userdel
> usermod vigr vipw; do
> + ln -s /sbin/${f} $RPM_BUILD_ROOT%{_sbindir}/${f}
> +done
> +
[...]
> +%attr(4755,root,root) /bin/chfn
> %attr(4755,root,root) %{_bindir}/chfn
> +%attr(4755,root,root) /bin/chsh
> %attr(4755,root,root) %{_bindir}/chsh
> +%attr(4755,root,root) /bin/expiry
> %attr(4755,root,root) %{_bindir}/expiry
> +%attr(4755,root,root) /bin/gpasswd
> %attr(4755,root,root) %{_bindir}/gpasswd
> +%attr(4755,root,root) /bin/passwd
> %attr(4755,root,root) %{_bindir}/passwd
> +%attr(4755,root,root) /bin/chage
> %attr(4755,root,root) %{_bindir}/chage
> +%attr(755,root,root) /bin/faillog
> %attr(755,root,root) %{_bindir}/faillog
> +%attr(4755,root,root) /bin/newgrp
> %attr(4755,root,root) %{_bindir}/newgrp
> +%attr(755,root,root) /bin/sg
> %attr(755,root,root) %{_bindir}/sg
> +%attr(755,root,root) /sbin/chgpasswd
> %attr(755,root,root) %{_sbindir}/chgpasswd
> +%attr(755,root,root) /sbin/chpasswd
> %attr(755,root,root) %{_sbindir}/chpasswd
> +%attr(755,root,root) /sbin/groupadd
> %attr(755,root,root) %{_sbindir}/groupadd
> +%attr(755,root,root) /sbin/groupdel
> %attr(755,root,root) %{_sbindir}/groupdel
> +%attr(755,root,root) /sbin/groupmems
> %attr(755,root,root) %{_sbindir}/groupmems
> +%attr(755,root,root) /sbin/groupmod
> %attr(755,root,root) %{_sbindir}/groupmod
[...]
Uhhh, please, no.
Either go traditional way and distribute binaries over directories (like
in coreutils), or maybe it's time to go merged-/usr distro-wide?
Are there still any profits from using local / with network or host shared /usr?
--
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/gcc6-java] - restored gcc 6.5.0, the last version with Java support
On 19.12.2019 21:27, qboosh wrote: - restored gcc 6.5.0, the last version with Java support why not just branch off that repo from the 6.5.0 commit? ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: broken deps
On Thu, Dec 19, 2019 at 02:44:35PM +0200, Elan Ruusamäe wrote: > if built package requires newer symbols ...it can just tell so; see set-versions in ALT RPM (jbj@ knows about that patch, just in case). But it's no smaller feat than gradually changing the whole versioning scheme in a repository towards those providing more information, and that will have an impact on both rpmdb size and repo-level tool speed. https://github.com/svpv/protva2016/blob/master/protva2016.pdf for those still interested and able to read Russian :) -- WBR, Michael Shigorin / http://altlinux.org -- http://opennet.ru / http://anna-news.info ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: broken deps
On 12/18/19 4:48 PM, Jan Rękorajski wrote: On Wed, 18 Dec 2019, Elan Ruusamäe wrote: On 12/18/19 4:12 PM, Jan Rękorajski wrote: On Wed, 18 Dec 2019, Elan Ruusamäe wrote: ``` 15:57:37 root[load: 0.35]@predator ~# fontpostinst TTF /usr/bin/fc-cache: symbol lookup error: /usr/lib64/libfontconfig.so.1: undefined symbol: FT_Done_MM_Var 15:57:40 root[load: 0.35]@predator ~# pkgbytime fontc Thu Jul 5 16:20:39 2018 fontconfig-libs-2.13.0-3.x86_64 Thu Jul 5 16:20:41 2018 fontconfig-2.13.0-3.x86_64 16:00:30 root[load: 0.26]@predator ~# rpm -qf /usr/bin/fc-cache /usr/lib64/libfontconfig.so.1 fontconfig-2.13.0-3.x86_64 fontconfig-libs-2.13.0-3.x86_64 16:00:36 root[load: 0.24]@predator ~# pkgbytime freet Tue May 16 13:01:32 2017 freetype-2.7.1-1.x86_64 [root@starbug ~]# fontpostinst TTF ; echo $? 0 [root@starbug ~]# rpm -qf /usr/bin/fc-cache fontconfig-2.13.1-1.x86_64 [root@starbug ~]# rpm -q freetype freetype-2.10.1-2.x86_64 apparently it was fixed by qboosh 1 year, 4 months ago, but no rebuild. added rebuild: - https://github.com/pld-linux/fontconfig/commit/34d0d813473923d3bb6c083b4d332d75b34f147f You completely missed the point, which was "there is nothing wrong in th now, you're running outdated packages". I'm not hiromant to read all that just from console output you pasted. I read only arrogant "works for me, don't care" from it. i totally disagree with the ideology that only way to keep pld distro stable is to "poldek --upgrade-dist". if built package requires newer symbols, it must require updated package as well. and qboosh commit did that. ps: lists archive broken? - http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2019-December/thread.html Works for me. You're looking at the wrong list? ah, indeed. thanks ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: broken deps
On Wed, 18 Dec 2019, Elan Ruusamäe wrote: > > On 12/18/19 4:12 PM, Jan Rękorajski wrote: > > On Wed, 18 Dec 2019, Elan Ruusamäe wrote: > > > >> ``` > >> 15:57:37 root[load: 0.35]@predator ~# fontpostinst TTF > >> /usr/bin/fc-cache: symbol lookup error: /usr/lib64/libfontconfig.so.1: > >> undefined symbol: FT_Done_MM_Var > >> > >> 15:57:40 root[load: 0.35]@predator ~# pkgbytime fontc > >> Thu Jul 5 16:20:39 2018 fontconfig-libs-2.13.0-3.x86_64 > >> Thu Jul 5 16:20:41 2018 fontconfig-2.13.0-3.x86_64 > >> > >> 16:00:30 root[load: 0.26]@predator ~# rpm -qf /usr/bin/fc-cache > >> /usr/lib64/libfontconfig.so.1 > >> fontconfig-2.13.0-3.x86_64 > >> fontconfig-libs-2.13.0-3.x86_64 > >> > >> 16:00:36 root[load: 0.24]@predator ~# pkgbytime freet > >> Tue May 16 13:01:32 2017 freetype-2.7.1-1.x86_64 > > [root@starbug ~]# fontpostinst TTF ; echo $? > > 0 > > [root@starbug ~]# rpm -qf /usr/bin/fc-cache > > fontconfig-2.13.1-1.x86_64 > > [root@starbug ~]# rpm -q freetype > > freetype-2.10.1-2.x86_64 > > > apparently it was fixed by qboosh 1 year, 4 months ago, but no rebuild. > > > added rebuild: > > - > https://github.com/pld-linux/fontconfig/commit/34d0d813473923d3bb6c083b4d332d75b34f147f You completely missed the point, which was "there is nothing wrong in th now, you're running outdated packages". > ps: lists archive broken? > > - > http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2019-December/thread.html Works for me. You're looking at the wrong list? -- 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: broken deps
On 12/18/19 4:12 PM, Jan Rękorajski wrote: On Wed, 18 Dec 2019, Elan Ruusamäe wrote: ``` 15:57:37 root[load: 0.35]@predator ~# fontpostinst TTF /usr/bin/fc-cache: symbol lookup error: /usr/lib64/libfontconfig.so.1: undefined symbol: FT_Done_MM_Var 15:57:40 root[load: 0.35]@predator ~# pkgbytime fontc Thu Jul 5 16:20:39 2018 fontconfig-libs-2.13.0-3.x86_64 Thu Jul 5 16:20:41 2018 fontconfig-2.13.0-3.x86_64 16:00:30 root[load: 0.26]@predator ~# rpm -qf /usr/bin/fc-cache /usr/lib64/libfontconfig.so.1 fontconfig-2.13.0-3.x86_64 fontconfig-libs-2.13.0-3.x86_64 16:00:36 root[load: 0.24]@predator ~# pkgbytime freet Tue May 16 13:01:32 2017 freetype-2.7.1-1.x86_64 [root@starbug ~]# fontpostinst TTF ; echo $? 0 [root@starbug ~]# rpm -qf /usr/bin/fc-cache fontconfig-2.13.1-1.x86_64 [root@starbug ~]# rpm -q freetype freetype-2.10.1-2.x86_64 apparently it was fixed by qboosh 1 year, 4 months ago, but no rebuild. added rebuild: - https://github.com/pld-linux/fontconfig/commit/34d0d813473923d3bb6c083b4d332d75b34f147f ps: lists archive broken? - http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2019-December/thread.html ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: broken deps
On Wed, 18 Dec 2019, Elan Ruusamäe wrote: > ``` > 15:57:37 root[load: 0.35]@predator ~# fontpostinst TTF > /usr/bin/fc-cache: symbol lookup error: /usr/lib64/libfontconfig.so.1: > undefined symbol: FT_Done_MM_Var > > 15:57:40 root[load: 0.35]@predator ~# pkgbytime fontc > Thu Jul 5 16:20:39 2018 fontconfig-libs-2.13.0-3.x86_64 > Thu Jul 5 16:20:41 2018 fontconfig-2.13.0-3.x86_64 > > 16:00:30 root[load: 0.26]@predator ~# rpm -qf /usr/bin/fc-cache > /usr/lib64/libfontconfig.so.1 > fontconfig-2.13.0-3.x86_64 > fontconfig-libs-2.13.0-3.x86_64 > > 16:00:36 root[load: 0.24]@predator ~# pkgbytime freet > Tue May 16 13:01:32 2017 freetype-2.7.1-1.x86_64 [root@starbug ~]# fontpostinst TTF ; echo $? 0 [root@starbug ~]# rpm -qf /usr/bin/fc-cache fontconfig-2.13.1-1.x86_64 [root@starbug ~]# rpm -q freetype freetype-2.10.1-2.x86_64 -- 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/zsh] - (re)added info patch (unify direntry) - explicit /etc files
On 02.12.2019 21:36, qboosh wrote: commit dab1d12108ed9cf26d3607c30f4b8878e65d2382 Author: Jakub Bogusz Date: Mon Dec 2 20:37:28 2019 +0100 - (re)added info patch (unify direntry) can you please submit these upstream? why is pld maintaining these over decades? ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs acl.pl not executable
On 04.12.2019 21:50, Jakub Bogusz wrote: Is it intentional? $ cvs ci ... uid_gid.db.txt cvs commit: cannot exec /cvsroot/CVSROOT/acl.pl: Permission denied cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first! unknown. fixed ``` root@1822-cvs /cvsroot/CVSROOT# ls -l --full /cvsroot/CVSROOT/acl.pl -r--r--r-- 1 cvs cvs 1086 2019-11-20 15:12:27.051548021 +0200 /cvsroot/CVSROOT/acl.pl 00:37:51 [load: 0.54 13.50% nproc: 4] root@1822-cvs /cvsroot/CVSROOT# chmod a+rx /cvsroot/CVSROOT/acl.pl 00:37:56 [load: 0.50 12.50% nproc: 4] root@1822-cvs /cvsroot/CVSROOT# ls -l --full /cvsroot/CVSROOT/acl.pl -r-xr-xr-x 1 cvs cvs 1086 2019-11-20 15:12:27.051548021 +0200 /cvsroot/CVSROOT/acl.pl* ``` might caused by cvs update itself, as the script is present in `checkoutlist`: ``` root@1822-cvs /cvsroot/CVSROOT# grep -n acl.pl checkoutlist 26:acl.pl ``` ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: git errors?
On 22/11/2019 17:42, Arkadiusz Miśkiewicz wrote: > On 22/11/2019 16:04, Elan Ruusamäe wrote: >> >> On 11/20/19 12:30 PM, Arkadiusz Miśkiewicz wrote: >>> On 20/11/2019 07:46, Elan Ruusamäe wrote: On 20.11.2019 01:06, Elan Ruusamäe wrote: occupied by Refs.git. I never understood that repo purpose... whatever the slug_watch-cron is doing, it's hitting at */15 and creating another ~500mb failed pack. >>> It runs "git gc" and leaves that tmp* when it fails. And it failed >>> because repository got somehow corrupted. >>> >>> >>> Was able to repair Refs.git repository (this repository is used by git >>> pld clone/fetch operations). >>> >>> Things should be back to normal now. >> >> yet no more commits are added there. > > Doh, and now the question is which script commited there. Kacper? That's also fixed (by starting slug_watch). -- 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: git errors?
On 22/11/2019 16:04, Elan Ruusamäe wrote: > > On 11/20/19 12:30 PM, Arkadiusz Miśkiewicz wrote: >> On 20/11/2019 07:46, Elan Ruusamäe wrote: >>> On 20.11.2019 01:06, Elan Ruusamäe wrote: >>> >>> occupied by Refs.git. I never understood that repo purpose... >>> >>> whatever the slug_watch-cron is doing, it's hitting at */15 and creating >>> another ~500mb failed pack. >> It runs "git gc" and leaves that tmp* when it fails. And it failed >> because repository got somehow corrupted. >> >> >> Was able to repair Refs.git repository (this repository is used by git >> pld clone/fetch operations). >> >> Things should be back to normal now. > > yet no more commits are added there. Doh, and now the question is which script commited there. Kacper? > > > ``` > root@1822-cvs repositories/Refs.git# git log -1 > commit 6d3e98486d0849e9d2b3814df99644b47074c938 (HEAD -> master) > Author: git > Date: Mon Nov 18 23:49:27 2019 +0100 > > Changes by atler > > ``` > > ___ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en -- 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: git errors?
On 11/20/19 12:30 PM, Arkadiusz Miśkiewicz wrote: On 20/11/2019 07:46, Elan Ruusamäe wrote: On 20.11.2019 01:06, Elan Ruusamäe wrote: occupied by Refs.git. I never understood that repo purpose... whatever the slug_watch-cron is doing, it's hitting at */15 and creating another ~500mb failed pack. It runs "git gc" and leaves that tmp* when it fails. And it failed because repository got somehow corrupted. Was able to repair Refs.git repository (this repository is used by git pld clone/fetch operations). Things should be back to normal now. yet no more commits are added there. ``` root@1822-cvs repositories/Refs.git# git log -1 commit 6d3e98486d0849e9d2b3814df99644b47074c938 (HEAD -> master) Author: git Date: Mon Nov 18 23:49:27 2019 +0100 Changes by atler ``` ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: git errors?
On 20/11/2019 07:46, Elan Ruusamäe wrote: > On 20.11.2019 01:06, Elan Ruusamäe wrote: > > occupied by Refs.git. I never understood that repo purpose... > > whatever the slug_watch-cron is doing, it's hitting at */15 and creating > another ~500mb failed pack. It runs "git gc" and leaves that tmp* when it fails. And it failed because repository got somehow corrupted. Was able to repair Refs.git repository (this repository is used by git pld clone/fetch operations). Things should be back to normal 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: git errors?
On 20.11.2019 01:06, Elan Ruusamäe wrote: occupied by Refs.git. I never understood that repo purpose... whatever the slug_watch-cron is doing, it's hitting at */15 and creating another ~500mb failed pack. disabling that cron for now. one more run and disk is full again. ``` root@1822-cvs repositories/Refs.git# l -rt objects/pack/tmp_pack_* |tail -r--rwxr--+ 1 git git 518M Nov 19 02:00 objects/pack/tmp_pack_TOKPzf* -r--rwxr--+ 1 git git 518M Nov 19 02:15 objects/pack/tmp_pack_C6ncYj* -r--rwxr--+ 1 git git 394M Nov 19 02:30 objects/pack/tmp_pack_1pofxe* -r--rwx---+ 1 git git 43M Nov 19 10:43 objects/pack/tmp_pack_eDeqJK* -r--rwx---+ 1 git git 518M Nov 19 11:14 objects/pack/tmp_pack_j1RWYF* -r--rwx---+ 1 git git 518M Nov 19 11:25 objects/pack/tmp_pack_BtnlQ5* -r--rwx---+ 1 git git 324M Nov 19 11:28 objects/pack/tmp_pack_2dOxMA* -r--rwx---+ 1 git git 518M Nov 19 11:30 objects/pack/tmp_pack_rgSPDh* -r--r--r-- 1 git git 518M Nov 20 01:15 objects/pack/tmp_pack_BiGbKn -r--r--r-- 1 git git 518M Nov 20 01:30 objects/pack/tmp_pack_GGMCo8 ``` ``` root@1822-cvs repositories/Refs.git# grep /usr/bin/slug_watch-cron /var/log/cron|tail Mar 22 05:30:01 1822-cvs CROND[9405]: (git) CMD (/usr/bin/slug_watch-cron) Mar 22 05:45:01 1822-cvs CROND[5946]: (git) CMD (/usr/bin/slug_watch-cron) Mar 22 06:00:01 1822-cvs CROND[3733]: (git) CMD (/usr/bin/slug_watch-cron) Mar 22 06:15:01 1822-cvs CROND[32181]: (git) CMD (/usr/bin/slug_watch-cron) Mar 22 06:30:01 1822-cvs CROND[22009]: (git) CMD (/usr/bin/slug_watch-cron) Mar 22 06:45:01 1822-cvs CROND[19842]: (git) CMD (/usr/bin/slug_watch-cron) Mar 22 07:00:01 1822-cvs CROND[17307]: (git) CMD (/usr/bin/slug_watch-cron) Mar 22 07:15:01 1822-cvs CROND[15668]: (git) CMD (/usr/bin/slug_watch-cron) Mar 22 07:30:01 1822-cvs CROND[13747]: (git) CMD (/usr/bin/slug_watch-cron) Binary file /var/log/cron matches ``` ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: git errors?
On 20.11.2019 01:06, Elan Ruusamäe wrote: occupied by Refs.git. I never understood that repo purpose... whatever the slug_watch-cron is doing, it's hitting at */15 and creating another ~500mb failed pack. disabling that cron for now. one more run and disk is full again. ``` root@1822-cvs repositories/Refs.git# l -rt objects/pack/tmp_pack_* |tail -r--rwxr--+ 1 git git 518M Nov 19 02:00 objects/pack/tmp_pack_TOKPzf* -r--rwxr--+ 1 git git 518M Nov 19 02:15 objects/pack/tmp_pack_C6ncYj* -r--rwxr--+ 1 git git 394M Nov 19 02:30 objects/pack/tmp_pack_1pofxe* -r--rwx---+ 1 git git 43M Nov 19 10:43 objects/pack/tmp_pack_eDeqJK* -r--rwx---+ 1 git git 518M Nov 19 11:14 objects/pack/tmp_pack_j1RWYF* -r--rwx---+ 1 git git 518M Nov 19 11:25 objects/pack/tmp_pack_BtnlQ5* -r--rwx---+ 1 git git 324M Nov 19 11:28 objects/pack/tmp_pack_2dOxMA* -r--rwx---+ 1 git git 518M Nov 19 11:30 objects/pack/tmp_pack_rgSPDh* -r--r--r-- 1 git git 518M Nov 20 01:15 objects/pack/tmp_pack_BiGbKn -r--r--r-- 1 git git 518M Nov 20 01:30 objects/pack/tmp_pack_GGMCo8 ``` ``` root@1822-cvs repositories/Refs.git# grep /usr/bin/slug_watch-cron /var/log/cron|tail Mar 22 05:30:01 1822-cvs CROND[9405]: (git) CMD (/usr/bin/slug_watch-cron) Mar 22 05:45:01 1822-cvs CROND[5946]: (git) CMD (/usr/bin/slug_watch-cron) Mar 22 06:00:01 1822-cvs CROND[3733]: (git) CMD (/usr/bin/slug_watch-cron) Mar 22 06:15:01 1822-cvs CROND[32181]: (git) CMD (/usr/bin/slug_watch-cron) Mar 22 06:30:01 1822-cvs CROND[22009]: (git) CMD (/usr/bin/slug_watch-cron) Mar 22 06:45:01 1822-cvs CROND[19842]: (git) CMD (/usr/bin/slug_watch-cron) Mar 22 07:00:01 1822-cvs CROND[17307]: (git) CMD (/usr/bin/slug_watch-cron) Mar 22 07:15:01 1822-cvs CROND[15668]: (git) CMD (/usr/bin/slug_watch-cron) Mar 22 07:30:01 1822-cvs CROND[13747]: (git) CMD (/usr/bin/slug_watch-cron) Binary file /var/log/cron matches ``` ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: git errors?
On 19.11.2019 10:40, Arkadiusz Miśkiewicz wrote: Yes, added 10GB, another 10GB free left to be assigned. And it's gone. 21G /cvs/root/gitolite/ gitolite ate that new 10GB. glen, could you look? occupied by Refs.git. I never understood that repo purpose... ``` root@1822-cvs gitolite/repositories# less du-20191120.txt 1. Refs.git/ 16691.22 MiB 2. packages/ 3402.93 MiB 3. SPECS.git/ 2504.43 MiB ``` ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: git errors?
On 18/11/2019 20:32, Arkadiusz Miśkiewicz wrote: > On 18/11/2019 20:19, Jakub Bogusz wrote: >> $ git push >> Enter passphrase for key '/home/comp/.ssh/id_rsa': >> Enumerating objects: 5, done. >> Counting objects: 100% (5/5), done. >> Delta compression using up to 4 threads >> Compressing objects: 100% (3/3), done. >> Writing objects: 100% (3/3), 906 bytes | 906.00 KiB/s, done. >> Total 3 (delta 1), reused 0 (delta 0) >> error: remote unpack failed: unable to create temporary object directory >> To ssh://git.pld-linux.org/packages/gnome-sound-recorder >> ! [remote rejected] HEAD -> master (unpacker error) >> error: failed to push some refs to >> 'ssh://g...@git.pld-linux.org/packages/gnome-sound-recorder' >> >> ENOSPC or so? > > Yes, added 10GB, another 10GB free left to be assigned. And it's gone. 21G /cvs/root/gitolite/ gitolite ate that new 10GB. glen, could you look? -- 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: git errors?
On 18/11/2019 20:19, Jakub Bogusz wrote: > $ git push > Enter passphrase for key '/home/comp/.ssh/id_rsa': > Enumerating objects: 5, done. > Counting objects: 100% (5/5), done. > Delta compression using up to 4 threads > Compressing objects: 100% (3/3), done. > Writing objects: 100% (3/3), 906 bytes | 906.00 KiB/s, done. > Total 3 (delta 1), reused 0 (delta 0) > error: remote unpack failed: unable to create temporary object directory > To ssh://git.pld-linux.org/packages/gnome-sound-recorder > ! [remote rejected] HEAD -> master (unpacker error) > error: failed to push some refs to > 'ssh://g...@git.pld-linux.org/packages/gnome-sound-recorder' > > ENOSPC or so? Yes, added 10GB, another 10GB free left to be assigned. -- 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: don't install pld openssh-8.0p1-3.x86_64
On 04/11/2019 22:42, Elan Ruusamäe wrote: > wth? > > > ``` > > Nov 4 23:37:43 glen sshd[17003]: fatal: privsep_preauth: preauth child > terminated by signal 31 > > ``` > > if this is (was) known issue these should be posted to devel list so > people don't get locked out of their systems. hmm, something new https://github.com/openssh/openssh-portable/pull/149 -- 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: th-x32 builder stuck or dead?
On 26/10/2019 14:32, Jakub Bogusz wrote: > What happened to th-x32 builder? > It either got stuck building python3-typed_ast-1.4.0-2 or died... > carme-x32 builds python3-typed_ast-1.4.0-2 without problems. restarted, tons of cron/python processes... syslog-ng again? hmm -- 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/librsvg] - updated dependencies; librsvg since 2.42 is partially in rust (what with th-x32?)
On Sat, 12 Oct 2019, Jakub Bogusz wrote: > On Wed, Jan 30, 2019 at 09:05:10PM +0100, Jan Rękorajski wrote: > > On Wed, 30 Jan 2019, Jakub Bogusz wrote: > > > > > On Wed, Jan 30, 2019 at 08:20:00PM +0100, qboosh wrote: > > > > commit fc65f7f1cf360e29b7e44b9835dece9805ad9dbc > > > > Author: Jakub Bogusz > > > > Date: Wed Jan 30 20:25:13 2019 +0100 > > > > > > > > - updated dependencies; librsvg since 2.42 is partially in rust > > > > (what with th-x32?) > > > > > > According to rust project site, code generation and std lib is supported > > > on x32, but there is no rustc hosted on x32 system - I assume that x86_64 > > > rustc must be used... > > > > 1. librsvg-c for x32? https://lwn.net/Articles/771355/ > > 2. get rust functional on x32 (I'm fine with x86_64 runtime and x32 stdlib) > > 3. drop x32 possibly? https://lwn.net/Articles/774734/ > > Followup: > > eog 3.34 already (optionally) requires rust-based librsvg >= 2.44), so > sticking > to 2.40.x is no longer an option. This strict version dependency is bullshit. As expected. You are welcome. -- 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/sudo] - up to 1.8.28
On 17/10/2019 17:18, Elan Ruusamäe wrote: > > On 16/10/2019 14:24, arekm wrote: >> commit 89b19f0a628b14fd900f10b9a70868a4feba74a5 >> Author: Arkadiusz Miśkiewicz >> Date: Wed Oct 16 13:24:09 2019 +0200 >> >> - up to 1.8.28 >> * Fixed CVE-2019-14287, a bug where a sudo user may be able to >> run a command as root when the Runas specification explicitly >> disallows root access as long as the ALL keyword is listed first. > > > can we get carme-ac up? > > > Changing title to carme-ac > ssh: connect to host carme-ac.pld-linux.org port 22: Network is unreachable > === Command terminated with exit status 255 (Thu Oct 17 18:17:57 2019) === Should be up now (until next carme reboot). -- 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/sudo] - up to 1.8.28
On 16/10/2019 14:24, arekm wrote: commit 89b19f0a628b14fd900f10b9a70868a4feba74a5 Author: Arkadiusz Miśkiewicz Date: Wed Oct 16 13:24:09 2019 +0200 - up to 1.8.28 * Fixed CVE-2019-14287, a bug where a sudo user may be able to run a command as root when the Runas specification explicitly disallows root access as long as the ALL keyword is listed first. can we get carme-ac up? Changing title to carme-ac ssh: connect to host carme-ac.pld-linux.org port 22: Network is unreachable === Command terminated with exit status 255 (Thu Oct 17 18:17:57 2019) === ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: multilib on carme-x32
On Wed, 09 Oct 2019, Jakub Bogusz wrote: > Can we have some multilib packages on carme-x32? > At least glibc.x86_64 for now. > > I'd like to try to build rust std library there (there is no hosted > rustc or cargo on this arch, so x86_64 ones must be used). Installed gcc-multilib and glibc-devel. -- 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/systemd] rel 1
On Fri, Oct 11, 2019 at 16:36:00 +0200, Arkadiusz Miśkiewicz wrote: > systemctl preset-all > > Should we call it in %post like docs say? >> >> BTW which docs? > > NEWS: > > * During package installation (with `ninja install`), we would create [...] > done anymore, and instead calling `systemctl preset-all` is > recommended after the first installation of systemd. So this is indeed purely for making system usable after initial install. We might consider this in %post install, however the base units are/were enabled directly in systemd.rpm package (i.e. results of this preset-all are/were already packaged). The open question would be: how should systemd install behave when done on system with other packages (like daemons) already installed (e.g. during migration from SysV)? But the answer is ...irrelevant, since we don't provide any fine-grained preset files, so after such transition admin is free to call preset-all by himself after setting the default policy. >>> So right now we end up with services that are not enabled with this >>> version of systemd that were enabled with earlier version (like getty >>> for tty1 etc). >> > These were enabled by default by just files existence. Now files were > removed (with update to 242; d482e20e65e32e51e9bdfdecb0d1375d9e62c0d1) Oh, this complicates things a bit... As we shouldn't (IMHO) call preset-all ...ever(!), and these files were packaged and put into running systems, they should be simply brought back now. Otherwise we risk breaking running systems, I can't see any other simply way. -- Tomasz Pala ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/librsvg] - updated dependencies; librsvg since 2.42 is partially in rust (what with th-x32?)
On Wed, Jan 30, 2019 at 09:05:10PM +0100, Jan Rękorajski wrote: > On Wed, 30 Jan 2019, Jakub Bogusz wrote: > > > On Wed, Jan 30, 2019 at 08:20:00PM +0100, qboosh wrote: > > > commit fc65f7f1cf360e29b7e44b9835dece9805ad9dbc > > > Author: Jakub Bogusz > > > Date: Wed Jan 30 20:25:13 2019 +0100 > > > > > > - updated dependencies; librsvg since 2.42 is partially in rust (what > > > with th-x32?) > > > > According to rust project site, code generation and std lib is supported > > on x32, but there is no rustc hosted on x32 system - I assume that x86_64 > > rustc must be used... > > 1. librsvg-c for x32? https://lwn.net/Articles/771355/ > 2. get rust functional on x32 (I'm fine with x86_64 runtime and x32 stdlib) > 3. drop x32 possibly? https://lwn.net/Articles/774734/ Followup: eog 3.34 already (optionally) requires rust-based librsvg >= 2.44), so sticking to 2.40.x is no longer an option. -- 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/systemd] rel 1
On 11/10/2019 11:53, Tomasz Pala wrote: > On Fri, Oct 11, 2019 at 09:11:27 +0200, Arkadiusz Miśkiewicz wrote: > systemctl preset-all Should we call it in %post like docs say? > > BTW which docs? NEWS: * During package installation (with `ninja install`), we would create symlinks for getty@tty1.service, systemd-networkd.service, systemd-networkd.socket, systemd-resolved.service, remote-cryptsetup.target, remote-fs.target, systemd-networkd-wait-online.service, and systemd-timesyncd.service in /etc, as if `systemctl enable` was called for those units, to make the system usable immediately after installation. Now this is not done anymore, and instead calling `systemctl preset-all` is recommended after the first installation of systemd. > >>> I think it's too risky since we don't have enough real-life testing. >> >> So right now we end up with services that are not enabled with this >> version of systemd that were enabled with earlier version (like getty >> for tty1 etc). > > Where were they being enabled? I'm not following this package recently, > and can't find any changes in %post*. These were enabled by default by just files existence. Now files were removed (with update to 242; d482e20e65e32e51e9bdfdecb0d1375d9e62c0d1) > >> If not call it on upgrade then at least on initial install. > > Install should call preset indeed - this operation requires attention anyway. > > I remember fixing something around presets: > http://git.pld-linux.org/gitweb.cgi?p=packages/rpm-build-macros.git;a=commitdiff;h=3303369cd82fe4c2d6297d60fec3272066a322c5 > (fixed later in aa13c88c1160df49c87ad3d9586c0bc0b4b3bc5d) > > > ...and I wonder if we could call on upgrade: > > systemctl preset-all --preset-mode=enable-only > > but personally I wouldn't be happy if upgrade enabled services I've > previously disabled[*] - sometimes masking is inappropriate as it prevents > manual service start. > > > We must also remember about such cases: > > http://git.pld-linux.org/gitweb.cgi?p=packages/systemd.git;a=blob;f=systemd.spec;h=67896dfd484b51979edb48046d97d86ab5d0;hb=HEAD#l995 > > - wouldn't this disable everything (not distro-preset"ted" to on) after > "preset-all"? > > Note the "default.preset" filename, i.e. without priority prefix, would > be applied last (which is correct as the first match wins), but we do > not provide preset files: > > $ ipoldek --skip-installed rsearch -f /systemd.\*\.preset$/ > > systemd-units-241-2.x86_64 > zfs-0.8.1-1.x86_64 > > So I guess this would result in disabled ssh as well (yikes!) > > > [*] "If no preset files exist, systemctl preset will enable all units that > are installed by default" > > PS: had no time to add missing directories: > /var/lib/systemd/journal-upload > /var/log/journal/remote > -- 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/systemd] rel 1
On Fri, Oct 11, 2019 at 09:11:27 +0200, Arkadiusz Miśkiewicz wrote: >>> systemctl preset-all >>> >>> Should we call it in %post like docs say? BTW which docs? >> I think it's too risky since we don't have enough real-life testing. > > So right now we end up with services that are not enabled with this > version of systemd that were enabled with earlier version (like getty > for tty1 etc). Where were they being enabled? I'm not following this package recently, and can't find any changes in %post*. > If not call it on upgrade then at least on initial install. Install should call preset indeed - this operation requires attention anyway. I remember fixing something around presets: http://git.pld-linux.org/gitweb.cgi?p=packages/rpm-build-macros.git;a=commitdiff;h=3303369cd82fe4c2d6297d60fec3272066a322c5 (fixed later in aa13c88c1160df49c87ad3d9586c0bc0b4b3bc5d) ...and I wonder if we could call on upgrade: systemctl preset-all --preset-mode=enable-only but personally I wouldn't be happy if upgrade enabled services I've previously disabled[*] - sometimes masking is inappropriate as it prevents manual service start. We must also remember about such cases: http://git.pld-linux.org/gitweb.cgi?p=packages/systemd.git;a=blob;f=systemd.spec;h=67896dfd484b51979edb48046d97d86ab5d0;hb=HEAD#l995 - wouldn't this disable everything (not distro-preset"ted" to on) after "preset-all"? Note the "default.preset" filename, i.e. without priority prefix, would be applied last (which is correct as the first match wins), but we do not provide preset files: $ ipoldek --skip-installed rsearch -f /systemd.\*\.preset$/ systemd-units-241-2.x86_64 zfs-0.8.1-1.x86_64 So I guess this would result in disabled ssh as well (yikes!) [*] "If no preset files exist, systemctl preset will enable all units that are installed by default" PS: had no time to add missing directories: /var/lib/systemd/journal-upload /var/log/journal/remote -- Tomasz Pala ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/systemd] rel 1
On 11/10/2019 08:10, Tomasz Pala wrote: > On Thu, Oct 10, 2019 at 11:34:03 +0200, Arkadiusz Miśkiewicz wrote: > >> What about >> >> systemctl preset-all >> >> Should we call it in %post like docs say? > > I think it's too risky since we don't have enough real-life testing. > So right now we end up with services that are not enabled with this version of systemd that were enabled with earlier version (like getty for tty1 etc). If not call it on upgrade then at least on initial install. -- 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/systemd] rel 1
On Thu, Oct 10, 2019 at 11:34:03 +0200, Arkadiusz Miśkiewicz wrote: > What about > > systemctl preset-all > > Should we call it in %post like docs say? I think it's too risky since we don't have enough real-life testing. -- Tomasz Pala ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: carme-x86_64 readline broken?
On 21/06/2019 13:34, Elan Ruusamäe wrote: could this be resolved please this is still exactly the same, please fix or re-install carme. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/systemd] rel 1
On 09/10/2019 23:28, atler wrote: > commit bd481f0d104c5f88c417cb539c0ab281b925873f > Author: Jan Palus > Date: Wed Oct 9 23:24:40 2019 +0200 > > rel 1 > > systemd.spec | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) What about systemctl preset-all Should we call it in %post like docs say? -- 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: Please always rebuild your updates
On Mon, Oct 07, 2019 at 09:16:55AM +0200, Jan Rękorajski wrote: > Hi, > > There is growing number of packages that have been updated in GIT, but > not built. This is causing unneccessary work when something needs > to be rebuilt due to broken deps (current case icu -> rebuld -> surprise > boost update -> more rebuilding). I'll be going through boost/icu rebuild this week. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: What happened to distfiles?
On 19/09/2019 18:56, Jakub Bogusz wrote: > On Sun, Sep 01, 2019 at 06:34:38PM +0200, Arkadiusz Miśkiewicz wrote: >> On 01/09/2019 17:22, Jakub Bogusz wrote: >>> On Thu, Aug 29, 2019 at 12:50:26PM +0200, Arkadiusz Miśkiewicz wrote: On 28/08/2019 20:56, Jakub Bogusz wrote: > Downloading works, but uploading doesn't: > > - Forwarded message from distfi...@distfiles.pld-linux.org - > > From: > To: qbo...@pld-linux.org > Subject: DISTFILES: glpk: ERRORS: glpk-4.65.tar.gz > X-distfiles-program: file-fetcher.pl > Date: Wed, 28 Aug 2019 16:22:43 +0200 > > scp problems: scp -pr -B -q > ./tmp/6b636521-54cc-4839-bf3e-3ab6408ed2ed/470a984a8b1c0e027bdb6d5859063fe8/ > pldd...@distfiles.pld-linux.org:ftp//by-md5/4/7: > lost connection > > The command has exited with a non-zero status. > > Files fetched: 0 tons of defunct sshds. Try now. >>> >>> It worked for a few days, but now it seems to be broken again... >> >> That's some syslog-ng problem. It seems to be getting stuck and all apps >> writting to /dev/log also hang. >> >> Restarting syslog-ng fixed the problem for now. > > It seems it happened again (on df). Yes and syslog-ng restart "fixed" it. I guess we need to update syslog-ng eventually in git and on df. -- 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: What happened to distfiles?
On Sun, Sep 01, 2019 at 06:34:38PM +0200, Arkadiusz Miśkiewicz wrote: > On 01/09/2019 17:22, Jakub Bogusz wrote: > > On Thu, Aug 29, 2019 at 12:50:26PM +0200, Arkadiusz Miśkiewicz wrote: > >> On 28/08/2019 20:56, Jakub Bogusz wrote: > >>> Downloading works, but uploading doesn't: > >>> > >>> - Forwarded message from distfi...@distfiles.pld-linux.org - > >>> > >>> From: > >>> To: qbo...@pld-linux.org > >>> Subject: DISTFILES: glpk: ERRORS: glpk-4.65.tar.gz > >>> X-distfiles-program: file-fetcher.pl > >>> Date: Wed, 28 Aug 2019 16:22:43 +0200 > >>> > >>> scp problems: scp -pr -B -q > >>> ./tmp/6b636521-54cc-4839-bf3e-3ab6408ed2ed/470a984a8b1c0e027bdb6d5859063fe8/ > >>> pldd...@distfiles.pld-linux.org:ftp//by-md5/4/7: > >>> lost connection > >>> > >>> The command has exited with a non-zero status. > >>> > >>> Files fetched: 0 > >> > >> tons of defunct sshds. Try now. > > > > It worked for a few days, but now it seems to be broken again... > > That's some syslog-ng problem. It seems to be getting stuck and all apps > writting to /dev/log also hang. > > Restarting syslog-ng fixed the problem for now. It seems it happened again (on df). -- 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/systemd] continue using hybrid cgroup hierarchy
On 04.09.2019 08:01, Arkadiusz Miśkiewicz wrote: > On 03/09/2019 23:13, atler wrote: > > commit d43959e98fc5590888c9a43d2345178c34e4f2c4 > > Author: Jan Palus > > Date: Tue Sep 3 23:08:49 2019 +0200 > > > > continue using hybrid cgroup hierarchy > > > > ...for docker compatibility. upstream switched default to unified > > hierarchy exposing core cgroupv2 functionality only > > Shouldn't we go for upstream default and only those who use docekr > should switch via cmdline option ? I do use docker but I don't care much about cgroups so can't really tell what are benefits of keeping "unified" hierarchy. The main point was not to break existing installations. If you believe "unified" hierarchy would be better, please feel free to change. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/systemd] continue using hybrid cgroup hierarchy
On 03/09/2019 23:13, atler wrote:
> commit d43959e98fc5590888c9a43d2345178c34e4f2c4
> Author: Jan Palus
> Date: Tue Sep 3 23:08:49 2019 +0200
>
> continue using hybrid cgroup hierarchy
>
> ...for docker compatibility. upstream switched default to unified
> hierarchy exposing core cgroupv2 functionality only
>
> systemd.spec | 1 +
> 1 file changed, 1 insertion(+)
> ---
> diff --git a/systemd.spec b/systemd.spec
> index 43427dd..4d75ada 100644
> --- a/systemd.spec
> +++ b/systemd.spec
> @@ -677,6 +677,7 @@ cp -p %{SOURCE2} src/systemd_booted.c
> %build
> %meson build \
> -Daudit=%{__true_false audit} \
> + -Ddefault-hierarchy=hybrid \
> -Ddefault-kill-user-processes=false \
> %{?debug:--buildtype=debug} \
> -Defi=%{__true_false efi} \
Shouldn't we go for upstream default and only those who use docekr
should switch via cmdline option ?
--
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: What happened to distfiles?
On 01/09/2019 17:22, Jakub Bogusz wrote: > On Thu, Aug 29, 2019 at 12:50:26PM +0200, Arkadiusz Miśkiewicz wrote: >> On 28/08/2019 20:56, Jakub Bogusz wrote: >>> Downloading works, but uploading doesn't: >>> >>> - Forwarded message from distfi...@distfiles.pld-linux.org - >>> >>> From: >>> To: qbo...@pld-linux.org >>> Subject: DISTFILES: glpk: ERRORS: glpk-4.65.tar.gz >>> X-distfiles-program: file-fetcher.pl >>> Date: Wed, 28 Aug 2019 16:22:43 +0200 >>> >>> scp problems: scp -pr -B -q >>> ./tmp/6b636521-54cc-4839-bf3e-3ab6408ed2ed/470a984a8b1c0e027bdb6d5859063fe8/ >>> pldd...@distfiles.pld-linux.org:ftp//by-md5/4/7: >>> lost connection >>> >>> The command has exited with a non-zero status. >>> >>> Files fetched: 0 >> >> tons of defunct sshds. Try now. > > It worked for a few days, but now it seems to be broken again... That's some syslog-ng problem. It seems to be getting stuck and all apps writting to /dev/log also hang. Restarting syslog-ng fixed the problem for now. (The same problem happened on one of 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: What happened to distfiles?
On Thu, Aug 29, 2019 at 12:50:26PM +0200, Arkadiusz Miśkiewicz wrote: > On 28/08/2019 20:56, Jakub Bogusz wrote: > > Downloading works, but uploading doesn't: > > > > - Forwarded message from distfi...@distfiles.pld-linux.org - > > > > From: > > To: qbo...@pld-linux.org > > Subject: DISTFILES: glpk: ERRORS: glpk-4.65.tar.gz > > X-distfiles-program: file-fetcher.pl > > Date: Wed, 28 Aug 2019 16:22:43 +0200 > > > > scp problems: scp -pr -B -q > > ./tmp/6b636521-54cc-4839-bf3e-3ab6408ed2ed/470a984a8b1c0e027bdb6d5859063fe8/ > > pldd...@distfiles.pld-linux.org:ftp//by-md5/4/7: > > lost connection > > > > The command has exited with a non-zero status. > > > > Files fetched: 0 > > tons of defunct sshds. Try now. It worked for a few days, but now it seems to be broken again... -- 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: What happened to distfiles?
On 28/08/2019 20:56, Jakub Bogusz wrote: > Downloading works, but uploading doesn't: > > - Forwarded message from distfi...@distfiles.pld-linux.org - > > From: > To: qbo...@pld-linux.org > Subject: DISTFILES: glpk: ERRORS: glpk-4.65.tar.gz > X-distfiles-program: file-fetcher.pl > Date: Wed, 28 Aug 2019 16:22:43 +0200 > > scp problems: scp -pr -B -q > ./tmp/6b636521-54cc-4839-bf3e-3ab6408ed2ed/470a984a8b1c0e027bdb6d5859063fe8/ > pldd...@distfiles.pld-linux.org:ftp//by-md5/4/7: > lost connection > > The command has exited with a non-zero status. > > Files fetched: 0 tons of defunct sshds. Try 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: [packages/dyninst] - dropped cfg_to_dot (its from examples subdir) - dropped unstrip and its non-binary *.db files
On 28/08/2019 22:22, hawk wrote: commit e356d518636cfc5a412f3e9a5ad163badc267374 Author: Marcin Krol Date: Wed Aug 28 21:20:09 2019 +0200 - dropped cfg_to_dot (its from examples subdir) - dropped unstrip and its non-binary *.db files you should (also) rm them in %install otherwise (*) someone will see them unpackaged, and add back to %files without even looking at previous commits. * unlikely to happen in real life as only you update the package, but this has happened with more popular packages. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [builder-th-i...@pld-linux.org: ERRORS: COMMAND]
On Tue, Aug 27, 2019 at 5:55 AM Jakub Bogusz wrote: > FHS package is too old on th-i686 (missing "ta" man dir), but it cannot > be simply upgraded. > Could sb do it manually (possibly adding /proc to netsharedpath or so)? > Done. -- 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: No new packages on ftp
On 8/6/19 12:59 PM, Adam Gołębiowski wrote: Looks like we hit -ENOSPC on ftp. th-test indexes (still?) broken ``` poldek:/all-avail> !poldek --up -n th-test Retrieving th-test::packages.ndir.md... Retrieving th-test::packages.ndir.gz... .. 100.0% [248.1K (27.9K/s)] error: ftp://ftp1.pld-linux.org/dists/th/test/i686/RPMS/packages.ndir.gz: broken file Retrieving th-test::packages.ndir.md... Retrieving th-test::packages.ndir.gz... .. 100.0% [431.0K (16.7K/s)] Retrieving th-test::packages.ndir.dscr.gz... .. 100.0% [19.3K (19.3K/s)] poldek:/all-avail> !poldek --up -n th-test error: ftp://ftp1.pld-linux.org/dists/th/test/i686/RPMS/packages.ndir.gz: broken file Retrieving th-test::packages.ndir.md... Retrieving th-test::packages.ndir.gz... .. 100.0% [248.1K (248.1K/s)] error: ftp://ftp1.pld-linux.org/dists/th/test/i686/RPMS/packages.ndir.gz: broken file Retrieving th-test::packages.ndir.md... th-test is up to date poldek:/all-avail> ``` -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: No new packages on ftp
Looks like we hit -ENOSPC on ftp. There's some extra space added now, not sure if pending packages will be synced from builders or will need to be pushed manually . - Original Message - From: "Jan Palus" To: pld-devel-en@lists.pld-linux.org Sent: wtorek, 6 sierpień 2019 0:37:29 Subject: No new packages on ftp Looks like packages built on Aug 4 and later did not reach ftp. 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 ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: upgrade failed ERRORS: python3.spec
On 03/08/2019 21:26, Jakub Bogusz wrote: > ??? > > Build failed on tests, but builder says, that only upgrade failed... > > And what are "foo" RPMs it tried to install? > python3.spec produces different packages. python 3 test suite builds foo*.rpm packages and our pld-builder automatic gets confused by that. We should skip that test but that doesn't seem to be working (%define broken_tests ... test_bdist_rpm) > > > On Sat, Aug 03, 2019 at 06:14:49PM +, PLD th-x86_64 builder wrote: >> python3.spec (auto/th/python3-3.7.4-2): FAILED >> >> --- python3.spec:auto/th/python3-3.7.4-2: >> upgrading packages >> error: open of >> /tmp/B.LdDK2F/BUILD/tmp/tmpcyf9boma/foo/build/bdist.linux-x86_64/rpm/RPMS/foo-0.1-1.noarch.rpm >> failed: No such file or directory >> package upgrade failed >> Build-Time: user:5378.04s sys:169.65s real:5102.93s (faults io:0 >> non-io:28072151) >> >> Files queued for ftp: >> 0 foo-0.1-1.noarch.rpm >> 0 foo-0.1-1.src.rpm >> 98 python3-3.7.4-2.src.rpm.uploadinfo > [...] >> Total duration: 2 min 41 sec >> Tests result: FAILURE then FAILURE >> make: *** [Makefile:1078: test] Error 2 >> error: Bad exit status from /tmp/B.LdDK2F/BUILD/tmp/rpm-tmp.77271 (%build) >> >> >> RPM build errors: >> Bad exit status from /tmp/B.LdDK2F/BUILD/tmp/rpm-tmp.77271 (%build) >> ended at: Sat Aug 3 20:14:48 2019, done in 1:24:51.824189 >> + chmod -R u+rwX /tmp/B.LdDK2F/BUILD >> + rm -rf /tmp/B.LdDK2F/tmp /tmp/B.LdDK2F/BUILD >> copy rpm files to cache_dir: /spools/ready >> cp: cannot stat >> '/tmp/B.LdDK2F/BUILD/tmp/tmpcyf9boma/foo/build/bdist.linux-x86_64/rpm/RPMS/foo-0.1-1.noarch.rpm': >> No such file or directory >> cp: cannot stat >> '/tmp/B.LdDK2F/BUILD/tmp/tmpcyf9boma/foo/build/bdist.linux-x86_64/rpm/SRPMS/foo-0.1-1.src.rpm': >> No such file or directory >> Begin-PLD-Builder-Info >> upgrading packages >> error: open of >> /tmp/B.LdDK2F/BUILD/tmp/tmpcyf9boma/foo/build/bdist.linux-x86_64/rpm/RPMS/foo-0.1-1.noarch.rpm >> failed: No such file or directory >> package upgrade failed >> End-PLD-Builder-Info >> + rm -rf /tmp/B.LdDK2F >> Begin-PLD-Builder-Info >> Build-Time: user:5378.04s sys:169.65s real:5102.93s (faults io:0 >> non-io:28072151) >> >> Files queued for ftp: >> 0 foo-0.1-1.noarch.rpm >> 0 foo-0.1-1.src.rpm >> 98 python3-3.7.4-2.src.rpm.uploadinfo >> >> End-PLD-Builder-Info >> > -- 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: upgrade failed ERRORS: python3.spec
??? Build failed on tests, but builder says, that only upgrade failed... And what are "foo" RPMs it tried to install? python3.spec produces different packages. On Sat, Aug 03, 2019 at 06:14:49PM +, PLD th-x86_64 builder wrote: > python3.spec (auto/th/python3-3.7.4-2): FAILED > > --- python3.spec:auto/th/python3-3.7.4-2: > upgrading packages > error: open of > /tmp/B.LdDK2F/BUILD/tmp/tmpcyf9boma/foo/build/bdist.linux-x86_64/rpm/RPMS/foo-0.1-1.noarch.rpm > failed: No such file or directory > package upgrade failed > Build-Time: user:5378.04s sys:169.65s real:5102.93s (faults io:0 > non-io:28072151) > > Files queued for ftp: > 0 foo-0.1-1.noarch.rpm > 0 foo-0.1-1.src.rpm > 98 python3-3.7.4-2.src.rpm.uploadinfo [...] > Total duration: 2 min 41 sec > Tests result: FAILURE then FAILURE > make: *** [Makefile:1078: test] Error 2 > error: Bad exit status from /tmp/B.LdDK2F/BUILD/tmp/rpm-tmp.77271 (%build) > > > RPM build errors: > Bad exit status from /tmp/B.LdDK2F/BUILD/tmp/rpm-tmp.77271 (%build) > ended at: Sat Aug 3 20:14:48 2019, done in 1:24:51.824189 > + chmod -R u+rwX /tmp/B.LdDK2F/BUILD > + rm -rf /tmp/B.LdDK2F/tmp /tmp/B.LdDK2F/BUILD > copy rpm files to cache_dir: /spools/ready > cp: cannot stat > '/tmp/B.LdDK2F/BUILD/tmp/tmpcyf9boma/foo/build/bdist.linux-x86_64/rpm/RPMS/foo-0.1-1.noarch.rpm': > No such file or directory > cp: cannot stat > '/tmp/B.LdDK2F/BUILD/tmp/tmpcyf9boma/foo/build/bdist.linux-x86_64/rpm/SRPMS/foo-0.1-1.src.rpm': > No such file or directory > Begin-PLD-Builder-Info > upgrading packages > error: open of > /tmp/B.LdDK2F/BUILD/tmp/tmpcyf9boma/foo/build/bdist.linux-x86_64/rpm/RPMS/foo-0.1-1.noarch.rpm > failed: No such file or directory > package upgrade failed > End-PLD-Builder-Info > + rm -rf /tmp/B.LdDK2F > Begin-PLD-Builder-Info > Build-Time: user:5378.04s sys:169.65s real:5102.93s (faults io:0 > non-io:28072151) > > Files queued for ftp: > 0 foo-0.1-1.noarch.rpm > 0 foo-0.1-1.src.rpm > 98 python3-3.7.4-2.src.rpm.uploadinfo > > End-PLD-Builder-Info > -- 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: kf5-ktexteditor.spec
On 25.07.2019 19:57, PLD th-i686 builder wrote: > -DQT_NO_DEBUG -Wl,--no-undefined -Wl,--fatal-warnings ... > /usr/bin/ld: warning: /lib/ld-linux.so.2: corrupt GNU_PROPERTY_TYPE (5) size: > 0 > collect2: error: ld returned 1 exit status any idea why /lib/ld-linux.so.2 appears to be broken on i686? $ readelf -n /lib/ld-linux.so.2 Displaying notes found in: .note.gnu.build-id Owner Data size Description GNU 0x0014 NT_GNU_BUILD_ID (unique build ID bitstring) Build ID: 99315096abbe23e4eac6ea4ac07fc9f5c86e2fe7 Displaying notes found in: .note.gnu.property Owner Data size Description GNU 0x NT_GNU_PROPERTY_TYPE_0 Properties: ^ on x86_64 it appears to be fine: $ readelf -n /lib64/ld-linux-x86-64.so.2 Displaying notes found in: .note.gnu.property Owner Data size Description GNU 0x0010 NT_GNU_PROPERTY_TYPE_0 Properties: x86 feature: IBT, SHSTK Displaying notes found in: .note.gnu.build-id Owner Data size Description GNU 0x0014 NT_GNU_BUILD_ID (unique build ID bitstring) Build ID: ee43aed962e9e79b6d6831ad5f68d1ee5bb64f3b ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ftp down
On 5/6/19 7:06 PM, Jan Rękorajski wrote: On Sun, 05 May 2019, Elan Ruusamäe wrote: the ftp is still unusable for poldek after exactly two months have passed. please make default poldek config to use http:// (or https://) if unable to support ftp:// Fix your /etc/resolv.conf and /etc/localtime. And no, I don't know why it breaks with incorrect or missing /etc/localtime. updated docker image build result to use http urls then: - https://gitlab.com/pld-linux/pld/merge_requests/5 -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: git push: No space left on device
Happened again: Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 4 threads Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 316 bytes | 316.00 KiB/s, done. Total 3 (delta 1), reused 0 (delta 0) remote: fatal: write failure on standard output: No space left on device remote: error: unable to write file sip.spec remote: Updated 1 path from 822c76c remote: Emitting a message to the fedmsg bus. remote: * Publishing information for 1 commits remote: exim: insufficient disk space remote: Error in hook hooks/post-receive.python.d/slug_hook.py remote: [Errno 28] No space left on device ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: carme-x86_64 readline broken?
On 20/06/2019 00:27, Arkadiusz Miśkiewicz wrote: On 19/06/2019 22:48, Elan Ruusamäe wrote: seems all operations that require some kind of interactivity are broken on carme. random examples: 1. coreutils prompts fail to prompt with bogus error closing file message carme has git version of readline-devel, so there can be mixed libraries linked (indirectly) with both readline versions. That could be the cause. ee, no? package installed year ago, and does not seem it's installed manually either ``` [~/rpm/packages/Firebird(3.0.4.33054) (master)↑★] ➔ pkgbytime readline Fri Jul 27 08:35:36 2018 readline-7.0.5-1.x86_64 Fri Jul 27 08:35:36 2018 readline-devel-7.0.5-1.x86_64 Fri Jul 27 08:35:36 2018 readline-static-7.0.5-1.x86_64 [~/rpm/packages/Firebird(3.0.4.33054) (master)↑★] ➔ rpm -V readline readline-devel [~/rpm/packages/Firebird(3.0.4.33054) (master)↑★] ➔ ``` could this be resolved please ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: carme-x86_64 readline broken?
On 19/06/2019 22:48, Elan Ruusamäe wrote:
> seems all operations that require some kind of interactivity are broken
> on carme.
>
>
> random examples:
>
> 1. coreutils prompts fail to prompt with bogus error closing file message
carme has git version of readline-devel, so there can be mixed libraries
linked (indirectly) with both readline versions.
That could be the cause.
>
> 2. nvim segfaults
>
> 3. git interactive stage fails to prompt (returns to shell)
>
>
> ```
> [~/rpm/packages/php(7.4.0) (dev-7.4)↑★] ➔ rm -i /dev/null
> rm: remove character special file '/dev/null'? rm: error closing file
> [~/rpm/packages/php(7.4.0) (dev-7.4)↑★] ➔ nvim
> Segmentation fault
> [~/rpm/packages/php(7.4.0) (dev-7.4)↑★] ➔
> [~/rpm/packages/php(7.4.0) (dev-7.4)↑★] ➔ git add -p
> diff --git a/php.spec b/php.spec
> index 2b4de4f..1b8f04d 100644
> --- a/php.spec
> +++ b/php.spec
> @@ -164,7 +164,7 @@ Summary(ru.UTF-8): PHP Версии 7 - язык препроцессирова
> Summary(uk.UTF-8): PHP Версії 7 - мова препроцесування HTML-файлів,
> виконувана на сервері
> Name: %{orgname}%{php_suffix}
> Version: 7.4.0
> -Release: 0.1
> +Release: 0.2
> Epoch: 4
> # All files licensed under PHP version 3.01, except
> # Zend is licensed under Zend
> Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]?
> [~/rpm/packages/php(7.4.0) (dev-7.4)↑★] ➔
>
> ```
>
> ___
> pld-devel-en mailing list
> pld-devel-en@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
--
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/binutils] - updated info patch (its purpose is to align info directory, ie. default info/pinfo page)
On 19/06/2019 10:22, qboosh wrote: commit f81d24890fc099cfa33b9951c6d77b0a6fb14c23 Author: Jakub Bogusz Date: Wed Jun 19 09:23:47 2019 +0200 - updated info patch (its purpose is to align info directory, ie. default info/pinfo page) not that i care of this patch, but this explanation gives nothing: 1. why the patch is needed 2. why it's never submitted upstream ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/firefox] - bump libicu-devel to 63.1; builds fine with nodejs 10 even with no read access to resolv.conf
On 03/06/2019 20:58, Jan Rękorajski wrote:
> On Mon, 03 Jun 2019, arekm wrote:
>
>> commit 28dc894f0a27bdc080bbfc821d2841760a70927b
>> Author: Arkadiusz Miśkiewicz
>> Date: Mon Jun 3 15:09:13 2019 +0200
>>
>> - bump libicu-devel to 63.1; builds fine with nodejs 10 even with no
>> read access to resolv.conf
>>
>> firefox.spec | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> ---
>> diff --git a/firefox.spec b/firefox.spec
>> index de14e08..c60c946 100644
>> --- a/firefox.spec
>> +++ b/firefox.spec
>> @@ -293,7 +293,7 @@ BuildRequires: libatomic-devel
>> BuildRequires: libevent-devel >= 1.4.7
>> # standalone libffi 3.0.9 or gcc's from 4.5(?)+
>> BuildRequires: libffi-devel >= 6:3.0.9
>> -%{?with_system_icu:BuildRequires: libicu-devel >= 59.1}
>> +%{?with_system_icu:BuildRequires: libicu-devel >= 63.1}
>> # requires libjpeg-turbo implementing at least libjpeg 6b API
>> BuildRequires: libjpeg-devel >= 6b
>> BuildRequires: libjpeg-turbo-devel
>>
>
> No, it does not:
>
> http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=firefox&id=05da2df8-250e-48ea-b5a4-93a6dbdf387f&action=tail
>
builders don't have nodejs 10, it's only in our git (and in .test-builds)
--
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/firefox] - bump libicu-devel to 63.1; builds fine with nodejs 10 even with no read access to resolv.conf
On Mon, 03 Jun 2019, arekm wrote:
> commit 28dc894f0a27bdc080bbfc821d2841760a70927b
> Author: Arkadiusz Miśkiewicz
> Date: Mon Jun 3 15:09:13 2019 +0200
>
> - bump libicu-devel to 63.1; builds fine with nodejs 10 even with no read
> access to resolv.conf
>
> firefox.spec | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> ---
> diff --git a/firefox.spec b/firefox.spec
> index de14e08..c60c946 100644
> --- a/firefox.spec
> +++ b/firefox.spec
> @@ -293,7 +293,7 @@ BuildRequires:libatomic-devel
> BuildRequires: libevent-devel >= 1.4.7
> # standalone libffi 3.0.9 or gcc's from 4.5(?)+
> BuildRequires: libffi-devel >= 6:3.0.9
> -%{?with_system_icu:BuildRequires:libicu-devel >= 59.1}
> +%{?with_system_icu:BuildRequires:libicu-devel >= 63.1}
> # requires libjpeg-turbo implementing at least libjpeg 6b API
> BuildRequires: libjpeg-devel >= 6b
> BuildRequires: libjpeg-turbo-devel
>
No, it does not:
http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=firefox&id=05da2df8-250e-48ea-b5a4-93a6dbdf387f&action=tail
--
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: firefox and builders...
On Mon, Jun 03, 2019 at 08:19:42AM +0200, Jacek Konieczny wrote: > On 03/06/2019 07.25, Jan Rękorajski wrote> > > I don't believe it's nodejs problem, I think it's builder > > security/networking problem. > But the security/networking restrictions are there for a reason. If we > allow build process to download anything it wants, then we could skip > shipping source packages at all. It's about reproducibility as well. > Yes it sucks in today's world, especially when trying to build something > like Node or Java crap. Proper source packages are harder and harder to > find, even for C code (e.g. when code is available only on github and > includes submodules)… We tend to fix tags at least, submodules is a major hassle indeed... > Maybe we should rethink our policy…, but just removing the restrictions > because one package stopped to build doesn't seem a right way to do it. ALT is building its repos without network access, maybe some patches or approaches will be reuseful to you too. In particular, fx67 has just landed: https://packages.altlinux.org/en/sisyphus/srpms/firefox I'm not into nodejs but it's sort of there too: https://packages.altlinux.org/en/sisyphus/srpms/node https://packages.altlinux.org/en/search?query=nodejs -- WBR, Michael Shigorin / http://altlinux.org -- http://opennet.ru / http://anna-news.info ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: firefox and builders...
That nodejs in firefox is not downloading anything AFAIK, it's just convoluted build process that needs nodejs started and it cannot start without dns :/ I don't remember how we run builds, but maybe if we point resolv.conf at 127.0.0.1 it will be enough for it. On Mon, Jun 3, 2019 at 8:19 AM Jacek Konieczny wrote: > On 03/06/2019 07.25, Jan Rękorajski wrote> > > I don't believe it's nodejs problem, I think it's builder > > security/networking problem. > But the security/networking restrictions are there for a reason. If we > allow build process to download anything it wants, then we could skip > shipping source packages at all. > > Yes it sucks in today's world, especially when trying to build something > like Node or Java crap. Proper source packages are harder and harder to > find, even for C code (e.g. when code is available only on github and > includes submodules)… > > Maybe we should rethink our policy…, but just removing the restrictions > because one package stopped to build doesn't seem a right way to do it. > > Jacek > ___ > 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 | 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: firefox and builders...
On 03/06/2019 07.25, Jan Rękorajski wrote> > I don't believe it's nodejs problem, I think it's builder > security/networking problem. But the security/networking restrictions are there for a reason. If we allow build process to download anything it wants, then we could skip shipping source packages at all. Yes it sucks in today's world, especially when trying to build something like Node or Java crap. Proper source packages are harder and harder to find, even for C code (e.g. when code is available only on github and includes submodules)… Maybe we should rethink our policy…, but just removing the restrictions because one package stopped to build doesn't seem a right way to do it. Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: firefox and builders...
On Sun, 02 Jun 2019, Elan Ruusamäe wrote: > On 02/06/2019 23:13, Jan Rękorajski wrote: > > > After long trial and error process I managed to get firefox to build, > > unfortunately our automation is overprotective and the build doesn't > > work on builders - I can run it manually on builders, but not in > > automatated way. > > > > Until someone finds out why nodejs doesn't start during firefox build > > process I'm going to remove the package from th. > > maybe update node to next lts (node 10): > > - https://github.com/nodejs/Release > I don't believe it's nodejs problem, I think it's builder security/networking problem. I can build firefox at home, I can build it on builder if I log in there and run it by hand. But when I send a request this happens: 4:16.50 Executing "/usr/bin/nodejs /tmp/B.5vhgKn/BUILD/firefox-67.0/devtools/client/shared/build/build.js /tmp/B.5vhgKn/BUILD/firefox-67.0/devtools/client/debugger/new/src/main.development.js /tmp/B.5vhgKn/BUILD/firefox-67.0/devtools/client/debugger/new/src/main.js /tmp/B.5vhgKn/BUILD/firefox-67.0/devtools/client/debugger/new/src/vendors.js" 4:16.57 dns.js:221 4:16.57 this._handle = new ChannelWrap(); 4:16.57^ 4:16.57 Error: EFILE http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=firefox&id=afcecd08-58e5-4b54-9bdc-4b4ed6574182&action=tail -- 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: firefox and builders...
On 02/06/2019 23:13, Jan Rękorajski wrote: After long trial and error process I managed to get firefox to build, unfortunately our automation is overprotective and the build doesn't work on builders - I can run it manually on builders, but not in automatated way. Until someone finds out why nodejs doesn't start during firefox build process I'm going to remove the package from th. maybe update node to next lts (node 10): - https://github.com/nodejs/Release ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: git push: No space left on device
nuked pldnotify tmp files: ``` root@1822-cvs ~# df Filesystem Type Size Used Avail Use% Mounted on /dev/sda3 ext3 16G 14G 686M 96% / root@1822-cvs /tmp# l total 1022M -rw--- 1 arekm cvsadm 8.2M Jun 2 00:37 3sUCfg -rw--- 1 arekm cvsadm 8.2M May 22 11:37 3yngEZ ... -rw--- 1 arekm cvsadm 42M May 27 14:03 LC09qj -rw--- 1 arekm cvsadm 42M May 30 08:27 rTG3Ny -rw--- 1 arekm cvsadm 42M Jun 2 02:39 9fFusL root@1822-cvs /tmp# ls 3sUCfg 7aisYm AOgDej CjoYBs egzPBi GVVgYV IMdYCY ky6SZM MJyqun pkwwYX rTG3Ny tkKQTz TxCKfd vNKbVx xgrXUW ZmX3wX 3yngEZ 9fFusL bKLMXg ckcKZR EtVuKX H0wUjP kqyavX LC09qj nQaRqB q72abZ s8IY3M tmux-35000/ ugz5GH W64ejM XQ6rPW ZQNqbE 4VHvgg ACfosT BuCxRS cRVWBO fhOWil h6wHPL KsfiDO lNOI6y o07mvf qhiWzM ssh-QpoL8zO4Iw/ tNamQj US5wV06C3e XCwOX6 yHKpFZ zXfBXz 6ZGCBe AgrapI bUpvI4 DjRrgV GtyfHwtvvV HLv5DW kuD1Hb lVWGWS p2b6GH QnZwka sYw019 TNWyoP vbufmU XG2nxD Z29c7L root@1822-cvs /tmp# rm -vf ?? removed '3sUCfg' removed '3yngEZ' removed '4VHvgg' ... root@1822-cvs /tmp# df / Filesystem Type Size Used Avail Use% Mounted on /dev/sda3 ext3 16G 13G 1.7G 89% / ``` On 02/06/2019 14:48, Elan Ruusamäe wrote: and already down by 700mb. something is continuing to eat space ``` root@1822-cvs repositories/SPECS.git# df / Filesystem Type Size Used Avail Use% Mounted on /dev/sda3 ext3 16G 14G 687M 96% / ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: git push: No space left on device
On 31/05/2019 12:28, Arkadiusz Miśkiewicz wrote: Deleted few things - now it's 1.4GB free. and already down by 700mb. something is continuing to eat space ``` root@1822-cvs repositories/SPECS.git# df / Filesystem Type Size Used Avail Use% Mounted on /dev/sda3 ext3 16G 14G 687M 96% / ``` imho /var, /var/log should be on separate partition: ``` root@1822-cvs repositories/SPECS.git# df /var /var/log Filesystem Type Size Used Avail Use% Mounted on /dev/sda3 ext3 16G 14G 686M 96% / /dev/sda3 ext3 16G 14G 686M 96% / ``` ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: git push: No space left on device
On 31/05/2019 11:03, Jacek Konieczny wrote: > Hi, > > Our repository seems to be misbehaving: > > remote: fatal: write failure on standard output: No space left on device > remote: error: unable to write file GxPlugins.lv2.spec > remote: Emitting a message to the fedmsg bus. > remote: * Publishing information for 1 commits > remote: exim: insufficient disk space > remote: Error in hook hooks/post-receive.python.d/slug_hook.py > remote: [Errno 28] No space left on device > > Jacek > ___ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > /dev/sda3 ext3 16G 15G 0 100% / # du -sh /var/lib/docker/ 7.5G/var/lib/docker/ no clue whats is this docker for there. Deleted few things - now it's 1.4GB free. -- 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/Vulkan-Loader] new package
On 24/05/2019 00.21, Elan Ruusamäe wrote: > > On 23/05/2019 21:13, jajcus wrote: >> +BuildRequires: python3 >= 3 > > python3 was unfortunately started with epoch: 1, copy paste from > python.spec > > otoh, if as you don't have more specific version here, just drop the > version construct? I have just copied this BT from the package I based on. I'll add the Epoch. Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/Vulkan-Loader] new package
On Fri, May 24, 2019 at 01:21:38AM +0300, Elan Ruusamäe wrote: > > On 23/05/2019 21:13, jajcus wrote: > >+BuildRequires: python3 >= 3 > > python3 was unfortunately started with epoch: 1, copy paste from python.spec > > otoh, if as you don't have more specific version here, just drop the > version construct? I prefer to specify version - in case given package gets renamed some day. -- 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/Vulkan-Loader] new package
On 23/05/2019 21:13, jajcus wrote: +BuildRequires: python3 >= 3 python3 was unfortunately started with epoch: 1, copy paste from python.spec otoh, if as you don't have more specific version here, just drop the version construct? ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/ka5-ark] - don't require programs for build, those are used only at runtime
On 16/05/2019 08:22, baggins wrote:
commit 80789b35d14e465bd1338d2a2e1bb4428fe61911
Author: Jan Rękorajski
Date: Thu May 16 07:22:03 2019 +0200
- don't require programs for build, those are used only at runtime
...
+--- ark-19.04.1/plugins/clirarplugin/CMakeLists.txt~ 2019-05-05
12:43:24.0 +0200
ark-19.04.1/plugins/clirarplugin/CMakeLists.txt2019-05-16
07:18:19.440090472 +0200
+@@ -24,17 +24,3 @@
+
+ set(SUPPORTED_ARK_MIMETYPES
"${SUPPORTED_ARK_MIMETYPES}${SUPPORTED_CLIRAR_MIMETYPES}" PARENT_SCOPE)
+ set(INSTALLED_KERFUFFLE_PLUGINS
"${INSTALLED_KERFUFFLE_PLUGINS}kerfuffle_clirar;" PARENT_SCOPE)
+-
+-find_program(UNRAR unrar)
+-if(UNRAR)
+-message(STATUS "Found unrar executable: ${UNRAR}")
+-else()
+-message(WARNING "Could not find the unrar executable. Ark requires unrar or
unar to extract RAR archives.")
+-endif()
i think you can do this with cmake commandline args:
-DUNRAR=/usr/bin/unrar
your approach may even be breaking if the code uses the $UNRAR variable
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
