From qboosh at pld-linux.org  Wed Jan  1 02:10:50 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 1 Jan 2014 02:10:50 +0100
Subject: [packages/samba4] - all samba/vfs modules belong to samba3
 exclusively; samba4 uses different ntvfs interface
In-Reply-To: <20131231183227.GB1508@home.mimuw.edu.pl>
References: <c53812ea5d1d5379f83fcc829f6f35d7b1c040f4_refs_heads_master@pld-linux.org>
 <2948c518df0a1cdc2672a30e14a7138de4b0a5bc_refs_heads_master@pld-linux.org>
 <20131231183227.GB1508@home.mimuw.edu.pl>
Message-ID: <20140101011050.GA13988@mail>

On Tue, Dec 31, 2013 at 07:32:27PM +0100, Jan R?korajski wrote:
> On Tue, 31 Dec 2013, qboosh wrote:
> 
> > commit 2948c518df0a1cdc2672a30e14a7138de4b0a5bc
> > Author: Jakub Bogusz <qboosh at pld-linux.org>
> > Date:   Tue Dec 31 19:26:50 2013 +0100
> > 
> >     - all samba/vfs modules belong to samba3 exclusively; samba4 uses different ntvfs interface
> 
> Oh, you are so wrong. Revert this commit.
> Did you deployed this software anywhere? AD functionality will not work
> without those few vfs modules.

Uhm.
The only place where I can see reference to vfs modules is:

samba-4.1.3/source3/smbd/vfs.c:                status = smb_load_module("vfs", module_path);

which is part of libsmbd_base, referenced only in source3 directory.

What is the path of using them from samba4/AD?

If there is such, then shouldn't other vfs modules be packages as common,
not samba3-specific?


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


From baggins at pld-linux.org  Wed Jan  1 11:51:22 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Wed, 1 Jan 2014 11:51:22 +0100
Subject: [packages/samba4] - all samba/vfs modules belong to samba3
 exclusively; samba4 uses different ntvfs interface
In-Reply-To: <20140101011050.GA13988@mail>
References: <c53812ea5d1d5379f83fcc829f6f35d7b1c040f4_refs_heads_master@pld-linux.org>
 <2948c518df0a1cdc2672a30e14a7138de4b0a5bc_refs_heads_master@pld-linux.org>
 <20131231183227.GB1508@home.mimuw.edu.pl>
 <20140101011050.GA13988@mail>
Message-ID: <20140101105122.GA1499@home.mimuw.edu.pl>

On Wed, 01 Jan 2014, Jakub Bogusz wrote:

> On Tue, Dec 31, 2013 at 07:32:27PM +0100, Jan R?korajski wrote:
> > On Tue, 31 Dec 2013, qboosh wrote:
> > 
> > > commit 2948c518df0a1cdc2672a30e14a7138de4b0a5bc
> > > Author: Jakub Bogusz <qboosh at pld-linux.org>
> > > Date:   Tue Dec 31 19:26:50 2013 +0100
> > > 
> > >     - all samba/vfs modules belong to samba3 exclusively; samba4 uses different ntvfs interface
> > 
> > Oh, you are so wrong. Revert this commit.
> > Did you deployed this software anywhere? AD functionality will not work
> > without those few vfs modules.
> 
> Uhm.
> The only place where I can see reference to vfs modules is:
> 
> samba-4.1.3/source3/smbd/vfs.c:                status = smb_load_module("vfs", module_path);
> 
> which is part of libsmbd_base, referenced only in source3 directory.
> 
> What is the path of using them from samba4/AD?

Can't tell you, due to those libs being intertwined to the point of
complete mess. What I can tell that I did try the change you made and
samba told me that system lacks xattr/acl support and AD will not
function properly. Maybe something changed recently, but I'm not too
keen on lerning it the hard way.

I based samba4 packaging on debian, so check there if you want.
But whatever you do please test this package before bumping release or
sending build requests (simple `samba-tool domain provision ; service samba start`
should do the trick).

-- 
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  Wed Jan  1 13:41:33 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Wed, 1 Jan 2014 13:41:33 +0100
Subject: GRUB2 =?utf-8?B?4oCTIHNob3Vs?= =?utf-8?Q?d?= we use a recent
 snapshot?
In-Reply-To: <52C2905C.4010300@jajcus.net>
References: <52C2905C.4010300@jajcus.net>
Message-ID: <20140101124133.GA1298@home.mimuw.edu.pl>

On Tue, 31 Dec 2013, Jacek Konieczny wrote:

> Hi,
> 
> The grub 2.00 release is buggy and lacking features. And their release
> cycle is ridiculous ? 2.00 was released in June 2012, lots of fixes were
> commited to their repository, but no new release was made.
> 
> We have some patches from Fedora. I have been trying to fix bugs by
> back-porting patches from upstream, but the package in th is still
> unreliable (checked with pld-new-rescue, which relies heavily on GRUB).
> 
> Back-porting changes from upstream is less and less convenient, as
> differences between their trunk and 2.00 are now very big.
> 
> Fedora now has over 480 patches in their grub 2.00 package (some are
> upstream fixes, some are their own inventions) ? I don't think we want
> to import and maintain all of them (not even knowing what they really
> fix and what is their impact). Cherry-picking Fedora patches would be
> probably even more difficult than back-porting fixes from upstream.
> 
> Instead I took a recent snapshot from GRUB2 repository and created a
> 'DEVEL' branch for our grub2 package. I have updated only the few
> missing patches that I thought they are usefull and dropped all the rest
> (including some PXE booting improvements from Fedora). Now the grub2
> package from the DEVEL branch works significantly better for me ? PLD NR
> can now quite reliably boot via PBX (both BIOS and EFI).
> 
> I think we should switch to GRUB2 snapshot in Th.
> 
> What do you think?
> Does anybody need the patches I have dropped on the DEVEL branch?
> Can any grub2 user test the package from the DEVEL branch?

Tested on laptop and workstation, works fine after fixing sysconfig/grub.
I'd say go and merge to master.

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


From caleb at pld-linux.org  Wed Jan  1 14:40:54 2014
From: caleb at pld-linux.org (Caleb Maclennan)
Date: Wed, 1 Jan 2014 15:40:54 +0200
Subject: Th 2013 snapshot released
In-Reply-To: <20131231204606.GA9293@polis.nbtsc.org>
References: <20131231203640.GC1508@home.mimuw.edu.pl>
 <20131231204606.GA9293@polis.nbtsc.org>
Message-ID: <CAP9w9P7u-O2VtJ2jc13B9-DeABHW_ZREpNJziQ02V+2zwEiPpw@mail.gmail.com>

On Tue, Dec 31, 2013 at 10:46 PM, Aria Stewart <aredridel at nbtsc.org> wrote:

> On Tue, Dec 31, 2013 at 09:36:40PM +0100, Jan R?korajski wrote:
> > As promised I made a new snapshot of the PLD Th line.
> > See the announcment on http://www.pld-linux.org/ for details.
>
> And there was much rejoicing!
>

Excellent, keep up the good work.

Now if there was just a way to install it...

Caleb


