from:"Daichi Fukui"

Bug#1005326: no-code-sections triggered on non-ELF files

2024-03-01 Thread Daichi Fukui

Hi

On Tue, 01 Nov 2022 18:43:31 -0400 Daniel Kahn Gillmor  wrote:
> This error is also mistakenly produced for libassuan-mingw-w64-dev (used
> for cross-building gpgv.exe as part of a windows installer signature
> verification tool):

Lintian also potentially produces the no-code-sections report for wasi-libc.
However, the report is currently not visible as lintian-overrides is in place:
https://sources.debian.org/src/wasi-libc/0.0~git20230113.4362b18-3/debian/wasi-libc.lintian-overrides/

It looks like we need some modification to the following code so we
can analyse non-ELF files using Lintian, but I have no clue how to
address it at the moment.
https://salsa.debian.org/lintian/lintian/-/blob/98e5ebd3f120e6200d293b81de8a49f33edef5c4/lib/Lintian/Check/Libraries/Static/NoCode.pm#L67-80

Best,
Fukui

Bug#1052015: RFS: blktrace/1.3.0-1 -- utilities for block layer IO tracing

2024-07-21 Thread Daichi Fukui

Hi Daniel,

Thank you for the guide.
It's been weeks since we talked with each other in the last month.

I now understand that there are some ways for the maintenance.
I will consider which maintenance approach to choose.

> Do you have any preference among the git workflows in Debian? .. yet ;-)
I agree with you.
The "only debian/ dir in git" approach for this package should be replaced.

>Hold off on uploading a new package to mentors with the metadata changes, I
>don't have the focus right now but I'm sure to have more review comments
>once I get around to it ;)
Thank you for taking time to review this draft package.
I'd appreciate it if you have some further comments and share them with me.

Best,
Fukui

On Sat, 29 Jun 2024 at 01:39, Daniel Gröber  wrote:
>
> Hi Daichi,
>
> On Sun, Jun 16, 2024 at 04:08:26PM +0900, Daichi Fukui wrote:
> > > Daichi, I'd be happy to sponsor this upload in principle (once it passes
> > > review) but only if you're interested in taking care of blktrace going
> > > forward.
> >
> > Yes, I'm interested in taking care of blktrace and have a plan to address
> > a different issue, that is #1069862.  I appreciate it if you could
> > sponsor this upload.
> >
> > > Firstly, apologies Daichi, if you wish adopt this package and maintain
> > > it moving forward, like Daniel, I would be happy to assist and support
> > > you as needed if requested.
> >
> > Yes, I would like to adopt the blktrace package and hopefully get
> > assistance for that if you don't mind.
>
> Alright. If you want to adopt it we should fixup the maintainer/uploader
> metadata. Since bas agreed to the takeover you can just go ahead and
> implement it yourself in d/control. Whether to leave Dmitry in Uploaders
> (which would represent co-maintanance) is your call as maintainer now.
>
> Overall you can basically choose one of the following maintanance
> approaches:
>
>   1) Be responsible for dealing with everything yourself. You are in
>  Maintainers and there's no Uploaders,
>   2) Have a select set of people (maint+uploaders) be collectively
>  responsible or
>   3) Collaborative maintainance across all of Debian. i.e. anyone can
>  upload (we call this NMU) at will. You'd add yourself to the
>  [LowThresholdNmu] list in that case
>
> [LowThresholdNmu]: https://wiki.debian.org/LowThresholdNmu
>
> Currently blktrace is packaged in git using the "only debian/ dir in git"
> approach https://salsa.debian.org/debian/blktrace. Personally I don't like
> that workflow and would strongly prefer switching to something else as it
> also impacts my sponsorship/review work. Do you have any preference among
> the git workflows in Debian? .. yet ;-)
>
> > In addition, I've updated the draft package as follows, following your
> > review for improvement.
>
> Hold off on uploading a new package to mentors with the metadata changes, I
> don't have the focus right now but I'm sure to have more review comments
> once I get around to it ;)
>
> Feel free to poke and prod if I don't get my keyboard in gear.
>
> --Daniel

Bug#1058016: RFS: wasix-libc/0.0~git20230922.d0362cb-1 [ITP] -- wasix libc implementation for WebAssembly

2024-07-27 Thread Daichi Fukui

Hi Andrey, Iwamatsu-san,
CC: Phil,

It's been a while since I posted the draft package some weeks ago.
I'd appreciate it if you sponsor this and help me upload it.

> Phil
Besides, I also appreciate Phil for his review work.
I hope the draft package will be satisfactory and ready to be uploaded.

Best,
Fukui

On Fri, 28 Jun 2024 at 09:36, Daichi Fukui
 wrote:
>
> Control: tags 1058016 - moreinfo
>
> Hi Andrey,
>
> Thank you for the comments.
>
> Though it took some time since your reply, I've updated the draft
> package following the comments.
> You can download the latest draft package with 'dget' using this command:
> dget -x 
> https://mentors.debian.net/debian/pool/main/w/wasix-libc/wasix-libc_2024-06-26.1+ds-1.dsc
>
> To access further information about this package, please visit the
> following URL:
> https://mentors.debian.net/package/wasix-libc/
>
> With regard to the comments,
>
> > - It should have only one changelog entry.
> Now there is only one changelog entry.
>
> > - Pre-built libclang_rt.builtins-wasm32.a should be removed from the
> >  orig.tar, assuming it's not used in the build process.
> The pre-build archive file is now removed from the orig.tar.
> It is actually used while Makefile is processing
> tools/append-builtins/wasm32-wasi.mri, but the archive file should be
> removed according to the Debian Policy.
> Following that change, the .mri file now refers to the
> libclang_rt.builtins-wasm32.a archive provided by the
> libclang-rt-16-dev-wasm32 package.
>
> >- debian/rules hardcodes llvm-*-16 and clang-16 but B-D are llvm and
> >  clang, those should use versioned names too.
> Now B-D uses versioned ones.
>
> >- You should follow the comments in debian/rules and debian/watch.
> Following the comments, unused lines are removed.
>
> >- An explicit build target looks unnecessary.
> The following explicit build process is now removed.
> --- a/debian/rules
> +++ b/debian/rules
> @@ -14,10 +9,6 @@ export TARGET_ARCH = wasm32
>  %:
> dh $@
>
> -.PHONY: build
> -build:
> -   dh $@
> -
>  override_dh_auto_build:
> dh_auto_build -- finish
>
> Meanwhile, I found an issue that most of the files from the wasix-libc
> package are duplicating the files from the wasi-libc package[0].
> This is considered an error of our wasix-libc draft package if we do
> not take measures.
> One possible solution is to add the Conflicts field to d/control and
> set wasi-libc to it.
> I hope this change is satisfactory and useful.
>
> [0] https://packages.debian.org/sid/all/wasi-libc/filelist
>
> Fukui

Bug#1058016: RFS: wasix-libc/0.0~git20230922.d0362cb-1 [ITP] -- wasix libc implementation for WebAssembly

2024-08-03 Thread Daichi Fukui

Hi Phil, Jeremy,

>These things can take time though, so please be patient.
I agree with you. I'll wait for DDs to pick up this package.

>BTW what's the difference with wasi-libc package ?
While WASI-libc provides the basic POSIX-compatible C APIs for
WebAssembly, WASIX-libc extends these capabilities with additional
features to support more complex and complete applications.
For example, WASI-libc provides support for standard I/O, file I/O,
filesystem manipulation, memory management, time, string, environment
variables, program startup.
In addition to that, WASIX-libc also includes full support for
efficient multithreading, sockets, current directory support, process
forking, subprocess spawning and waiting, TTY support, asynchronous
polling of sockets and files, pipe and event support, and DNS
resolution.
If you are interested in more details, I'd recommend looking at the
defined symbols of WASIX-libc[0] and WASI-libc[1] and then comparing
them with each other.

[0] 
https://github.com/wasix-org/wasix-libc/blob/main/expected/wasm32-wasi/defined-symbols.txt
[1] 
https://github.com/WebAssembly/wasi-libc/blob/main/expected/wasm32-wasip1/defined-symbols.txt

Best regards,
Fukui

Bug#1052015: RFS: blktrace/1.3.0-1 -- utilities for block layer IO tracing

2024-08-03 Thread Daichi Fukui

Hi Phil,

>Have we decided how this package will be moving forward?
Partly yes.
I'm going to take the following approach out of the three approaches
Daniel introduced in the previous email.
 2) Have a select set of people (maint+uploaders) be collectively
 responsible or
Since Dmitry has already been an uploader, I'll follow this tradition
so that Bas will be another uploader for this package.

That said, I'm holding off on uploading a new package with the
metadata changes because I'm waiting for Daniel (and other DDs) to
have some time for reviewing this package and sharing feedback with
us.

Best,
Fukui

Bug#1072719: RFS: blktrace/1.3.0-0.1 [NMU] -- utilities for block layer IO tracing

2024-06-06 Thread Daichi Fukui

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my NMU package "blktrace":

 * Package name : blktrace
   Version  : 1.3.0-0.1
   Upstream contact : Jens Axboe 
 * URL  :
https://git.kernel.org/pub/scm/linux/kernel/git/axboe/blktrace.git/about/
 * License  : GPL, public-domain, GPL-2+, GPL-2
 * Vcs  : https://salsa.debian.org/debian/blktrace
   Section  : utils

The source builds the following binary packages:

  blktrace - utilities for block layer IO tracing

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/blktrace/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/b/blktrace/blktrace_1.3.0-0.1.dsc

Changes since the last upload:

 blktrace (1.3.0-0.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
 .
   [ Debian Janitor ]
   * Trim trailing whitespace.
   * Remove 1 obsolete maintscript entry.
   * Bump debhelper from old 11 to 13.
   * Set debhelper-compat version in Build-Depends.
   * Fix day-of-week for changelog entry 0~git-20061221162513-1.
   * Update standards version to 4.6.0, no changes needed.
   * Avoid explicitly specifying -Wl,--as-needed linker flag.
 .
   [ Fukui Daichi ]
   * New upstream version 1.3.0
   * Remove and fix patches to catch up with 1.3.0
   * Update d/copyright

Regards,

Bug#1052015: RFS: blktrace/1.3.0-1 -- utilities for block layer IO tracing

2024-06-16 Thread Daichi Fukui

Hi Phil, Daniel, Bas, and Tobias

Thank you for taking time for this discussion and your advice for improvement.

Daniel,
> Daichi, I'd be happy to sponsor this upload in principle (once it passes
> review) but only if you're interested in taking care of blktrace going
> forward.
Yes, I'm interested in taking care of blktrace and have a plan to
address a different issue, that is #1069862.
I appreciate it if you could sponsor this upload.

