Hi!
FAS user tmatsuu is innactive for almost two years [1], he did not answered on
email. Does anyone know how to contact him?
Dmitrij
[1] http://koji.fedoraproject.org/koji/userinfo?userID=1247
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinf
On 27.06.2014 19:03, DJ Delorie wrote:
Welcome to the 21st century!
Do we have different eyes and brains than we did last century?
Because otherwise, excessively wide paragraphs are just as hard to
read now as they were then.
E.g. for me, 'bz.rh-cols90.png' is consistent, unlike 'bz.rh-col
On 2014-06-26 15:26 (GMT-0400) Felix Miata composed:
On 2014-06-26 13:24 (GMT-0500) Chris Adams composed:
Felix Miata said:
Now that the kernel is no longer putting the display to
sleep and I can start X, I find that setterm command no longer
applies only to the vttys. It's now coloring my
I'm also investigating the results, as I also couldn't see what's wrong there.
I fixed this package days ago and it at least could be built(it uses
jam to build which is totally a mess to me).
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/dev
On Fri, Jun 27, 2014 at 03:21:42PM -0700, Brian C. Lane wrote:
> So be forewarned :) And if someone can help sort out what the heck is
> causing this I'd sure be grateful.
I've just fired off a new anaconda build with David Shea's signal
patches which, in my testing here, seem to have solved the w
Hello, Dear Fedorian Community,
I am to retire Synapse from the Fedora repos. The reason is clearly stated here:
https://answers.launchpad.net/synapse-project/+question/246635#yui_3_10_3_1_1403917606540_250
If anybody has any last words, they're welcome.
--
It's hard to be free... but I love to
On 27/06/14 23:58, Sergio Pascual wrote:
Hello, I have updated two laptops runing F20 today. After the update, on
both of them (Asus and Dell) the trackpad has turned very slow, and
unaffected of any change in the gnome control panel.
Try this update:
https://admin.fedoraproject.org/updates/F
On 2014-06-24 15:12, Till Maas wrote:
The following packages are orphaned or did not build for two
releases and will be retired when Fedora (F21) is branched, unless someone
adopts them.
More patches:
alliance chitlesh, tnorth
https://bugzilla.redhat.com/show_bug.cgi?i
Hello, I have updated two laptops runing F20 today. After the update, on
both of them (Asus and Dell) the trackpad has turned very slow, and
unaffected of any change in the gnome control panel.
I'm not sure which update is responsible. Perhaps
xorg-x11-server-*-1.14.4-10.fc20.x86_64?
Has anybody
On 06/27/2014 12:28 PM, Dridi Boukelmoune wrote:
> It may also be possible to compress-and-sign them on the fly. If the
> gpg check can be done incrementally, you could compress the rpm to
> /dev/null and gradually compute the signature.
>
> That leaves you a signature to check and a ready-to-inst
I've spent my day trying to sort out what the heck is going on here, but
failed.
I'll do a new build of lorax in a bit so that the nightly rawhide
compose will work tonight, but you may hit some problems.
With my locally built boot.iso I am seeing a variety of failures at
different points. There'
On 27.06.2014 18:56, Kevin Fenzi wrote:
Well, I think you are talking here about a patch that changes the code
of the package. Many of the cases people were talking about for these
'trivial' or 'simple' patches didn't even touch the code... they simply
modified the spec, so have little to do wit
On Fri, Jun 27, 2014 at 08:08:59PM +0200, Florian Weimer wrote:
> /usr/lib/libedelib.so.2.1.0 is quite corrupted. ldd thinks it's statically
> linked, and readelf reports these errors (among others0.
>
> readelf: Error: Section 15 has invalid sh_entsize of 5a794
> readelf: Error: (Using the expec
On Thu, Jun 26, 2014 at 10:27 PM, Mukundan Ragavan
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
> I think having a "trivial patch" policy and proven packager route of
> implementation is a great idea!
>
> On 06/26/2014 11:42 AM, Kevin Fenzi wrote:
>> provenpackagers who would be
On 2014-06-27 07:09, Mikolaj Izdebski wrote:
On 06/26/2014 08:01 PM, Yaakov Selkowitz wrote:
As a newcomer to Fedora development, is there something else I should
doing to get these patches reviewed and committed?
I offered you on IRC applying any patches for Java packages, as this is
my area
> Welcome to the 21st century!
Do we have different eyes and brains than we did last century?
Because otherwise, excessively wide paragraphs are just as hard to
read now as they were then.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
/usr/lib/libedelib.so.2.1.0 is quite corrupted. ldd thinks it's
statically linked, and readelf reports these errors (among others0.
readelf: Error: Section 15 has invalid sh_entsize of 5a794
readelf: Error: (Using the expected size of 12 for the rest of this dump)
readelf: Error: Section 16 has
On Fri, Jun 27, 2014 at 7:35 PM, Kevin Fenzi wrote:
> On Fri, 27 Jun 2014 19:23:04 +0200
> drago01 wrote:
>
>> Why?
>
> My understanding of the process as it exists:
>
> Download drpm.
> Take drpm contents + old package files installed locally that were not
> changed and create updated rpm.
> yum
On Fri, 27 Jun 2014 19:23:04 +0200
drago01 wrote:
> Why?
My understanding of the process as it exists:
Download drpm.
Take drpm contents + old package files installed locally that were not
changed and create updated rpm.
yum/dnf hands off this updated new version to rpm as normal.
If they
On Fri, Jun 27, 2014 at 7:13 PM, Kevin Fenzi wrote:
> On Fri, 27 Jun 2014 19:11:53 +0200
> drago01 wrote:
>
>> That wasn't about "poor" as in slow vs. "great" as in fast but
>> bandwith capped vs. not.
>>
>> If building deltas are slow the solution is not to disable them but to
>> find out why th
On Fri, Jun 27, 2014 at 7:21 PM, Kevin Fenzi wrote:
> On Fri, 27 Jun 2014 19:18:15 +0200
> drago01 wrote:
>
>> On Fri, Jun 27, 2014 at 7:13 PM, Kevin Fenzi wrote:
>> > On Fri, 27 Jun 2014 19:11:53 +0200
>> > drago01 wrote:
>> >
>> >> That wasn't about "poor" as in slow vs. "great" as in fast bu
On Fri, 27 Jun 2014 19:18:15 +0200
drago01 wrote:
> On Fri, Jun 27, 2014 at 7:13 PM, Kevin Fenzi wrote:
> > On Fri, 27 Jun 2014 19:11:53 +0200
> > drago01 wrote:
> >
> >> That wasn't about "poor" as in slow vs. "great" as in fast but
> >> bandwith capped vs. not.
> >>
> >> If building deltas ar
On Fri, Jun 27, 2014 at 7:13 PM, Kevin Fenzi wrote:
> On Fri, 27 Jun 2014 19:11:53 +0200
> drago01 wrote:
>
>> That wasn't about "poor" as in slow vs. "great" as in fast but
>> bandwith capped vs. not.
>>
>> If building deltas are slow the solution is not to disable them but to
>> find out why th
On Fri, 27 Jun 2014 19:11:53 +0200
drago01 wrote:
> That wasn't about "poor" as in slow vs. "great" as in fast but
> bandwith capped vs. not.
>
> If building deltas are slow the solution is not to disable them but to
> find out why there are slow and fix that. One thing for instance is
> that it
On Fri, Jun 27, 2014 at 6:14 PM, Jon wrote:
> I personally tend to agree with Troy.
>
> We should consider defaulting to disable delta rpm at most, and at
> least comment the configs, or make things intelligent.
>
> For me, it takes longer to process delta rpm files than to download
> the actual f
On Fri, Jun 27, 2014 at 6:14 PM, Jon wrote:
> I personally tend to agree with Troy.
>
> We should consider defaulting to disable delta rpm at most, and at
> least comment the configs, or make things intelligent.
>
> For me, it takes longer to process delta rpm files than to download
> the actual f
On Fri, Jun 27, 2014 at 12:13 PM, Phil Knirsch wrote:
> Hi everyone.
>
> As Bill Nottingham has decided to resign from the committee we now have a
> free seat that we'd like to fill with another person.
That should be two seats. I also resigned. If there was confusion
around that, my apologies.
Hi
On Fri, Jun 27, 2014 at 12:07 PM, Troy Daws
> All that being said, what is the criteria for getting a default
> configuration line put into yum.conf?
> I'd really like to get the deltarpm= line put in there.
>
File a bug report in yum bug tracker or Red Hat bugzilla against yum as the
compon
On Fri, 27 Jun 2014 11:55:37 -0400 (EDT)
Miloslav Trmač wrote:
> That’s only in some ideal case where we can get all the manpower we
> might need.
>
> Adding a non-upstream patch to a package by a non-owner of the
> package essentially commits the owner of the package to either push
> the patch
Welcome to the 21st century!
https://bugzilla.redhat.com/show_bug.cgi?id=1114075
poma
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Sat, Jun 28, 2014 at 12:34 AM, Juan Orti Alcaine
wrote:
> El Sábado, 28 de junio de 2014 00:31:26 Christopher Meng escribió:
> Thank you.
It's better to nofity him about his archaic email address IMO, as he
uses his working address in the %changelog[1] but not in the whole
system.
[1]---http:
El Sábado, 28 de junio de 2014 00:31:26 Christopher Meng escribió:
> On Sat, Jun 28, 2014 at 12:17 AM, Bruno Wolff III wrote:
> > He is or was a Red Hat employee.
>
> No.
>
> Please use this email address:
(...)
Thank you.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedor
On Sat, Jun 28, 2014 at 12:17 AM, Bruno Wolff III wrote:
> He is or was a Red Hat employee.
No.
Please use this email address:
vanmeeuwen.kolabsys@com (@ <-> .)
Thanks.
Yours sincerely,
Christopher Meng
Noob here.
http://cicku.me
--
devel mailing list
devel@lists.fedoraproject.org
https://
On Fri, Jun 27, 2014 at 11:07 AM, Troy Dawson wrote:
>
> Cool,
> I'm glad it's in the man pages now. It isn't in the man pages of my
> older versions of yum.
> And it's actually a very good section, talking about how it determines
> how many threads to use.
>
> Now that we've established that, w
On 06/27/2014 05:50 PM, Miloslav Trmač wrote:
- Original Message -
- Should this be rawhide only? That would avoid 'trivial' patches that
cause a problem from affecting users that aren't as able to debug
them.
Probably (or perhaps it could be up to the provenpackager applying the
On Fri, Jun 27, 2014 at 17:50:31 +0200,
Juan Orti Alcaine wrote:
FAS user kanarip is comaintainer of one of my packages, and I receive mail
bounces of their email address . It seems like the domain
is no longer valid:
Following the policy, I ask the list if anyone knows how to contact this
I personally tend to agree with Troy.
We should consider defaulting to disable delta rpm at most, and at
least comment the configs, or make things intelligent.
For me, it takes longer to process delta rpm files than to download
the actual full rpm, even on high end systems, or low end.
I suppose
Hi everyone.
As Bill Nottingham has decided to resign from the committee we now have
a free seat that we'd like to fill with another person.
In order to fill this seat i'm therefore reaching out here to Fedora
development to offer allow any applicant from the community to get in
touch with u
On Fri, 2014-06-20 at 17:25 -0700, Adam Williamson wrote:
> I've drafted a comps change (further to the quick one I did yesterday to
> throw in NetworkManager-wifi to the desktop groups) to account for the
> recent (March) split of several bits of NetworkManager functionality
> into subpackages. As
On 06/27/2014 10:45 AM, Rahul Sundaram wrote:
> Hi
>
>
> On Fri, Jun 27, 2014 at 11:26 AM, Troy Dawson wrote:
>
>
>
> It is a hidden default that is not in any man page or documentation.
> Yes, I used a poor choice of words.
>
>
> man yum.conf
>
> deltarpm
>
> When n
On 06/27/2014 05:50 PM, Rahul Sundaram wrote:
Hi
On Fri, Jun 27, 2014 at 11:36 AM, Yaakov Selkowitz wrote:
On 2014-06-27 10:17, Till Maas wrote:
Yes, I missed this as well. Also IIRC the guidelines demand an patch
status comment for each patch in the spec file, so just add
On 06/27/2014 05:17 PM, Till Maas wrote:
On Fri, Jun 27, 2014 at 10:05:31AM +0200, Dan Horák wrote:
oh, that's an impressive list, but I would like see to one more thing
there - links to upstream bug reports where relevant (eg. fixing
configure stuff), because we usually need them fixed in upst
- Original Message -
> On 06/27/2014 08:26 AM, Marcela Mašláňová wrote:
>
> > I'm not sure if it's so great idea for all bugzillas. Some packagers
> > prefer to add patches first into upstream then carry a patch for many
> > releases.
> This consideration actually is pretty much irrelevant
2014-06-27 16:45 GMT+02:00 Miroslav Suchý :
> Does koji use state plugin? If yes, it must be disabled:
> /etc/mock/site-defaults.cfg
> config_opts['plugin_conf']['package_state_enable'] = False
> Because state plugin require yum-utils-1.1.31 which are not in el6.
>
Not sure about this, it's t
- Original Message -
> - Should this be rawhide only? That would avoid 'trivial' patches that
> cause a problem from affecting users that aren't as able to debug
> them.
Probably (or perhaps it could be up to the provenpackager applying the patch,
but with rawhide-only being the expec
Hello,
FAS user kanarip is comaintainer of one of my packages, and I receive mail
bounces of their email address . It seems like the domain
is no longer valid:
(expanded from ):
Host or domain name not found. Name service error for name=kanarip.com
type=A: Host found but no data record
Hi
On Fri, Jun 27, 2014 at 11:36 AM, Yaakov Selkowitz wrote:
> On 2014-06-27 10:17, Till Maas wrote:
>
>> Yes, I missed this as well. Also IIRC the guidelines demand an patch
>> status comment for each patch in the spec file, so just adding patch
>> without noting why it is not upstreamable or i
Hi
On Fri, Jun 27, 2014 at 11:26 AM, Troy Dawson wrote:
>
>
> It is a hidden default that is not in any man page or documentation.
> Yes, I used a poor choice of words.
>
man yum.conf
deltarpm
When non-zero, delta-RPM files are used if available. The
value
speci
Hi all,
Rpm 4.12 alpha just got released:
http://lists.rpm.org/pipermail/rpm-announce/2014-June/45.html
The plan is to update rawhide to this shiny new version first thing on
Monday morning and babysit as needed (ie the usual drill), but if you're
feeling bored over the weekend or its a
On 2014-06-27 10:17, Till Maas wrote:
Yes, I missed this as well. Also IIRC the guidelines demand an patch
status comment for each patch in the spec file, so just adding patch
without noting why it is not upstreamable or information about when/how
it was upstreamed is bad and should IMHO not be d
Hi Troy,
On 27/06/14 16:26, Troy Dawson wrote:
It is a hidden default that is not in any man page or documentation.
Did you look for deltarpm in the yum.conf man page? If it's missing then
that might be the problem (it's there on my x86_64 F20 machines at least).
Cheers,
Andy
--
devel maili
On 06/27/2014 09:17 AM, Rahul Sundaram wrote:
> Hi
>
>
> On Fri, Jun 27, 2014 at 10:07 AM, Troy Dawson wrote:
>
> The fact that Fedora practically forces people to use delta rpm's has
> rattled my cage for quite a while.
>
>
> [Snipped]
>
> --- Does it force you to do them like
On Fri, Jun 27, 2014 at 10:05:31AM +0200, Dan Horák wrote:
> oh, that's an impressive list, but I would like see to one more thing
> there - links to upstream bug reports where relevant (eg. fixing
> configure stuff), because we usually need them fixed in upstreams too
Yes, I missed this as well.
On Fri, 27 Jun 2014 10:47:09 +0200
Florian Weimer wrote:
> On 06/26/2014 06:42 PM, Kevin Fenzi wrote:
> > Another idea that leaps to mind is to add more provenpackagers...
> > have we set the bar too high so no one wants to apply?
>
> Debian has packages in collab-maint, where any Debian Develop
On Fri, 27 Jun 2014 22:03:30 +0800
Christopher Meng wrote:
> My opinion is, you should only comaintain what you want, not take over
> other's packages.
>
> If FESCo member could give consent of adding someone as an admin(not
> the point of the contact) of a package instead of orphaning lots of
>
On Fri, 2014-06-27 at 12:48 +0200, Sandro Mani wrote:
> So just to clarify here: the idea behind my proposal is not
> necessarily
> to aid people who often fix large number of small bugs across
> packages,
> for such people it is best if they applied for proven packager
> status.
> What I'm more
On Fri, 2014-06-27 at 08:58 +0200, Ralf Corsepius wrote:
> This consideration actually is pretty much irrelevant when it comes
> to
> bugs. The only thing that counts is Fedora end-user experience, to
> whom
> it's quite irrelevant who fixes a bug.
>
> In other words, if bug affects users, these
On 06/27/2014 04:19 PM, Dominic Hopf wrote:
Greetings,
I'm having an issue when trying to build a package for EPEL6, see the root.log
here:
https://kojipkgs.fedoraproject.org//work/tasks/3518/7083518/root.log
Any ideas if i'm doing something wrong or if this is a serious issue?
Regards,
Domi
Greetings,
I'm having an issue when trying to build a package for EPEL6, see the
root.log here:
https://kojipkgs.fedoraproject.org//work/tasks/3518/7083518/root.log
Any ideas if i'm doing something wrong or if this is a serious issue?
Regards,
Dominic
--
Diese E-Mail ist nicht mit GPG sig
Hi
On Fri, Jun 27, 2014 at 10:07 AM, Troy Dawson wrote:
> The fact that Fedora practically forces people to use delta rpm's has
> rattled my cage for quite a while.
>
[Snipped]
--- Does it force you to do them like yum does?
>
[Snipped]
You keep calling it force while acknowledging it is m
Hi,
I have a very small server room. It has very good network, but lots of
not very powerful computers. Many of them are ARM based.
As I hear about ARM users taking 8 hours to update 1 package (I've had
it take 12 hours to fail to update a package) I irritates me.
The fact that Fedora practical
My opinion is, you should only comaintain what you want, not take over
other's packages.
If FESCo member could give consent of adding someone as an admin(not
the point of the contact) of a package instead of orphaning lots of
packages, that will be helpful.
Thanks.
--
devel mailing list
devel@li
Hello,
On 27 June 2014 12:52, Mikolaj Izdebski wrote:>
Currently guacamole-client is in FTBFS in rawhide [2] and I couldn't find
> > any help for fixing it due to a Maven bug [3], that requires a specific
> > Fedora workaround that I frankly don't understand [4]. On RHEL 7, and
> > Fedora 19/20
On 06/26/2014 10:31 PM, Kevin Fenzi wrote:
On Wed, 25 Jun 2014 18:19:32 +0200
Sandro Mani wrote:
Hi,
Given that no-one seems to know how to contact deji, I'd like to
request the takeover of scotch.
as a fesco member I can ack this.
We will be orphaning his packages and you can pick up scot
- Original Message -
> Agenda:
> - Collect and discuss candidates for open positions in WG
> - Updated on help for Base WG (pknirsch)
> - Open floor
Unfortunately I can't attend today, I have conflicting meeting today :(.
R.
> Thanks & regards, Phil
>
> --
> Philipp Knirsch
Agenda:
- Collect and discuss candidates for open positions in WG
- Updated on help for Base WG (pknirsch)
- Open floor
Thanks & regards, Phil
--
Philipp Knirsch | Tel.: +49-711-96437-470
Manager Core Services| Fax.: +49-711-96437-111
Red Hat GmbH | Emai
On 06/26/2014 08:01 PM, Yaakov Selkowitz wrote:
> On 2014-06-26 11:17, Richard Hughes wrote:
>> On 26 June 2014 17:02, Simone Caronni wrote:
>>> +1 from me!
>>
>> If it's a trivial patch then I think it makes sense to just do it.
>> From someone that touches hundreds of different projects every m
On 06/27/2014 09:45 AM, Simone Caronni wrote:
> Hello,
>
> I'm looking for co-maintainers for the Guacamole [1] stack packages. It is
> an HTML 5 plugin-less remote desktop for VNC, RDP, SSH, Telnet and Spice
> (WIP). Upstream is really responsive, software is updated frequently and
> it's really
On 26.06.2014 21:40, Bruno Wolff III wrote:
On Thu, Jun 26, 2014 at 10:42:17 -0600,
Kevin Fenzi wrote:
Another idea that leaps to mind is to add more provenpackagers...
have we set the bar too high so no one wants to apply?
Trivial bug fixing across the project seems to be a reasonable
ju
On Thu, Jun 26, 2014 at 03:27:21PM -0500, Mukundan Ragavan wrote:
> Isn't it best for the project as a whole to have the bar for proven
> packager high? :)
I think it is detrimental. If someone has loads of time to do bugfixes
across packages, let them. I do loads and loads of trivial bugfixes (no
On 06/27/2014 10:46 AM, Florian Weimer wrote:
On 06/27/2014 08:58 AM, Ralf Corsepius wrote:
This consideration actually is pretty much irrelevant when it comes to
bugs. The only thing that counts is Fedora end-user experience, to whom
it's quite irrelevant who fixes a bug.
Is this really true?
On 06/26/2014 06:42 PM, Kevin Fenzi wrote:
Another idea that leaps to mind is to add more provenpackagers...
have we set the bar too high so no one wants to apply?
Debian has packages in collab-maint, where any Debian Developer can make
changes and upload them. In Debian, this is purely a soc
On 06/27/2014 08:58 AM, Ralf Corsepius wrote:
This consideration actually is pretty much irrelevant when it comes to
bugs. The only thing that counts is Fedora end-user experience, to whom
it's quite irrelevant who fixes a bug.
Is this really true? I'm under the impression that Fedora also car
On Thu, 26 Jun 2014 17:53:08 -0500
Yaakov Selkowitz wrote:
> On 2014-06-26 15:33, Kevin Fenzi wrote:
> > On Thu, 26 Jun 2014 13:01:05 -0500 Yaakov Selkowitz wrote:
> >> This seems to be particularly needed around mass rebuilds, which
> >> IMHO should be an "all-hands-on-deck" time. For example,
On 26 June 2014 23:53, Yaakov Selkowitz wrote:
> Here are my unreviewed patches from last week or earlier, oldest to newest:
Someone make this person a provenpackager.
Richard.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code
Hello,
I'm looking for co-maintainers for the Guacamole [1] stack packages. It is
an HTML 5 plugin-less remote desktop for VNC, RDP, SSH, Telnet and Spice
(WIP). Upstream is really responsive, software is updated frequently and
it's really amazing.
I've been able to throw a bunch of Citrix XenApp
On 06/27/2014 08:26 AM, Marcela Mašláňová wrote:
I'm not sure if it's so great idea for all bugzillas. Some packagers
prefer to add patches first into upstream then carry a patch for many
releases.
This consideration actually is pretty much irrelevant when it comes to
bugs. The only thing that
77 matches
Mail list logo