Re: Handling Japanese new era "令和 (Reiwa)"

[Tatsuya Kinoshita]

On May 7, 2019 at 3:45AM +0900, henrich (at iijmio-mail.jp) wrote:
>>  I've noticed that Japan renews its era from 平成 (Heisei) to 令和 (Reiwa)
>>  (U+32FF) at 1st May and it's necessary to update some packages to deal
>>  with it. 
> 
>  Status update...

I updated the mhc package (schedule management tool for Emacs).

 * mhc: fixed in buster 1.2.1-2
   - 
https://tracker.debian.org/news/1039095/accepted-mhc-121-2-source-all-into-unstable/
   - https://tracker.debian.org/news/1039366/mhc-121-2-migrated-to-testing/

Also, simile-timeline seems fixed in buster.

cf. https://tracker.debian.org/pkg/simile-timeline

https://lists.debian.org/cgi-bin/search?P=reiwa&DEFAULTOP=and&B=Gdebian-devel-changes&SORT=0&HITSPERPAGE=100

https://groups.google.com/forum/#!searchin/linux.debian.bugs.dist/reiwa%7Csort:date

Thanks,
-- 
Tatsuya Kinoshita

Re: Preferred git branch structure when upstream moves from tarballs to git

[Ian Jackson]

Ansgar Burchardt writes ("Re: Preferred git branch structure when upstream 
moves from tarballs to git"):
> Sam Hartman  writes:
> > OK, I didn't hear that as an answer but think I'm coming to the same
> > conclusion that Ian did after reading your mail.
> > It sounds like you are talking about having the Debian packaging in a
> > separate repository from upstream.
> > Do I correctly understand the model you are talking about?
...
> I'll point to [1] for what complexity this avoids.  Try explaining that
> to someone without advanced Git knowledge...
> 
>   [1] 
> https://manpages.debian.org/unstable/git-debrebase/git-debrebase.5.en.html

I am getting increasingly unhappy with your tone, and with the thrust
of your arguments, in this thread.  Your messages feel very hostile to
me.

In this message you are using the fact that I have written a
comprehensive data model specification, against me.  This is a
seriously bad thing to do.  You should be applauding me for providing
serious documentation for advanced users.

The obvious counter is the (still comprehensive, but user-facing)
tutorial manpage.  For example,
  
https://manpages.debian.org/stretch-backports/dgit/dgit-maint-debrebase.7.en.html#EDITING_THE_DEBIAN_PACKAGING
et seq.

An equivalently detailed and frank document about dpkg-source would be
a nightmare.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#928604: ITP: soscleaner -- Python application to clean sensitive and un-wanted data from an existing sosreport

[Eric Desrochers]

Package: wnpp
Severity: wishlist
Owner: Eric Desrochers 

* Package name: soscleaner
  Version : v0.4.3
  Upstream Author : jduncan 
* URL : https://github.com/jduncan-rva/soscleaner
* License : GPL-2+
  Programming Lang: Python
  Description : Python application to clean sensitive and un-wanted data 
from an existing sosreport

Soscleaner is an open-source tool to take an sosreport, or any arbitrary 
dataset, and sanely obfuscate
potentially sensitive information so it can be shared with outside parties for 
support. An unaltered
copy of the data is maintained by the user so data can be mapped and 
suggestions supplied by a support
team can still be actionable, even without the sensitive information.

https://soscleaner.readthedocs.io/


* Why is this pacakge useful/relevant ?
This tool allow users to sanitise a sosreport before sharing it with  outside 
parties for support by
obfuscating every occurences of a hostname, ip, mac address and user. This is 
relevant for users who
doesn't want to share such sensible information and are concern about 
confidentiality.

* Is it a dependency for another package ?
The goal is to have soscleaner sanitizing existing sosreport collection, so 
soscleaner will depend on
sosreport which is already found in the archive.

* Do you use it ?
Yes, I've been testing it and used it, and I know that others will be 
interested to use it also.

* If there are other packages providing similar function
No, this package is very specific to sosreport, maybe other tool can do 
something similar but most
likely not as good as soscleaner does. Its main focus is sanitizing sosreport. 
It's also made by the same
upstream group.

* How do you plan to maintain it ?
I'm planning to maintain and/or co-maintain it. I'm already an uploader for 
sosreport, and planning to
maintain sosreport as well to make the release of both package smooth.

* Do you need a sponsor ?
Yes, until I get my DM permissions.

Re: Preferred git branch structure when upstream moves from tarballs to git

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

Ian> Ansgar Burchardt writes ("Re: Preferred git branch structure
Ian> when upstream moves from tarballs to git"):
>> Sam Hartman  writes: > OK, I didn't hear
>> that as an answer but think I'm coming to the same > conclusion
>> that Ian did after reading your mail.  > It sounds like you are
>> talking about having the Debian packaging in a > separate
>> repository from upstream.  > Do I correctly understand the model
>> you are talking about?
Ian> ...
>> I'll point to [1] for what complexity this avoids.  Try
>> explaining that to someone without advanced Git knowledge...
>> 
>> [1]
>> 
https://manpages.debian.org/unstable/git-debrebase/git-debrebase.5.en.html

Ian> I am getting increasingly unhappy with your tone, and with the
Ian> thrust of your arguments, in this thread.  Your messages feel
Ian> very hostile to 

I'd like to try and step in.

Ian, it sounds like you're frustrated.
I'd like to understand exactly why.

Is it that  you're frustrated  because you've spent a lot of time
working on documenting what you think is the simplest, best option, and
others are disagreeing?

I do find the work you've done valuable.  But like Ansgar I find that it
demonstrates there is a lot of complexity in the dgit work flows.  I
don't think this is a criticism of your work; I think that the reason
people are pointing to your work is that it clearly demonstrates the
complexity.

I also know that it's easy to sweep the complexity that we're familiar
with under the rug.  I hear your concern that people advocating other
approaches may be hiding complexity and that we need to be careful not
to hide complexity simply because it is undocumented.


That said, I think Ansgar has some really valid points.  I think that
dgit (or git-dpm) are the hardest work flows to teach.
One of my coworkers in a debian developer.
I could teach him dgit (although I think he already knows it
reasonably).

I would not expect to succeed at teaching dgit or debrebase to the other
two engineers at my company, although I'm kind of tempted to try as a
discussion point.

I was going to argue that I thought teaching gbp pq was easier than
dgit, and that's true up until you have to update a patch.

I do think I could teach the other engineers separate debian repository.
That's certainly true assuming that upstream doesn't need to be changed.
I think that so long as I said redo your patches from scratch every new
upstream release I could even teach separate debian repositories.

By teach dgit I mean teach dgit well enough to add an upstream patch,
and migrate that across to upstream releases as they change.

I think that patches applied git workflows have a lot to add.  I know I
don't want separate debian repositories as my preferred workflow.  But I
do think there really is a lot of complexity here, and I think that it
is a lot easier to get someone started with some of the simpler
workflows.

That said, I also hear your argument that for downstreams who are
want to just add a patch or two (and throw it all away and start over
when they take a new upstream), patches applied workflows are easier.

Re: Preferred git branch structure when upstream moves from tarballs to git

[Ian Campbell]

On Tue, 2019-05-07 at 11:01 -0400, Sam Hartman wrote:
> That said, I think Ansgar has some really valid points.  I think that
> dgit (or git-dpm) are the hardest work flows to teach.

I think perhaps you meant `git-debrebase` rather than `dgit` throughout
the remainder of your mail, since comparing `dgit` and `git-dpm` is
(AFAIUI) a type error of sorts since they are not serving the same
purpose -- `dgit` replaces `dput` not your patch managment system so
comparing it to `git-dpm`, a patch management system, is somewhat
apples to oranges.

Ian.

Re: Preferred git branch structure when upstream moves from tarballs to git

[Ansgar]

On Tue, 2019-05-07 at 12:51 +0100, Ian Jackson wrote:
> Ansgar Burchardt writes ("Re: Preferred git branch structure when
> upstream moves from tarballs to git"):
> > Sam Hartman  writes:
> > > OK, I didn't hear that as an answer but think I'm coming to the
> > > same
> > > conclusion that Ian did after reading your mail.
> > > It sounds like you are talking about having the Debian packaging
> > > in a
> > > separate repository from upstream.
> > > Do I correctly understand the model you are talking about?
> ...
> > I'll point to [1] for what complexity this avoids.  Try explaining
> > that
> > to someone without advanced Git knowledge...
> > 
> >   [1] 
> > https://manpages.debian.org/unstable/git-debrebase/git-debrebase.5.en.html
[...]

> In this message you are using the fact that I have written a
> comprehensive data model specification, against me.  This is a
> seriously bad thing to do.
> 

I think you underestimate how much knowledge you require from users
right from the beginning...

So in a way the problem is that the documentation needs to exist.  git-
debrebase or dgit (to a lesser extend) implement a Debian-specific
version control system on top of Git.  git-debrebase makes this most
obvious: the Git history it generates is pretty much unlike anything
you would ever get from regular Git usage (counterexamples welcome), it
mangles your Git commits into a specific format it expects
(laundering), mangles rebased branches into fast-forward merges with
pseudomerges; all this does not happen in regular Git usage.

dgit has less of these problems, but still does things different from
regular git usage (again pseudomerges to make rebases fast-forward for
example); there are other issues as well such as its suggested use for
NMUs feeling rather unfriendly as it moves the packaging to another VCS
than the maintainer uses with a disjoint history...

Sure, dealing with patch series is not nice either way, but I don't
think the added complexity of git-debrebase (or dgit) is worth what it
provides.  Alternatives require less intimiate knowledge of git and
provide a gentler learning curve; some basic patch queue manipulation
even doesn't require special tools at all (adding/removing patches that
already exist in the right format and apply).

Other distributions have intentionally be trying to move to less
distro-specific tools to reduce barrier of entry; dgit and git-
debrebase both move in the opposite direction (more highly distro-
specific tools).

> You should be applauding me for providing serious documentation for
> advanced users.

According to git-debrebase(1) the documentation I referred to is basic
documentation:

> You should read this manpage in cojnunction with "TERMINOLOGY" in 
> git-debrebase(5), which defines many important terms used here.

"TERMINOLOGY" then refers to most other sections.

> The obvious counter is the (still comprehensive, but user-facing)
> tutorial manpage.  For example,
>   
> https://manpages.debian.org/stretch-backports/dgit/dgit-maint-debrebase.7.en.html#EDITING_THE_DEBIAN_PACKAGING
> et seq.

It illustrates my other main gripe with dgit/git-debrebase: it makes it
harder to share in-progress work, in fact git-debrebase discourages
people from doing so:

| Note that each time you conclude a debrebase you introduce a
| pseudomerge into your git history, which may make it harder to read.

| A simple convention you can use to minimise the number of
| pseudomerges is to git debrebase conclude only right before you
| upload or push to salsa.debian.org. 

Yes, one can avoid some of the problems by pushing a non-fast-forward,
non-interchange branch.  But that differs from the regular workflow
and, again, requires more advanced Git knowledge.

> An equivalently detailed and frank document about dpkg-source would
> be a nightmare.

The concept behind 3.0 (quilt) is much easier to explain: extract
tarballs, optionally apply some patches provided.  With the bonus that
users who have used other distributions before might already know about
most of this which lowers barrier of entry.  Implementation details
like constructing a .dsc are indeed messy.

With most other Debian packaging workflows one can also limit oneself
to more basic Git commands for regular usage, in the most minimalistic
case only commit/push/pull (not even merge); these also match what
users will know if they have used Git at all (be it for packaging in
other distribution, upstream projects, or even just writing their
thesis).

You might say that git-debrebase is not required, but what about users
that want to contribute to a package maintained using it?  They will
have to deal with the complexity...  This also differs from other
packaging workflows that usually don't make specific tools mandatory.

(Not all tools can always be made optional of course, but one should do
some consideration if one makes new tools mandatory.)

Ansgar

Re: Preferred git branch structure when upstream moves from tarballs to git

[Sam Hartman]

> "Ian" == Ian Campbell  writes:

Ian> On Tue, 2019-05-07 at 11:01 -0400, Sam Hartman wrote:
>> That said, I think Ansgar has some really valid points.  I think
>> that dgit (or git-dpm) are the hardest work flows to teach.

Ian> I think perhaps you meant `git-debrebase` rather than `dgit`
Ian> throughout the remainder of your mail, since comparing `dgit`
Ian> and `git-dpm` is (AFAIUI) a type error of sorts since they are
Ian> not serving the same purpose -- `dgit` replaces `dput` not your
Ian> patch managment system so comparing it to `git-dpm`, a patch
Ian> management system, is somewhat apples to oranges.

I'm aware I'm making a typing error, and speaking in generalities.  I
agree that my statement is true for debrebase, but I meant the dgit
ecosystem.

git-dpm is harder than debrebase because it is less polished and
involves more explicit branches in some ways.
Dgit is harder overall even if you ignore debrebase because it has a lot
of moving parts that in my experience sometimes fail and because dgit
wants to get involved in your build process, wants to be aware of your
patch management, etc.

Dgit and debrebase are not really separate in terms of teaching.
If you look at the documentation for debrebase, you'll find that there
are a lot of cross references from debrebase docs to dgit.
For example if you want to  talk about handling new upstreams  or orig
tarballs with debrebase you need to talk about something else--either
from the dgit ecosystem or the gbp ecosystem or something.

Please understand I think dgit and debrebase are great technologies.
I'm moving towards using them more and more, and when I'm acting as a
downstream rather than a Debian developer, dgit clone is the best thing
since sliced bread.  Since I've mostly stopped eating bread perhaps I
should come up with a new metaphor, but it's really neat regardless of
what metaphor I use.

Still, this stuff is hard.

Re: Preferred git branch structure when upstream moves from tarballs to git

[Ian Jackson]

Sam Hartman writes ("Re: Preferred git branch structure when upstream moves 
from tarballs to git"):
> I was going to argue that I thought teaching gbp pq was easier than
> dgit, and that's true up until you have to update a patch.

I'm sorry not to really deal with your whole mail, but this (and a few
more statements like it in your email) is a category error.

dgit is not an alternative to gbp pq.  dgit is (amongst other things)
a tool a maintainer can use *together with* gbp pq, to publish their
git history.

A maintainer who is currently using gbp pq can (and IMO generally
should) use `dgit push' to do their uploads, rather than dput/dupload.

Ansgar was pointing to the git-debrebase manpage.  git-debrebase *is*
an alternative to gbp pq.  Both git-debrebase and gbp pq are
alternatives to git-dpm and to use of raw quilt.


Block diagrams:

For the maintainer:

  gbp pq  |  git-debrebase  |  git-dpm  |  quilt  | ...
   -
 dgit push[-source] |   dupload / dput  

   Maintainer must choose one from top row ("git workflow"), and
   then one from the bottom row ("upload/publication tool").
   Most but not yet quite all gitish workflows are supported by
   dgit push.

What I am primarily advocating for in this thread is that maintainers
should choose `dgit push-source' over `dput' (where this is possible).
This is the only way for a maintainer to provide users with the git
history in a sensible form (ie, a form which does not require the user
to know what special git practices the maintainer has adopted).


For the user/downstream:

   git   ||   git + quilt, gbp, ???   ||  dpkg-source
 ||(depends on package)   ||   quilt
   --||---||--
   dgit clone||git clone salsa||  apt-get
/fetch   ||aka debcheckout||source

   User must choose one stack.


For the NMUer:

   git   ||   git + quilt, gbp, ???   ||  dpkg-source
 ||(depends on package)   ||   quilt
   --||---||
   dgit clone||   debcheckout ||  apt-get source
   ---||
   dgit push |dput / dupload  ||  dput

   NMUer must choose a stack, although if they use a gitish
   workflow they can mix-and-match upload tools.


Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

RE:Preferred git branch structure when upstream moves from tarballs to git

[PICCA Frederic-Emmanuel]

Hello,

I am also the upstream of a bunch of project.
what is the right way to use dgit  when upstream contain the debian directory.

source format etc...

thanks

Frederic

Re: Preferred git branch structure when upstream moves from tarballs to git

[Sune Vuorela]

On 2019-05-07, Ansgar  wrote:
> The concept behind 3.0 (quilt) is much easier to explain: extract
> tarballs, optionally apply some patches provided.  With the bonus that
> users who have used other distributions before might already know about
> most of this which lowers barrier of entry.  Implementation details
> like constructing a .dsc are indeed messy.

I currently work with some yocto guys trying to get some of their
recipes adapted to better multilib support. I've been pointing to
debian/rules and debian/patches/* as places to find inspiration for
"weird things". The fact that the packages in question have been in 3.0
(quilt) with either a only-debian repository or full upstream source
have been very easy to glance over.

So from an external-ish PoV, current state of things is very nice. 

But of course, it is not our primary customers. But probably our
secondary ones.

/Sune

Re: Preferred git branch structure when upstream moves from tarballs to git

[Ian Jackson]

Sam Hartman writes ("Re: Preferred git branch structure when upstream moves 
from tarballs to git"):
> I'm aware I'm making a typing error, and speaking in generalities.  I
> agree that my statement is true for debrebase, but I meant the dgit
> ecosystem.

I don't think this "the dgit ecosystem" is a helpful framing.  It is
very misleading, not to say entirely false.  Ecosystems are about
interactions, notably synergies.  dgit synergises about as well with
git-dpm or gbp pq or indeed raw git as it does with git-debrebase.

So "git-debrebase" is not part of "the dgit ecosystem".  "The dgit
ecosystem" is primarily git, gbp pq, and git-dpm.  git-debrebase is a
minority interest for dgit (because many people use gbp pq and few
people use git-debrebase).

 dgit   git-debrebase

Direct   dput, dupload, gbp pq, git-dpm
Competitors  apt-get source git-merge

Works well   gbp pq, git-dpm,   git
with git-merge, git

Who should   Everyone who can   Brave people
use it, for  who like it
which packages   Hopefully, Packages with
  all packages   nontrivial delta

Adoption FUDMaintainer needs
barriers Bugs in .dsc tools  to completely
 Maintainer selfishness   change workflow

Primary  Users and  Maintainers
beneficiaries downstreamswithin Debian
of adoption   outside Debian

Opinionated  To the most minimalCompletely
  extent possible

Maturity Very matureQuite new

Ethics ofUse of "dgit push" Few ethical
adoption  is IMO an ethical  implications
   imperative

Team adoptionEach individualWhole team
 decision uploader can adopt must agree
   dgit push, or not

Repository   No change needed,  Must convert branch
 conversion   use existing masterfrom previous tool

Future,  Obsolete when  Rather better
after source  source packagesif no source
packages  go awaypackages needed


Lumping these two things together with some kind of "ecosystem" label,
does more to obscure than it does to illuminate.

Basically the only things they have in common are:
  * They are to do with git and Debian source code
  * I wrote them
  * The tutorials for git-debrebase say to use dgit

The latter point is because using dgit push is an ethical imperative,
not because the two somehow have some deep technical linkage.  IMO
almost *any* tutorial being written now about how to do Debian
packaging, and which mentions git at all, ought to say to use dgit.


> Dgit and debrebase are not really separate in terms of teaching.
> If you look at the documentation for debrebase, you'll find that there
> are a lot of cross references from debrebase docs to dgit.

dgit and gbp pq are not separate in terms of teaching either!

There are just as many cross-references from dgit-maint-gbp(7) to dgit
documentation as there are from dgit-maint-debrebase(7).


> Dgit is harder overall even if you ignore debrebase because it has a lot
> of moving parts that in my experience sometimes fail and because dgit
> wants to get involved in your build process, wants to be aware of your
> patch management, etc.

When dgit fails it is, almost always, because the "source code" you
are uploading to the Debian archive is not the same as what you are
actually working with as the source code in your own workflow.

Other tools don't notice this (or even have special code to achieve
it!)  IMO this is a violation of our principles which you should be
concerned to fix and which you should applaud a tool for spotting.

The only reason dgit needs to get involved in your build process is
because of the .gitignore bug.  (#908747)

> git-dpm is harder than debrebase because it is less polished and
> involves more explicit branches in some ways.

I have little interest in advocating git-debrebase.  Obviously I think
it's great, and I may advocate its use in a team I'm in, but if other
people disagree then fine.

> Please understand I think dgit and debrebase are great technologies.
> I'm moving towards using them more and more, and when I'm acting as a
> downstream rather than a Debian developer, dgit clone is the best thing
> since sliced bread.

Thanks for the compliment.

But, you will have noticed that dgit clone sometimes doesn't give you
a good history.  That happens when the maintainer uses dput or dupload
instead of dgit push.

That is why I am engaging in this thread.  I want to see `dgit clone'
produce the best answer much more of the time.  That means maintainers
need to use `dgit push'.


>  Since I've mostly stopped eating bread perhaps I
> should come

Bug#928621: ITP: xfce4-taskbar-plugin -- Windows 7 Taskbar Mimic for XFCE

[Null Nullington]

Package: wnpp
Severity: wishlist
Owner: Null Nullington 

* Package name: xfce4-taskbar-plugin
  Version : 1.0
  Upstream Author : Nick Schermer 
* URL : https://git.xfce.org/archive/xfce4-taskbar-plugin
* License : GPL2
  Programming Lang: C
  Description : Windows 7 Taskbar Mimic for XFCE

xfce4-taskbar-plugin is a Windows 7 like taskbar for the XFCE desktop
environment. It has the same functionality as the window list, which is
built in to the xfce4-panel, with the added functionality to pin
applications. These pinned applications behave like launchers, allowing
you to launch new instances of the application.

There is xfce4-dockbarx-plugin, which is not packaged for debian, but it
doesn't integrate well with GTK themes. So the Taskbar Plugin is better.

I do need a sponsor. I plan on porting it to other architectures, but as
of now, I only have access to an amd64 machine. I may have others help
out as well, as I am not that good at C, so I won't be able to fix bugs
myself. I have already built the package, both binary and source. All I
need is someone to add it to the archive.

Re: Preferred git branch structure when upstream moves from tarballs to git

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

Ian> Sam Hartman writes ("Re: Preferred git branch structure when
Ian> upstream moves from tarballs to git"):
>> I'm aware I'm making a typing error, and speaking in
>> generalities.  I agree that my statement is true for debrebase,
>> but I meant the dgit ecosystem.

Thanks so much for both this  mail and your previous one.
As an aside, frustration is part of the game.
What I'm happy about is that we're working to respect each other and
that we're reaching understanding.
I expect to be frustrated; it's part of life and being passionate about
what we do.
I'm happy when people work with me as you're doing and we get past that.
Thank you very much for working with me.


Ian> The latter point is because using dgit push is an ethical
Ian> imperative, not because the two somehow have some deep
Ian> technical linkage.  IMO almost *any* tutorial being written now
Ian> about how to do Debian packaging, and which mentions git at
Ian> all, ought to say to use dgit.

I think this is at the crux of our disagreement.
I'm going to need to think about this for myself.
I think it's safe to say there is not a project consensus that dgit is
an ethical imperative.
And yes understanding that you believe that's the case makes it a lot
easier to understand the rest of your mail.

As I said I'll need to think about whether I agree with that.  A lot of
my thinking in this discussion is that I consider dgit a nice to have,
not a requirement.


>> Dgit and debrebase are not really separate in terms of teaching.
>> If you look at the documentation for debrebase, you'll find that
>> there are a lot of cross references from debrebase docs to dgit.

Ian> dgit and gbp pq are not separate in terms of teaching either!

If you accept the premis that everyone should be using dgit, I agree
with you.
I don't think the gbp documentation has adopted that premis.

>> Dgit is harder overall even if you ignore debrebase because it
>> has a lot of moving parts that in my experience sometimes fail
>> and because dgit wants to get involved in your build process,
>> wants to be aware of your patch management, etc.

Ian> When dgit fails it is, almost always, because the "source code"
Ian> you are uploading to the Debian archive is not the same as what
Ian> you are actually working with as the source code in your own
Ian> workflow.

For me I'm finding I need to include or not include some overwrites, or
running into trouble with keys or random stuff like that.
I find it takes me two or three attempted pushes to get it right and
about half the time dgit's right that I should adjust something and half
the time I'm fairly sure I disagree with it.
And yeah, I should file bugs, and I have sometimes, and will file more
in the future.

Ian> The only reason dgit needs to get involved in your build
Ian> process is because of the .gitignore bug.  (#908747)

Well, and dgit wants to construct my dsc, which means it wants to
construct my changes, which... means it wants to call sbuild or
something else for me.


Anyway, thanks; I think your message clarified where I need to think
more.

Re: Looking for a technical writer to update the Debian Handbook

[Kashif Shah]

Hi All,

I could also proofread or edit. Regular user and sometimes admin on my
internal network of Debian boxes I use for projects / dev work.

Best regards,
Kashif.

On Fri, May 3, 2019 at 4:54 PM Andrew M.A. Cater 
wrote:

> On 03/05/2019 12:25, Iván Alemán wrote:
> > Hello Raphael,
> >
> > I can help with some chapters if you don't find the technical writer.
> >
> > Will contact you directly.
> >
> > Best,
> >
> > On Fri, 3 May 2019 at 12:25, Raphael Hertzog  > > wrote:
> >
> > Hello,
> >
> > Roland and I, the authors of the Debian Administrator's Handbook
> > (package
> > debian-handbook), we have not managed to update the book for Debian
> > 9 and
> > I don't want this to happen again for Debian 10 buster.
> >
> > I'm thus looking for a technical writer that would be willing to
> update
> > the book for Debian 10. This work would be paid by Freexian thanks to
> > the donation that we are collecting on
> https://debian-handbook.info/get/
> > (and thanks to the sales on lulu.com ).
> >
> > The ideal candidate would be someone who:
> > - loves the Debian OS and knows the ecosystem very well
> > - has experience with system administration of Debian servers
> >   (the book covers many common services)
> > - has good English writing skills
> > - is not afraid to edit Docbook XML in a text editor
> > - can emit invoices to Freexian for the work done
> > - can commit enough time to the task in the upcoming months
> >   (trying to get the book entirely updated for the buster release)
> >
> > If you want to have a look at the project, it's hosted on salsa:
> > https://salsa.debian.org/hertzog/debian-handbook
> >
> > If you are interested, please get back to me and we can discuss this
> > in more details.
> >
> > If you don't have enough time to update the entire book, but would be
> > willing to update some chapters, please get in touch anyway, we
> might be
> > able to share the work between multiple persons.
> >
> > Cheers,
> > --
> > Raphaël Hertzog ◈ Debian Developer
> >
> > Support Debian LTS:
> https://www.freexian.com/services/debian-lts.html
> > Learn to master Debian: https://debian-handbook.info/get/
> >
> >
> >
> > --
> > Iván
> > @alemani
>
> Not much time - use and love Debian, am system administrator. Can proof
> read if this helps. Would do this for no salary.
>
> Andy C
>
>

Re: Preferred git branch structure when upstream moves from tarballs to git

[Scott Kitterman]

On May 7, 2019 8:50:57 PM UTC, Sam Hartman  wrote:
>> "Ian" == Ian Jackson  writes:
>
>Ian> Sam Hartman writes ("Re: Preferred git branch structure when
>Ian> upstream moves from tarballs to git"):
>>> I'm aware I'm making a typing error, and speaking in
>>> generalities.  I agree that my statement is true for debrebase,
>>> but I meant the dgit ecosystem.
>
>Thanks so much for both this  mail and your previous one.
>As an aside, frustration is part of the game.
>What I'm happy about is that we're working to respect each other and
>that we're reaching understanding.
>I expect to be frustrated; it's part of life and being passionate about
>what we do.
>I'm happy when people work with me as you're doing and we get past
>that.
>Thank you very much for working with me.
>
>
>Ian> The latter point is because using dgit push is an ethical
>Ian> imperative, not because the two somehow have some deep
>   Ian> technical linkage.  IMO almost *any* tutorial being written now
>Ian> about how to do Debian packaging, and which mentions git at
>Ian> all, ought to say to use dgit.
>
>I think this is at the crux of our disagreement.
>I'm going to need to think about this for myself.
>I think it's safe to say there is not a project consensus that dgit is
>an ethical imperative.
>And yes understanding that you believe that's the case makes it a lot
>easier to understand the rest of your mail.
>
>As I said I'll need to think about whether I agree with that.  A lot of
>my thinking in this discussion is that I consider dgit a nice to have,
>not a requirement.

For what it's worth, when you start calling me names (unethical) because I'm 
not using your shiny new toy, my immediate reaction is to decide to ignore 
further discussion on the topic.

Scott K

Bug#928632: ITP: libdevel-findperl-perl -- Perl module to find the path to the currently running perl

[Joenio Costa]

Package: wnpp
Severity: wishlist
Owner: Joenio Costa 

* Package name: libdevel-findperl-perl
  Version : 0.015
  Upstream Author : Leon Timmermans , Randy Sims 

* URL : https://metacpan.org/release/Devel-FindPerl
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module to find the path to the currently running perl

The Devel::FindPerl module tries to find the path to the currently running
perl. It implements a function to try (really really hard) to find the path to
the perl running your program and another function to test if the perl in
`$path` is the same perl as the currently running one.

SECURITY ALERT: This module by default does things that are not particularly
secure (run programs based on external input).

Re: Handling Japanese new era "令和 (Reiwa)"

[NOKUBI Takatsugu]

On Tue, 07 May 2019 03:45:33 +0900,
Hideki Yamane wrote:
>  * IME (Input Method Editor)
>- anthy: not yet

done.

>  * "Natural language processing" Japanese dictionaries
>- mecab-ipadic: not yet

done.

unidic is still active maintained dictionary by upstream, but there
are no new release.