Hi All,
I'm a software engineer in the UK working at Citrix. I have worked on
quite a few open source projects: XenServer for my day job; in my spare
time I help maintain GVFS upstream and have worked on CPython in the
past. I also developed integration of GVFS with libnfs. Since libnfs is
not in
Haïkel wrote:
> I see no emergency, F23 package was updated this friday, and as
> *nothing is broken*,
Something is broken: the upgrade path.
I'm fed up of those upgrade path problems coming up all the time. You MUST
build your new packages for Rawhide first. It is NOT acceptable to submit a
ne
Kevin Fenzi wrote:
> * There could be some nasty issues with keeping known vulnerable/broken
> packages around. ie, foo-1.0 has a severe security bug, foo-1.1 fixes
> it. You now just need to trick someone into downgrading or directly
> installing foo-1.0 (which is in normal repos and signed
Hi,
I have attempted to contact Kaigai about doing the work to get mod_selinux into
EPEL. Sadly, he hasn't responded to me in a few months about this topic.
Would someone be able to help guide me through the process of getting this
package into EPEL? I'm happy to co-maintain it if that's what's r
On Mon, 3 Aug 2015 00:59:55 +0200, Dominik 'Rathann' Mierzejewski wrote:
> On Sunday, 02 August 2015 at 22:21, Igor Gnatenko wrote:
> > Dudes, I don't have time sometimes to report problems to bugzilla, attach
> > patches there. I just wanted to help. If you think it's useless (I don't
> > think s
On Sunday, 02 August 2015 at 22:21, Igor Gnatenko wrote:
> Dudes, I don't have time sometimes to report problems to bugzilla, attach
> patches there. I just wanted to help. If you think it's useless (I don't
> think so) -- I will not contribute at all.
It's much less useful sending patches to the
On 2 August 2015 at 22:57, Jonathan Underwood
wrote:
> On 2 August 2015 at 15:29, Marcin Haba wrote:
>> My image of configuration files is that they are files for read/write
>> purpose by design, because they enables _configure_ something
>> (application, service, single program, script...whateve
On 2 August 2015 at 15:29, Marcin Haba wrote:
> My image of configuration files is that they are files for read/write
> purpose by design, because they enables _configure_ something
> (application, service, single program, script...whatever). If they are
> dedicated only for reading then from my p
On Sun, 2 Aug 2015 16:29:06 +0200, Marcin Haba wrote:
> >> A) if a shell script can be treated as configuration file?
> >
> > Certainly. It's a cheap way to set a program's runtime configuration
> > instead of implementing a full config file loader/parser.
>
> My image of configuration files is
I spotted this problem when I was drinking beer with my friend. I wrote
this mail because it's not first time when grub is older in rawhide than in
XXX. I can't really file bugs in RHBZ while I'm not with laptop, only with
PHONE.
On Sun, Aug 2, 2015 at 7:53 PM Pierre-Yves Chibon
wrote:
> On Sun,
Dudes, I don't have time sometimes to report problems to bugzilla, attach
patches there. I just wanted to help. If you think it's useless (I don't
think so) -- I will not contribute at all.
On Sun, Aug 2, 2015 at 7:46 PM Haïkel wrote:
> +1
>
> @Igor: patches should be sent through bugzilla or by
Hi,
I see no emergency, F23 package was updated this friday, and as
*nothing is broken*,
that could have waited Peter's feedback.
Yes, this is an open source project, but we can respect other
contributors right to enjoy
their week-end peacefully.
Had it broke something, I'd have understood not wa
# Fedora Quality Assurance Meeting
# Date: 2015-08-03
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net
Greetings testers!
It's QA meeting time again!
Let's check in on Fedora 23 and also see if there's anything we need to
On Sun, Aug 02, 2015 at 12:33:39PM -0400, Josh Boyer wrote:
> On Sun, Aug 2, 2015 at 12:30 PM, Pierre-Yves Chibon
> wrote:
> > On Sun, Aug 02, 2015 at 01:26:17PM +, Igor Gnatenko wrote:
> >>Hi, Peter did bump to 0.18 in f23 to fix building on aarch64, but
> >> haven't
> >>did the sam
+1
@Igor: patches should be sent through bugzilla or by mail to package
owners, unless
you have a good reason like requests for comments or serious dispute
w/ package owners
though there are better ways.
Moreover, not contacting package maintainer won't encourage
provenpackagers to give it
a shot
On Sun, Aug 2, 2015 at 12:30 PM, Pierre-Yves Chibon wrote:
> On Sun, Aug 02, 2015 at 01:26:17PM +, Igor Gnatenko wrote:
>>Hi, Peter did bump to 0.18 in f23 to fix building on aarch64, but haven't
>>did the same for rawhide. Therefore we have older version in rawhide which
>>is not
On Sun, Aug 02, 2015 at 01:26:17PM +, Igor Gnatenko wrote:
>Hi, Peter did bump to 0.18 in f23 to fix building on aarch64, but haven't
>did the same for rawhide. Therefore we have older version in rawhide which
>is not good. Please fix it.
Hi Igor,
I have to ask the same question a
On Sun, Aug 02, 2015 at 02:39:24AM +0300, Igor Gnatenko wrote:
> Signed-off-by: Igor Gnatenko
And this is sent to devel because?
From the look of it, it belongs to the mailbox of the package maintainers or in
bugzilla, but I'm not sure I understand why sending it to devel.
Pierre
--
devel mail
On Sat, 1 Aug 2015 07:33:39 -0400
Nico Kadel-Garcia wrote:
> On Fri, Jul 31, 2015 at 3:14 PM, Richard Hughes
> wrote:
> > On 31 July 2015 at 17:27, Radek Holy wrote:
> >> One can say that the mirrors should keep the older versions
> >
> > I would completely agree. As we can't rely that packages
On 02.08.2015 14:48, Michael Schwendt wrote:
> On Sun, 2 Aug 2015 14:24:00 +0200, Marcin Haba wrote:
>
>>> The explanation is given by "rpmlint -i …".
>>>
>>
>> Hello,
>>
>> Not really. I read output from rpmlint and I am not sure if it is
>> unambiguous for shell scripts placed in /etc location.
Hi, Peter did bump to 0.18 in f23 to fix building on aarch64, but haven't
did the same for rawhide. Therefore we have older version in rawhide which
is not good. Please fix it.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of
On Sun, 2 Aug 2015 14:24:00 +0200, Marcin Haba wrote:
> > The explanation is given by "rpmlint -i …".
> >
>
> Hello,
>
> Not really. I read output from rpmlint and I am not sure if it is
> unambiguous for shell scripts placed in /etc location.
Well, it is the contents of the file that matter.
On 02.08.2015 12:34, Michael Schwendt wrote:
>> My question is: what is valid answer for this case?
>
> The explanation is given by "rpmlint -i …".
>
Hello,
Not really. I read output from rpmlint and I am not sure if it is
unambiguous for shell scripts placed in /etc location. Please look:
oss
Compose started at Sun Aug 2 07:15:03 UTC 2015
Broken deps for armhfp
--
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires
mvn(org.apache.juddi:
On Sun, 02 Aug 2015 13:54:58 +0200, Ralf Corsepius wrote:
> I still don't get it. If librpm's SONAME changes between Fedora releases,
> these libs will be call incompatible, no matter if they will be dlopen'ed or
> linked directly.
The librpm functionality in GDB is very marginal one. For normal
On 08/02/2015 09:33 AM, Jan Kratochvil wrote:
It was reworked from ordinary DT_NEEDED to this dlopen() approach because
librpm.so is (was) the only incompatible shared library dependency between
various versions of RHELs/CentOSes and Fedoras. So with dlopen()ed librpm one
can take latest Fedora
On Sun, 02 Aug 2015 12:02:08 +0200, Florian Weimer wrote:
> Isn't GDB moving to C++ soon?
C++ is in the plan but I do not know the schedule.
> This means that possibility will be lost anyway.
I think it is already lost by all the DT_NEEDED libpython versions anyway.
> If that's the only reaso
On Sun, 2 Aug 2015 08:39:28 +0200, Marcin Haba wrote:
> Hello,
>
> I am trying to make informal review following feature request:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1244353
>
> One from warnings returned by rpmlint is:
>
> ossim-data.x86_64: W: non-conffile-in-etc /etc/profile.d/o
On 08/02/2015 09:33 AM, Jan Kratochvil wrote:
> It was reworked from ordinary DT_NEEDED to this dlopen() approach because
> librpm.so is (was) the only incompatible shared library dependency between
> various versions of RHELs/CentOSes and Fedoras. So with dlopen()ed librpm one
> can take latest F
On Sun, 02 Aug 2015 10:54:17 +0200, Florian Weimer wrote:
> Why do you use dlopen for such essential system libraries? Why not link
> to them directly?
https://lists.fedoraproject.org/pipermail/devel/2015-August/213029.html
Message-ID: <20150802073308.ga15...@host1.jankratochvil.net>
--
devel ma
On 08/01/2015 09:25 PM, Jan Kratochvil wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1249325
>
> GDB requires some library libXXX.so.3 by dlopen(). Therefore it is not found
> by rpm automatic requires/provides from DT_NEEDED. Therefore one has to add
> the libXXX.so.3 by specific BuildR
On 02.08.2015 08:54, Ralf Corsepius wrote:
> On 08/02/2015 08:39 AM, Marcin Haba wrote:
>> Hello,
>>
>> I am trying to make informal review following feature request:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1244353
>>
>> One from warnings returned by rpmlint is:
>>
>> ossim-data.x86_64: W
On Sat, 01 Aug 2015 21:48:24 +0200, Igor Gnatenko wrote:
> I'd propose to add something like:
> %if %{__isa_bits} = 64
> Requires: libFOO.so.X()(64bit)
> %else
> Requires: libFOO.so.X
> %endif
Thanks, used that. __isa_bits is 32 even on s390 (sometimes called as 31-bit).
Jan Kratochvil
--
deve
On Sun, 02 Aug 2015 08:35:46 +0200, Ralf Corsepius wrote:
> On 08/01/2015 09:25 PM, Jan Kratochvil wrote:
> >(1) How to make a dependency on librpm.so.7?
> >
> >librpm.so.7 is in rpm-libs-4.12.90-3.fc24.x86_64 which --provides:
> > librpm.so.7()(64bit)
> > librpmio.so.7()(64bit)
> > rpm
34 matches
Mail list logo
