[arch-general] Any place where changes in testing are announced?

Peter Galiovsky

28 Apr 2008 28 Apr '08

3:07 p.m.

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

Show replies by date

Grigorios Bouzakis

28 Apr 28 Apr

3:28 p.m.

New subject: [arch-general] Any place where changes in testing are announced?

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

Xavier

3:47 p.m.

On Mon, Apr 28, 2008 at 3:28 PM, Grigorios Bouzakis 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.

Peter Galiovsky

29 Apr 29 Apr

12:17 a.m.

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

Alessio Bolognino

12:24 a.m.

New subject: [arch-general] Any place where changes in testing are announced?

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

Scott Horowitz

12:32 a.m.

On Mon, Apr 28, 2008 at 4:24 PM, Alessio Bolognino 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

Alessio Bolognino

12:40 a.m.

New subject: [arch-general] Any place where changes in testing are announced?

On Mon 2008-04-28 16:32 , Scott Horowitz wrote:

...

On Mon, Apr 28, 2008 at 4:24 PM, Alessio Bolognino 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

Scott Horowitz

1:05 a.m.

On Mon, Apr 28, 2008 at 4:40 PM, 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.

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

Dan McGee

1:17 a.m.

On Mon, Apr 28, 2008 at 6:05 PM, Scott Horowitz wrote:

...

On Mon, Apr 28, 2008 at 4:40 PM, 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.

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

Scott Horowitz

4:43 a.m.

On Mon, Apr 28, 2008 at 5:17 PM, Dan McGee 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

Peter Galiovsky

30 Apr 30 Apr

12:48 p.m.

Dan McGee __ 29.04.2008 01:17

...

On Mon, Apr 28, 2008 at 6:05 PM, Scott Horowitz 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

Attila

29 Apr 29 Apr

7:52 a.m.

New subject: [arch-general] Any place where changes in testing are announced?

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

5837

Age (days ago)

5839

Last active (days ago)

List overview

Download

11 comments

7 participants

participants (7)

Alessio Bolognino
Attila
Dan McGee
Grigorios Bouzakis
Peter Galiovsky
Scott Horowitz
Xavier