Hi,
there's been some work in progress already:
https://bugzilla.redhat.com/show_bug.cgi?id=850896
Proof-of-concept code (to be merged into dnf/createrepo_c in the future):
https://github.com/Tojaj/DeltaRepo
The idea behind that is simple:
* create deltas as small repos on server
* download del
On 13.02.2015 08:11, Casey Jao wrote:
> How feasible would it be to keep the listings in primary.xml and
> filelists.xml sorted by package name and arch? Doing so could open the door
> to simple and efficient diffs of repository metadata.
Something like pdiffs in Debian?
> Those two are by far th
Hi,
I just released mock-1.2.7. It have - beside one small bug and new F22
configs - one important change.
The rawhide configs have this one line included:
config_opts['package_manager'] = 'dnf'
which means that Mock will use DNF for building packages for rawhide
targets. There are two conse
> How feasible would it be to keep the listings in primary.xml and
> filelists.xml sorted by package name and arch? Doing so could open the door
> to simple and efficient diffs of repository metadata.
Createrepo_c [1] keeps packages sorted by filename [2] by default.
Sorting based on filenames was
Dne 13.2.2015 v 09:21 Marcin Juszkiewicz napsal(a):
On 13.02.2015 08:11, Casey Jao wrote:
How feasible would it be to keep the listings in primary.xml and
filelists.xml sorted by package name and arch? Doing so could open the door
to simple and efficient diffs of repository metadata.
Something
Hi,
On 12-02-15 19:32, Stephen Gallagher wrote:
(Logistical note: please keep all replies to this thread on
devel@lists.fedoraproject.org)
tl;dr Shall we consider requiring a lesser package review for packages
that are not present on Product or Spin install media?
== Premise ==
So, some time
On 02/12/2015 07:32 PM, Stephen Gallagher wrote:
(Logistical note: please keep all replies to this thread on
devel@lists.fedoraproject.org)
tl;dr Shall we consider requiring a lesser package review for packages
that are not present on Product or Spin install media?
== Premise ==
So, some time
On Fri, Feb 13, 2015 at 09:35:30AM +0100, Miroslav Suchy wrote:
> Hi,
> I just released mock-1.2.7. It have - beside one small bug and new F22
> configs - one important change.
>
> The rawhide configs have this one line included:
> config_opts['package_manager'] = 'dnf'
> which means that Mock w
On 2015-02-12, Paul Howarth wrote:
> We generally have requires for most optional functionality in Perl
> packages at the moment, to avoid bugs being raised about missing
> dependencies when people try to use that optional functionality.
>
> If there was consensus about use of soft dependencies, t
On Fri Feb 13 2015 at 2:02:27 AM Colin Walters wrote:
> On Thu, Feb 12, 2015, at 01:32 PM, Stephen Gallagher wrote:
>
> > tl;dr Shall we consider requiring a lesser package review for packages
> > that are not present on Product or Spin install media?
>
> It's worth noting here that having two le
On 13.2.2015 02:11, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Feb 12, 2015 at 01:32:04PM -0500, Stephen Gallagher wrote:
>> (Logistical note: please keep all replies to this thread on
>> devel@lists.fedoraproject.org)
>>
>> tl;dr Shall we consider requiring a lesser package review for packages
>
On Friday, February 13, 2015, Pierre-Yves Chibon
wrote:
> On Fri, Feb 13, 2015 at 09:35:30AM +0100, Miroslav Suchy wrote:
> RHEL/EPEL users do not have DNF available, therefore they are unable to
> > build packages for Fedora Rawhide. There is however a workaround. Just
> > change this line:
> >
* Paul Howarth [12/02/2015 20:05] :
>
> We generally have requires for most optional functionality in Perl
> packages at the moment, to avoid bugs being raised about missing
> dependencies when people try to use that optional functionality.
Based on past emails, I suspect that Colin wishes nothing
On 02/12/2015 08:51 PM, Marcin Juszkiewicz wrote:
> I plan to make something like Ubuntu has [2] which was great help when I
> was working on fixing packages while working for Canonical.
With Michael Simacek we are working on Koschei [1,2] - a service for
tracking package buildability status. I wo
Dear all,
I don't know if this has been discussed before, but I didn't find any.
Summary: I have a proposal to make it easier for maintainers to have
multiple versions of the same library in distro (by making it
*naturally* possible) (and with minimal maintenance overhead), and for
users/devel
On 01/24/2015 07:14 PM, Kevin Kofler wrote:
> Ralf Corsepius wrote:
>> This is not entirely true. GCC and related projects apply a pretty
>> complex peer review process, with defined roles and privileges. (Cf. the
>> file MAINTAINERS in GCC's sourcetree for details).
>>
>> Somewhat over-simplified
On 02/12/2015 10:40 AM, Peter Robinson wrote:
>> Is the koji rawhide repo not pointing to the new F23 builds/repo somehow?
>> My otf2-1.5.1-1.fc23 build doesn't appear to be showing up.
>>
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=8902498
>
> It's pointed to f-23 just fine
> http://koj
On Fri, Feb 13, 2015 at 11:55:02AM +, Andrew Haley wrote:
> On 01/24/2015 07:14 PM, Kevin Kofler wrote:
> > Ralf Corsepius wrote:
> >> This is not entirely true. GCC and related projects apply a pretty
> >> complex peer review process, with defined roles and privileges. (Cf. the
> >> file MAINT
On 13.02.2015 12:28, Mikolaj Izdebski wrote:
> On 02/12/2015 08:51 PM, Marcin Juszkiewicz wrote:
>> I plan to make something like Ubuntu has [2] which was great help when I
>> was working on fixing packages while working for Canonical.
>
> With Michael Simacek we are working on Koschei [1,2] - a s
On 02/13/2015 01:20 PM, Marcin Juszkiewicz wrote:
> On 13.02.2015 12:28, Mikolaj Izdebski wrote:
>> On 02/12/2015 08:51 PM, Marcin Juszkiewicz wrote:
>>> I plan to make something like Ubuntu has [2] which was great help when I
>>> was working on fixing packages while working for Canonical.
>>
>> Wi
Don't containers already accomplish this same concept?
jduncan
- Original Message -
From: "Hedayat Vatankhah"
To: "Development discussions related to Fedora"
Sent: Friday, February 13, 2015 6:51:17 AM
Subject: Proposal to (formally/easily) allowing multiple versions of the same
l
On 02/13/2015 10:56 AM, Petr Spacek wrote:
Modified version of Zbyszek's idea with time constraints follows:
1) Accept the new package into Fedora N even with bundled libraries.
I am inclined to be Fedora needs to encounter a serious vulnerability
originating from bundling, such that you guy
On Thu, 12 Feb 2015 16:49:13 -0500, Stephen Gallagher wrote:
> On Thu, 2015-02-12 at 20:18 +0100, Alec Leamas wrote:
> > On 12/02/15 19:32, Stephen Gallagher wrote:
> > > (Logistical note: please keep all replies to this thread on
> > > devel@lists.fedoraproject.org)
> > >
> > > tl;dr Shall we con
On Fri, 2015-02-13 at 15:21 +0330, Hedayat Vatankhah wrote:
> Dear all,
> I don't know if this has been discussed before, but I didn't find any.
> Summary: I have a proposal to make it easier for maintainers to have
> multiple versions of the same library in distro (by making it
> *naturally* possi
Hello,
After reading this article[1] on how many totally unsecured mongodb
installations there are on the internet, I noticed a recent (and
worrying) change in the defaults on Fedora's mongodb package.
In January, the Fedora rawhide package for mongo[2] was changed to
listen on all interfaces by
On Fri, 13 Feb 2015 13:54:59 +0100, Ralf Corsepius wrote:
> Meanwhile, we've had much more critical vulnerablities in widely used
> libs (Remember heartbleed), which all have been quite easy to fix
> packaging-wise. IMO, to a great portion, thanks to having mostly banned
> static linkage and bu
On Mon, Nov 17, 2014 at 8:06 PM, Adam Jackson wrote:
> Since the modular X repackaging in FC5, we have limited X server updates
> such that the ABI does not change. F20 shipped with xserver 1.14.4, for
> example, so we might update it to 1.14.7 but not to 1.15.0. With the
> reduced driver set in
On 13 February 2015 at 13:06, Michael Schwendt wrote:
> On Thu, 12 Feb 2015 16:49:13 -0500, Stephen Gallagher wrote:
>
>> On Thu, 2015-02-12 at 20:18 +0100, Alec Leamas wrote:
>> > On 12/02/15 19:32, Stephen Gallagher wrote:
>> > > (Logistical note: please keep all replies to this thread on
>> > >
Hedayat Vatankhah wrote:
> Proposal: let's make it possible to have multiple versions of the same
> library installed, as far as their .so version permits that
It's already possible (you gave several examples, like Qt)
Am I missing something? Or rather, what leads you to believe that it is not
Rex Dieter wrote:
> KDE SIG is investigating some recent/serious reported crasher bugs in
> rawhide, notably:
>
> "Could not sync environment to dbus." (startkde)
> https://bugzilla.redhat.com/show_bug.cgi?id=1191171
>
> and (an older one, but the situation has gotten worse recently):
>
> Qt5
On 13.02.2015 15:53, Rex Dieter wrote:
Rex Dieter wrote:
KDE SIG is investigating some recent/serious reported crasher bugs in
rawhide, notably:
"Could not sync environment to dbus." (startkde)
https://bugzilla.redhat.com/show_bug.cgi?id=1191171
and (an older one, but the situation has got
> As my work usually is around fixing packages which failed to build on
> AArch64 I spend lot of time with Koji.
>
> Today I started writing script which has to list all current FTBFS
> entries from selected Koji instance - kind like [1] does but with few
> extras:
>
> - no packages which got bui
On Fri, 2015-02-13 at 13:54 +0100, Ralf Corsepius wrote:
> On 02/13/2015 10:56 AM, Petr Spacek wrote:
>
> > Modified version of Zbyszek's idea with time constraints follows:
> >
> > 1) Accept the new package into Fedora N even with bundled libraries.
>
> I am inclined to be Fedora needs to enc
On 13. 2. 2015 at 08:03:18, Rex Dieter wrote:
> Hedayat Vatankhah wrote:
> > Proposal: let's make it possible to have multiple versions of the same
> > library installed, as far as their .so version permits that
>
> It's already possible (you gave several examples, like Qt)
>
> Am I missing somet
Stephen Gallagher wrote:
> (Logistical note: please keep all replies to this thread on
> devel@lists.fedoraproject.org)
>
> tl;dr Shall we consider requiring a lesser package review for packages
> that are not present on Product or Spin install media?
I would welcome our new ring-based overlords
On Thu, Feb 12, 2015 at 9:28 AM, gil wrote:
> as i wrote in my e-mail titled "jni libraries fails in koji"
> i have the same problem
> i haven't done any changes in koji client config
I tried the csdp build again this morning to see if perhaps the
problem is nondeterministic. It failed again:
h
On 13.02.2015 13:30, Mikolaj Izdebski wrote:
> On 02/13/2015 01:20 PM, Marcin Juszkiewicz wrote:
>>> With Michael Simacek we are working on Koschei [1,2] - a service for
>>> tracking package buildability status. I would like you to consider using
>>> Koschei. We can discuss adding missing features
On 13. 2. 2015 at 19:10:01, Christopher Meng wrote:
> On Friday, February 13, 2015, Pierre-Yves Chibon
>
> wrote:
> > On Fri, Feb 13, 2015 at 09:35:30AM +0100, Miroslav Suchy wrote:
> >
> > RHEL/EPEL users do not have DNF available, therefore they are unable to
> >
> > > build packages for Fedo
On Fri, 13 Feb 2015 14:00:07 +, Ian Malone wrote:
> Actually, a question I have about this is how it will impact people
> trying to become maintainers. When I last checked (it may have
> changed) the only way to do that was to create a new package.
That isn't the only way to become a packager
Jerry James wrote on 02/14/2015 12:23 AM:
On Thu, Feb 12, 2015 at 9:28 AM, gil wrote:
as i wrote in my e-mail titled "jni libraries fails in koji"
i have the same problem
i haven't done any changes in koji client config
I tried the csdp build again this morning to see if perhaps the
problem i
On 02/13/2015 04:13 PM, Stephen Gallagher wrote:
On Fri, 2015-02-13 at 13:54 +0100, Ralf Corsepius wrote:
On 02/13/2015 10:56 AM, Petr Spacek wrote:
Meanwhile, we've had much more critical vulnerablities in widely used
libs (Remember heartbleed), which all have been quite easy to fix
packa
On Fri, Feb 13, 2015 at 04:43:53PM +0100, Ralf Corsepius wrote:
> >words, I think it might be reasonable to have bundling in the outer
> >rings be a blacklist rather than a whitelist, so long as we can always
> >find out with a simple repoquery what contains a package.
> To me, this idea is not hel
On 02/13/2015 04:51 PM, Matthew Miller wrote:
On Fri, Feb 13, 2015 at 04:43:53PM +0100, Ralf Corsepius wrote:
words, I think it might be reasonable to have bundling in the outer
rings be a blacklist rather than a whitelist, so long as we can always
find out with a simple repoquery what contains
On Fri, 13 Feb 2015 12:55:23 +0100
Mikolaj Izdebski wrote:
> On 02/12/2015 10:40 AM, Peter Robinson wrote:
> >> Is the koji rawhide repo not pointing to the new F23 builds/repo
> >> somehow? My otf2-1.5.1-1.fc23 build doesn't appear to be showing
> >> up.
> >>
> >> http://koji.fedoraproject.org/k
"Ryan S. Brown" writes:
> [...] In January, the Fedora rawhide package for mongo[2] was
> changed to listen on all interfaces by default [...] To help
> protect users, I think the default should be changed back to
> localhost only. [...]
We have a slew of network-servers in the fedora distribu
/*Jan Zelený */ wrote on Fri, 13 Feb 2015 16:15:08
+0100:
On 13. 2. 2015 at 08:03:18, Rex Dieter wrote:
Hedayat Vatankhah wrote:
Proposal: let's make it possible to have multiple versions of the same
library installed, as far as their .so version permits that
It's already possible (you gave
On 13 February 2015 at 15:35, Michael Schwendt wrote:
> On Fri, 13 Feb 2015 14:00:07 +, Ian Malone wrote:
>
>> Actually, a question I have about this is how it will impact people
>> trying to become maintainers. When I last checked (it may have
>> changed) the only way to do that was to create
Am 13.02.2015 um 17:25 schrieb Frank Ch. Eigler:
"Ryan S. Brown" writes:
[...] In January, the Fedora rawhide package for mongo[2] was
changed to listen on all interfaces by default [...] To help
protect users, I think the default should be changed back to
localhost only. [...]
We have a
Build was OK, but bodhi is giving an error:
bodhi -n -r F22 -t enhancement -N 'see:
https://github.com/cython/cython/blob/master/CHANGES.rst ' Cython-0.22-1.fc22
Creating a new update for Cython-0.22-1.fc22
Cython-0.22-1.fc22 not tagged as an update candidate
http://koji.fedoraproject.org/koji
On Fri, 13 Feb 2015 11:53:09 -0500
Neal Becker wrote:
> Build was OK, but bodhi is giving an error:
>
> bodhi -n -r F22 -t enhancement -N 'see:
> https://github.com/cython/cython/blob/master/CHANGES.rst '
> Cython-0.22-1.fc22 Creating a new update for Cython-0.22-1.fc22
> Cython-0.22-1.fc22 not
Hi
On Fri, Feb 13, 2015 at 11:40 AM, Ian Malone wrote:
> Thanks. I think when I'd looked at it I'd discounted the review and
> comment on others' submissions process as it would seem to require you
> to have a better idea of what you're doing than the person submitting
> the package, and potentia
Hedayat Vatankhah wrote:
> It is possible, but it'll need package reviews for each new version.
Yes, it is a new package so a new review will be required (for either the
old-compat or the new-parallel-installable version).
this requirement for an additional review is likely non-negotiable.
>
Rex Dieter wrote:
> Sure, additional documentation is always welcome. Are you willing to help
> write some?
My apologies, re-reading the whole thread, including the initial post, I see
you did have a specific proposal... to which I responded separately to a
couple of points (but otherwise, a g
Hedayat Vatankhah wrote:
> 2. No reviews are required for new libfooX packages (as it is not
> required right now when you update your libfoo package
I disagree with this point, reviews are important, arguably *more* important
in special cases like parallel-installable libraries.
> For -devel p
On Fri, 2015-02-13 at 14:36 +0100, drago01 wrote:
> On Mon, Nov 17, 2014 at 8:06 PM, Adam Jackson wrote:
> > Since the modular X repackaging in FC5, we have limited X server updates
> > such that the ABI does not change. F20 shipped with xserver 1.14.4, for
> > example, so we might update it to 1
/*Nikos Mavrogiannopoulos */ wrote on Fri, 13 Feb 2015
14:11:49 +0100:
On Fri, 2015-02-13 at 15:21 +0330, Hedayat Vatankhah wrote:
Dear all,
I don't know if this has been discussed before, but I didn't find any.
Summary: I have a proposal to make it easier for maintainers to have
multiple vers
On Sat, 14 Feb 2015 00:45:50 +0900
Mamoru TASAKA wrote:
> Note that this fails on "buildSRPMFromSCM", i.e. when creating srpm,
> and not on "buildArch" (armv7hl, i686, x86_64), where rpmbuild the
> newly created srpm is executed.
>
> So when using mock, usually srpm is already there on your loca
/*Rex Dieter*/ wrote on Fri, 13 Feb 2015 11:15:58 -0600:
Hedayat Vatankhah wrote:
2. No reviews are required for new libfooX packages (as it is not
required right now when you update your libfoo package
I disagree with this point, reviews are important, arguably *more* important
in special ca
On Thu, 12 Feb 2015 13:32:04 -0500
Stephen Gallagher wrote:
> (Logistical note: please keep all replies to this thread on
> devel@lists.fedoraproject.org)
>
> tl;dr Shall we consider requiring a lesser package review for packages
> that are not present on Product or Spin install media?
IMHO, no
On Fri, 13 Feb 2015 15:21:17 +0330
Hedayat Vatankhah wrote:
> Dear all,
> I don't know if this has been discussed before, but I didn't find any.
...snip...
> Proposal: let's make it possible to have multiple versions of the
> same library installed, as far as their .so version permits that.
>
On 02/13/2015 12:15 PM, Rex Dieter wrote:
> Hedayat Vatankhah wrote:
>
>> 2. No reviews are required for new libfooX packages (as it is not
>> required right now when you update your libfoo package
>
> I disagree with this point, reviews are important, arguably *more* important
> in special case
On 02/12/2015 07:32 PM, Stephen Gallagher wrote:
> Second, I will call attention to the fact that different Fedora
> users have very different needs from the software. For example,
> those running Fedora Server and Fedora Cloud are likely far more
> concerned with Fedora as a *deployment* platform
On 02/13/2015 04:13 PM, Stephen Gallagher wrote:
> I'd like to point out something that I think you missed in my
> initial email. I'm not saying that anything should be allowed to
> bundle software transparently. The primary problem we faced back in
> '99 was that *we didn't know what was bundling
On Tue, 2015-02-10 at 04:01 -0500, Radek Holy wrote:
> TBH, I don't know whether we should extend the forms of package
> specifications to support your case. The current behaviour seems to be
> safer to me. I mean, if we improve it, user wouldn't be able to query
> just package names as easily as
/*Kevin Fenzi*/ wrote on Fri, 13 Feb 2015 11:36:47 -0700:
On Fri, 13 Feb 2015 15:21:17 +0330
Hedayat Vatankhah wrote:
<...>
But the thing is, it's really difficult to get right details about the
new package. Forget to change a name somewhere or a provides or
obsoletes. People mess this up all
Hi,
as has happened many times before, the GCC bump in rawhide has broken
all Fortran packages, desperately needing a mass rebuild. Unfortunately,
rpm is blissfully unaware of any breakage happening (BZ #1192617) so
maintainers won't even know when this breakage happens.
Before I start rebu
On Fri, 13 Feb 2015 12:47:07 -0800
Susi Lehtola wrote:
> Hi,
>
>
> as has happened many times before, the GCC bump in rawhide has broken
> all Fortran packages, desperately needing a mass rebuild.
Can you expand on the breakage? Is it that they no longer rebuild?
Or that they no longer run?
On Fri, Feb 13, 2015 at 01:53:12PM -0700, Kevin Fenzi wrote:
> On Fri, 13 Feb 2015 12:47:07 -0800
> Susi Lehtola wrote:
> > as has happened many times before, the GCC bump in rawhide has broken
> > all Fortran packages, desperately needing a mass rebuild.
>
> Can you expand on the breakage? Is i
Am Freitag, den 13.02.2015, 13:53 -0700 schrieb Kevin Fenzi:
> On Fri, 13 Feb 2015 12:47:07 -0800
> Susi Lehtola wrote:
>
> > Hi,
> >
> >
> > as has happened many times before, the GCC bump in rawhide has broken
> > all Fortran packages, desperately needing a mass rebuild.
>
> Can you expand
On 13.02.2015 16:04, Sandro Mani wrote:
On 13.02.2015 15:53, Rex Dieter wrote:
Rex Dieter wrote:
KDE SIG is investigating some recent/serious reported crasher bugs in
rawhide, notably:
"Could not sync environment to dbus." (startkde)
https://bugzilla.redhat.com/show_bug.cgi?id=1191171
and (
I need FORTRAN for R and R packages - if it's not 100% for the R
ecosystme I'd consider any bugs to be at least blockers for beta, if
not alpha.
On Fri, Feb 13, 2015 at 12:59 PM, Björn Esser wrote:
> Am Freitag, den 13.02.2015, 13:53 -0700 schrieb Kevin Fenzi:
>> On Fri, 13 Feb 2015 12:47:07 -080
On Fri, 13 Feb 2015 16:40:25 +, Ian Malone wrote:
> >->
> > https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
> >
> > Submitting a new package is just _one_ of multiple ways to find a sponsor,
> > since it is an opportunity to demonstrate that you know packaging.
On 13.02.2015 22:21, Sandro Mani wrote:
On 13.02.2015 16:04, Sandro Mani wrote:
On 13.02.2015 15:53, Rex Dieter wrote:
Rex Dieter wrote:
KDE SIG is investigating some recent/serious reported crasher bugs in
rawhide, notably:
"Could not sync environment to dbus." (startkde)
https://bugzilla
On 13 February 2015 at 09:05, Ralf Corsepius wrote:
> On 02/13/2015 04:51 PM, Matthew Miller wrote:
>
>> On Fri, Feb 13, 2015 at 04:43:53PM +0100, Ralf Corsepius wrote:
>>
>>> words, I think it might be reasonable to have bundling in the outer
rings be a blacklist rather than a whitelist, so
On 02/13/2015 11:25 AM, Frank Ch. Eigler wrote:
> "Ryan S. Brown" writes:
>
>> [...] In January, the Fedora rawhide package for mongo[2] was
>> changed to listen on all interfaces by default [...] To help
>> protect users, I think the default should be changed back to
>> localhost only. [...]
>
a fix for this problem is:
(see
http://pkgs.fedoraproject.org/cgit/java-service-wrapper.git/tree/java-service-wrapper.spec
)
# rpmbuild < 4.6 support
%if ! 0%{?__isa_bits}
%ifarch x86_64 ia64 ppc64 sparc64 s390x alpha ppc64le aarch64
%global __isa_bits 64
%else
%global __isa_bits 32
%endif
%end
# F22 Blocker Review meeting
# Date: 2015-02-16
# Time: 1700 UTC
# Location: #fedora-blocker-review on irc.freenode.net
It's Blocker Review time again! While we don't yet have an Alpha TC to
test, testing against rawhide has continued. The results have yielded a
couple proposed blockers: 3 Alpha a
On 02/13/2015 01:57 PM, Jakub Jelinek wrote:
> On Fri, Feb 13, 2015 at 01:53:12PM -0700, Kevin Fenzi wrote:
>> On Fri, 13 Feb 2015 12:47:07 -0800
>> Susi Lehtola wrote:
>>> as has happened many times before, the GCC bump in rawhide has broken
>>> all Fortran packages, desperately needing a mass r
On Fri, Feb 13, 2015 at 6:06 AM, Michael Schwendt wrote:
> On Thu, 12 Feb 2015 16:49:13 -0500, Stephen Gallagher wrote:
>> Ultimately, it's about one thing: Help get more software into Fedora
>> without scaring people away.
>
> What is the background for this? Who has been scared away?
Here's one
On Fri, 13 Feb 2015 17:45:23 -0700, Ken Dreyer wrote:
> > On Thu, 12 Feb 2015 16:49:13 -0500, Stephen Gallagher wrote:
> >> Ultimately, it's about one thing: Help get more software into Fedora
> >> without scaring people away.
> >
> > What is the background for this? Who has been scared away?
>
>
Michael Schwendt wrote:
> Naming the package "libunicode" could be safer with regard to avoiding a
> clash with another future project with the same name. But if following the
> guidelines, I would name it courier-unicode.
IMHO, the potential for conflicts and confusion with other projects is
act
Pierre-Yves Chibon wrote:
> Could it be an idea to check if /usr/bin/dnf exists (or if dnf can be
> found in $PATH) before calling dnf and if not a) warn the user and b)
> switch back to yum?
>
> This would make mock run out of the box for RHEL/EPEL users as well.
IMHO, it is the job of the EPEL
Am 13.02.2015 um 21:42 schrieb Hedayat Vatankhah:
I'm not sure if things will be (much) worse than the current situation.
Maintainers already do maintain multiple versions of the same library,
and also the upgrade path from a Fedora release to the next should work.
My assumption was that the eff
I got a complaint about this:
not ok - depcheck for Bodhi update vtk-6.1.0-23.fc21# FAIL
---
arch: x86_64
details:
output: |-
Build vtk-6.1.0-23.fc21 failed depcheck
package vtk-qt-python-6.1.0-23.fc21.i686 requires vtk(x86-32) =
6.1.0-23.fc21, but none of the providers
:
> [alex]
> alex-3.1.3-1.fc22.i686 requires
> ghc(unix-2.7.0.1-b0d741fe9ce9a85eada7f5178fc621fa)
> alex-3.1.3-1.fc22.i686 requires
> ghc(time-1.4.2-c7bfcef03445b2ec67d3d5b04c386722)
> alex-3.1.3-1.fc22.i686 requires
> ghc(template-haskell-2.9.0.0-57f65c241f99343438be3dddb73913
On 02/13/2015 08:14 PM, Florian Weimer wrote:
On 02/12/2015 07:32 PM, Stephen Gallagher wrote:
Second, I will call attention to the fact that different Fedora
users have very different needs from the software. For example,
those running Fedora Server and Fedora Cloud are likely far more
concerne
On 14/02/15 01:45, Ken Dreyer wrote:
Here's the new policy that I would vote for:
1) We allow bundled libraries, and each bundled library MUST have a
virtual Provides: bundled(foo) in the RPM spec. (The packager SHOULD
provide a version number too, with the admission that it is sometime
On 02/13/2015 08:20 PM, Florian Weimer wrote:
I have some people express the notation that they can always switch to
the system library version in case a security vulnerability comes out,
but I doubt that this works in practice (because then there wouldn't
be a reason for bundling).
It sometim
I don't think libunicode is a good name, actually it's too common and
should be avoided.
You should also ask upstream about the potential file conflicts.
--
Yours sincerely,
Christopher Meng
http://cicku.me
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/m
On Fri, Feb 13, 2015 at 11:37 PM, Ryan S. Brown wrote:
> On 02/13/2015 11:25 AM, Frank Ch. Eigler wrote:
>> "Ryan S. Brown" writes:
>>
>>> [...] In January, the Fedora rawhide package for mongo[2] was
>>> changed to listen on all interfaces by default [...] To help
>>> protect users, I think th
90 matches
Mail list logo