From glen at delfi.ee  Wed Jan  1 13:15:55 2014
From: glen at delfi.ee (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Wed, 01 Jan 2014 14:15:55 +0200
Subject: Th 2013 snapshot released
In-Reply-To: <20131231203640.GC1508@home.mimuw.edu.pl>
References: <20131231203640.GC1508@home.mimuw.edu.pl>
Message-ID: <52C406FB.40101@delfi.ee>

On 31/12/13 22:36, Jan R?korajski wrote:
> As promised I made a new snapshot of the PLD Th line.
> See the announcment on http://www.pld-linux.org/ for details.
>
> Happy New Year Everyone!
hell yea


-- 
glen



From mateusz-lists at ant.gliwice.pl  Wed Jan  1 17:28:56 2014
From: mateusz-lists at ant.gliwice.pl (Mateusz Korniak)
Date: Wed, 01 Jan 2014 17:28:56 +0100
Subject: GRUB2 =?UTF-8?B?4oCT?= should we use a recent snapshot?
In-Reply-To: <20140101124133.GA1298@home.mimuw.edu.pl>
References: <52C2905C.4010300@jajcus.net>
 <20140101124133.GA1298@home.mimuw.edu.pl>
Message-ID: <7590037.ugrDmzRkQ4@matkor-toshiba>

On Wednesday 01 January 2014 13:41:33 Jan R?korajski wrote:
> On Tue, 31 Dec 2013, Jacek Konieczny wrote:
> > Can any grub2 user test the package from the DEVEL branch?
> 
> Tested on laptop and workstation, works fine after fixing sysconfig/grub.

Does remembering of last selected boot menu entry works?

-- 
Mateusz Korniak
"(...) mam brata - powa?ny, domator, liczykrupa, hipokryta, pobo?ni?,
 	kr?tko m?wi?c - podpora spo?ecze?stwa."
				Nikos Kazantzakis - "Grek Zorba"



From jajcus at jajcus.net  Wed Jan  1 18:12:03 2014
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 01 Jan 2014 18:12:03 +0100
Subject: GRUB2 =?UTF-8?B?4oCTIHNob3VsZCB3ZSB1c2UgYSByZWNlbnQgc25hcHNo?=
 =?UTF-8?B?b3Q/?=
In-Reply-To: <7590037.ugrDmzRkQ4@matkor-toshiba>
References: <52C2905C.4010300@jajcus.net>
 <20140101124133.GA1298@home.mimuw.edu.pl> <7590037.ugrDmzRkQ4@matkor-toshiba>
Message-ID: <52C44C63.8050706@jajcus.net>

On 2014-01-01 17:28, Mateusz Korniak wrote:
> On Wednesday 01 January 2014 13:41:33 Jan R?korajski wrote:
>> On Tue, 31 Dec 2013, Jacek Konieczny wrote:
>>> Can any grub2 user test the package from the DEVEL branch?
>>
>> Tested on laptop and workstation, works fine after fixing sysconfig/grub.
> 
> Does remembering of last selected boot menu entry works?

I don't use this feature. And I don't use the auto-generated grub
configs (update-grup/grub-mkconfig). That is why I wanted others to test
this before I merge it onto master.


The 'remembering of last selected boot menu' feature uses grub
environment save/load and that has several limitations ? it is available
only on some file systems (without journaling IIRC).
Upgrading/downagrading GRUB won't help much.

Greets,
    Jacek


From jajcus at jajcus.net  Wed Jan  1 18:30:48 2014
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 01 Jan 2014 18:30:48 +0100
Subject: PLD New Rescue  1.0 / Th 2013
Message-ID: <52C450C8.5090906@jajcus.net>

Hi,

I have just released a new PLD NR built, based on the fresh Th 2013
snapshot:

https://github.com/Jajcus/pld-new-rescue/releases/tag/th2013-1.0

What is new:

 ? Based on the brand new 'Th 2013' snapshot
 ? PXE boot (both legacy and EFI)
 ? built with a recent GRUB snapshot
 ? wicd network manager added
 ? shutdown fixes
 ? other minor improvements

Greets,
   Jacek


From baggins at pld-linux.org  Wed Jan  1 23:26:36 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Wed, 1 Jan 2014 23:26:36 +0100
Subject: GRUB2 =?utf-8?B?4oCTIHNob3Vs?= =?utf-8?Q?d?= we use a recent
 snapshot?
In-Reply-To: <7590037.ugrDmzRkQ4@matkor-toshiba>
References: <52C2905C.4010300@jajcus.net>
 <20140101124133.GA1298@home.mimuw.edu.pl>
 <7590037.ugrDmzRkQ4@matkor-toshiba>
Message-ID: <20140101222633.GA1336@home.mimuw.edu.pl>

On Wed, 01 Jan 2014, Mateusz Korniak wrote:

> On Wednesday 01 January 2014 13:41:33 Jan R?korajski wrote:
> > On Tue, 31 Dec 2013, Jacek Konieczny wrote:
> > > Can any grub2 user test the package from the DEVEL branch?
> > 
> > Tested on laptop and workstation, works fine after fixing sysconfig/grub.
> 
> Does remembering of last selected boot menu entry works?

Works for me.

-- 
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  Thu Jan  2 22:44:51 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Thu, 2 Jan 2014 22:44:51 +0100
Subject: Th 2013 snapshot released
In-Reply-To: <20131231203640.GC1508@home.mimuw.edu.pl>
References: <20131231203640.GC1508@home.mimuw.edu.pl>
Message-ID: <20140102214451.GB2517@home.mimuw.edu.pl>

On Tue, 31 Dec 2013, Jan R?korajski wrote:

> As promised I made a new snapshot of the PLD Th line.
> See the announcment on http://www.pld-linux.org/ for details.
> 
> Happy New Year Everyone!

Update on the release:
We had a bug in packaging system that resulted in x86_64 kernel
supporting only up to 8 CPUs. The problem is fixed and fixed kernels are
available in 2013/updates and main PLD Th ftp repo.

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


From qboosh at pld-linux.org  Sat Jan  4 18:04:12 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sat, 4 Jan 2014 18:04:12 +0100
Subject: Non-standard variables in %cmake macro
Message-ID: <20140104170412.GA26455@mail>

The following variables set in %cmake macro:

    -DINCLUDE_INSTALL_DIR:PATH=%{_includedir} \\\
    -DLIB_INSTALL_DIR:PATH=%{_libdir} \\\
    -DSHARE_INSTALL_PREFIX:PATH=%{_datadir} \\\
    -DSYSCONF_INSTALL_DIR:PATH=%{_sysconfdir} \\\

aren't standard for cmake; they appear in some examples, but are not
actually set or used by cmake distribution.

They are used in KDE4-specific cmake files, but are not standardized
globally; some packages (libgit2, to name one, and I saw at least two
more) expect passed values (if any) to be always relative (to
CMAKE_INSTALL_PREFIX); KDE4 cmake files support both absolute and
relative values.
KDE4 defaults are sane (provided CMAKE_INSTALL_PREFIX and LIB_SUFFIX
variables are passed properly) except for SYSCONF_INSTALL_DIR (which
is ${CMAKE_INSTALL_PREFIX}/etc by default).

My proposal is to remove the first three variables from %cmake macro
and pass them only in the rare cases when they are required.
I'd keep SYSCONF_INSTALL_DIR, because relative value is always wrong
with FHS.

Any better solutions?


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


From r.wobben at home.nl  Sat Jan  4 18:12:31 2014
From: r.wobben at home.nl (Roelof Wobben)
Date: Sat, 04 Jan 2014 18:12:31 +0100
Subject: Cinnamon
In-Reply-To: <52B5D41A.2060409@home.nl>
References: <52B5D41A.2060409@home.nl>
Message-ID: <52C840FF.2000908@home.nl>

Roelof Wobben schreef op 21-12-2013 18:47:
> Hello,
>
> Is there still interest in Cinnamon 2.0.
> If so, I can do the job if someone wants to mentor me because I do not 
> have any experience with rpm porting.
>
> Second question : Is there good English documentation how to keep my 
> box up-to-date ?
>
> Roelof
>


Sorry for the late respons.

Cinnamon is a Gnome 3 fork. See this link : http://cinnamon.linuxmint.com

Roelof




---
Dit e-mailbericht bevat geen virussen en malware omdat avast! Antivirus-bescherming actief is.
http://www.avast.com



From jajcus at jajcus.net  Sun Jan  5 20:31:50 2014
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Sun, 05 Jan 2014 20:31:50 +0100
Subject: configfs and systemd and dependencies
Message-ID: <52C9B326.1080707@jajcus.net>

I am preparing 'targetcli' package for the iSCSI target configuration. I
have taken the systemd service file from Fedora, which says:

[Unit]
Description=Restore LIO kernel target configuration
Requires=sys-kernel-config.mount
After=sys-kernel-config.mount network.target local-fs.target

The 'Requires' line is important, configfs should be mounted at
/sys/kernel/config. But in PLD it won't mount by default ('systemctl
start sys-kernel-config.mount' won't work), because:

# systemctl status sys-kernel-config.mount
sys-kernel-config.mount - Configuration File System
   Loaded: loaded (/lib/systemd/system/sys-kernel-config.mount; static)
   Active: inactive (dead)
           start condition failed at Sun 2014-01-05 20:15:14 CET; 21s ago
           ConditionPathExists=/sys/kernel/config was not met

/sys/kernel/config does not exists, as the 'configfs' module is not loaded.

It seems sys-kernel-config.mount expects it being loaded by
systemd-modules-load.service ? which means 'configfs' would be enabled
in {/etc,/run,/usr/lib}/modules-load.d which is not currently the case.

I wonder how to solve that right?
? remove 'ConditionPathExists=/sys/kernel/config' and use
'ExecStartPre=modprobe configfs' instead?
? put 'configfs' to modules-load.d? In what packages? Will that work
reliably without reboots?
? anything else?

Greets,
    Jacek


From jajcus at jajcus.net  Mon Jan  6 12:25:25 2014
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Mon, 06 Jan 2014 12:25:25 +0100
Subject: configfs and systemd and dependencies
In-Reply-To: <52C9B326.1080707@jajcus.net>
References: <52C9B326.1080707@jajcus.net>
Message-ID: <52CA92A5.8070009@jajcus.net>

On 2014-01-05 20:31, Jacek Konieczny wrote:
> I wonder how to solve that right?
> ? remove 'ConditionPathExists=/sys/kernel/config' and use
> 'ExecStartPre=modprobe configfs' instead?

It was a bit more complicated than that, but I have patched the systemd
units so the 'configfs' module will be loaded when needed.

Greets,
	Jacek


From baggins at pld-linux.org  Sat Jan 11 14:56:21 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 11 Jan 2014 14:56:21 +0100
Subject: Non-standard variables in %cmake macro
In-Reply-To: <20140104170412.GA26455@mail>
References: <20140104170412.GA26455@mail>
Message-ID: <20140111135621.GA1317@home.mimuw.edu.pl>

On Sat, 04 Jan 2014, Jakub Bogusz wrote:

> The following variables set in %cmake macro:
> 
>     -DINCLUDE_INSTALL_DIR:PATH=%{_includedir} \\\
>     -DLIB_INSTALL_DIR:PATH=%{_libdir} \\\
>     -DSHARE_INSTALL_PREFIX:PATH=%{_datadir} \\\
>     -DSYSCONF_INSTALL_DIR:PATH=%{_sysconfdir} \\\
> 
> aren't standard for cmake; they appear in some examples, but are not
> actually set or used by cmake distribution.
> 
> They are used in KDE4-specific cmake files, but are not standardized
> globally; some packages (libgit2, to name one, and I saw at least two
> more) expect passed values (if any) to be always relative (to
> CMAKE_INSTALL_PREFIX); KDE4 cmake files support both absolute and
> relative values.
> KDE4 defaults are sane (provided CMAKE_INSTALL_PREFIX and LIB_SUFFIX
> variables are passed properly) except for SYSCONF_INSTALL_DIR (which
> is ${CMAKE_INSTALL_PREFIX}/etc by default).
> 
> My proposal is to remove the first three variables from %cmake macro
> and pass them only in the rare cases when they are required.
> I'd keep SYSCONF_INSTALL_DIR, because relative value is always wrong
> with FHS.
> 
> Any better solutions?

Your proposal looks like a proper cleanup. Just do it, IMO.

-- 
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  Sat Jan 11 18:44:35 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Sat, 11 Jan 2014 19:44:35 +0200
Subject: /proc for docker
Message-ID: <52D18303.2010805@pld-linux.org>

hi

