From mmazur at kernel.pl  Wed Jul  2 11:40:51 2014
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Wed, 2 Jul 2014 11:40:51 +0200
Subject: New systemd
Message-ID: <201407021140.51188.mmazur@kernel.pl>

Are there any reasons not to upgrade to 214?

--mmazur


From baggins at pld-linux.org  Wed Jul  2 14:03:00 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Wed, 2 Jul 2014 14:03:00 +0200
Subject: New systemd
In-Reply-To: <201407021140.51188.mmazur@kernel.pl>
References: <201407021140.51188.mmazur@kernel.pl>
Message-ID: <20140702120300.GA7910@tachikoma.lan>

On Wed, 02 Jul 2014, Mariusz Mazur wrote:

> Are there any reasons not to upgrade to 214?

Read the changelog. It needs to be carefully cut down and unbloated.
Systemd upgrade is not someting we can "just bump and rebuild",
and I don't have the time for it (job change, moving house, etc.)

-- 
Jan R?korajski                                 | PLD/Linux
SysAdm                                         | http://www.pld-linux.org/
baggins<at>mimuw.edu.pl
baggins<at>pld-linux.org


From jajcus at jajcus.net  Wed Jul  2 15:04:30 2014
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 02 Jul 2014 15:04:30 +0200
Subject: New systemd
In-Reply-To: <20140702120300.GA7910@tachikoma.lan>
References: <201407021140.51188.mmazur@kernel.pl>
 <20140702120300.GA7910@tachikoma.lan>
Message-ID: <53B4035E.5000801@jajcus.net>

On 02/07/14 14:03, Jan R?korajski wrote:
> On Wed, 02 Jul 2014, Mariusz Mazur wrote:
> 
>> Are there any reasons not to upgrade to 214?
> 
> Read the changelog. 

I have just read all the release announcement since 208. A lot of useful
changes have been introduced.

> It needs to be carefully cut down and unbloated.

What do you mean by 'cut down'? And what do you consider the 'bloat'.
Most the things introduced since 208 may be really useful, and the rest
won't break anything.
Many of the changes make a lot of hacks, needed now, unnecessary.

> Systemd upgrade is not someting we can "just bump and rebuild",

Yes.

> and I don't have the time for it (job change, moving house, etc.)

Maybe someone else can take care of that. It could be me, but not now.

Greets,
Jacek


From glen at pld-linux.org  Wed Jul  2 15:45:30 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Wed, 02 Jul 2014 16:45:30 +0300
Subject: pulseaudio: dbus & avahi
Message-ID: <53B40CFA.9090509@pld-linux.org>

http://git.pld-linux.org/?p=packages/pulseaudio.git;a=commitdiff;h=9a1fe95ea83c5587bac294642a2e1daf8d9efc34

why these are required not suggested?

-- 
glen



From baggins at pld-linux.org  Wed Jul  2 21:06:15 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Wed, 2 Jul 2014 21:06:15 +0200
Subject: New systemd
In-Reply-To: <53B4035E.5000801@jajcus.net>
References: <201407021140.51188.mmazur@kernel.pl>
 <20140702120300.GA7910@tachikoma.lan> <53B4035E.5000801@jajcus.net>
Message-ID: <20140702190614.GC7910@tachikoma.lan>

On Wed, 02 Jul 2014, Jacek Konieczny wrote:

> On 02/07/14 14:03, Jan R?korajski wrote:
> > On Wed, 02 Jul 2014, Mariusz Mazur wrote:
> > 
> >> Are there any reasons not to upgrade to 214?
> > 
> > Read the changelog. 
> 
> I have just read all the release announcement since 208. A lot of useful
> changes have been introduced.

I saw them too, but...

> 
> > It needs to be carefully cut down and unbloated.
> 
> What do you mean by 'cut down'? And what do you consider the 'bloat'.
> Most the things introduced since 208 may be really useful, and the rest
> won't break anything.

... that's unfortunately not true :( Right now the obstacle is networkd
and I do consider this daemon a bloat, maybe it improved over time but
when it came out it was primitive bordering on pathetic _and_ it would just
kill your network if you had anything more than simple dhcp address.
Especially with the advanced configs we have in PLD, networkd must be
disabled by default.

> Many of the changes make a lot of hacks, needed now, unnecessary.

Agree here, we could probably safely remove LVM/MD/DM detection helpers.

> > Systemd upgrade is not someting we can "just bump and rebuild",
> 
> Yes.
> 
> > and I don't have the time for it (job change, moving house, etc.)
> 
> Maybe someone else can take care of that. It could be me, but not now.

Anyone can do it, but has to be very, very carefull when doing so.

-- 
Jan R?korajski                                 | PLD/Linux
SysAdm                                         | http://www.pld-linux.org/
baggins<at>mimuw.edu.pl
baggins<at>pld-linux.org


From jajcus at jajcus.net  Thu Jul  3 09:17:52 2014
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Thu, 03 Jul 2014 09:17:52 +0200
Subject: New systemd
In-Reply-To: <20140702190614.GC7910@tachikoma.lan>
References: <201407021140.51188.mmazur@kernel.pl>
 <20140702120300.GA7910@tachikoma.lan> <53B4035E.5000801@jajcus.net>
 <20140702190614.GC7910@tachikoma.lan>
Message-ID: <53B503A0.4050201@jajcus.net>

On 02/07/14 21:06, Jan R?korajski wrote:
>> What do you mean by 'cut down'? And what do you consider the 'bloat'.
>> Most the things introduced since 208 may be really useful, and the rest
>> won't break anything.
> 
> ... that's unfortunately not true :( Right now the obstacle is networkd
> and I do consider this daemon a bloat, maybe it improved over time but
> when it came out it was primitive bordering on pathetic _and_ it would just
> kill your network if you had anything more than simple dhcp address.
> Especially with the advanced configs we have in PLD, networkd must be
> disabled by default.

1. from the announcements I got a feeling that networkd is fully
optional and enabled by default only for specific cases (virtualization)

2. PLD rc-scripts, even though has many advanced settings and support
for some very weird setups, is also pathetic and unusable for many
simple and typical use cases.

Let's take the default configuration:
? it would start and auto-configure (DHCP) only the first ethernet
interface, whatever it is during the boot (which is quite unpredictable
when there is more than one)
? it won't even start the DHCP client when there is no link on the
interface. The network won't work until someone manually restarts the
interface. This is a big fuck-up, which only could have make sense 10
years ago when DHCP clients were not able to monitor link state by
themselves.
? there is no way to easily support multiple interfaces with multiple
DNS configuration sources.

All these affect a laptop with Ethernet, WiFi and mobile interfaces used
interchangeably. Of course, dropping all the ifcfg-* configs and using
NetworkManager fixes that, but having a low-level working solution for
that is a good idea too. And that is exactly what networkd provides.

And even some servers need some lightweight, automatic and dynamic
network configuration in times when a server may be a virtual entity
which can be moved around the globe without a reboot.

We could, of course, try to fix rc-scripts with more and more shell
hacking (still trying to keep backward-compatibility), but why force us
to maintain that, when there are other, simple, tested and maintained
solutions.

networkd probably should not be enabled by default if the network is
already configured PLD-way, but otherwise it is good to have it.
I think it could be a good idea to use it by default when there is no
other network configuration. There is a change it will 'just work' in
the most common scenarios. We cannot provide this with our rc-scripts.

>>> Systemd upgrade is not someting we can "just bump and rebuild",
>>
>> Yes.
>>
>>> and I don't have the time for it (job change, moving house, etc.)
>>
>> Maybe someone else can take care of that. It could be me, but not now.
> 
> Anyone can do it, but has to be very, very carefull when doing so.

Yes.

Greets,
	Jacek


From baggins at pld-linux.org  Thu Jul  3 10:30:45 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Thu, 3 Jul 2014 10:30:45 +0200
Subject: New systemd
In-Reply-To: <53B503A0.4050201@jajcus.net>
References: <201407021140.51188.mmazur@kernel.pl>
 <20140702120300.GA7910@tachikoma.lan> <53B4035E.5000801@jajcus.net>
 <20140702190614.GC7910@tachikoma.lan> <53B503A0.4050201@jajcus.net>
Message-ID: <20140703083045.GF7910@tachikoma.lan>

On Thu, 03 Jul 2014, Jacek Konieczny wrote:

> On 02/07/14 21:06, Jan R?korajski wrote:
> >> What do you mean by 'cut down'? And what do you consider the 'bloat'.
> >> Most the things introduced since 208 may be really useful, and the rest
> >> won't break anything.
> > 
> > ... that's unfortunately not true :( Right now the obstacle is networkd
> > and I do consider this daemon a bloat, maybe it improved over time but
> > when it came out it was primitive bordering on pathetic _and_ it would just
> > kill your network if you had anything more than simple dhcp address.
> > Especially with the advanced configs we have in PLD, networkd must be
> > disabled by default.
> 
> 1. from the announcements I got a feeling that networkd is fully
> optional and enabled by default only for specific cases (virtualization)

I remember that when it came out it was enabled by default and I even
found a rant somewhere that it breaks your (any) distro settings because
of that.

> 2. PLD rc-scripts, even though has many advanced settings and support
> for some very weird setups, is also pathetic and unusable for many
> simple and typical use cases.

No arguing here :)
[...]

> networkd probably should not be enabled by default if the network is
> already configured PLD-way, but otherwise it is good to have it.
> I think it could be a good idea to use it by default when there is no
> other network configuration. There is a change it will 'just work' in
> the most common scenarios. We cannot provide this with our rc-scripts.

That's some solution, but consider new install, where networkd will be
enabled and then admin wants to make some changes to the NIC setup only
to find out it doesn't work. We need a simple way for networkd to
disable itself or our network scripts to disable it when needed.

Or we could just enable networkd by default on new/unconfigured installs
and put a big information-warning in our scripts what to do when someone
wants to use them instead of networkd.

-- 
Jan R?korajski                                 | PLD/Linux
SysAdm                                         | http://www.pld-linux.org/
baggins<at>mimuw.edu.pl
baggins<at>pld-linux.org


From jajcus at jajcus.net  Thu Jul  3 11:01:30 2014
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Thu, 03 Jul 2014 11:01:30 +0200
Subject: New systemd
In-Reply-To: <20140703083045.GF7910@tachikoma.lan>
References: <201407021140.51188.mmazur@kernel.pl>
 <20140702120300.GA7910@tachikoma.lan> <53B4035E.5000801@jajcus.net>
 <20140702190614.GC7910@tachikoma.lan> <53B503A0.4050201@jajcus.net>
 <20140703083045.GF7910@tachikoma.lan>
