From baggins at pld-linux.org Sat Jul 1 11:51:46 2017 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sat, 1 Jul 2017 11:51:46 +0200 Subject: dnssec-tools package broken by glibc Message-ID: <20170701095146.GA18148@home> dnssec-tools does not build because the code it relies on was removed from glibc. Until someone steps up and fixes it, I will remove dnssec-tools from Th. -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From qboosh at pld-linux.org Sat Jul 1 19:33:14 2017 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 1 Jul 2017 19:33:14 +0200 Subject: dnssec-tools package broken by glibc In-Reply-To: <20170701095146.GA18148@home> References: <20170701095146.GA18148@home> Message-ID: <20170701173314.GA561@mail> On Sat, Jul 01, 2017 at 11:51:46AM +0200, Jan R?korajski wrote: > dnssec-tools does not build because the code it relies on was removed > from glibc. Build fixed, thanks to Arch Linux. -- Jakub Bogusz http://qboosh.pl/ From baggins at pld-linux.org Mon Jul 3 08:07:09 2017 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Mon, 3 Jul 2017 08:07:09 +0200 Subject: [packages/rust] rpm4 noarch In-Reply-To: References:

Message-ID: <20170703060703.GB18148@home> Why do you keep adding that cruft? Please stop doing this. We don't use rpm4 for 5 (five) years. On Sun, 02 Jul 2017, glen wrote: > commit b19b9d5139395caf6414506d1baa84d8bc1b69e6 > Author: Elan Ruusam?e > Date: Sun Jul 2 23:46:57 2017 +0300 > > rpm4 noarch > > rust.spec | 8 ++++++++ > 1 file changed, 8 insertions(+) > --- > diff --git a/rust.spec b/rust.spec > index 7e7d09a..91be41a 100644 > --- a/rust.spec > +++ b/rust.spec > @@ -95,7 +95,9 @@ documentation generator. > %package debugger-common > Summary: Common debugger pretty printers for Rust > Group: Development/Debuggers > +%if "%{_rpmversion}" >= "5" > BuildArch: noarch > +%endif > > %description debugger-common > This package includes the common functionality for %{name}-gdb and > @@ -106,7 +108,9 @@ Summary: GDB pretty printers for Rust > Group: Development/Debuggers > Requires: %{name}-debugger-common = %{version}-%{release} > Requires: gdb > +%if "%{_rpmversion}" >= "5" > BuildArch: noarch > +%endif > > %description gdb > This package includes the rust-gdb script, which allows easier > @@ -117,7 +121,9 @@ Summary: LLDB pretty printers for Rust > Group: Development/Debuggers > Requires: %{name}-debugger-common = %{version}-%{release} > Requires: lldb > +%if "%{_rpmversion}" >= "5" > BuildArch: noarch > +%endif > > %description lldb > This package includes the rust-lldb script, which allows easier > @@ -126,7 +132,9 @@ debugging of Rust programs. > %package doc > Summary: Documentation for Rust > Group: Documentation > +%if "%{_rpmversion}" >= "5" > BuildArch: noarch > +%endif > > %description doc > This package includes HTML documentation for the Rust programming > ================================================================ > > ---- gitweb: > > http://git.pld-linux.org/gitweb.cgi/packages/rust.git/commitdiff/b19b9d5139395caf6414506d1baa84d8bc1b69e6 > > _______________________________________________ > pld-cvs-commit mailing list > pld-cvs-commit at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From n3npq at me.com Mon Jul 3 08:14:02 2017 From: n3npq at me.com (Jeffrey Johnson) Date: Mon, 03 Jul 2017 02:14:02 -0400 Subject: [packages/rust] rpm4 noarch In-Reply-To: <20170703060703.GB18148@home> References:

<20170703060703.GB18148@home> Message-ID: <03D37F21-1E9A-4CCC-97F7-D97C550DDF36@me.com> > On Jul 3, 2017, at 2:07 AM, Jan R?korajski wrote: > > Why do you keep adding that cruft? Please stop doing this. > We don't use rpm4 for 5 (five) years. > Hmmm ? there?s the other incompatibility side as well Why isn?t BuildArch needed for RPM4? I can remove (or at least make optional) the need for "BuildArch: noarch" in RPM5 if necessary. (aside) The BuildArch: directive forces rpm build to abort the current build, discard/reread entire configuration, and restart build parsing. SO its one if the crazier pieces of code in RPM, always has been. But if rpm.org has removed the beed for BuildArch: no arch, I?m sure I can do the same in RPM5. 73 de Jeff > On Sun, 02 Jul 2017, glen wrote: > >> commit b19b9d5139395caf6414506d1baa84d8bc1b69e6 >> Author: Elan Ruusam?e >> Date: Sun Jul 2 23:46:57 2017 +0300 >> >> rpm4 noarch >> >> rust.spec | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> --- >> diff --git a/rust.spec b/rust.spec >> index 7e7d09a..91be41a 100644 >> --- a/rust.spec >> +++ b/rust.spec >> @@ -95,7 +95,9 @@ documentation generator. >> %package debugger-common >> Summary: Common debugger pretty printers for Rust >> Group: Development/Debuggers >> +%if "%{_rpmversion}" >= "5" >> BuildArch: noarch >> +%endif >> >> %description debugger-common >> This package includes the common functionality for %{name}-gdb and >> @@ -106,7 +108,9 @@ Summary: GDB pretty printers for Rust >> Group: Development/Debuggers >> Requires: %{name}-debugger-common = %{version}-%{release} >> Requires: gdb >> +%if "%{_rpmversion}" >= "5" >> BuildArch: noarch >> +%endif >> >> %description gdb >> This package includes the rust-gdb script, which allows easier >> @@ -117,7 +121,9 @@ Summary: LLDB pretty printers for Rust >> Group: Development/Debuggers >> Requires: %{name}-debugger-common = %{version}-%{release} >> Requires: lldb >> +%if "%{_rpmversion}" >= "5" >> BuildArch: noarch >> +%endif >> >> %description lldb >> This package includes the rust-lldb script, which allows easier >> @@ -126,7 +132,9 @@ debugging of Rust programs. >> %package doc >> Summary: Documentation for Rust >> Group: Documentation >> +%if "%{_rpmversion}" >= "5" >> BuildArch: noarch >> +%endif >> >> %description doc >> This package includes HTML documentation for the Rust programming >> ================================================================ >> >> ---- gitweb: >> >> http://git.pld-linux.org/gitweb.cgi/packages/rust.git/commitdiff/b19b9d5139395caf6414506d1baa84d8bc1b69e6 >> >> _______________________________________________ >> pld-cvs-commit mailing list >> pld-cvs-commit at lists.pld-linux.org >> http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit > > -- > Jan R?korajski | PLD/Linux > SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From baggins at pld-linux.org Mon Jul 3 08:18:50 2017 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Mon, 3 Jul 2017 08:18:50 +0200 Subject: [packages/rust] rpm4 noarch In-Reply-To: <03D37F21-1E9A-4CCC-97F7-D97C550DDF36@me.com> References:

<20170703060703.GB18148@home> <03D37F21-1E9A-4CCC-97F7-D97C550DDF36@me.com> Message-ID: <20170703061850.GC18148@home> On Mon, 03 Jul 2017, Jeffrey Johnson wrote: > > > On Jul 3, 2017, at 2:07 AM, Jan R?korajski wrote: > > > > Why do you keep adding that cruft? Please stop doing this. > > We don't use rpm4 for 5 (five) years. > > > > Hmmm ? there?s the other incompatibility side as well > > Why isn?t BuildArch needed for RPM4? > > I can remove (or at least make optional) the need for "BuildArch: noarch" in RPM5 if necessary. > > (aside) > The BuildArch: directive forces rpm build to abort the current build, discard/reread entire configuration, > and restart build parsing. SO its one if the crazier pieces of code in RPM, always has been. > > But if rpm.org has removed the beed for BuildArch: no arch, I?m sure I can do the same in RPM5. You don't need to remove anything. This directive here is for antiquated rpm4 that did not support BuildArch in subpackages. I want those %if's gone. > > 73 de Jeff > > > On Sun, 02 Jul 2017, glen wrote: > > > >> commit b19b9d5139395caf6414506d1baa84d8bc1b69e6 > >> Author: Elan Ruusam?e > >> Date: Sun Jul 2 23:46:57 2017 +0300 > >> > >> rpm4 noarch > >> > >> rust.spec | 8 ++++++++ > >> 1 file changed, 8 insertions(+) > >> --- > >> diff --git a/rust.spec b/rust.spec > >> index 7e7d09a..91be41a 100644 > >> --- a/rust.spec > >> +++ b/rust.spec > >> @@ -95,7 +95,9 @@ documentation generator. > >> %package debugger-common > >> Summary: Common debugger pretty printers for Rust > >> Group: Development/Debuggers > >> +%if "%{_rpmversion}" >= "5" > >> BuildArch: noarch > >> +%endif > >> > >> %description debugger-common > >> This package includes the common functionality for %{name}-gdb and > >> @@ -106,7 +108,9 @@ Summary: GDB pretty printers for Rust > >> Group: Development/Debuggers > >> Requires: %{name}-debugger-common = %{version}-%{release} > >> Requires: gdb > >> +%if "%{_rpmversion}" >= "5" > >> BuildArch: noarch > >> +%endif > >> > >> %description gdb > >> This package includes the rust-gdb script, which allows easier > >> @@ -117,7 +121,9 @@ Summary: LLDB pretty printers for Rust > >> Group: Development/Debuggers > >> Requires: %{name}-debugger-common = %{version}-%{release} > >> Requires: lldb > >> +%if "%{_rpmversion}" >= "5" > >> BuildArch: noarch > >> +%endif > >> > >> %description lldb > >> This package includes the rust-lldb script, which allows easier > >> @@ -126,7 +132,9 @@ debugging of Rust programs. > >> %package doc > >> Summary: Documentation for Rust > >> Group: Documentation > >> +%if "%{_rpmversion}" >= "5" > >> BuildArch: noarch > >> +%endif > >> > >> %description doc > >> This package includes HTML documentation for the Rust programming > >> ================================================================ > >> > >> ---- gitweb: > >> > >> http://git.pld-linux.org/gitweb.cgi/packages/rust.git/commitdiff/b19b9d5139395caf6414506d1baa84d8bc1b69e6 > >> > >> _______________________________________________ > >> pld-cvs-commit mailing list > >> pld-cvs-commit at lists.pld-linux.org > >> http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit > > > > -- > > Jan R?korajski | PLD/Linux > > SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ > > _______________________________________________ > > pld-devel-en mailing list > > pld-devel-en at lists.pld-linux.org > > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From n3npq at me.com Mon Jul 3 08:24:48 2017 From: n3npq at me.com (Jeffrey Johnson) Date: Mon, 03 Jul 2017 02:24:48 -0400 Subject: [packages/rust] rpm4 noarch In-Reply-To: <20170703061850.GC18148@home> References:

<20170703060703.GB18148@home> <03D37F21-1E9A-4CCC-97F7-D97C550DDF36@me.com> <20170703061850.GC18148@home> Message-ID: <3E5BF9E4-2471-4E97-ACCC-22F9F337E91B@me.com> > > You don't need to remove anything. > This directive here is for antiquated rpm4 that did not support > BuildArch in subpackages. I want those %if's gone. > Ah yes, thanks. I?ve forgotten ... Yes: recent (like last 8y? I forget) rpm.org also supports noarch sub-packages, so there?s no need unless building with rpm-4.5 from way back when. Meanwhile BuildArch: noarch is one of the crazier pieces of code in rpmbuild. Someday ts gonna break and cause some effort to repair the rpmbuild parser. There?s easier ways to reset stageful read?s then restarting the build ? WORKSFORME. 73 de Jeff From jajcus at jajcus.net Mon Jul 3 13:21:17 2017 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 3 Jul 2017 13:21:17 +0200 Subject: [packages/iptables] - added ebtables patch to support plain ebtables command In-Reply-To: <87ffab9ee39fd264c3cbae4bd42e4c8b663d04bf_refs_heads_master@pld-linux.org> References: <037d4c5ec0e8ca11bece575c1cd7e2280d786920_refs_heads_master@pld-linux.org> <87ffab9ee39fd264c3cbae4bd42e4c8b663d04bf_refs_heads_master@pld-linux.org> Message-ID: <3843e411-7fa9-911c-bdde-c8b4ca6973c6@jajcus.net> On 2016-02-28 10:30, qboosh wrote: > commit 87ffab9ee39fd264c3cbae4bd42e4c8b663d04bf > Author: Jakub Bogusz > Date: Sun Feb 28 10:33:51 2016 +0100 > > - added ebtables patch to support plain ebtables command I lost a few hours of work today because of this not-well-thought-out change. There was a reason this command is not there upstream. This is not compatible with original ebtables, and buggy even in the basic functionality it is supposed to provide. Jacek From jajcus at jajcus.net Mon Jul 3 13:26:41 2017 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 3 Jul 2017 13:26:41 +0200 Subject: [packages/iptables] - added ebtables init scripts In-Reply-To: <9ec3dc4d5d00befe1b59d557cc4d4e34635816c5_refs_heads_master@pld-linux.org> References: <87ffab9ee39fd264c3cbae4bd42e4c8b663d04bf_refs_heads_master@pld-linux.org> <9ec3dc4d5d00befe1b59d557cc4d4e34635816c5_refs_heads_master@pld-linux.org> Message-ID: <476910e0-dfe1-24d7-05b7-5c92578b8f01@jajcus.net> On 2016-04-09 15:45, baggins wrote: > commit 9ec3dc4d5d00befe1b59d557cc4d4e34635816c5 > Author: Jan R?korajski > Date: Sat Apr 9 21:57:09 2016 +0900 > > - added ebtables init scripts Have you actually tested this? > + if is_yes "$EBTABLES_BINARY_FORMAT"; then > + for table in $(ls /etc/sysconfig/ebtables.* 2>/dev/null | sed -e 's/.*ebtables\.//' -e '/save/d' ); do > + /usr/sbin/ebtables -t $table --atomic-file /etc/sysconfig/ebtables.$table --atomic-commit || RETVAL=1 > + done --atomic-file, --atomic-commit do not seem to work at all in the iptables-provided 'ebtables' [root at jajo ~]# ebtables-compat -t filter --atomic-file /tmp/x --atomic-commit Extensions only for -A, -I, -D and -C. [root at jajo ~]# ebtables-compat -t filter --atomic-file /tmp/x --atomic-save Extensions only for -A, -I, -D and -C. > + else > + /usr/sbin/ebtables-restore < /etc/sysconfig/ebtables || RETVAL=1 > + fi And there is no such thing as ebtables-restore or ebtables-save here, Jacek From baggins at pld-linux.org Tue Jul 4 21:07:47 2017 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Tue, 4 Jul 2017 21:07:47 +0200 Subject: [packages/iptables] - added ebtables init scripts In-Reply-To: <476910e0-dfe1-24d7-05b7-5c92578b8f01@jajcus.net> References: <87ffab9ee39fd264c3cbae4bd42e4c8b663d04bf_refs_heads_master@pld-linux.org> <9ec3dc4d5d00befe1b59d557cc4d4e34635816c5_refs_heads_master@pld-linux.org> <476910e0-dfe1-24d7-05b7-5c92578b8f01@jajcus.net> Message-ID: <20170704190747.GA11733@tachikoma> On Mon, 03 Jul 2017, Jacek Konieczny wrote: > On 2016-04-09 15:45, baggins wrote: > > commit 9ec3dc4d5d00befe1b59d557cc4d4e34635816c5 > > Author: Jan R?korajski > > Date: Sat Apr 9 21:57:09 2016 +0900 > > > > - added ebtables init scripts > > Have you actually tested this? Not on in a real deployment. Just did basic run-test. Thank you for fixing this, please rebuild fixed packages. -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From baggins at pld-linux.org Wed Jul 5 10:06:08 2017 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Wed, 5 Jul 2017 10:06:08 +0200 Subject: [packages/iptables] - added ebtables init scripts In-Reply-To: <20170704190747.GA11733@tachikoma> References: <87ffab9ee39fd264c3cbae4bd42e4c8b663d04bf_refs_heads_master@pld-linux.org> <9ec3dc4d5d00befe1b59d557cc4d4e34635816c5_refs_heads_master@pld-linux.org> <476910e0-dfe1-24d7-05b7-5c92578b8f01@jajcus.net> <20170704190747.GA11733@tachikoma> Message-ID: <20170705080608.GA4292@home> On Tue, 04 Jul 2017, Jan R?korajski wrote: > On Mon, 03 Jul 2017, Jacek Konieczny wrote: > > > On 2016-04-09 15:45, baggins wrote: > > > commit 9ec3dc4d5d00befe1b59d557cc4d4e34635816c5 > > > Author: Jan R?korajski > > > Date: Sat Apr 9 21:57:09 2016 +0900 > > > > > > - added ebtables init scripts > > > > Have you actually tested this? > > Not on in a real deployment. Just did basic run-test. > Thank you for fixing this, please rebuild fixed packages. New packages moved to th-ready. Thanks. -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From glen at pld-linux.org Thu Jul 6 14:31:45 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Thu, 6 Jul 2017 15:31:45 +0300 Subject: grub legacy Message-ID: <459de0f9-810d-5da1-0a04-7f49f2e55627@pld-linux.org> removed grub legacy from th it's broken at least since 2015 february, and nobody bothered even to test that it actually works. -rw-r--r-- 3 pldth pldth 574 Feb 28 2015 grub-0.97-18.src.rpm.info the problem is that due our broken linkage (or whatever) the stage1 is 130mb, so it's unusable (too big) for anything, and if you do not know that, you get grub installed but it hangs at boot, because it was not really properly installed. this will hopefully save someones precious time in the future. -- glen From baggins at pld-linux.org Mon Jul 10 13:02:48 2017 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Mon, 10 Jul 2017 20:02:48 +0900 Subject: [packages/FHS] introduce /usr/{,local/}libexec directories In-Reply-To: References:

Message-ID: <20170710110246.GA2752@tachikoma> If you want me to keep this commit and directory then follow up by: a) updating rpm macros b) cleaning up packages that have libexec redefined directly in specs FHS states this directory is optional, and I do not care at all what GNU shamans think. This is not GNU/PLD, just PLD. On Thu, 06 Jul 2017, gotar wrote: > commit d49d853dc96ef5cd1a7d7f8f900577608a38be03 > Author: Tomasz Pala > Date: Thu Jul 6 11:41:42 2017 +0200 > > introduce /usr/{,local/}libexec directories > > https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html > > Note, that /usr/local/libexec is not mentioned explicitly in > https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#requirements10, > but rationale behind both libexec and local hierarchy allow us to treat > this as lib. > > Since /usr/local/libexec should exist for GNU applications according to > https://www.gnu.org/prep/standards/html_node/Directory-Variables.html, > we must provide /usr/libexec directory as well to met FHS requirements. > > FHS.spec | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > --- > diff --git a/FHS.spec b/FHS.spec > index f92f737..3291fdd 100644 > --- a/FHS.spec > +++ b/FHS.spec > @@ -12,7 +12,7 @@ Summary(pl.UTF-8): Podstawowy uk?ad katalog?w systemu Linux zgodny z FHS 3.0 > Summary(tr.UTF-8): Temel dosya sistemi yap?s? > Name: FHS > Version: 3.0 > -Release: 1 > +Release: 2 > License: GPL > Group: Base > URL: http://refspecs.linuxfoundation.org/fhs.shtml > @@ -83,10 +83,10 @@ install -d \ > $RPM_BUILD_ROOT/etc/{X11,opt} \ > $RPM_BUILD_ROOT/lib/modules \ > $RPM_BUILD_ROOT/{mnt,media,proc,root/tmp,sbin,tmp} \ > - $RPM_BUILD_ROOT/usr/{bin,games,include,lib,sbin,share,src} \ > + $RPM_BUILD_ROOT/usr/{bin,games,include,lib{,exec},sbin,share,src} \ > $RPM_BUILD_ROOT/usr/share/{color/icc,dict,doc,games,info,misc,ppd,tmac,xml} \ > $RPM_BUILD_ROOT/usr/lib/games \ > - $RPM_BUILD_ROOT/usr/local/{bin,etc,games,include,lib,sbin,share/{color/icc,doc,info,man},src} \ > + $RPM_BUILD_ROOT/usr/local/{bin,etc,games,include,lib{,exec},sbin,share/{color/icc,doc,info,man},src} \ > $RPM_BUILD_ROOT/var/{cache,crash,db,games,lib/{color/icc,misc},local,lock,log,mail,opt,run,spool,tmp,yp} > > %if %{with lib64} > @@ -165,6 +165,7 @@ posix.chown("/var/lock", 0, %{gid_uucp}) > %dir /usr/games > %dir /usr/include > %dir /usr/lib > +%dir /usr/libexec > %dir /usr/lib/games > %dir /usr/sbin > %dir /usr/share > @@ -187,6 +188,7 @@ posix.chown("/var/lock", 0, %{gid_uucp}) > %dir /usr/local/games > %dir /usr/local/include > %dir /usr/local/lib > +%dir /usr/local/libexec > %dir /usr/local/sbin > %dir /usr/local/share > %dir /usr/local/share/color > ================================================================ > > ---- gitweb: > > http://git.pld-linux.org/gitweb.cgi/packages/FHS.git/commitdiff/d49d853dc96ef5cd1a7d7f8f900577608a38be03 > > _______________________________________________ > pld-cvs-commit mailing list > pld-cvs-commit at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From gotar at pld-linux.org Mon Jul 10 16:57:30 2017 From: gotar at pld-linux.org (Tomasz Pala) Date: Mon, 10 Jul 2017 16:57:30 +0200 Subject: [packages/FHS] introduce /usr/{,local/}libexec directories In-Reply-To: <20170710110246.GA2752@tachikoma> References:

<20170710110246.GA2752@tachikoma> Message-ID: <20170710145730.GA444@polanet.pl> On Mon, Jul 10, 2017 at 20:02:48 +0900, Jan R?korajski wrote: > If you want me to keep this commit and directory then follow up by: > > a) updating rpm macros Yes, I was considering this point. Just wondering, what would break (in theory: nothing should) and how to perform the validation. Didn't want to do such change without more feedback, so now - if you already summoned this subject, I'll wait a few days for any comments. I've already reviewed these and only one (re)definition needs to be adjusted (in /usr/lib/rpm/macros.d/pld), remaining macros seem to be cascading properly. > b) cleaning up packages that have libexec redefined directly in specs > FHS states this directory is optional, and I do not care at all what GNU > shamans think. This is not GNU/PLD, just PLD. I don't care about all this GNU/crap either, but using some Fedora systems this directory was really convenient. My personal rationale is 'follow the world', just to avoid being different than all the rest. -- Tomasz Pala From qboosh at pld-linux.org Mon Jul 10 17:35:26 2017 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Mon, 10 Jul 2017 17:35:26 +0200 Subject: [packages/FHS] introduce /usr/{,local/}libexec directories In-Reply-To: <20170710145730.GA444@polanet.pl> References:

<20170710110246.GA2752@tachikoma> <20170710145730.GA444@polanet.pl> Message-ID: <20170710153526.GA31957@mail> On Mon, Jul 10, 2017 at 04:57:30PM +0200, Tomasz Pala wrote: > On Mon, Jul 10, 2017 at 20:02:48 +0900, Jan R?korajski wrote: > > > If you want me to keep this commit and directory then follow up by: > > > > a) updating rpm macros > > Yes, I was considering this point. Just wondering, what would break (in > theory: nothing should) and how to perform the validation. Didn't want > to do such change without more feedback, so now - if you already > summoned this subject, I'll wait a few days for any comments. > > I've already reviewed these and only one (re)definition needs to be > adjusted (in /usr/lib/rpm/macros.d/pld), remaining macros seem to be > cascading properly. Note that there are some inter-package consistency requirements. And just like some packages having hardcoded /usr/libexec, and "require hackery" to use libdir subdirectory, the others have hardcoded /usr/lib** for this purpose and would "require hackery" to use libexec. Without using libexec consequently, I don't see any profits (single place for internal binaries). > > b) cleaning up packages that have libexec redefined directly in specs > > > FHS states this directory is optional, and I do not care at all what GNU > > shamans think. This is not GNU/PLD, just PLD. > > I don't care about all this GNU/crap either, but using some Fedora > systems this directory was really convenient. My personal rationale is > 'follow the world', just to avoid being different than all the rest. On the other side, the "second half of the world" (Debian/Ubuntu) doesn't use libexec. >From minorities, e.g. Gentoo uses, Arch doesn't. -- Jakub Bogusz http://qboosh.pl/ From gotar at polanet.pl Mon Jul 10 18:38:13 2017 From: gotar at polanet.pl (Tomasz Pala) Date: Mon, 10 Jul 2017 18:38:13 +0200 Subject: [packages/FHS] introduce /usr/{,local/}libexec directories In-Reply-To: <20170710153526.GA31957@mail> References:

<20170710110246.GA2752@tachikoma> <20170710145730.GA444@polanet.pl> <20170710153526.GA31957@mail> Message-ID: <20170710163813.GA25668@polanet.pl> On Mon, Jul 10, 2017 at 17:35:26 +0200, Jakub Bogusz wrote: > Note that there are some inter-package consistency requirements. > > And just like some packages having hardcoded /usr/libexec, and "require > hackery" to use libdir subdirectory, the others have hardcoded /usr/lib** > for this purpose and would "require hackery" to use libexec. > > Without using libexec consequently, I don't see any profits (single > place for internal binaries). There is at least one I've mentioned previously - we could enforce no-or-only-libdir policy (forbid mixing shared libraries with other constant-path files within one subpackage). Whether it is profitable to have not all the private binaries inside libdir is a matter of taste. Of course, moving 10% is pointless, but if we managed to move 70% it would significally reduce the libdir clutter. And - what should be mentioned, introducing /usr/libexec might be a value ITSELF. Just as you've noticed, some packages require hackery the either way. Why don't we simply choose to not swing them back and forth? Remember, FHS stands that it is the APPLICATION's choice which location it uses. Having that in mind I would stand for not-altering defaults. The obvious gain: simplified packaging. >> I don't care about all this GNU/crap either, but using some Fedora >> systems this directory was really convenient. My personal rationale is >> 'follow the world', just to avoid being different than all the rest. > > On the other side, the "second half of the world" (Debian/Ubuntu) doesn't > use libexec. From minorities, e.g. Gentoo uses, Arch doesn't. I've found an interesting discussion: https://lists.debian.org/debian-devel/2005/05/msg00565.html - they didn't have libexec only because it was non-existant in FHS 2.x. I do however remember, that Ubuntu had libexec some time ago... Would it be possible, that Debian still uses FHS 2.3? http://www.debian.org/doc/debian-policy/ch-opersys.html 3.0 is only 2 years old, they might have not switched yet. Anyway, BSD also uses libexec. And while traversing google I find many bug reports regarding missing libexec in Debian, which convinces me that it's also our trouble source not to have it. -- Tomasz Pala From glen at pld-linux.org Mon Jul 10 23:31:32 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 11 Jul 2017 00:31:32 +0300 Subject: caja broken (gtk+2 vs gtk+3) Message-ID: [~] ? caja . (caja:27619): Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported Trace/breakpoint trap [~] ? rpm -q caja caja-1.16.1-1.x86_64 [~] ? -- glen From baggins at pld-linux.org Tue Jul 11 01:56:52 2017 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Tue, 11 Jul 2017 08:56:52 +0900 Subject: [packages/FHS] introduce /usr/{,local/}libexec directories In-Reply-To: <20170710153526.GA31957@mail> References:

<20170710110246.GA2752@tachikoma> <20170710145730.GA444@polanet.pl> <20170710153526.GA31957@mail> Message-ID: <20170710235650.GB2752@tachikoma> On Mon, 10 Jul 2017, Jakub Bogusz wrote: > On Mon, Jul 10, 2017 at 04:57:30PM +0200, Tomasz Pala wrote: > > On Mon, Jul 10, 2017 at 20:02:48 +0900, Jan R?korajski wrote: > > > > > If you want me to keep this commit and directory then follow up by: > > > > > > a) updating rpm macros > > > > Yes, I was considering this point. Just wondering, what would break (in > > theory: nothing should) and how to perform the validation. Didn't want > > to do such change without more feedback, so now - if you already > > summoned this subject, I'll wait a few days for any comments. > > > > I've already reviewed these and only one (re)definition needs to be > > adjusted (in /usr/lib/rpm/macros.d/pld), remaining macros seem to be > > cascading properly. > > Note that there are some inter-package consistency requirements. > > And just like some packages having hardcoded /usr/libexec, and "require > hackery" to use libdir subdirectory, the others have hardcoded /usr/lib** > for this purpose and would "require hackery" to use libexec. > > Without using libexec consequently, I don't see any profits (single > place for internal binaries). I see a profit - not doing that hackery. The other hackery is for mixing arch and noarch subpackages. Right now it's either all or nothing - libdir or datadir (see git-core ping-pong), or hacking program to understand both locations. With libexec dir we'll have it the way author wanted and will be able to build noarch subpackages. -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From gotar at polanet.pl Tue Jul 11 05:18:37 2017 From: gotar at polanet.pl (Tomasz Pala) Date: Tue, 11 Jul 2017 05:18:37 +0200 Subject: caja broken (gtk+2 vs gtk+3) In-Reply-To: References: Message-ID: <20170711031836.GA28640@polanet.pl> On Tue, Jul 11, 2017 at 00:31:32 +0300, Elan Ruusam?e wrote: > (caja:27619): Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x > and GTK+ 3 in the same process is not supported ldd -v objdump -x | grep NEEDED would help you to track what dependency fetches different library SOVER. -- Tomasz Pala From baggins at pld-linux.org Sun Jul 16 02:24:13 2017 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sun, 16 Jul 2017 09:24:13 +0900 Subject: [packages/gtef] - new (and the last release undef gtef name) In-Reply-To: <9c6268a7e3fa022b2a562585758ec0d34cad2075_refs_heads_master@pld-linux.org> References: <150013791081.14663.8291356790433687312@pld-linux.org> <9c6268a7e3fa022b2a562585758ec0d34cad2075_refs_heads_master@pld-linux.org> Message-ID: <20170716002411.GA2709@tachikoma> What's the point of adding this? It looks like waste of effort and resources, especially that you also added package under new name. On Sat, 15 Jul 2017, qboosh wrote: > commit 9c6268a7e3fa022b2a562585758ec0d34cad2075 > Author: Jakub Bogusz > Date: Sat Jul 15 19:00:14 2017 +0200 > > - new (and the last release undef gtef name) > > gtef.spec | 168 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 168 insertions(+) > --- > diff --git a/gtef.spec b/gtef.spec > new file mode 100644 > index 0000000..b146363 > --- /dev/null > +++ b/gtef.spec > @@ -0,0 +1,168 @@ > +# > +# Conditional build: > +%bcond_without static_libs # don't build static libraries > +# > +Summary: Gtef - GTK+ Text Editor Framework > +Summary(pl.UTF-8): Gtef (GTK+ Text Editor Framework) - szkielet edytora tekstu operatego na GTK+ > +Name: gtef > +Version: 2.0.1 > +Release: 1 > +License: LGPL v2.1+ > +Group: Libraries > +Source0: http://ftp.acc.umu.se/pub/GNOME/sources/gtef/2.0/%{name}-%{version}.tar.xz > +# Source0-md5: fbd29e1b3503156e5d40714839474b25 > +URL: https://wiki.gnome.org/Projects/Gtef > +BuildRequires: autoconf >= 2.64 > +BuildRequires: automake >= 1:1.14 > +BuildRequires: gettext-tools >= 0.19.4 > +BuildRequires: glib2-devel >= 1:2.52 > +BuildRequires: gobject-introspection-devel >= 1.42.0 > +BuildRequires: gtk+3-devel >= 3.20 > +BuildRequires: gtk-doc >= 1.25 > +BuildRequires: gtksourceview3-devel >= 3.22 > +BuildRequires: libtool >= 2:2.2.6 > +BuildRequires: libxml2-devel >= 1:2.5 > +BuildRequires: pkgconfig > +BuildRequires: uchardet-devel > +BuildRequires: vala > +Requires: glib2 >= 1:2.52 > +Requires: gtk+3 >= 3.20 > +Requires: gtksourceview3 >= 3.22 > +Requires: libxml2 >= 1:2.5 > +BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n) > + > +%description > +The final goal is to create a Tabbed Document Interface (TDI) > +framework suitable for text editors. > + > +But the first short-term goal is to have a higher-level API to load > +and save a file. All the errors would be handled by Gtef, showing > +GtkInfoBars etc. > + > +%description -l pl.UTF-8 > +Ostatecznym celem projektu jest stworzenie szkieletu zak?adkowego > +interfejsu do dokument?w (TDI - Tabbed Document Interface), nadaj?cego > +si? do edytor?w tekstu. > + > +Ale pierwszym, kr?tkoterminowym celem, jest stworzenie > +wysokopoziomowego API do wczytywania i zapisywania plik?w. Wszystkie > +b??dy maj? by? obs?ugiwane przez Gtef, z wy?wietlaniem GtkInfoBar?w > +itp. > + > +%package devel > +Summary: Header files for Gtef library > +Summary(pl.UTF-8): Pliki nag??wkowe biblioteki Gtef > +Group: Development/Libraries > +Requires: %{name} = %{version}-%{release} > +Requires: glib2-devel >= 1:2.52 > +Requires: gtk+3-devel >= 3.20 > +Requires: gtksourceview3-devel >= 3.22 > +Requires: libxml2-devel >= 1:2.5 > +Requires: uchardet-devel > + > +%description devel > +Header files for Gtef library. > + > +%description devel -l pl.UTF-8 > +Pliki nag??wkowe biblioteki Gtef. > + > +%package static > +Summary: Static Gtef library > +Summary(pl.UTF-8): Statyczna biblioteka Gtef > +Group: Development/Libraries > +Requires: %{name}-devel = %{version}-%{release} > + > +%description static > +Static Gtef library. > + > +%description static -l pl.UTF-8 > +Statyczna biblioteka Gtef. > + > +%package -n vala-gtef > +Summary: Vala API for Gtef library > +Summary(pl.UTF-8): API j?zyka Vala do biblioteki Gtef > +Group: Development/Libraries > +Requires: %{name}-devel = %{version}-%{release} > +Requires: vala > + > +%description -n vala-gtef > +Vala API for Gtef library. > + > +%description -n vala-gtef -l pl.UTF-8 > +API j?zyka Vala do biblioteki Gtef. > + > +%package apidocs > +Summary: API documentation for Gtef library > +Summary(pl.UTF-8): Dokumentacja API biblioteki Gtef > +Group: Documentation > +%if "%{_rpmversion}" >= "5" > +BuildArch: noarch > +%endif > + > +%description apidocs > +API documentation for Gtef library. > + > +%description apidocs -l pl.UTF-8 > +Dokumentacja API biblioteki Gtef. > + > +%prep > +%setup -q > + > +%build > +# rebuild ac/am/lt for as-needed to work > +%{__libtoolize} > +%{__aclocal} -I m4 > +%{__autoconf} > +%{__autoheader} > +%{__automake} > +%configure \ > + --disable-silent-rules \ > + %{?with_static_libs:--enable-static} \ > + --with-html-dir=%{_gtkdocdir} > +%{__make} > + > +%install > +rm -rf $RPM_BUILD_ROOT > + > +%{__make} install \ > + DESTDIR=$RPM_BUILD_ROOT > + > +# obsoleted by pkg-config > +%{__rm} $RPM_BUILD_ROOT%{_libdir}/libgtef-2.la > + > +%find_lang gtef-2 > + > +%clean > +rm -rf $RPM_BUILD_ROOT > + > +%post -p /sbin/ldconfig > +%postun -p /sbin/ldconfig > + > +%files -f gtef-2.lang > +%defattr(644,root,root,755) > +%doc AUTHORS NEWS README > +%attr(755,root,root) %{_libdir}/libgtef-2.so.*.*.* > +%attr(755,root,root) %ghost %{_libdir}/libgtef-2.so.0 > +%{_libdir}/girepository-1.0/Gtef-2.typelib > + > +%files devel > +%defattr(644,root,root,755) > +%attr(755,root,root) %{_libdir}/libgtef-2.so > +%{_includedir}/gtef-2 > +%{_datadir}/gir-1.0/Gtef-2.gir > +%{_pkgconfigdir}/gtef-2.pc > + > +%if %{with static_libs} > +%files static > +%defattr(644,root,root,755) > +%{_libdir}/libgtef-2.a > +%endif > + > +%files -n vala-gtef > +%defattr(644,root,root,755) > +%{_datadir}/vala/vapi/gtef-2.deps > +%{_datadir}/vala/vapi/gtef-2.vapi > + > +%files apidocs > +%defattr(644,root,root,755) > +%{_gtkdocdir}/gtef-2.0 > ================================================================ > > ---- gitweb: > > http://git.pld-linux.org/gitweb.cgi/packages/gtef.git/commitdiff/9c6268a7e3fa022b2a562585758ec0d34cad2075 > > _______________________________________________ > pld-cvs-commit mailing list > pld-cvs-commit at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From qboosh at pld-linux.org Sun Jul 16 08:43:19 2017 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sun, 16 Jul 2017 08:43:19 +0200 Subject: [packages/gtef] - new (and the last release undef gtef name) In-Reply-To: <20170716002411.GA2709@tachikoma> References: <150013791081.14663.8291356790433687312@pld-linux.org> <9c6268a7e3fa022b2a562585758ec0d34cad2075_refs_heads_master@pld-linux.org> <20170716002411.GA2709@tachikoma> Message-ID: <20170716064319.GA18280@mail> On Sun, Jul 16, 2017 at 09:24:13AM +0900, Jan R?korajski wrote: > What's the point of adding this? It looks like waste of effort and > resources, especially that you also added package under new name. gtef has stable releases and is used by latexila from GNOME 3.24. tepl has only development prerelease (2.99.x) and will be used in the future. -- Jakub Bogusz http://qboosh.pl/ From n3npq at me.com Tue Jul 18 12:47:10 2017 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 18 Jul 2017 06:47:10 -0400 Subject: rpm-5.4.18 snapshot available Message-ID: <7AFE8A3F-2C2C-4986-9A91-313AAD459903@me.com> There?s a work-in-progress snapshot of the next version of RPM at rpm-5.4.17-0.20160510.src.rpm I?m mostly interested in early feedback on the contents before deciding what (e.g. gnulib) should be included in a final tarball at this point. rpm-5.4.18 implements file capabilities, and has an implementation of zest compression., to name two features that might be of interest. Berkeley DB detection has been reworked so that no patching is needed, and the latest available installed libdb-X.Y will be used. Note that there is a 1-line patch to Berkeley DB needed since db-6.1.23: . If multiple versions of Berkeley DB are installed with /us/include/db.h, then you will need to specify which db.h version to use explicitly using ?with-db=/usr/lib64:/usr/include/dbXY Almost all the splint annotations have been removed in RPM sources. so many patches will have to be rebased. Opinions? Please copy any replies to as well. 73 de Jeff From n3npq at me.com Tue Jul 18 12:48:56 2017 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 18 Jul 2017 06:48:56 -0400 Subject: rpm-5.4.18 snapshot available In-Reply-To: <7AFE8A3F-2C2C-4986-9A91-313AAD459903@me.com> References: <7AFE8A3F-2C2C-4986-9A91-313AAD459903@me.com> Message-ID: > On Jul 18, 2017, at 6:47 AM, Jeffrey Johnson wrote: > > There?s a work-in-progress snapshot of the next version of RPM at > rpm-5.4.17-0.20160510.src.rpm > Forgot to refresh my browser. The URL is rpm-5.4.18-0.20170718.src.rpm 73 de Jeff From glen at delfi.ee Tue Jul 18 15:08:24 2017 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 18 Jul 2017 16:08:24 +0300 Subject: rpm-5.4.18 snapshot available In-Reply-To: References: <7AFE8A3F-2C2C-4986-9A91-313AAD459903@me.com> Message-ID: <6d2b3624-2451-31aa-1ab7-46db239478eb@delfi.ee> On 18/07/2017 13:48, Jeffrey Johnson wrote: >> On Jul 18, 2017, at 6:47 AM, Jeffrey Johnson wrote: >> >> There?s a work-in-progress snapshot of the next version of RPM at >> rpm-5.4.17-0.20160510.src.rpm >> > Forgot to refresh my browser. The URL is > > rpm-5.4.18-0.20170718.src.rpm pld branch created, just tarball upload for now https://github.com/pld-linux/rpm/tree/dev-5.4.18 https://github.com/pld-linux/rpm/commit/6b2c729f771cae5d41568f332cf8732689d8e51c