you may have already head about awesome docker (https://www.docker.io/), 
but you probably have never tried it.


anyway, there's some problem is that /proc gets setup in container such 
weird way that makes procps tools to complain /proc not mounted.
the problem is that pid dirs exist (ls show they exist), but are not 
accessible (chdir says ENOENT)

the problem can be reproduced with vagrant:
(wiki page: https://www.pld-linux.org/packages/lxc-docker#vagrant )

$ poldek -u vagrant
$ mkdir test; cd test
$ wget -O Vagrantfile 
https://www.pld-linux.org/_export/code/packages/lxc-docker?codeblock=3
$ vagrant up
$ vagrant ssh

with 0.7.0 and earlier, just procps tools (killall, pidof) failed, but 
with 0.7.5 it fails more miserably making even container startup to fail:

$ docker version
Client version: 0.7.0
Go version (client): go1.1.2
Git commit (client): pld-1
Server version: 0.7.0
Git commit (server): pld-1
Go version (server): go1.1.2
Last stable version: 0.7.5, please update docker

$ docker run -i -t ubuntu bash

root at e0ea0ce6904b:/# ls -l /proc
ls: cannot access /proc/1: No such file or directory
ls: cannot access /proc/10: No such file or directory
total 0
??????????  ? ?    ?                  ?            ? 1
??????????  ? ?    ?                  ?            ? 10
dr-xr-xr-x  3 root root               0 Jan 11 17:38 acpi
-r--r--r--  1 root root               0 Jan 11 17:38 buddyinfo
dr-xr-xr-x  4 root root               0 Jan 11 17:38 bus

can't even check /proc/mounts as it's symlink to current pid directory, 
which is not accessible:

root at e0ea0ce6904b:/# ls -l /proc/mounts
lrwxrwxrwx 1 root root 11 Jan 11 17:39 /proc/mounts -> self/mounts
root at e0ea0ce6904b:/# ls -l /proc/self/
ls: cannot access /proc/self/: No such file or directory
root at e0ea0ce6904b:/# ls -l /proc/self
lrwxrwxrwx 1 root root 0 Jan 11 17:37 /proc/self -> 18
root at e0ea0ce6904b:/# ls -l /proc/self/
ls: cannot access /proc/self/: No such file or directory
root at e0ea0ce6904b:/#

with newer docker can't even start container because it needs to access 
/proc/PID/status :
# poldek -s http://carme.pld-linux.org/~glen/th/x86_64/ -u lxc-docker
# service lxc-docker restart

19:41:40 vagrant[load: 0.22]@pld64 ~$ docker version
Client version: 0.7.5
Go version (client): go1.1.2
Git commit (client): pld-1
Server version: 0.7.5
Git commit (server): pld-1
Go version (server): go1.1.2
Last stable version: 0.7.5

19:41:49 vagrant[load: 0.18]@pld64 ~$ docker run -i -t ubuntu bash
2014/01/11 17:41:54 open /proc/1/status: no such file or directory
19:41:54 vagrant[load: 0.17]@pld64 ~$


-- 
glen



From jan.palus at gmail.com  Sat Jan 11 18:56:16 2014
From: jan.palus at gmail.com (Jan Palus)
Date: Sat, 11 Jan 2014 18:56:16 +0100
Subject: /proc for docker
In-Reply-To: <52D18303.2010805@pld-linux.org>
References: <52D18303.2010805@pld-linux.org>
Message-ID: <20140111175616.GA11421@cukinia>

On 11.01.2014 19:44, Elan Ruusam?e wrote:
> root at e0ea0ce6904b:/# ls -l /proc
> ls: cannot access /proc/1: No such file or directory
> ls: cannot access /proc/10: No such file or directory

Just a wild guess, but that reminds me of issues with our default mount
option for /proc -- hidepid=2.


From glen at pld-linux.org  Sat Jan 11 23:59:38 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Sun, 12 Jan 2014 00:59:38 +0200
Subject: /proc for docker
In-Reply-To: <20140111175616.GA11421@cukinia>
References: <52D18303.2010805@pld-linux.org> <20140111175616.GA11421@cukinia>
Message-ID: <52D1CCDA.8010409@pld-linux.org>

On 11/01/14 19:56, Jan Palus wrote:
> On 11.01.2014 19:44, Elan Ruusam?e wrote:
>> root at e0ea0ce6904b:/# ls -l /proc
>> ls: cannot access /proc/1: No such file or directory
>> ls: cannot access /proc/10: No such file or directory
> Just a wild guess, but that reminds me of issues with our default mount
> option for /proc -- hidepid=2.

that is not logical, as the problem is in started containers, and docker 
mounts the /proc itself

anyway, i remounted host /proc without hidepid and the problem did not 
dissapear.

-- 
glen



From glen at pld-linux.org  Sun Jan 12 13:16:46 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Sun, 12 Jan 2014 14:16:46 +0200
Subject: /proc for docker
In-Reply-To: <52D18303.2010805@pld-linux.org>
References: <52D18303.2010805@pld-linux.org>
Message-ID: <52D287AE.8000704@pld-linux.org>

On 11/01/14 19:44, Elan Ruusam?e wrote:
>
> anyway, there's some problem is that /proc gets setup in container 
> such weird way that makes procps tools to complain /proc not mounted.
> the problem is that pid dirs exist (ls show they exist), but are not 
> accessible (chdir says ENOENT)
do we even have grsec patch applied? i can't seem to find it on 3.10 branch

-- 
glen



From baggins at pld-linux.org  Sun Jan 12 13:29:56 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 12 Jan 2014 13:29:56 +0100
Subject: /proc for docker
In-Reply-To: <52D287AE.8000704@pld-linux.org>
References: <52D18303.2010805@pld-linux.org> <52D287AE.8000704@pld-linux.org>
Message-ID: <20140112122956.GB1318@home.mimuw.edu.pl>

On Sun, 12 Jan 2014, Elan Ruusam?e wrote:

> On 11/01/14 19:44, Elan Ruusam?e wrote:
> >
> > anyway, there's some problem is that /proc gets setup in container 
> > such weird way that makes procps tools to complain /proc not mounted.
> > the problem is that pid dirs exist (ls show they exist), but are not 
> > accessible (chdir says ENOENT)
> do we even have grsec patch applied? i can't seem to find it on 3.10 branch

We don't. For more than a year.

-- 
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  Wed Jan 15 20:45:38 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Wed, 15 Jan 2014 20:45:38 +0100
Subject: [RFC] Retired/dead packages in repo
Message-ID: <20140115194538.GB1286@home.mimuw.edu.pl>

Hi,
We need some form of retiring unused/dead/obsoleted packages to avoid
mistakes, duplicates or just to tell everyone "this is not the package
you are looking for". As an example lets take libcrypto++ package which
is an outdated, misnamed duplicate of cryptopp, I started updating it
recently only to realize it was a waste of time because cryptopp package
was already up to date.

My proposal is to do what Fedora does in its repo, for a retired package:
1) git delete all files in package, spec, patches, etc.
2) create "dead.package" file with explanation why it was retired (for
   example "Obsoleted by XXX" or "Renamed to YYY")
3) make package read-only to avoid grave digging

Please comment what you think about it.

-- 
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 Jan 15 21:00:18 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Wed, 15 Jan 2014 22:00:18 +0200
Subject: /proc for docker
In-Reply-To: <52D18303.2010805@pld-linux.org>
References: <52D18303.2010805@pld-linux.org>
Message-ID: <52D6E8D2.70303@pld-linux.org>

On 11/01/14 19:44, Elan Ruusam?e wrote:
> root at e0ea0ce6904b:/# ls -l /proc
> ls: cannot access /proc/1: No such file or directory
> ls: cannot access /proc/10: No such file or directory
> total 0
> ??????????  ? ?    ?                  ?            ? 1
> ??????????  ? ?    ?                  ?            ? 10
> dr-xr-xr-x  3 root root               0 Jan 11 17:38 acpi
> -r--r--r--  1 root root               0 Jan 11 17:38 buddyinfo
> dr-xr-xr-x  4 root root               0 Jan 11 17:38 bus

the problem that readdir() returns pid entries but stat() gives ENOENT 
is caused by vserver patch.
i.e disabling vserver patch would make it work back again.

i updated vserver patch to be recent, just in case 3.10.25-vs2.3.6.8, 
but the problem remained.

btw, this can be easily tested with plain lxc only:
# lxc-create -t busybox --name busybox
# lxc-start --name busybox -d
# lxc-attach busybox --name busybox ls -- -l /proc/self
ls: /proc/self: cannot read link: No such file or directory
lrwxrwxrwx    1 root     root             0 Jan 15 19:58 /proc/self



-- 
glen



From baggins at pld-linux.org  Wed Jan 15 21:06:33 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Wed, 15 Jan 2014 21:06:33 +0100
Subject: /proc for docker
In-Reply-To: <52D6E8D2.70303@pld-linux.org>
References: <52D18303.2010805@pld-linux.org>
 <52D6E8D2.70303@pld-linux.org>
Message-ID: <20140115200632.GA3635@home.mimuw.edu.pl>

On Wed, 15 Jan 2014, Elan Ruusam?e wrote:

> On 11/01/14 19:44, Elan Ruusam?e wrote:
> > root at e0ea0ce6904b:/# ls -l /proc
> > ls: cannot access /proc/1: No such file or directory
> > ls: cannot access /proc/10: No such file or directory
> > total 0
> > ??????????  ? ?    ?                  ?            ? 1
> > ??????????  ? ?    ?                  ?            ? 10
> > dr-xr-xr-x  3 root root               0 Jan 11 17:38 acpi
> > -r--r--r--  1 root root               0 Jan 11 17:38 buddyinfo
> > dr-xr-xr-x  4 root root               0 Jan 11 17:38 bus
> 
> the problem that readdir() returns pid entries but stat() gives ENOENT 
> is caused by vserver patch.
> i.e disabling vserver patch would make it work back again.
> 
> i updated vserver patch to be recent, just in case 3.10.25-vs2.3.6.8, 
> but the problem remained.
> 
> btw, this can be easily tested with plain lxc only:
> # lxc-create -t busybox --name busybox
> # lxc-start --name busybox -d
> # lxc-attach busybox --name busybox ls -- -l /proc/self
> ls: /proc/self: cannot read link: No such file or directory
> lrwxrwxrwx    1 root     root             0 Jan 15 19:58 /proc/self