Message-ID: <53B51BEA.3000107@jajcus.net>

On 03/07/14 10:30, Jan R?korajski wrote:
>> networkd probably should not be enabled by default if the network is
>> already configured PLD-way, but otherwise it is good to have it.
>> I think it could be a good idea to use it by default when there is no
>> other network configuration. There is a change it will 'just work' in
>> the most common scenarios. We cannot provide this with our rc-scripts.
> 
> That's some solution, but consider new install, where networkd will be
> enabled and then admin wants to make some changes to the NIC setup only
> to find out it doesn't work. We need a simple way for networkd to
> disable itself or our network scripts to disable it when needed.

I guess networkd has some facilities for interaction with NetworkManager
(one should probably disable the other), maybe that could be reused for
rc-scripts too. Our 'ifup', when used with our ifcfg file could just
tell networkd 'ignore this interface from now on' or something. When
there is no ifcfg file, then ifup/ifdown could be just another interface
to networkd.

> Or we could just enable networkd by default on new/unconfigured installs
> and put a big information-warning in our scripts what to do when someone
> wants to use them instead of networkd.

That is the easy way and the solution I had initially in mind.

Greets,
	Jacek


From mike at osdn.org.ua  Fri Jul  4 13:55:17 2014
From: mike at osdn.org.ua (Michael Shigorin)
Date: Fri, 4 Jul 2014 14:55:17 +0300
Subject: New systemd
In-Reply-To: <201407021140.51188.mmazur@kernel.pl>
References: <201407021140.51188.mmazur@kernel.pl>
Message-ID: <20140704115517.GX9798@osdn.org.ua>

On Wed, Jul 02, 2014 at 11:40:51AM +0200, Mariusz Mazur wrote:
> Are there any reasons not to upgrade to 214?

We've had quite considerable PITA with its sysvinit related changes, JFYI.
On the positive side, 214 looks to be the fastest starter/halter for my 
ALT-based regular livecds (those of the set based on sysvinit, that is).

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info


From mike at osdn.org.ua  Fri Jul  4 14:03:17 2014
From: mike at osdn.org.ua (Michael Shigorin)
Date: Fri, 4 Jul 2014 15:03:17 +0300
Subject: network configuration subsystems (was: New systemd)
In-Reply-To: <53B503A0.4050201@jajcus.net>
References: <201407021140.51188.mmazur@kernel.pl>
 <20140702120300.GA7910@tachikoma.lan> <53B4035E.5000801@jajcus.net>
 <20140702190614.GC7910@tachikoma.lan> <53B503A0.4050201@jajcus.net>
Message-ID: <20140704120316.GY9798@osdn.org.ua>

On Thu, Jul 03, 2014 at 09:17:52AM +0200, Jacek Konieczny wrote:
> We could, of course, try to fix rc-scripts with more and more
> shell hacking (still trying to keep backward-compatibility),
> but why force us to maintain that, when there are other,
> simple, tested and maintained solutions.

Well you might be interested in /etc/net -- it's mature to the
point it needs minor to no maintenance, even the website has been
closed by its original author several years ago; here's the git:
http://git.altlinux.org/gears/e/etcnet.git?p=etcnet.git;a=tree;f=docs;hb=HEAD

Basically built from ground up around modern Linux kernel
networking capabilities and corresponding userspace tools.

