Re: Bug#994594: ITP: time-decode -- timestamp decoder and converter
Hello Jan, > Can you point out a resource, which explains how salsa, the CI-system > with its janitor-bot and the FTP-masters queue work hand in hand? > I couldn't find any good information on that until now. Let me see if I can help here; FTP-master: https://wiki.debian.org/Teams/FTPMaster https://ftp-master.debian.org/#intro https://ftp-master.debian.org/new.html (they are not processed in a FIFO manner BTW) Salsa: For Salsa in general, you can refer to Gitlab's docs (as Salsa is an instance of it), or to this link for how Debian operates it (though not very detailed): https://wiki.debian.org/Salsa/Doc Salsa-ci: Salsa-ci is in a way "just" the recipes to perform the tests we want, you can read their source code from here: https://salsa.debian.org/salsa-ci-team/pipeline Janitor: Janitor is a project on its own, which is slowly getting better integrated into our tools, you can read it more about it here: https://www.jelmer.uk/debian-janitor.html https://janitor.debian.net/about https://youtu.be/pqpvjw60I7s There's also a bunch of similar projects which I really like and you might too, some of them are: https://wiki.debian.org/Debuginfod https://trends.debian.net/ In general I would say we still have lots of room for improving and tidying up our docs (some things are still disconnected from each other). Hopefully what I sent you will help, feel free to ask more questions if you're looking for something specific. Alternatively, you can also start a thread on d-devel asking about this sort of thing (or on IRC). Sometimes it is also faster to just talk to someone to get the initial grasp of some things, so I'm available for a call if you prefer that option as well, I probably won't be able to get into much detail about these things but I can help. Cheers! -- Samuel Henrique
Re: Bug#994594: ITP: time-decode -- timestamp decoder and converter
Hello Samuel, thanks for the last minute catch and the upload! Happy, that time-decode is now in the new-queue to be processed by the FTP-masters. Can you point out a resource, which explains how salsa, the CI-system with its janitor-bot and the FTP-masters queue work hand in hand? I couldn't find any good information on that until now. Best regards Jan On 10/6/21 12:39 AM, Samuel Henrique wrote: Hello Jan, I spotted an issue on d/watch at the very last minute and fixed it myself to avoid the turnaround. The package is looking good and I have uploaded it for you! Thank you for your contributions !
Re: Bug#994594: ITP: time-decode -- timestamp decoder and converter
Hello Jan, I spotted an issue on d/watch at the very last minute and fixed it myself to avoid the turnaround. The package is looking good and I have uploaded it for you! Thank you for your contributions ! -- Samuel Henrique
Re: Bug#994594: ITP: time-decode -- timestamp decoder and converter
Hello Samuel, On 10/5/21 1:11 AM, Samuel Henrique wrote: I thought that uploader is the actual sponsor of the package, therefore I added myself as maintainer. With regards to permissions, there is no difference between Maintainer and Uploaders, but I believe there are a few small differences like the Maintainer being the one that receives emails when bugs are reported (maybe that's the only difference). Our policy says we must put the team in the Maintainer field and humans on Uploaders, as seen: on https://www.debian.org/doc/debian-policy/ch-binary.html#the-maintainer-of-a-package It's worth noting that the naming of those fields should not be misled with the idea of maintainer of the package; we say everybody in Maintainer + Uploaders is the maintainer of a package. Thanks for the clarification on this and providing the link. This should have been: Removed those swap files. It was a typo, I didn't want to sound rude in any way. No worries, it didn't sound rude but even if it did, I would assume good intentions :) That's reassuring. :) After incorporating the changes requested by you, I think the package is in a quite good shape already, don't you think so? I believe there's just one last thing before I can sponsor the upload, can you add the relevant Vcs-* fields and point to the repo under the team? I missed this one the last time as well. I added those fields in commit 2a2b080b. Looking forward to the upload. Thank you for your contributions! Thanks for your help! Best regards, Jan
Re: Bug#994594: ITP: time-decode -- timestamp decoder and converter
Hello Jan, > > 4) d/control: > > 4a) You can add the team as the Maintainer and move yourself to > > Uploader, if you'd like to keep the package under the team's umbrella. > > I thought that uploader is the actual sponsor of the package, therefore > I added myself as maintainer. With regards to permissions, there is no difference between Maintainer and Uploaders, but I believe there are a few small differences like the Maintainer being the one that receives emails when bugs are reported (maybe that's the only difference). Our policy says we must put the team in the Maintainer field and humans on Uploaders, as seen: on https://www.debian.org/doc/debian-policy/ch-binary.html#the-maintainer-of-a-package It's worth noting that the naming of those fields should not be misled with the idea of maintainer of the package; we say everybody in Maintainer + Uploaders is the maintainer of a package. > This should have been: Removed those swap files. > It was a typo, I didn't want to sound rude in any way. No worries, it didn't sound rude but even if it did, I would assume good intentions :) > After incorporating the changes requested by you, I think the package is > in a quite good shape already, don't you think so? I believe there's just one last thing before I can sponsor the upload, can you add the relevant Vcs-* fields and point to the repo under the team? Thank you for your contributions! -- Samuel Henrique
Re: Bug#994594: ITP: time-decode -- timestamp decoder and converter
Correction: On 10/4/21 9:24 PM, Jan Gru wrote: Remove those swap files, my bad, sorry! This should have been: Removed those swap files. It was a typo, I didn't want to sound rude in any way. Best regards, Jan
Re: Bug#994594: ITP: time-decode -- timestamp decoder and converter
Hello Samuel, On 10/3/21 8:51 PM, Samuel Henrique wrote: > Hello Jan, removing the ITP's email address from this reply. > >> Thank you for your offer to sponsor `time-decode`, Samuel. I worked on >> the package and want to ask for a review. The sources for the packaging >> process can be found here: >> >> https://salsa.debian.org/jgru/time-decode > > Cool, I have created the repo under the team's org and I gave you > maintainer permission until the end of 2022 [0]. Thank you for creating the repository! > > Allow me to suggest one thing which is usually helpful when reviewing > packages (both my own and somebody else's): You can setup salsa-ci[1] > to have a summary of some basic checks available to everyone. > I see you commited salsa-ci.yml, but maybe forgot to enable CI in your > project (or to trigger a build after doing so). Totally understandable, I activated the CI-pipeline, with the already present yml-file. > > I'll enumerate the findings of my review to make it easier to discuss > them, their order doesn't mean anything: > > 1) d/tests/*~: > I see you accidentally committed some vim temporary/swap files there, > you can remove all of them. Remove those swap files, my bad, sorry! > > 2) d/manpage/time-decode.1: > In the SYNOPSIS, only the first line of parameters is being > highlighted in bold, you need to add the .B marker at the start of > each line. Added .B markers. Looks far nicer now. > > 3) d/changelog: > The NMU issues lintian is complaining about are related to a few > things you'll have to fix: > 3a) The last changelog entry of a NEW package needs to start with "* > Initial release (Closes: #994594)", so I suggest you merge the last > two entries together. Merged. Originally I wanted to keep those two changelog entries, since I created several patches for version 3.1.1, which were incorporated by upstream, but this makes no sense, when the repo's content moves to the team-managed repository, I guess. > > 3b) Your name in the last entry is not matching what's in d/control, > so lintian thinks it's an NMU. I overlooked this slight deviation, thanks for pointing this out. > > 3c) The changelog entry for a NEW package doesn't have to contain > anything besides the "Initial release" message, sometimes we want to > add a few more things, especially if the packaging is based on another > distro, to show what has been changed. But in the case of the entries > you have there, they can be removed[3]. I removed those detailed bulletpoints. > > 4) d/control: > 4a) You can add the team as the Maintainer and move yourself to > Uploader, if you'd like to keep the package under the team's umbrella. I thought that uploader is the actual sponsor of the package, therefore I added myself as maintainer. > > 4b) Standards-Version can be bumped to 4.6.0 Both issues corrected. > > > 5) missing-build-dependency-for-dh-addon: > There's a recent lintian version that issues an Error for the above > finding, discussion is ongoing in the lintian's bug report, but > everything in pointing in the direction of this not being a real > issue: > https://bugs.debian.org/995498 I read the discussion and decided to add `:any`, so that the lintian-tests pass. If you want me to remove it, please let me know. > 6) file-without-copyright-information: > Lintian is complaining that the .gitignore file is not matched by any > entry in d/copyright, my suggestion is to follow the practice of using > the first entry in d/copyright to match all of the files "Files: *" > and then have following entries where you target the files that you > want to exclude from the catch-all case. This will avoid leaving files > unmatched, but you're free to explicitly list all the files if you > want to. Since the proposed approach is far cleaner, I remove the explicit file list and changed it to "Files: *" > >> I would be very glad, if you or another team member could conduct a >> thourough review and provide some feedback, so that the package might >> find its way in unstable's or testing's package sources eventually in >> the future. If there are any issues, please let me know. > > Great, I'm replying to this email with the review, please always feel > free to request a private review if you'd like. After incorporating the changes requested by you, I think the package is in a quite good shape already, don't you think so? > > It's good to have them in the team's list as the whole process is a > learning opportunity for everyone (myself included)[2], besides being > able to reuse some reviews when helping other people. > >> [0] `git clone https://salsa.debian.org/jgru/time-decode.git; cd >> time-decode; gbp buildpackage --git-debian-branch=debian/master >> --git-ignore-new --git-upstream-tree="upstream";` > > Just a tip here, if you clone with gbp clone, and you setup d/gbp.conf > the way we do for the team's packages, you just need a: > gbp clone https://salsa.debian.org/jgru/time-decode.git > cd time-decode && gbp
Re: Bug#994594: ITP: time-decode -- timestamp decoder and converter
I forgot one small thing 7) d/source/local-options: This file contains two commented out lines, I suggest removing them if you're not gonna need it. Keeping it is also fine as long as it's a conscious choice done by you (not accidentally left there), let me know if that's the case. Thanks, -- Samuel Henrique
Re: Bug#994594: ITP: time-decode -- timestamp decoder and converter
Hello Jan, removing the ITP's email address from this reply. > Thank you for your offer to sponsor `time-decode`, Samuel. I worked on > the package and want to ask for a review. The sources for the packaging > process can be found here: > > https://salsa.debian.org/jgru/time-decode Cool, I have created the repo under the team's org and I gave you maintainer permission until the end of 2022 [0]. > `time-decode`' can be built successfully by running the commands listed > in [0]. Furthermore, I created three autopackage-tests, which check the > functionality of the resulting package. Those can be run with the > command listed in [1]. > > The package seems to be lintian-clean, except for some warnings about > NMU-version numbering and a not forwarded manpage. Allow me to suggest one thing which is usually helpful when reviewing packages (both my own and somebody else's): You can setup salsa-ci[1] to have a summary of some basic checks available to everyone. I see you commited salsa-ci.yml, but maybe forgot to enable CI in your project (or to trigger a build after doing so). I'll enumerate the findings of my review to make it easier to discuss them, their order doesn't mean anything: 1) d/tests/*~: I see you accidentally committed some vim temporary/swap files there, you can remove all of them. 2) d/manpage/time-decode.1: In the SYNOPSIS, only the first line of parameters is being highlighted in bold, you need to add the .B marker at the start of each line. 3) d/changelog: The NMU issues lintian is complaining about are related to a few things you'll have to fix: 3a) The last changelog entry of a NEW package needs to start with "* Initial release (Closes: #994594)", so I suggest you merge the last two entries together. 3b) Your name in the last entry is not matching what's in d/control, so lintian thinks it's an NMU. 3c) The changelog entry for a NEW package doesn't have to contain anything besides the "Initial release" message, sometimes we want to add a few more things, especially if the packaging is based on another distro, to show what has been changed. But in the case of the entries you have there, they can be removed[3]. 4) d/control: 4a) You can add the team as the Maintainer and move yourself to Uploader, if you'd like to keep the package under the team's umbrella. 4b) Standards-Version can be bumped to 4.6.0 5) missing-build-dependency-for-dh-addon: There's a recent lintian version that issues an Error for the above finding, discussion is ongoing in the lintian's bug report, but everything in pointing in the direction of this not being a real issue: https://bugs.debian.org/995498 6) file-without-copyright-information: Lintian is complaining that the .gitignore file is not matched by any entry in d/copyright, my suggestion is to follow the practice of using the first entry in d/copyright to match all of the files "Files: *" and then have following entries where you target the files that you want to exclude from the catch-all case. This will avoid leaving files unmatched, but you're free to explicitly list all the files if you want to. > I would be very glad, if you or another team member could conduct a > thourough review and provide some feedback, so that the package might > find its way in unstable's or testing's package sources eventually in > the future. If there are any issues, please let me know. Great, I'm replying to this email with the review, please always feel free to request a private review if you'd like. It's good to have them in the team's list as the whole process is a learning opportunity for everyone (myself included)[2], besides being able to reuse some reviews when helping other people. > [0] `git clone https://salsa.debian.org/jgru/time-decode.git; cd > time-decode; gbp buildpackage --git-debian-branch=debian/master > --git-ignore-new --git-upstream-tree="upstream";` Just a tip here, if you clone with gbp clone, and you setup d/gbp.conf the way we do for the team's packages, you just need a: gbp clone https://salsa.debian.org/jgru/time-decode.git cd time-decode && gbp buildpackage The "--git-ignore-new" is not needed as this is a brand new clone, you probably got used to using it when you want to test-build ignoring uncommitted changes. I understand you probably already know all of this, but it's worth saying as I've seen other people getting bitten by it; I recommend you to be on the watch for this parameter confusing you when you see that the build fails due to some change you thought you had committed already. The packaging is in a good state, and the tests are much appreciated, feel free to push your next changes directly to the team's repo. Thank you for working on this package :) [0] As usual, if the permission expires before you receive broader permissions permanently, we can extend that. [1] https://salsa.debian.org/salsa-ci-team/pipeline#basic-use [2] And somebody else could also call out a mistake I could make in the review. [3] That is, unle
Re: Bug#994594: ITP: time-decode -- timestamp decoder and converter
Dear Samuel, dear pkg-security-team, Samuel Henrique writes: > > I can sponsor for you, just let me know when the package is ready for a > review (or if you need help with anything) :) > > Thank you > Thank you for your offer to sponsor `time-decode`, Samuel. I worked on the package and want to ask for a review. The sources for the packaging process can be found here: https://salsa.debian.org/jgru/time-decode `time-decode`' can be built successfully by running the commands listed in [0]. Furthermore, I created three autopackage-tests, which check the functionality of the resulting package. Those can be run with the command listed in [1]. The package seems to be lintian-clean, except for some warnings about NMU-version numbering and a not forwarded manpage. I would be very glad, if you or another team member could conduct a thourough review and provide some feedback, so that the package might find its way in unstable's or testing's package sources eventually in the future. If there are any issues, please let me know. Thank you already in advance for your help on this! Best regards Jan -- [0] `git clone https://salsa.debian.org/jgru/time-decode.git; cd time-decode; gbp buildpackage --git-debian-branch=debian/master --git-ignore-new --git-upstream-tree="upstream";` [1] Assuming your chroot's alias is UNRELEASED: `autopkgtest --debug -- schroot UNRELEASED`
Bug#994594: ITP: time-decode -- timestamp decoder and converter
> > Hello Jan, .** Maintainenace plan > I suggest to maintain time-decode inside the pkg-security-team's > repository on salsa, since most of the packages related to forensics > live there. However, I am looking for a sponsor for this package - > ideally a member of the pkg-security-team. > I can sponsor for you, just let me know when the package is ready for a review (or if you need help with anything) :) Thank you >
Bug#994594: ITP: time-decode -- timestamp decoder and converter
Package: wnpp Severity: wishlist Owner: Jan Gru X-Debbugs-Cc: debian-de...@lists.debian.org, debian-security-tools@lists.debian.org * Package name: time-decode Version : 3.1.1 Upstream Author : Corey Forman * URL : https://github.com/digitalsleuth/time_decode * License : MIT Programming Lang: Python Description : timestamp decoder and converter time-decode provides the functionality to decode various timestamps and UUIDs to aid digital forensics and incident response processes. The supported formats range from common ones, like Unix epochs, WebKit/Chrome timestamps and Microsoft's FILETIME to more exotic formats like LDAP/Active Directory timestamps and Metasploit payload UUIDs. In addition, even timestamps used by some social media services, like Twitter, are included. ** Relevance of the package In most DFIR investigations temporal information is particularly important. Analysts often stumble over various timestamps and need to convert and normalize them quickly. While toolkits like plaso can help with the normalization of logfiles in bulk, Debian's package archives lack tooling for the convenient conversion of single timestamps of either known or unknown format. Given this finding and my experience from using it, time-decode seems to be an valuable prospective package to round off Debian's collection of forensic tools. ** Maintainenace plan I suggest to maintain time-decode inside the pkg-security-team's repository on salsa, since most of the packages related to forensics live there. However, I am looking for a sponsor for this package - ideally a member of the pkg-security-team.