Maybe try playing with vprocunhide from util-vserver?

-- 
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 Jan 15 21:11:07 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Wed, 15 Jan 2014 22:11:07 +0200
Subject: [RFC] Retired/dead packages in repo
In-Reply-To: <20140115194538.GB1286@home.mimuw.edu.pl>
References: <20140115194538.GB1286@home.mimuw.edu.pl>
Message-ID: <52D6EB5B.9030102@pld-linux.org>

On 15/01/14 21:45, Jan R?korajski wrote:
> My proposal is to do what Fedora does in its repo, for a retired package:
> 1) git delete all files in package, spec, patches, etc.
> 2) create "dead.package" file with explanation why it was retired (for
>     example "Obsoleted by XXX" or "Renamed to YYY")
> 3) make package read-only to avoid grave digging
this would apply only packages that "Were on ftp"?
we still have packages which are duplicates and need merging to one 
package, "retiring" before merge does not seem right.

what about packages that provide alternative versions, for example 
ruby.spec provides ruby-json 1.5, but ruby-json provides newer version 
that some ruby packages already require. similar situation exists with 
perl modules bundled from perl.spec.

also, qboosh has just noted in spec comments that it's obsolete, 
probably to be able to build old versions (enlightment packages)

also, should github mirror delete retired packages?

-- 
glen



From jajcus at jajcus.net  Wed Jan 15 22:04:40 2014
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 15 Jan 2014 22:04:40 +0100
Subject: [RFC] Retired/dead packages in repo
In-Reply-To: <20140115194538.GB1286@home.mimuw.edu.pl>
References: <20140115194538.GB1286@home.mimuw.edu.pl>
Message-ID: <52D6F7E8.8000805@jajcus.net>

On 2014-01-15 20:45, Jan R?korajski wrote:
> My proposal is to do what Fedora does in its repo, for a retired package:
> 1) git delete all files in package, spec, patches, etc.
> 2) create "dead.package" file with explanation why it was retired (for
>    example "Obsoleted by XXX" or "Renamed to YYY")
> 3) make package read-only to avoid grave digging

I have no idea what Fedora does, but this is what I was thinking about
too. Dummy repositories pointing to the right packages cost little and
may really help.

Greets,
	Jacek


From jajcus at jajcus.net  Wed Jan 15 22:10:07 2014
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 15 Jan 2014 22:10:07 +0100
Subject: [RFC] Retired/dead packages in repo
In-Reply-To: <52D6EB5B.9030102@pld-linux.org>
References: <20140115194538.GB1286@home.mimuw.edu.pl>
 <52D6EB5B.9030102@pld-linux.org>
Message-ID: <52D6F92F.8040508@jajcus.net>

On 2014-01-15 21:11, Elan Ruusam?e wrote:
> On 15/01/14 21:45, Jan R?korajski wrote:
>> My proposal is to do what Fedora does in its repo, for a retired package:
>> 1) git delete all files in package, spec, patches, etc.
>> 2) create "dead.package" file with explanation why it was retired (for
>>     example "Obsoleted by XXX" or "Renamed to YYY")
>> 3) make package read-only to avoid grave digging
> this would apply only packages that "Were on ftp"?

This could apply not only to packages that "were on ftp", but even to
those which were never packaged for PLD under this name, but people may
expect them there. E.g. the 'pjproject' I have recently packaged is also
known as 'pjsip'. Source package is named 'pjproject' and Asterisk
documentation refereces it as 'pjproject', but other places say 'pjsip'
keeping something  in a dummy 'pjsip' repository may prevent further
confusion.

> we still have packages which are duplicates and need merging to one
> package, "retiring" before merge does not seem right.
> 
> what about packages that provide alternative versions, for example
> ruby.spec provides ruby-json 1.5, but ruby-json provides newer version
> that some ruby packages already require. similar situation exists with
> perl modules bundled from perl.spec.

In such cases I just add a proper note at the very beginning of the spec
file. Whoever ever touches this spec should see it and take into his
consideration. And this works not only for repositories, but also for
different branches of a single package.

Greets,
	Jacek


From glen at pld-linux.org  Thu Jan 16 00:10:10 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Thu, 16 Jan 2014 01:10:10 +0200
Subject: [RFC] Retired/dead packages in repo
In-Reply-To: <52D6F7E8.8000805@jajcus.net>
References: <20140115194538.GB1286@home.mimuw.edu.pl>
 <52D6F7E8.8000805@jajcus.net>
Message-ID: <52D71552.9020205@pld-linux.org>

On 15/01/14 23:04, Jacek Konieczny wrote:
> On 2014-01-15 20:45, Jan R?korajski wrote:
>> My proposal is to do what Fedora does in its repo, for a retired package:
>> 1) git delete all files in package, spec, patches, etc.
>> 2) create "dead.package" file with explanation why it was retired (for
>>     example "Obsoleted by XXX" or "Renamed to YYY")
>> 3) make package read-only to avoid grave digging
> I have no idea what Fedora does, but this is what I was thinking about
> too. Dummy repositories pointing to the right packages cost little and
> may really help.
>
this has somehow to be linked with SPECS repo.

because i never look whether package exists, i only do ls in SPECS repo 
to find if package exists

technically speaking, i have cron that pulls SPECS repo, and cron that 
runs updatedb for that dir, and to find package i use:
$ locate -i SOMETHING | grep -i SOMETHING_MORE

-- 
glen



From mateusz-lists at ant.gliwice.pl  Mon Jan 20 11:44:59 2014
From: mateusz-lists at ant.gliwice.pl (Mateusz Korniak)
Date: Mon, 20 Jan 2014 11:44:59 +0100
Subject: GRUB2 =?UTF-8?B?4oCT?= should we use a recent snapshot?
In-Reply-To: <20140101222633.GA1336@home.mimuw.edu.pl>
References: <52C2905C.4010300@jajcus.net> <7590037.ugrDmzRkQ4@matkor-toshiba>
 <20140101222633.GA1336@home.mimuw.edu.pl>
Message-ID: <3852715.A6OVl8EsWR@matkor-toshiba>

On Wednesday 01 January 2014 23:26:36 Jan R?korajski wrote:
> > Does remembering of last selected boot menu entry works?
> 
> Works for me.

With
grub2-2.02-0.beta2.1.x86_64
grub2-platform-efi-2.02-0.beta2.1.x86_64
it started to work for me too.

-- 
Mateusz Korniak
"(...) mam brata - powa?ny, domator, liczykrupa, hipokryta, pobo?ni?,
 	kr?tko m?wi?c - podpora spo?ecze?stwa."
				Nikos Kazantzakis - "Grek Zorba"



From mike at osdn.org.ua  Tue Jan 21 00:02:19 2014
From: mike at osdn.org.ua (Michael Shigorin)
Date: Tue, 21 Jan 2014 01:02:19 +0200
Subject: GRUB2 -- should we use a recent snapshot?
In-Reply-To: <3852715.A6OVl8EsWR@matkor-toshiba>
References: <52C2905C.4010300@jajcus.net> <7590037.ugrDmzRkQ4@matkor-toshiba>
 <20140101222633.GA1336@home.mimuw.edu.pl> <3852715.A6OVl8EsWR@matkor-toshiba>
Message-ID: <20140120230219.GJ5845@osdn.org.ua>

On Mon, Jan 20, 2014 at 11:44:59AM +0100, Mateusz Korniak wrote:
> > > Does remembering of last selected boot menu entry works?
> > Works for me.
> With
> grub2-2.02-0.beta2.1.x86_64
> grub2-platform-efi-2.02-0.beta2.1.x86_64
> it started to work for me too.

Just in case, works for me with grub2-efi-2.00-alt19
(and IIRC never broke with 2.00 here in the first place).

Glad for you though :)

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


From arekm at maven.pl  Tue Jan 21 08:34:22 2014
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Tue, 21 Jan 2014 08:34:22 +0100
Subject: [packages/wxWidgets] - added gtk3 patch,
 allow to build wxGTK3 - handle sdl bcond
In-Reply-To: <d8ba414b6798df934319652e08832c200d312a48_refs_heads_master@pld-linux.org>
References: <528134dea8b488cd2ac158f025a9c93eb0b28720_refs_heads_master@pld-linux.org>
 <d8ba414b6798df934319652e08832c200d312a48_refs_heads_master@pld-linux.org>
Message-ID: <201401210834.22721.arekm@maven.pl>

On Monday 20 of January 2014, qboosh wrote:
> commit d8ba414b6798df934319652e08832c200d312a48
> Author: Jakub Bogusz <qboosh at pld-linux.org>
> Date:   Mon Jan 20 21:38:08 2014 +0100
> 
>     - added gtk3 patch, allow to build wxGTK3
>     - handle sdl bcond

Is wxGTK3 API different from wxGTK2 API?

If API is the same do we actually need both?

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


From baggins at pld-linux.org  Tue Jan 21 20:29:40 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 21 Jan 2014 20:29:40 +0100
Subject: [RFC] Retired/dead packages in repo
In-Reply-To: <52D6EB5B.9030102@pld-linux.org>
References: <20140115194538.GB1286@home.mimuw.edu.pl>
 <52D6EB5B.9030102@pld-linux.org>
Message-ID: <20140121192940.GA1466@home.mimuw.edu.pl>

On Wed, 15 Jan 2014, Elan Ruusam?e wrote:

> On 15/01/14 21:45, Jan R?korajski wrote:
> > My proposal is to do what Fedora does in its repo, for a retired package:
> > 1) git delete all files in package, spec, patches, etc.
> > 2) create "dead.package" file with explanation why it was retired (for
> >     example "Obsoleted by XXX" or "Renamed to YYY")
> > 3) make package read-only to avoid grave digging
> this would apply only packages that "Were on ftp"?

No, any package can and should be possible to be retired.

> we still have packages which are duplicates and need merging to one 
> package, "retiring" before merge does not seem right.

But, of course, retiring is a means of telling all devs that this
package is finished, dead and gone. If there is still need for the
package it stays, but it would be a good practice to NOTE such packages
as "to be retired after merging with ....".

> what about packages that provide alternative versions, for example 
> ruby.spec provides ruby-json 1.5, but ruby-json provides newer version 
> that some ruby packages already require. similar situation exists with 
> perl modules bundled from perl.spec.

This is different. Those kind of packages are still in use and usefull.

> also, qboosh has just noted in spec comments that it's obsolete, 
> probably to be able to build old versions (enlightment packages)
> 
> also, should github mirror delete retired packages?

I don't think so, there won't be that many, and removing them there will
make mirror inconsistent with source.

-- 
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 Jan 21 20:33:39 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 21 Jan 2014 20:33:39 +0100
Subject: [RFC] Retired/dead packages in repo
In-Reply-To: <52D71552.9020205@pld-linux.org>
References: <20140115194538.GB1286@home.mimuw.edu.pl>
 <52D6F7E8.8000805@jajcus.net> <52D71552.9020205@pld-linux.org>
Message-ID: <20140121193339.GB1466@home.mimuw.edu.pl>

On Thu, 16 Jan 2014, Elan Ruusam?e wrote:

> On 15/01/14 23:04, Jacek Konieczny wrote:
> > On 2014-01-15 20:45, Jan R?korajski wrote:
> >> My proposal is to do what Fedora does in its repo, for a retired package:
> >> 1) git delete all files in package, spec, patches, etc.
> >> 2) create "dead.package" file with explanation why it was retired (for
> >>     example "Obsoleted by XXX" or "Renamed to YYY")
> >> 3) make package read-only to avoid grave digging
> > I have no idea what Fedora does, but this is what I was thinking about
> > too. Dummy repositories pointing to the right packages cost little and
> > may really help.
> >
> this has somehow to be linked with SPECS repo.

I don't know how SPECS is built, but two solutions come to mind. One is
to leave things as is, meaning dead package -> no spec in SPECS, second
one is to create there dummy spec with contents of dead.package file.

> because i never look whether package exists, i only do ls in SPECS repo 
> to find if package exists
> 
> technically speaking, i have cron that pulls SPECS repo, and cron that 
> runs updatedb for that dir, and to find package i use:
> $ locate -i SOMETHING | grep -i SOMETHING_MORE


-- 
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 Jan 21 20:51:47 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 21 Jan 2014 20:51:47 +0100
Subject: [ANN] Java in Th
Message-ID: <20140121195147.GC1466@home.mimuw.edu.pl>

Hi,
I'm going to move java-sun and oracle-java packages from th-main to
obsolete. There will be one last update to oracle-java, to avoid
keeping package with lots of known security holes, but other than that I
don't see any future for those.

The rationale for the java-sun (JDK 6) removal is this quote from Oracle
web page:

> WARNING: These older versions of the JRE and JDK are provided to help
> developers debug issues in older systems. They are not updated with the
> latest security patches and are not recommended for use in production.

http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase6-419409.html

As for the oracle-java (JDK 7), the security is also a concern, but more
importantly it looks like we don't fulfill the licence:

http://www.oracle.com/technetwork/java/javase/terms/license/index.html

> (i) [...] and for the sole purpose of running, your Programs
> (ii) the Programs add significant and primary functionality to the Software
> (iii) you do not distribute additional software intended to replace any component(s) of the Software

especially the (iii) ;)

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


From qboosh at pld-linux.org  Tue Jan 21 21:40:55 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 21 Jan 2014 21:40:55 +0100
Subject: [packages/wxWidgets] - added gtk3 patch,
 allow to build wxGTK3 - handle sdl bcond
In-Reply-To: <201401210834.22721.arekm@maven.pl>
References: <528134dea8b488cd2ac158f025a9c93eb0b28720_refs_heads_master@pld-linux.org>
 <d8ba414b6798df934319652e08832c200d312a48_refs_heads_master@pld-linux.org>
 <201401210834.22721.arekm@maven.pl>
Message-ID: <20140121204055.GA4921@mail>

On Tue, Jan 21, 2014 at 08:34:22AM +0100, Arkadiusz Mi?kiewicz wrote:
> On Monday 20 of January 2014, qboosh wrote:
> > commit d8ba414b6798df934319652e08832c200d312a48
> > Author: Jakub Bogusz <qboosh at pld-linux.org>
> > Date:   Mon Jan 20 21:38:08 2014 +0100
> > 
> >     - added gtk3 patch, allow to build wxGTK3
> >     - handle sdl bcond
> 
> Is wxGTK3 API different from wxGTK2 API?

As I can see, there are some differences:

$ grep WXGTK3 -r  ../BUILD/wxWidgets-3.0.0/include/wx/
../BUILD/wxWidgets-3.0.0/include/wx/aui/tabart.h:    #if defined(__WXGTK20__) && !defined(__WXGTK3__)
../BUILD/wxWidgets-3.0.0/include/wx/defs.h:#if !defined(__WXGTK3__)
../BUILD/wxWidgets-3.0.0/include/wx/defs.h:#if defined(__WXGTK3__)
../BUILD/wxWidgets-3.0.0/include/wx/gtk/chkconf.h:#ifdef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/bitmap.h:#ifdef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/bitmap.h:#ifdef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/bitmap.h:#ifdef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/bitmap.h:#ifdef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/bitmap.h:#ifndef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/bitmap.h:#ifndef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/region.h:#ifdef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/region.h:#ifdef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/control.h:#ifdef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/colour.h:#ifdef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/colour.h:#ifdef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/colour.h:#ifdef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/setup.h://#define __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/window.h:#ifdef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/window.h:#ifdef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/window.h:#ifndef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/window.h:#ifdef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/dvrenderers.h:#ifdef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/glcanvas.h:#ifdef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/private/textmeasure.h:#ifndef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/private/gtk2-compat.h:#ifndef __WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/private/gtk2-compat.h:#endif // !__WXGTK3__
../BUILD/wxWidgets-3.0.0/include/wx/gtk/dc.h:#ifdef __WXGTK3__

and wxGTK2 is considered more mature (that's why it's still the default
version of wxGTK).


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


From mmazur at kernel.pl  Thu Jan 23 11:15:05 2014
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Thu, 23 Jan 2014 11:15:05 +0100
Subject: New distfiles dropin
Message-ID: <201401231115.05899.mmazur@kernel.pl>


   scp something.tar.gz dropin at dropin.pld-linux.org:
or/b?d?:
   scp something.tar.gz distfiles at dropin.pld-linux.org:



en_US
From now on one uses distfiles' dropin via SCP, not FTP. SSH keys are synced 
with git at git.pld-linux.org. Old FTP upload has been disabled. Nothing else 
changed. (Two accounts for upload are provided, so one does not have to 
remember which one it was.)


pl_PL
Od teraz distfilesowy dropin jest robiony po SCP, a nie po FTP. Klucze SSH s? 
brane z git at git.pld-linux.org, wi?c wszystkim powinno dzia?a?. Stary upload po 
FTP zosta? wy??czony. ?adnych innych zauwa?alnych zmian nie powinno by?. Dla 
wygody zosta?y ustawione dwa konta do upload?w, ?eby nie trzeba by?o pami?ta? 
jak si? nazywa?y.


--mmazur


From mateusz-lists at ant.gliwice.pl  Thu Jan 23 17:31:09 2014
From: mateusz-lists at ant.gliwice.pl (Mateusz Korniak)
Date: Thu, 23 Jan 2014 17:31:09 +0100
Subject: update-grub -> cat: /sys/block/mapper/vg_raid10_bitmap-root/dm/uuid:
 No such file or directory (grub2-2.02-0.beta2.1.i686)
Message-ID: <2082305.ckk1cP3cvv@matkor-toshiba>

With root FS on LVM over raid10 [1]: newest grub2 fails to me:

# update-grub                                                                                                                                                                                                                                      
/sbin/grub-mkconfig[153]: cat: /sys/block/mapper/vg_raid10_bitmap-root/dm/uuid: 
No such file or directory

It's from:

# sh -x /sbin/grub-mkconfig -o /boot/grub/grub.cfg

fails with:

+ /sbin/grub-probe '--target=device' /
+ GRUB_DEVICE=/dev/mapper/vg_raid10_bitmap-root 
+ readlink -f /dev/mapper/vg_raid10_bitmap-root
+ DM_REAL_DEVICE=/dev/mapper/vg_raid10_bitmap-root 
+ cat /sys/block/mapper/vg_raid10_bitmap-root/dm/uuid
/sbin/grub-mkconfig[153]: cat: /sys/block/mapper/vg_raid10_bitmap-root/dm/uuid: 
No such file or directory
+ DM_UUID= 


Any hints?
TIA 


[1]: mount:
/dev/mapper/vg_raid10_bitmap-root on / type ext4 
(rw,relatime,stripe=256,data=ordered)


-- 
Mateusz Korniak
"(...) mam brata - powa?ny, domator, liczykrupa, hipokryta, pobo?ni?,
 	kr?tko m?wi?c - podpora spo?ecze?stwa."
				Nikos Kazantzakis - "Grek Zorba"



From qboosh at pld-linux.org  Thu Jan 23 21:13:22 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Thu, 23 Jan 2014 21:13:22 +0100
Subject: samba-libs/libsmbclient dependency loop
Message-ID: <20140123201322.GA12308@mail>