ALT specific, portable (I've heard of a Gentoo package and router
use with a pile of physical interfaces, there was a failed Fedora
proposal too: https://bugzilla.redhat.com/195365).

Coexists with NM and connman just fine over here.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info


From alucard at nospheratu.net  Fri Jul  4 16:46:19 2014
From: alucard at nospheratu.net (Tomasz Rutkowski)
Date: Fri, 04 Jul 2014 16:46:19 +0200
Subject: New systemd
In-Reply-To: <53B51BEA.3000107@jajcus.net>
References: <201407021140.51188.mmazur@kernel.pl>
 <20140702120300.GA7910@tachikoma.lan> <53B4035E.5000801@jajcus.net>
 <20140702190614.GC7910@tachikoma.lan> <53B503A0.4050201@jajcus.net>
 <20140703083045.GF7910@tachikoma.lan> <53B51BEA.3000107@jajcus.net>
Message-ID: <1404485179.4387.1.camel@corvette.ultimo.pl>

Dnia 2014-07-03, czw o godzinie 11:01 +0200, Jacek Konieczny pisze:
> On 03/07/14 10:30, Jan R?korajski wrote:
> >> networkd probably should not be enabled by default if the network is
> >> already configured PLD-way, but otherwise it is good to have it.
> >> I think it could be a good idea to use it by default when there is no
> >> other network configuration. There is a change it will 'just work' in
> >> the most common scenarios. We cannot provide this with our rc-scripts.
> > 
> > That's some solution, but consider new install, where networkd will be
> > enabled and then admin wants to make some changes to the NIC setup only
> > to find out it doesn't work. We need a simple way for networkd to
> > disable itself or our network scripts to disable it when needed.
> 
> I guess networkd has some facilities for interaction with NetworkManager
> (one should probably disable the other), maybe that could be reused for
> rc-scripts too. Our 'ifup', when used with our ifcfg file could just
> tell networkd 'ignore this interface from now on' or something. When
> there is no ifcfg file, then ifup/ifdown could be just another interface
> to networkd.
> 
> > Or we could just enable networkd by default on new/unconfigured installs
> > and put a big information-warning in our scripts what to do when someone
> > wants to use them instead of networkd.
> 

networkd in last versions does automatic configuration on new interfaces
only for containers created with systemd-nspawn
normally it needs to have {systemd_dir}/network/whatever.network .netdev
files, thus it lives quite happy with our rc-scripts (dunno NM but I
presume similar)

215 works well on my kvm machines, have not tested yet baremetal...


regards
Tomasz Rutkowski



From baggins at pld-linux.org  Tue Jul  8 20:26:26 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 8 Jul 2014 20:26:26 +0200
Subject: [ANN] New kernel packages in Th and no vserver on master
Message-ID: <20140708182625.GK7910@tachikoma.lan>

Hi,
Probably you already now, but 3.14 was announced as a new longterm line.
We will ship now three longterm kernels, until 3.4 gets deprecated in
October this year, when it will be removed from Th.

Also, and more importantly, vserver support will be disabled on master,
that is 3.15.x as of this moment. It's because upstream support is
lacking and the project is falling behind the mainline kernel and only
really supported for the stable/longterm kernels. I'm sorry for this,
but we just don't have the resources to maintain and test updates for
this patch on our own.

-- 
Jan R?korajski                                 | PLD/Linux
SysAdm                                         | http://www.pld-linux.org/
baggins<at>mimuw.edu.pl
baggins<at>pld-linux.org


From baggins at pld-linux.org  Tue Jul  8 21:52:12 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 8 Jul 2014 21:52:12 +0200
Subject: ImageMagick Q8
In-Reply-To: <201406250922.10436.arekm@maven.pl>
References: <20140624110923.GA7612@polanet.pl>
 <201406250922.10436.arekm@maven.pl>
Message-ID: <20140708195211.GM7910@tachikoma.lan>

On Wed, 25 Jun 2014, Arkadiusz Mi?kiewicz wrote:

> On Tuesday 24 of June 2014, Tomasz Pala wrote:
> > Hi,
> > 
> > most images these days are 8-bit/component, most IM use cases covers
> > simple one-pass actions like converting formats or resizing, so while
> > defaulting to Q16 is the right way to go as suggested by IM docs itself,
> > we should also provide Q8 version, especially for wide range of
> > server-side processing of user supplied content. And the overhead of Q16
> > is HUGE - 30-50% more of CPU time and TWICE as much of memory. All that
> > wasted when most of the time anyone uses IM.
> 
> What major distros do? FC seems to use Q16, didn't check the rest.

Debian uses Q16, Ubuntu defaults which is Q16, Arch Q16, Alt Q16,
openSUSE Q16.

> If most of major distros is using Q8 then we could probably switch back. Or 
> use Q8 for php and Q16 for desktop apps if possible?

Practially everyone is using Q16, so the only viable solution would be a
separate, non-default, Q8 build for PHP and other CPU intensive, but not
quality oriented programs.

-- 
Jan R?korajski                                 | PLD/Linux
SysAdm                                         | http://www.pld-linux.org/
baggins<at>mimuw.edu.pl
baggins<at>pld-linux.org


From glen at pld-linux.org  Wed Jul  9 12:10:51 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Wed, 09 Jul 2014 13:10:51 +0300
Subject: ImageMagick Q8
In-Reply-To: <20140708195211.GM7910@tachikoma.lan>
References: <20140624110923.GA7612@polanet.pl>
 <201406250922.10436.arekm@maven.pl> <20140708195211.GM7910@tachikoma.lan>
Message-ID: <53BD152B.5040505@pld-linux.org>

On 08.07.2014 22:52, Jan R?korajski wrote:
> Practially everyone is using Q16, so the only viable solution would be a
> separate, non-default, Q8 build for PHP and other CPU intensive, but not
> quality oriented programs.
and would like to decrease dependencies in that Q8 build so that php 
doesn't yet again pull dozen of desktop deps!

i wonder, should such version be built from main IM.spec or create 
IMQ8.spec for this?

-- 
glen



From baggins at pld-linux.org  Fri Jul 11 08:40:29 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Fri, 11 Jul 2014 08:40:29 +0200
Subject: ImageMagick Q8
In-Reply-To: <53BD152B.5040505@pld-linux.org>
References: <20140624110923.GA7612@polanet.pl>
 <201406250922.10436.arekm@maven.pl>
 <20140708195211.GM7910@tachikoma.lan>
 <53BD152B.5040505@pld-linux.org>
Message-ID: <20140711064029.GN7910@tachikoma.lan>

On Wed, 09 Jul 2014, Elan Ruusam?e wrote:

> On 08.07.2014 22:52, Jan R?korajski wrote:
> > Practially everyone is using Q16, so the only viable solution would be a
> > separate, non-default, Q8 build for PHP and other CPU intensive, but not
> > quality oriented programs.
> and would like to decrease dependencies in that Q8 build so that php 
> doesn't yet again pull dozen of desktop deps!

Yes, that makes sense. No need for desktop apps on servers.

> i wonder, should such version be built from main IM.spec or create 
> IMQ8.spec for this?

I'd just make a single Q8 subpackage in IM.spec  with
all the files/modules (no splitting).

-- 
Jan R?korajski                                 | PLD/Linux
SysAdm                                         | http://www.pld-linux.org/
baggins<at>mimuw.edu.pl
baggins<at>pld-linux.org


From arekm at maven.pl  Sat Jul 12 18:42:46 2014
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Sat, 12 Jul 2014 18:42:46 +0200
Subject: glibc man pages
Message-ID: <201407121842.46748.arekm@maven.pl>


Hi. There are outdated manual pages in glibc.spec:
Source5:        http://qboosh.pl/man/%{name}-man-pages.tar.bz2

So the question is - do we really want them there? man-pages project have 
updated version, so why we don't use these pages from man-pages?

example strtoll page

-- 
Arkadiusz Mi?kiewicz, arekm / maven.pl


From qboosh at pld-linux.org  Sat Jul 12 21:08:15 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sat, 12 Jul 2014 21:08:15 +0200
Subject: glibc man pages
In-Reply-To: <201407121842.46748.arekm@maven.pl>
References: <201407121842.46748.arekm@maven.pl>
Message-ID: <20140712190815.GA917@mail>

On Sat, Jul 12, 2014 at 06:42:46PM +0200, Arkadiusz Mi?kiewicz wrote:
> 
> Hi. There are outdated manual pages in glibc.spec:
> Source5:        http://qboosh.pl/man/%{name}-man-pages.tar.bz2
> 
> So the question is - do we really want them there? man-pages project have 
> updated version, so why we don't use these pages from man-pages?

This tarball should be updated from latest man pages.

I worked on some automation scripts for updating per-package man pages
tarballs a few years ago, maybe it would be easy to use them for glibc
now...


-- 
Jakub Bogusz    http://qboosh.pl/


From arekm at maven.pl  Sat Jul 12 21:28:47 2014
From: arekm at maven.pl (Arkadiusz =?iso-8859-2?q?Mi=B6kiewicz?=)
Date: Sat, 12 Jul 2014 21:28:47 +0200
Subject: glibc man pages
In-Reply-To: <20140712190815.GA917@mail>
References: <201407121842.46748.arekm@maven.pl> <20140712190815.GA917@mail>
Message-ID: <201407122128.47709.arekm@maven.pl>

On Saturday 12 of July 2014, Jakub Bogusz wrote:
> On Sat, Jul 12, 2014 at 06:42:46PM +0200, Arkadiusz Mi?kiewicz wrote:
> > Hi. There are outdated manual pages in glibc.spec:
> > Source5:        http://qboosh.pl/man/%{name}-man-pages.tar.bz2
> > 
> > So the question is - do we really want them there? man-pages project have
> > updated version, so why we don't use these pages from man-pages?
> 
> This tarball should be updated from latest man pages.
> 
> I worked on some automation scripts for updating per-package man pages
> tarballs a few years ago, maybe it would be easy to use them for glibc
> now...

I fail to understand why we want them in glibc.spec so badly. man-pages.spec 
providing them is more sane to me.

Maintained, doesn't require glibc rebuild and upgrade to get updated docs etc.

-- 
Arkadiusz Mi?kiewicz, arekm / maven.pl


From glen at pld-linux.org  Sat Jul 12 22:08:15 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Sat, 12 Jul 2014 23:08:15 +0300
Subject: dotnet-notify-sharp
Message-ID: <53C195AF.7070100@pld-linux.org>

there's 3.0
https://www.meebey.net/projects/notify-sharp/

needed by sparkeshare
---
checking for NOTIFY_SHARP... no
configure: error: Package requirements (notify-sharp-3.0) were not met:

No package 'notify-sharp-3.0' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables NOTIFY_SHARP_CFLAGS
and NOTIFY_SHARP_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
---

so, should it be packaged as new package? what basename?
or just current dotnet-notify-sharp.spec updated to 3.x?

-- 
glen



From qboosh at pld-linux.org  Sun Jul 13 08:59:32 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sun, 13 Jul 2014 08:59:32 +0200
Subject: dotnet-notify-sharp
In-Reply-To: <53C195AF.7070100@pld-linux.org>
References: <53C195AF.7070100@pld-linux.org>
Message-ID: <20140713065932.GA3681@mail>

On Sat, Jul 12, 2014 at 11:08:15PM +0300, Elan Ruusam?e wrote:
> there's 3.0
> https://www.meebey.net/projects/notify-sharp/
> 
> needed by sparkeshare
> ---
> checking for NOTIFY_SHARP... no
> configure: error: Package requirements (notify-sharp-3.0) were not met:
> 
> No package 'notify-sharp-3.0' found
> 
> Consider adjusting the PKG_CONFIG_PATH environment variable if you
> installed software in a non-standard prefix.
> 
> Alternatively, you may set the environment variables NOTIFY_SHARP_CFLAGS
> and NOTIFY_SHARP_LIBS to avoid the need to call pkg-config.
> See the pkg-config man page for more details.
> ---
> 
> so, should it be packaged as new package? what basename?
> or just current dotnet-notify-sharp.spec updated to 3.x?

I'd use dotnet-notify-sharp3.spec or update existing package.
Everything except for -devel seems parallel installable.
notify-sharp 0.4.x was for GTK+ 2, notify-sharp 3.0.0 is for GTK+ 3.

If preserving existing package, it could be updated to 0.4.1 (from
meebey's git) to use plain dbus-sharp instead of obsolete ndesk variant.


-- 
Jakub Bogusz    http://qboosh.pl/


From glen at pld-linux.org  Sun Jul 13 13:20:54 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Sun, 13 Jul 2014 14:20:54 +0300
Subject: P python(abi)
Message-ID: <53C26B96.7000409@pld-linux.org>

mono-devel-3.4.0-1.x86_64: required "python(abi)" is provided by the 
following packages:
a) python-libs-2.7.7-1.x86_64
b) python-modules-2.7.7-1.x86_64
c) python3-libs-3.3.5-2.x86_64

