[arch-general] Any place where changes in testing are announced?
Hello, after doing a system upgrade after some months, I found out the hard way that the HAL support was removed from xorg-server. I wasted a full hour trying to get my keyboard layouts back before realizing my recreated policy file is fine, it is just not being used... Is there any place -- other than arch-dev-public which I do not read -- where changes in testing are announced and that could save me headaches like this? (Besides, I'm not using an US layout and had no issues with the Xkb configuration through HAL...) Thanks, :g
On Mon, Apr 28, 2008 at 03:07:02PM +0200, Peter Galiovsky wrote:
Hello,
after doing a system upgrade after some months, I found out the hard way that the HAL support was removed from xorg-server. I wasted a full hour trying to get my keyboard layouts back before realizing my recreated policy file is fine, it is just not being used...
Is there any place -- other than arch-dev-public which I do not read -- where changes in testing are announced and that could save me headaches like this?
(Besides, I'm not using an US layout and had no issues with the Xkb configuration through HAL...)
Thanks, :g
Keep an eye on the bug tracker and the arch-dev-public mailing list. Changes in testing are not announced. They are discussed in either or both of the above places. The issue you are refering to started in the forum, moved to the bugtracker and then was discussed on the public dev mailing list. Greg
On Mon, Apr 28, 2008 at 3:28 PM, Grigorios Bouzakis <grbzks@gmail.com> wrote:
On Mon, Apr 28, 2008 at 03:07:02PM +0200, Peter Galiovsky wrote:
Hello,
after doing a system upgrade after some months, I found out the hard way that the HAL support was removed from xorg-server. I wasted a full hour trying to get my keyboard layouts back before realizing my recreated policy file is fine, it is just not being used...
Is there any place -- other than arch-dev-public which I do not read -- where changes in testing are announced and that could save me headaches like this?
(Besides, I'm not using an US layout and had no issues with the Xkb configuration through HAL...)
Thanks, :g
Keep an eye on the bug tracker and the arch-dev-public mailing list. Changes in testing are not announced. They are discussed in either or both of the above places. The issue you are refering to started in the forum, moved to the bugtracker and then was discussed on the public dev mailing list.
Greg
And as far as I can see, the testing repo is what it means : for testing! Packages are tested, and breakages / changes are often found during that period. When these changes are normal and/or unavoidable, an announcement is usually made before they are pushed to core / extra. Testing is for people who are willing to contribute to the stability and smooth upgrades of core/extra packages, who have time to figure things out when a breakage happen (which sometimes means spending a few hours, and getting headaches), who update regularly (more than every few months), and who follow arch-dev-public. No one can prevent people who don't fit all these requirements to use testing, but at least they should be aware of them.
Xavier __ 28.04.2008 15:47
And as far as I can see, the testing repo is what it means : for testing! Packages are tested, and breakages / changes are often found during that period. When these changes are normal and/or unavoidable, an announcement is usually made before they are pushed to core / extra. Testing is for people who are willing to contribute to the stability and smooth upgrades of core/extra packages, who have time to figure things out when a breakage happen (which sometimes means spending a few hours, and getting headaches), who update regularly (more than every few months), and who follow arch-dev-public. No one can prevent people who don't fit all these requirements to use testing, but at least they should be aware of them.
There are times when I do have the time to upgrade often, read the mailing lists, browse through the forums and file some bugs. And there are times when I don't have it. Probably I should just disable the testing repo for times like that. I was just curious if there is any single place where, for example, changelogs for packages can be found. Maybe it could be created automatically from SVN log messages. (Yeah, I know, I can implement it if I really want it.) :g
On Tue 2008-04-29 00:17 , Peter Galiovsky wrote:
[...] I was just curious if there is any single place where, for example, changelogs for packages can be found.
Maybe it could be created automatically from SVN log messages.
(Yeah, I know, I can implement it if I really want it.)
Actually there is the support for packages' changelog, but few maintainers write them. -- Alessio (molok) Bolognino Please send personal email to themolok@gmail.com Public Key http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFE0270FB GPG Key ID = 1024D / FE0270FB 2007-04-11 Key Fingerprint = 9AF8 9011 F271 450D 59CF 2D7D 96C9 8F2A FE02 70FB
On Mon, Apr 28, 2008 at 4:24 PM, Alessio Bolognino <themolok.ml@gmail.com> wrote:
Actually there is the support for packages' changelog, but few maintainers write them.
Wouldn't changelogs more reflect upstream changes than Arch packaging changes? Scott
On Mon 2008-04-28 16:32 , Scott Horowitz wrote:
On Mon, Apr 28, 2008 at 4:24 PM, Alessio Bolognino <themolok.ml@gmail.com> wrote:
Actually there is the support for packages' changelog, but few maintainers write them.
Wouldn't changelogs more reflect upstream changes than Arch packaging changes?
Pacman's changelog support was added to reflect "package's changes", not "upstream changes"; that's what frugalware devs are doing, and they use (almost) the same package manager. -- Alessio (molok) Bolognino Please send personal email to themolok@gmail.com Public Key http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFE0270FB GPG Key ID = 1024D / FE0270FB 2007-04-11 Key Fingerprint = 9AF8 9011 F271 450D 59CF 2D7D 96C9 8F2A FE02 70FB
On Mon, Apr 28, 2008 at 4:40 PM, Alessio Bolognino <themolok.ml@gmail.com> wrote:
Pacman's changelog support was added to reflect "package's changes", not "upstream changes"; that's what frugalware devs are doing, and they use (almost) the same package manager.
Interesting, it seems you're correct. It looks like the only way to know this, though, is to look at the changelog.proto file. None of the pacman documentation alludes to this fact, so I always assumed it was upstream changes. Considering this is the case, I'm with Peter - why not just automatically update the changelog from svn commit messages? Otherwise I'm having a hard time believing that packagers will ever start writing them... Scott
On Mon, Apr 28, 2008 at 6:05 PM, Scott Horowitz <stonecrest@gmail.com> wrote:
On Mon, Apr 28, 2008 at 4:40 PM, Alessio Bolognino
<themolok.ml@gmail.com> wrote:
Pacman's changelog support was added to reflect "package's changes", not "upstream changes"; that's what frugalware devs are doing, and they use (almost) the same package manager.
Interesting, it seems you're correct. It looks like the only way to know this, though, is to look at the changelog.proto file. None of the pacman documentation alludes to this fact, so I always assumed it was upstream changes.
Considering this is the case, I'm with Peter - why not just automatically update the changelog from svn commit messages? Otherwise I'm having a hard time believing that packagers will ever start writing them...
Well if a changelog consisting of: upgpkg: gimp 2.5.0-2 upgpkg: gimp 2.5.0-1 upgpkg: gimp 2.4.9-1 upgpkg: gimp 2.4.8-1 upgpkg: gimp 2.4.7-1 helps you, then file a support request or something. I don't find it particularly helpful. But this ties SVN to package building, and you can't commit before you build the package, and then your log messages are always one behind, etc. I didn't want to go flaming before and I still don't, but the OP is asking for us to keep him informed of every decision and step we take even though he doesn't have time to read the mailing list. Sorry, but this is impossible and the rest of us aren't going to take the time to keep you perfectly happy. Either you follow the public mailing list or you can't- that is fine. But you can't expect our small development staff to bend over to feed you changelogs when you can look at the SVN commits to follow development. Speaking of which, maybe this will be helpful to some: http://archlinux.org/pipermail/arch-commits/ -Dan
On Mon, Apr 28, 2008 at 5:17 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Well if a changelog consisting of: upgpkg: gimp 2.5.0-2 upgpkg: gimp 2.5.0-1 upgpkg: gimp 2.4.9-1 upgpkg: gimp 2.4.8-1 upgpkg: gimp 2.4.7-1
helps you, then file a support request or something. I don't find it particularly helpful. But this ties SVN to package building, and you can't commit before you build the package, and then your log messages are always one behind, etc.
Granted that it's not always very interesting, but I'd rather know that changelog by issuing a simple pacman command than hunting down the commit log through the web interface. That said, you raise a good point about always being one behind. Damn those pesky details. Scott
Dan McGee __ 29.04.2008 01:17
On Mon, Apr 28, 2008 at 6:05 PM, Scott Horowitz <stonecrest@gmail.com> wrote:
On Mon, Apr 28, 2008 at 4:40 PM, Alessio Bolognino Considering this is the case, I'm with Peter - why not just automatically update the changelog from svn commit messages? Otherwise I'm having a hard time believing that packagers will ever start writing them...
Well if a changelog consisting of: upgpkg: gimp 2.5.0-2 upgpkg: gimp 2.5.0-1 upgpkg: gimp 2.4.9-1 upgpkg: gimp 2.4.8-1 upgpkg: gimp 2.4.7-1
helps you, then file a support request or something. I don't find it particularly helpful. But this ties SVN to package building, and you
Neither do I. I assumed "package's changes" (not upstream changes) were already being entered as SVN log entries.
Speaking of which, maybe this will be helpful to some: http://archlinux.org/pipermail/arch-commits/
That could be helpful, thanks. :g
On Dienstag, 29. April 2008 00:40 Alessio Bolognino wrote:
Pacman's changelog support was added to reflect "package's changes", not "upstream changes"; that's what frugalware devs are doing, and they use (almost) the same package manager.
Yes that is right and i don't think that anyone will make more work for the devs. Okay, let us look at the beginning of this thread and so at first, xorg-server has no ChangeLog but this "--enable-config-hal" was a "package's change" and not a "upstream change". Second, i suggest that the devs take a look at *.spec files from a rpm based distribution (or something else) and think about if this will be realy so much work to document the changes which could be a help for testers, users and other devs too. I attach the xorg-x11.spec from opensuse 10.3 source rpm to give a example (search for the %changelog line) and again, this is only a suggestion to make it easier for everyone to see the diffs. You will see that the lines been very short but in the worst case they could be very helpfull to understand the problem or in the best case you can understand why something works better as before and another one can make his package in the same way. Sometimes i have the feeling that in every discussion about this ChangeLog the most see this more than a "ohh, i have to write a documentation" instead of that his could be a help for themselves too. Important last note: I don't suggest to document the past because we all do this here in private time. And yes, if the package is the normal and simple configure&make game than a ChangeLog is not really necessary. See you, Attila
participants (7)
-
Alessio Bolognino
-
Attila
-
Dan McGee
-
Grigorios Bouzakis
-
Peter Galiovsky
-
Scott Horowitz
-
Xavier