On 17 Jul 2020, Boyuan Yang wrote:
>Source: onetime
>Version: 1.122-1
>Severity: important
>X-Debbugs-CC: kfo...@red-bean.com
>
>Hi Karl,
>
>Thanks for maintaining package onetime in Debian. With Debian's removal
>of python2, your package (onetime) is affected since it depends on
>python2.
>
>I see
Norbert Preining writes:
>reassign 854059 texlive-lang-japanese
>reassign 853937 texlive-lang-japanese
>severity 854059 serious
>severity 853937 serious
>merge 852611 854059 853937
>thanks
>
>Hi Andreas, hi Karl,
>
>already reported and will hopefully be fixed by src:texlive-base
>transitioning to
I'm also experiencing this bug, FWIW. This is on a Deban GNU/Linux 'testing'
distro system, dist-upgraded daily:
Linux kwork 4.9.0-1-amd64 #1 SMP Debian 4.9.2-2 (2017-01-12) x86_64 GNU/Linux
At the end of this mail, I'll include the full output of 'apt-get
dist-upgrade', but first here's the
I'm seeing this bug too, for what it's worth. By the way, if you do
# apt-get remove iagno
...the result is very bad -- apt-get claims it will remove 'gnome' and
'gnome-desktop-environment', among other things!
The reason appears to be that 'gnome' depends on 'gnome-games', and
'gnome-games'
This can be closed now -- the 2to3 man page has apparently been updated,
and now starts with this text:
2to3-2.7 - Python2 to Python3 converter
I would close this ticket myself, if I could figure out how! I
originally tried to do so by sending this mail to "close-662005" (at
bugs.debian.o
Daniel Kahn Gillmor writes:
>Package: onetime
>Version: 1.122-1
>Severity: wishlist
>
>as you probably know, onetime version 2.0-beta is available upstream
>:P
>
>http://www.red-bean.com/onetime/
>
>it would be great to have this in debian, even if only in experimental
>while it's beta.
Recommend
I ran into this problem too. I was doing a netinstall of Debian
'testing' (having booted from a USB stick created by "zcat boot.img.gz >
/dev/sdb", then mounting, then running unetbootin on the same stick).
Early in the "Install the base system" stage, using the text (ncurses?
non-graphical, anyw
I was stuck in the same place in a squeeze->testing upgrade -- doing
"apt-get upgrade" (and various other commands) got the error:
E: Could not perform immediate configuration on 'libgstreamer0.10-0'.
Please see man 5 apt.conf under APT::Immediate-Configure for details. (2)
I do not have a re
I've incorporated both of your changes into the upstream;
when the next version comes out, your patch will be in it. See
http://viewvc.red-bean.com/onetime?view=revision&revision=108 .
-Karl Fogel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subjec
New version uploaded, after comments from some people helping. I
won't bother to paste the upload output here any longer, as the
package is signed anyway.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Everything is here:
http://www.red-bean.com/kfogel/debian/onetime/
MD5 sums:
3b0851676b54bfde83ae554f698bad87 onetime_1.73-1.diff.gz
406245483994c4712bcdf41613296442 onetime_1.73-1.dsc
787629d4b3e7e631eee1338471efa70d onetime_1.73-1_i386.changes
8c13560c2749d27f33d483050450fd20
Latest files are in the usual place:
http://www.red-bean.com/kfogel/debian/onetime/
File sizes:
3164 2008-09-14 02:55 onetime_1.73-1.diff.gz
936 2008-09-14 02:55 onetime_1.73-1.dsc
1684 2008-09-14 02:55 onetime_1.73-1_i386.changes
11642 2008-09-14 02:55 onetime_1.73-1_
By the way, anyone can reproduce what I'm doing by following these
steps:
$ svn co http://svn.red-bean.com/repos/onetime/trunk/ onetime
$ cd onetime
$ make deb
$ lintian -i debian/output/onetime_1.73-1_i386.changes
IOW, the packaging routine is encoded in the top-level Makefile and in
Most of the lintian errors are fixed now, but these remain:
$ lintian onetime_1.73-1_i386.changes
W: onetime source: debian-watch-file-in-native-package
W: onetime source: native-package-with-dash-version
W: onetime: binary-without-manpage usr/bin/onetime
$
(I'll give the detaile
I didn't run 'lintian' yet, nor the other cleanup steps listed in
Chapter 7 of the Debian New Maintainers guide, that is:
http://www.debian.org/doc/maint-guide/ch-checkit.en.html
You may wish to ignore the above package files until I've done that
and (presumably) uploaded new versions.
-Karl
I've packaged it up (thanks to Micah Anderson for gobs of help, and to
Jacob Appelbaum for a timely tweak). Everything's in here:
http://www.red-bean.com/kfogel/debian/onetime/
Specifically:
onetime_1.73-1.dsc
onetime_1.73-1.tar.gz
onetime_1.73-1_i386.changes
onetime_1.73-1_i386.
Package: wnpp
Severity: wishlist
Owner: Karl Fogel <[EMAIL PROTECTED]>
* Package name: onetime
Version : 1.73
Upstream Author : Karl Fogel <[EMAIL PROTECTED]>
* URL : http://www.red-bean.com/onetime
* License : Public Domain
Programming
"Wesley J. Landaker" <[EMAIL PROTECTED]> writes:
> On Monday 12 February 2007 13:41, dann frazier wrote:
>> fyi, my current plan is to upload this to Debian as a separate package
>> (could be merged into subversion later). If there's enough time, I may
>> ask the release managers to accept it into
dann frazier <[EMAIL PROTECTED]> writes:
> But, I'd like to propose my own - 'svn-load'. I prefer this because:
> * Its short! And I tend to type it a lot...
> * It has 'svn' as a prefix
> * It is reminiscent of the original (what was the name of that
> command that replaced svn_load_dirs...
"Ivan Zhakov" <[EMAIL PROTECTED]> writes:
> Looks reasonable for me. Also I propose change "_" separator symbol to "-".
> So "svn-intake" is my best :)
+1, I like it.
> And we could have "svn import --intake" (or "svn import --replace") in
> feature.
You mean, as a built-in feature of Subversio
"Ivan Zhakov" <[EMAIL PROTECTED]> writes:
> I've an old idea that functionality of 'svn_load_dirs.pl' should just
> extended behavior of 'svn import' command. So I propose name like
> 'svn_import'.
But then it would be impossible to tell whether one means "svn import"
or "svn_import", in speech.
dann frazier <[EMAIL PROTECTED]> writes:
> Due to licensing issues w/ svn_load_dirs[1], I have started a
> reimplementation of this tool, currently under the GPL license. This
> implementation is intended to become a drop-in replacement for
> svn_load_dirs, though it is currently missing some of it
Hey, Peter, can I make a suggestion? "svn_load_dirs" was never a very
descriptive name anyway, for a tool that essentially does what most
people think of as "vendor branches" (although some object to the
latter term on the grounds that often the source is not a vendor but
another open source proje
23 matches
Mail list logo