$ rpm -q python-modules --provides|grep abi
python(abi) = 2.7

$ rpm -q python-libs --provides|grep abi
python(abi) = 2.7

$ rpm -q python3-libs --provides|grep abi
python(abi) = 3.3


where does that provide really belong? python-libs? python-modules? python?
and shouldn't python3 use it's own namespace like we have for pythoneggs?

-- 
glen



From glen at pld-linux.org  Sun Jul 13 13:25:41 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Sun, 13 Jul 2014 14:25:41 +0300
Subject: [packages/php-phpunit-bytekit] - added virtual bytekit req - rel 2
In-Reply-To: <a6bc0c0255eb6575ec97db1d1de472b3f4e20d67_refs_heads_master@pld-linux.org>
References: <6450cb9d08662a51a4d9a2705724f534f0b8fe0d_refs_heads_master@pld-linux.org>
 <a6bc0c0255eb6575ec97db1d1de472b3f4e20d67_refs_heads_master@pld-linux.org>
Message-ID: <53C26CB5.5010903@pld-linux.org>

On 13/07/14 12:52, baggins wrote:
> -Requires:	php-bytekit
> +Requires:	php(bytekit)

i was wondering, should we use "php-ext" instead of "php" for such 
virtual dependencies? the way composer[1] does?