libsmbclient Requires: samba-libs (because of libsmbclient.so.0 dependencies)
and:

rpm -qpR ../RPMS/samba-libs-4.1.4-3.i686.rpm|grep libwb
libwbclient.so.0
libwbclient.so.0(WBCLIENT_0.9)

At least these libraries from samba-libs require libwbclient.so.0:
libauth.so
libauth4.so
liblibsmb.so
libpdb.so.0
libsmbd_base.so

How to resolve it?
1) merge libsmbclient into samba-libs (overkill? current libsmbclient is 190kB,
   while samba-libs 18MB)
2) move libraries required by libsmbclient to libsmbclient package?
   (I didn't check their size)
3) any better ideas?


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


From ed at yen.ipipan.waw.pl  Fri Jan 24 08:30:01 2014
From: ed at yen.ipipan.waw.pl (=?utf-8?B?xYF1a2FzeiBNYcWba28=?=)
Date: Fri, 24 Jan 2014 08:30:01 +0100
Subject: samba-libs/libsmbclient dependency loop
In-Reply-To: <20140123201322.GA12308@mail>
References: <20140123201322.GA12308@mail>
Message-ID: <8639399.hDMxYIo5l6@laptok>

Dnia czwartek, 23 stycznia 2014 21:13:22 Jakub Bogusz pisze:
[...]
> How to resolve it?
> 1) merge libsmbclient into samba-libs (overkill? current libsmbclient is
> 190kB, while samba-libs 18MB)
> 2) move libraries required by libsmbclient to libsmbclient package?
>    (I didn't check their size)
> 3) any better ideas?

Ad.3. Etract libs common for both libsmbclient and samba-libs as a separate 
package... But I'm not convinced, if this is the best idea...
-- 
?ukasz Ma?ko                                                            _o)
Lukasz.Masko(at)ipipan.waw.pl                                           /\\
Registered Linux User #61028                                           _\_V
Ubuntu: staroafryka?skie s?owo oznaczaj?ce "Nie umiem zainstalowa? Debiana"



From glen at pld-linux.org  Fri Jan 24 10:41:42 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Fri, 24 Jan 2014 11:41:42 +0200
Subject: update-grub -> cat:
 /sys/block/mapper/vg_raid10_bitmap-root/dm/uuid:
 No such file or directory (grub2-2.02-0.beta2.1.i686)
In-Reply-To: <2082305.ckk1cP3cvv@matkor-toshiba>
References: <2082305.ckk1cP3cvv@matkor-toshiba>
Message-ID: <52E23556.60301@pld-linux.org>

On 23.01.2014 18:31, Mateusz Korniak wrote:
>
> Any hints?
>   
this is fixed and package is sent to builders.

-- 
glen



From mike at osdn.org.ua  Fri Jan 24 12:30:09 2014
From: mike at osdn.org.ua (Michael Shigorin)
Date: Fri, 24 Jan 2014 13:30:09 +0200
Subject: New distfiles dropin
In-Reply-To: <201401231115.05899.mmazur@kernel.pl>
References: <201401231115.05899.mmazur@kernel.pl>
Message-ID: <20140124113009.GG6310@osdn.org.ua>

On Thu, Jan 23, 2014 at 11:15:05AM +0100, Mariusz Mazur wrote:
> From now on one uses distfiles' dropin via SCP, not FTP. SSH
> keys are synced with git at git.pld-linux.org. Old FTP upload has
> been disabled.

Just in case you choose to tighen things up a bit more by
only allowing rsync transport before it's a separate change: 
http://ftp.altlinux.org/pub/people/ldv/rshell/in_rsync.c
(there were issues with scp, at least back then; ask ldv@
altlinux.org if interested).

Useful for resuming uploads as well.

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


From mateusz-lists at ant.gliwice.pl  Fri Jan 24 13:56:16 2014
From: mateusz-lists at ant.gliwice.pl (Mateusz Korniak)
Date: Fri, 24 Jan 2014 13:56:16 +0100
Subject: update-grub -> cat:
 /sys/block/mapper/vg_raid10_bitmap-root/dm/uuid: No such file or directory
 (grub2-2.02-0.beta2.1.i686)
In-Reply-To: <52E23556.60301@pld-linux.org>
References: <2082305.ckk1cP3cvv@matkor-toshiba> <52E23556.60301@pld-linux.org>
Message-ID: <1585692.A7M7Okrqbu@matkor-toshiba>

On Friday 24 January 2014 11:41:42 Elan Ruusam?e wrote:
> On 23.01.2014 18:31, Mateusz Korniak wrote:
> > Any hints?
> 
> this is fixed and package is sent to builders.

Right!
grub2-2.02-0.beta2.2.i686 from works perfectly for me now.

Big thanks for fixing this, regards,

-- 
Mateusz Korniak
"(...) mam brata - powa?ny, domator, liczykrupa, hipokryta, pobo?ni?,
 	kr?tko m?wi?c - podpora spo?ecze?stwa."
				Nikos Kazantzakis - "Grek Zorba"



From baggins at pld-linux.org  Fri Jan 24 18:52:24 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Fri, 24 Jan 2014 18:52:24 +0100
Subject: samba-libs/libsmbclient dependency loop
In-Reply-To: <20140123201322.GA12308@mail>
References: <20140123201322.GA12308@mail>
Message-ID: <20140124175224.GA1304@home.mimuw.edu.pl>

On Thu, 23 Jan 2014, Jakub Bogusz wrote:

> libsmbclient Requires: samba-libs (because of libsmbclient.so.0 dependencies)
> and:
> 
> rpm -qpR ../RPMS/samba-libs-4.1.4-3.i686.rpm|grep libwb
> libwbclient.so.0
> libwbclient.so.0(WBCLIENT_0.9)
> 
> At least these libraries from samba-libs require libwbclient.so.0:
> libauth.so
> libauth4.so
> liblibsmb.so
> libpdb.so.0
> libsmbd_base.so
> 
> How to resolve it?

Do we have to? This package is a RPITA, all the interdependencies are
really hard to resolve.

> 1) merge libsmbclient into samba-libs (overkill? current libsmbclient is 190kB,
>    while samba-libs 18MB)
> 2) move libraries required by libsmbclient to libsmbclient package?
>    (I didn't check their size)

10MB on x66-64, i.e. half of samba-libs.

> 3) any better ideas?

Let's just leave it as it is, maybe somewhere in future it clears itself.
The current split is more informational than dep-functional, and done
to keep compatibility with samba 3.x package set. if we really
tried to remove all loops there we'd end up merging -libs, -common,
python- and libsmbclient (at least) into one gigantic mess.

-- 
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  Fri Jan 24 21:44:17 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Fri, 24 Jan 2014 21:44:17 +0100
Subject: [packages/asterisk] Note about the ASTERISK_12 branch
In-Reply-To: <b9799345287553d52115e094d0d2a95693a0fb89_refs_heads_master@pld-linux.org>
References: <0195c89be8a898ff298d5b17cc9c125f77daa8bd_refs_heads_master@pld-linux.org>
 <b9799345287553d52115e094d0d2a95693a0fb89_refs_heads_master@pld-linux.org>
Message-ID: <20140124204417.GB1304@home.mimuw.edu.pl>

Hi,
Can you marege it to master? What we have in Th (10.0.1) is from
November 2012 and what we have on master (10.12.2) does not build.
IMO there is no point in waiting, especially if it works.

On Wed, 08 Jan 2014, jajcus wrote:

> commit b9799345287553d52115e094d0d2a95693a0fb89
> Author: Jacek Konieczny <j.konieczny at eggsoft.pl>
> Date:   Wed Jan 8 16:07:39 2014 +0100
> 
>     Note about the ASTERISK_12 branch
>     
>     In case someone misses it
> 
>  asterisk.spec | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> ---
> diff --git a/asterisk.spec b/asterisk.spec
> index 0e5d390..ecc94b1 100644
> --- a/asterisk.spec
> +++ b/asterisk.spec
> @@ -1,3 +1,10 @@
> +
> +# NOTE:
> +#  There is Asterisk 12 avaiable at the ASTERISK_12 branch, but it is not clear
> +#  we are ready for it now.
> +#  The ASTERISK_12 spec file is also cleaned up a lot, so think twice before
> +#  making big changes here.
> +
>  # TODO:
>  # - cgi-bin package - separate, because of suid-root
>  # - use shared versions of LIBILBC:=ilbc/libilbc.a (ilbc not enabled currently)
> @@ -20,7 +27,7 @@
>  # - app_{rx,tx}fax seems to b replaced by app_fax alongside latest spanddsp
>  #   See: http://sourceforge.net/projects/agx-ast-addons/
>  #        https://agx-ast-addons.svn.sourceforge.net/svnroot/agx-ast-addons/trunk/attic/
> -#
> +
>  # Conditional build:
>  %bcond_with	rxfax		# without rx (also tx:-D) fax
>  %bcond_with	zhone		# zhone hack
> ================================================================
> 
> ---- gitweb:
> 
> http://git.pld-linux.org/gitweb.cgi/packages/asterisk.git/commitdiff/b9799345287553d52115e094d0d2a95693a0fb89
> 
> _______________________________________________
> 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                                         | http://www.pld-linux.org/
baggins<at>mimuw.edu.pl
baggins<at>pld-linux.org


From jajcus at jajcus.net  Fri Jan 24 22:14:44 2014
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Fri, 24 Jan 2014 22:14:44 +0100
Subject: [packages/asterisk] Note about the ASTERISK_12 branch
In-Reply-To: <20140124204417.GB1304@home.mimuw.edu.pl>
References: <0195c89be8a898ff298d5b17cc9c125f77daa8bd_refs_heads_master@pld-linux.org>
 <b9799345287553d52115e094d0d2a95693a0fb89_refs_heads_master@pld-linux.org>
 <20140124204417.GB1304@home.mimuw.edu.pl>
