Bug#1014850: O: python-imaplib2 -- Threaded Python IMAP4 client (Python 3)
Control: owner -1 ! Control: retitle -1 "ITA: python-imaplib2 -- Threaded Python IMAP4 client (Python 3)" -- On Wed, Jul 13, 2022 at 10:43:29AM +0300, Ilias Tsitsimpis wrote: > Package: wnpp > Severity: normal > X-Debbugs-Cc: Sudip Mukherjee , Ulises Vitulli > > Control: affects -1 src:python-imaplib2 > > I intend to orphan the python-imaplib2 package. Since this package is > used by OfflineIMAP, I have reached out to Sudip Mukherjee (CC-ed) who > is willing to adopt this package (thank you Sudip). Thanks Ilias for maintaining this package for so many years. -- Regards Sudip
Bug#1028532: license
The license information is not correct, so packaging this for Debian will be postponed until upstream fixes the copyright. An example from https://github.com/teddywlq/smifb2/blob/main/ddk750/ddk750_2d.c: * Copyright (c) 2007 by Silicon Motion, Inc. (SMI) * * All rights are reserved. Reproduction or in part is prohibited * without the written consent of the copyright owner.. -- Regards Sudip
Bug#1028532: copyright fixed
Upstream has fixed the copyright information. -- Regards Sudip
Bug#1043288: ITP: qad -- A simple, REST-API compliant daemon for automated testing
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-Cc: debian-de...@lists.debian.org, sudipm.mukher...@gmail.com * Package name: qad Version : 0.0~git20230710.75f9d50 Upstream Contact: James Thomas Scott Clarke * URL : https://gitlab.com/CodethinkLabs/qad/qad/ * License : GPL and MIT Programming Lang: C and Perl Description : A simple, REST-API compliant daemon for automated testing This is a simple, REST-API compliant daemon which makes automated testing on hardware possible by removing the need for physical intervention as Q.A.D allows inputs to be injected via http/https requests. This both eliminates the need to physically interact with the rig and allows for tasks to be carried out entirely automatically. Q.A.D. can also take a screenshot and send it back to invoker. It can be integrated with openQA for automated testing. I use it as part of my $dayjob and will maintain it. -- Regards Sudip
Bug#1028532: ITP: smifb2 -- SiliconMotion SM750/SM768 Graphics PCI-E DRM Driver
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-Cc: debian-de...@lists.debian.org, sudipm.mukher...@gmail.com * Package name: smifb2 Version : 2.2.1 Upstream Author : Teddy Wang * URL : https://github.com/teddywlq/smifb2 * License : GPLv2 Programming Lang: C Description : SiliconMotion SM750/SM768 Graphics PCI-E DRM Driver SM768 is high performance graphics processor which provides dual display channels and supports multiple output interfaces, including HDMI, DisplayPort, DVI, VGA, LVDS and digital interfaces. SM768 has 128-bit graphics engine to accelerate graphics displays and provides color space conversion and scaling features. Display resolution supports up to 4K UHD (3840x2160@30p) or 2K/Full HD@60p. SM768 supports H.264/MJPEG hardware video decoding. . SM750, Dual Display Graphics Chip is a PCI Express 2D multimedia mobile display controller device providing video and 2D capability to the embedded industry in a 265-pin BGA package. SM750 framebuffer driver is available in the mainline kernel but the drm driver is not in the mainline kernel yet. This driver using dkms will be a combined drm driver for SM750 and SM768. The work for upstreaming the drm driver to mainline kernel is ongoing which is the final goal. I can maintain this package. -- Regards Sudip
Bug#1030196: RFP: libzbd Zoned Block device Manipulation library and tools
Control: close -1 -- Hi Tommy, On Wed, Feb 01, 2023 at 12:59:09PM +0900, Tommy McGee wrote: > > Package: wnnp > Severity: wishlist > > * Package name: libzbd > * Version : 2.0.4 > * URL :https://github.com/westerndigitalcorporation/libzbd > * License : GPL > Programming Language: C > Description :libzbd is a library providing functions > simplifying access to zoned block device information and the > execution of zone management operations. libzbd is already in Debian - https://tracker.debian.org/pkg/libzbd -- Regards Sudip
Bug#1032323: ITP: moulin -- A meta build system capable of building multiple images at once.
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-Cc: debian-de...@lists.debian.org, sudipm.mukher...@gmail.com * Package name: moulin Version : 0.0~git20230227.1630f49 Upstream Author : many * URL : https://github.com/xen-troops/moulin * License : Apache Programming Lang: Python Description : A meta build system capable of building multiple images at once. Main purpose of moulin is to build complex images for embedded devices. Imagine that you are running hypervisor (like Xen or KVM) on your device and you want to build multiple VM images with one simple command. moulin is made exactly for this task. As part of my role in Elisa (https://elisa.tech/) I had to use moulin, but being a Debian user I did not like installing moulin from their git. So, this ITP. I can maintain it under the umbrella of Debian Python team. -- Regards Sudip
Bug#1056209: ITP: authselect -- Configures authentication and identity sources from supported profiles
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-Cc: debian-de...@lists.debian.org, sudipm.mukher...@gmail.com * Package name: authselect Version : 1.4.3 Upstream Contact: Pavel Březina . * URL : https://github.com/authselect/authselect/ * License : GPL-3.0 Programming Lang: C Description : Authselect is a tool to select system authentication and identity sources from a list of supported profiles Authselect is designed to be a replacement for authconfig but it takes a different approach to configure the system. Instead of letting the administrator build the PAM stack with a tool (which may potentially end up with a broken configuration), it would ship several tested stacks (profiles) that solve a use-case and are well tested and supported. At the same time, some obsolete features of authconfig are not supported by authselect. -- Regards Sudip
Bug#1053729: RFP: SAIL image decoding library
Hi Andrius, On Wed, Oct 18, 2023 at 08:38:52AM +0300, Andrius Merkys wrote: > Hi Dmitry, > > On 2023-10-17 16:25, Dmitry Baryshev wrote: > > > Does it produce desired Debian packages? > > > > I've just pushed a couple of fixes to the Debian rules. I'm able to > > build packages on LUbuntu 23.04. Maybe a couple of small fixes are still > > needed to build packages on Debian. So the recommended git sha to use is > > 4705cb4cf96. It's a release candidate and ready to use in client > > applications. > > > OK, makes sense. > > Since this is an image decoding library, my personal opinion is that it > would better fit the scope of Debian Multimedia Team instead of Debian > Science Team. Just wanted to check if you are planning to package this. Its still a RFP so I guess not, but still want to confirm. If you are not packaging this then I can take it up. -- Regards Sudip
Bug#1027756: RFP: vncdotool -- command line VNC client
Control: retitle -1 ITP: vncdotool -- command line VNC client Control: owner -1 ! -- I was looking for something to use with VNC for a personal project I was planning and found about vncdotool. Initial test showed it will work perfectly for me. -- Regards Sudip
Bug#983384: change owner
control: owner -1 Christoph Berg -- Moving owner to Christoph as discussed in the thread at https://lists.debian.org/debian-java/2021/05/msg00017.html. -- Regards Sudip
Bug#992027: ITP: openqa-client -- Python API to access openQA server
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-Cc: debian-de...@lists.debian.org, sudipm.mukher...@gmail.com, Philip Hands * Package name: openqa-client Version : 4.1.2 * URL : https://github.com/os-autoinst/openQA-python-client * License : GPL-2.0 Programming Lang: Python Description : Python API to access openQA server This is a client for the openQA API, based on requests. The API always returns JSON responses; this client's request functions parse the response before returning it. There is already another RFP for openqa server and the client, #840253 and I think Philip Hands is already working on that and has made a great job at openqa.debian.net. This package is only the python api to communicate with the openqa server. I do use it as part of my role in https://openqa.qa.codethink.co.uk/. Added Cc to Philip Hands also and if he is planning to add Python API as part of his implementation then I can close this and wait for him. -- Regards Sudip
Bug#992027: ITP: openqa-client -- Python API to access openQA server
Hi Philip, On Tue, Aug 10, 2021 at 10:39 PM Philip Hands wrote: > > Sudip Mukherjee writes: > > > Package: wnpp > > Severity: wishlist > > Owner: Sudip Mukherjee > > X-Debbugs-Cc: debian-de...@lists.debian.org, sudipm.mukher...@gmail.com, > > Philip Hands > > > > * Package name: openqa-client > > Version : 4.1.2 > > * URL : https://github.com/os-autoinst/openQA-python-client > > * License : GPL-2.0 > > Programming Lang: Python > > Description : Python API to access openQA server > > > > > > Added Cc to Philip Hands also and if he is planning to add Python API > > as part of his implementation then I can close this and wait for him. > > At present my packaging of openqa (which I hope to get into a state fit > to upload very soon -- a few lintian warnings need addressing) already > produces a package called openqa-client, which includes the scripts such > as openqa-cli and openqa-client. > > BTW You can see the current state of play here: > > https://salsa.debian.org/philh/openqa Yes, I have seen that. Please do let me know if you need any help with that. Though I have zero perl knowledge. :( > > The openqa-client script is obsolescent, so renaming that package to > be openqa-cli would make sense anyway, since that is the script to use > these days, but I think calling what seems to be a python library simply > 'openqa-client' would be a bit confusing. Yes, I agree. > > Wouldn't it make sense to put a 'python' in the package name? Will rename this to python-openqa-client. > > I'm not really a python programmer, so probably not the person to > package this, but would be pleased to see it available in Debian, and am > very happy help where I can. And I started using the python client after seeing that the openqa-client is based on perl. :) Dont worry, I can package it and maintain it under the umbrella of Debian Python team. Thanks for your work in packaging openqa and for openqa.debian.net. Regards Sudip
Bug#1009899: ITP: genimage -- The Image Creation Tool
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-Cc: debian-de...@lists.debian.org, sudipm.mukher...@gmail.com * Package name: genimage Version : v15 Upstream Author : many * URL : https://github.com/pengutronix/genimage * License : GPL-2.0 Programming Lang: C Description : The Image Creation Tool genimage is a tool to generate multiple filesystem and flash/disk images from a given root filesystem tree. It also supports creating flash/disk images out of different file-system images and files. I am using it as part of my current project in $dayjob. Its a necessary tool to create images with u-boot. I can maintain it. -- Regards Sudip
Bug#1004238:
Hi Nilson, On Fri, Jul 14, 2023 at 01:12:03AM +, Nilson Silva wrote: > Hello > > Konstantinos Margaritis! > > Seeing that his package has the adoption request, I decided to adopt him. Can > you upload it when I'm done? If you are still interested in adopting it, I will suggest go for it. Or else I can take it up with "Debian Python Team" as maintainer. This package needs to be updated to the latest version urgently. -- Regards Sudip
Bug#1064957: bpftop
All dependencies have been packaged under Debian Rust team. bpftop_0.5.2 is now in the NEW queue. -- Regards Sudip
Bug#962686: Bug#974967: RFS: s2geometry/0.9.0-1 [ITP] -- Computational geometry and spatial indexing on the sphere
On Tue, Nov 17, 2020 at 11:54 AM Emmanuel Arias wrote: > > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "s2geometry": > > * Package name: s2geometry >Version : 0.9.0-1 >Upstream Author : Google > * URL : https://github.com/google/s2geometry > * License : Apache-2.0, BSD-3-Clause > * Vcs : https://salsa.debian.org/eamanu/s2geometry >Section : libs > > It builds those binary packages: > > s2geometry - Computational geometry and spatial indexing on the sphere just fyi, a fork of this (which has some other fixes) is already in Debian. https://tracker.debian.org/pkg/s2-geometry-library -- Regards Sudip
Bug#976425: ITP: libtracefs -- API to access the kernel tracefs directory
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee * Package name: libtracefs Version : 0 Upstream Author : Steven Rostedt * URL : https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git * License : LGPL-2.1 Programming Lang: C Description : API to access the kernel tracefs directory It had been part of tracecmd but has been split into its own repo. The announcement mail was at https://lore.kernel.org/lkml/20201120200314.21efa...@oasis.local.home/ Note: This is not needed for Bullseye and so I am only planning to upload to experimental for now. -- Regards Sudip
Bug#977914:
Control: tags 977914 + pending -- Uploaded to NEW queue. -- Regards Sudip
Bug#978973: RFP: gnome-activity-journal -- Activity Journal for the GNOME desktop environment ( Powered by Zeitgeist 1.0.3 )
Control: retitle -1 ITP: gnome-activity-journal -- Activity Journal for the GNOME desktop environment Control: owner -1 ! -- Hi crvi, On Fri, Jan 01, 2021 at 08:07:44PM +0530, crvi wrote: > Package: wnpp > Severity: wishlist > X-Debbugs-Cc: crvi...@gmail.com > > * Package name: gnome-activity-journal > Version : 1.0.0 It seems you have bumped the version but have not created any tag. Can you please tag the version. -- Regards Sudip
Bug#978973: RFP: gnome-activity-journal -- Activity Journal for the GNOME desktop environment ( Powered by Zeitgeist 1.0.3 )
On Thu, Jan 7, 2021 at 10:29 AM crvi c wrote: > > Hi Sudip, > > I've a couple of pending changes. I'll tag the version shortly. Thanks. I will start with packaging and upload. It needs to cross the NEW queue which takes time. I can update the package after you have done your changes. -- Regards Sudip
Bug#978973:
Control: tags -1 pending -- Uploaded to NEW for experimental. Will upload to unstable after it has passed NEW queue and upstream has tagged the new 1.0.0 version. -- Regards Sudip
Bug#978973: RFP: gnome-activity-journal -- Activity Journal for the GNOME desktop environment ( Powered by Zeitgeist 1.0.3 )
On Wed, Jan 27, 2021 at 3:49 AM crvi c wrote: > > Hi Sudip, > > I'll be tagging the package this weekend. If you've any queries, please let > me know. Sure. The previous upload is still in NEW queue at https://ftp-master.debian.org/new/gnome-activity-journal_0.9.0.88.g69f48b1-1.html and I will upload your tagged version after it has been approved from NEW. -- Regards Sudip
Bug#985939: ITP: wiredpanda -- logic circuits simulator
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: wiredpanda Version : v3.0.0 Upstream Author : Davi Morales, Fábio Cappabianco, Lucas Lellis, Rodrigo Torres and Vinícius Miguel * URL : https://github.com/GIBIS-UNIFESP/wiRedPanda * License : GPL-3.0 Programming Lang: C++ Description : Logic circuits simulator WiRed Panda is a free software designed to help students to learn about logic circuits and simulate them in an easy and friendly way. The main features of the software are: * works on Windows, macOS and Linux; * Real time logic simulation; * User-friendly interface; * It's intuitive and easy to use; * Export your work as an image or a PDF. -- Regards Sudip
Bug#986288: poke in Debian
Hi Hilko, poke has already been packaged. Is it something different? https://tracker.debian.org/pkg/poke -- Regards Sudip
Bug#986347: ITP: kernelshark -- Utilities for graphically analyzing function tracing in the kernel
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: kernelshark Version : v1.3 Upstream Author : Steven Rostedt Yordan Karadzhov (VMware) * URL : https://git.kernel.org/pub/scm/utils/trace-cmd/kernel-shark.git/ * License : GPL-2 and LGPL-2.1 Programming Lang: C++ Description : Utilities for graphically analyzing function tracing in the kernel. Data for analysis may be generated by the trace-cmd utility. kernelshark is already available in Debian as part of trace-cmd but upstream has now decided to move kernelshark to its own repo at: https://git.kernel.org/pub/scm/utils/trace-cmd/kernel-shark.git and the announcement is at https://git.kernel.org/pub/scm/utils/trace-cmd/trace-cmd.git/tag/?h=trace-cmd-v2.9.2 -- Regards Sudip
Bug#986288: poke in Debian
On Fri, Apr 2, 2021 at 4:57 PM Hilko Bengen wrote: > > * Sudip Mukherjee: > > > poke has already been packaged. Is it something different? > > https://tracker.debian.org/pkg/poke > > Oh, I hadn't noticed because it was only uploaded to experimental. Will > contact the packager. I think that is because it is recommended not to upload anything to unstable which is not meant for Bullseye. -- Regards Sudip
Bug#964105: RFH: album-data -- themes, plugins and translations for album
On Wed, Jul 01, 2020 at 12:22:59PM -0700, David Ljung Madison wrote: > Package: wnpp > Severity: important > > The package 'album-data' is a data package for 'album' > > I am the author of album and album-data. > > It has an incorrect dependency on "libjs-swfobject" which I recently > noticed because, since libjs-swfobject has been removed, has caused > album-data to also be removed. > > album-data does not depend on libjs-swfobject. fyi, I have done a NMU and removed this dependency. -- Regards Sudip
Bug#968237: ITP: auctex-12 -- AUCTeX version 12, LaTeX environment for Emacs
Hi Itaï, On Tue, Aug 11, 2020 at 1:54 PM Itaï BEN YAACOV wrote: > > Package: wnpp > Severity: wishlist > Owner: Itaï BEN YAACOV > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: auctex-12 > Version : 12.2 > Upstream Author : GNU Project > * URL : https://www.gnu.org/software/auctex/ > * License : GPL v3 > Description : AUCTeX version 12, LaTeX environment for Emacs > > Hello, > > This is not truly an ITP but a request for guidance. ITP is truly not the right one for this. And this should be merged with #896844. > auctex v11.91 already exists in Debian, and has not been updated since > 2018 despite bug reports requesting that. Specifically, the preview-latex > feature no longer works due to changes in ghostscript, which is solved in > upstream. Looks like there are multiple users who are saying its unusable. > > The relevant bug #896844 was filed in Apr 2018, the maintainer said "I'll > work on it" and nothing ever happened since, depite numerous follow-ups to > the bug. I tried to contact him directly in early 2020, getting no useful > reply, except that he considers that he is still maintaining the package. > > I am not a Debian developper, but am able to package (in fact I have packaged > auctex v12 for personal use). > > What should / can be done in this case ? You have auctex/12.2-0.4 which doesn't make sense for Debian. So, create a package for auctex/12.2-0.1, also add the fix for #951973 to it. And then take a look at https://mentors.debian.net/ about how to upload and find a sponsor. -- Regards Sudip
Bug#968834: ITP: screeninfo -- Fetch location and size of physical screens
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee * Package name: screeninfo Version : 0.6.5 Upstream Author : Marcin Kurczewski * URL : https://github.com/rr-/screeninfo * License : MIT and BSD-3-clause Programming Lang: Python Description : Fetch location and size of physical screens Python library to fetch location and size of physical screens. It can also detect screen sizes in a multi-monitor setup. iiuc, Tkinter can also detect the size of the display but will fail when multiple displays are connected. The latest version of 'topplot' is using screeninfo to detect multiple displays, and so I will need 'screeninfo' to update 'topplot'. I can maintain this under the umbrella of Debian Python Modules Team. -- Regards Sudip
Bug#968834: ITP: screeninfo -- Fetch location and size of physical screens
On Fri, Aug 21, 2020 at 11:33:54PM +0100, Sudip Mukherjee wrote: > Package: wnpp > Severity: wishlist > Owner: Sudip Mukherjee > > * Package name: screeninfo > Version : 0.6.5 > Upstream Author : Marcin Kurczewski > * URL : https://github.com/rr-/screeninfo > * License : MIT and BSD-3-clause correction: Its MIT license only, have clarified it with upstream. -- Regards Sudip
Bug#968959: ITP: fling -- Terrible program for flinging files and pipes over a network
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee * Package name: fling Version : v1.0 Upstream Author : Rob Kendrick * URL : https://github.com/rjek/fling * License : MIT Programming Lang: C Description : Transfer data from stdin over network to destination quickly fling transfers data quickly over a trusted network. It does not encrypt the data. It tries to avoid copying data between kernel and userspace where it can; We can see the most improvement over other tools like netcat on systems with low memory bandwidth. fling is extremely Linux-specific, as almost all the optimisations used beyond what other similar tools do are non-portable. -- Regards Sudip
Bug#882640: Uploaded dm-zoned-tools package
Hi Andrew, On Tue, Dec 18, 2018 at 05:47:23PM +1100, Andrew Worsley wrote: > I saw your talk where you asked for a packaging of the dmzadm tool. > > I am not a debian developer but am aiming to try and become one. > Anyway I created a debian package (using deb_make) and built it and > uploaded it to my debian mentor account This again came up in Ben's talk today and I was wondering what happened after you uploaded your package to mentors. I am unable to find it anywhere. Also, the latest upstream version is v1.1.0 now. -- Regards Sudip
Bug#969021: RFP: getmail6 -- Mail retriever with support for POP3, IMAP4 and SDPS
X-Debbugs-Cc: Osamu Aoki On Wed, Aug 26, 2020 at 04:51:33PM +0800, Dan Jacobson wrote: > Package: wnpp > Severity: wishlist > X-Debbugs-Cc: 968...@bugs.debian.org > > * Package name: getmail6 > Version : 6.4 > Upstream Author : roland.punta...@gmail.com > * URL : https://github.com/getmail6 > * License : GNU GPL version 2 > Programming Lang: Python > Description : Mail retriever with support for POP3, IMAP4 and SDPS > > getmail is intended as a simple replacement for fetchmail. It retrieves mail > (either all messages, or only unread messages) from one or more > POP3/IMAP4/SDPS servers for one or more email accounts, and reliably > delivers into a qmail-style Maildir, mbox file or to a command (pipe > delivery) like maildrop or procmail, specified on a per-account basis. > getmail also has support for domain (multidrop) mailboxes. > > The current getmail package only works with python2. > > But debian has moved to python3. > > Therefore getmail6, which is designed to work with python3, should be > added to Debian. > > No need to update the current debian getmail package. > Just somebody should maintain a new independent getmail6 pacakge. This getmail6 will install files like: /usr/bin/getmail /usr/bin/getmail_fetch /usr/bin/getmail_mbox /usr/bin/getmail_maildir /usr/bin/getmail-gmail-xoauth-tokens /usr/lib/python3/dist-packages/getmailcore which are also installed by getmail. So, I guess the best possible way might be if getmail maintainer updates to this source, else I can package getmail6 with a "Breaks: getmail". -- Regards Sudip
Bug#969107: ITP: gnome-shell-extension-panel-osd -- Configure the place where notifications are shown
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee * Package name: gnome-shell-extension-panel-osd Version : 1.0-46-g28656ac Upstream Author : Berend De Schouwer Jens Lody * URL : https://gitlab.com/jenslody/gnome-shell-extension-panel-osd/ * License : GPL-3+ Programming Lang: JavaScript Description : Configure the place where notifications are shown gnome-shell-extension-panel-osd is an extension to show the notification messages at any (configurable) place on the (primary) monitor. I use this extension on my personal laptop as I found it very disturbing to get all my irc notification at the default location (top-centre). Now, thanks to this extension I can define where I want my notifications. -- Regards Sudip
Bug#969021: RFP: getmail6 -- Mail retriever with support for POP3, IMAP4 and SDPS
On Thu, Aug 27, 2020 at 7:37 PM 積丹尼 Dan Jacobson wrote: > > Actually I am guessing the current maintainer isn't reading these > emails, and you Sudip, should consider non-maintainer uploads or steps > on how to take over the project altogether from non-active maintainers. Thats package hijacking. And Osamu is an active developer. So, I can't do that. And besides, We are all at debconf now so please expect delayed reply. -- Regards Sudip
Bug#969021: RFP: getmail6 -- Mail retriever with support for POP3, IMAP4 and SDPS
On Sun, Aug 30, 2020 at 5:24 AM Osamu Aoki wrote: > > On Thu, 2020-08-27 at 19:42 +0100, Sudip Mukherjee wrote: > > On Thu, Aug 27, 2020 at 7:37 PM 積丹尼 Dan Jacobson > > wrote: > > > Actually I am guessing the current maintainer isn't reading these > > > emails, and you Sudip, should consider non-maintainer uploads or > > > steps > > > on how to take over the project altogether from non-active > > > maintainers. > > > > Thats package hijacking. And Osamu is an active developer. So, I > > can't do that. > > And besides, We are all at debconf now so please expect delayed > > reply. > > Sudip > > You can hijack if you are competent DM. I am happy with this. iiuc, getmail6 is a fork of getmail and from the getmail mailing list it appears that Charles (upstream of getmail) is also working on python3 version of getmail which will be ready sometime in the future. Keeping that in mind I will suggest that we keep getmail and getmail6 separate. I have mailed upstream of getmail6 and will need to ask him about few of my doubts regarding copyright, after I get the reply I will move it to ITP, unless someone else wants to package it before me. -- Regards Sudip
Bug#969021: ITP: getmail6 -- Mail retriever with support for POP3, IMAP4 and SDPS
Control: tags -1 pending -- It is now in the NEW queue waiting for review by the ftp masters. -- Regards Sudip
Bug#968194: Prerelease getmail6 .deb
On Wed, Sep 9, 2020 at 11:56 PM 積丹尼 Dan Jacobson wrote: > > I can test a Prerelease getmail6 .deb for you when you make one. Thanks. Its already in the NEW queue, and sent you the .deb file in another email. Thanks again for testing. -- Regards Sudip
Bug#943552: update
Control: tags -1 help -- All the dependencies are now packaged and I can now build tracecompass. But when I try to use the launcher to launch the built application I get errors. I have attached the error log. Will appreciate any help or pointers to fix the problem. -- Regards Sudip config.ini org.eclipse.equinox.simpleconfigurator Install location: file:/home/sudip/trace-compass/ Configuration file: file:/home/sudip/trace-compass/configuration/config.ini loaded Configuration location: file:/home/sudip/trace-compass/configuration/ Framework located: file:/home/sudip/trace-compass/plugins/eclipse-osgi-3.15.300.jar Loading extension: reference:file:eclipse-osgi-compatibility-state-1.1.800.jar eclipse.properties not found Framework classpath: file:/home/sudip/trace-compass/plugins/eclipse-osgi-3.15.300.jar file:/home/sudip/trace-compass/plugins/ file:/home/sudip/trace-compass/plugins/eclipse-osgi-compatibility-state-1.1.800.jar Debug options: file:/home/sudip/.options not found Time to load bundles: 37 Starting application: 1590 !SESSION 2020-09-07 20:36:38.848 --- eclipse.buildId=unknown java.version=11.0.8 java.vendor=Debian BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_GB Command-line arguments: -consolelog -clean -debug -data @noDefault !ENTRY org.eclipse.e4.ui.workbench 4 0 2020-09-07 20:36:41.208 !MESSAGE Unable to create class 'org.eclipse.e4.ui.internal.workbench.addons.CommandProcessingAddon' from bundle '43' !STACK 0 org.eclipse.e4.core.di.InjectionException: Unable to process "CommandProcessingAddon.broker": no actual value was found for the argument "IEventBroker". at org.eclipse.e4.core.internal.di.InjectorImpl.reportUnresolvedArgument(InjectorImpl.java:482) at org.eclipse.e4.core.internal.di.InjectorImpl.resolveRequestorArgs(InjectorImpl.java:473) at org.eclipse.e4.core.internal.di.InjectorImpl.internalInject(InjectorImpl.java:129) at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:405) at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:346) at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:227) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:94) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:60) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:37) at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:289) at org.eclipse.ui.internal.Workbench.lambda$createAndRunWorkbench$1(Workbench.java:579) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:557) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:154) at org.eclipse.tracecompass.internal.tracing.rcp.ui.Application.start(Application.java:95) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:137) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:107) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:657) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:594) at org.eclipse.equinox.launcher.Main.run(Main.java:1447) at org.eclipse.equinox.launcher.Main.main(Main.java:1420) !ENTRY org.eclipse.e4.ui.workbench 4 0 2020-09-07 20:36:41.211 !MESSAGE Unable to create class 'org.eclipse.e4.ui.internal.workbench.addons.ContextProcessingAddon' from bundle '43' !STACK 0 org.eclipse.e4.core.di.InjectionException: Unable to process "ContextProcessingAddon.broker": no actual value was found for the argument "IEventBroker". at org.eclipse.e4.core.internal.di.InjectorImpl.reportUnresolvedArgument(InjectorImpl.java:482) at org.eclipse.e4.core.internal.di.InjectorImpl.resolveRequestorArgs(InjectorImpl.java:473) at org.eclipse.e4.core.internal.di.InjectorImpl.internalInject(InjectorImpl.java:129) at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:405) at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:346) at org.eclipse.e4.core.contexts.ContextInject
Bug#760485: Jitsi meet packaging
On Sun, Sep 27, 2020 at 11:49 AM Mathias Behrle wrote: > > * Fioddor Superconcentrado: " Jitsi meet packaging" (Sun, 27 Sep 2020 12:10:17 > +0200): > > Hi, > > > As user I'm interested in having Jitsi Meet available in FreedomBox. Since > > it is a pure Debian blend we need an official Debian package. So I'm > > considering to step forward and take over it. > > > > But > > 1) I've never ever packaged any Debian package. > > 2) According to this bug, previous attempts have failed, so I guess there > > are reasons for that. > > > > So, any guidance would be welcome. > > > > I've seen that upstream already provides a .deb file. I guess it needs > > further debianisation to be accepted in the archive. > > At least the original owner of #760485 seems to be the same person that is > currently active and in Uploaders at > https://github.com/jitsi/jitsi-meet/blob/master/debian/control > > Best will be to ask him directly why he didn't push to get the packages into > Debian main. I have added him on CC. I had the same interest and mailed Damencho around March and he mentioned about lack of resources to maintain jitsi in Debian as its a lot of work. -- Regards Sudip
Bug#760485: Jitsi meet packaging
On Sun, Sep 27, 2020 at 3:41 PM Damian Minkov wrote: > > Hi all, > > Thanks for the interest in the project. There are a few concerns I have, > first is that we do not have the resources to maintain this. > > Nowadays the video bridge had been rewritten and has fewer dependencies. I'm > also not sure about the state of Kotlin, is it yet in the repos, cause it is > one of the dependencies? Not yet. :( https://bugs.debian.org/892842 -- Regards Sudip
Bug#960423: unblock
Control: unblock 943552 by -1 -- takari-polyglot-maven is needed to enable pomless tycho builds, so it will be needed to enable that feature in tycho. I have now generated the pom files manually for tracecompass, so its not blocking that anymore. -- Regards Sudip
Bug#970623: RFA: offlineimap -- IMAP/Maildir synchronization and reader support
Hi Ilias, On Sun, Sep 20, 2020 at 09:13:57AM +0300, Ilias Tsitsimpis wrote: > Package: wnpp > Severity: normal > > OfflineIMAP is an IMAP/Maildir synchronization tool. Currently, > OfflineIMAP is Python 2 only, but there is a Python 3 port underway. > Unfortunately, I do not have the time to help with this port, so I > request an adopter. I use offlineimap and will hate to see it go away with Bullseye. I think the Python3 port is at https://github.com/OfflineIMAP/offlineimap3. I can adopt it, but just wanted to know what will you suggest - update the existing offlineimap with the new one or package the new one as new 'offlineimap3' ? -- Regards Sudip
Bug#970623: (no subject)
Control: retitle -1 ITA: offlineimap -- IMAP/Maildir synchronization and reader support owner -1 ! -- I will update the package to python3 port after testing it in my setup. -- Regards Sudip
Bug#972512: ITP: offlineimap3 -- IMAP/Maildir synchronization and reader support
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee * Package name: offlineimap3 Version : Upstream Author : * URL : https://github.com/OfflineIMAP/offlineimap3 * License : GPL-2+ with OpenSSL exception Programming Lang: Python Description : IMAP/Maildir synchronization and reader support This is the python3 port of OfflineIMAP. As discussed in https://github.com/OfflineIMAP/offlineimap3/issues/10 upstream is asking to treat offlineimap and offlineimap3 separately and it can be packaged after upstream has done its first official release. -- Regards Sudip
Bug#972512: ITP: offlineimap3 -- IMAP/Maildir synchronization and reader support
On Mon, Oct 19, 2020 at 8:25 PM Emilio Pozuelo Monfort wrote: > > On 19/10/2020 18:54, Sudip Mukherjee wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Sudip Mukherjee > > > > * Package name: offlineimap3 > >Version : > >Upstream Author : > > * URL : https://github.com/OfflineIMAP/offlineimap3 > > * License : GPL-2+ with OpenSSL exception > >Programming Lang: Python > >Description : IMAP/Maildir synchronization and reader support > > > > This is the python3 port of OfflineIMAP. > > > > As discussed in https://github.com/OfflineIMAP/offlineimap3/issues/10 > > upstream is asking to treat offlineimap and offlineimap3 separately and > > it can be packaged after upstream has done its first official release. > > What's the point of packaging this under a new name, if the old version is > going > to be removed? If they aren't meant to be coinstalled, and specially if the > application interface is compatible with the old version, then there's little > benefit in renaming it. The language (version) is just an implementation > detail > in this case. Totally agree. Discussion about this was ongoing at https://github.com/OfflineIMAP/offlineimap3/issues/10 and also at #debian-mentors. I will be uploading offlineimap (python3 version) to experimental for more testing. And, if upstream does not have any specific concern for https://github.com/OfflineIMAP/offlineimap3/issues/10#issuecomment-712683745 then I will either close this ITP or reuse this for something else. -- Regards Sudip
Bug#971924: RFP: ironseed -- science-fiction exploration/strategy adventure game in space
Hi Matija, On Fri, Oct 09, 2020 at 10:46:34PM +0200, Matija Nalis wrote: > Package: wnpp > Severity: wishlist > > * Package name: ironseed > Version : 0.2.4 > Upstream Author : Matija Nalis > * URL : https://github.com/mnalis/ironseed_fpc > * License : GPLv3 > Programming Lang: Pascal > Description : science-fiction exploration/strategy adventure game in > space > > > If more work is required on it, I'm willing to do it, if someone will > point me in right direction. But I am not DD and thus cannot do it all > the way through myself. > > If I get Debian lingo right, I'm looking for a sponsor. You should retitle this bug as "ITP" and then look at https://mentors.debian.net/intro-maintainers/ Your package will need some minor work, like version etc. And also it fails to build for me with: ctags c_utils.c cargtool.pas combat.pas comm.pas comm2.pas crew2.pas crewgen.pas crewinfo.pas crewtick.pas data.pas display.pas ending.pas explore.pas gmouse.pas heapchk.pas info.pas intro.pas is.pas journey.pas main.pas modplay.pas saveload.pas starter.pas usecode.pas utils.pas utils2.pas utils_.pas version.pas weird.pas make[2]: ctags: No such file or directory make[2]: *** [Makefile:127: tags] Error 127 make[2]: Leaving directory '/<>' dh_auto_build: error: make -j1 "INSTALL=install --strip-program=true" prefix=/usr returned exit code 2 make[1]: *** [debian/rules:17: override_dh_auto_build] Error 25 make[1]: Leaving directory '/<>' make: *** [debian/rules:11: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 -- Regards Sudip
Bug#972512: ITP: offlineimap3 -- IMAP/Maildir synchronization and reader support
On Tue, Oct 20, 2020 at 10:53:44AM +0100, Sudip Mukherjee wrote: > On Mon, Oct 19, 2020 at 8:25 PM Emilio Pozuelo Monfort > wrote: > > > > On 19/10/2020 18:54, Sudip Mukherjee wrote: > > > Package: wnpp > > > Severity: wishlist > > > Owner: Sudip Mukherjee > > > > > > * Package name: offlineimap3 > > And, if upstream does not have any specific concern for > https://github.com/OfflineIMAP/offlineimap3/issues/10#issuecomment-712683745 > then I will either close this ITP or reuse this for something else. Unfortunately it looks like we need to go for a separate package. :( -- Regards Sudip
Bug#972707: ITP: morfologik-stemming2 -- Finite state automaton and stemming engine library
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee * Package name: morfologik-stemming2 Version : 2.1.6 Upstream Author : Dawid Weiss, Marcin Miłkowski * URL : https://github.com/morfologik/morfologik-stemming * License : BSD 3-Clause Programming Lang: Java Description : Finite state automaton and stemming engine library Java based morfologik-stemming library provides the following fatures: . - Finite state automaton traversal routines for Jan Daciuk's FSA package. - A stemming engine for the Polish language built on top of FSA traversal. . The library may be used for other languages as well. Debian already has morfologik-stemming but updating it to v2.1.6 will break the build of lucene4.10 as there was an API change. Discussed at https://lists.debian.org/debian-java/2020/10/msg00022.html. I can maintain it under the umbrella of Java team. -- Regards Sudip
Bug#972790: ITP: rfc6555 -- Happy Eyeballs Algorithm described in RFC 6555 using Python
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee * Package name: rfc6555 Version : Upstream Author : Seth Michael Larson * URL : https://github.com/sethmlarson/rfc6555 * License : Apache-2.0 Programming Lang: Python Description : Happy Eyeballs Algorithm described in RFC 6555 using Python Provided with a single file and dead-simple API to allow easy vendoring and integration into other projects. The new offlineimap3 (Python3 fork of offlineimap) is using this rfc6555. There has been no official release yet and I have mailed upstream askig about it. I can maintain it under the umbrella of Python team. -- Regards Sudip
Bug#972376: confusion with License
I noticed a problem with the license and so https://github.com/BLumia/pineapple-pictures/issues/8 has been opened. -- Regards Sudip
Bug#972790: ITP: rfc6555 -- Happy Eyeballs Algorithm described in RFC 6555 using Python
On Fri, Oct 23, 2020 at 7:19 PM Gunnar Wolf wrote: > > Sudip Mukherjee dijo [Fri, Oct 23, 2020 at 06:25:26PM +0100]: > > Package: wnpp > > Severity: wishlist > > Owner: Sudip Mukherjee > > > > * Package name: rfc6555 > > Version : > > Upstream Author : Seth Michael Larson > > * URL : https://github.com/sethmlarson/rfc6555 > > (...) > > The new offlineimap3 (Python3 fork of offlineimap) is using this rfc6555. > > There has been no official release yet and I have mailed upstream askig > > about it. > > I can maintain it under the umbrella of Python team. > > I understand you are packaging something for which the author didn't > manage to choose a name, but you are _not_ packaging RFC 6555 (and you > cannot even include it, because RFCs are nonmodifiable by their > license and thus non-free in nature). Please help choose a name; > ideally, you can communicate with the author, and try to find a > suitable, meaningful human name for this! Thanks for pointing that out. Looking at "python-rfc3986" I guess I can change the package name of this one to "python-rfc6555". I will also open mail upstream about choosing a suitable name. -- Regards Sudip
Bug#972512:
Update: blocked on https://github.com/OfflineIMAP/offlineimap3/issues/12. -- Regards Sudip
Bug#972512:
Control: unblock -1 by 972790 -- Unblocking as the patch to remove python-rfc6555 dependency has been ported from offlineimap. The dependency can be added later. -- Regards Sudip
Bug#973045: ITP: geometry-common -- Geometry Utilities
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee * Package name: geometry-common Version : 1.0.2 Upstream Author : SgrAlpha * URL : https://github.com/io-sgr/geometry-common * License : Apache-2.0 Programming Lang: Java Description : Geometry Utilities This library is a simple JAVA / Android library that helps you transform coordinate between earth(WGS-84) and mars in China(GCJ-02). This is needed for s2-geometry-library java library. -- Regards Sudip
Bug#973047: Fwd: ITP: s2-geometry-library -- Java library for spherical math
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee * Package name: s2-geometry-library Version : 1.0.1 Upstream Author : many * URL : https://github.com/io-sgr/s2-geometry-library-java * License : Apache-2.0 Programming Lang: Java Description : Java library for spherical math The S2 Geometry Library is a spherical geometry library, very useful for manipulating regions on the sphere (commonly on Earth) and indexing geographic data. This the a fork from the original s2-geometry-library-java library by google. The latest lucene is using this library and will be needed for #970738. -- Regards Sudip
Bug#973054: ITP: s2-geometry-library -- Java library for spherical math
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee * Package name: s2-geometry-library Version : 1.0.1 Upstream Author : many * URL : https://github.com/io-sgr/s2-geometry-library-java * License : Apache-2.0 Programming Lang: Java Description : Java library for spherical math The S2 Geometry Library is a spherical geometry library, very useful for manipulating regions on the sphere (commonly on Earth) and indexing geographic data. This the a fork from the original s2-geometry-library-java library by google. The latest lucene is using this library and will be needed for #970738. -- Regards Sudip
Bug#973045:
Control: unblock 973047 by -1 -- Turns out that this one is not needed for s2-geometry-library java library and so unblocking #973047. Its almost packaged in local system but I am not uploading since I dont need it now. Keeping the ITP open, if anyone needs this package then I can upload. -- Regards Sudip
Bug#636734: systune
Hi All, Is this package still being used? I downloaded it and had a look at the source and also played with it in my laptop, its only a very simple script which is doing 'cat' to read the values and then using 'echo' to restore the values to /proc. -- Regards Sudip
Bug#740580: O: fbset -- framebuffer device maintenance program
Hi All, On Mon, Mar 03, 2014 at 12:25:05PM +0100, Cyril Brulebois wrote: > Guillem Jover (2014-03-03): > > This package has a lethargic upstream, and needs to be synced from time > > to time with the latest Linux framebuffer header, accelerators, docs and > > modes, from «linux/include/linux/fb.h» and «linux/Documentation/fb/» > > respectively, which I've not done since linux-3.0.0-rc1, as I can't be > > bothered any longer. It also produces a udeb, so people interested in > > the installer might want to take a look. > > I only quickly looked, but I didn't find anything obvious making use of > the binaries the udeb contains, or a reference to the udeb itself; so I > might be OK for it to go away entirely. Cc-ing -boot@ so that someone > can yell if I missed something. I have a framebuffer driver in the upstream kernel and have used fbset to test the driver. Though I have not used the debian version and built it from source for my use, I will hate to see it go away. I have looked at the source and the docs needs to update and one change in the header file. I will like to maintain it if noone else has already shown interest and if it is still orphan. I can see Guillem has updated it after making it orphan, so not sure what the currect status is. -- Regards Sudip
Bug#943552: ITP: tracecompass -- trace viewer and analyzer
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: tracecompass Version : 5.1.0 * URL : https://www.eclipse.org/tracecompass/ * License : Eclipse Public License Programming Lang: Java Description : trace viewer and analyzer Eclipse Trace Compass is an open source application to solve performance and reliability issues by reading and analyzing traces and logs of a system. Its goal is to provide views, graphs, metrics, and more to help extract useful information from traces, in a way that is more user-friendly and informative than huge text dumps. - tracecompass supports multiple trace formats including lttng and ftrace. - I need to use it frequently for my dayjob. - I will need a sponsor.
Re: trace-cmd in debian is very old compared to upstream
On Sat, Oct 26, 2019 at 11:12:00AM +0100, Sudip Mukherjee wrote: > On Sat, Oct 26, 2019 at 10:31:52AM +0100, Sudip Mukherjee wrote: > > Package: trace-cmd > > Version: 2.6.1-0.1 > > Severity: important > > > > The trace-cmd package in debian seems to be very old. The upstream > > available version is v2.8.3 and the version used in debian is v2.5.3. > > There had been major improvements in trace-cmd and kernelshark recently. > > And it has been removed from bullseye also. Is the package orphan now? > Its not in the orphaned package list. update: It was removed because of #885529. I just built v2.8.3 in bullseye and verified that both trace-cmd and kernelshark works. I will try to package it now. Is it too late to add it in bullseye? Not sure who can advice so adding wnpp. -- Regards Sudip
Bug#944138: ITP: libtraceevent -- The libtraceevent library provides APIs to access kernel tracepoint events
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ker...@lists.debian.org * Package name: libtraceevent Version : 1.1.0 Upstream Author : Steven Rostedt (VMware) * URL : NA * License : GPL-2.0 and LGPL-2.1 Programming Lang: C Description : The libtraceevent library provides APIs to access kernel tracepoint events, located in the tracefs file system under the events directory. The kernel tracepoints are now being used by multiple packages like trace-cmd, perf, powertop, rasdaemon. And all of them have duplicate codes in them to use the tracepoints. libtraceevent is planned to move all the duplicate codes in a single library so that the duplicate code will be removed from the next versions of these packages and they can depend on libtraceevent. The code for libtracevent lives in the kernel tree at git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git in tools/lib/traceevent folder. And so, it will be great if kernel team will like to package and maintain it, if not, then I will be happy to do it. But, if I am doing it then I will need a sponsor to upload it. -- Regards Sudip
Bug#943552: ITP: tracecompass -- trace viewer and analyzer
The first problem I faced while building has been fixed with the help of tracecompass maintainers. Now I am blocked by the other plugins and components needed. Debian is not having the needed versions. I will start by updating the other packages, and so looks like I am blocked on this for now and will take time to complete. I will start the other update process with tycho. We have 1.0.0-2 in Debian but 1.3.0 is needed for tracecompass. -- Regards Sudip
Bug#944138: ITP: libtraceevent -- The libtraceevent library provides APIs to access kernel tracepoint events
On Fri, Nov 08, 2019 at 07:56:55PM +, Ben Hutchings wrote: > On Mon, 2019-11-04 at 21:44 +0000, Sudip Mukherjee wrote: > [...] > > The code for libtracevent lives in the kernel tree at > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git in > > tools/lib/traceevent folder. > > And so, it will be great if kernel team will like to package and maintain > > it, if not, then I will > > be happy to do it. But, if I am doing it then I will need a sponsor to > > upload it. > > If kernel.org's kernel source repository is the canonical location for > this code, not just a convenience copy, then the binary package should > be built from src:linux and not a separate source package. > > I think src:linux already builds the library, but only as a static > library that's linked into perf. > > I don't know exactly what changes you would need to make, but they > should be roughly along these lines: > > > 4. Generate the debian/libtraceevent.symbols file recording >the shared library's exported symbols. Thanks for your reply Ben. I will try these steps and see how it goes. > > 5. (Not sure if this is needed.) Modify >debian/rules.d/tools/perf/Makefile to make perf use the shared >library. Add libtraceevent to the dependencies of >linux-perf- in debian/templates/control.tools-versioned.in. This should not be needed as perf does not yet depend on libtraceevent. The libtraceevent that perf is creating is only having the plugins. -- Regards Sudip
Bug#944138: ITP: libtraceevent -- The libtraceevent library provides APIs to access kernel tracepoint events
Hi Ben, On Sun, Nov 10, 2019 at 10:01 PM Ben Hutchings wrote: > > On Sun, 2019-11-10 at 21:29 +, Sudip Mukherjee wrote: > > On Fri, Nov 08, 2019 at 07:56:55PM +, Ben Hutchings wrote: > > > On Mon, 2019-11-04 at 21:44 +, Sudip Mukherjee wrote: > > > [...] > > > > The code for libtracevent lives in the kernel tree at > > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git in > > > > tools/lib/traceevent folder. > > > > And so, it will be great if kernel team will like to package and > > > > maintain it, if not, then I will > > > > be happy to do it. But, if I am doing it then I will need a sponsor to > > > > upload it. > > > > > > If kernel.org's kernel source repository is the canonical location for > > > this code, not just a convenience copy, then the binary package should > > > be built from src:linux and not a separate source package. > > > > > > I think src:linux already builds the library, but only as a static > > > library that's linked into perf. > > > > > > I don't know exactly what changes you would need to make, but they > > > should be roughly along these lines: > > > > > > > > 4. Generate the debian/libtraceevent.symbols file recording > > >the shared library's exported symbols. > > > > Thanks for your reply Ben. > > I will try these steps and see how it goes. > > > > > 5. (Not sure if this is needed.) Modify > > >debian/rules.d/tools/perf/Makefile to make perf use the shared > > >library. Add libtraceevent to the dependencies of > > >linux-perf- in debian/templates/control.tools-versioned.in. > > > > This should not be needed as perf does not yet depend on libtraceevent. > > The libtraceevent that perf is creating is only having the plugins. > > I'm pretty sure it does; look for "libtraceevent.a" in > <https://buildd.debian.org/status/fetch.php?pkg=linux&arch=amd64&ver=5.3.9-1&stamp=1573349194&raw=1>. iiuc, perf used tools/lib/traceevent to generate "libtraceevent.a" which is a static library and perf is building against that. It is also using the plugins generated by traceevent. But it is not using "libtraceevent.so" which is generated. So, as a result all the traceevent code is statically linked in perf when it builds. If I see the installation folder of perf I am only seeing "lib64/traceevent/plugins" and I am not seeing the dynamic library created by traceevent. Moreover if I do "ldd perf" it is not showing that it is linked to libtraceevent.so. But, in anycase, I will need to modify the rules as the plugins will be installed by traceevent which will be used by perf. I hope I was able to explain properly. But, let me make the changes and test first and then I can show you what I did. Thanks for your help. -- Regards Sudip
Bug#944138: ITP: libtraceevent -- The libtraceevent library provides APIs to access kernel tracepoint events
iiuc, Debian kernel can only have patches accepted upstream. And, so this is now blocked on: https://patchwork.kernel.org/patch/11243801/ https://patchwork.kernel.org/patch/11246125/ https://patchwork.kernel.org/patch/11246127/ I will wait till they are accepted and appears on linux-next. -- Regards Sudip
Bug#944138: ITP: libtraceevent -- The libtraceevent library provides APIs to access kernel tracepoint events
On Fri, Nov 15, 2019 at 11:44:03AM +, Sudip Mukherjee wrote: > iiuc, Debian kernel can only have patches accepted upstream. And, so > this is now blocked on: > https://patchwork.kernel.org/patch/11243801/ > https://patchwork.kernel.org/patch/11246125/ > https://patchwork.kernel.org/patch/11246127/ > > I will wait till they are accepted and appears on linux-next. wip merge request has been opened in salsa at: https://salsa.debian.org/kernel-team/linux/merge_requests/192 Another patch had to be sent upstream, and once I get the Ack for that the wip: can be removed from the merge request. @Ben: if you get some time can you please have an initial look at this. -- Regards Sudip
Bug#944138: ITP: libtraceevent -- The libtraceevent library provides APIs to access kernel tracepoint events
just fyi. Merge request has been opened in salsa - https://salsa.debian.org/kernel-team/linux/merge_requests/192 and is waiting for the review from kernel-team. -- Regards Sudip
Bug#949307: ITP: disk-filltest -- Simple Tool to Detect Bad Disks by Filling with Random Data
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: disk-filltest Version : 0.8 Upstream Author : Timo Bingmann * URL : https://panthema.net/2013/disk-filltest/ * License : GPL-3 Programming Lang: C Description : Simple Tool to Detect Bad Disks by Filling with Random Data The number of hard disk produced in the last five years is huge. Of course, this is the same number of hard disks that will most probably fail in the next five years, possibly with catastrophic consequences for the particular user or business. The simple tool disk-filltest can help, together with S.M.A.R.T. monitoring, to check disks periodically and thus be forewarned about coming failures. The function of disk-filltest is simple: * Write files random- to the current directory until the disk is full. * Read the files again and verify the pseudo-random sequence written. * Any write or read error will be reported, either by the operating system or by checking the pseudo-random sequence. * Optionally, delete the random files after a successful run. -- Regards Sudip
Bug#949308: ITP: digup -- A Digest Updating Tool
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: digup Version : 0.6.50 Upstream Author : Timo Bingmann * URL : https://panthema.net/2009/digup/ * License : GPL-2 Programming Lang: C Description : A Digest Updating Tool digup is a tool to update md5sum or shasum digest files. It will read existing digest files, check the current directory for new, updated, modified, renamed or deleted files and query the user with a summary of changes. After reviewing the updates, they can be written back to the digest file. -- Regards Sudip
Bug#949827: ITP: traceshark -- Graphical viewer for the Ftrace and Perf events.
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: traceshark Version : 0.9.9-beta Upstream Author : Viktor Rosendahl * URL : https://github.com/cunctator/traceshark * License : GPL-3.0 Programming Lang: C++ Description : This is a graphical viewer for the Ftrace and Perf events that can be captured by the Linux kernel. It can be used to visualize the following events: cpu_frequency cpu_idle sched_migrate_task sched_process_exit sched_process_fork sched_switch sched_wakeup sched_wakeup_new sched_waking The trace can be collected using trace-cmd or perf. The filtered trace file from traceshark can be used with flamegraph to generate image. Debian alreday has kernel-shark as a viewer of ftrace traces, but this has the advantage of converting to an image and also taking screenshots of the plot. -- Regards Sudip
Bug#910917: RFA: apache2 -- Apache HTTP Server
Hi, On Wed, Nov 28, 2018 at 09:47:34AM +0100, Xavier wrote: > Job started. Could you update my role in salsa ? "developer" role > doesn't allow me to use GitLab API: I'd like to configure project to add > "tagpending" webhook. It seems Xavier has taken up the package since Version: 2.4.38-1. Do you want me to close this bug now or are you still looking for people to adopt apache2 ? -- Regards Sudip
Bug#949308: ITP: digup -- A Digest Updating Tool
Initial packaging has been done, but I am waitig for the response from upstream on a doubt about licence of one of the file at: https://panthema.net/2009/digup/digup-0.6.55/src/rbtree.c.html -- Regards Sudip
Bug#956453: ITP: libcyaml -- Schema-based YAML parsing and serialisation
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libcyaml Version : 1.0.2 Upstream Author : Michael Drake * URL : https://github.com/tlsa/libcyaml * License : ISC Programming Lang: C Description : Schema-based YAML parsing and serialisation LibCYAML is a C library for reading and writing structured YAML documents. The fundamental idea behind CYAML is to allow applications to construct schemas which describe both the permissible structure of the YAML documents to read/write, and the C data structure(s) in which the loaded data is arranged in memory. I will need a sponsor for this and I can maintain it after it has been uploaded and accepted. -- Regards Sudip
Bug#959870: ITP: mplcursors -- Interactive data selection cursors for Matplotlib
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: mplcursors Version : 0.3 Upstream Author : Antony Lee * URL : https://github.com/anntzer/mplcursors * License : MIT Programming Lang: Python Description : Interactive data selection cursors for Matplotlib mplcursors provides interactive data selection cursors for Matplotlib. It is inspired from mpldatacursor, with a much simplified API. This is needed to package "topplot". Though my python knowledge is very limited but I can maintain it but I will need sponsors for uploads. -- Regards Sudip
Bug#959872: ITP: topplot -- Munge logs from top in to useful graphs
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: topplot Version : 0.0.4 Upstream Author : Jonathan Sambrook * URL : https://gitlab.com/eBardie/topplot/ * License : GPL-3 Programming Lang: Python Description : Munge logs from top in to useful graphs topplot produces graphs of information it munges from top logs. It can select which processes to focus on, and it can split out information by cpu core (if top was configured to record the cpu core column, and/or display the cpu summary info by core). topplot can save the graphs as PNG files. It can also print information derived from the logs to stdout, with or without emitting the graphs. There may be better, more efficient ways of collecting live system information, but if for some reason you've hundreds of thousands of lines of top logs and you want to see what's in them, topplot can help. I personally have to use topplot in my $dayjob and so my interest in having it as a proper Debian package. This will need mplcursors and I have raised separate ITP (#959870) for that. Though my python knowledge is very limited but I can maintain it and I will need sponsors for uploads. -- Regards Sudip
Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files
On Wed, May 06, 2020 at 10:22:03AM -0400, Olek Wojnar wrote: > Oops, dropped bug email... > > -- Forwarded message - > From: Olek Wojnar > Date: Wed, May 6, 2020 at 10:21 AM > Subject: Re: RFP: diffutils-java -- Implementation of general operations > with diff files > To: Andrej Shadura > > > Hi Andrej, > > Thanks for bringing up this point! > > Based on Yun Peng's comment, would it be better if we disambiguated this > package by calling it "google-diffutils-java" instead? Maybe mention the > line vs character thing as well in the description? Taking the source from: https://code.google.com/archive/p/java-diff-utils/source/default/source the packaging was fairly simple and if noone has already done it I can finalize it and upload to mentors and change this to ITP at the same time. Please let me know if I have mistaken and that link was not the source for this package. -- Regards Sudip
Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files
On Wed, May 06, 2020 at 04:54:22PM +0100, Sudip Mukherjee wrote: > On Wed, May 06, 2020 at 10:22:03AM -0400, Olek Wojnar wrote: > > Oops, dropped bug email... > > > > -- Forwarded message - > > From: Olek Wojnar > > Date: Wed, May 6, 2020 at 10:21 AM > > Subject: Re: RFP: diffutils-java -- Implementation of general operations > > with diff files > > To: Andrej Shadura > > > > > > Hi Andrej, > > > > Thanks for bringing up this point! > > > > Based on Yun Peng's comment, would it be better if we disambiguated this > > package by calling it "google-diffutils-java" instead? Maybe mention the > > line vs character thing as well in the description? > > Taking the source from: > https://code.google.com/archive/p/java-diff-utils/source/default/source > the packaging was fairly simple and if noone has already done it I can > finalize it and upload to mentors and change this to ITP at the same time. > > Please let me know if I have mistaken and that link was not the source > for this package. fwiw, I did a diff and its the same source in the linked jar and the link I gave. Also, looking at java-diff-utils that Andrej mentioned, is actually a fork from the google code. -- Regards Sudip
Bug#959834: Fwd: RFP: diffutils-java -- Implementation of general operations with diff files
Control: retitle 959834 RFP: diffutils-java -- Implementation of general operations with diff files On Wed, May 06, 2020 at 07:34:21PM +0200, Andrej Shadura wrote: > On 06/05/2020 19:31, Andrej Shadura wrote: > > On 06/05/2020 19:25, Andrej Shadura wrote: > >> I don’t think we need the original code since it’s much older and the > >> fork has seen quite some development. They are backwards-compatible > >> except that the Maven coordinates are different. Basically, we only need > >> to patch Bazel to use it. > > > > Correction: they’re not fully compatible, but API difference is not big > > and porting is quite straight-forward. > > Right, I now remember one more reason why I chose the fork but not the > original. There was a licensing issue around the diff algo > implementation in the original. I don’t remember the details, but the > fork has completely reimplemented it, thus working it around. Thanks Andrej. Moving it back to RFP for now. -- Regards Sudip
Bug#960423: ITP: takari-polyglot-maven -- modules to enable Maven usage in others JVM languages
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-CC: debian-j...@lists.debian.org * Package name: takari-polyglot-maven Version : 0.4.5 Upstream Author : * URL : https://github.com/takari/polyglot-maven * License : EPL-1.0 Programming Lang: Java Description : modules to enable Maven usage in others JVM languages Polyglot Maven harnesses the power of Maven through modern implementations of the JVM language like Groovy, Scala, Clojure and JRuby. The old package "polyglot-maven" is already in Debian, the new update has changed the package name. If we update Debian version of polyglot-maven then that will break the build of many other packages. So, as discussed in https://lists.debian.org/debian-java/2020/05/msg00017.html, this ITP is to package the new version as a separate package so that other packages which needs new polyglot-maven can use this (like #792149). I can maintain this under the umbrella of java-team. -- Regards Sudip
Bug#950907: RFP: git-repo-updater -- A console script that allows you to easily update multiple git repositories at once
Control: retitle -1 ITP: git-repo-updater -- A console script that allows you to easily update multiple git repositories at once This looks quite handy, and I have to use multiple repo as part of my $dayjob. I was just using a script for now but this is much better than just using a script. I have mailed "Ben Kurtovic" to confirm his willingness to support as upstream. If he confirms I can package it, if not I will move it back to RFP. -- Regards Sudip
Bug#961742: ITP: nsntrace -- perform network trace of a single process by using network namespaces
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-CC: p...@debian.org * Package name: nsntrace Version : v3 or v4 Upstream Author : Jonas Danielsson * URL : https://github.com/nsntrace/nsntrace * License : GPL-2+ Programming Lang: C Description : perform network trace of a single process by using network namespaces Uses Linux network namespaces to perform network traces of a single application. The traces are saved as pcap files. And can later be analyzed by for instance Wireshark. Note: This is a reintroduction of the package.
Bug#961795: ITP: eclipse-cdt -- C/C++ Development Tools for Eclipse
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee Control: block 943552 by -1 * Package name: eclipse-cdt Version : 9.11.0 Upstream Author : many * URL : https://www.eclipse.org/cdt/ * License : EPL-2.0 Programming Lang: Java Description : C/C++ Development Tools for Eclipse The CDT Project provides a fully functional C and C++ Integrated Development Environment based on the Eclipse platform. Features include: support for project creation and managed build for various toolchains, standard make build, source navigation, various source knowledge tools, such as type hierarchy, call graph, include browser, macro definition browser, code editor with syntax highlighting, folding and hyperlink navigation, source code refactoring and code generation, visual debugging tools, including memory, registers, and disassembly viewers. This is a re-introduction of the package and I will only intend to build org.eclipse.cdt.core.* and org.eclipse.cdt.utils.* as I will need them for #943552. This will be maintained under the umbrella of java-team. -- Regards Sudip
Bug#961796: ITP: eclipse-linuxtools -- framework for profiling tools for Eclipse CDT
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee Control: block 943552 by -1 * Package name: eclipse-linuxtools Version : v7.6.0 Upstream Author : many * URL : https://www.eclipse.org/linuxtools/ * License : EPL-2.0 Programming Lang: Java Description : framework for profiling tools for Eclipse CDT The Linux Tools project aims to bring a full-featured C and C++ IDE to Linux developers. We build on the source editing and debugging features of the CDT and integrate popular native development tools such as Valgrind, OProfile, RPM, SystemTap, GCov, GProf, LTTng, etc. Current projects include LTTng trace viewers and analyzers, an RPM .spec editor, a Valgrind heap usage analysis tool, and OProfile and Perf call profiling tools. This is a re-introduction of the package and for now I only intend to build org.eclipse.linuxtools.dataviewers.piechart.PieChart which I will need for #943552. This will be maintained under the umbrella of java-team. -- Regards Sudip
Bug#961797: ITP: eclipse-remote-services-api -- Eclipse Remote Services API
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee Control: block 943552 by -1 * Package name: eclipse-remote-services-api Version : 2.1.0 Upstream Author : many * URL : https://git.eclipse.org/c/ptp/org.eclipse.remote.git/ * License : EPL-1.0 Programming Lang: Java Description : Eclipse Remote Services API The purpose of this API is to provide a programming interface to remote services that is agnostic to the actual remote services implementation. Currently the only implementation supported is JSch. This is a reintroduction of the package and I only intend to build org.eclipse.remote.core and org.eclipse.remote.ui as I need them for #943552. This will be maintained under the umbrella of java-team. -- Regards Sudip
Bug#943552: ITP: tracecompass -- trace viewer and analyzer
Control: block 943552 by 960423 Just an update: I had the chance to work on this during this mini-Debcamp and have now opened other ITP which is blocking this. This will also need pomless tycho build and #960423 is needed to enable pomless feature in tycho. -- Regards Sudip
Bug#961891: ITP: eclipse-swtchart -- Eclipse SWTChart allows to create different types of charts
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee Control: block 961796 by -1 * Package name: eclipse-swtchart Version : 0.12.0 Upstream Author : Yoshitaka Yanagida Philip Wenig * URL : https://projects.eclipse.org/projects/science.swtchart * License : EPL-2.0 Programming Lang: Java Description : Eclipse SWTChart allows to create different types of charts The API allows to create Line, Bar and Scatter charts easily. Size, colors, axes, ranges and all aspects of the charts can be modified via code. It is easy to create customized charts. The library already contains data compression to show large data sets in a performant way. Charts can be created even more easily with the SWTChart extensions. It uses the convention over configuration pattern and offers many additional improvements to scale axes of different type automatically or to select specific data ranges. The old package "libswtchart-java" is already in debian but this new version is now a eclipse project and the class names have all changed to org.eclipse.swtchart instead of the old old.swtchart. This is needed to package #961796 and I can maintain it under the umbrella of java-team. Note: Once it has landed, it should be possible to update the other packages depending on the old "libswtchart-java" and use this one instead. -- Regards Sudip
Bug#961796: ITP: eclipse-linuxtools -- framework for profiling tools for Eclipse CDT
Control: unblock -1 by 961891 On Fri, May 29, 2020 at 12:14:49PM +0100, Sudip Mukherjee wrote: > Package: wnpp > Severity: wishlist > Owner: Sudip Mukherjee > Control: block 943552 by -1 > > * Package name: eclipse-linuxtools > Version : v7.6.0 Correction: I will need v7.4.0 (for now) to package the tracecompass I am trying to package. And eclipse-linuxtools_7.4.0 uses the old version of swtcharts which is already in Debian and so, #961891 is not a blocker for this. -- Regards Sudip
Bug#960984: ITP: google-http-client-java -- Google HTTP Client Library for Java
Hi Olek, On Wed, Jun 3, 2020 at 8:30 AM Olek Wojnar wrote: > > Hi Sudip, > > Thanks for taking a look! > > On Tue, Jun 2, 2020 at 11:03 AM Sudip Mukherjee > wrote: >> >> > >> >> From a quick look at bazel >> (https://github.com/bazelbuild/bazel/tree/master/third_party/api_client) >> , it seems only "google-http-client" and "google-http-client-jackson2" >> is needed. So, another quick look at the source code and it seems we >> don't have "com.google.j2objc" and "io.opencensus". I think >> com.google.j2objc can be ignored but we will need io.opencensus. And >> you already have ITP for that. #959838. imho, "io.opencensus" needs to >> be packaged before "google-http-client-java", and from that you will >> mostly need "io.opencensus.common, io.opencensus.contrib and >> io.opencensus.trace". > > > Correct, those are the only two artifacts we need. The problem with the > dependencies is that opencensus depends on google-auth which in turn depends > on http-client-java. ;) Yay dependencies! :) So we need to figure out how to > either build http-client without opencensus or the other way around. Ideas > are very welcome! Do you know which modules from google-auth you will need? I think thats #959830. -- Regards Sudip
Bug#960984: ITP: google-http-client-java -- Google HTTP Client Library for Java
Hi Olek, On Wed, Jun 3, 2020 at 3:18 PM Olek Wojnar wrote: > > Hi Sudip, > > On Wed, Jun 3, 2020 at 7:43 AM Sudip Mukherjee > wrote: >> >> >> Do you know which modules from google-auth you will need? I think thats >> #959830. > > > Yes, I do: google-auth-library-credentials.jar, > google-auth-library-oauth2-http.jar. Take a look at [1], we've got lots of > good info there. Please let me know if anything is missing or you have any > other questions. We appreciate any assistance! Sorry, I think I am missing something. To build http-java-client you should only need "api" and "contrib/http_util" from opencensus-java which (iiuc) does not need google-auth. I dont know anything about gradle to help you with that but I think first packaging "api" and "contrib/http_util" from opencensus-java and then using that to build google-http-client should be achievable. -- Regards Sudip
Bug#961795: ITP: eclipse-cdt -- C/C++ Development Tools for Eclipse
On Fri, May 29, 2020 at 12:06:33PM +0100, Sudip Mukherjee wrote: > Package: wnpp > Severity: wishlist > Owner: Sudip Mukherjee > Control: block 943552 by -1 > > * Package name: eclipse-cdt > Version : 9.11.0 Correction: The version needed is 9.9.0 > Upstream Author : many > * URL : https://www.eclipse.org/cdt/ > * License : EPL-2.0 > Programming Lang: Java > Description : C/C++ Development Tools for Eclipse > > > This is a re-introduction of the package and I will only intend to build > org.eclipse.cdt.core.* and org.eclipse.cdt.utils.* as I will need them > for #943552. org.eclipse.cdt.core and org.eclipse.cdt.core.native is needed and only those two will be built for now. -- Regards Sudip
Bug#962239: RFP: jc -- converts command output to JSON
On Thu, Jun 04, 2020 at 03:03:35PM -0700, Kelly Brazil wrote:
> Package: wnpp
> Severity: wishlist
>
> I am the developer of jc, which is now packaged on OpenSUSE, NixOS, macOS
> (Homebrew), and FreeBSD (ports). jc is currently in process for packaging on
> Fedora.
>
> jc is licensed under the MIT license.
>
> https://github.com/kellyjonbrazil/jc
> https://pypi.org/project/jc/
>
> JSON CLI output utility
I do not use this personally, but I think this might be a good package
to be in Debian. I made an initial packaging, but getting error while
trying to use that.
$ ls -l /usr/bin | jc --ls
Traceback (most recent call last):
File "/usr/bin/jc", line 11, in
load_entry_point('jc==1.11.2', 'console_scripts', 'jc')()
File "/usr/lib/python3/dist-packages/jc/cli.py", line 401, in main
json_out(result, pretty=pretty, mono=mono, piped_out=piped_output())
File "/usr/lib/python3/dist-packages/jc/cli.py", line 249, in json_out
class JcStyle(Style):
File "/usr/lib/python3/dist-packages/pygments/style.py", line 101, in __new__
ndef[0] = colorformat(styledef)
File "/usr/lib/python3/dist-packages/pygments/style.py", line 58, in
colorformat
assert False, "wrong color format %r" % text
AssertionError: wrong color format 'ansiblue'
I have also tried with ls -l /usr/bin | jc --ls -m
Note: This works fine when I install Pygments from pip3 (v2.6.1) rather
than using the Debian version which is v2.3.1
--
Regards
Sudip
Bug#961797: ITP: eclipse-remote-services-api -- Eclipse Remote Services API
Control: retitle -1 ITP: eclipse-remote -- Eclipse Remote Services API Control: block -1 by 961795 On Sun, May 31, 2020 at 11:02:40AM +0200, Emmanuel Bourg wrote: > Hi Sudip, > > Since the upstream repository is named "org.eclipse.remote" I suggest > renaming the package to "eclipse-remote", that would be more in line > with the new eclipse-* packages we've introduced two years ago. Thanks Emmanuel. So, then this is not going to be a reintroduction but is going to be a new package. And also, the previous package was built from a different branch and had a different version so would have needed epoch. -- Regards Sudip
Bug#962866: ITP: openjson -- rewrite of the evil licensed json.org
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee Control: block 943552 by -1 * Package name: openjson Version : v1.0.12 Upstream Author : many * URL : https://github.com/openjson/openjson * License : Apache-2.0 Programming Lang: java Description : rewrite of the evil licensed json.org Json.org is a popular java library to parse and create json string from the author of the json standard Douglas Crockford. His implementation however is not free software[1]. The Android team did a cleanroom reimplementation of a json library and this package has extended the implementation done by the Android team. [1] http://wiki.debian.org/qa.debian.org/jsonevil I need a json library for #943552 and the libandroid-json-org-java that we have in Debian has not implemented all the methods that tracecompass uses. I can modify the tracecompass code to use libandroid-json-org-java but using this 'openjson' is a cleaner implementation, without the need to modify original code. I can maintain the package under the umbrella of java-team. -- Regards Sudip
Bug#962861: RFP: drm-info -- Small utility to dump info about DRM devices
On Mon, Jun 15, 2020 at 09:35:56AM +0200, Guido Günther wrote: > Package: wnpp > Severity: wishlist > > > drm_info dumps information about available drm device like available > devices, planes, encoders, crtcs and connectors and their DRM > properties. This looks like an useful utility and I did an initial packaging. But while testing I get a segfault after printing all the information. $ drm_info Node: /dev/dri/card0 ├───Driver: bochs-drm (bochs dispi vga interface (qemu stdvga)) version 1.0.0 (20130925) │ ├───DRM_CLIENT_CAP_STEREO_3D supported │ ├───DRM_CLIENT_CAP_UNIVERSAL_PLANES supported │ ├───DRM_CLIENT_CAP_ATOMIC supported │ ├───DRM_CLIENT_CAP_ASPECT_RATIO supported │ ├───DRM_CLIENT_CAP_WRITEBACK_CONNECTORS supported │ ├───DRM_CAP_DUMB_BUFFER = 1 │ ├───DRM_CAP_VBLANK_HIGH_CRTC = 1 │ ├───DRM_CAP_DUMB_PREFERRED_DEPTH = 24 │ ├───DRM_CAP_DUMB_PREFER_SHADOW = 0 │ ├───DRM_CAP_PRIME = 0 │ ├───DRM_CAP_TIMESTAMP_MONOTONIC = 1 │ ├───DRM_CAP_ASYNC_PAGE_FLIP = 0 │ ├───DRM_CAP_CURSOR_WIDTH = 64 │ ├───DRM_CAP_CURSOR_HEIGHT = 64 │ ├───DRM_CAP_ADDFB2_MODIFIERS = 0 │ ├───DRM_CAP_PAGE_FLIP_TARGET = 0 │ ├───DRM_CAP_CRTC_IN_VBLANK_EVENT = 1 │ ├───DRM_CAP_SYNCOBJ = 0 │ └───DRM_CAP_SYNCOBJ_TIMELINE = 0 Segmentation fault I also tried with "drm_info -j" and that works pergectly without any error. Note: I have used Debian packages of json-c, libdrm and libpci. It will be good to have a manpage along with the fix for segfault. -- Regards Sudip
Bug#962861: RFP: drm-info -- Small utility to dump info about DRM devices
ooi, I had a look at the coredump. #0 0x in ?? () #1 0x7f43bfe22751 in ?? () from /lib/x86_64-linux-gnu/libpci.so.3 #2 0x7f43bfe2054a in ?? () from /lib/x86_64-linux-gnu/libpci.so.3 #3 0x7f43bfe208b7 in pci_lookup_name () from /lib/x86_64-linux-gnu/libpci.so.3 #4 0x55f574f94bb2 in print_device (obj=) at ../pretty.c:106 #5 0x55f574f95ac4 in print_node (obj=0x55f57511a9c0, path=) at ../pretty.c:774 #6 print_drm (obj=) at ../pretty.c:795 #7 0x55f574f8f482 in main (argc=1, argv=) at ../main.c:36 -- Regards Sudip
Bug#959829: [covid-19] Help needed to finalise bazel predependency google-api-client-java
On Wed, Jun 17, 2020 at 9:13 AM Andreas Tille wrote: > > Hi Tony, > > On Tue, Jun 16, 2020 at 09:34:20PM -0700, tony mancill wrote: > > > > I've pushed a "tmancill" branch to the Salsa repo that gets us further > > along. I have taken the liberty to push to "tmancill" branch and the issue with "com.google.api.client.util" is now resolved. It needs to depend on "libgoogle-oauth-client-java" which is still in NEW. But, it now fails with: google-api-client/src/main/java/com/google/api/client/googleapis/services/AbstractGoogleClientRequest.java:[435,16] cannot find symbol [ERROR] symbol: method setResponseReturnRawInputStream(boolean) [ERROR] location: variable httpRequest of type com.google.api.client.http.HttpRequest And, indeed https://salsa.debian.org/java-team/google-http-client-java/-/blob/master/google-http-client/src/main/java/com/google/api/client/http/HttpRequest.java is not having the method "setResponseReturnRawInputStream". And, it seems the packaged version of libgoogle-http-client-java in Debian is 1.27 and "setResponseReturnRawInputStream" was added in v1.29.0. So, we will need to update libgoogle-http-client-java to 1.29.0 atleast. -- Regards Sudip
Bug#959829: [covid-19] Help needed to finalise bazel predependency google-api-client-java
On Wed, Jun 17, 2020 at 5:40 PM Olek Wojnar wrote: > > On Wed, Jun 17, 2020 at 12:19 PM Andreas Tille wrote: >> >> I have the feeling we are coming closer to a solution iteratively now >> but there are some remaining errors unfortunately: > > > If any of you have a moment, I recommend patching the main pom.xml to only > build the two modules that we need (google-api-client and > google-api-client-jackson2). That should vastly simplify things. That was easy. I have pushed my changes to "sudip" which now builds only those two. And, just noticed (after pushing) that the Vcs in d/control is wrong. It should be https://salsa.debian.org/java-team/google-api-java-client or the repo needs to be renamed. -- Regards Sudip