or rather pointless, not worth the effort?

[1] https://getcomposer.org/

-- 
glen



From qboosh at pld-linux.org  Sun Jul 13 22:02:22 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sun, 13 Jul 2014 22:02:22 +0200
Subject: glibc man pages
In-Reply-To: <201407122128.47709.arekm@maven.pl>
References: <201407121842.46748.arekm@maven.pl> <20140712190815.GA917@mail>
 <201407122128.47709.arekm@maven.pl>
Message-ID: <20140713200222.GA6289@mail>

On Sat, Jul 12, 2014 at 09:28:47PM +0200, Arkadiusz Mi?kiewicz wrote:
> On Saturday 12 of July 2014, Jakub Bogusz wrote:
> > On Sat, Jul 12, 2014 at 06:42:46PM +0200, Arkadiusz Mi?kiewicz wrote:
> > > Hi. There are outdated manual pages in glibc.spec:
> > > Source5:        http://qboosh.pl/man/%{name}-man-pages.tar.bz2
> > > 
> > > So the question is - do we really want them there? man-pages project have
> > > updated version, so why we don't use these pages from man-pages?
> > 
> > This tarball should be updated from latest man pages.
> > 
> > I worked on some automation scripts for updating per-package man pages
> > tarballs a few years ago, maybe it would be easy to use them for glibc
> > now...
> 
> I fail to understand why we want them in glibc.spec so badly. man-pages.spec 
> providing them is more sane to me.

To get ldconfig manuals together with ldconfig, similarly for ldd,
getconf etc. - just like in other packages.


-- 
Jakub Bogusz    http://qboosh.pl/


From arekm at maven.pl  Sun Jul 13 22:23:32 2014
From: arekm at maven.pl (Arkadiusz =?iso-8859-2?q?Mi=B6kiewicz?=)
Date: Sun, 13 Jul 2014 22:23:32 +0200
Subject: glibc man pages
In-Reply-To: <20140713200222.GA6289@mail>
References: <201407121842.46748.arekm@maven.pl>
 <201407122128.47709.arekm@maven.pl> <20140713200222.GA6289@mail>
Message-ID: <201407132223.32145.arekm@maven.pl>

On Sunday 13 of July 2014, Jakub Bogusz wrote:
> On Sat, Jul 12, 2014 at 09:28:47PM +0200, Arkadiusz Mi?kiewicz wrote:
> > On Saturday 12 of July 2014, Jakub Bogusz wrote:
> > > On Sat, Jul 12, 2014 at 06:42:46PM +0200, Arkadiusz Mi?kiewicz wrote:
> > > > Hi. There are outdated manual pages in glibc.spec:
> > > > Source5:        http://qboosh.pl/man/%{name}-man-pages.tar.bz2
> > > > 
> > > > So the question is - do we really want them there? man-pages project
> > > > have updated version, so why we don't use these pages from
> > > > man-pages?
> > > 
> > > This tarball should be updated from latest man pages.
> > > 
> > > I worked on some automation scripts for updating per-package man pages
> > > tarballs a few years ago, maybe it would be easy to use them for glibc
> > > now...
> > 
> > I fail to understand why we want them in glibc.spec so badly.
> > man-pages.spec providing them is more sane to me.
> 
> To get ldconfig manuals together with ldconfig, similarly for ldd,
> getconf etc. - just like in other packages.