Message-ID: <52E2D7C4.8060207@jajcus.net>

On 2014-01-24 21:44, Jan R?korajski wrote:
> Hi,
> Can you marege it to master? What we have in Th (10.0.1) is from
> November 2012 and what we have on master (10.12.2) does not build.
> IMO there is no point in waiting, especially if it works.

It will take months before I really test this in production ? I am not
sure how would it work for someone using Asterisk 10 from PLD (we
currently use Asterisk 1.8).

Before merging on master I would like to see opinion of anybody using
the asterisk package.

On the other hand? if the current master doesn't build and the package
on FTP is so old? then probably no one cares anyway.

If no one protest I can merge it this weekend or in two weeks.

Greets,
	Jacek


From caleb at pld-linux.org  Fri Jan 24 23:13:04 2014
From: caleb at pld-linux.org (Caleb Maclennan)
Date: Sat, 25 Jan 2014 00:13:04 +0200
Subject: [packages/asterisk] Note about the ASTERISK_12 branch
In-Reply-To: <52E2D7C4.8060207@jajcus.net>
References: <0195c89be8a898ff298d5b17cc9c125f77daa8bd_refs_heads_master@pld-linux.org>
 <b9799345287553d52115e094d0d2a95693a0fb89_refs_heads_master@pld-linux.org>
 <20140124204417.GB1304@home.mimuw.edu.pl> <52E2D7C4.8060207@jajcus.net>
Message-ID: <CAP9w9P5_K+zVOJJ8LmQzZ8sJLfLoNAL6+HfF7E6Hp3jUPNkkfQ@mail.gmail.com>

On Fri, Jan 24, 2014 at 11:14 PM, Jacek Konieczny <jajcus at jajcus.net> wrote:

> Before merging on master I would like to see opinion of anybody using
> the asterisk package.
>

I am using the 1.8 packages in production but the boxes are EOLed and I'm
in the process of migrating the services, so I don't plan on upgrading it
even if they hit TH. Sorry I won't be much help testing Asterisk on PLD.


From mike at osdn.org.ua  Fri Jan 24 23:53:39 2014
From: mike at osdn.org.ua (Michael Shigorin)
Date: Sat, 25 Jan 2014 00:53:39 +0200
Subject: [packages/asterisk] Note about the ASTERISK_12 branch
In-Reply-To: <52E2D7C4.8060207@jajcus.net>
References: <0195c89be8a898ff298d5b17cc9c125f77daa8bd_refs_heads_master@pld-linux.org>
 <b9799345287553d52115e094d0d2a95693a0fb89_refs_heads_master@pld-linux.org>
 <20140124204417.GB1304@home.mimuw.edu.pl> <52E2D7C4.8060207@jajcus.net>
Message-ID: <20140124225338.GJ6310@osdn.org.ua>

On Fri, Jan 24, 2014 at 10:14:44PM +0100, Jacek Konieczny wrote:
> > Can you marege it to master? What we have in Th (10.0.1) is from
> > November 2012 and what we have on master (10.12.2) does not build.
> > IMO there is no point in waiting, especially if it works.
> It will take months before I really test this in production --
> I am not sure how would it work for someone using Asterisk 10
> from PLD (we currently use Asterisk 1.8).

Erm, sorry for being annoying probably but ALT's * maintainer is
also actively using it and patching at times, maybe there's some
sense in cooperation to that end:

http://packages.altlinux.org/en/search?query=asterisk

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


From glen at pld-linux.org  Sat Jan 25 00:33:57 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Sat, 25 Jan 2014 01:33:57 +0200
Subject: New distfiles dropin
In-Reply-To: <201401231115.05899.mmazur@kernel.pl>
References: <201401231115.05899.mmazur@kernel.pl>
Message-ID: <52E2F865.2080301@pld-linux.org>

On 23.01.2014 12:15, Mariusz Mazur wrote:
>     scp something.tar.gz dropin at dropin.pld-linux.org:
> or/b?d?:
>     scp something.tar.gz distfiles at dropin.pld-linux.org:
>
>
>
> en_US
>  From now on one uses distfiles' dropin via SCP, not FTP. SSH keys are synced
> with git at git.pld-linux.org. Old FTP upload has been disabled. Nothing else
> changed. (Two accounts for upload are provided, so one does not have to
> remember which one it was.)

you broke automation by shutting down old service and provide no time to 
migrate scripts

dropin scipt is broken now
http://git.pld-linux.org/?p=packages/rpm-build-tools.git;a=blob;f=dropin

-- 
glen



From qboosh at pld-linux.org  Mon Jan 27 18:46:37 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Mon, 27 Jan 2014 18:46:37 +0100
Subject: Non-standard variables in %cmake macro
In-Reply-To: <20140111135621.GA1317@home.mimuw.edu.pl>
References: <20140104170412.GA26455@mail>
 <20140111135621.GA1317@home.mimuw.edu.pl>
Message-ID: <20140127174637.GA12846@stranger.qboosh.pl>

On Sat, Jan 11, 2014 at 02:56:21PM +0100, Jan R?korajski wrote:
> On Sat, 04 Jan 2014, Jakub Bogusz wrote:
> 
> > The following variables set in %cmake macro:
> > 
> >     -DINCLUDE_INSTALL_DIR:PATH=%{_includedir} \\\
> >     -DLIB_INSTALL_DIR:PATH=%{_libdir} \\\
> >     -DSHARE_INSTALL_PREFIX:PATH=%{_datadir} \\\
> >     -DSYSCONF_INSTALL_DIR:PATH=%{_sysconfdir} \\\
> > 
> > aren't standard for cmake; they appear in some examples, but are not
> > actually set or used by cmake distribution.
> > 
> > They are used in KDE4-specific cmake files, but are not standardized
> > globally; some packages (libgit2, to name one, and I saw at least two
> > more) expect passed values (if any) to be always relative (to
> > CMAKE_INSTALL_PREFIX); KDE4 cmake files support both absolute and
> > relative values.
> > KDE4 defaults are sane (provided CMAKE_INSTALL_PREFIX and LIB_SUFFIX
> > variables are passed properly) except for SYSCONF_INSTALL_DIR (which
> > is ${CMAKE_INSTALL_PREFIX}/etc by default).
> > 
> > My proposal is to remove the first three variables from %cmake macro
> > and pass them only in the rare cases when they are required.
> > I'd keep SYSCONF_INSTALL_DIR, because relative value is always wrong
> > with FHS.
> > 
> > Any better solutions?
> 
> Your proposal looks like a proper cleanup. Just do it, IMO.

Done in 1.684.


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


From qboosh at pld-linux.org  Mon Jan 27 19:00:49 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Mon, 27 Jan 2014 19:00:49 +0100
Subject: qt5-qtbase libraries packaging
In-Reply-To: <loom.20131229T130359-318@post.gmane.org>
References: <20131228173532.1918.79304@pld-linux.org>
 <51df396b833ac28442462aedcf270608217142c8_refs_heads_master@pld-linux.org>
 <20131228195423.GA7719@mail>
 <loom.20131229T130359-318@post.gmane.org>
Message-ID: <20140127180049.GB12846@stranger.qboosh.pl>

On Sun, Dec 29, 2013 at 12:22:45PM +0000, Witold Filipczyk wrote:
> Jakub Bogusz <qboosh <at> pld-linux.org> writes:
> 
> > 
> > How to split it?
> > One big package is too big e.g. for non-GUI apps.
> > 
> > RH/Fedora uses base and -gui.
> > Rosa (Mandriva?) uses libqt5core etc.
> > 
> > In qt4 we used QtModule convention - should we follow it, using Qt5Module
> > packages?
> > 
> > Alternatives are:
> > libQt5Module
> > qt5-Qt5Module
> > qt5-libQt5Module
> > 
> > I think that Qt5Module convention is the most simple and consistent with
> > our qt4 packages.
> 
> The question is:
> to split or not to split?
> 35MB is big or not?

After separation of qmake (4 MB) and other devel tools (5 MB) it's (for x86):
21MB for base runtime
19MB for devel

Qt5Core is ~4MB, Qt5Network ~1MB, Qt5DBus ~0.5MB, Qt5Sql 0.2MB
(+modules, not required for development), Qt5Test 0.1MB, Qt5Xml 0.2MB
- total ~30% of base package.
The rest is GUI (having also more dependencies), so I'd split.

> If split, then every single library in separate package.
> It will be easier to package this way. But what with plugins?
> 
> If split, then split other qt5-libraries.
> IMO: Naming convention: specs like in Fedora qt5-qtbase.spec, qt5-
> qtxmlpatterns.spec, etc.
> Package names like: Qt5Xml , Qt5Xml-devel, qt5-qtbase-doc, qt5-qtbase-
> examples. Libraries like in qt4, docs and examples take names from specs.

Agreed.


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


From baggins at pld-linux.org  Tue Jan 28 19:54:23 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 28 Jan 2014 19:54:23 +0100
Subject: [packages/dietlibc] - added dynamic patch, now builds with dynamic
In-Reply-To: <7e2c13899f156ecac4d7f89211b5c2b515c6148d_refs_heads_master@pld-linux.org>
References: <c2b5ba7b08ac12de55d3db1043c82f4fd0cbcabb_refs_heads_master@pld-linux.org>
 <7e2c13899f156ecac4d7f89211b5c2b515c6148d_refs_heads_master@pld-linux.org>
Message-ID: <20140128185423.GA1317@home.mimuw.edu.pl>

On Tue, 28 Jan 2014, qboosh wrote:

> commit 7e2c13899f156ecac4d7f89211b5c2b515c6148d
> Author: Jakub Bogusz <qboosh at pld-linux.org>
> Date:   Tue Jan 28 19:51:39 2014 +0100
> 
>     - added dynamic patch, now builds with dynamic
> 
>  dietlibc-dynamic.patch | 25 +++++++++++++++++++++++++
>  dietlibc.spec          |  8 ++++----
>  2 files changed, 29 insertions(+), 4 deletions(-)

It still doesn't. At least on x8664.

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


From qboosh at pld-linux.org  Tue Jan 28 21:41:31 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 28 Jan 2014 21:41:31 +0100
Subject: [packages/dietlibc] - added dynamic patch, now builds with dynamic
In-Reply-To: <20140128185423.GA1317@home.mimuw.edu.pl>
References: <c2b5ba7b08ac12de55d3db1043c82f4fd0cbcabb_refs_heads_master@pld-linux.org>
 <7e2c13899f156ecac4d7f89211b5c2b515c6148d_refs_heads_master@pld-linux.org>
 <20140128185423.GA1317@home.mimuw.edu.pl>
Message-ID: <20140128204131.GA4807@mail>

On Tue, Jan 28, 2014 at 07:54:23PM +0100, Jan R?korajski wrote:
> On Tue, 28 Jan 2014, qboosh wrote:
> 
> > commit 7e2c13899f156ecac4d7f89211b5c2b515c6148d
> > Author: Jakub Bogusz <qboosh at pld-linux.org>
> > Date:   Tue Jan 28 19:51:39 2014 +0100
> > 
> >     - added dynamic patch, now builds with dynamic
> > 
> >  dietlibc-dynamic.patch | 25 +++++++++++++++++++++++++
> >  dietlibc.spec          |  8 ++++----
> >  2 files changed, 29 insertions(+), 4 deletions(-)
> 
> It still doesn't. At least on x8664.

Ehh, tested just on i686 first.
Should build now on both x86/x86_64.


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


From glen at delfi.ee  Fri Jan 31 12:56:03 2014
From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Fri, 31 Jan 2014 13:56:03 +0200
Subject: cronie: PAM ERROR: User account has expired
Message-ID: <52EB8F53.1050504@delfi.ee>

our triggers and restart's still can't fix the disaster of broken cron 
service!
...at least on ac nodes

----

another machine where cron fails with account expired... solved by crond 
restart:


13:43:17 root[load: 0.26]@smtp /etc# service crond status
crond (pid 4600) is running...

13:46:37 root[load: 0.17]@smtp /etc# tail /var/log/cron
Jan 31 13:37:01 smtp /usr/sbin/crond[5164]: PAM ERROR: User account has 
expired
Jan 31 13:38:01 smtp /usr/sbin/crond[5219]: PAM ERROR: User account has 
expired
Jan 31 13:39:01 smtp /usr/sbin/crond[5277]: PAM ERROR: User account has 
expired
Jan 31 13:40:01 smtp /usr/sbin/crond[5317]: PAM ERROR: User account has 
expired
Jan 31 13:41:01 smtp /usr/sbin/crond[5429]: PAM ERROR: User account has 
expired
Jan 31 13:42:01 smtp /usr/sbin/crond[5832]: PAM ERROR: User account has 
expired
Jan 31 13:43:01 smtp /usr/sbin/crond[5876]: PAM ERROR: User account has 
expired
Jan 31 13:43:13 smtp crontab[6236]: (root) LIST (root)
Jan 31 13:44:01 smtp /usr/sbin/crond[6365]: PAM ERROR: User account has 
expired
Jan 31 13:44:01 smtp /usr/sbin/crond[4600]: (system_u) RELOAD 
(/etc/cron.d/chef-client)

13:46:40 root[load: 0.17]@smtp /etc# service crond restart

good news is that service crond restart "fixed" it :

Jan 31 13:48:01 smtp /usr/sbin/crond[7006]: (*system*) RELOAD 
(/etc/cron.d/chef-client)
Jan 31 13:48:01 smtp /USR/SBIN/CROND[7143]: (root) CMD 
(LC_ALL=en_US.utf8 /usr/bin/chef-client)


cron probably broken since cronie upgrade:

  13:51:49 root[load: 0.08]@smtp /etc# pkgbytime |grep glibc
Thu Jun 14 16:59:17 2012 glibc64-2.3.6-20.amd64
Thu Jun 14 16:59:20 2012 glibc-misc-2.3.6-20.amd64
Mon Jan 13 14:41:27 2014 glibc-localedb-delfi-1.11-1 at 2.3.6.amd64

13:55:07 root[load: 0.19]@smtp /etc# pkgbytime pam
Wed Jun 10 04:42:09 2009 pam-0.80.1-19.amd64
Wed Jun 10 04:42:09 2009 pam-libs-0.80.1-19.amd64
Thu Jun 21 09:15:56 2012 pam-pam_ldap-183-1.amd64

13:51:55 root[load: 0.07]@smtp /etc# pkgbytime |grep cron
Mon Jan 13 14:41:01 2014 cronie-1.4.8-18.amd64

yep, cron.log confirms this:

Jan 13 10:01:01 smtp /usr/sbin/crond[18476]: (root) CMD (/bin/run-parts 
/etc/cron.hourly)
Jan 13 11:01:01 smtp /usr/sbin/crond[23334]: (root) CMD (/bin/run-parts 
/etc/cron.hourly)
Jan 13 12:01:01 smtp /usr/sbin/crond[29047]: (root) CMD (/bin/run-parts 
/etc/cron.hourly)
Jan 13 13:01:01 smtp /usr/sbin/crond[3504]: (root) CMD (/bin/run-parts 
/etc/cron.hourly)
Jan 13 14:01:01 smtp /usr/sbin/crond[8584]: (root) CMD (/bin/run-parts 
/etc/cron.hourly)
Jan 13 14:41:04 smtp crontab[12667]: (root) LIST (root)
Jan 13 14:41:20 smtp crontab[13158]: (root) LIST (root)
Jan 13 14:42:01 smtp /usr/sbin/crond[4600]: (system_u) RELOAD 
(/etc/cron.d/crontab)
Jan 13 15:01:01 smtp /usr/sbin/crond[15536]: PAM ERROR: User account has 
expired
Jan 13 15:24:01 smtp /usr/sbin/crond[16620]: PAM ERROR: User account has 
expired
Jan 13 16:01:01 smtp /usr/sbin/crond[20953]: PAM ERROR: User account has 
expired
Jan 13 16:24:01 smtp /usr/sbin/crond[22369]: PAM ERROR: User account has 
expired
Jan 13 17:01:01 smtp /usr/sbin/crond[26352]: PAM ERROR: User account has 
expired
Jan 13 17:24:01 smtp /usr/sbin/crond[27546]: PAM ERROR: User account has 
expired
Jan 13 17:32:33 smtp crontab[29068]: (root) LIST (root)
Jan 13 18:01:01 smtp /usr/sbin/crond[32141]: PAM ERROR: User account has 
expired
Jan 13 18:24:01 smtp /usr/sbin/crond[985]: PAM ERROR: User account has 
expired
Jan 13 19:01:01 smtp /usr/sbin/crond[4421]: PAM ERROR: User account has 
expired
Jan 13 19:24:01 smtp /usr/sbin/crond[5593]: PAM ERROR: User account has 
expired
Jan 13 20:01:01 smtp /usr/sbin/crond[8870]: PAM ERROR: User account has 
expired
Jan 13 20:24:01 smtp /usr/sbin/crond[10058]: PAM ERROR: User account has 
expired
Jan 13 21:01:01 smtp /usr/sbin/crond[13387]: PAM ERROR: User account has 
expired
Jan 13 21:24:01 smtp /usr/sbin/crond[14283]: PAM ERROR: User account has 
expired
Jan 13 22:01:01 smtp /usr/sbin/crond[17441]: PAM ERROR: User account has 
expired


-- 
glen



From baggins at pld-linux.org  Fri Jan 31 14:25:32 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Fri, 31 Jan 2014 14:25:32 +0100
Subject: [ANN] New Kernel packages set
Message-ID: <20140131132532.GF26769@sith.mimuw.edu.pl>

Hi,
Because of some seemingly unfixable problems reported for 3.10, I
decided to stay with 3.4.x line as longterm kernel for Th.

But more important changes will apply to main kernel package, we are
currently 3 releases behind because of slow updates of the Linux-Vserver
patch. So there will be an additional package set - kernel-vserver which
will be the latest mainline kernel supported by vserver community
(currently it's 3.10.x). This means that main kernel packages WILL NOT
HAVE VSERVER SUPPORT!

To sum it up:
- kernel-longterm - 3.4.x as long as maintained upstream
- kernel-vserver - latest upstream supported by Linux-Vserver
- kernel - mainline, without Vserver

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


From slsiwek at gmail.com  Fri Jan 24 21:18:07 2014
From: slsiwek at gmail.com (Szymon Siwek)
Date: Fri, 24 Jan 2014 21:18:07 +0100
Subject: update-grub -> cat:
 /sys/block/mapper/vg_raid10_bitmap-root/dm/uuid: No such file or directory
 (grub2-2.02-0.beta2.1.i686)
In-Reply-To: <1585692.A7M7Okrqbu@matkor-toshiba>
References: <2082305.ckk1cP3cvv@matkor-toshiba> <52E23556.60301@pld-linux.org>
 <1585692.A7M7Okrqbu@matkor-toshiba>
Message-ID: <20140124201807.GA27136@szydlo>

On Fri, Jan 24, 2014 at 01:56:16PM +0100, Mateusz Korniak wrote:
> On Friday 24 January 2014 11:41:42 Elan Ruusam?e wrote:
> > On 23.01.2014 18:31, Mateusz Korniak wrote:
> > > Any hints?
> > 
> > this is fixed and package is sent to builders.
> 
> Right!
> grub2-2.02-0.beta2.2.i686 from works perfectly for me now.
> 
> Big thanks for fixing this, regards,
> 
Yeap

-- 
Szymon Siwek