Phil,
> Firstly, apologies Daichi, if you wish adopt this package and maintain it 
> moving
> forward, like Daniel, I would be happy to assist and support you as needed if
> requested.
Yes, I would like to adopt the blktrace package and hopefully get
assistance for that if you don't mind.
In addition, I've updated the draft package as follows, following your
review for improvement.
For further details, please visit the following URL:
https://mentors.debian.net/package/blktrace/
Alternatively, you can also download the package with 'dget' like:
dget -x 
https://mentors.debian.net/debian/pool/main/b/blktrace/blktrace_1.3.0-0.1.dsc

> - Edit line '* Update standards version to 4.6.0, no changes needed.' and 
> change
> to '4.7.0' to match 'debian/control'.
I've added '* Update standards version to 4.7.0, no changes needed.'
to my section of the changelog.

> - Edit line '* New upstream version 1.3.0' and now close bug #1073161 that I
> filed asking for the update to version 1.3.0.
"(Closes: #1073161)" is now added to the changelog.

> - Maybe be more verbose on what was updated in 'debian/copyright'.
d/copyright was updated to show more precise copyright information, so
I'ved added that description to the changelog.

Hope this update is satisfactory and you, Daniel, or other developers
help me upload and update this package.

Daichi Fukui

On Sat, 15 Jun 2024 at 11:41, Phil Wyett  wrote:
>
> Hi all,
>
> I will do a short review in hope Daichi still has interest in the package.
>
> * Package build: Good.
> * Lintian: Good.
> * Install: Good.
> * Licenses:
>
> philwyett@ks-windu:~/Development/builder/debian/mentoring/blktrace-1.3.0$ lrc
> en: Versions: recon 1.10.1  check 3.3.9-1
>
> Parsing Source Tree  
> Reading copyright
> Running licensecheck 
>
> d/copyright | licensecheck
>
> GPL-2+  | GPL  btrace.spec
>
> Nothing to really worry about here. For exactness it could be added to
> 'debian/copyright' at a later date, but lets not be picky. :-)
>
> * Debian files:
>
> 'debian/changelog':
>
> - Edit line '* Update standards version to 4.6.0, no changes needed.' and 
> change
> to '4.7.0' to match 'debian/control'.
>
> - Edit line '* New upstream version 1.3.0' and now close bug #1073161 that I
> filed asking for the update to version 1.3.0.
>
> - Maybe be more verbose on what was updated in 'debian/copyright'.
>
> Regards
>
> Phil
>
> --
>
> Website: https://kathenas.org
>
> Instagram: https://instagram.com/kathenasorg/
>
> Buy Me A Coffee: https://buymeacoffee.com/kathenasorg

Bug#1052015: RFS: blktrace/1.3.0-1 -- utilities for block layer IO tracing

2024-06-17 Thread Daichi Fukui

Hi Phil,

> The package looks good to me and I thank you for your work and enthusiasm for
> the package.
That sounds nice. Thank you for taking your time to review it.

> Let us give it a couple of days for other input/feedback and after this give 
> to
> Daniel for sponsorship. Good with you?
Sure, I'm fine with that schedule.

Daichi Fukui

On Mon, 17 Jun 2024 at 06:29, Phil Wyett  wrote:
>
> On Sun, 2024-06-16 at 16:08 +0900, Daichi Fukui wrote:
> > Hi Phil, Daniel, Bas, and Tobias
> >
> > Thank you for taking time for this discussion and your advice for 
> > improvement.
> >
> > Daniel,
> > > Daichi, I'd be happy to sponsor this upload in principle (once it passes
> > > review) but only if you're interested in taking care of blktrace going
> > > forward.
> > Yes, I'm interested in taking care of blktrace and have a plan to
> > address a different issue, that is #1069862.
> > I appreciate it if you could sponsor this upload.
> >
> > Phil,
> > > Firstly, apologies Daichi, if you wish adopt this package and maintain it 
> > > moving
> > > forward, like Daniel, I would be happy to assist and support you as 
> > > needed if
> > > requested.
> > Yes, I would like to adopt the blktrace package and hopefully get
> > assistance for that if you don't mind.
> > In addition, I've updated the draft package as follows, following your
> > review for improvement.
> > For further details, please visit the following URL:
> > https://mentors.debian.net/package/blktrace/
> > Alternatively, you can also download the package with 'dget' like:
> > dget -x 
> > https://mentors.debian.net/debian/pool/main/b/blktrace/blktrace_1.3.0-0.1.dsc
> >
> > > - Edit line '* Update standards version to 4.6.0, no changes needed.' and 
> > > change
> > > to '4.7.0' to match 'debian/control'.
> > I've added '* Update standards version to 4.7.0, no changes needed.'
> > to my section of the changelog.
> >
> > > - Edit line '* New upstream version 1.3.0' and now close bug #1073161 
> > > that I
> > > filed asking for the update to version 1.3.0.
> > "(Closes: #1073161)" is now added to the changelog.
> >
> > > - Maybe be more verbose on what was updated in 'debian/copyright'.
> > d/copyright was updated to show more precise copyright information, so
> > I'ved added that description to the changelog.
> >
> > Hope this update is satisfactory and you, Daniel, or other developers
> > help me upload and update this package.
> >
> > Daichi Fukui
> >
> > On Sat, 15 Jun 2024 at 11:41, Phil Wyett  wrote:
> > > Hi all,
> > >
> > > I will do a short review in hope Daichi still has interest in the package.
> > >
> > > * Package build: Good.
> > > * Lintian: Good.
> > > * Install: Good.
> > > * Licenses:
> > >
> > > philwyett@ks-windu:~/Development/builder/debian/mentoring/blktrace-1.3.0$ 
> > > lrc
> > > en: Versions: recon 1.10.1  check 3.3.9-1
> > >
> > > Parsing Source Tree  
> > > Reading copyright
> > > Running licensecheck 
> > >
> > > d/copyright | licensecheck
> > >
> > > GPL-2+  | GPL  btrace.spec
> > >
> > > Nothing to really worry about here. For exactness it could be added to
> > > 'debian/copyright' at a later date, but lets not be picky. :-)
> > >
> > > * Debian files:
> > >
> > > 'debian/changelog':
> > >
> > > - Edit line '* Update standards version to 4.6.0, no changes needed.' and 
> > > change
> > > to '4.7.0' to match 'debian/control'.
> > >
> > > - Edit line '* New upstream version 1.3.0' and now close bug #1073161 
> > > that I
> > > filed asking for the update to version 1.3.0.
> > >
> > > - Maybe be more verbose on what was updated in 'debian/copyright'.
> > >
> > > Regards
> > >
> > > Phil
> > >
> > > --
> > >
> > > Website: https://kathenas.org
> > >
> > > Instagram: https://instagram.com/kathenasorg/
> > >
> > > Buy Me A Coffee: https://buymeacoffee.com/kathenasorg
>
> Hi Daichi,
>
> Sorry for the delayed response. I am a motor racing fan and the glorious 24
> hours of Le Mans has more than distracted me. :-D
>
> The package looks good to me and I thank you for your work and enthusiasm for
> the package.
>
> Let us give it a couple of days for other input/feedback and after this give 
> to
> Daniel for sponsorship. Good with you?
>
> Regards
>
> Phil
>
> --
>
> Website: https://kathenas.org
>
> Instagram: https://instagram.com/kathenasorg/
>
> Buy Me A Coffee: https://buymeacoffee.com/kathenasorg

Bug#1058016: RFS: wasix-libc/0.0~git20230922.d0362cb-1 [ITP] -- wasix libc implementation for WebAssembly

2024-06-27 Thread Daichi Fukui

Control: tags 1058016 - moreinfo

Hi Andrey,

Thank you for the comments.

Though it took some time since your reply, I've updated the draft
package following the comments.
You can download the latest draft package with 'dget' using this command:
dget -x 
https://mentors.debian.net/debian/pool/main/w/wasix-libc/wasix-libc_2024-06-26.1+ds-1.dsc

To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/wasix-libc/

With regard to the comments,

> - It should have only one changelog entry.
Now there is only one changelog entry.

> - Pre-built libclang_rt.builtins-wasm32.a should be removed from the
>  orig.tar, assuming it's not used in the build process.
The pre-build archive file is now removed from the orig.tar.
It is actually used while Makefile is processing
tools/append-builtins/wasm32-wasi.mri, but the archive file should be
removed according to the Debian Policy.
Following that change, the .mri file now refers to the
libclang_rt.builtins-wasm32.a archive provided by the
libclang-rt-16-dev-wasm32 package.

>- debian/rules hardcodes llvm-*-16 and clang-16 but B-D are llvm and
>  clang, those should use versioned names too.
Now B-D uses versioned ones.

>- You should follow the comments in debian/rules and debian/watch.
Following the comments, unused lines are removed.

>- An explicit build target looks unnecessary.
The following explicit build process is now removed.
--- a/debian/rules
+++ b/debian/rules
@@ -14,10 +9,6 @@ export TARGET_ARCH = wasm32
 %:
dh $@

-.PHONY: build
-build:
-   dh $@
-
 override_dh_auto_build:
dh_auto_build -- finish

Meanwhile, I found an issue that most of the files from the wasix-libc
package are duplicating the files from the wasi-libc package[0].
This is considered an error of our wasix-libc draft package if we do
not take measures.
One possible solution is to add the Conflicts field to d/control and
set wasi-libc to it.
I hope this change is satisfactory and useful.

[0] https://packages.debian.org/sid/all/wasi-libc/filelist

Fukui

Bug#1017088: ITP: c4core -- library of low-level C++ utilities, written with low-latency projects in mind

2022-10-31 Thread Daichi Fukui

Hi Punit-san,

Thanks for a reply.

On Tue, 25 Oct 2022 at 06:46, Punit Agrawal  wrote:

> Hi Fukui-san,
>
> Daichi Fukui  writes:
>
> > Hello Debian Developers,
> >
> > On Sat, 13 Aug 2022 13:03:16 + Fukui Daichi <
> a.dog.will.t...@akane.waseda.jp> wrote:
> >> Package: wnpp
> >> Severity: wishlist
> >> Owner: Fukui Daichi 
> >> X-Debbugs-Cc: debian-de...@lists.debian.org,
> a.dog.will.t...@akane.waseda.jp
> >>
> >> * Package name: c4core
> >>   Version : 0.1.9
> >>   Upstream Author : Joao Paulo Magalhaes 
> >> * URL : https://github.com/biojppm/c4core
> >> * License : MIT
> >>   Programming Lang: C++
> >>   Description : library of low-level C++ utilities, written with
> low-latency projects in mind
> >>
> >> Rationale:
> >>rapidyaml [0] depends on this utility.
> >>Moreover, jsonnet [1] depends on rapidyaml.
> >>
> >>[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003397
> >>[1] https://tracker.debian.org/pkg/jsonnet
> >>
> >> Maintenance plan:
> >>Because I am a novice in debian packaging, I would like to
> >>ask for someone who can review my upload. I need a sponsor too.
> >>
> >>
> >
> > As mentioned in a different bugreport [0], c4core depends on
> biojppm/cmake, debugbreak, and fast_float.
> > To meet the dependency, we're now preparing for uploading debugbreak and
> fast_float [1][2].
> >
> > As for biojppm/cmake, it looks like this software is used for the
> author's project only.
> > This makes me wonder if it is really reasonable to package biojppm/cmake.
> > It is technically possible to package it but it could end up with no
> other packages depending on the packaged biojppm/cmake than c4core.
> > To make a clear decision, I would like to ask for your opinion on this
> issue.
> >
> > If you are interested, see also a discussion [3] similar to this one.
>
> I'm not familiar with Debian convention regarding this so please take
> any comments here with a pinch of salt.
>
> Considering that you've found a precedent, you should be able to package
> biojppm/cmake together with c4core. Does upstream provide a combined
> release tarball with it included? If so, I'd suggest using that for the
> upload and look to split it out of the package if required.
>
> Hope that helps.
>
> Regards,
> Punit
>
> > [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003397#35
> > [1] https://ftp-master.debian.org/new/debugbreak_1.0-1.html
> > [2] https://ftp-master.debian.org/new/fast-float_3.5.1-1.html
> > [3] https://lists.debian.org/debian-security-tools/2020/12/msg00012.html
>
>
OK, I'll keep biojppm/cmake embedded rather than creating a new package for
it.

Yes, c4core upstream provides a tarball combined with biojppm/cmake.
With the help of DDs, I'll try to upload the source code with cmake
included in it when it's ready.

Best,
Fukui

Bug#1005092: [EXTERNAL] Re: pytest-mpl: Please update to version 0.13

2022-10-31 Thread Daichi Fukui

Hi Leo,

Thanks for your reply.

On Tue, 18 Oct 2022 13:37:12 + "Singer, Leo P. (GSFC-6610)" <
leo.p.sin...@nasa.gov> wrote:
> Hi Daichi,
>
> Yes, I can do that next week. (I am traveling and do not have my Debian
key on me.)
>
> Leo
>
> From: Daichi Fukui 
> Date: Tuesday, October 18, 2022 at 09:36
> To: "1005...@bugs.debian.org" <1005...@bugs.debian.org>
> Cc: "leo.sin...@ligo.org" 
> Subject: [EXTERNAL] Re: pytest-mpl: Please update to version 0.13
>
> Dear maintainer
> CC: Leo Singer
>
> > Dear maintainer,
> >
> > I am currently packaging cmyt [1], which is a new dependency of the "yt"
> > package. For testing, cmyt requires at least version 0.13 of pytest-mpl.
> > Could I ask to update the version in Debian to this latest version?
> >
> > Thank you very much!
> >
> > Ole
> If you don't mind, can I work on updating this package to version 0.13?
> I'd be happy if I could contribute to this one and the Astro team.
>
> FYI, I've CC'd this email to Leo because it seems Leo is the top
contributor according to d/changelog.
>
> Best,
> Fukui

It's been a while since we had a conversation some ten days ago.
I just want to let you know that I'm still working on this and need some
time to complete the package draft.
This is because pytest returns a bunch of errors with the updated source
code.
I'm now trying to address them.

Best,
Fukui

Bug#1020606:

2022-11-08 Thread Daichi Fukui

Hi all,

I've created a new version of the enet source package [0], which is going
to be 1.3.17+ds-1 with this update.
The draft source package has already been shared with the maintainers of
and a key contributor to enet as well as Debian Games Team.
However, I haven't received any response from them so far, so that I am
considering an NMU with the help of a Debian Developer.

This version introduces the following changes:
  * New upstream version 1.3.17+ds
  * debian/rules: Update version for get-orig-source target.
  * Switch to compat level 13.
  * Add Rules-Requires-Root field
  * debian/copyright: Update years of copyright and contributors
  * Add a new symbol and Build-Depends-Package field
  * 0001-ftbfs-on-hurd-i386.patch: update metadata
  * debian/rules: add hardening
  * debian/rules: do not build .a and .la files
  * Fix watch file (Thanks Reiner)
  * Bumped Standards-Version to 4.6.1

If this update is satisfactory and helpful,
I would appreciate it if you review and sponsor the package.
If there is still no response, I would take the next step for an NMU.

[0] https://salsa.debian.org/dfukui/enet

Best,
Fukui

Bug#1017088: ITP: c4core -- library of low-level C++ utilities, written with low-latency projects in mind

2022-11-10 Thread Daichi Fukui

Hi all,

On Mon, 31 Oct 2022 21:46:18 +0900 Daichi Fukui <
a.dog.will.t...@akane.waseda.jp> wrote:
> Hi Punit-san,
>
> Thanks for a reply.
>
> On Tue, 25 Oct 2022 at 06:46, Punit Agrawal 
wrote:
>
> > Hi Fukui-san,
> >
> > Daichi Fukui  writes:
> >
> > > Hello Debian Developers,
> > >
> > > On Sat, 13 Aug 2022 13:03:16 + Fukui Daichi <
> > a.dog.will.t...@akane.waseda.jp> wrote:
> > >> Package: wnpp
> > >> Severity: wishlist
> > >> Owner: Fukui Daichi 
> > >> X-Debbugs-Cc: debian-de...@lists.debian.org,
> > a.dog.will.t...@akane.waseda.jp
> > >>
> > >> * Package name: c4core
> > >>   Version : 0.1.9
> > >>   Upstream Author : Joao Paulo Magalhaes 
> > >> * URL : https://github.com/biojppm/c4core
> > >> * License : MIT
> > >>   Programming Lang: C++
> > >>   Description : library of low-level C++ utilities, written with
> > low-latency projects in mind
> > >>
> > >> Rationale:
> > >>rapidyaml [0] depends on this utility.
> > >>Moreover, jsonnet [1] depends on rapidyaml.
> > >>
> > >>[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003397
> > >>[1] https://tracker.debian.org/pkg/jsonnet
> > >>
> > >> Maintenance plan:
> > >>Because I am a novice in debian packaging, I would like to
> > >>ask for someone who can review my upload. I need a sponsor too.
> > >>
> > >>
> > >
> > > As mentioned in a different bugreport [0], c4core depends on
> > biojppm/cmake, debugbreak, and fast_float.
> > > To meet the dependency, we're now preparing for uploading debugbreak
and
> > fast_float [1][2].
> > >
> > > As for biojppm/cmake, it looks like this software is used for the
> > author's project only.
> > > This makes me wonder if it is really reasonable to package
biojppm/cmake.
> > > It is technically possible to package it but it could end up with no
> > other packages depending on the packaged biojppm/cmake than c4core.
> > > To make a clear decision, I would like to ask for your opinion on this
> > issue.
> > >
> > > If you are interested, see also a discussion [3] similar to this one.
> >
> > I'm not familiar with Debian convention regarding this so please take
> > any comments here with a pinch of salt.
> >

I've been trying to use the newly added libfast-float-dev [0] and
debugbreak [1] packages to replace some embedded header files of c4core.

While looking at libfast-float-dev, I came up with the following issue.
Let me explain what's going on.

c4core uses fast_float.hpp and fast_float_all.h many times in its source
code,
so first I tried to simply replace them with the header files which the
libfast-float-dev package provides.
Note that the fast_float.hpp is effectively a wrapper for fast_float_all.h.
However, it seems a bit difficult to use the libfast-float-dev package for
replacing fast_float.hpp and fast_float_all.h.
This is because fast_float_all.h was apparently created with
fast_float/script/amalgamate.py as a single header file,
which the libfast-float-dev package does not provide as such.

Taking the situation above into account, I would like to propose the
following options to address this issue.

Options:

(a) Use fast_float.hpp and fast_float_all.hpp, both of which are already
embedded in c4core;
we don't use libfast-float-dev for replacing them.

(b) Use the fast_float pacakge - use amalgamate.py to generate a single
header like fast_float_all.hpp,
add it to the fast_float package, then replace fast_float_all.hpp with the
one which the package provides

I would appreciate it if you help me decide which option to take or if you
share other options, if any.
What do you think?

FYI, there are no issues when it comes to using debugbreak for c4core.

[0] https://packages.debian.org/bookworm/libfast-float-dev
[1] https://packages.debian.org/bookworm/debugbreak

Best,
Fukui

Bug#1030578: RFS: fast-float/3.9.0-1 -- Implementation of the C from_chars functions for float and double types

2023-02-05 Thread Daichi Fukui

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "fast-float":

 * Package name : fast-float
   Version  : 3.9.0-1
   Upstream contact : Daniel Lemire 
 * URL  : https://github.com/fastfloat/fast_float
 * License  : Expat or Apache
   Section  : libdevel

The source builds the following binary packages:

  libfast-float-dev - Implementation of the C++ from_chars functions
for float and double types

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/fast-float/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/f/fast-float/fast-float_3.9.0-1.dsc

Changes since the last upload:

 fast-float (3.9.0-1) unstable; urgency=medium
 .
   * New upstream release 3.9.0.
   * Make fast_float_all.h available under /usr/include/fast_float/

Regards,
Fukui

Bug#1020341: RFS: fast-float/3.5.1-1 [ITP] -- Implementation of the C from_chars functions for float and double types

2022-09-20 Thread Daichi Fukui

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "fast-float":

 * Package name : fast-float
   Version  : 3.5.1-1
   Upstream contact : Daniel Lemire 
 * URL  : https://github.com/fastfloat/fast_float
 * License  : Expat or Apache
 * Vcs  : [TBD]
   Section  : devel

Rationale for this ITP:

c4core depends on fast-float [0].
rapidyaml [1] depends on c4core.
Moreover, jsonnet [2] depends on rapidyaml.

[0] https://github.com/biojppm/c4core/blob/v0.1.9/.gitmodules
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003397
[2] https://tracker.debian.org/pkg/jsonnet

See #1019961 for details:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019961

---

The source builds the following binary packages:

  fast-float - Implementation of the C++ from_chars functions for float and
double types

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/fast-float/

Alternatively, you can download the package with 'dget' using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/f/fast-float/fast-float_3.5.1-1.dsc

Changes for the initial release:

 fast-float (3.5.1-1) unstable; urgency=low
 .
   * Initial release. Closes: #1019961

Regards,

Bug#1020341: RFS: fast-float/3.5.1-1 [ITP] -- Implementation of the C from_chars functions for float and double types

2022-09-26 Thread Daichi Fukui

On Wed, 21 Sep 2022 04:04:21 +0200 Adam Borowski 
wrote:
> On Wed, Sep 21, 2022 at 12:31:11AM +0900, Daichi Fukui wrote:
> >  * Package name : fast-float
> >Version  : 3.5.1-1
> >  * URL  : https://github.com/fastfloat/fast_float
>
> >   fast-float - Implementation of the C++ from_chars functions for float
and
> > double types
>
> Hi!
> The package looks good so far, but C/C++ development header packages are
> supposed to be named libXXX-dev.  Strictly speaking, the Policy demands
> that only for headers of shared libraries, but I wouldn't go different
> for a header-only lib.
>
> Eg:
> source package: plf-colony
> binary package: libplf-colony-dev
>
> (Of course, some other sponsor may think different...)

Hi Adam,

Thanks for reviewing my draft source package.

Taking your advice into consideration, I changed the name for the binary
package, which is now called libfast-float-dev.
The README file says fast-float itself is a "library", so it would be
better to treat it as such.

Here is the latest draft (see Upload #2):
https://mentors.debian.net/package/fast-float/

If you don't mind, can you sponsor this package and help me upload it to
the archive?

Best regards,
Fukui

Bug#1017088: ITP: c4core -- library of low-level C++ utilities, written with low-latency projects in mind

2022-09-29 Thread Daichi Fukui

Hello Debian Developers,

On Sat, 13 Aug 2022 13:03:16 + Fukui Daichi <
a.dog.will.t...@akane.waseda.jp> wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Fukui Daichi 
> X-Debbugs-Cc: debian-de...@lists.debian.org,
a.dog.will.t...@akane.waseda.jp
>
> * Package name: c4core
>   Version : 0.1.9
>   Upstream Author : Joao Paulo Magalhaes 
> * URL : https://github.com/biojppm/c4core
> * License : MIT
>   Programming Lang: C++
>   Description : library of low-level C++ utilities, written with
low-latency projects in mind
>
> Rationale:
>rapidyaml [0] depends on this utility.
>Moreover, jsonnet [1] depends on rapidyaml.
>
>[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003397
>[1] https://tracker.debian.org/pkg/jsonnet
>
> Maintenance plan:
>Because I am a novice in debian packaging, I would like to
>ask for someone who can review my upload. I need a sponsor too.
>
>

As mentioned in a different bugreport [0], c4core depends on biojppm/cmake,
debugbreak, and fast_float.
To meet the dependency, we're now preparing for uploading debugbreak and
fast_float [1][2].

As for biojppm/cmake, it looks like this software is used for the author's
project only.
This makes me wonder if it is really reasonable to package biojppm/cmake.
It is technically possible to package it but it could end up with no other
packages depending on the packaged biojppm/cmake than c4core.
To make a clear decision, I would like to ask for your opinion on this
issue.

If you are interested, see also a discussion [3] similar to this one.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003397#35
[1] https://ftp-master.debian.org/new/debugbreak_1.0-1.html
[2] https://ftp-master.debian.org/new/fast-float_3.5.1-1.html
[3] https://lists.debian.org/debian-security-tools/2020/12/msg00012.html

Best regards,
Fukui

Bug#1017088: ITP: c4core -- library of low-level C++ utilities, written with low-latency projects in mind

2022-10-18 Thread Daichi Fukui

Hi all,

> As mentioned in a different bugreport [0], c4core depends on
biojppm/cmake,
> debugbreak, and fast_float.
> To meet the dependency, we're now preparing for uploading debugbreak and
> fast_float [1][2].
>
> As for biojppm/cmake, it looks like this software is used for the author's
> project only.
> This makes me wonder if it is really reasonable to package biojppm/cmake.
> It is technically possible to package it but it could end up with no other
> packages depending on the packaged biojppm/cmake than c4core.
> To make a clear decision, I would like to ask for your opinion on this
> issue.

With the help of Debian developers, debugbreak and fast_float were uploaded
to the archive.
Thus it is a good time to work on c4core.

If you don't mind, can you share your thoughts on the issue relating
to biojppm/cmake as discussed above?

Best,
Fukui

Bug#1005092: pytest-mpl: Please update to version 0.13

2022-10-18 Thread Daichi Fukui

Dear maintainer
CC: Leo Singer

> Dear maintainer,
>
> I am currently packaging cmyt [1], which is a new dependency of the "yt"
> package. For testing, cmyt requires at least version 0.13 of pytest-mpl.
> Could I ask to update the version in Debian to this latest version?
>
> Thank you very much!
>
> Ole

If you don't mind, can I work on updating this package to version 0.13?
I'd be happy if I could contribute to this one and the Astro team.

FYI, I've CC'd this email to Leo because it seems Leo is the top
contributor according to d/changelog.

Best,
Fukui

Bug#1005092: [EXTERNAL] Fwd: Fwd: pytest-mpl: Request to review new version 0.16.1-1

2023-01-02 Thread Daichi Fukui

Hi Ole,
CC: Leo

I've uploaded master, pristine-tar, and upstream branches of pytest-mpl to
salsa respectively[1].

Note that this latest version of my draft does not include the following
d/patches, which try to address privacy-breach-generic and
privacy-breach-uses-embedded-file.
* debian/patches/0003-Use-packaged-bootstrap.bundle.min.js.patch
* debian/patches/0006-Use-packaged-bootstrap.min.css.patch

This is because URLs for external resources are embedded in an html file as
an output of the mpl plugin, which, in my opinion, is not considered
fetching data from external resources "at runtime".
Running the mpl plugin does not trigger fetching external data but it will
be fetched when the html file is browsed.

Meanwhile, in the previous conversation, Ole pointed out that there was
DeprecationWarning possibly caused by pyparsing.
However, I couldn't reproduce that error with the latest python3-pyparsing
package (3.0.9), while Ole was using 3.0.7 according to his build log.
Thus, the latest version of my source package draft doesn't address this
issue.

As for debian/changelog, the entry generated by the Debian Janitor was
merged with my own one, addressing Ole's comment.

If things are satisfactory, can you sponsor and help me upload this package
to the archive?

[1] https://salsa.debian.org/debian-astro-team/pytest-mpl/-/tree/master

Best,
Fukui

Bug#1020606:

2022-11-14 Thread Daichi Fukui

Hi Markus,

On Sun, 13 Nov 2022 at 05:11, Markus Koschany  wrote:

> Hi,
>
> Am Dienstag, dem 08.11.2022 um 23:14 +0900 schrieb Daichi Fukui:
> > Hi all,
> >
> > I've created a new version of the enet source package [0], which is going
> > to be 1.3.17+ds-1 with this update.
> >
> >
> > [0] https://salsa.debian.org/dfukui/enet
>
> The repository seems to be gone. Can you reupload your sources again?
>
> Regards,
>
> Markus
>
>
Thanks for taking time.

Ouch. The visibility was set to be private.
We are now able to look at the contents of that repo.
I'd appreciate it if you review my draft package and give me some feedback.

Best,
Fukui

Bug#1024350: ITP: fapolicyd -- File Access Policy Daemon

2022-11-18 Thread Daichi Fukui

Hello Iwamatsu-san,

On Fri, 18 Nov 2022 14:55:47 +0900 Nobuhiro Iwamatsu 
wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Nobuhiro Iwamatsu 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: fapolicyd
>   Version : 1.1.7
>   Upstream Author : Steve Grubb 
> * URL :
https://github.com/linux-application-whitelisting/fapolicyd
> * License : GPL-3
>   Programming Lang: C
>   Description : File Access Policy Daemon
>
>   Fapolicyd is a simple application whitelisting daemon for Linux.

Thank you for this ITP.
I am interested in fapolicyd as well, so you can ping me when there's
something to share.
Hopefully we'll try to implement this package together.

Best,
Fukui

Bug#1005092: pytest-mpl: Request to review new version 0.16.1-1

2022-11-23 Thread Daichi Fukui

Hello Leo,

>
> It's been a while since we had a conversation some ten days ago.
> I just want to let you know that I'm still working on this and need some
> time to complete the package draft.
> This is because pytest returns a bunch of errors with the updated source
> code.
> I'm now trying to address them.
>
> Best,
> Fukui

Thanks for waiting for a long time.

I've created a new version of pytest-mpl source package [0], which is going
to be 0.16.1-1 with this package.
This draft includes the following updates:
  * New upstream version 0.16.1 (Closes: #1005092)
  * Update copyright
  * Patch: adapt to upstream
  * Update d/watch version
  * Update d/copyright
  * Update debhelper version to 13
  * Add libjs-bootstrap and libjs-bootstrap4 as Depends
  * Update standards version
  * Add Rules-Requires-Root field
  * d/patches: update fields and indexes
  * Add the following new patches to address lintian reports
* Use-packaged-bootstrap.bundle.min.js.patch
* Add-mpl_image_compare-to-markers.patch
* Skip-failing-tests.patch
* Use-packaged-bootstrap.min.css.patch

If this update is satisfactory and helpful,
I would appreciate it if you review and sponsor this draft source package.

[0] https://salsa.debian.org/dfukui/pytest-mpl

Best,
Fukui

Bug#1005092: [EXTERNAL] pytest-mpl: Request to review new version 0.16.1-1

2022-11-23 Thread Daichi Fukui

Hi Leo,

Thanks for a quick response.
OK, I'll forward the request to Ole then.

Best,
Fukui

On Wed, 23 Nov 2022 at 22:22, Singer, Leo P. (GSFC-6610) <
leo.p.sin...@nasa.gov> wrote:

> Hi Daichi,
>
>
>
> I can’t sponsor it myself because I cannot get to my Debian key at the
> moment (it’s in my safety deposit box and I can’t find they key to it). Ole
> might be able to help you.
>
>
>
> Leo
>
>
>
> *From: *Daichi Fukui 
> *Date: *Wednesday, November 23, 2022 at 08:10
> *To: *"1005...@bugs.debian.org" <1005...@bugs.debian.org>
> *Cc: *Leo Singer , "leo.sin...@ligo.org" <
> leo.sin...@ligo.org>, "D. Fukui" 
> *Subject: *[EXTERNAL] pytest-mpl: Request to review new version 0.16.1-1
>
>
>
> Hello Leo,
>
>
>
> >
> > It's been a while since we had a conversation some ten days ago.
> > I just want to let you know that I'm still working on this and need some
> > time to complete the package draft.
> > This is because pytest returns a bunch of errors with the updated source
> > code.
> > I'm now trying to address them.
> >
> > Best,
> > Fukui
>
>
>
> Thanks for waiting for a long time.
>
>
> I've created a new version of pytest-mpl source package [0], which is
> going to be 0.16.1-1 with this package.
> This draft includes the following updates:
>   * New upstream version 0.16.1 (Closes: #1005092)
>   * Update copyright
>   * Patch: adapt to upstream
>   * Update d/watch version
>   * Update d/copyright
>   * Update debhelper version to 13
>   * Add libjs-bootstrap and libjs-bootstrap4 as Depends
>   * Update standards version
>   * Add Rules-Requires-Root field
>   * d/patches: update fields and indexes
>   * Add the following new patches to address lintian reports
> * Use-packaged-bootstrap.bundle.min.js.patch
> * Add-mpl_image_compare-to-markers.patch
> * Skip-failing-tests.patch
> * Use-packaged-bootstrap.min.css.patch
>
> If this update is satisfactory and helpful,
> I would appreciate it if you review and sponsor this draft source package.
>
> [0] https://salsa.debian.org/dfukui/pytest-mpl
> <https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsalsa.debian.org%2Fdfukui%2Fpytest-mpl&data=05%7C01%7Cleo.p.singer%40nasa.gov%7Cafedf9be6a8c468c925408dacd541a91%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638048058364112117%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=uz%2Bqxmds8ym47lgZ5C%2BpCPMdeP9DsHDmtggalpiwLYk%3D&reserved=0>
>
> Best,
> Fukui
>

Bug#1017088: ITP: c4core -- library of low-level C++ utilities, written with low-latency projects in mind

2023-01-24 Thread Daichi Fukui

Hi all
CC: Iwamatsu-san

On Thu, 10 Nov 2022 21:57:30 +0900 Daichi Fukui <
when.a.cat.sits.beside@gmail.com> wrote:
> > > >> * Package name: c4core
> > > >>   Version : 0.1.9
> > > >>   Upstream Author : Joao Paulo Magalhaes 
> > > >> * URL : https://github.com/biojppm/c4core
> > > >> * License : MIT
> > > >>   Programming Lang: C++
> > > >>   Description : library of low-level C++ utilities, written
with
> > > low-latency projects in mind

I've uploaded the draft source package of c4core, which consists of
debian/master, upstream, pristine-tar [0].
When you have time, can you review it and help me upload to the archive?
Note that the upstream version was updated to 0.1.11.

As for the issue discussed earlier [1], I decided to keep fast_float.hpp
and fast_float_all.h header files embedded in c4core.
This is because they do not belong to src/c4/ext/debugbreak or
src/c4/ext/fast_float
in terms of source tree.

[0] https://salsa.debian.org/dfukui/c4core
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017088#30

Best,
Fukui

Bug#1052015: RFS: blktrace/1.3.0-1 -- utilities for block layer IO tracing

2023-09-15 Thread Daichi Fukui

Package: sponsorship-requests
Severity: normal

Dear mentors,
(CC: Bas, Dmitry)

I am looking for a sponsor for the new version 1.3.0-1 of the package
"blktrace" as shown below.
If you think this is satisfactory and helpful, I would like you to
upload that draft to the archive.

FYI, I forked the blktrace repository in salsa and added my changes as
well as pristine-tar and upstream branches for 1.3.0.
Hopefully it is helpful for you to update the repository in salsa.

 * Package name : blktrace
   Version  : 1.3.0-1
   Upstream contact : [fill in name and email of upstream]
 * URL  :
https://git.kernel.org/pub/scm/linux/kernel/git/axboe/blktrace.git/about/
 * License  : GPL, GPL-2+, public-domain, GPL-2
 * Vcs  : https://salsa.debian.org/debian/blktrace
   Section  : utils

The source builds the following binary packages:

  blktrace - utilities for block layer IO tracing

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/blktrace/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/b/blktrace/blktrace_1.3.0-1.dsc

Changes since the last upload:

 blktrace (1.3.0-1) unstable; urgency=medium
 .
   [ Debian Janitor ]
   * Trim trailing whitespace.
   * Remove 1 obsolete maintscript entry.
   * Bump debhelper from old 11 to 13.
   * Set debhelper-compat version in Build-Depends.
   * Fix day-of-week for changelog entry 0~git-20061221162513-1.
   * Update standards version to 4.6.0, no changes needed.
   * Avoid explicitly specifying -Wl,--as-needed linker flag.
   [ Fukui Daichi ]
   * New upstream version 1.3.0
   * Remove and fix patches to catch up with 1.3.0
   * Update d/copyright

Regards,
Fukui

Bug#1052015: RFS: blktrace/1.3.0-1 -- utilities for block layer IO tracing

2023-09-23 Thread Daichi Fukui

Hi,
(CC: Bas, Dmitry)

It's been a week since I filed this bug report.
I would appreciate it if you could take time to review this draft and
sponsor it.

Best,
Fukui

On Sat, 16 Sep 2023 14:21:01 +0900 Daichi Fukui
 wrote:
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
> (CC: Bas, Dmitry)
>
> I am looking for a sponsor for the new version 1.3.0-1 of the package
> "blktrace" as shown below.
> If you think this is satisfactory and helpful, I would like you to
> upload that draft to the archive.
>
> FYI, I forked the blktrace repository in salsa and added my changes as
> well as pristine-tar and upstream branches for 1.3.0.
> Hopefully it is helpful for you to update the repository in salsa.
>
>  * Package name : blktrace
>Version  : 1.3.0-1
>Upstream contact : [fill in name and email of upstream]
>  * URL  :
> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/blktrace.git/about/
>  * License  : GPL, GPL-2+, public-domain, GPL-2
>  * Vcs  : https://salsa.debian.org/debian/blktrace
>Section  : utils
>
> The source builds the following binary packages:
>
>   blktrace - utilities for block layer IO tracing
>
> To access further information about this package, please visit the
> following URL:
>
>   https://mentors.debian.net/package/blktrace/
>
> Alternatively, you can download the package with 'dget' using this command:
>
>   dget -x 
> https://mentors.debian.net/debian/pool/main/b/blktrace/blktrace_1.3.0-1.dsc
>
> Changes since the last upload:
>
>  blktrace (1.3.0-1) unstable; urgency=medium
>  .
>[ Debian Janitor ]
>* Trim trailing whitespace.
>* Remove 1 obsolete maintscript entry.
>* Bump debhelper from old 11 to 13.
>* Set debhelper-compat version in Build-Depends.
>* Fix day-of-week for changelog entry 0~git-20061221162513-1.
>* Update standards version to 4.6.0, no changes needed.
>* Avoid explicitly specifying -Wl,--as-needed linker flag.
>[ Fukui Daichi ]
>* New upstream version 1.3.0
>* Remove and fix patches to catch up with 1.3.0
>* Update d/copyright
>
> Regards,
> Fukui
>
>

Bug#1052015: RFS: blktrace/1.3.0-1 -- utilities for block layer IO tracing

2023-10-17 Thread Daichi Fukui

Hi Bas, Dmitry,

It's been a while since the last contact.
I would appreciate it if you could take some time to review this draft
and sponsor it.

Best,
Fukui

On Sat, 23 Sept 2023 at 16:06, Daichi Fukui
 wrote:
>
> Hi,
> (CC: Bas, Dmitry)
>
> It's been a week since I filed this bug report.
> I would appreciate it if you could take time to review this draft and
> sponsor it.
>
> Best,
> Fukui
>
> On Sat, 16 Sep 2023 14:21:01 +0900 Daichi Fukui
>  wrote:
> > Package: sponsorship-requests
> > Severity: normal
> >
> > Dear mentors,
> > (CC: Bas, Dmitry)
> >
> > I am looking for a sponsor for the new version 1.3.0-1 of the package
> > "blktrace" as shown below.
> > If you think this is satisfactory and helpful, I would like you to
> > upload that draft to the archive.
> >
> > FYI, I forked the blktrace repository in salsa and added my changes as
> > well as pristine-tar and upstream branches for 1.3.0.
> > Hopefully it is helpful for you to update the repository in salsa.
> >
> >  * Package name : blktrace
> >Version  : 1.3.0-1
> >Upstream contact : [fill in name and email of upstream]
> >  * URL  :
> > https://git.kernel.org/pub/scm/linux/kernel/git/axboe/blktrace.git/about/
> >  * License  : GPL, GPL-2+, public-domain, GPL-2
> >  * Vcs  : https://salsa.debian.org/debian/blktrace
> >Section  : utils
> >
> > The source builds the following binary packages:
> >
> >   blktrace - utilities for block layer IO tracing
> >
> > To access further information about this package, please visit the
> > following URL:
> >
> >   https://mentors.debian.net/package/blktrace/
> >
> > Alternatively, you can download the package with 'dget' using this command:
> >
> >   dget -x 
> > https://mentors.debian.net/debian/pool/main/b/blktrace/blktrace_1.3.0-1.dsc
> >
> > Changes since the last upload:
> >
> >  blktrace (1.3.0-1) unstable; urgency=medium
> >  .
> >[ Debian Janitor ]
> >* Trim trailing whitespace.
> >* Remove 1 obsolete maintscript entry.
> >* Bump debhelper from old 11 to 13.
> >* Set debhelper-compat version in Build-Depends.
> >* Fix day-of-week for changelog entry 0~git-20061221162513-1.
> >* Update standards version to 4.6.0, no changes needed.
> >* Avoid explicitly specifying -Wl,--as-needed linker flag.
> >[ Fukui Daichi ]
> >* New upstream version 1.3.0
> >* Remove and fix patches to catch up with 1.3.0
> >* Update d/copyright
> >
> > Regards,
> > Fukui
> >
> >

Bug#1003397:

2022-09-02 Thread Daichi Fukui

Hello Iwamatsu-san,

I have drafted a source package of debugbreak.
I'm doing this because c4core, which you mentioned before, depends on this
software.
Kindly find URLs for the ITP below.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017846
https://mentors.debian.net/package/debugbreak/

I would appreciate it if you review the source package.

Best,
Fukui

On Sat, 13 Aug 2022 22:12:35 +0900 Daichi Fukui <
when.a.cat.sits.beside@gmail.com> wrote:
> Hi Iwamatsu-san,
>
> > First, This is emedded with C4CORE.
> > Do you have any plans to package this?
> >   https://github.com/biojppm/c4core
>
> I filed an ITP for c4core. For details, take a look at the following.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017088
>
> Let's continue discussion about packaging c4core there.
>
> Best,
> Fukui
>
> On Mon, 25 Jul 2022 06:58:22 +0900 Nobuhiro Iwamatsu 
> wrote:
> > Hi Daichi,
> >
> > I reviewed your package.
> >
> > First, This is emedded with C4CORE.
> > Do you have any plans to package this?
> >   https://github.com/biojppm/c4core
> >
> > debain/control:
> >   development package is required., because this is a library.
> >
> > debian/patches:
> >   Currently, this package does not have any patches. so this can delete.
> >
> > Best regards,
> >   Nobuhiro
> >
> > 2022年7月20日(水) 23:09 Daichi Fukui :
> >
> > >
> > > Hello Iwamatsu-san,
> > >
> > > I have drafted a source package of rapidyaml and put it onto my
private
> repository in salsa:
> > >
> > > https://salsa.debian.org/dfukui/rapidyaml/-/tree/debian/0.4.1-1
> > >
> > > When you have time, can you review the source package and help me
> upload it to the archive?
> > >
> > > Best regards,
> > > Fukui
> >
> >
> >
> > --
> > Nobuhiro Iwamatsu
> >iwamatsu at {nigauri.org / debian.org}
> >GPG ID: 40AD1FA6
> >
> >

Bug#1017324: libhugetlbfs: FTBFS: morecore.c:368:17: error: ‘__morecore’ undeclared (first use in this function); did you mean ‘thp_morecore’?

2022-09-05 Thread Daichi Fukui

Hi,

I have created a patch to address this issue.
Kindly find my github repository below for details:
https://github.com/daichifukui/libhugetlbfs

Note that this patch is based on an upstream pull request, which has not
been reviewed yet:
https://github.com/libhugetlbfs/libhugetlbfs/pull/63

Perhaps we need to review the original patch as well.

Best,
Fukui

On Sun, 14 Aug 2022 10:44:55 +0200 Lucas Nussbaum  wrote:
> Source: libhugetlbfs
> Version: 2.23-4
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220813 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > cc -m64 -Wdate-time -D_FORTIFY_SOURCE=2 -D__LIBHUGETLBFS__ -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wall -fPIC -o obj64/kernel-features.o -c
kernel-features.c
> > morecore.c: In function ‘__lh_hugetlbfs_setup_morecore’:
> > morecore.c:368:17: error: ‘__morecore’ undeclared (first use in this
function); did you mean ‘thp_morecore’?
> >   368 | __morecore = &thp_morecore;
> >   | ^~
> >   | thp_morecore
> > morecore.c:368:17: note: each undeclared identifier is reported only
once for each function it appears in
> > make[1]: *** [Makefile:298: obj64/morecore.o] Error 1
>
>
> The full build log is available from:
> http://qa-logs.debian.net/2022/08/13/libhugetlbfs_2.23-4_unstable.log
>
> All bugs filed during this archive rebuild are listed at:
>
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20220813;users=lu...@debian.org
> or:
>
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20220813&fusertaguser=lu...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> If you reassign this bug to another package, please marking it as
'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
>
> If you fail to reproduce this, please provide a build log and diff it
with mine
> so that we can identify if something relevant changed in the meantime.
>
>

Bug#1003397:

2022-09-07 Thread Daichi Fukui

Hello Iwamatsu-san,

I have drafted a source package for debugbreak.
Kindly find the URL below for the latest source package (Upload #3).
https://mentors.debian.net/package/debugbreak/

I would appreciate it if you review the source package.

Best,
Fukui

On Mon, 5 Sep 2022 09:17:48 +0900 Nobuhiro Iwamatsu 
wrote:
> Hi Daichi,
>
> 2022年9月3日(土) 15:22 Daichi Fukui :
> >
> > Hello Iwamatsu-san,
> >
> > I have drafted a source package of debugbreak.
> > I'm doing this because c4core, which you mentioned before, depends on
this software.
> > Kindly find URLs for the ITP below.
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017846
> > https://mentors.debian.net/package/debugbreak/
> >
> > I would appreciate it if you review the source package.
>
> This contains a Python script.
>   /usr/share/debugbreak/gdb/debugbreak-gdb.py
>
> I recommend that you specify gdb for Sugguest.
>
> Best regards,
>   Nobuhiro
>
>
> >
> > Best,
> > Fukui
> >
> > On Sat, 13 Aug 2022 22:12:35 +0900
*－－－*
福意 大智

Daichi Fukui

a.dog.will.talk [at] akane.waseda.jp
*－－－*
 wrote:
> > > Hi Iwamatsu-san,
> > >
> > > > First, This is emedded with C4CORE.
> > > > Do you have any plans to package this?
> > > >   https://github.com/biojppm/c4core
> > >
> > > I filed an ITP for c4core. For details, take a look at the following.
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017088
> > >
> > > Let's continue discussion about packaging c4core there.
> > >
> > > Best,
> > > Fukui
> > >
> > > On Mon, 25 Jul 2022 06:58:22 +0900 Nobuhiro Iwamatsu <
iwama...@nigauri.org>
> > > wrote:
> > > > Hi Daichi,
> > > >
> > > > I reviewed your package.
> > > >
> > > > First, This is emedded with C4CORE.
> > > > Do you have any plans to package this?
> > > >   https://github.com/biojppm/c4core
> > > >
> > > > debain/control:
> > > >   development package is required., because this is a library.
> > > >
> > > > debian/patches:
> > > >   Currently, this package does not have any patches. so this can
delete.
> > > >
> > > > Best regards,
> > > >   Nobuhiro

Bug#1019961: ITP: fast-float -- Implementation of the C++ from_chars functions for float and double types

2022-09-17 Thread Daichi Fukui

Hi Stephan,

Thanks for your interest.
Sure. I'll let you know when there's progress.

Best,
Fukui

On Sat, 17 Sept 2022 at 16:54, Stephan Lachnit 
wrote:

> While short on time, I have a interest in rapidyml, so you can try to ping
> me. Also maybe ask Gürkan Myczko (CC).
>
> Regards,
> Stephan
>

Bug#967228:

2021-08-02 Thread Daichi Fukui

Hi Maintainer,

Looks like this issue has already been resolved upstream [0].
libpython2.7-dev was simply replaced with libpython3-dev there, so we
can modify debian/control as well.

I look forward to a new update on this package.

[0] 
https://github.com/namhyung/uftrace/commit/4bfe0f1dc915e9658f5c5e1a0c47dd933c32155c

Best regards,
Fukui


replace-libpython.patch
Description: Binary data

Bug#91815: Patch to add memusage and memusagestat

2020-11-28 Thread Daichi Fukui

Hi

Do you have a plan to push the patch
'0001-Build-and-package-memusage.patch' so that it lands in Bullseye or
later?
I'm looking forward to it.

Best,
Fukui

Bug#974844: ovmf: EFI shell prompt doesn't show up in qemu curses

2020-11-15 Thread Daichi Fukui

Package: ovmf
Version: 2020.08-1
Severity: normal
X-Debbugs-Cc: daichi.fuku...@gmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
When I was trying to boot a Debian image with OVMF_CODE.secboot.fd enabled 
in a QEMU virtual machine,
I noticed that the EFI shell didn't show up with  curses enabled.
Here is a list of options to boot the image:
$ qemu-system-x86_64 \
--machine q35,smm=on \
-global driver=cfi.pflash01,property=secure,value=on  \
-drive 
if=pflash,format=raw,unit=0,file=/usr/share/OVMF/OVMF_CODE.secboot.fd,readonly=on
 \
-drive if=pflash,format=raw,unit=1,file=/usr/share/OVMF/OVMF_VARS.fd \
-display none -serial mon:stdio -echr 2 -vga none -curses -k en-us \
-drive file=debian-qemu-amd64-2.img,format=raw,index=0,media=disk \
--enable-kvm -m 2048 -net none

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   To make things clearer, I tested two different firmwares - OVMF_CODE.fd and 
OVMF_CODE.secboot.fd - with the same qemu options including '-curses'.
   As a result, the EFI shell successfully showed up in curses with 
OVMF_CODE.fd, but the EFI shell failed to show up with OVMF_CODE.secboot.fd. 

   # With OVMF_CODE.fd, the EFI shell prompt successfully appears
   $ qemu-system-x86_64 \
   -bios /usr/share/OVMF/OVMF_CODE.fd \
   -display none -serial mon:stdio \
   -echr 2 -vga none -curses -k en-us -net none
   [...]
   UEFI Interactive Shell v2.2
   EDK II
   UEFI v2.70 (EDK II, 0x0001)
   Mapping table
BLK0: Alias(s):
 PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
   Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
   Shell> 

   # With OVMF_CODE.secboot.fd, the EFI shell doesn't show up in curses
   $ qemu-system-x86_64 \
   -bios /usr/share/OVMF/OVMF_CODE.secboot.fd \
   -display none -serial mon:stdio \
   -echr 2 -vga none -curses -k en-us -net none
   [...]
   (Nothing appeared after some minutes)

   * What was the outcome of this action?
   When a qemu image boots up with OVMF_CODE.secboot.fd provided, 
   the EFI shell prompt doesn't show up in curses without showing any log 
messages.

   I suspect that this situation means that there is a bug in the secure boot 
firmware, guessing from the result above.   
   Unfortunately, with OVMF_CODE.secboot.fd in use, 
   the curses console does not provide any logs, so I could not investigate the 
situation further.
   I would appreciate it if you could point me to instructions on how to 
collect logs in such a situation.

   * What outcome did you expect instead?
   When a qemu image boots up with OVMF_CODE.secboot.fd provided, 
   the EFI shell prompt successfully shows up in curses.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.10.0-27-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

-- debconf information excluded

Bug#995583: dpkg-depcheck: use mktemp to replace obsolete tempfile

2021-10-02 Thread Daichi Fukui

-utils5.2.5-2

Versions of packages devscripts suggests:
pn  adequate 
pn  at   
pn  autopkgtest  
pn  bls-standalone   
pn  bsd-mailx | mailx
ii  build-essential  12.9
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.5.2
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
ii  faketime 0.9.8-9
pn  gnuplot  
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1.1
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-2
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3300-2
pn  libyaml-syck-perl
pn  mmdebstrap   
ii  mozilla-devscripts   0.54.2
pn  mutt 
ii  openssh-client [ssh-client]  1:8.4p1-6
pn  piuparts 
pn  postgresql-client
pn  pristine-lfs 
ii  quilt0.66-2.1
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
pn  w3m  

-- no debconf information
>From ac8eb6bd020009f63cb410acdfad41f2529bdcbb Mon Sep 17 00:00:00 2001
From: Daichi Fukui 
Date: Sat, 2 Oct 2021 09:37:47 +
Subject: [PATCH] scripts/dpkg-depcheck: replace tempfile with mktemp

Signed-off-by: Daichi Fukui 
---
 scripts/dpkg-depcheck.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/dpkg-depcheck.pl b/scripts/dpkg-depcheck.pl
index 401aa5ca..63854156 100755
--- a/scripts/dpkg-depcheck.pl
+++ b/scripts/dpkg-depcheck.pl
@@ -372,7 +372,7 @@ sub getusedfiles (@) {
 $file = $opts{"strace-input"};
 } else {
 my $old_locale = $ENV{'LC_ALL'} || undef;
-$file = $opts{"strace-output"} || `tempfile -p depcheck`;
+$file = $opts{"strace-output"} || `mktemp`;
 chomp $file;
 $file =~ s%^(\s)%./$1%;
 my @strace_cmd = (
-- 
2.33.0

Bug#1000256: debmake-doc: Typo in asciidoc/57-chroot.txt

2021-11-20 Thread Daichi Fukui

Package: debmake-doc
Version: 1.17-2
Severity: minor
Tags: patch
X-Debbugs-Cc: daichi.fuku...@gmail.com

Dear Maintainer,

There is a typo in asciidoc/57-chroot.txt.
Kindly consider applying the attached patch file.

Best,
Fukui


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.15.0-144-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

debmake-doc depends on no packages.

Versions of packages debmake-doc recommends:
ii  debmake  4.3.2-1.1

Versions of packages debmake-doc suggests:
pn  debian-policy 
pn  developers-reference  

-- no debconf information
>From b9a3d206604129ffbb77b088d6d621c7cade58b8 Mon Sep 17 00:00:00 2001
From: Daichi Fukui 
Date: Sat, 20 Nov 2021 09:12:14 +
Subject: [PATCH] Update asciidoc/57-chroot.txt: fix typo

Signed-off-by: Daichi Fukui 
---
 asciidoc/57-chroot.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/asciidoc/57-chroot.txt b/asciidoc/57-chroot.txt
index eb06512..dd67310 100644
--- a/asciidoc/57-chroot.txt
+++ b/asciidoc/57-chroot.txt
@@ -11,7 +11,7 @@ Here is a quick summary of available package build commands.  
There are many way
 * *schroot* = core of the Debian chroot environment tool
 * *sbuild* = *schroot* + *dpkg-buildpackage* (build in the chroot)
 * *gbp* = manage the Debian source under git
-* *gbp buildpackge* = *sbuild* + *dpkg-buildpackage* + *gbp* (if configured 
with *sbuild*)
+* *gbp buildpackage* = *sbuild* + *dpkg-buildpackage* + *gbp* (if configured 
with *sbuild*)
 
 A clean *unstable* distribution chroot environment can be used as follows.
 
-- 
2.33.0

Bug#1001504: packaging-tutorial: URL to Ubuntu Packaging Guide is too old

2021-12-11 Thread Daichi Fukui

Package: packaging-tutorial
Version: 0.29
Severity: normal
Tags: patch
X-Debbugs-Cc: daichi.fuku...@gmail.com

Dear Maintainer,

Looks like the URL of Ubuntu Packaging Guide was changed.
Let's update the slide 'More documentation' accordingly.

Best regards,
Fukui

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.15.0-144-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

-- no debconf information
>From 1cdaf2a8fa41b7703a6c67f285486735ea952e56 Mon Sep 17 00:00:00 2001
From: Daichi Fukui 
Date: Sat, 11 Dec 2021 09:27:53 +
Subject: [PATCH] Update URL to Ubuntu Packaging Guide

Signed-off-by: Daichi Fukui 
---
 packaging-tutorial.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/packaging-tutorial.tex b/packaging-tutorial.tex
index a5dac35..70cce1c 100644
--- a/packaging-tutorial.tex
+++ b/packaging-tutorial.tex
@@ -1321,7 +1321,7 @@ You
 \hbr
 
   \item Ubuntu Packaging Guide\\
-\url{http://developer.ubuntu.com/resources/tools/packaging/}
+\url{https://packaging.ubuntu.com/html/}
   \end{itemize}
 \end{frame}
 
-- 
2.33.0

Bug#1016580: RFS: jsonnet/0.18.0 ds-3 -- data templating language

2022-08-03 Thread Daichi Fukui

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "jsonnet":

 * Package name: jsonnet
   Version : 0.18.0+ds-3
   Upstream Author : [fill in name and email of upstream]
 * URL : https://github.com/google/jsonnet
 * License : Apache-2.0, RSA-MD5, BSD-3-clause, Boost-1.0,
BSD-2-Clause, MIT2, Expat
 * Vcs : https://salsa.debian.org/debian/jsonnet
   Section : devel

The source builds the following binary packages:

  jsonnet - data templating language
  libjsonnet0 - data templating language (lib)
  libjsonnet-dev - data templating language (devel)
  python3-jsonnet - data templating language (Python)

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/jsonnet/

Alternatively, you can download the package with 'dget' using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/j/jsonnet/jsonnet_0.18.0+ds-3.dsc

Changes since the last upload:

 jsonnet (0.18.0+ds-3) unstable; urgency=medium
 .
   * Add riscv64 architecture (Closes: #1014598)

Regards,

Bug#1003397:

2022-08-13 Thread Daichi Fukui

Hi Iwamatsu-san,

> First, This is emedded with C4CORE.
> Do you have any plans to package this?
>   https://github.com/biojppm/c4core

I filed an ITP for c4core. For details, take a look at the following.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017088

Let's continue discussion about packaging c4core there.

Best,
Fukui

On Mon, 25 Jul 2022 06:58:22 +0900 Nobuhiro Iwamatsu 
wrote:
> Hi Daichi,
>
> I reviewed your package.
>
> First, This is emedded with C4CORE.
> Do you have any plans to package this?
>   https://github.com/biojppm/c4core
>
> debain/control:
>   development package is required., because this is a library.
>
> debian/patches:
>   Currently, this package does not have any patches. so this can delete.
>
> Best regards,
>   Nobuhiro
>
> 2022年7月20日(水) 23:09 Daichi Fukui :
>
> >
> > Hello Iwamatsu-san,
> >
> > I have drafted a source package of rapidyaml and put it onto my private
repository in salsa:
> >
> > https://salsa.debian.org/dfukui/rapidyaml/-/tree/debian/0.4.1-1
> >
> > When you have time, can you review the source package and help me
upload it to the archive?
> >
> > Best regards,
> > Fukui
>
>
>
> --
> Nobuhiro Iwamatsu
>iwamatsu at {nigauri.org / debian.org}
>GPG ID: 40AD1FA6
>
>

Bug#1013310: jsonnet: FTBFS on several release architectures

2022-07-01 Thread Daichi Fukui

Hello Bastian,

Thanks for reporting this.
And apologies for a late reply.

To address this FTBFS issue, I uploaded the following changes to s
alsa.

* fix FTBFS on several release architectures
* fix FTBFS error on armel
* Remove mipsel, mips64el, s390x as build target

For further information, kindly visit the following URL:
https://salsa.debian.org/dfukui/jsonnet/-/commits/debian/0.18.0+ds-2

If you don't mind, I would appreciate it if you sponsor and help me upload
this package.
The following are some technical comments.

According to the original source code [0], c4core does not support the
following CPU architectures:
s390x, mipsel, mips64el
Thus, we should drop these ones from the Architecture field on d/control.

Meanwhile, debugbreak should have been successfully built by falling back
to raising SIGTRAP [1] for several architectures, but build fails due to a
bug in upstream.
This issue has already been addressed [2], so a patch [3] was created and
added to d/patches based on upstream. In a similar story, I fixed FTBFS on
armel and filed a patch [4].

Thanks for reading.

[0]
https://github.com/biojppm/c4core/blob/52f3ff57b287ce57c2bbf80dc091bd21e4d9f977/src/c4/cpu.hpp
[1]
https://github.com/google/jsonnet/blob/v0.18.0/third_party/rapidyaml/rapidyaml/ext/c4core/src/c4/ext/debugbreak/debugbreak.h#L123
[2]
https://github.com/scottt/debugbreak/commit/8b4a755e76717103adc814c0c05ceb3b91befa7d
[3]
https://salsa.debian.org/dfukui/jsonnet/-/commit/1bea08d549c450b8c9624e686df88f025e1d3d5c
[4]
https://salsa.debian.org/dfukui/jsonnet/-/commit/efb346e3ec210104897c38979291ab68e1eead73

Best,
Fukui

Bug#1013310: jsonnet: FTBFS on several release architectures

2022-07-02 Thread Daichi Fukui

Hello Bastian,

Thanks for pointing this out.

> Please do not just copy patches from upstream and put your name on it.
> The new patch is partly derived from
https://github.com/biojppm/debugbreak/commit/8b4a755e76717103adc814c0c05ceb3b91befa7d
OK, I followed DEP-3 and updated the patches i made accordingly.
See:
https://salsa.debian.org/dfukui/jsonnet/-/commit/1bea08d549c450b8c9624e686df88f025e1d3d5c
https://salsa.debian.org/dfukui/jsonnet/-/commit/efb346e3ec210104897c38979291ab68e1eead73

> Also, you have not removed architectures but whitelisted some
architectures.
> Please correct your changelog.
Got it.
Here is an updated changelog:
https://salsa.debian.org/debian/jsonnet/-/commit/21be6a0c840ca38ad002b2a031c7077ecb6fb674

> Please use the Vcs that is recorded in d/control.
Ah yes, I remembered I was recently granted permission for the Vcs.
I've uploaded the latest updates here:
https://salsa.debian.org/debian/jsonnet/-/commits/debian/0.18.0+ds-2

> Also please make sure not to write to sub...@debian.org.
Indeed. I'll be careful about this.

Best,
Fukui

Bug#1003397:

2022-07-20 Thread Daichi Fukui

Hello Iwamatsu-san,

I have drafted a source package of rapidyaml and put it onto my
private repository in salsa:

https://salsa.debian.org/dfukui/rapidyaml/-/tree/debian/0.4.1-1

When you have time, can you review the source package and help me upload it
to the archive?

Best regards,
Fukui

Bug#1003397:

2022-07-31 Thread Daichi Fukui

Hello Iwamatsu-san,

> First, This is embedded with C4CORE.
> Do you have any plans to package this?
>  https://github.com/biojppm/c4core

Thanks for pointing this out.
Looks like we need to package c4core as well.
Yes, I'll do that.

But before starting it, let me share one thing as follows.
According to .gitmodule, c4core depends on cmake, debugbreak, and
fast_float [0].
Then, is it correct to say we need to package debugbreak and fast_float as
well as c4core?

As for other stuff you mentioned, I'll do them accordingly.

[0]
https://github.com/biojppm/c4core/blob/5ff3aa3a10c65c784d12716954e1e742376620d0/.gitmodules

Best,
Fukui

On Mon, 25 Jul 2022 at 06:58, Nobuhiro Iwamatsu 
wrote:

> Hi Daichi,
>
> I reviewed your package.
>
> First, This is emedded with C4CORE.
> Do you have any plans to package this?
>   https://github.com/biojppm/c4core
>
> debain/control:
>   development package is required., because this is a library.
>
> debian/patches:
>   Currently, this package does not have any patches. so this can delete.
>
> Best regards,
>   Nobuhiro
>
> 2022年7月20日(水) 23:09 Daichi Fukui :
>
> >
> > Hello Iwamatsu-san,
> >
> > I have drafted a source package of rapidyaml and put it onto my private
> repository in salsa:
> >
> > https://salsa.debian.org/dfukui/rapidyaml/-/tree/debian/0.4.1-1
> >
> > When you have time, can you review the source package and help me upload
> it to the archive?
> >
> > Best regards,
> > Fukui
>
>
>
> --
> Nobuhiro Iwamatsu
>iwamatsu at {nigauri.org / debian.org}
>GPG ID: 40AD1FA6
>

Bug#1012708: RFS: jsonnet/0.18.0 ds-1 [ITA] -- data templating language

2022-06-12 Thread Daichi Fukui

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "jsonnet":

 * Package name: jsonnet
   Version : 0.18.0+ds-1
   Upstream Author : [fill in name and email of upstream]
 * URL : https://github.com/google/jsonnet
 * License : MD5-a-certain-license, Apache-2.0, Expat
 * Vcs : https://salsa.debian.org/debian/jsonnet
   Section : devel

The source builds the following binary packages:

  jsonnet - data templating language
  libjsonnet0 - data templating language (lib)
  libjsonnet-dev - data templating language (devel)
  python3-jsonnet - data templating language (Python)

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/jsonnet/

Alternatively, you can download the package with 'dget' using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/j/jsonnet/jsonnet_0.18.0+ds-1.dsc

Changes since the last upload:

 jsonnet (0.18.0+ds-1) unstable; urgency=medium
 .
   * New upstream version 0.18.0+ds
   * Remove tests-dont-use-python2.patch

Regards,

Bug#1012294:

2022-06-12 Thread Daichi Fukui

Hi

I intend to adopt jsonnet -- data templating language.

I am looking for an opportunity to contribute to Debian through packaging.
If you don't mind, let me adopt this package.

Regards,
Fukui

Bug#983803: ITA: simple-revision-control -- single-file and single-user revision control system

2022-03-20 Thread Daichi Fukui

Hi

I intend to adopt simple-revision-control -- single-file and single-user
revision control system.

I am looking for an opportunity to contribute to Debian through packaging.
If you don't mind, let me adopt this package.

Regards,
Fukui

On Mon, 1 Mar 2021 23:37:47 +0200 Adrian Bunk  wrote:
> Package: wnpp
> Severity: normal
>
> The current maintainer of simple-revision-control has retired.
Therefore, I orphan this package now.
>
> Maintaining a package requires time and skills. Please only adopt this
> package if you will have enough time and attention to work on it.
>
> If you want to be the new maintainer, please see
> http://www.debian.org/devel/wnpp/index.html#howto-o
> for detailed instructions how to adopt a package properly.
>
> More information about this package:
>
> http://tracker.debian.org/pkg/simple-revision-control
>
>
> Package: simple-revision-control
> Binary: simple-revision-control
> Version: 1.26-2
> Maintainer: Dmitry Bogatov 
> Build-Depends: asciidoc, debhelper-compat (= 11), docbook-xml,
docbook-xsl, xsltproc
> Architecture: all
> Standards-Version: 4.3.0
> Format: 3.0 (quilt)
> Files:
>  de78a6112a426b73588f7fff51ee8193 2044 simple-revision-control_1.26-2.dsc
>  565b556139f8385aad342174badfef12 56482
simple-revision-control_1.26.orig.tar.gz
>  08bd3dbeec365ecbcecc595c8950eee3 2764
simple-revision-control_1.26-2.debian.tar.xz
> Vcs-Browser: https://salsa.debian.org/debian/simple-revision-control
> Vcs-Git: https://salsa.debian.org/debian/simple-revision-control.git
> Checksums-Sha256:
>  92ee43c54e6994a2eb06aac0d917a9d11c28068b2950c25ed74b617640ab86b6 2044
simple-revision-control_1.26-2.dsc
>  435c457f9f577d84ae1fd763e2bd3548d84f84c50cd2c88f664fba259cd5d71a 56482
simple-revision-control_1.26.orig.tar.gz
>  3358e36461ed89a3e5951261cc4c25e83751c0ed09d6291f9f509b3e2d156660 2764
simple-revision-control_1.26-2.debian.tar.xz
> Homepage: https://gitlab.com/esr/src
> Package-List:
>  simple-revision-control deb vcs optional arch=all
> Directory: pool/main/s/simple-revision-control
> Priority: extra
> Section: misc
>
> Package: simple-revision-control
> Version: 1.26-2
> Installed-Size: 146
> Maintainer: Dmitry Bogatov 
> Architecture: all
> Depends: python3, rcs
> Suggests: sccs
> Description-en: single-file and single-user revision control system
>  This package provides a powerful modern user interface for an RCS
>  (and to some extend, SCCS) backend. It will be familiar to users
>  with modern Subversion, Git, Hg experience, as well as a
>  reasonable introduction to this toolset to novices.
>  .
>  SRC is designed to provide its strength for single-file, single-user
>  version tracking. When it is overkill to make a whole directory and
>  multi-file repository store (under, for example, Git or Hg), src can
>  provide tracking for individual files instead.  Examples of such might
>  be your ~/bin scripts, /etc files, personal notes, résumés, and any such

Bug#1008049: RFS: simple-revision-control/1.29-1 [ITA] -- single-file and single-user revision control system

2022-03-21 Thread Daichi Fukui

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "simple-revision-control":

 * Package name: simple-revision-control
   Version : 1.29-1
   Upstream Author : Eric S. Raymond 
 * URL : https://gitlab.com/esr/src
 * License : BSD-2-clause
 * Vcs : https://salsa.debian.org/debian/simple-revision-control
   Section : vcs

The source builds the following binary packages:

  simple-revision-control - single-file and single-user revision control
system

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/simple-revision-control/

Alternatively, you can download the package with 'dget' using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/s/simple-revision-control/simple-revision-control_1.29-1.dsc

Changes since the last upload:

 simple-revision-control (1.29-1) unstable; urgency=medium
 .
   * New maintainer (Closes: #983803)
   * New upstream release

Regards,
Fukui

Bug#1007959: uftrace: Intent to NMU

2022-03-26 Thread Daichi Fukui

Hi Paul.

> I have a new 0.11-4 release prepared at
> https://github.com/thepaul/uftrace/tree/deb, if either of you would care
> to take a look by way of review, to make sure I have incorporated both
> of your inputs.

LGTM.
Yes, what I wanted to upload is all incorporated.

Best,
Fukui

Bug#1053587: simple-revision-control: Fails when importing legacy RCS files with "description" content

2024-02-23 Thread Daichi Fukui

Hello Penney,

On Sat, 07 Oct 2023 06:51:59 +0100 RW Penney
 wrote:
>
> When using simple-revision-control to import RCS histories, it appears
> unable to handle RCS files that include a non-empty "description" field.
> This seems to be because the "src" application treats this field
> as JSON, which may be inconsistent with the RCS file format,
> as well as the format used by the RCS tools currently in bookworm.

Thank you for reporting the bug.
The bug you reported is fixed with the following upstream commit:
https://gitlab.com/esr/src/-/commit/9917f118882fa57b7ae171cd4a27fce0c59f54f7

That commit is included in the latest package 1.33-1.

Best,
Fukui

Bug#1082328: blktrace: Missing build on mips64el and ppc64el

2024-11-13 Thread Daichi Fukui

Hi Paul, Dmitry,

>Paul
Thank you very much for applying the patch. I apologize for my very late
response.
For your information, I would like to share with you my experimental and
unofficial blktrace repo, where the original tarball is simply extracted
and the debian directory is copied.

https://salsa.debian.org/dfukui/blktrace.git

>Dmitry
I appreciate you sharing the insight on how to handle the debian-only repo
layout.
As we discussed before, I'll keep the blktrace repo layout as it is since
upstream blktrace doesn't get many releases.

Best,
Fukui

On Fri, 1 Nov 2024 at 18:11, Dmitry Smirnov  wrote:

> On Wednesday, 23 October 2024 9:22:00 PM AEDT Paul Gevers wrote:
> > I have applied the patch and have uploaded it to the archive with dgit.
>
> Thank you for your help.
>
>
> > I'll try to push the changes as commit to salsa, but (unfortunately for
> > me) I'll need to tweak it a bit because it's a ./debian only repo which
> > I don't know how to handle.
>
> "/debian"-only repo is the simplest and easiest layout for Debian package
> repositories. It requires no knowledge of sophisticated tools like dgit
> and git-buildpackage and it works even with complex packages (e.g.
> MUT) that can't be managed by GBP.
>
> "debian/" folder represents exactly what is combined with upstream source
> to build a package.
>
> Here is the simplest build workflow that can be used with this layout:
>
>   https://salsa.debian.org/onlyjob/notes/-/wikis/bp
>
> GBP can be adjusted to work with such layout and the following document
> have some hints about how that could be done:
>
>
> https://salsa.debian.org/onlyjob/notes/-/wikis/no-gbp#building-with-git-buildpackage
>
> --
> Best wishes,
>  Dmitry Smirnov
>  GPG key : 4096R/52B6BBD953968D1B
>
> ---
>
> Scientific education for the masses will do little good, and probably a lot
> of harm, if it simply boils down to more physics, more chemistry, more
> biology, etc to the detriment of literature and history. Its probable
> effect on the average human being would be to narrow the range of his
> thoughts and make him more than ever contemptuous of such knowledge as he
> did not possess.
>  -- George Orwell
>

Bug#1069862: blktrace: FTBFS on ppc64el in Ubuntu (-O3?) due to wrong code analysis

2024-09-22 Thread Daichi Fukui

Hello Steve,

> It's possible/likely that this build failure is caused by the use of -O3
by
> default for ppc64el builds in Ubuntu; so the attached patch, while it
fixes
> the problem in Ubuntu and should be harmless in Debian, may not be
something
> you want to apply as-is.  Perhaps you would prefer to use $(filter
-O3,...)
> instead?

Thank you for reporting this issue.

Your idea of using $(filter -O3,...) looks good to me, but I would like to
clarify one thing.

When I tried to reproduce the issue on ppc64el with Debian unstable as of
September 22, 2024, I was unable to do so.
According to the build log[0] on ppc64el, it appears that the -O2 option is
used for the build rather than -O3.

For further investigation, if the following change is applied to d/rules,
the issue is reproduced on ppc64el with Debian unstable, but that is not
what we want to do.

```
--- ../blktrace/debian/rules2024-08-18 06:21:55.98400 +
+++ debian/rules2024-09-22 06:48:37.69600 +
@@ -5,7 +5,7 @@
 include /usr/share/dpkg/architecture.mk
 include /usr/share/dpkg/pkg-info.mk

-CFLAGS += -Wall -Wextra -Wno-shadow -Werror -g
+CFLAGS += -Wall -Wextra -Wno-shadow -Werror -g -O3

 export DEB_BUILD_MAINT_OPTIONS = hardening=+all future=+all qa=+all
reproducible=+all
```

Additionally, the -O2 option is used for all CPU architectures in Ubuntu
except for ppc64el[1], which makes me wonder why -O3 is used for ppc64el in
Ubuntu.
Do you have any idea why -O3 is used only for ppc64el in Ubuntu?
I would like to know whether this issue is specific to Ubuntu.

[0]
https://buildd.debian.org/status/fetch.php?pkg=blktrace&arch=ppc64el&ver=1.2.0-5&stamp=1551092176&raw=0
[1] https://launchpad.net/ubuntu/+source/blktrace/1.2.0-5build1

Best regards,
Fukui

Bug#1069862: blktrace: FTBFS on ppc64el in Ubuntu (-O3?) due to wrong code analysis

2024-09-25 Thread Daichi Fukui

Hello Chris,
CC: Steve

Thank you for your response.

After reviewing the source code of dpkg, I now understand that the -O3
optimisation level is set by default for ppc64el in Ubuntu.
However, it appears that there is no code to change the optimisation level
based on CPU architecture in Debian.
Therefore, I believe this issue is specific to Ubuntu.

If there are no objections, we can close this issue.
I am happy to continue this discussion if you’d like.

Best regards,
Fukui

53 matches

Mail list logo