This approach clearly doesn't work for section 3 man pages. So maybe keep man3 
in man-pages and keep that (mostly outdated) glibc-man-pages tarball for 
tools?

-- 
Arkadiusz Mi?kiewicz, arekm / maven.pl


From jan.palus at gmail.com  Sat Jul 26 14:24:40 2014
From: jan.palus at gmail.com (Jan Palus)
Date: Sat, 26 Jul 2014 14:24:40 +0200
Subject: Building against ffmpeg with opencl
Message-ID: <20140726122440.GA13555@cukinia>

Hi,

I'm trying to build new release of mpv against ffmpeg-2.2.5 which is now
built with opencl. Unfortunately I get undefined symbols during linking:

/usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavutil.so: undefined reference to `clReleaseMemObject at OPENCL_1.0'
/usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavutil.so: undefined reference to `clReleaseCommandQueue at OPENCL_1.0'
/usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavfilter.so: undefined reference to `clFinish at OPENCL_1.0'
/usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavutil.so: undefined reference to `clSetKernelArg at OPENCL_1.0'
/usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavfilter.so: undefined reference to `clReleaseProgram at OPENCL_1.0'
/usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavutil.so: undefined reference to `clGetPlatformInfo at OPENCL_1.0'
/usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavutil.so: undefined reference to `clEnqueueUnmapMemObject at OPENCL_1.0'
/usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavutil.so: undefined reference to `clCreateProgramWithSource at OPENCL_1.0'
...

I suppose it is somewhat connected to the fact that NVIDIA's libOpenCL
(which I have installed) does not provide versioned symbols. Any ideas
how this could be solved? Adding -lOpenCL fixes the problem but I don't
think it is a right direction.


From qboosh at pld-linux.org  Sat Jul 26 15:29:30 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sat, 26 Jul 2014 15:29:30 +0200
Subject: Building against ffmpeg with opencl
In-Reply-To: <20140726122440.GA13555@cukinia>
References: <20140726122440.GA13555@cukinia>
Message-ID: <20140726132930.GA32407@mail>

On Sat, Jul 26, 2014 at 02:24:40PM +0200, Jan Palus wrote:
> Hi,
> 
> I'm trying to build new release of mpv against ffmpeg-2.2.5 which is now
> built with opencl. Unfortunately I get undefined symbols during linking:
> 
> /usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavutil.so: undefined reference to `clReleaseMemObject at OPENCL_1.0'
> /usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavutil.so: undefined reference to `clReleaseCommandQueue at OPENCL_1.0'
> /usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavfilter.so: undefined reference to `clFinish at OPENCL_1.0'
> /usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavutil.so: undefined reference to `clSetKernelArg at OPENCL_1.0'
> /usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavfilter.so: undefined reference to `clReleaseProgram at OPENCL_1.0'
> /usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavutil.so: undefined reference to `clGetPlatformInfo at OPENCL_1.0'
> /usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavutil.so: undefined reference to `clEnqueueUnmapMemObject at OPENCL_1.0'
> /usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavutil.so: undefined reference to `clCreateProgramWithSource at OPENCL_1.0'
> ...
> 
> I suppose it is somewhat connected to the fact that NVIDIA's libOpenCL
> (which I have installed) does not provide versioned symbols. Any ideas
> how this could be solved? Adding -lOpenCL fixes the problem but I don't
> think it is a right direction.

(Side note: Mesa libOpenCL doesn't provide @OPENCL_1.0 versioning, AMD's
(fglrx) IIRC does).

Use ocl-icd libOpenCL, which redirects calls to selected target library
(every implementation should provide a file in /etc/OpenCL/vendors dir).


-- 
Jakub Bogusz    http://qboosh.pl/


From jan.palus at gmail.com  Sat Jul 26 15:48:32 2014
From: jan.palus at gmail.com (Jan Palus)
Date: Sat, 26 Jul 2014 15:48:32 +0200
Subject: Building against ffmpeg with opencl
In-Reply-To: <20140726132930.GA32407@mail>
References: <20140726122440.GA13555@cukinia>
 <20140726132930.GA32407@mail>
Message-ID: <20140726134832.GA3091@cukinia>

On 26.07.2014 15:29, Jakub Bogusz wrote:
> (Side note: Mesa libOpenCL doesn't provide @OPENCL_1.0 versioning, AMD's
> (fglrx) IIRC does).
> 
> Use ocl-icd libOpenCL, which redirects calls to selected target library
> (every implementation should provide a file in /etc/OpenCL/vendors dir).

That fixed compilation indeed thanks, but is this ocl-icd preferred solution
now?  Instead of providing custom ld.so.conf should nvidia libs require
ocl-icd-libOpenCL along with ocl-icd vendor config?

While compilation was fixed, it seems mpv is unable to start, probably
due to failed opencl initialization in ffmpeg. Any ideas?

