Bug#486594: timestamps
Booh ! Le 01. 12. 13 06:00, James McCoy a écrit : An alternative would be to use the faketime[0] tool to wrap your dch calls. That's it ! I wondered if something like that existed. Thanks ! I also found out that dch could invoke date -d @1970-timestamp. That does look useful, but if there aren't any side effects to setting LC_TIME, I'd prefer that over adding a dependency. It's still simple enough code. Can be. I would personally prefer using the package, %a, %d %b %Y %T %z isn't really meaningful, but you are the people who care for the script, so I let you decide. Feel free, I will make my program work with faketime if you reject 0002. As you told Julian Gilbey and as far as I know, the three variants that exist get us to the same result. If setting LC_TIME affected something else than the call to strftime I'm messing with, There would probably be a mistake in the first place, since these tools shouldn't produce locale-dependent output, except for the timezone. Is this reasoning right ? Big up, Louis -- When I grow up, I will run a Tor node around the clock, To help threatened protesters 'round the world. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#486594: timestamps
Good evening developers,
I'm a novice contributor and I have done some work on your scripts,
which I would like to submit to you.
I didn't found any library that can produce d/changelog files, so I
decided to invoke dch with the right options, besides it can manage
multi-maintainer releases, and since this feature is hardcoded, I
thought there was no library supporting it at all. I needed to create
entries with specific timestamps, so I started hacking dch to implement
an option for that.
Since there seems to be no way to feed a %s value to date, I decided
to use strftime(), and thus get rid of the date -R invocation. It seems
to me that globally setting the locale to C doesn't cause trouble
(dch Ìnîtíãl release. is fine) but I may be wrong. However, there
could be a better solution with the Email::Date::Format package ; it
takes care of formatting time according to RFC 2822 and doesn't touch
the locale. It does exactly what we want in a clean way, so it's
probably worth depending on it.
Please take time to judge the attached patches. If you ask, I can
rearrange them, removing the intermediate step `date` - strftime() -
email_date, for example. I didn't update the changelog (no joke
intended) to keep patches light.
Greetings,
Louis
--
When I grow up,
I will run a Tor node around the clock,
To help threatened protesters 'round the world.
From 3855f74c27cf79a230d3c89c0d2e211fe43c2d1c Mon Sep 17 00:00:00 2001
From: Louis Bettens lo...@bettens.info
Date: Sat, 30 Nov 2013 20:12:00 +0100
Subject: [PATCH 1/5] debchange: replace call to date -R with strftime()
---
scripts/debchange.pl | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/scripts/debchange.pl b/scripts/debchange.pl
index 82875d6..3ec288d 100755
--- a/scripts/debchange.pl
+++ b/scripts/debchange.pl
@@ -43,6 +43,9 @@ use Dpkg::Compression;
use Dpkg::Vendor qw(get_current_vendor);
use lib '/usr/share/devscripts';
use Devscripts::Debbugs;
+use POSIX qw(locale_h strftime);
+
+setlocale(LC_TIME, C); # so that strftime is locale independent
# Predeclare functions
sub fatal($);
@@ -989,8 +992,7 @@ if (@ARGV and ! $TEXT) {
}
# Get the date
-my $date_cmd = ($opt_tz ? TZ=$opt_tz : ) . date -R;
-chomp(my $DATE=`$date_cmd`);
+my $DATE=strftime %a, %d %b %Y %T %z, localtime();
if ($opt_news !$opt_i !$opt_a) {
if ($VERSION eq $changelog{'Version'} !$opt_v !$opt_l) {
--
1.8.4.3
From e5a0712e721fa3d2ba01a83b33035ad83f88c967 Mon Sep 17 00:00:00 2001
From: Louis Bettens lo...@bettens.info
Date: Sat, 30 Nov 2013 19:58:10 +0100
Subject: [PATCH 2/5] add --timestamp
---
scripts/debchange.pl | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/scripts/debchange.pl b/scripts/debchange.pl
index 3ec288d..b6ce458 100755
--- a/scripts/debchange.pl
+++ b/scripts/debchange.pl
@@ -129,6 +129,9 @@ Options:
Increase the Debian release number, adding a new changelog entry
-v version, --newversion=version
Add a new changelog entry with version number specified
+ --timestamp=timestamp
+ When generating a trailer line, use the specified time as a number of
+ seconds after january 1st, 1970 instead of the current time
-e, --edit
Don't change version number or add a new changelog entry, just
update the changelog's stamp and open up an editor
@@ -363,7 +366,7 @@ if (@ARGV and $ARGV[0] =~ /^--no-?conf$/) {
# We use bundling so that the short option behaviour is the same as
# with older debchange versions.
my ($opt_help, $opt_version);
-my ($opt_i, $opt_a, $opt_e, $opt_r, $opt_v, $opt_b, $opt_d, $opt_D, $opt_u, $opt_force_dist);
+my ($opt_i, $opt_a, $opt_timestamp, $opt_e, $opt_r, $opt_v, $opt_b, $opt_d, $opt_D, $opt_u, $opt_force_dist);
my ($opt_n, $opt_bn, $opt_qa, $opt_R, $opt_s, $opt_team, $opt_U, $opt_bpo, $opt_l, $opt_c, $opt_m, $opt_M, $opt_create, $opt_package, @closes);
my ($opt_news);
my ($opt_level, $opt_regex, $opt_noconf, $opt_empty);
@@ -371,6 +374,7 @@ my ($opt_level, $opt_regex, $opt_noconf, $opt_empty);
Getopt::Long::Configure('bundling');
GetOptions(help|h = \$opt_help,
version = \$opt_version,
+ timestamp=s = \$opt_timestamp,
i|increment = \$opt_i,
a|append = \$opt_a,
e|edit = \$opt_e,
@@ -992,7 +996,8 @@ if (@ARGV and ! $TEXT) {
}
# Get the date
-my $DATE=strftime %a, %d %b %Y %T %z, localtime();
+$opt_timestamp = defined $opt_timestamp ? $opt_timestamp : time;
+my $DATE=strftime %a, %d %b %Y %T %z, localtime($opt_timestamp);
if ($opt_news !$opt_i !$opt_a) {
if ($VERSION eq $changelog{'Version'} !$opt_v !$opt_l) {
--
1.8.4.3
From dad123b835d99a012c29e908026b4ccf1b259910 Mon Sep 17 00:00:00 2001
From: Louis Bettens lo...@bettens.info
Date: Sat, 30 Nov 2013 20:52:49 +0100
Subject: [PATCH 3/5] bts: replace call to date -R with strftime()
---
scripts/bts.pl | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/scripts/bts.pl b/scripts/bts.pl
Bug#725577: haskell-hashable_1.2.1.0-1_amd64.changes ACCEPTED into unstable
Hi! Thank you for building my packages, especially ghc (an hour and a half). The 0.7.0 release of yi fixes this bug, so I closed it in the changelog. Some package depended on by yi also depend on hashable. I updated uniplate and the others can be built with the new version. I'm taking a quick look at the other packages that depend on hashable to ensure they don't break. Louis -- When I grow up, I will run a Tor node around the clock, To help threatened protesters 'round the world. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725577: [Pkg-haskell-maintainers] Bug#725577: yi: FTBFS: The program alex version =3.0.3 =3.0.5 is required but the version found at /usr/bin/alex is version 3.1.0
Hello again! The bug on the test suite has been fixed by dd691fa6791d67981388ec044b28343879d8c2b1, commit by Johan Tibell, last year on 29th October. He fixed the exact bug I ran into. I'm creating a patch on the Cabal included in ghc applying the fix with quilt. No conflict. I'm tuning the patch metadata and I'm sending it. Good night, Louis -- When I grow up, I will run a Tor node around the clock, To help threatened protesters 'round the world. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725577: [Pkg-haskell-maintainers] Bug#725577: yi: FTBFS: The program alex version =3.0.3 =3.0.5 is required but the version found at /usr/bin/alex is version 3.1.0
'evening, Hashable's test suit is fine with cabal-1.19. I'll bisect tomorrow (I just attempted to). Louis -- When I grow up, I will run a Tor node around the clock, To help threatened protesters 'round the world. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725577: yi: FTBFS: The program alex version =3.0.3 =3.0.5 is required but the version found at /usr/bin/alex is version 3.1.0
Le 06. 10. 13 22:39, Joachim Breitner a écrit : Control: tags -1 + confirmed fixed-upstream Hi, Am Sonntag, den 06.10.2013, 22:00 +0200 schrieb David Suárez: Relevant part (hopefully): unordered-containers-0.2.3.0 Dependency utf8-string=0.3.1: using utf8-string-0.3.7 Dependency vty=4.7.0.0 5: using vty-4.7.0.20 Dependency xdg-basedir=0.2.1 0.3: using xdg-basedir-0.2.2 Dependency yi -any: using yi-0.6.7.0 hlibrary.setup: The program alex version=3.0.3 =3.0.5 is required but the version found at /usr/bin/alex is version 3.1.0 make: *** [dist-ghc] Error 1 fixed in upstream’s 0.7.0. Louis, care to do an upload? Greetings, Joachim Yep! I ran pkg-haskell-uupdate to look at what would happen, but I don't have much time this evening. Seems like this new version depends on hashable-1.2, but it's only packaged up to 1.1. I got a build error with the test suite of hashable-1.2, I'll search this when I have free time. I can also say that patching yi.cabal to loosen the dependency lets yi build. (and that's all, perhaps it doesn't run properly.) Gute Nacht, Louis -- When I grow up, I will run a Tor node around the clock, To help threatened protesters 'round the world. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725577: yi: FTBFS: The program alex version =3.0.3 =3.0.5 is required but the version found at /usr/bin/alex is version 3.1.0
Allo, Le 07. 10. 13 21:04, Joachim Breitner a écrit : it probably makes more sense to update hashable, if that does not require (too many) updates of other packages. Of course the test suite should go through first. You are right. Even under pdebuild, when building hashable's testsuite, cabal guesses that hsc2hs should be run on tests/Regress/Mmap.hsc, but the result goes into dist/build/Regress/Mmap.hs and later, ghc looks for it in dist/build/tests/tests-tmp/Regress/Mmap.hs. Cabal bug? Here's my output : $ cabal configure --enable-tests Resolving dependencies... Configuring hashable-1.2.1.0... $ cabal build Building hashable-1.2.1.0... Preprocessing library hashable-1.2.1.0... [1 of 3] Compiling Data.Hashable.Class ( Data/Hashable/Class.hs, dist/build/Data/Hashable/Class.o ) [2 of 3] Compiling Data.Hashable.Generic ( Data/Hashable/Generic.hs, dist/build/Data/Hashable/Generic.o ) [3 of 3] Compiling Data.Hashable( Data/Hashable.hs, dist/build/Data/Hashable.o ) [1 of 3] Compiling Data.Hashable.Class ( Data/Hashable/Class.hs, dist/build/Data/Hashable/Class.p_o ) [2 of 3] Compiling Data.Hashable.Generic ( Data/Hashable/Generic.hs, dist/build/Data/Hashable/Generic.p_o ) [3 of 3] Compiling Data.Hashable( Data/Hashable.hs, dist/build/Data/Hashable.p_o ) In-place registering hashable-1.2.1.0... Preprocessing test suite 'tests' for hashable-1.2.1.0... Mmap.hsc: In function ‘main’: Mmap.hsc:53:5: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] Mmap.hsc:53:5: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] The above proves that hsc2hs has been working. tests/Regress.hs:8:18: Could not find module `Regress.Mmap' Use -v to see a list of the files searched for. Yep. Suggest cabal build --ghc-option=-v. What do you think? It's late, so I'll report what ought to be reported tomorrow. Buona notte, Louis -- When I grow up, I will run a Tor node around the clock, To help threatened protesters 'round the world. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720714: [Pkg-haskell-maintainers] Bug#720714: Bug#720714: Acknowledgement (will no longer work once rebuilt with linux-libc-dev 3.10.5)
Le 24. 08. 13 23:38, Joey Hess a écrit : Louis Bettens wrote: Done. The patch is being pushed in a couple of minutes. I commited a NMU (at least in the changelog) so what's next? This patch has been included in a new upstream release. Oups, well, I went ahead and adapted your commit to the current version, the same way I did before on Taffybar. I'm going to use pkg-haskell-uupdate and rollback the patch I added. Also, shouldn't we add a dependency constraint on libc-something? -- When I grow up, I will run a Tor node around the clock, To help threatened protesters 'round the world. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720714: [Pkg-haskell-maintainers] Bug#720714: Acknowledgement (will no longer work once rebuilt with linux-libc-dev 3.10.5)
Le 24. 08. 13 20:35, Joey Hess a écrit : See https://github.com/audreyt/network-multicast/pull/6 for a patch for this and also for an ugly file descriptor leak bug. ___ Pkg-haskell-maintainers mailing list pkg-haskell-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-haskell-maintainers Hello, I'm familiar with darcs, so I'm going to do that. Have a nice day, Louis
Bug#720714: [Pkg-haskell-maintainers] Bug#720714: Bug#720714: Acknowledgement (will no longer work once rebuilt with linux-libc-dev 3.10.5)
Le 24. 08. 13 20:42, Louis Bettens a écrit : Hello, I'm familiar with darcs, so I'm going to do that. Have a nice day, Louis Done. The patch is being pushed in a couple of minutes. I commited a NMU (at least in the changelog) so what's next? -- When I grow up, I will run a Tor node around the clock, To help threatened protesters 'round the world. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
