Re: F27 Self Contained Change: New default cipher in OpenVPN
On 07/20/2017 02:09 AM, David Sommerseth wrote:
> On 18/07/17 22:55, Farkas Levente wrote:
>> On 07/18/2017 10:03 PM, David Sommerseth wrote:
>>> On 18/07/17 17:50, Farkas Levente wrote:
>>>> On 07/18/2017 03:55 PM, Jaroslav Reznik wrote:
>>>>> This will result in the following:
>>>>> * OpenVPN 2.4 based clients will automatically upgrade to AES-256-GCM,
>>>>> regardless if they have --cipher in their configuration file or not.
>>>>> For OpenVPN v2.4 configurations not wanting this cipher upgrade, the
>>>>> client configuration needs to deploy --ncp-disable.
>>>>> * OpenVPN 2.3 based clients and older (and v2.4 clients using
>>>>> --ncp-disable in the client configuration) can connect to the server
>>>>> using any of the --ncp-ciphers list; this is what is called "poor
>>>>> man's cipher negotiation" by the upstream OpenVPN developers.
>>>>> * Any client not providing --cipher defaults to BF-CBC. These clients
>>>>> should still be able to connect to the server as the server allows
>>>>> BF-CBC through --ncp-ciphers.
>>>>
>>>> unfortunately it's not working:-(
>>>> it takes me long time to debug it on my own server and a long discussion
>>>> in this ticket:
>>>> https://community.openvpn.net/openvpn/ticket/886
>>>> it's not possible to set
>>>> cipher AES-256-GCM
>>>> since in this case old clients eg android client which not updated to
>>>> 2.4.x are not able to connect.
>>>
>>> The issue I believe you refer to ("unreliable NCP") should be fixed in
>>> OpenVPN v2.4.3.
>>> <https://community.openvpn.net/openvpn/ticket/887#comment:13>
>>
>> this means only a few weeks ago...
>> imho openvpn is _very_ widely used and if it's break anything it's break
>> a lots of thing...
>> i'd rather postpone it to f28 when it's fully tested and stabilized.
>
> What is the benefit of postponing based on a bug which have been fixed?
> And have been tested? And where the test process should reasonably
> thoroughly documented and can be verified by others?
>
> Also considering that we're just in the very early planning phase of
> F-27 and F-26 have just been released. So F-27 is at least 6 months
> ahead of us. Which means the NCP feature will be at least 1 year old,
> with the last fix making this work will be 6 months - which should be
> plenty of time to test this out. Plus considering that OpenVPN is
> deployed elsewhere in much grander scales than Fedora alone where also
> NCP is getting more and more used and rolled out in similar ways as this
> proposal. So this is also being tested outside the Fedora universe as well.
if this is so obvious and has only benefits and at the same time you
also upstream developer why the upstream openvpn not change it's
default? since it'll exactly has the same effect as it's changed in
fedora and in this case fedora don't have to do anything.
--
Levente "Si vis pacem para bellum!"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 Self Contained Change: New default cipher in OpenVPN
On 07/18/2017 10:03 PM, David Sommerseth wrote:
> On 18/07/17 17:50, Farkas Levente wrote:
>> On 07/18/2017 03:55 PM, Jaroslav Reznik wrote:
>>> This will result in the following:
>>> * OpenVPN 2.4 based clients will automatically upgrade to AES-256-GCM,
>>> regardless if they have --cipher in their configuration file or not.
>>> For OpenVPN v2.4 configurations not wanting this cipher upgrade, the
>>> client configuration needs to deploy --ncp-disable.
>>> * OpenVPN 2.3 based clients and older (and v2.4 clients using
>>> --ncp-disable in the client configuration) can connect to the server
>>> using any of the --ncp-ciphers list; this is what is called "poor
>>> man's cipher negotiation" by the upstream OpenVPN developers.
>>> * Any client not providing --cipher defaults to BF-CBC. These clients
>>> should still be able to connect to the server as the server allows
>>> BF-CBC through --ncp-ciphers.
>>
>> unfortunately it's not working:-(
>> it takes me long time to debug it on my own server and a long discussion
>> in this ticket:
>> https://community.openvpn.net/openvpn/ticket/886
>> it's not possible to set
>> cipher AES-256-GCM
>> since in this case old clients eg android client which not updated to
>> 2.4.x are not able to connect.
>
> The issue I believe you refer to ("unreliable NCP") should be fixed in
> OpenVPN v2.4.3.
> <https://community.openvpn.net/openvpn/ticket/887#comment:13>
this means only a few weeks ago...
imho openvpn is _very_ widely used and if it's break anything it's break
a lots of thing...
i'd rather postpone it to f28 when it's fully tested and stabilized.
--
Levente "Si vis pacem para bellum!"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 Self Contained Change: New default cipher in OpenVPN
On 07/18/2017 03:55 PM, Jaroslav Reznik wrote: > This will result in the following: > * OpenVPN 2.4 based clients will automatically upgrade to AES-256-GCM, > regardless if they have --cipher in their configuration file or not. > For OpenVPN v2.4 configurations not wanting this cipher upgrade, the > client configuration needs to deploy --ncp-disable. > * OpenVPN 2.3 based clients and older (and v2.4 clients using > --ncp-disable in the client configuration) can connect to the server > using any of the --ncp-ciphers list; this is what is called "poor > man's cipher negotiation" by the upstream OpenVPN developers. > * Any client not providing --cipher defaults to BF-CBC. These clients > should still be able to connect to the server as the server allows > BF-CBC through --ncp-ciphers. unfortunately it's not working:-( it takes me long time to debug it on my own server and a long discussion in this ticket: https://community.openvpn.net/openvpn/ticket/886 it's not possible to set cipher AES-256-GCM since in this case old clients eg android client which not updated to 2.4.x are not able to connect. -- Levente "Si vis pacem para bellum!" ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: blivet-gui announcement
On 09/05/2014 06:03 PM, Lennart Poettering wrote: On Fri, 05.09.14 11:52, Matthias Clasen (mcla...@redhat.com) wrote: On Fri, 2014-09-05 at 15:55 +0200, Vratislav Podzimek wrote: On Fri, 2014-09-05 at 09:04 -0400, Bastien Nocera wrote: - Original Message - Good news, everyone! We (me and CC'd Vojtech Trefny) would like to introduce you the next generation tool for storage management -- the **blivet-gui** tool [1]_. It is a GUI tool based on the blivet python library (originally Anaconda's storage management and configuration tool) inspired by GParted and other storage management tools. Why not use GParted you ask? Actually my question is why not gnome-disk-utility? :) Because it doesn't work well with LVM, RAID, BTRFS and a combination of them. Leaving LVM out was an explicit decision, because of all the system integration problems with LVM. It works fine with RAID and btrfs as far as I know. Do you have any concrete complaints about the RAID or btrfs support in gnome-disk-utility ? Also, note that gnome-disk-utility actually properly separates out the unpriviliged UI from the priviliged backend in udisks. In this day-and-age we should not write new programs anymore that require the entire UI stack to run as root. We should really get away from doing something like that. In the blivet-ui docs su is the recommended way to invoke the program, and that's really wrong for a graphical one. gnome-disk-utility got that right. the new blivet ui did not. And this is not something you can add as an afterthought, you actually need to do your homework and split things up into privileged and non-priviliged parts from the beginning. The blivet-ui thing in this regard is certainly not an improvement over g-d-u, it's a step back. system-config-lvm was removed from rhel7 while g-d-u is not able to configure lvm. so it _definitely_ a step forward. and really not agree with you about the root user usage. you imho those who would like to configure disk and lvm should have to be root privileges and should have to know what he does. it's again so lennartish when you belive a buggy pulse is better then a working alsa if the concept is better. NO simple it's not true. a usable working program always better the a perfectly design idealism which never really works. -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: blivet-gui announcement
On 09/05/2014 09:27 PM, Matthias Clasen wrote: On Fri, 2014-09-05 at 20:53 +0200, Farkas Levente wrote: system-config-lvm was removed from rhel7 while g-d-u is not able to configure lvm. so it _definitely_ a step forward. and really not agree with you about the root user usage. you imho those who would like to configure disk and lvm should have to be root privileges and should have to know what he does. it's again so lennartish when you belive a buggy pulse is better then a working alsa if the concept is better. NO simple it's not true. a usable working program always better the a perfectly design idealism which never really works. I don' think this is a productive direction to take this discussion in. This has nothing to do with Lennart, alsa or idealism. Separating the privileged mechanism from the UI is really not 'design idealism', but simply with good engineering practice. Pointing this out is not being a 'negative nelly' either, but providing constructive feedback. if you read lennart mail you can see it's a step back which is an idealism and which is what i really replying. -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf replacement for yum-cron
On 06/16/2014 05:06 PM, drago01 wrote: On Mon, Jun 16, 2014 at 4:53 PM, Matthew Miller mat...@fedoraproject.org wrote: On Mon, Jun 16, 2014 at 09:11:43AM -0500, Jeffrey Ollie wrote: Been using yum-cron for years with good results. If yum is being phased out, I'll want a dnf-cron replacement Already exists: $ rpm -ql dnf | grep systemd /usr/lib/systemd/system/dnf-makecache.service /usr/lib/systemd/system/dnf-makecache.timer $ cat /usr/lib/systemd/system/dnf-makecache.service [Unit] Description=dnf makecache That's not the most descriptiony of all descriptions ever, but if the name is any indication, it is just a thing which keeps the cache up to date. yum-cron can actually apply updates [] That sounds dangerous ... updates are not really atomic (i.e not at all) doing them silently in the background is a very bad idea. if you think it's dangerous don't use it! but it's not a reason! and since many of us use it since many years we still wanna use it. and if dnf has not as feature rich as yum + yum-utils + yum-cron then probably it's not a 'replacement' for yum. and those who prefer dnf in stead of yum still can replace it. -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Java 8
is this version of eclipse be ported to rhel dev tools for rhel-6 and rhel-7? On 05/06/2014 09:50 AM, Aleksandar Kurtakov wrote: One of the biggest offenders (Eclipse) is now happily compiling(always has been running fine) with Java 8 and while looking at fixing it many other issues has been identified and fixed so personally I'm fine with OpenJDK7 being obsoleted now. Alexander Kurtakov Red Hat Eclipse team - Original Message - From: Aleksandar Kurtakov akurt...@redhat.com To: Deepak Bhole dbh...@redhat.com, Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Wednesday, March 26, 2014 3:41:30 PM Subject: Re: F21 System Wide Change: Java 8 I'm not proposing having OpenJDK7 in Fedora 21. What I'm asking for is to have them both for a month or two before obsoleting so transition can be smoother if problems appear. Alexander Kurtakov Red Hat Eclipse team - Original Message - From: Deepak Bhole dbh...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Wednesday, March 26, 2014 3:31:59 PM Subject: Re: F21 System Wide Change: Java 8 * Christopher ctubb...@apache.org [2014-03-25 19:59]: I also would like to see 1.7.0 stick around for awhile. Not necessarily as the default, but at least available in the repos. As it stands, it's difficult to use a modern Fedora on projects that are still developing against JDK 1.6. Unfortunately, OpenJDK7 will be EOLd in April 2015[1], which is within the support time-frame of the F21. This is one the reasons why we would like to be able to switch over to OpenJDK8 asap for F21. 1: http://www.oracle.com/technetwork/java/eol-135779.html Deepak -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Mar 25, 2014 at 4:05 PM, Aleksandar Kurtakov akurt...@redhat.com wrote: Please keep java 1.7.0 around for some time. It would make moving easier if we have to jump back for a build or two. Alexander Kurtakov Red Hat Eclipse team - Original Message - From: Omair Majid oma...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Tuesday, March 25, 2014 9:07:39 PM Subject: Re: F21 System Wide Change: Java 8 * Mikolaj Izdebski mizde...@redhat.com [2014-03-24 11:55]: That's exactly the problem. We need to use a modified version of java-1.8.0-openjdk with extra provides and adjusted priorities for alternatives. I have started a new java-1.8.0-openjdk build that should fix this: http://koji.fedoraproject.org/koji/buildinfo?buildID=506921 Blocking java-1.7.0-oepnjdk may also be required. This makes it impossible to scratch-build Java packages using f21-build target in current state. Is there anything I can/should do here? Shall I file a rel-eng ticket to block java-1.7.0-openjdk? Would it be worth waiting a little while to ensure that there are no show-stopper bugs in java-1.8.0-openjdk? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: when startup delays become bugs
On 05/15/2013 02:48 PM, Lennart Poettering wrote: On Wed, 15.05.13 07:45, Dan Williams (d...@redhat.com) wrote: Is anything waiting on NetworkManager-wait-online in your install? That target is really intended for servers where you want to block Apache or Sendmail or Database from starting until you're sure your networking is fully configured. If you don't have any services that require a network to be up, then you can mask NetworkManager-wait-online and things will be more parallel. Dan, could you please implement these recommendations for F19: https://bugzilla.redhat.com/show_bug.cgi?id=787314#c37 This really shouldn't be pulled in unconditionally... The changes you suggest there seem fine; one question about After=syslog.target being removed though: intentional? I pretty much just take your guidance on the .service files. After=syslog.target is unnecessary these days and should be removed from all unit files, to keep things simple. We nowadays require syslog implementations to be socket activatable, and that socket is around before normal services start, and that's guaranteed, hence nobody has to depend on syslog explicitly anymore. All services will have logging available anyway, out-of-the-box, as default, with no manual configuration necessary, and without any referring to syslog.target. is it documented? in many of your mails in this thread you wrote nowadays, anymore, default, modern system, modern hardware, etc... does it documented anywhere? what are the assumptions and how nowadays fedora should have to work? -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mission Impossible #1: qt without gtk
On 04/28/2013 10:58 PM, Rex Dieter wrote: Eugene Pivnev wrote: As I'm trying to create gtk-/gnome-/kde*-free environment (QtDesktop) - I tested - what about Fedora without them? So: 1. yum remove gtk3: ... * gvfs * qt-mobility * qtwebkit * ffmpeg * ffmpeg-libs * mplayer * phonon * smplayer 2. yum remove gtk2: all above+ * ImageMagick The yum output from the above commands gives the why (admittedly in great detail, so it's probably difficult to make sense of), but... At least, one chain of dependencies is: qtwebkit/qt-mobility/phonon - ... - gstreamer and gstreamer - ... - gtk2/gtk3 gtk or glib? imho gstreamer requires only glib... -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another glibc change that nearly got pushed into F16
On 10/26/2011 10:45 AM, Richard W.M. Jones wrote: I forgot to add that it's probably a good idea to recompile any package that was compiled against the -13 glibc package. Strictly speaking, any package that uses a function that is defined with __THROW or __NTH in the glibc header files, but it's probably easier to compile every package. Is there a Koji query to get a list of such packages? which means delay f16, create a stable glibc, test it, then make a massrebuild and test again the result... -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tcplay: BSD-licensed alternative to TrueCrypt
On 10/07/2011 09:25 PM, Richard W.M. Jones wrote: On Fri, Oct 07, 2011 at 02:51:26PM -0400, Tom Callaway wrote: On 10/06/2011 04:54 PM, Richard Shaw wrote: On Thu, Oct 6, 2011 at 3:28 PM, T.C. Hollingsworth tchollingswo...@gmail.com wrote: On Thu, Oct 6, 2011 at 4:54 AM, Richard Shaw hobbes1...@gmail.com wrote: If I remember correctly it's not that TrueCrypt is non-free, but that the license is incompatible with Fedora and upstream was not willing to budge on that so it was re-branded instead. The TrueCrypt License is, in fact, non-free for several reasons: http://lists.freedesktop.org/archives/distributions/2008-October/000276.html That's being rather pedantic... Yes it's considered non-free because of the screwy licensing agreement, however, the software is free to download and use, it is open source. TrueCrypt is definitely not Free Software. A simple rebranding to prevent use of their trademark is not sufficient to make it Free Software. It is also not Open Source, as it fails several of the OSI Open Source Definition criteria. In addition, I have strong reason to believe that the license in TrueCrypt is carefully crafted to incorporate legal conditions where the TrueCrypt upstream could do all sorts of really really nasty and horrible things, including suing users for _complying_ with the terms of the license. When I pointed this out to TrueCrypt's upstream in 2008, their answer was basically Yeah, so what?. Stand far, far, far away. Is there any reason to use TrueCrypt, over the whole disk encryption that Fedora already provides? LUKS just works afaict ... works on both linux and windows:-) while you use it on windows since it has a lots of features you can also use you pendrive on linux...and there is no alternative:-( -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide
On 10/05/2011 12:47 AM, Richard W.M. Jones wrote: On Tue, Oct 04, 2011 at 11:38:18PM +0200, Farkas Levente wrote: On 10/04/2011 05:30 PM, Eric Sandeen wrote: XFS has been proven at this scale on Linux for a very long time, is all. the why rh do NOT support it in 32 bit? there're still system that should have to run on 32 bit:-( 32-bit machines have a 32-bit index into the page cache; on x86, that limits us to 16T for XFS, as well. So 32-bit is really not that interesting for large filesystem use. If you need really scalable filesystems, I'd suggest a 64-bit machine. i mean if you support xfs and think it's better then ext4 why not support it on rhel 32bit? This is a question you should direct through Red Hat's support channels. i'm just like to ask Erik's opinion (who seems to be the fs people at rh:-) -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide
On 10/05/2011 05:42 PM, Eric Sandeen wrote: right; for large ext4 fs use (or testing), try # mkfs.ext4 -E lazy_itable_init=1 /dev/blah this will cause it to skip inode table initialization, and speed up mkfs a LOT. It'll also keep sparse test images smaller. IMHO this should probably be made default above a certain size. The tradeoff is that inode table initialization happens in kernelspace, post-mount - with efforts made to do it in the background, and not impact other I/O too much. Sorry, Lukas reminds me that this should already be the default mode, with a new enough kernel and new enough e2fsprogs. Rawhide should meet those criteria. yes i know it's not rhel list, but still is it working on rhel-6? -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide
On 10/04/2011 01:03 AM, Eric Sandeen wrote: On 10/3/11 5:53 PM, Farkas Levente wrote: On 10/04/2011 12:33 AM, Eric Sandeen wrote: On 10/3/11 5:13 PM, Richard W.M. Jones wrote: On Mon, Oct 03, 2011 at 04:11:28PM -0500, Eric Sandeen wrote: I wasn't able to give the VM enough memory to make this succeed. I've only got 8G on this laptop. Should I need large amounts of memory to create these filesystems? At 100T it doesn't run out of memory, but the man behind the curtain starts to show. The underlying qcow2 file grows to several gigs and I had to kill it. I need to play with the lazy init features of ext4. Rich. Bleah. Care to use xfs? ;) why we've to use xfs? really? nobody really use large fs on linux? or nobody really use rhel? why not the e2fsprogs has too much upstream support? with 2-3TB disk the 16TB fs limit is really funny...or not so funny:-( XFS has been proven at this scale on Linux for a very long time, is all. the why rh do NOT support it in 32 bit? there're still system that should have to run on 32 bit:-( -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide
On 10/04/2011 01:03 AM, Eric Sandeen wrote: Large filesystem support for ext4 has languished upstream for a very long time, and few in the community seemed terribly interested to test it, either. why? that's what i simple do not understand!?... -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide
On 10/04/2011 05:30 PM, Eric Sandeen wrote: XFS has been proven at this scale on Linux for a very long time, is all. the why rh do NOT support it in 32 bit? there're still system that should have to run on 32 bit:-( 32-bit machines have a 32-bit index into the page cache; on x86, that limits us to 16T for XFS, as well. So 32-bit is really not that interesting for large filesystem use. If you need really scalable filesystems, I'd suggest a 64-bit machine. i mean if you support xfs and think it's better then ext4 why not support it on rhel 32bit? -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide
On 10/04/2011 12:33 AM, Eric Sandeen wrote: On 10/3/11 5:13 PM, Richard W.M. Jones wrote: On Mon, Oct 03, 2011 at 04:11:28PM -0500, Eric Sandeen wrote: I wasn't able to give the VM enough memory to make this succeed. I've only got 8G on this laptop. Should I need large amounts of memory to create these filesystems? At 100T it doesn't run out of memory, but the man behind the curtain starts to show. The underlying qcow2 file grows to several gigs and I had to kill it. I need to play with the lazy init features of ext4. Rich. Bleah. Care to use xfs? ;) why we've to use xfs? really? nobody really use large fs on linux? or nobody really use rhel? why not the e2fsprogs has too much upstream support? with 2-3TB disk the 16TB fs limit is really funny...or not so funny:-( -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
noarch vs missing deps
hi, the same problem happened against which i try to discuss earlier. gstreamer-java is pure java package so it'd have to package as a noarch package. which is true and can be working. but it has a subpackage gstreamer-java-swt which is depend on eclipse-swt but still arch independent. but when i try to build it in fedora's mock it goes most of the time (as the noarch packages used to) to the ppc build server which are try to satisfy it's buildreq. but it's depend on libswt3-gtk2 (which is provided by eclipse-swt). but as eclipse can't be build on ppc (at least i assume so) the ppc build server can't build it. even if the resulting jar can be used/run even on windows!? the worst part that i can't write ExcludeArch into a noarch rpm since rpm do not allow it. what is the solution? do i really have to make it none noarch? or try richard's solution ie. try a few build and if it's choose x86 build server then i lucky!:-( regards. -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Btrfs status for F16
On 08/08/2011 04:07 PM, Josef Bacik wrote: On Mon, Aug 8, 2011 at 9:22 AM, Genes MailLists li...@sapience.com wrote: On 08/08/2011 08:55 AM, Josef Bacik wrote: On Mon, Aug 8, 2011 at 8:53 AM, Matej Cepl mc...@redhat.com wrote: On 8.8.2011 14:44, Josef Bacik wrote: I appreciate those who will continue to use it and report bugs, we are working very hard on trying to get everything more stable and it is a slow going process. With your help we will be in a better situation for F17. Thanks, Sounds good ... can you give us an update and ballpark timeline of RAID-5 on btrfs as well if you don't mind? It requires the larger than page size blocksize work which is slated for 3.2, I'm not sure what Chris has in mind specifically but I imagine that stuff will land in 3.2 to get plenty of testing, and then the RAID5 stuff will follow. Or both could land in 3.2, I'm not entirely sure. Thanks, it seems obvious that a lots of people waiting for btrfs. may be it'd useful to create some kind of roadmap, missing features, planed kernel release etc.. it's clear that one of the zfs biggest feature is the raid and fs layer merge. how does it planed in btrfs etc... ps. anyway it was a good decision to shift as default fs. -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Btrfs status for F16
On 08/08/2011 07:48 PM, Peter Robinson wrote: Sounds good ... can you give us an update and ballpark timeline of RAID-5 on btrfs as well if you don't mind? It requires the larger than page size blocksize work which is slated for 3.2, I'm not sure what Chris has in mind specifically but I imagine that stuff will land in 3.2 to get plenty of testing, and then the RAID5 stuff will follow. Or both could land in 3.2, I'm not entirely sure. Thanks, it seems obvious that a lots of people waiting for btrfs. may be it'd useful to create some kind of roadmap, missing features, planed kernel release etc.. it's clear that one of the zfs biggest feature is the raid and fs layer merge. how does it planed in btrfs etc... You mean like this one on the btrfs home page? https://btrfs.wiki.kernel.org/index.php/Main_Page something better. there is no roadmap, who is responsible for what which is the planed kernel version, how do you plane raid-5/6 integration etc... -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS: The Good, The Bad and The Ugly
On 07/13/2011 11:14 PM, Josef Bacik wrote: On Wed, Jul 13, 2011 at 4:53 PM, Manuel Escudero jmlev...@gmail.com wrote: Today I'll be switching from BTRFS to Ext4 again because of the troubles I've been having with the New Linux Filesystem. As BTRFS is going to be the Default in F16 I wanted the developers to know what kind of troubles I've been experiencing with this FS in F15 so they can take a look at them in order to have a better F16 release: The Good: Since BTRFS arrived into my computer (Everything in the HDD is formated with BTRFS excluding /boot) I've seen a performance improvement in the data transfer part from and to the computer (copying files seem to be faster than before) But that's all about the good things I noticed... The Bad: BTRFS has reduced system's overall performance, at this point, sometimes it is OK, sometimes it is VERY BAD, I've noticed Performance Peaks in F15 with BTRFS and the Boot times are not nice: I mean, they are not the slowest ones, but they're not as good as Before in F14 with Ext4 instead of BTRFS. The performance Running/Launching apps has been afected too and now the PC freezes sometimes (that never happened in F14 unless I forced it a lot with 4 VM's to suck the 4GB of RAM I have); And Now it freezes very often when it wants without a lot of effort. The Ugly: Running VM's when having their virtual HDD's stored in a BTRFS partition is DEATH! They're very slow, sometimes they open, sometimes they not, usually they freeze, You can't work with them. Same thing about Gnome Shell working over a BTRFS partition: it is really slow, sometimes it reacts but most of the time is pretty unresponsive. Reading in the Web, I found that some users think that the BTRFS poor performance is caused by some special kind of fragmentation it suffers, others think it's because of it's CopyonWrite attributes and some others blame other stuff, God Knows! the only thing I know is that BTRFS is not ready for being used in normal production machines (as I tought) and it needs to be fixed before the release of F16, because it's performance is really far from good... Other Stuff I noticed is that with Kernel 2.6.38.8-35 the system seems to work better that with the previous one, just a little, but is some kind of improvement. Here you have all the info I found on the net about BTRFS Performance issues noticed by users: https://bugzilla.redhat.com/show_bug.cgi?id=689127 http://arosenfeld.wordpress.com/2010/12/27/back-to-ext4-from-btrfs/ http://www.vyatta4people.org/btrfs-is-a-bad-choice-when-running-kvm/ http://lkml.org/lkml/2010/7/13/475 http://blog.patshead.com/2011/03/btrfs---six-months-later.html I only have a question: Why Any Kind of VM is Sooo Slow when being stored on a BTRFS partition? Any Way to Solve this? or at least have a BTRFS performance improvement? Yeah VMs are a particular problem with Btrfs. There are a ton of reasons for this, for example by default we use fsync. Fsync _sucks_ for btrfs currently, and it has historically not been a well optimized piece of code. I'm working on fixing this, but it requires VFS level changes that are currently sitting in Al's queue. I suspect they will go into 3.1 and so we can move ahead with our work, but for now, it sucks. You can use cache=none you get better performance, but still not that great. And this is all because of one major thing Btrfs has threads for _everything_. This works out fantastically when you have big chunks of reads or writes you want done. This _sucks_ when you are doing little piddly io's. The reason for all of this is because we don't want you to get bottlenecked on us calculating/verifying checksums, so we farm all IO and endio out to different threads, which as I said works out great if you are trying to cram gigs of data down your drives throat. But with VMs you are doing small scattered IO's, so the IO comes down, we prepare it, and farm it off to a thread and wait for that thread to wake up and submit the io. Then the io is completed and that is farmed off to another thread and we wait on that. This switching around and waiting for things to wake up is hugely painful when all you want to do is write a few bytes. If you were to do dd if=/dev/zero of=/mnt/btrfs/file bs=4k count=100 oflag=direct on a btrfs fs and then do it on an ext4 fs, you would see about a 20% difference between the 2. But if you do say bs=20M, the gap closes quite a bit. I fixed part of this problem for O_DIRECT (which is cache=none with qemu), if the IO's are small we don't send it off to a thread but submit it within our threads context, which is what got us with 20% of ext4 as opposed to 50%. The other half is doing the completion in the submitters context, which is going to take some extra work. I'm fixing this in the fsync case as well, but as I said we need a VFS patch to do it properly so that will be a little later coming.
Re: R: Re: Calling autoconf in a spec.
On 07/03/2011 10:34 PM, Kevin Kofler wrote: FWIW, I think we should actually run autoreconf -i -f in ALL specfiles as a matter of policy, even if we aren't changing anything, the same way we require Java JARs to be rebuilt from source. please no! curently most of the fedora packages can be rebuild on rhel/centos. if you change this policy most of the packages will NOT rebuild since most of the new packages requires newer autotools then shipped with rhel/centos! -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive Package Maintainer - Jeroen van Meeuwen
On 06/17/2011 02:01 PM, Vít Ondruch wrote: I'm following the procedure at: http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers Does anyone know how to contact Jeroen van Meeuwen? He is not answering e-mails at his listed address or the following Bugzilla reports: https://bugzilla.redhat.com/show_bug.cgi?id=707934 https://bugzilla.redhat.com/show_bug.cgi?id=707937 There is also many other Jeroen's packages which would need some maintenance. there're dozen of reports about revisor too which is not working on any current fedora and epel either. -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wireless-tools/net-tools are DEPRECATED
On Sun, Apr 24, 2011 at 05:25, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Kevin Kofler kevin.kof...@chello.at said: Newsflash: the network service is DEPRECATED!!! That's what NetworkManager is for. Newsflash: NM doesn't replace the network service yet. Maybe when NM can do everything ifup/ifdown can do, the discussion about deprecation can happen, but until then, please stop saying NM replaces the network service. +1 -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to speed up mock?
On Mon, Jan 18, 2010 at 17:30, Ville Skyttä ville.sky...@iki.fi wrote: On Monday 18 January 2010, Seth Vidal wrote: On Mon, 18 Jan 2010, Farkas Levente wrote: the real bottleneck is not the rpmbuild itself (with ccache it cab be very fast), but the mock surroundings. suppose there is build which takes about 2 minutes and in mock it takes about 5 minutes:-( most of the time is in yum, python tar, gzip etc which all use only one cpu/core and it's very slow! the tar and gzip are mostly BUILDING the cache. I've been using lzop as the root cache compressor, it makes a difference over gzip here, especially when compressing the cache, but somewhat also when decompressing it. Add this to /etc/mock/site-defaults.cfg to try it out: config_opts['plugin_conf']['root_cache_opts']['compress_program'] = 'lzop' config_opts['plugin_conf']['root_cache_opts']['extension'] = '.lzo' For boxes with multiple cores, pigz (and maybe even pbzip2) might be worth looking into. I haven't tried these myself. why we compress at all? disk space is cheep. can we speed up mock to somehow totally disable compressing root_cache? it used the case but store and restore in an uncompressed way? thanks. -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On 10/12/2010 09:53 AM, Gilboa Davara wrote: the other point of richards is what the whole fedora community and redhat should have to understand: most users like ubuntu rather then fedora/redhat. why? because: -... better is what most user like. period. Following your simplistic logic, we should mimic the Windows Vista/7 UAC (Even if it's insecure by design) or even consider running as root by default, why? with better i simple refer here to the style (ie. which one looks better) it's nothing to do functionality or security. of course if you wouldn't like to understand that's a different story. ps. and yes most of the case windows and windows apps looks better the linux and we'd have to learn a lot from them. -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On 10/11/2010 06:09 PM, Jon Masters wrote: On Mon, 2010-10-11 at 17:39 +0200, Gilboa Davara wrote: Comparing the Ubuntu 10.04 DVD installer (which I use a couple of weeks ago) to Fedora 13 DVD installer is like comparing the Cessna to a Boeing 747. Sure, both can accomplish the same task. Read: transporting people from one airport to another, but lets see you try transporting 400 peoples from London to NY using a Cessna... The same logic applies to the Ubuntu installer: As long as you require a fairly basic -desktop- configuration (Read: No fancy storage, no LVM, no fancy setup source [nfs, dvd, http], -very- basic encryption, standard software set and repository selection, etc), the Ubuntu installer is a great tool, but once you need something complex, you're screwed. That's all true. I've found the Ubuntu installer looks /very/ polished and nice for very common install cases, but I always use LVM on every install that I do, and last time I did a VM install of Ubuntu, I had to switch to a VT and get LVM sorted on the command line. Not super user friendly as compared with Anaconda. Other installers were even more of a joke doing this stuff. Tried doing LVM on Gentoo? :) Things like LVM and VNC do really matter, and not just for Enterprise users. You don't need to use LVM w/wo RAID, you can just do bare partitions if you don't care about being able to do anything useful with your disks at all :) imho, the never drop any feature since raid, lvm, iscsi are important (what's more i use them:-), BUT most user don't ie. 80% of the users never use them. it can be an advanced installer option for us, and a basic for average user. the other point of richards is what the whole fedora community and redhat should have to understand: most users like ubuntu rather then fedora/redhat. why? because: - it's looks better. every component looks better, installer, default gnome themes etc. we can make a long discussion about which is better but our opinion simple do not count. better is what most user like. period. - it's easier to use. for average user it's the most important thing. we can always have an advance and basic settings. wouldn't be useful to ask users which they like and try to make fedora/redhat's component better? just my 2c. -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg koji error
On 10/08/2010 03:53 PM, Dennis Gilmore wrote: On Thursday, October 07, 2010 04:25:45 am Thomas Spura wrote: On Wed, 06 Oct 2010 11:19:21 +0200 Farkas Levente wrote: hi, while try to make a scratch build i always got: - # fedpkg scratch-build Could not log into koji: Opening a SSL connection failed - even if i try to remove .fedora.cert and fedora-packager-setup (so it's not a certificate problem). what else can be the reason? thanks in advance. regards. This is because the ssl_login to koji failed, so your SSL key is expired. Generate a new one and upload it to fas: https://admin.fedoraproject.org/accounts/ After waiting an hour or something, it should work again (I hope). Thomas fedora-cert -v will verify if the cert is valid or not. when you need a new cert the recommended way to get it it to use fedora- packager-setup or fedora-cert. you dont upload a ssl cert to fas. and there is no waiting for it to be valid. --- [lfar...@fox jna (f12)]$ fedora-cert -v Verifying Certificate cert expires: 2011-04-06 CRL Checking not implemented yet [lfar...@fox jna (f12)]$ fedpkg build Could not log into koji: Opening a SSL connection failed --- so what's now? -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg koji error
On 10/08/2010 04:28 PM, Dennis Gilmore wrote: On Friday, October 08, 2010 09:15:08 am Farkas Levente wrote: On 10/08/2010 03:53 PM, Dennis Gilmore wrote: On Thursday, October 07, 2010 04:25:45 am Thomas Spura wrote: On Wed, 06 Oct 2010 11:19:21 +0200 Farkas Levente wrote: hi, while try to make a scratch build i always got: - # fedpkg scratch-build Could not log into koji: Opening a SSL connection failed - even if i try to remove .fedora.cert and fedora-packager-setup (so it's not a certificate problem). what else can be the reason? thanks in advance. regards. This is because the ssl_login to koji failed, so your SSL key is expired. Generate a new one and upload it to fas: https://admin.fedoraproject.org/accounts/ After waiting an hour or something, it should work again (I hope). Thomas fedora-cert -v will verify if the cert is valid or not. when you need a new cert the recommended way to get it it to use fedora- packager-setup or fedora-cert. you dont upload a ssl cert to fas. and there is no waiting for it to be valid. --- [lfar...@fox jna (f12)]$ fedora-cert -v Verifying Certificate cert expires: 2011-04-06 CRL Checking not implemented yet [lfar...@fox jna (f12)]$ fedpkg build Could not log into koji: Opening a SSL connection failed --- so what's now? fedpkg -v build [lfar...@eagle jna (f12)]$ fedora-cert -v Verifying Certificate cert expires: 2011-04-06 CRL Checking not implemented yet [lfar...@eagle jna (f12)]$ fedpkg -v build Creating module object from /home/lfarkas/work/lenux/fedora/jna Initiating a koji session to http://koji.fedoraproject.org/kojihub Could not log into koji: Opening a SSL connection failed -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg koji error
On 10/08/2010 07:19 PM, Jesse Keating wrote: On 10/8/10 9:57 AM, Farkas Levente wrote: On 10/08/2010 04:28 PM, Dennis Gilmore wrote: On Friday, October 08, 2010 09:15:08 am Farkas Levente wrote: On 10/08/2010 03:53 PM, Dennis Gilmore wrote: On Thursday, October 07, 2010 04:25:45 am Thomas Spura wrote: On Wed, 06 Oct 2010 11:19:21 +0200 Farkas Levente wrote: hi, while try to make a scratch build i always got: - # fedpkg scratch-build Could not log into koji: Opening a SSL connection failed - even if i try to remove .fedora.cert and fedora-packager-setup (so it's not a certificate problem). what else can be the reason? thanks in advance. regards. This is because the ssl_login to koji failed, so your SSL key is expired. Generate a new one and upload it to fas: https://admin.fedoraproject.org/accounts/ After waiting an hour or something, it should work again (I hope). Thomas fedora-cert -v will verify if the cert is valid or not. when you need a new cert the recommended way to get it it to use fedora- packager-setup or fedora-cert. you dont upload a ssl cert to fas. and there is no waiting for it to be valid. --- [lfar...@fox jna (f12)]$ fedora-cert -v Verifying Certificate cert expires: 2011-04-06 CRL Checking not implemented yet [lfar...@fox jna (f12)]$ fedpkg build Could not log into koji: Opening a SSL connection failed --- so what's now? fedpkg -v build [lfar...@eagle jna (f12)]$ fedora-cert -v Verifying Certificate cert expires: 2011-04-06 CRL Checking not implemented yet [lfar...@eagle jna (f12)]$ fedpkg -v build Creating module object from /home/lfarkas/work/lenux/fedora/jna Initiating a koji session to http://koji.fedoraproject.org/kojihub Could not log into koji: Opening a SSL connection failed What version of nss do you have installed? There was a nss build that could not handle the certs offered by FAS. rhel-6 beta2's nss-3.12.6-3.el6.x86_64 anyway yesterday morning i was not able to build, but afternoot after a new cert ie: fedora-packager-setup i was able to build again. then today i can't build again... -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg koji error
On 10/08/2010 07:57 PM, Jesse Keating wrote: On 10/8/10 10:52 AM, Farkas Levente wrote: rhel-6 beta2's nss-3.12.6-3.el6.x86_64 anyway yesterday morning i was not able to build, but afternoot after a new cert ie: fedora-packager-setup i was able to build again. then today i can't build again... Are you generating the cert on multiple hosts? You can only ever have one cert, you have to copy it manually to all the hosts that you work from. Also, I seem to recall RHEL6's nss having issues with our cert, somebody more familiar with the problem will have to verify though. i synchronize my home and all of my system use rhel-6 beta2 and yesterday i was able to build today i'm not again (and there was not any kind of package in the last few weeks:-). -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git commit in all available branches
On 10/08/2010 04:03 PM, Pavel Alexeev (aka Pahan-Hubbitus) wrote: In most cases I try sync all branches if there no real reasons to make differences. After made some changes in origin/master and commit is I also must do for each available branches something similar: fedpkg switch-branch el5; git pull git merge origin/master git push fedpkg build fedpkg update Off course I can script it with shell, but may be there already possibility to commit in few branches? Something like this: fedpkg commit -F clog -B f12,f13,f14,el5,el6 And will be very cool to start build and push updates (by single template interactively filled one time) also for several branches. +1. i like to do the same. -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg koji error
On 10/08/2010 08:49 PM, Toshio Kuratomi wrote: On Fri, Oct 08, 2010 at 08:09:32PM +0200, Farkas Levente wrote: On 10/08/2010 07:57 PM, Jesse Keating wrote: On 10/8/10 10:52 AM, Farkas Levente wrote: rhel-6 beta2's nss-3.12.6-3.el6.x86_64 anyway yesterday morning i was not able to build, but afternoot after a new cert ie: fedora-packager-setup i was able to build again. then today i can't build again... Are you generating the cert on multiple hosts? You can only ever have one cert, you have to copy it manually to all the hosts that you work from. Also, I seem to recall RHEL6's nss having issues with our cert, somebody more familiar with the problem will have to verify though. i synchronize my home and all of my system use rhel-6 beta2 and yesterday i was able to build today i'm not again (and there was not any kind of package in the last few weeks:-). Okay, here's something to try: python import fedora_cert c = fedora_cert._open_cert() hex(c.get_serial_number()) Looking at our CA, your certificate's serial number should currently be: 3ECB Python 2.6.2 (r262:71600, Jun 22 2010, 15:25:05) [GCC 4.4.4 20100611 (Red Hat 4.4.4-8)] on linux2 Type help, copyright, credits or license for more information. import fedora_cert c = fedora_cert._open_cert() hex(c.get_serial_number()) '0x3ecbL' -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg koji error
On 10/08/2010 08:51 PM, Dennis Gilmore wrote: On Friday, October 08, 2010 01:09:32 pm Farkas Levente wrote: On 10/08/2010 07:57 PM, Jesse Keating wrote: On 10/8/10 10:52 AM, Farkas Levente wrote: rhel-6 beta2's nss-3.12.6-3.el6.x86_64 anyway yesterday morning i was not able to build, but afternoot after a new cert ie: fedora-packager-setup i was able to build again. then today i can't build again... Are you generating the cert on multiple hosts? You can only ever have one cert, you have to copy it manually to all the hosts that you work from. Also, I seem to recall RHEL6's nss having issues with our cert, somebody more familiar with the problem will have to verify though. i synchronize my home and all of my system use rhel-6 beta2 and yesterday i was able to build today i'm not again (and there was not any kind of package in the last few weeks:-). Rhel6's curl doesnt support fas certs. but openssl does since it makes them. does koji list-tasks --mine work? ok. sorry it was my fault:-( one of my machine use koji-1.4.0-4 which is no longer works on rhel-6, just only on fedora. after i downgrade to koji-1.4.0-2 it's start to work again... anyway it'd be useful to keep koji and fedpkg versions consistent on all release (both fedora and rhel) to avoid such problems... -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
fedpkg koji error
hi, while try to make a scratch build i always got: - # fedpkg scratch-build Could not log into koji: Opening a SSL connection failed - even if i try to remove .fedora.cert and fedora-packager-setup (so it's not a certificate problem). what else can be the reason? thanks in advance. regards. -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpms/redir/EL-6 import.log,1.2,1.3 redir.spec,1.3,1.4
but not on all rhel/centos-5 so i suggest:
%if 0%{?rhel} 5 || 0%{?fedora}
for rhel6 and fedora since now all fedora is at least 11 and usually
rhel6 and fedora packages are compatible with eachother all other case
the old (4,5) rhel releases.
On Thu, May 27, 2010 at 19:44, Kevin Kofler kevin.kof...@chello.at wrote:
On Thursday 27 May 2010, Farkas Levente wrote:
are you sure rhel is defined on rhel-5? imho not by default!
AFAIK, it's defined in the EPEL build system.
Kevin Kofler
--
Levente Si vis pacem para bellum!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
primary arch and buildsys arch are not in sync
hi, now as ppc was removed from primary arch i try to build gstreamer-java as a noarch packages. until now it was not possible because of this jdk bug on ppc: https://bugzilla.redhat.com/show_bug.cgi?id=468831 http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=190 http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=268 but now i assume as ppc is not a primary arch it's possible to change to noarch, but i was wrong. even if ppc is not a primary arch there are buildhost which are ppc. so the build fail since java compiler crash: http://koji.fedoraproject.org/koji/taskinfo?taskID=2143327 imho it's a bug and all buildhost should have to replaced to x86 x86_64 hosts. or ...? -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: primary arch and buildsys arch are not in sync
On 04/28/2010 07:58 PM, Josh Boyer wrote: On Wed, Apr 28, 2010 at 06:54:14PM +0200, Till Maas wrote: On Wed, Apr 28, 2010 at 04:54:18PM +0200, Farkas Levente wrote: now as ppc was removed from primary arch i try to build gstreamer-java as a noarch packages. until now it was not possible because of this jdk bug on ppc: imho it's a bug and all buildhost should have to replaced to x86 x86_64 hosts. or ...? You might need to wait until F11 is EOL, because there ppc is still a primary arch iirc. It is in F12 too. how can i find it's true? http://fedoraproject.org/wiki/Architectures it has no version... -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: primary arch and buildsys arch are not in sync
On 04/28/2010 06:40 PM, Jon Masters wrote: On Wed, 2010-04-28 at 16:54 +0200, Farkas Levente wrote: now as ppc was removed from primary arch i try to build gstreamer-java as a noarch packages. until now it was not possible because of this jdk bug on ppc: https://bugzilla.redhat.com/show_bug.cgi?id=468831 http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=190 http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=268 but now i assume as ppc is not a primary arch it's possible to change to noarch, but i was wrong. even if ppc is not a primary arch there are buildhost which are ppc. so the build fail since java compiler crash: http://koji.fedoraproject.org/koji/taskinfo?taskID=2143327 imho it's a bug and all buildhost should have to replaced to x86 x86_64 hosts. or ...? This has been brought up a number of times before. I know they're looking at the buildhost selection for the SRPM generation but in the interim I've heard the solution is to just re-submit and hope you get an x86/x86_64 host selected the next time :) nice. why can't koji choose in this way? -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to speed up mock?
On 01/18/2010 04:10 PM, Seth Vidal wrote: On Mon, 18 Jan 2010, Farkas Levente wrote: the real bottleneck is not the rpmbuild itself (with ccache it cab be very fast), but the mock surroundings. suppose there is build which takes about 2 minutes and in mock it takes about 5 minutes:-( most of the time is in yum, python tar, gzip etc which all use only one cpu/core and it's very slow! the tar and gzip are mostly BUILDING the cache. no tar and gzip used unpacking root cache. Mock currently makes a cached copy of the buildroot it just created so it doesn't have to redepsolve and download/install the rpms each time. but have to run yum each time for the package specific depsolve and yum installs (ps axufww:) --- \_ /usr/bin/python -tt /usr/sbin/mock -r testing-i386 --define rhel 5 --define el5 1 --define dist .el5 --rebuild /home/robot/rpm/SRPMS/xyz-4.2.2-5280.el5.src.rpm root 28319 49.5 0.8 255000 34292 pts/1D16:15 0:00 | \_ /usr/bin/python /usr/bin/yum --installroot /var/lib/mock/testing-i386/root/ install ccache rsync zip --- and it much slower then the compile itself. it's very annoying when i try to rebuild only a dozen of packages most of the time. eg in this output: --- INFO: mock.py version 1.0.2 starting... State Changed: init plugins State Changed: start INFO: Start(/home/robot/rpm/SRPMS/xyz-4.2.2-5280.el5.src.rpm) Config(testing-i386) State Changed: lock buildroot State Changed: clean State Changed: init State Changed: lock buildroot Mock Version: 1.0.2 INFO: Mock Version: 1.0.2 INFO: enabled root cache State Changed: unpacking root cache INFO: enabled yum cache State Changed: cleaning yum metadata INFO: enabled ccache State Changed: running yum State Changed: setup State Changed: build INFO: Done(/home/robot/rpm/SRPMS/xyz-4.2.2-5280.el5.src.rpm) Config(testing-i386) 3 minutes 37 seconds INFO: Results and/or logs in: /var/lib/mock/testing-i386/result --- the time reach the State Changed: build is usually more then all other stuff before it. So the first time you run it makes a cache. You aren't clearing out the cache each time, are you? That would definitely eat up a lot of time. of course not:-) -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
