Re: %changelog not in descending chronological order
On Thu, Jul 12, 2012 at 03:16:02PM -0400, Jeffrey Johnson wrote: On Jul 12, 2012, at 2:26 PM, Kacper Kornet drae...@pld-linux.org wrote: That can be because 'git rev-list', used to generate the changelog, returns the commits ordered by commit date and not the AuthorDate Doing qsort(3) on RPMTAG_CHANGELOG* in rpmbuild isn't too hard, might be easier than trying to figure out how to trick up git sewage. I wonder if RPM really needs to enforce the changelog order. Would it really hurt if it just allowed building a package with such seemingly unordered entries? Will anything break if we just disable the test? Greets, Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %changelog not in descending chronological order
On Jul 16, 2012, at 12:38 PM, Jacek Konieczny jaj...@jajcus.net wrote: On Thu, Jul 12, 2012 at 03:16:02PM -0400, Jeffrey Johnson wrote: On Jul 12, 2012, at 2:26 PM, Kacper Kornet drae...@pld-linux.org wrote: That can be because 'git rev-list', used to generate the changelog, returns the commits ordered by commit date and not the AuthorDate Doing qsort(3) on RPMTAG_CHANGELOG* in rpmbuild isn't too hard, might be easier than trying to figure out how to trick up git sewage. I wonder if RPM really needs to enforce the changelog order. Would it really hurt if it just allowed building a package with such seemingly unordered entries? Will anything break if we just disable the test? Yes loss of legacy compatibility would hurt with unordered entries. Nothing would break if all change log entries were ripped out either. (aside) The ordering constraint was likely a quick hack to detect time issues on an alpha miata (knowing almost all of RPM's hysteria). 73 de Jeff Greets, Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %changelog not in descending chronological order
On Mon, Jul 16, 2012 at 12:41:55PM -0400, Jeffrey Johnson wrote: (aside) The ordering constraint was likely a quick hack to detect time issues on an alpha miata (knowing almost all of RPM's hysteria). Well it does help detect some mismerges... -- WBR, Michael Shigorin m...@altlinux.ru -- Linux.Kiev http://www.linux.kiev.ua/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %changelog not in descending chronological order
On Mon, Jul 16, 2012 at 06:38:10PM +0200, Jacek Konieczny wrote: On Thu, Jul 12, 2012 at 03:16:02PM -0400, Jeffrey Johnson wrote: On Jul 12, 2012, at 2:26 PM, Kacper Kornet drae...@pld-linux.org wrote: That can be because 'git rev-list', used to generate the changelog, returns the commits ordered by commit date and not the AuthorDate Doing qsort(3) on RPMTAG_CHANGELOG* in rpmbuild isn't too hard, might be easier than trying to figure out how to trick up git sewage. I wonder if RPM really needs to enforce the changelog order. Would it really hurt if it just allowed building a package with such seemingly unordered entries? Will anything break if we just disable the test? So we have two solutions: a) Switch to show committer dates in changelog. It should be possible to show these dates should be in chronological order. Drawback: for commits migrated from CVS this date is set to some value =~ time of cvs-git migration b) Patch rpm in PLD to remove enforcing of chronological order in changelog. The patch seems trivial. I would go for b). -- Kacper ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %changelog not in descending chronological order
On Jul 16, 2012, at 3:43 PM, Kacper Kornet drae...@pld-linux.org wrote: On Mon, Jul 16, 2012 at 06:38:10PM +0200, Jacek Konieczny wrote: On Thu, Jul 12, 2012 at 03:16:02PM -0400, Jeffrey Johnson wrote: On Jul 12, 2012, at 2:26 PM, Kacper Kornet drae...@pld-linux.org wrote: That can be because 'git rev-list', used to generate the changelog, returns the commits ordered by commit date and not the AuthorDate Doing qsort(3) on RPMTAG_CHANGELOG* in rpmbuild isn't too hard, might be easier than trying to figure out how to trick up git sewage. I wonder if RPM really needs to enforce the changelog order. Would it really hurt if it just allowed building a package with such seemingly unordered entries? Will anything break if we just disable the test? So we have two solutions: a) Switch to show committer dates in changelog. It should be possible to show these dates should be in chronological order. Drawback: for commits migrated from CVS this date is set to some value =~ time of cvs-git migration b) Patch rpm in PLD to remove enforcing of chronological order in changelog. The patch seems trivial. I would go for b). c) qsort the 3 change log tags d) rip out change logs from *.rpm entirely Unlike git scripting, any of b), c), f) are quite tricky. b) will introduce some incompatibilities: for starters, there's functionality already implemented to truncate change log's by number/oldest that will break if you just go unordered. hth 73 de Jeff -- Kacper ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
[PATCH] xorg-driver-input-wacom-0.15.0 - 0.16.0
ChangeLog:
0.15.0 - 0.16.0
Provide consistent 'filler' axes to X
Create a wrapper for InitValuatorAxisStruct
Find mouse buttons on pad devices if no generic buttons found
xsetwacom: fix leak in set()
Re-enable relative wheel scrolling from pad devices
Align returned type of wcmEventAutoDevProbe with expected type
Fix warning: Re-scope variable in wcmPreInitParseOptions
Fix warning: Remove variable re-definition in wcmSerialValidate
Fix warning: Swap empty string for NULL in wcmIsHotpluggedDevice
Fix warning: Swap empty string for NULL in wcmIsAValidType
Fix warning: Swap empty string for NULL in wcmNeedAutoHotplug
Fix warning: Swap empty string for NULL in wcmIsDuplicate
Fix warning: Swap empty strings for NULL in wcmCheckSource
Fix warning: Constify 'name' argument of InitWcmAtom
Fix warning: Remove superflous 'event' pointer in usbParseBTNEvent
Fix warning: Constify _WacomCommonRec.device_path
Fix warning: Change default_options to be const
Fix warning: Have wcmEventAutoDevProbe return const
Fix warning: Remove superflous casts in getScrollDelta
Add 0xED and 0xEF
conf: add Intuos4 WL (PTK-540WL) to fdi file
--
Przemo Firszt prz...@firszt.eu
--- xorg-driver-input-wacom/xorg-driver-input-wacom.spec~ 2012-07-16 21:33:21.279427449 +0100
+++ xorg-driver-input-wacom/xorg-driver-input-wacom.spec 2012-07-16 21:35:01.932161839 +0100
@@ -2,12 +2,12 @@
Summary: X.org input driver for Wacom tablets
Summary(pl.UTF-8): Sterownik wejściowy X.org dla tabletów Wacom
Name: xorg-driver-input-wacom
-Version: 0.15.0
+Version: 0.16.0
Release: 1
License: GPL
Group: X11/Applications
Source0: http://downloads.sourceforge.net/project/linuxwacom/xf86-input-wacom/xf86-input-wacom-%{version}.tar.bz2
-# Source0-md5: 3e342101f1f22a38741f246403487be6
+# Source0-md5: aeee2bd339c825a9b1215df6a2e5e50b
URL: http://xorg.freedesktop.org/
BuildRequires: autogen
BuildRequires: automake
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %changelog not in descending chronological order
On Mon, Jul 16, 2012 at 03:47:41PM -0400, Jeffrey Johnson wrote: b) will introduce some incompatibilities: for starters, there's functionality already implemented to truncate change log's by number/oldest that will break if you just go unordered. But that would be not 'totally unordered'. GIT history is just not linear, so there is no 'one real chronological order'. What is currently generated is enough for such features like 'truncate to last X entries', it is just not 'chronological enough' for RPM. RPM doing the sorting may in fact break the history – RPM does not know full history from the short git log excerpts. E.g. an old commit (made long time ago on a development branch) just recently added to the master branch could be moved past the truncation point. I also think that patching RPM may be the best choice here – easy and effective. Greets, Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %changelog not in descending chronological order
On Tue, Jul 17, 2012 at 12:02:58AM +0200, Jacek Konieczny wrote: But that would be not 'totally unordered'. GIT history is just not linear It's the different history: take %changelog as NEWS and commit messages as CHANGELOG. The latter is for developers while the former is for users (sysadmins). And for a given package there's sense to make sure its git history *is* linear. See e.g. http://git.altlinux.org/gears/r/rpm.git (which is an archived version of what got into packages built -- while individual maintainers can have widely different intermediate trees published, the inheritance is enforced by the build system). -- WBR, Michael Shigorin m...@altlinux.ru -- Linux.Kiev http://www.linux.kiev.ua/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %changelog not in descending chronological order
On Mon, Jul 16, 2012 at 03:47:41PM -0400, Jeffrey Johnson wrote: On Jul 16, 2012, at 3:43 PM, Kacper Kornet drae...@pld-linux.org wrote: On Mon, Jul 16, 2012 at 06:38:10PM +0200, Jacek Konieczny wrote: On Thu, Jul 12, 2012 at 03:16:02PM -0400, Jeffrey Johnson wrote: On Jul 12, 2012, at 2:26 PM, Kacper Kornet drae...@pld-linux.org wrote: That can be because 'git rev-list', used to generate the changelog, returns the commits ordered by commit date and not the AuthorDate Doing qsort(3) on RPMTAG_CHANGELOG* in rpmbuild isn't too hard, might be easier than trying to figure out how to trick up git sewage. I wonder if RPM really needs to enforce the changelog order. Would it really hurt if it just allowed building a package with such seemingly unordered entries? Will anything break if we just disable the test? So we have two solutions: a) Switch to show committer dates in changelog. It should be possible to show these dates should be in chronological order. Drawback: for commits migrated from CVS this date is set to some value =~ time of cvs-git migration b) Patch rpm in PLD to remove enforcing of chronological order in changelog. The patch seems trivial. I would go for b). c) qsort the 3 change log tags That can be done during changelog generation in builder. But I don't think it is a right solution. In my opinion changelog should reflect the topological history of development. b) will introduce some incompatibilities: for starters, there's functionality already implemented to truncate change log's by number/oldest that will break if you just go unordered. Do you mean the one build/parseChangelog.c:addChangelog? It depends how the breakage is defined. I have just checked and it behaves as expected in case of the non chronological changelog. If %_changelog_truncate macro is set to a date it ommits only older commits. All newer one are included independent of their position in changelog. And I think in PLD %_changelog_truncat macro should be set to a number, not a date. And there is always a possibility that was used in PLD in CVS. Generate the text of the whole changelog as a single entry in changelog from rpm point of view. That way rpm always see only one revision and does not complain. -- Kacper ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %changelog not in descending chronological order
On Tue, Jul 17, 2012 at 01:54:40AM +0300, Michael Shigorin wrote: On Tue, Jul 17, 2012 at 12:02:58AM +0200, Jacek Konieczny wrote: But that would be not 'totally unordered'. GIT history is just not linear It's the different history: take %changelog as NEWS and commit messages as CHANGELOG. The latter is for developers while the former is for users (sysadmins). And for a given package there's sense to make sure its git history *is* linear. See e.g. http://git.altlinux.org/gears/r/rpm.git (which is an archived version of what got into packages built -- while individual maintainers can have widely different intermediate trees published, the inheritance is enforced by the build system). Could you elaborate a little more how do you do it? I see that changelog entries are still present in spec files, and they are generated from commitlogs of tagged commits. But how does these commitlogs are generated. Are they some short of condensed 'git log' from the last tag? And how to you force that the tagged commits are in chronological order? -- Kacper ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
