Folks,
we see many Gtk3 crashes in Firefox recently
(https://bugzilla.mozilla.org/show_bug.cgi?id=1239962) which comes from
Gtk3 system library.
If you's like to help here, please install latest FF updates from koji:
F23: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8344bd0b61
F22: ht
Also please remove Firefox from ABRT blacklist at:
/etc/abrt/abrt-action-save-package-data.conf
ma.
On 02/03/2016 10:43 AM, Martin Stransky wrote:
Folks,
we see many Gtk3 crashes in Firefox recently
(https://bugzilla.mozilla.org/show_bug.cgi?id=1239962) which comes from
Gtk3 system library.
On Tue, Feb 02, 2016 at 06:13:13PM -0600, Yaakov Selkowitz wrote:
> >This approach really scales badly and creates busywork.
> And breaking rawhide however often due to unnoticed soname bumps
> does scale well and does not cause busywork?
Right. Tooling should stop that too. And I'm not just talki
On Tue, Feb 02, 2016 at 06:13:13PM -0600, Yaakov Selkowitz wrote:
> >Ideally, every line in a package definition (specfile or what have you)
> >is only there because of some exception from the typical case. For
> >well-behaved
> >upstreams, the perfect packaging description would be _empty_.
> I d
Don't know it it will help, but I see Firefox almost always crash when I
open new window and try to close it on F23. Sometimes earlier after
opening the windows, sometimes later after closing.
Jakub
On 02/03/2016 10:43 AM, Martin Stransky wrote:
Folks,
we see many Gtk3 crashes in Firefox rec
I'd need the ABRT backtrace for that - don't see it on my F23 box.
On 02/03/2016 11:58 AM, Jakub Jelen wrote:
Don't know it it will help, but I see Firefox almost always crash when I
open new window and try to close it on F23. Sometimes earlier after
opening the windows, sometimes later after cl
On Tue, 02 Feb 2016 13:01:04 +0100, Adam Williamson wrote:
> > Even if the spec file uses wildcards to include any shared library
> > version, the automatic dependency checks for Rawhide will notice the
> > SONAME change and inform the packager about it.
> > [...]
>
> This is too late, though. We
On Wed, 3 Feb 2016 05:26:23 -0500, Matthew Miller wrote:
> On Tue, Feb 02, 2016 at 06:13:13PM -0600, Yaakov Selkowitz wrote:
> > >This approach really scales badly and creates busywork.
> > And breaking rawhide however often due to unnoticed soname bumps
> > does scale well and does not cause bu
On Wed, 3 Feb 2016 07:34:06 +0100, Pierre-Yves Chibon wrote:
> On Tue, Feb 02, 2016 at 10:45:04PM -, Christian Stadelmann wrote:
> > Is there any reason why two packages provide tsqllib and tsqllib-devel? See
> > https://apps.fedoraproject.org/packages/s?search=trustedqsl and the related
> >
On Tue, Feb 2, 2016 at 4:45 PM, Christian Stadelmann <
genodeft...@fedoraproject.org> wrote:
> Is there any reason why two packages provide tsqllib and tsqllib-devel?
> See https://apps.fedoraproject.org/packages/s?search=trustedqsl and the
> related .spec files in git repos?
They used to be sup
On Tue, Feb 2, 2016 at 4:38 PM, Pierre-Yves Chibon
wrote:
> On Tue, Feb 02, 2016 at 04:11:46PM -0600, Richard Shaw wrote:
> >I was notified by a user that a newer version of trustedqsl was
> available
> >so I looked into why I wasn't notified.
> >For some reason it still thinks 1.13 i
On 02/03/2016 10:53 AM, Martin Stransky wrote:
Also please remove Firefox from ABRT blacklist at:
/etc/abrt/abrt-action-save-package-data.conf
ma.
On 02/03/2016 10:43 AM, Martin Stransky wrote:
Folks,
we see many Gtk3 crashes in Firefox recently
(https://bugzilla.mozilla.org/show_bug.cgi?id=
On 02/03/2016 02:45 PM, Jakub Jelen wrote:
On 02/03/2016 10:53 AM, Martin Stransky wrote:
Also please remove Firefox from ABRT blacklist at:
/etc/abrt/abrt-action-save-package-data.conf
ma.
On 02/03/2016 10:43 AM, Martin Stransky wrote:
Folks,
we see many Gtk3 crashes in Firefox recently
(h
= Proposed Self Contained Change: Graphical System Upgrades =
https://fedoraproject.org/wiki/Changes/GraphicalSystemUpgrades
Change owner(s):
* Kalev Lember < klember AT redhat DOT com >
Add support for performing system upgrades to a newer Fedora release
through GNOME Software.
== Detailed Desc
On Wed, Feb 03, 2016 at 03:00:53PM +0100, Jan Kurik wrote:
> We'll implement a graphical user interface for system upgrades. The
> implementation will use PackageKit and the libhif stack as a backend
> and GNOME Software as a frontend. First supported version is going to
> be Fedora 23->24 upgrades
= Proposed System Wide Change: GNOME 3.20 =
https://fedoraproject.org/wiki/Changes/GNOME3.20
Change owner(s):
* Kalev Lember
Update GNOME to the latest upstream release, 3.20
== Detailed Description ==
The new features for 3.20 include:
* Graphical System Upgrades
* Cantarell font improvements
Am Mittwoch, den 03.02.2016, 15:00 +0100 schrieb Jan Kurik:
> First supported version is going to
> be Fedora 23->24 upgrades.
Does this mean the changes will be backported to GNOME Software 3.18?
--
Regards,
Heiko Adams
signature.asc
Description: This is a digitally signed message part
--
dev
= Proposed System Wide Change: Removal of librtkaio from glibc =
https://fedoraproject.org/wiki/Changes/GLIBC223_librtkaio_removal
Change owner(s):
* Carlos O'Donell
Remove librtkaio support from glibc in Fedora 24.
== Detailed Description ==
On July 2003 the rtkaio add-on was added to Fedora i
On 02/03/2016 03:11 PM, Matthew Miller wrote:
> On Wed, Feb 03, 2016 at 03:00:53PM +0100, Jan Kurik wrote:
>> We'll implement a graphical user interface for system upgrades. The
>> implementation will use PackageKit and the libhif stack as a backend
>> and GNOME Software as a frontend. First suppor
On Wed, Feb 03, 2016 at 03:21:26PM +0100, Kalev Lember wrote:
> >> We'll implement a graphical user interface for system upgrades. The
> >> implementation will use PackageKit and the libhif stack as a backend
> >> and GNOME Software as a frontend. First supported version is going to
> >> be Fedora
= Proposed System Wide Change: The GNU C Library version 2.23 =
https://fedoraproject.org/wiki/Changes/GLIBC223
Change owner(s):
* Carlos O'Donell
Switch glibc in Fedora 24 to glibc version 2.23.
== Detailed Description ==
The GNU C Library version 2.23 will be released at the end of February
2
On 02/03/2016 03:16 PM, Heiko Adams wrote:
> Am Mittwoch, den 03.02.2016, 15:00 +0100 schrieb Jan Kurik:
>> First supported version is going to
>> be Fedora 23->24 upgrades.
> Does this mean the changes will be backported to GNOME Software 3.18?
No. The plan is to put GNOME Software 3.20 in F23, s
On 2016-02-02, Florian Weimer wrote:
> May packages assume that /usr/sbin is on PATH when they are built?
>
> If you need a program which is currently only in /usr/sbin, should a
> package use an absolute path, or reset PATH to include /usr/sbin?
>
When I was small, I was tought that sbin is for p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/03/2016 09:35 AM, Petr Pisar wrote:
> On 2016-02-02, Florian Weimer wrote:
>> May packages assume that /usr/sbin is on PATH when they are built?
>>
>> If you need a program which is currently only in /usr/sbin, should a
>> package use an absol
On 3 February 2016 at 14:35, Petr Pisar wrote:
> On 2016-02-02, Florian Weimer wrote:
>> May packages assume that /usr/sbin is on PATH when they are built?
>>
>> If you need a program which is currently only in /usr/sbin, should a
>> package use an absolute path, or reset PATH to include /usr/sbi
On Wed, Feb 03, 2016 at 09:44:21AM -0500, Stephen Gallagher wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/03/2016 09:35 AM, Petr Pisar wrote:
> > On 2016-02-02, Florian Weimer wrote:
> >> May packages assume that /usr/sbin is on PATH when they are built?
> >>
> >> If you nee
On Wed, Feb 03, 2016 at 03:00:53PM +0100, Jan Kurik wrote:
> = Proposed Self Contained Change: Graphical System Upgrades =
> https://fedoraproject.org/wiki/Changes/GraphicalSystemUpgrades
This change is really light on details (or progress?). How is this going
to be different (and why) from the dn
Hi,
On Wed, Jan 27, 2016 at 11:57:37PM +0100, Jan Pokorný wrote:
> attempt on settle this one down: http://tools.ietf.org/html/rfc6761
rfc6761 is a useful reference, but it doesn't really solve this
discussion one way or another.
It's concerned with names to be "carved off a sub-tree of the DNS
n
On Tue, Feb 2, 2016 at 11:30 PM, Pierre-Yves Chibon wrote:
> Well, one thing about this is that no-one owns packages anymore. We are a
> community and there are package maintainers in that community.
> Each package has one or more maintainers, but nobody owns it. The only reason
> we
> even have
On 3 February 2016 at 15:27, Brian C. Lane wrote:
> On Wed, Feb 03, 2016 at 03:00:53PM +0100, Jan Kurik wrote:
> > = Proposed Self Contained Change: Graphical System Upgrades =
> > https://fedoraproject.org/wiki/Changes/GraphicalSystemUpgrades
>
> This change is really light on details (or progre
Hi all,
Per the Fedora 24 schedule[1] we will be starting a mass rebuild for Fedora 24
very shortly. We are doing a mass rebuild for Fedora 24 for
https://fedoraproject.org/wiki/Changes/GCC6
we will start the mass rebuild on 2016-02-03
This is a heads up that it will be done in a side tag and m
On 03/02/16 08:44 -0700, Jerry James wrote:
1. Demotivating packagers
I know a number of companies have experimented with "ownership-free"
models of code development, but they are able to offer incentives that
Fedora cannot offer, such as money and kudos offered in front of
coworkers. What mot
On Wed, Feb 3, 2016 at 3:26 AM, Matthew Miller wrote:
> Right. Tooling should stop that too. And I'm not just talking
> _completely_ in hand-wavy theory. This is Dennis Gilmore's plan, where
> any package build which breaks other packages (or possibly other
> integration testing) gets automaticall
On 03/02/16 11:58 +0100, Jakub Jelen wrote:
Don't know it it will help, but I see Firefox almost always crash when
I open new window and try to close it on F23. Sometimes earlier after
opening the windows, sometimes later after closing.
I've been seeing this recently when I close a tab that wa
On Wed, Feb 03, 2016 at 03:12:17PM +, Zbigniew Jędrzejewski-Szmek wrote:
> Using %{_sbindir} is just busywork. It is safe it too asume that is
> $PATH.
I sadly agree. Ship sailed for fixing this about a decade ago. It'd be
a nice usability enhancement to get programs which are not intended to
On Wed, 3 Feb 2016 07:32:33 -0600, Richard Shaw wrote:
> On Tue, Feb 2, 2016 at 4:45 PM, Christian Stadelmann wrote:
>
> > Is there any reason why two packages provide tsqllib and tsqllib-devel?
> > See https://apps.fedoraproject.org/packages/s?search=trustedqsl and the
> > related .spec files
I would have just made the lib a subproject but the version is higher than
that of the binary/overall version. Maybe the best thing to do is just to
go ahead and bite the bullet and bump the Epoch and do it that way.
Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.
Sorry to reply with such a delay.
On Mon, Jan 25, 2016 at 07:43:35PM -0800, Andrew Lutomirski wrote:
> I also think that the whole gethostname(2) mechanism is terminally
> screwed up. We abuse the hostname for multiple purposes:
>
> 1. It shows up in the default bash prompt.
>
> 2. It gets sent
On Wed, Feb 03, 2016 at 11:09:48AM -0500, Matthew Miller wrote:
> On Wed, Feb 03, 2016 at 03:12:17PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > Using %{_sbindir} is just busywork. It is safe it too asume that is
> > $PATH.
>
> I sadly agree. Ship sailed for fixing this about a decade ago. It'd
With the release of GCC 6.0 in Rawhide I'm having a build
warning/error[1,2] with OpenImageIO I'm not sure what to do with (other
than adding a flag to ignore it).
Upstream is looking into it but currently thinks that the pugixml API is
requiring a method that GCC 6.0 doesn't like:
[ 3%] Buildi
On 02/03/2016 05:59 PM, Richard Shaw wrote:
> In member function 'void OpenImageIO::v1_6::pugi::xml_document::create()':
> /builddir/build/BUILD/oiio-Release-1.6.9/src/include/OpenImageIO/pugixml.cpp:5143:58:
> error: placement new constructing an object of type
> 'OpenImageIO::v1_6::pugi::impl::x
On Wed, Feb 3, 2016 at 11:15 AM, Florian Weimer wrote:
> On 02/03/2016 05:59 PM, Richard Shaw wrote:
>
> > In member function 'void
> OpenImageIO::v1_6::pugi::xml_document::create()':
> >
> /builddir/build/BUILD/oiio-Release-1.6.9/src/include/OpenImageIO/pugixml.cpp:5143:58:
> > error: placement
On Wed, 2016-02-03 at 08:44 -0700, Jerry James wrote:
> I know a number of companies have experimented with "ownership-free"
> models of code development, but they are able to offer incentives
> that
> Fedora cannot offer, such as money and kudos offered in front of
> coworkers. What motivates vol
On 03/02/16 10:59 -0600, Richard Shaw wrote:
With the release of GCC 6.0 in Rawhide I'm having a build
warning/error[1,2] with OpenImageIO I'm not sure what to do with (other
than adding a flag to ignore it).
tl;dr either add -Wno-error=placement-new for now or try the
workaround at the bottom
On 03/02/16 17:30 +, Jonathan Wakely wrote:
On 03/02/16 10:59 -0600, Richard Shaw wrote:
With the release of GCC 6.0 in Rawhide I'm having a build
warning/error[1,2] with OpenImageIO I'm not sure what to do with (other
than adding a flag to ignore it).
tl;dr either add -Wno-error=placement
On 02/03/2016 12:42 PM, Michael Schwendt wrote:
On Wed, 3 Feb 2016 05:26:23 -0500, Matthew Miller wrote:
On Tue, Feb 02, 2016 at 06:13:13PM -0600, Yaakov Selkowitz wrote:
This approach really scales badly and creates busywork.
And breaking rawhide however often due to unnoticed soname bumps
d
On 02/03/2016 05:08 PM, Jonathan Wakely wrote:
On 03/02/16 11:58 +0100, Jakub Jelen wrote:
Don't know it it will help, but I see Firefox almost always crash when
I open new window and try to close it on F23. Sometimes earlier after
opening the windows, sometimes later after closing.
I've been
On 02/03/2016 08:44 AM, Jerry James wrote:
> On Tue, Feb 2, 2016 at 11:30 PM, Pierre-Yves Chibon
> wrote:
>> Well, one thing about this is that no-one owns packages anymore. We are a
>> community and there are package maintainers in that community.
>> Each package has one or more maintainers, but
First the C++ code:
namespace Amanith {
struct GNamedSVGcolor {
GChar8 Name[22];
GVector4 RGBA;
};
static const GNamedSVGcolor SVGColors[147] = {
{ "aliceblue", GVector4(0.941, 0.973, 1.000, 1.000) },
{ "antiquewhite", GVector4(0.980, 0.922, 0.843, 1.000) },
On 02/03/2016 07:37 PM, Tom Callaway wrote:
> Ideas?
Please tells us which package and which build. This needs more context
for an investigation, I think.
Florian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
From b1efc082c60eae772d5f0edb3caf7b63ed916140 Mon Sep 17 00:00:00 2001
From: Dennis Gilmore
Date: Wed, 3 Feb 2016 17:15:59 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
---
bucardo.spec | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/b
On 02/03/2016 01:49 PM, Florian Weimer wrote:
> On 02/03/2016 07:37 PM, Tom Callaway wrote:
>
>> Ideas?
>
> Please tells us which package and which build. This needs more context
> for an investigation, I think.
amanith:
https://kojipkgs.fedoraproject.org//work/tasks/6502/12806502/build.log
~t
On 02/03/2016 07:51 PM, Tom Callaway wrote:
> On 02/03/2016 01:49 PM, Florian Weimer wrote:
>> On 02/03/2016 07:37 PM, Tom Callaway wrote:
>>
>>> Ideas?
>>
>> Please tells us which package and which build. This needs more context
>> for an investigation, I think.
>
> amanith:
> https://kojipkgs.f
On 02/03/2016 01:57 PM, Florian Weimer wrote:
> Okay, self-contained test case is:
>
> struct GVector4 {
> GVector4(int);
> };
> struct GNamedSVGcolor {
> char Name[22];
> GVector4 RGBA;
> };
>
> static const GNamedSVGcolor SVGColors[1] = {
> { "aliceblue", GVector4(1) },
> };
>
> The R
On Wed, 3 Feb 2016 16:04:19 +, Jonathan Wakely wrote:
> When a provenpackager is rebuilding *hundreds* of packages at once,
> and trying to deal with maybe dozens of build failures, sending emails
> to all the package owners and waiting to see if they respond promptly
> is not an efficient way
On Wed, Feb 03, 2016 at 02:10:46PM -0500, Tom Callaway wrote:
> On 02/03/2016 01:57 PM, Florian Weimer wrote:
>
> > Okay, self-contained test case is:
> >
> > struct GVector4 {
> > GVector4(int);
> > };
> > struct GNamedSVGcolor {
> > char Name[22];
> > GVector4 RGBA;
> > };
> >
> > static
On 02/03/2016 02:21 PM, Marek Polacek wrote:
> Looks like a g++ bug; I opened
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69658
> to track it further.
Thanks. Always nice to have someone else agree that it probably isn't my
fault. :D
~tom
==
Red Hat
--
devel mailing list
devel@lists.fedorapr
Michael Schwendt (mschwe...@gmail.com) said:
> > Sometimes a provenpackager will make a bad change, and that's
> > unfortunate, but it happens. Sometimes package owners make bad changes
> > too! :-)
>
> You're taking it too lightly. Somebody who performs version upgrades really
> needs to take ca
On Wed, Feb 3, 2016 at 2:19 PM, Michael Schwendt wrote:
> On Wed, 3 Feb 2016 16:04:19 +, Jonathan Wakely wrote:
>
>> When a provenpackager is rebuilding *hundreds* of packages at once,
>> and trying to deal with maybe dozens of build failures, sending emails
>> to all the package owners and wa
Yaakov Selkowitz wrote:
> This is the hazard of using %{_libdir}/*.so.* in %files. Is there any
> reason why such a syntax should NOT be formally discouraged in the
> packaging guidelines?
There is: I do not want to have to pointlessly edit my specfile each time
some soname changes, and waste a
I have lots of test installations using identical partition sizes for EXT3 or
EXT4 / filesystems. the filesystem space these provided is adequate on all if
running Mageia or openSUSE, but quite often not for Fedora. Working around
the inadequacy on Fedora presents problems #2 & #3.
Problem #1:
NAI
Do we have zypper in Fedora?
Perhaps we should give that a try?
On Feb 3, 2016 23:28, "Felix Miata" wrote:
> I have lots of test installations using identical partition sizes for EXT3
> or
> EXT4 / filesystems. the filesystem space these provided is adequate on all
> if
> running Mageia or openS
On Wed, Feb 3, 2016 at 3:28 PM, Felix Miata wrote:
> I have lots of test installations using identical partition sizes for EXT3 or
> EXT4 / filesystems. the filesystem space these provided is adequate on all if
> running Mageia or openSUSE, but quite often not for Fedora. Working around
> the inad
Jerry James wrote:
> a. Last fall, a provenpackager updated a package for which I am the
> primary point of contact (as well as the original submitter). The
> update was to an upstream alpha release. It was alpha for a reason.
> The release is super buggy. I had not updated to it on purpose. A
Jonathan Wakely wrote:
> A workaround would be to make it too hard for the compiler to see the
> problem:
>
> void* ptr = page->data;
> _root = new (ptr) impl::xml_document_struct(page);
>
> This way GCC doesn't see that the address refers to a 1-byte array.
Why not simply:
char data[
#i
On 02/03/2016 02:28 PM, Felix Miata wrote:
Problem #3:
When running from say the /boot directory the same dnf command above:
# dnf update kd*, kf*, q*, per*, pyt*, u*, v*, x* y*, z*
dnf reports cannot install package inityada, cannot install package vmliyada,
It ought to be smart e
Hello /all,
I've been using GNU/Linux since 1998. That year I joined to GPUL, the Coruña
(North Spain) Linux Users Group. In these years I organised with my LUG a lot
of free software hackmeetings, the greatest one, the GUADEC 2012.
I was a Debian zealot more than 10 years, but because my curre
On Wed, Feb 3, 2016, at 05:54 PM, Chris Murphy wrote:
>
> > NAICT, DNF, like Yum before it, offers no option I can recognize from its
> > man
> > page to download less than all the to-be-updated/installed packages before
> > proceeding to install any packages. Thus it downloads (typically hundred
On 3 February 2016 at 23:00, Kevin Kofler wrote:
>
> Really, it is not realistic to expect people who need to urgently fix
> something to write up a polite e-mail and wait possibly days for you to
> reply (especially if you then answer that you don't want the change and more
> days are wasted goi
On Wed, 03 Feb 2016 23:27:30 +0100
Kevin Kofler wrote:
> Yaakov Selkowitz wrote:
> > This is the hazard of using %{_libdir}/*.so.* in %files. Is there
> > any reason why such a syntax should NOT be formally discouraged in
> > the packaging guidelines?
>
> There is: I do not want to have to po
On Wed, 3 Feb 2016 23:26:23 +
Ian Malone wrote:
> If this is a requirement then it rules out a lot of potential
> packagers who are not full time employed to work on OSS. I could not
> sit at my desk and respond to IRCs about Fedora all day.
As with so much in life, IMHO, it's not a black an
I'll be updating these in rawhide only. The big change is that
courier-unicode has changed the library name to libcourier-unicode and
includes a couple extra header files. As far as I can tell the only
package that cares is maildrop, so this shouldn't be an issue.
--
Brian C. Lane | Anaconda Team
On Wed, Feb 3, 2016 at 6:10 PM, Samuel Sieb wrote:
> On 02/03/2016 02:28 PM, Felix Miata wrote:
>
>> Problem #3:
>> When running from say the /boot directory the same dnf command above:
>>
>> # dnf update kd*, kf*, q*, per*, pyt*, u*, v*, x* y*, z*
>>
>> dnf reports cannot install package
Chris Murphy composed on 2016-02-03 15:54 (UTC-0700):
> Felix Miata wrote:
...
>> Does anyone here agree that each of the three would represent legitimate
>> wishlist bugs, unlikely to be summarily dismissed as wontfix?
> My expectation is that's a lot more work than for dnf to do a better
> esti
On Qua, 2016-02-03 at 15:10 -0800, Samuel Sieb wrote:
> On 02/03/2016 02:28 PM, Felix Miata wrote:
> > Problem #3:
> > When running from say the /boot directory the same dnf command
> > above:
> >
> > # dnf update kd*, kf*, q*, per*, pyt*, u*, v*, x* y*, z*
> >
> > dnf reports cannot install
Kevin Fenzi wrote:
> Why would it be a pointless edit? Surely you are editing it to update
> to the new version, why wouldn't you also just edit it to adjust the
> so files? or do you not test your version upgrade specs before firing
> off official builds?
Of course not. The rule of thumb is "Rawh
On Wed, 2016-02-03 at 08:44 -0700, Jerry James wrote:
>
> I think we need to ask ourselves, as a project, what behaviors we want
> to motivate and what behaviors we want to demotivate in our packagers.
> I think we need to take human nature, flawed as it is, into account
> when doing so. I fear t
On Wed, 2016-02-03 at 16:04 +, Jonathan Wakely wrote:
> > If I send these two provenpackagers a somewhat hostile email, are you
> > going to blame me? I have no problem with most provenpackager
> > changes. In general, they have an obvious purpose and save me the
> > work of making the same
Missing expected images:
Kde disk raw armhfp
Cloud disk raw i386
Cloud disk raw x86_64
Cloud_atomic disk raw x86_64
Images in this compose but not Rawhide 20160202:
Design_suite live x86_64
Generic boot x86_64
Lxde live i386
Soas disk raw armhfp
Xfce disk raw armhfp
Security live i386
Scientific
On Thu, 04 Feb 2016 09:09:33 +0800
Ian Kent wrote:
> I agree.
>
> I believe that package ownership has at least a couple of clear
> advantages for obvious reasons and I find it hard to understand how
> people can discount their usefulness.
>
> 1) A point of contact and co-ordination for changes
Missing expected images:
Kde disk raw armhfp
Cloud disk raw i386
Cloud disk raw x86_64
Cloud_atomic disk raw x86_64
Images in this compose but not Rawhide 20160202:
Design_suite live x86_64
Generic boot x86_64
Lxde live i386
Soas disk raw armhfp
Xfce disk raw armhfp
Security live i386
Scientific
On Wed, 3 Feb 2016 08:44:32 -0700
Jerry James wrote:
> Several people have said something similar lately, and it worries me.
> I understand that we're trying to combat the hostility some packagers
> show when somebody does something to "their" packages, but I'm
> concerned that we may have swung
On Wed, 2016-02-03 at 18:44 -0700, Kevin Fenzi wrote:
> On Thu, 04 Feb 2016 09:09:33 +0800
> Ian Kent wrote:
>
> > I agree.
> >
> > I believe that package ownership has at least a couple of clear
> > advantages for obvious reasons and I find it hard to understand how
> > people can discount thei
83 matches
Mail list logo
