JS ABI breakage update coming
Hello. Few day ago I asked [1] build js without UTF-8 C strings. But before that was opposite request. As acceptable solution found update to recent version, starting from 1.8.0-rc1 [2]. But it have also known bugs and we move to 1.8.5 version from Firefox 4.0 [3] mercurial repository. 1.8 version introduce runtime UTF-8 support [4]. So, to use new version of js with UTF8 C strings support not enough to just rebuild and relink. Instead you need patch (or better ask upstream to do that) you software to add call function JS_SetCStringsAreUTF8. See [4] for more details. I plan build it today (I have still some troubles in it) and push in rawhide in middle of next week. Also in future it is suggested for F15 branch. In CC owners of dependent packages. [1] https://bugzilla.redhat.com/show_bug.cgi?id=676441 [2] https://developer.mozilla.org/En/SpiderMonkey/1.8 [3] https://developer.mozilla.org/en/javascript [4] https://developer.mozilla.org/En/SpiderMonkey/JSAPI_Reference/JS_CStringsAreUTF8 -- With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact with me use jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Mock fails when /var/cache/mock is bind-mounted.
Is there any particular reason why Mock can't work when /var/cache/mock is bind-mounted? I have a relatively small flash drive for the root filesystem and a big disk mounted on /disk/data. To avoid filling the flash drive I bind-mounted /disk/data/mock on /var/cache/mock. When I run "fedpkg mockbuild", Mock fails because /var/cache/mock/fedora-rawhide-x86_64/yum_cache doesn't exist. Creating that directory manually doesn't help; it seems to disappear when I run "fedpkg mockbuild", and /var/cache/mock/fedora-rawhide-x86_64 too. "umount /var/cache/mock" allowed Mock to work. I can imagine that the file permissions might be wrong, although they seem OK to me, but the error is that the directory doesn't exist. Why are the directories removed and not re-created? Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mock fails when /var/cache/mock is bind-mounted.
Once upon a time, Björn Persson said:
> I can imagine that the file permissions might be wrong, although they seem OK
> to me, but the error is that the directory doesn't exist. Why are the
> directories removed and not re-created?
You mention the probable cause, but you don't show the perms. The best
way to get the perms correct is to:
- umount /var/cache/mock
- chown --reference=/var/cache/mock /disk/data/mock
- chmod --reference=/var/cache/mock /disk/data/mock
- chcon --reference=/var/cache/mock /disk/data/mock
- mount -t bind /disk/data/mock /var/cache/mock
Alternately, rather than using bind mounts, you could edit
/etc/mock/site-defaults.cfg to move from /var/{lib,cache}/mock to
/disk/data/mock. You still need to get the permissions correct though.
It may be a bug in mock is not noticing that it failed to create the
necessary directories and then reports the problem as "directory not
found" (rather than "permission denied").
--
Chris Adams
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mock fails when /var/cache/mock is bind-mounted.
On 02/13/2011 07:00 PM, Björn Persson wrote: > Is there any particular reason why Mock can't work when /var/cache/mock is > bind-mounted? > > I have a relatively small flash drive for the root filesystem and a big disk > mounted on /disk/data. To avoid filling the flash drive I bind-mounted > /disk/data/mock on /var/cache/mock. When I run "fedpkg mockbuild", Mock fails > because /var/cache/mock/fedora-rawhide-x86_64/yum_cache doesn't exist. I have a similar setup as yours plus I bind-mount /var/lib/mock too, and it has always worked fine for me (current mock git, F-14). I have never tried "fedpkg mockbuild", but I do use plain mock for building quite a bit. Have you tried plain mock --rebuild /path/to/something.src.rpm? Does mock --verbose output anything interesting? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in rawhide
On Mon, Feb 7, 2011 at 8:59 PM, Bill Nottingham wrote: > Each release, we undergo the effort to track down owners for orphaned > packages in the release, and block those orphaned packages where > necessary. It's that time again for Fedora 15. > > The following packages are currently orphaned and exist in F-15. As > you can see, there are a lot of dependencies on these packages. Please > pick up these packages if you have a need for them. There was discussion of packages that were FTBFS since F-12 to be added to the list to be orphaned/blocked, is that still going to be the case, are they included in this list? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass rebuild breaks rawhide dependencies
On Sat, Feb 12, 2011 at 10:58 PM, Ben Boeckel wrote: > John Reiser wrote: >> The mass rebuild has broken the dependencies of packages in rawhide, >> and I'm upset about it. >> >> For instance, fresh install General Desktop from DVD made just after >> the mass rebuild, then boot the new system and try to "yum install pungi". >> I see several errors such as: >> - >> Error: Package: glibc-2.13.90-2.i686 (fedora) >> Requires: glibc-common = 2.13.90-2 >> Installed: glibc-common-2.13.90-3.x86_64 >> (@anaconda-InstallationRepo-201102112219.x86_64) >> glibc-common = 2.13.90-3 >> Available: glibc-common-2.13.90-2.x86_64 (fedora) >> glibc-common = 2.13.90-2 >> - >> >> Take a good look at those dependencies [a fixed-width font helps me]: >> glibc-common-2.13.90-3.x86_64 installed >> glibc-common = 2.13.90-2 required >> glibc-common-2.13.90-2.x86_64 available >> >> Changing a mere build number from "-2" to "-3" breaks dependencies? >> That is a poor system. > > It's a subpackage and these are supposed to have release-grained > dependencies. The problem stems from the fact that the 32bit version is > looking to get installed, but the 64bit version is -3 and yum won't > downgrade from the -3 you have to the -2 in the repos. The > `--allow-downgrades' flag in yum (also may need a plugin, I forget) or > grabbing the correct version from koji should help. That issue tends to happen when a package that depends on a one of the packages in question has a broken dependency. The mass rebuild will take a little while to settle out, esp with the branch and having to submit packages as updates, so its likely it will be broken for a little while. welcome to the joys of rawhide. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass Rebuild and Mass branching status update
On Sat, Feb 12, 2011 at 11:52 PM, Kevin Kofler wrote: > Dennis Gilmore wrote: > >> On Friday, February 11, 2011 04:16:44 am Christoph Wickert wrote: >>> On IRC you said it is ok to just push a build. Do I now need to submit >>> them through bodhi? >> >> yes you need to push them though bodhi. > > I think this process could really use improvement. There are many packages > which failed to build due to the recent RPM and GCC changes and the > extremely recent v4l change. Requiring the fixed builds to all go through > Bodhi is really unhelpful. Why can't we go back to the old (pre-NFR) process > of having F15 be self-populating until Beta (i.e. what used to be Preview)? > As I pointed out to Jesse when NFR was originally implemented, we don't have > to throw out NFR (nor any essential part of it) to implement that at all. > We'd still keep the early branching and Rawhide moving on towards F16. (We'd > also keep the fact that F15 is feature-frozen now, of course; that would > have been the case even pre-NFR.) We'd just have to let dist-f15 work like > Rawhide (for Koji/rel-eng purposes) until the Beta Freeze, and start using > Bodhi only then. What we need to do is to ensure major breakage changes such as a mass rebuild are actually done a little while before branching to give people the ability to fix their packages and quickly get them in. I've been travelling for a chunk of the mass rebuild so haven't had the chance to fix alot of my breakages. We had the same problem last release with the tagging and mass breakage due to a python change. It becomes a little painful. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: really strange ext4 behavior
On 02/12/2011 11:52 PM, Ric Wheeler wrote: > On 02/12/2011 05:31 PM, Michał Piotrowski wrote: >> Hi, >> >> W dniu 12 lutego 2011 23:19 użytkownik Ric Wheeler >>napisał: >>> On 02/12/2011 05:12 PM, Michał Piotrowski wrote: Hi, I added a disc to my box. I wanted to use ext4. I run fs_mark to test speed, to my surprise I heard a really strange noises. It's very strange because the drive is new 9 Power_On_Hours 0x0032 100 100 000Old_age Always - 12 # fs_mark -d test/ [..] FSUse%Count SizeFiles/sec App Overhead 0 100051200 22.854347 I decided to create an ext3 file system on this drive and everything works fine. # fs_mark -d test/ [..] FSUse%Count SizeFiles/sec App Overhead 0 100051200103.757229 When I mount this ext3 fs as ext4 and run fs_mark I hear strange sounds again. I use F14 and self compiled kernel from rawhide 2.6.37-1.fc14.x86_64 + e2fsprogs-1.41.14-2.fc14.x86_64. I mount ecryptfs on top of this file system. Does anyone know what might be causing this strange ext4 behavior? >>> Hi Michael, >>> >>> fs_mark run a fsync heavy test. What you might be hearing is the impact of >>> the fsync's. ext4 defaults to using "write barriers" enabled, ext3 does not. >>> Without write barriers, those fsync push data from the box to the write >>> cache on the drive only. With barriers, the disk will flush that cache to >>> the platter, so the platter moves and you probably hear the head, etc. >>> >>> You can test if this is the cause by mouting ext4 with "nobarrier" to see if >>> the noise goes away. >> I mounted fs with nobarrier and now it works just like ext3. Thanks! This >> solves >> the riddle :) >> > > Good to hear that it worked! > > Note that the barrier code makes your data safer, so you should run with it on > by default (unless you really don't care about the file system). If ext3 was running fine without barriers for all these years why is this such a problem with ext4? Does ext4 do something differently that barriers are now required? Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mock fails when /var/cache/mock is bind-mounted.
Chris Adams wrote:
> Once upon a time, Björn Persson said:
> > I can imagine that the file permissions might be wrong, although they
> > seem OK to me, but the error is that the directory doesn't exist. Why
> > are the directories removed and not re-created?
>
> You mention the probable cause, but you don't show the perms. The best
> way to get the perms correct is to:
>
> - umount /var/cache/mock
> - chown --reference=/var/cache/mock /disk/data/mock
> - chmod --reference=/var/cache/mock /disk/data/mock
> - chcon --reference=/var/cache/mock /disk/data/mock
> - mount -t bind /disk/data/mock /var/cache/mock
I moved the whole tree with cp -a and replaced the original /var/cache/mock
with a symbolic link. When that didn't work I tried a bind mount instead. Thus
I can't use /var/cache/mock as a reference, but the permissions should be
right since I used cp -a. What I have now is:
[root@hactar ~]# ls -la /var/cache/mock/
totalt 16
drwxr-sr-x 3 root mock 4096 13 feb 17.17 .
drwxr-xr-x. 18 root root 4096 13 feb 16.58 ..
drwxr-sr-x 5 root mock 4096 13 feb 17.17 fedora-rawhide-x86_64
[root@hactar ~]# mount /disk/data/mock/
[root@hactar ~]# ls -la /var/cache/mock/
totalt 32
drwxrwsr-x 7 root mock 4096 13 feb 18.10 .
drwxr-xr-x. 18 root root 4096 13 feb 16.58 ..
drwxr-sr-x 5 root mock 4096 8 mar 2010 fedora-11-x86_64
drwxr-sr-x 5 root mock 4096 6 feb 02.35 fedora-13-x86_64
drwxr-sr-x 5 root mock 4096 29 aug 17.03 fedora-14-i386
drwxr-sr-x 5 root mock 4096 28 aug 00.26 fedora-14-x86_64
drwxr-sr-x 5 root mock 4096 2 aug 2010 fedora-rawhide-i386
The former works and the latter does not. I see one difference, the group write
permission. Let's try removing that.
[root@hactar ~]# chmod g-w /disk/data/mock/
[root@hactar ~]# ls -la /var/cache/mock/
totalt 32
drwxr-sr-x 7 root mock 4096 13 feb 18.23 .
drwxr-xr-x. 18 root root 4096 13 feb 16.58 ..
drwxr-sr-x 5 root mock 4096 8 mar 2010 fedora-11-x86_64
drwxr-sr-x 5 root mock 4096 6 feb 02.35 fedora-13-x86_64
drwxr-sr-x 5 root mock 4096 29 aug 17.03 fedora-14-i386
drwxr-sr-x 5 root mock 4096 28 aug 00.26 fedora-14-x86_64
drwxr-sr-x 5 root mock 4096 2 aug 2010 fedora-rawhide-i386
Nope. It still fails in the same way.
> Alternately, rather than using bind mounts, you could edit
> /etc/mock/site-defaults.cfg to move from /var/{lib,cache}/mock to
> /disk/data/mock. You still need to get the permissions correct though.
Even that doesn't help. Maybe it isn't caused by the bind mount after all.
I see this note in site-defaults.cfg:
# Note: the path pointed to by basedir and cache_topdir must be owned
#by group 'mock' and must have mode: g+rws
so I put that write permission back. It still fails.
So it's not caused by the permissions that ls -l shows, and SElinux is
disabled. The only difference in mount options is that / is mounted with
relatime and /disk/data with noatime. Is it conceivable that Mock doesn't work
with noatime? What else is there to check?
Björn Persson
signature.asc
Description: This is a digitally signed message part.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mock fails when /var/cache/mock is bind-mounted.
Ville Skyttä wrote: > On 02/13/2011 07:00 PM, Björn Persson wrote: > > Is there any particular reason why Mock can't work when /var/cache/mock > > is bind-mounted? > > > > I have a relatively small flash drive for the root filesystem and a big > > disk mounted on /disk/data. To avoid filling the flash drive I > > bind-mounted /disk/data/mock on /var/cache/mock. When I run "fedpkg > > mockbuild", Mock fails because > > /var/cache/mock/fedora-rawhide-x86_64/yum_cache doesn't exist. > > I have a similar setup as yours plus I bind-mount /var/lib/mock too, and > it has always worked fine for me (current mock git, F-14). I have never > tried "fedpkg mockbuild", but I do use plain mock for building quite a bit. > > Have you tried plain mock --rebuild /path/to/something.src.rpm? That gives me: ERROR: Could not find required config file: /etc/mock/default.cfg ERROR: Did you forget to specify the chroot to use with '-r'? but if I try the same command that fedpkg runs, that is "mock -r fedora-devel- x86_64 --resultdir /home/beorn/fedora- git/GtkAda/GtkAda/2.22.0/0.0.trunk.1.fc15 --rebuild /home/beorn/fedora- git/GtkAda/GtkAda-2.22.0-0.0.trunk.1.fc15.src.rpm", then it fails in the same way. > Does mock --verbose output anything interesting? Well, it outputs the error message to the terminal so I don't have to look in root.log. That's more convenient, but there's no new information. The command that fails is "mount -n --bind /var/cache/mock/fedora-rawhide- x86_64/yum_cache/ /var/lib/mock/fedora-rawhide-x86_64/root/var/cache/yum". Mount complains that /var/cache/mock/fedora-rawhide-x86_64/yum_cache/ doesn't exist, and returns 32. Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mock fails when /var/cache/mock is bind-mounted.
Once upon a time, Björn Persson said: > I can't use /var/cache/mock as a reference, but the permissions should be > right since I used cp -a. What I have now is: You can always check the RPM database: $ rpm -qvl mock | fgrep /var/cache/mock drwxrwsr-x2 rootmock0 Jan 6 20:58 /var/cache/mock Have you also checked /var/lib/mock? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: really strange ext4 behavior
W dniu 13 lutego 2011 19:29 użytkownik Dennis Jacobfeuerborn napisał: > On 02/12/2011 11:52 PM, Ric Wheeler wrote: >> >> On 02/12/2011 05:31 PM, Michał Piotrowski wrote: >>> >>> Hi, >>> >>> W dniu 12 lutego 2011 23:19 użytkownik Ric Wheeler >>> napisał: On 02/12/2011 05:12 PM, Michał Piotrowski wrote: > > Hi, > > I added a disc to my box. I wanted to use ext4. I run fs_mark to test > speed, to my surprise I heard a really strange noises. > > It's very strange because the drive is new > 9 Power_On_Hours 0x0032 100 100 000 Old_age > Always - 12 > > > # fs_mark -d test/ > [..] > FSUse% Count Size Files/sec App Overhead > 0 1000 51200 22.8 54347 > > I decided to create an ext3 file system on this drive and everything > works > fine. > > # fs_mark -d test/ > [..] > FSUse% Count Size Files/sec App Overhead > 0 1000 51200 103.7 57229 > > When I mount this ext3 fs as ext4 and run fs_mark I hear strange sounds > again. > > I use F14 and self compiled kernel from rawhide 2.6.37-1.fc14.x86_64 + > e2fsprogs-1.41.14-2.fc14.x86_64. > > I mount ecryptfs on top of this file system. > > Does anyone know what might be causing this strange ext4 behavior? > Hi Michael, fs_mark run a fsync heavy test. What you might be hearing is the impact of the fsync's. ext4 defaults to using "write barriers" enabled, ext3 does not. Without write barriers, those fsync push data from the box to the write cache on the drive only. With barriers, the disk will flush that cache to the platter, so the platter moves and you probably hear the head, etc. You can test if this is the cause by mouting ext4 with "nobarrier" to see if the noise goes away. >>> >>> I mounted fs with nobarrier and now it works just like ext3. Thanks! This >>> solves >>> the riddle :) >>> >> >> Good to hear that it worked! >> >> Note that the barrier code makes your data safer, so you should run with >> it on >> by default (unless you really don't care about the file system). > > If ext3 was running fine without barriers for all these years why is this > such a problem with ext4? Does ext4 do something differently that barriers > are now required? Ext4 uses extents - AFAIRC it is harder to recover data on file system that uses extents, so perhaps for this reason additional measures were taken > > Regards, > Dennis > -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass rebuild breaks rawhide dependencies
On Sunday, February 13, 2011 12:24:14 pm Peter Robinson wrote: > On Sat, Feb 12, 2011 at 10:58 PM, Ben Boeckel wrote: > > John Reiser wrote: > >> The mass rebuild has broken the dependencies of packages in rawhide, > >> and I'm upset about it. > >> > >> For instance, fresh install General Desktop from DVD made just after > >> the mass rebuild, then boot the new system and try to "yum install > >> pungi". I see several errors such as: > >> - > >> Error: Package: glibc-2.13.90-2.i686 (fedora) > >> Requires: glibc-common = 2.13.90-2 > >> Installed: glibc-common-2.13.90-3.x86_64 > >> (@anaconda-InstallationRepo-201102112219.x86_64) glibc-common = > >> 2.13.90-3 > >> Available: glibc-common-2.13.90-2.x86_64 (fedora) > >> glibc-common = 2.13.90-2 > >> - > >> > >> Take a good look at those dependencies [a fixed-width font helps me]: > >> glibc-common-2.13.90-3.x86_64 installed > >> glibc-common = 2.13.90-2 required > >> glibc-common-2.13.90-2.x86_64 available > >> > >> Changing a mere build number from "-2" to "-3" breaks dependencies? > >> That is a poor system. > > > > It's a subpackage and these are supposed to have release-grained > > dependencies. The problem stems from the fact that the 32bit version is > > looking to get installed, but the 64bit version is -3 and yum won't > > downgrade from the -3 you have to the -2 in the repos. The > > `--allow-downgrades' flag in yum (also may need a plugin, I forget) or > > grabbing the correct version from koji should help. > > That issue tends to happen when a package that depends on a one of the > packages in question has a broken dependency. The mass rebuild will > take a little while to settle out, esp with the branch and having to > submit packages as updates, so its likely it will be broken for a > little while. welcome to the joys of rawhide. > > Peter It looks like he has used a self created install iso. and the install repos dont match the content of the public repos. note that due to the massive churn we have not yet been able to get branched composed. its failing to create the deltarpms. last nighst is still running likely his issue will be fixed when we do get branched out. Dennis signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mock fails when /var/cache/mock is bind-mounted.
Chris Adams wrote: > Have you also checked /var/lib/mock? Um, no. A quick look at /var/lib/mock made the problem obvious. /var/lib/mock and /var/cache/mock were both pointed at /disk/data/mock. What happened was most likely that Mock deleted /var/lib/mock/fedora-rawhide-x86_64 and thereby deleted /var/cache/mock/fedora-rawhide-x86_64 also, as it was the same directory. I'm now using /disk/data/var-lib-mock and /disk/data/var-cache- mock, and Mock is working fine. I'll go LART myself now. Sorry for the noise. Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JS ABI breakage update coming
On Sun, 2011-02-13 at 13:30 +0300, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > Hello. > > Few day ago I asked [1] build js without UTF-8 C strings. But before > that was opposite request. > As acceptable solution found update to recent version, starting from > 1.8.0-rc1 [2]. But it have also known bugs and we move to 1.8.5 version > from Firefox 4.0 [3] mercurial repository. > 1.8 version introduce runtime UTF-8 support [4]. So, to use new version > of js with UTF8 C strings support not enough to just rebuild and relink. > Instead you need patch (or better ask upstream to do that) you software > to add call function JS_SetCStringsAreUTF8. See [4] for more details. > > I plan build it today (I have still some troubles in it) and push in > rawhide in middle of next week. Also in future it is suggested for F15 > branch. > > > In CC owners of dependent packages. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=676441 > [2] https://developer.mozilla.org/En/SpiderMonkey/1.8 > [3] https://developer.mozilla.org/en/javascript > [4] > https://developer.mozilla.org/En/SpiderMonkey/JSAPI_Reference/JS_CStringsAreUTF8 > Isn't there yet more breakage coming, as well? https://groups.google.com/forum/#!topic/mozilla.dev.tech.js-engine/5uQ9oIPyio4 Perhaps we should just wait for this? -- Braden McDaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: incompatible screen update
On Thu, 10.02.11 09:33, Miroslav Lichvar (mlich...@redhat.com) wrote: > > On Tue, Feb 08, 2011 at 06:16:29PM +0100, Lennart Poettering wrote: > > > The problem is it would require making screen setuid root which I do not > > > think it is too good idea. > > > > Well, I think the fear of making something SUID root is not reason > > enough not to make things technically correct. > > How about creating a helper similar to utempter? The PAM session hooks need to be run in the parent process before the session process is forked off and after it died. In the child another hook needs to be called before the session binary is exec()'ed. PAM requires this so that process parameters can be influenced by the PAM modules. That makes it impossible to do PAM session setup out-of-process. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Backported gtk3 for F14 available
I wrote: > to allow porting applications to GTK+ 3 and testing them with a current > GTK+ 3 on Fedora 14 (the stock 2.90.5 is quite old, from before the > theming changes, among other things), I have prepared packages of the > latest gtk3 (2.99.3) for Fedora 14: > http://repos.fedorapeople.org/repos/kkofler/gtk3-f14-backport/ Effective now, the repository carries gtk3-3.0.0, the official release. The same notes and warnings as previously apply: > Some notes: > * WARNING: This repository will REPLACE YOUR SYSTEM VERSION OF glib2 > (2.26.0) with a newer stable version (2.28.0). glib2 is also used by > many other things, including gtk2 and even (for event loop integration) > qt. It is supposed to be backwards compatible, but if there are any > problems: You have been warned! (see also Bastien Nocera's reply, pointing out particular caveats resulting from that) > * The gtk3 package has introspection disabled, because the > gobject-introspection in F14 (0.9.3) is too old, the required version > (0.10.1) is not backwards-compatible, and I haven't managed to make gtk3 > build with 0.9.3 when I tried. (By the way, to the gtk3 maintainers, you > should fix gobject_introspection_version in gtk3.spec, it still says > 0.9.3, but the sources actually require 0.10.1.) > * The packages in this repository are signed with my GPG key, as found on: > https://www.calcforge.org/RPM-GPG-KEY-calcforge > * Only glib2, gtk3 and their subpackages are provided at this time. > Anything higher in the GNOME 3 stack is NOT available, and the versions > in F14, if any, are likely not to work with this gtk3. Again, you have > been warned. > * This repository is NOT endorsed or supported by Red Hat, the Red Hat > Desktop Team nor the Fedora GTK+/GNOME packagers. Use at your own risk! Whether any further updates will be provided or not will depend on 1. usage/demand and 2. my available time. Further updates will NOT be announced here, check the repository if you're interested (but let me know – I'd like to know whether anybody actually uses the repository). If you have any questions about the repository, you can find me on IRC, I normally hang around on #fedora-kde on Freenode. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Backported gtk3 for F14 available
On Thu, Feb 10, 2011 at 10:28 PM, Matthias Clasen wrote: > On Thu, 2011-02-10 at 19:30 +0100, Kevin Kofler wrote: > [...] > Interesting idea. Note that I've _just_ released the stable GTK+ 3.0.0. > We could think about updating the gtk3 package in F14 to 3.0.0 if that > is useful for people. We had essentially abandoned this and a few other > packages in F14 after GNOME 3 was delayed to F15, and nothing in the > repo should depend on it... Well mutter and gnome-shell do. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: really strange ext4 behavior
On 02/13/2011 01:29 PM, Dennis Jacobfeuerborn wrote: snip >> >> Good to hear that it worked! >> >> Note that the barrier code makes your data safer, so you should run with it >> on >> by default (unless you really don't care about the file system). > > > If ext3 was running fine without barriers for all these years why is this > such > a problem with ext4? Does ext4 do something differently that barriers are now > required? > > Regards, > Dennis ext3 has a default behaviour that lets is magically flush out the data every so many seconds. It also has supported barrier mode (and has done for years, other distros like opensuse have defaulted barriers on long ago for ext3 as well). Even with the magic thread that ext3 has, you really do want to run with barriers enabled for data integrity. ext4 is actually faster to repair than ext3 (up to 10 times faster in my testing) :) ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JS ABI breakage update coming
On 02/13/2011 12:32 PM, Braden McDaniel wrote: > Isn't there yet more breakage coming, as well? > > > https://groups.google.com/forum/#!topic/mozilla.dev.tech.js-engine/5uQ9oIPyio4 > > Perhaps we should just wait for this? > Those patches already landed in tracemonkey on Wednesday and mozilla-central on Friday. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JS ABI breakage update coming
On Sun, 2011-02-13 at 20:23 -0800, Christopher Aillon wrote: > On 02/13/2011 12:32 PM, Braden McDaniel wrote: > > Isn't there yet more breakage coming, as well? > > > > > > https://groups.google.com/forum/#!topic/mozilla.dev.tech.js-engine/5uQ9oIPyio4 > > > > Perhaps we should just wait for this? > > > > Those patches already landed in tracemonkey on Wednesday and > mozilla-central on Friday. Okay... I'm not sufficiently well versed in Mozilla development terminology to know whether that means that it'll be in the next XULRunner prerelease package in rawhide; but I think I can gather from the context of your statement that it does mean that. -- Braden McDaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JS ABI breakage update coming
On 02/13/2011 08:35 PM, Braden McDaniel wrote: > On Sun, 2011-02-13 at 20:23 -0800, Christopher Aillon wrote: >> On 02/13/2011 12:32 PM, Braden McDaniel wrote: >>> Isn't there yet more breakage coming, as well? >>> >>> >>> https://groups.google.com/forum/#!topic/mozilla.dev.tech.js-engine/5uQ9oIPyio4 >>> >>> Perhaps we should just wait for this? >>> >> >> Those patches already landed in tracemonkey on Wednesday and >> mozilla-central on Friday. > > Okay... I'm not sufficiently well versed in Mozilla development > terminology to know whether that means that it'll be in the next > XULRunner prerelease package in rawhide; but I think I can gather from > the context of your statement that it does mean that. Should be, but that's somewhat irrelevant, actually. Pavel is talking about the standalone spidermonkey package named 'js'. https://admin.fedoraproject.org/pkgdb/acls/name/js It's been stuck on JS 1.7 (which translates to the JS engine in Firefox 2!) for a long while, and I asked him to update it to something more modern. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Package review report for last 2 weeks
Top five FAS account holders who have completed reviewing "Package review" components on bugzilla for last 2 weeks ending 14th Feb were Mohammed Morsi, Haïkel Guémar, Jason Tibbitts, Mohamed El Morabity and Parag AN(पराग). Mohammed Morsi : 4 https://bugzilla.redhat.com/show_bug.cgi?id=668090 rubygem-railties https://bugzilla.redhat.com/show_bug.cgi?id=667954 rubygem-arel https://bugzilla.redhat.com/show_bug.cgi?id=674587 rubygem-sqlite3 https://bugzilla.redhat.com/show_bug.cgi?id=665560 rubygem-mail Haïkel Guémar : 3 https://bugzilla.redhat.com/show_bug.cgi?id=672455 perl-AnyEvent-DBus https://bugzilla.redhat.com/show_bug.cgi?id=673661 R-ALL https://bugzilla.redhat.com/show_bug.cgi?id=673665 R-XML Jason Tibbitts : 3 https://bugzilla.redhat.com/show_bug.cgi?id=592487 ffgtk https://bugzilla.redhat.com/show_bug.cgi?id=596138 nss-gui https://bugzilla.redhat.com/show_bug.cgi?id=664817 perl-HTML-Selector-XPath Mohamed El Morabity : 3 https://bugzilla.redhat.com/show_bug.cgi?id=662301 plotdrop https://bugzilla.redhat.com/show_bug.cgi?id=669311 mupdf https://bugzilla.redhat.com/show_bug.cgi?id=671024 wallpaperd Parag AN(पराग) : 3 https://bugzilla.redhat.com/show_bug.cgi?id=673027 manchu-fonts https://bugzilla.redhat.com/show_bug.cgi?id=673029 sil-nuosu-fonts https://bugzilla.redhat.com/show_bug.cgi?id=673026 ukij-tuz-fonts Jon Stanley : 2 https://bugzilla.redhat.com/show_bug.cgi?id=669939 mediawiki116-ParserFunctions https://bugzilla.redhat.com/show_bug.cgi?id=669940 mediawiki116-Cite Martin Gieseking : 2 https://bugzilla.redhat.com/show_bug.cgi?id=623606 gxneur https://bugzilla.redhat.com/show_bug.cgi?id=654879 since Michal Fojtik : 2 https://bugzilla.redhat.com/show_bug.cgi?id=671095 rubygem-pr_geohash https://bugzilla.redhat.com/show_bug.cgi?id=675705 rubygem-tilt Minnikhanov : 2 https://bugzilla.redhat.com/show_bug.cgi?id=668822 rubygem-memcache-client https://bugzilla.redhat.com/show_bug.cgi?id=668823 rubygem-text-format Robin Lee : 2 https://bugzilla.redhat.com/show_bug.cgi?id=674674 python-zope-configuration https://bugzilla.redhat.com/show_bug.cgi?id=674676 python-zope-deprecation Ruediger Landmann : 2 https://bugzilla.redhat.com/show_bug.cgi?id=521909 ne7ssh https://bugzilla.redhat.com/show_bug.cgi?id=664911 perl-Test-WWW-Mechanize-PSGI Volker Fröhlich : 2 https://bugzilla.redhat.com/show_bug.cgi?id=656186 drupal6-mimedetect https://bugzilla.redhat.com/show_bug.cgi?id=655184 drupal6-data Alexander Kurtakov : 1 https://bugzilla.redhat.com/show_bug.cgi?id=669552 swingx Bill Nottingham : 1 https://bugzilla.redhat.com/show_bug.cgi?id=674672 libwnck3 Dominic Hopf : 1 https://bugzilla.redhat.com/show_bug.cgi?id=625592 PyCAM Golo Fuchert : 1 https://bugzilla.redhat.com/show_bug.cgi?id=674180 knights Ian Weller : 1 https://bugzilla.redhat.com/show_bug.cgi?id=668243 libqb Lakshmi Narasimhan : 1 https://bugzilla.redhat.com/show_bug.cgi?id=637360 ghc-parameterized-data Lubomir Rintel : 1 https://bugzilla.redhat.com/show_bug.cgi?id=670999 perl-MongoDB Marcela Mašláňová : 1 https://bugzilla.redhat.com/show_bug.cgi?id=673404 perl-Parse-CPAN-Meta Marek Goldmann : 1 https://bugzilla.redhat.com/show_bug.cgi?id=672318 python26-m2crypto Matthew Barnes : 1 https://bugzilla.redhat.com/show_bug.cgi?id=673485 libldb Petr Pisar : 1 https://bugzilla.redhat.com/show_bug.cgi?id=672779 perl-Module-Metadata Pierre-YvesChibon : 1 https://bugzilla.redhat.com/show_bug.cgi?id=676791 goocanvas2 Rahul Sundaram : 1 https://bugzilla.redhat.com/show_bug.cgi?id=674207 python-cloudfiles Ralf Corsepius : 1 https://bugzilla.redhat.com/show_bug.cgi?id=674929 sh-elf-binutils Rex Dieter : 1 https://bugzilla.redhat.com/show_bug.cgi?id=623868 abattis-cantarell-fonts Rich Mattes : 1 https://bugzilla.redhat.com/show_bug.cgi?id=674006 openni Stanislav Ochotnicky : 1 https://bugzilla.redhat.com/show_bug.cgi?id=664619 jspeex Tim Lauridsen : 1 https://bugzilla.redhat.com/show_bug.cgi?id=674673 lovelock-backgrounds Tim Niemueller : 1 https://bugzilla.redhat.com/show_bug.cgi?id=672440 flann Tomas Mraz : 1 https://bugzilla.redhat.com/show_bug.cgi?id=663384 scap-workbench Total reviews modified: 50 Merge Reviews: 0 Review Requests: 50 This report by generated by bzReviewReport.py. The source is available at:
