Bug#466342: ITP: gmyth -- library for accessing MythTV backends
Package: wnpp Severity: wishlist Owner: Mario Limonciello <[EMAIL PROTECTED]> * Package name: gmyth Version : 0.7.0 Upstream Author : Alexsandro Jose Virginio dos Santos <[EMAIL PROTECTED]> Hallyson Luiz de Morais Melo <[EMAIL PROTECTED]> Leonardo Sobral Cunha <[EMAIL PROTECTED]> Rosfran Lins Borges <[EMAIL PROTECTED]> * URL : http://gmyth.sourceforge.net/ * License : GPL Programming Lang: C Description : library for accessing MythTV backends A library intended to access mythtv backend functionalities Gmyth accesses MythTV backend functionalities from a glib/gobject perspective. It includes access to the program guide, recorded programs, scheduling, etc. -- System Information: Debian Release: lenny/sid APT prefers hardy-updates APT policy: (500, 'hardy-updates'), (500, 'hardy-security'), (500, 'hardy-proposed'), (500, 'hardy-backports'), (500, 'hardy') Architecture: i386 (i686) Kernel: Linux 2.6.24-8-generic (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466400: ITP: libnet-upnp-perl -- Perl extensions for UPnP
Package: wnpp Severity: wishlist Owner: Mario Limonciello <[EMAIL PROTECTED]> * Package name: libnet-upnp-perl Version : 1.2.1 Upstream Author : Satoshi Konno <[EMAIL PROTECTED]> * URL : skonno/Net-UPnP-1.2.1/ * License : Written by owner Programming Lang: Perl Description : Perl extensions for UPnP Net::UPnP provides support for applications that contact other devices via UPnP protocols. -- System Information: Debian Release: lenny/sid APT prefers hardy-updates APT policy: (500, 'hardy-updates'), (500, 'hardy-security'), (500, 'hardy-proposed'), (500, 'hardy-backports'), (500, 'hardy') Architecture: i386 (i686) Kernel: Linux 2.6.24-8-generic (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#467368: ITP: gmyth-upnp -- The GObject based library for using a UPnP MythTV backend
Package: wnpp Severity: wishlist Owner: Mario Limonciello <[EMAIL PROTECTED]> * Package name: gmyth-upnp Version : 0.7 Upstream Author : Alexsandro Jose Virginio dos Santos <[EMAIL PROTECTED]> Hallyson Luiz de Morais Melo <[EMAIL PROTECTED]> Leonardo Sobral Cunha <[EMAIL PROTECTED]> Rosfran Lins Borges <[EMAIL PROTECTED]> * URL : http://gmyth.sourceforge.net * License : GPL, Programming Lang: C Description : The GObject based library for using a UPnP MythTV backend GMyth-UPnP is a library intended to access MythTV backend functionalities from a GLib/GObject perspective via UPnP. It includes access to the program guide, recorded programs, scheduling, etc. -- System Information: Debian Release: lenny/sid APT prefers hardy-updates APT policy: (500, 'hardy-updates'), (500, 'hardy-security'), (500, 'hardy-proposed'), (500, 'hardy-backports'), (500, 'hardy') Architecture: i386 (i686) Kernel: Linux 2.6.24-8-generic (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: DKMS - Dynamic Kernel Module Support
David Paleino wrote: > Sure, but I believe Mario intended "trasparently adding modules" -- i.e. > modules you forgot to update&install would automatically be handled by DKMS on > boot. Mario, am I wrong? > Correct, the service will simply compile the modules for you. rmmod/modprobe/udev control of the modules is outside the scope of what it handles. > > I believe this is a bug in the zaptel init scripts... shouldn't they check > whether they can be unloaded? Is there a --force option? But this is another > story :) > > For the case that was mentioned for asterisk holding zaptel devices open, that's not what DKMS is here to solve. DKMS is one step up the chain producing the modules that are needed for Zaptel. > > Googling for "dkms zaptel" gives some results, but most for Mandriva. I > believe > some effort should be made to make a "central repository" (like for > autopackage, and for other similar "cross-vendor" projects) where to store > "vanilla" tarballs. Mario, do you know of any "central source" currently > available? > The original plan for DKMS built modules was not to provide a central repository for these modules. They *should* all end up in the kernel in the long term. In cases that a vendor is providing a driver to be used on a variety of distributions, they should be hosting it on their own webspace generally. Another usecase is putting it directly into distributions that are most interesting to the vendor, but this is significantly more work. This is how a few drivers in Ubuntu are handled at this point. > > > I'm sorry I haven't all that experience with DKMS to clearly confirm this. > Mario, can you confirm? > > So if there were issues between the interaction of the Zaptel userspace init script and DKMS producing the modules to be used, an upstart style script will be needed so that Zaptel's userspace script doesn't get launched unless DKMS is finished. -- Mario Limonciello *Dell | Linux Engineering* [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: RFC: DKMS - Dynamic Kernel Module Support
Hi Cohen: Keep in mind, if there is a new kernel that gets installed, this will build the driver for that kernel, but nothing will be activated until you reboot. That choice is your own. Due to the kernel postinstall service, you won't even need to build the modules during the next boot prior to the zaptel service starting. Regards Tzafrir Cohen wrote: > On Thu, Sep 11, 2008 at 05:29:44PM +0200, David Paleino wrote: > > > > Maybe it's possible (I'm not exactly sure. I think it's possible, at > least in most cases). But do I want this? Do I want to shut down my PBX > because of the Ubuntu kernel upgrade of the month? > > Which is why I never tried to add such an option to the init script, and > why noone has asked for it. > > -- Mario Limonciello *Dell | Linux Engineering* [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: RFC: DKMS - Dynamic Kernel Module Support
Hi David: I'll add on the Ubuntu kernel team here to get some comments on this postinstall hook functionality and it's origins. Regards David Paleino wrote: > On Thu, 11 Sep 2008 10:00:38 +0200, David Paleino wrote: > > >> If you have AUTOINSTALL set to yes in a DKMS control file: >> >> 1) It includes a kernel postinstall hook. This means that, the moment kernel >> headers get installed, your modules are automatically rebuilt. >> > > This is achieved through the installation of a script in: > > /etc/kernel/header_postinst.d/ > /etc/kernel/postinst.d/ > /etc/kernel/prerm.d/ > > A quick search with apt-file didn't return any result. > Is this approach supported by Debian? I remember grub updating itself when a > new kernel is installed: is that a postinst by the kernel package itself? > > Kindly, > David > > -- Mario Limonciello *Dell | Linux Engineering* [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: RFC: DKMS - Dynamic Kernel Module Support
Hi Josselin: As I understand, the dpkg maintainer (Michael Vogt) is implementing the idea of package groups that have sticky dependencies. This should mean that when a package gets installed, it will need to register with the package group. When a kernel with a new ABI is available, it won't be offered as an upgrade until all of the items in the package group are available for the upgrade. I've added him on to try to comment on this some more. Josselin Mouette wrote: > Le jeudi 11 septembre 2008 à 17:29 +0200, David Paleino a écrit : > > > This is definitely the correct way to build extra modules. This could > mean: > * The end of the nightmare for users who need to rebuild their > modules by hand every time the kernel ABI changes. > * More smoothness for testing migration of non-free modules, which > could simply be shipped as source. > > Please go ahead in this direction. > > One of the issues I’m wondering about is: how do you ensure you always > have the kernel headers for the installed kernels? > > Cheers, > -- Mario Limonciello *Dell | Linux Engineering* [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: RFC: DKMS - Dynamic Kernel Module Support
Tzafrir Cohen wrote:
> Upon initial inspection of the dkms script, it seems to generate
> deb packages whose name does not not include $KVERS . But I didn't test
> it.
>
This is correct, because you don't want to have multiple DKMS packages
installed to support many versions of the kernel module. The idea is
that if you were to ship a binary kernel module in the package, you
would be shipping the source with it. When the user were to install
another kernel version, the source would be used to build a new binary
kernel module.
This will not, by far, be the first package to install manage that are
not contained within the package. You should see it just like the
byte-compilation of elisp or python modules: when a new
kernel/interpreter version is available, you need to compile/bytecompile
the drivers/modules that are handled by dkms/python-{central,support}.
The only thing that is different is that you need to ensure that the
headers are installed for each of the kernel images.
I would also much agree to install these files in a separate directory
tree from /lib/modules/2.6.xx-y-zzz, so that no confusion arises. /var
is not possible because it may not be mounted, but
think /lib/modules.dkms for example. This requires simple changes to
module-init-tools and initramfs-tools, but I think we can get something
working simply and correctly.
Earlier in this thread it was mentioned that since these compiled files
are not managed by dpkg, that perhaps they should be stored in /var.
This is already the case, /var/lib/dkms is where everything is stored
at. It's copied over to /lib/modules/... If there is a worry about
storing files in /lib/modules when they are copied, perhaps instead
making this action a symlink would be better?
--
Mario Limonciello
*Dell | Linux Engineering*
[EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
Bug#793446: ITP: fwupd -- Firmware update daemon
Package: wnpp Severity: wishlist Owner: Mario Limonciello * Package name: fwupd Version : 0.1.4 Upstream Author : Richard Hughes * URL : https://github.com/hughsie/fwupd * License : GPL Programming Lang: C Description : Firmware update daemon fwupd is a daemon to allow session software to update device firmware. You can either use a GUI software manager like GNOME Software to view and apply updates, the command-line tool or the system D-Bus interface directly. Currently, firmware updates using the UEFI capsule format and for the ColorHug are supported. More formats may be supported in the future. Currently Daniel Jared Dominguez and I have been collaborating on packaging for fwupd located at http://linux.dell.com/cgi-bin/cgit.cgi/debian/fwupd.git/ We are discussing assembling a packaging maintenance team for firmware related packages such as fwupd, fwupdate, efivar, etc. Upstream has not yet released the 0.1.4 release. That is the first release that should be put into Debian. The 0.1.3 release doesn't yet properly support UEFI capsules. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150724055002.3479.1913.reportbug@supermario-XPS-13-9343
Bug#920777: ITP: libxmlb -- XML binary library
Package: wnpp Severity: wishlist Owner: Mario Limonciello * Package name: libxmlb Version : 0.1.6 Upstream Author : Richard Hughes * URL : https://github.com/hughsie/libxmlb * License : LGPL2.1+ Programming Lang: C Description : XML binary library The libxmlb library takes XML source, and converts it to a structured binary representation with a deduplicated string table -- where the strings have the NULs included. . This allows an application to mmap the binary XML file, do an XPath query and return some strings without actually parsing the entire document. This is all done using (almost) zero allocations and no actual copying of the binary data. This package is used by newer versions of fwupd and gnome-software as a mandatory dependency. It's intended to be maintained by the debian-efi team as part of supporting the UEFI stack.
Bug#953565: ITP: libjcat -- JSON Catalog library
Package: wnpp Severity: wishlist Owner: Mario Limonciello * Package name: libjcat Version : 0.1.0 Upstream Author : Richard Hughes * URL : https://github.com/hughsie/libjcat * License : LGPL 2.1+ Programming Lang: C Description : JSON Catalog library The libjcat library assembles checksum and metadata into a JSON based catalog. This is used by other software to validate metadata. This will be a dependency for fwupd in the future (1.4.0 release or newer). It will be maintained by the debian-efi team which also maintains the rest of the firmware updating stack for UEFI machines. The packaging has already been started at https://salsa.debian.org/efi- team/libjcat. It will be uploaded when libjcat has it's first release.
Bug#855065: ITP: thunderbolt-software-user-space -- Thunderbolt daemon and userspace tools for thunderbolt NVM flashing
Package: wnpp Severity: wishlist Owner: Mario Limonciello * Package name: thunderbolt-software-user-space Version : 2017.01.19 Upstream Author : Intel Thunderbolt Linux Team * URL : https://github.com/01org/thunderbolt-software-user- space.git * License : BSD Programming Lang: C Description : Thunderbolt daemon and userspace tools for thunderbolt NVM flashing This daemon provides support for the Intel Thunderbolt daemon. It provides support for peer-to-peer networks over Thunderbolt as well as the ability to flash the Thunderbolt NVM in-band. It will be used for the Thunderbolt plugin that is part of fwupd. https://github.com/hughsie/fwupd/tree/master/plugins/thunderbolt I'd like to maintain it as part of the UEFI team that already maintains fwupd, fwupdate, and the rest of the UEFI tools stack.
Bug#820124: ITP: fwupdate-signed -- Linux Firmware Updater EFI signed binary
Package: wnpp Severity: wishlist Owner: Mario Limonciello * Package name: fwupdate-signed Version : 1.11 Upstream Author : Mario Limonciello * URL : https://launchpad.net/ubuntu/+source/fwupdate-signed * License : (GPL-3+) Programming Lang: (Python) Description : Linux Firmware Updater EFI signed binary This package will be maintained by debian-efi as a team. That is the same team that currently maintains the unsigned version of fwupdate.
Re: Change the expectation that emails should wrap at 80 characters
On 3/2/25 12:27, Marc Haber wrote: On Mon, Mar 03, 2025 at 01:39:11AM +0800, Blair Noctis wrote: I installed mutt and tried to reply to that email, and mutt showed me the Content-Transfer-Encoding: base64 source. I'm not sure if that's what you saw. If you saw the decoded text, I copied it into vim and vim seems to wrap it just fine. Thankfully you usually don't copy the message into vim, but you hit R)eply, L)ist Reply or reply A)ll and mutt fires up the Editor for you. Would you kindly show me how it looked on your side? In the Editor, the long lines show up as long lines, with the disadvantage that you either quote them not at all, or completely, or have to go through intra-line editing to just leave what you want to quote, and if it's a really long line vim will not show it at all instead of partially. That is surely something that one could adapt to, but I'd hate having to. Notes and Outlook have done incredible damage to E-Mail culture, introducing Top-Posting as the widely accepted (but totally inferior) way to have discussions in e-mail. Please let us consider using a method that doesn't make discussions harder. The biggest problem with Outlook is that getting it to use plain text in any sane way is a lot of work. It really messes up quoting. So if you're conversing with someone who uses Outlook but hasn't reconfigured it top posting or changing text colors for HTML mail is the only "sane" way to tell who wrote what. With how pervasive it is in the corporate world; it's going to be an uphill battle to change. The "New Outlook" with Microsoft 365 is even worse. I can't find a way to even *configure it* to do plain text and quoting sanely. FWIW; I think that Thunderbird mostly gets things right when you send plain text email. In the composing window you'll see where it does the wrapping for you at ~72-75 characters. It defaults F=f, and when I looked at the source of what it was viewing, it was sent with the breaks on 72 for my test emails. When you open an email the width automatically goes to match the width of your window. Seems like the best of both worlds to me.
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On 3/7/25 12:42, Soren Stoutner wrote: On Friday, March 7, 2025 11:33:53 AM MST Simon Josefsson wrote: > pan...@disroot.org writes: > > I urge Debian to rethink its decision to officially include non-free > > firmware and correct the social contract. Instead of making non-free > > firmware the default, Debian should ensure that users consciously > > choose to install it while being made aware of the implications. > > I agree and would personally come back to use Debian on some of my > laptops if there was a supported way to install Debian from official > installer images that did not promote non-free software by including > firmware on them. > > The recent AMD Microcode vulnerability is a good case-study on the > dangers of permitting non-free code to run on your CPU: > > https://bughunters.google.com/blog/5424842357473280/zen-and-the-art- of-microco > de-hacking > > There is no way for me as a user to audit that the Debian installer > images is not including vulnerable microcode, since source code for the > firmware is not available. FTR there is a kernel patch that was introduced specifically because of this vulnerability. https://git.kernel.org/torvalds/c/50cef76d5cb0e199cda19f026842560f6eedc4f7 The kernel patch separately verifies the sha256 of the microcode attempting to be loaded on an affected processor (both early or late) and rejects modified microcode. If you are concerned with malware having tampered with the microcode before the kernel is loaded, there is a TPM2 PCR event log that the firmware records. You can validate that the TPM2 PCR event log and the TPM2 PCR values match to ensure that you can trust it. This is one of the checks that 'fwupdmgr security' will run and report if they don't match. OpenPGP_0x2D192CA624770276.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1099862: ITP: passim -- A local caching server
Package: wnpp Severity: wishlist Owner: Mario Limonciello X-Debbugs-Cc: debian-devel@lists.debian.org, supe...@gmail.com * Package name: passim Version : 0.1.9 * URL : https://github.com/hughsie/passim * License : LGPL2.1 Programming Lang: C Description : A local caching server Passim is used to cache small files (such as those from a CDN) to be able to share with other clients on the local network that would otherwise be downloading the same files. I'm planning to maintain it in the debian-efi team as it is an optional dependency for fwupd. Fwupd can use it to fetch files from the CDN and then share them with other clients on the same local network.
Re: Change the expectation that emails should wrap at 80 characters
Mario Limonciello (hints of format=flowed support) Thanks for the summary. I am of the camp of f=f. At least with the MUA I'm using most of the time (Thunderbird) this is the default, and no one has complained to me directly about it for any email sent to the Kernel community or Debian community. As it seems to be a polarizing discussion I do wonder if maybe it would make most sense to have a "proper" vote to determine which way the "silent majority" of developers actually lean? OpenPGP_0x2D192CA624770276.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Interesting learnings about Guix contributor dynamics that apply to Debian?
On 5/23/25 11:59, Andrew M.A. Cater wrote: On Fri, May 23, 2025 at 10:00:22AM -0400, Roberto C. Sánchez wrote: On Fri, May 23, 2025 at 10:59:47AM +0200, Marc Haber wrote: On Fri, 23 May 2025 08:57:36 +0100, "Jonathan Dowland" wrote: On Thu May 22, 2025 at 4:56 PM BST, Ahmad Khalifa wrote: It's alive, not sure if sponsored by Red Hat/Mozilla, but both use it (and Kernel, KDE, the list goes on). Red Hat have transitioned almost entirely to JIRA. Thankfully that's not an option for us (not dfsg free). But it could be an option. If Atlassian offered the Debian project free (gratis) use of their platform (especially if they handle the administration), why wouldn't we accept? Three points: Having used Jira - I think I'd rather stick hot needles in my eyes. Atlassian are *EXTREMELY* unlikely to offer anyone gratis use of their software. Do remember why we have Git to replace Bitkeeper - free gifts can get withdrawn. Just my €0.02 If we're at that point of "considering" having a second system to the BTS (or to augment) what would be wrong with using Gitlab issues on Salsa? I've done little research on the matter besides a quick search [1], but presumably the BTS software could be modified to build a bridge with the Gitlab issues? Then perhaps maintainers for packages that want to opt in could set a flag to have the BTS forward everything from BTS to Salsa for their packages. [1] https://docs.gitlab.com/administration/incoming_email/
