You are not logged in.
This is not another thread asking when Gnome 2.26 will be released (though I am curious and looking forward to it). This is a thread trying to figure out why even asking about it results in short replies and closed topics. We know that releasing an upgrade to Gnome is a big job. We know it will be ready when it is ready. I think we are just hoping for a possible status update. Or some idea of how we can help make it ready.
I understand that everyone working on Arch is doing it in their free time and I appreciate that. Possibly to help stop people from asking about when it is coming, you can make a page/sticky/something with just brief status updates to let us know that work is progressing.
Offline
It's up to the maintainer to inform about the progress. Personally I see no need to maintain a website with status/progress information. The only thing you see would be a website with information about which package of gnome 2.26 was built. And if you have a website with percentage for example and it will stuck at ~80% everybody will ask why it stucks, etc.
If you want to know what is going on at our SVN, just subscribe to the arch-commits mailinglist (http://www.archlinux.org/mailman/listinfo/arch-commits). Every single commit of every single package will be send to you by mail and you know who is working on which topic or task.
To give a small status update: Jan is working hard on Gnome 2.26 and told me that he has finished 90% of the packages.
Last edited by ise (2009-03-23 14:28:19)
Offline
Thanks for your excellent reply. I wasn't aware of the commits mailinglist.
To give a small status update: Jan is working hard on Gnome 2.26 and told me that he has finished 90% of the packages.
That is excellent and exactly what I was looking for.
Also, is there any way for users to help in the packaging process? If not with this release, then future releases?
Offline
Also, is there any way for users to help in the packaging process? If not with this release, then future releases?
I think not. The packaging of the official repository is maintained only by developers. You can test the packages after they hit the testing repo and file bug reports, if there are any.
Offline
Welcome to the forums Dianoga.
One thing that every user can do if they're willing is enable the testing repository in order to make sure the packages are sane. Parts of the new Gnome have been going into testing since the tarballs were released.
Offline
I had a thought about this.
A group of users could start writing PKGBUILDs for the next version of GNOME earlier in the cycle. A lot of the time there won't be huge changes, and they particularly don't change much from beta to final release. We can submit them to AUR as *-devel. Then when it comes around for a dev to package them, he can see changes in dependencies etc and can check package quality (malicious commands etc), instead of having to find out why each package isn't building. Just taking a bit of the work off the devs
We could then try to get GNOME pkgs up on release day like KDE!
just a thought
Offline
I had a thought about this.
A group of users could start writing PKGBUILDs for the next version of GNOME earlier in the cycle. A lot of the time there won't be huge changes, and they particularly don't change much from beta to final release. We can submit them to AUR as *-devel. Then when it comes around for a dev to package them, he can see changes in dependencies etc and can check package quality (malicious commands etc), instead of having to find out why each package isn't building. Just taking a bit of the work off the devsWe could then try to get GNOME pkgs up on release day like KDE!
just a thought
KDE got ready in days because 4.0 and 4.1 were development releases. There was over a year of packages breaking constantly to get it release ready. We don't have that "luxury" with Gnome.
For everyone:
The fact is that Gnome 2.26 has been out for a week. History has shown that every upstream breakage will be blamed on Arch by some user or another (or 1000). If it takes 10 or 14 days to get into the repos, so what? ABS exists and adjusting PKGBUILDs usually isn't that difficult.
Offline
Oh yes,
alex_anthony, I think that your idea of a community driven Gnome testing area is a good one. I know that some people were running subversion builds for both KDE4 and XFCE4 before, but I'm not sure that it needs to be that extensive. The Gnome project releases development tarballs pretty frequently and on a schedule. If the goal is to get ready for a major release, the simplest way is to start building when tarballs are labeled .90 and up. For instance, I put evince-gtk in AUR when the development tarball hit 2.25.91. I started building at 2.25.90.
A pure development branch may work too. The only major issue that people may run into is that there are some pretty low level libraries that Gnome gets built against (glib2 for instance). One needs to be careful to rebuild other things that depend on those libraries.
Offline
Will epiphany use webkit?
I'm the type to fling myself headlong through the magical wardrobe, and then incinerate the ornate mahogany portal behind me with a Molotov cocktail.
Offline
Funny, didn't they delay it on 2.22 and 2.24, too?
Offline
Odysseus wrote:Will epiphany use webkit?
No, it was delayed to 2.27 release. epiphany still use gecko in this release.
Aww. That's okay. The epiphany-webkit package in AUR is oprhaned and I've been thinking about adopting it. 'Bout time I gave something back.
I'm the type to fling myself headlong through the magical wardrobe, and then incinerate the ornate mahogany portal behind me with a Molotov cocktail.
Offline
Is it just me or does epiphany+webkit suck anyway?
Offline
evolution 2.26 is working well for me, from the tesing repo..good job devs...
Offline
ise wrote:Odysseus wrote:Will epiphany use webkit?
No, it was delayed to 2.27 release. epiphany still use gecko in this release.
Aww. That's okay. The epiphany-webkit package in AUR is oprhaned and I've been thinking about adopting it. 'Bout time I gave something back.
Go for it!
Offline
Is it just me or does epiphany+webkit suck anyway?
it does. it starts up slowly and freezes for seconds after each action taken
Last edited by viktor (2009-03-24 10:30:19)
Offline
Thanx for a wonderful thread.
I wonder if pulseaudio will be implemented in the archlinux release of gnome 2.26.
Offline
Thanx for a wonderful thread.
I wonder if pulseaudio will be implemented in the archlinux release of gnome 2.26.
A very interesting question... pulseaudio is really nice!!! But not well integrated in gnome 2.24 and Arch...
Sorry for my bad English
Offline
i think jgc has mention that if pulse audio is an optional depedency he wouldn't integrate in gnome.
http://bbs.archlinux.org/viewtopic.php? … 66#p516666
Last edited by wonder (2009-03-24 11:20:01)
Give what you have. To someone, it may be better than you dare to think.
Offline
In http://news.softpedia.com/news/First-Lo … 7111.shtml I read:
First Look: GNOME 2.26
Includes hot new features and updated applications.
____
PulseAudio is now the default audio input/output framework. One of its most powerful features is the ability to control applications' volume independently. This tool is sure to be very useful in many scenarios. Furthermore, rerouting sound devices is now made in real time, thanks to plug-and-play support. And don't worry, if you still use GStreamer, its mixer is still available and received a new sound theme tab.
________
But I am too unexperienced to understand the width of pulseaudio - I guess the soundserver involves other than gnome apps as well.
But we'll see what will come :-)
Offline
pulseaudio and low sound volume(especially HDA-Intel cards) are an existing issue in most distributions.
there was a patch awaiting upstream fixing this issue(hopefully) which may have been part of 2.6.29 kernel.
just for information purpose only
Offline
I had a thought about this.
A group of users could start writing PKGBUILDs for the next version of GNOME earlier in the cycle. A lot of the time there won't be huge changes, and they particularly don't change much from beta to final release. We can submit them to AUR as *-devel. Then when it comes around for a dev to package them, he can see changes in dependencies etc and can check package quality (malicious commands etc), instead of having to find out why each package isn't building. Just taking a bit of the work off the devsWe could then try to get GNOME pkgs up on release day like KDE!
just a thought
Good idea. We used to have that when I wasn't a developer: it was me who made those packages.
Now I'm a dev and maintain mozilla-*, xorg and GNOME. We already have xorg-server 1.6 sitting in testing, which had more priority than getting gnome 2.25.90 in the repositories.
Sometimes I have to make choices. Getting a GNOME beta release packaged was not high priority, users can wait for a week or two.
As for pulseaudio: I won't implement it. Adding pulseaudio to gnome-applets and gnome-settings-daemon means that pulseaudio is a forced dependency. If pulse isn't running, you won't have sound or volume control. I compiled gnome-applets with the gstreamer mixer and patched gnome-settings-daemon to use gstreamer instead of pulse for volume control using multimedia keys.
Last edited by JGC (2009-03-25 09:27:39)
Offline
As for pulseaudio: I won't implement it. Adding pulseaudio to gnome-applets and gnome-settings-daemon means that pulseaudio is a forced dependency. If pulse isn't running, you won't have sound or volume control. I compiled gnome-applets with the gstreamer mixer and patched gnome-settings-daemon to use gstreamer instead of pulse for volume control using multimedia keys.
Great news to me! I don't know much about how pulse audio is supposed to work but I really hate not having sound because of a buggy app. Maybe in a year's time it'll be worth putting back in. Thanks Jan
Offline
If JGC also likes the idea of a community sponsored test bed for Gnome stuff, then I think that a new discussion on just that subject would be a good thing. If some of you are interested, let's open up a new thread to get a clean start.
Offline
alex_anthony wrote:I had a thought about this.
A group of users could start writing PKGBUILDs for the next version of GNOME earlier in the cycle. A lot of the time there won't be huge changes, and they particularly don't change much from beta to final release. We can submit them to AUR as *-devel. Then when it comes around for a dev to package them, he can see changes in dependencies etc and can check package quality (malicious commands etc), instead of having to find out why each package isn't building. Just taking a bit of the work off the devsWe could then try to get GNOME pkgs up on release day like KDE!
just a thought
Good idea. We used to have that when I wasn't a developer: it was me who made those packages.
Now I'm a dev and maintain mozilla-*, xorg and GNOME. We already have xorg-server 1.6 sitting in testing, which had more priority than getting gnome 2.25.90 in the repositories.
Sometimes I have to make choices. Getting a GNOME beta release packaged was not high priority, users can wait for a week or two.As for pulseaudio: I won't implement it. Adding pulseaudio to gnome-applets and gnome-settings-daemon means that pulseaudio is a forced dependency. If pulse isn't running, you won't have sound or volume control. I compiled gnome-applets with the gstreamer mixer and patched gnome-settings-daemon to use gstreamer instead of pulse for volume control using multimedia keys.
gnome-applets and gnome-settings-daemon are the only two packages concerining the pulse-audio question?
I'd like to know because surely I'll de-patch them myself, as I'm using Pulseaudio for a while and I'm happy with it.
Btw I agree for this decision, in fact many people don't use already PA or they have some (big) problems with it.
Offline