% mpv
X server found. dri2 connection failed! 
Trying to open render node...
open("/dev/dri/renderD128", O_RDWR) failed: No such file or directory
open("/dev/dri/renderD129", O_RDWR) failed: No such file or directory
open("/dev/dri/renderD130", O_RDWR) failed: No such file or directory
open("/dev/dri/renderD131", O_RDWR) failed: No such file or directory
open("/dev/dri/renderD132", O_RDWR) failed: No such file or directory
open("/dev/dri/renderD133", O_RDWR) failed: No such file or directory
open("/dev/dri/renderD134", O_RDWR) failed: No such file or directory
open("/dev/dri/renderD135", O_RDWR) failed: No such file or directory
open("/dev/dri/renderD136", O_RDWR) failed: No such file or directory
open("/dev/dri/renderD137", O_RDWR) failed: No such file or directory
open("/dev/dri/renderD138", O_RDWR) failed: No such file or directory
open("/dev/dri/renderD139", O_RDWR) failed: No such file or directory
open("/dev/dri/renderD140", O_RDWR) failed: No such file or directory
open("/dev/dri/renderD141", O_RDWR) failed: No such file or directory
open("/dev/dri/renderD142", O_RDWR) failed: No such file or directory
open("/dev/dri/renderD143", O_RDWR) failed: No such file or directory
Trying to open directly...
/dev/dri/card0 not authenticated
open("/dev/dri/card1", O_RDWR) failed: No such file or directory
open("/dev/dri/card2", O_RDWR) failed: No such file or directory
open("/dev/dri/card3", O_RDWR) failed: No such file or directory
open("/dev/dri/card4", O_RDWR) failed: No such file or directory
open("/dev/dri/card5", O_RDWR) failed: No such file or directory
open("/dev/dri/card6", O_RDWR) failed: No such file or directory
open("/dev/dri/card7", O_RDWR) failed: No such file or directory
open("/dev/dri/card8", O_RDWR) failed: No such file or directory
open("/dev/dri/card9", O_RDWR) failed: No such file or directory
open("/dev/dri/card10", O_RDWR) failed: No such file or directory
open("/dev/dri/card11", O_RDWR) failed: No such file or directory
open("/dev/dri/card12", O_RDWR) failed: No such file or directory
open("/dev/dri/card13", O_RDWR) failed: No such file or directory
open("/dev/dri/card14", O_RDWR) failed: No such file or directory
open("/dev/dri/card15", O_RDWR) failed: No such file or directory
Device open failed



From jan.palus at gmail.com  Sat Jul 26 16:18:51 2014
From: jan.palus at gmail.com (Jan Palus)
Date: Sat, 26 Jul 2014 16:18:51 +0200
Subject: Building against ffmpeg with opencl
In-Reply-To: <20140726134832.GA3091@cukinia>
References: <20140726122440.GA13555@cukinia> <20140726132930.GA32407@mail>
 <20140726134832.GA3091@cukinia>
Message-ID: <20140726141851.GB3091@cukinia>

On 26.07.2014 15:48, Jan Palus wrote:
> On 26.07.2014 15:29, Jakub Bogusz wrote:
> > (Side note: Mesa libOpenCL doesn't provide @OPENCL_1.0 versioning, AMD's
> > (fglrx) IIRC does).
> > 
> > Use ocl-icd libOpenCL, which redirects calls to selected target library
> > (every implementation should provide a file in /etc/OpenCL/vendors dir).
> 
> That fixed compilation indeed thanks, but is this ocl-icd preferred solution
> now?  Instead of providing custom ld.so.conf should nvidia libs require
> ocl-icd-libOpenCL along with ocl-icd vendor config?
> 
> While compilation was fixed, it seems mpv is unable to start, probably
> due to failed opencl initialization in ffmpeg. Any ideas?
> 
> % mpv
> X server found. dri2 connection failed! 
> Trying to open render node...
> open("/dev/dri/renderD128", O_RDWR) failed: No such file or directory

ok found the issue with OCL_ICD_DEBUG=2 - it turned out I had beignet
package installed which provides ocl-icd vendor file. Is there any way
to choose preferred vendor instead of running into such issues when one
only wants to play a movie?


From jan.palus at gmail.com  Sat Jul 26 16:39:26 2014
From: jan.palus at gmail.com (Jan Palus)
Date: Sat, 26 Jul 2014 16:39:26 +0200
Subject: Building against ffmpeg with opencl
In-Reply-To: <20140726141851.GB3091@cukinia>
References: <20140726122440.GA13555@cukinia> <20140726132930.GA32407@mail>
 <20140726134832.GA3091@cukinia> <20140726141851.GB3091@cukinia>
Message-ID: <20140726143926.GC3091@cukinia>

On 26.07.2014 16:18, Jan Palus wrote:
> ok found the issue with OCL_ICD_DEBUG=2 - it turned out I had beignet
> package installed which provides ocl-icd vendor file. Is there any way
> to choose preferred vendor instead of running into such issues when one
> only wants to play a movie?

One more observation based on mpv build - zsh completion is built at the
end of the process by invoking newly created binary: mpv --list-options
which failed silently with beignet package installed. This in turn
created corrupted completion file. While one may argue if build process
should continue after failed invocation, the problem remains that
builders should probably be independent of all this opencl vendors. No
idea how this should be solved as I have no working knowledge about
opencl.