Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
Hi, On Tue, 13 Oct 2020, at 06:53, Noah Meyerhans wrote: > On Fri, Oct 09, 2020 at 12:14:23PM +0200, Stephan Seitz wrote: > > That’s why I need to know the different programs anyway. Why would I go for > > something like open which can only use one program for the file type? > You wouldn't, but that's not the point. The availability of > /usr/bin/open wouldn't preclude your use of whatever program you want to > use. What it would do is provide a convenient utility to support people > who don't (yet) have a preference for what application they want to use > to open a file. Maybe they have only basic needs, or are unfamiliar > with the file type and its associated commands. There are surely many > other reasons. I’m a potential user of "open", since I currently use xdg-open instead, and it’s longer to type. Very often I can’t or don’t want to remember what the binary of the application is called, especially in case of GNOME apps, which no longer use the application name in the UI: eog, evince etc. -- Cheers, Andrej
Re: how to add small console application to debian linux distribution?
Hi,
it's nice that you want to make the software available for others, but
this task is simply way to simple to have a special package for it.
The whole thing can be done with a few shell commands, so there is no
need for a tool in my opinion.
For example a perl oneliner doing the line substitution:
export myopt='bla'; perl -i -pe
's/^(GRUB_CMDLINE_LINUX_DEFAULT=)\"(.*)\"/$1\"$2 $ENV{myopt}\"/' /tmp/grub
However nobody prevents you for creating a debian package even for a
small application or a script, a good starting place probably is the New
Maintainer's Guide: https://www.debian.org/doc/manuals/maint-guide/
Best,
Alex
On 10/12/20 2:11 PM, pe pi wrote:
Hello,
im not sure
if you install one linux machine, maybe this tool will be unnecessary.
but if you will install for example 10 linux machines it will be usefull.
i think better solution will be if tools like this be a part of linux
main install.
pe pi
On 12. 10. 2020 13:41, Gard Spreemann wrote:
pe pi writes:
1) Open Terminal
2) Type: sudo nano /etc/default/grub
3) Find the line starting with GRUB_CMDLINE_LINUX_DEFAULT, and add
video=hyperv_fb:[the resolution you want].
So my line ends up looking like this:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=hyperv_fb:1366x768"
4) Write the changes and quit nano
5) Run: sudo update-grub
6) Reboot the virtual machine run: sudo reboot
... and i have developed console application which do it this way ...
sudo hypervscrres --set grub 1366x768 update reboot yes
... and all application variants of use looks like this ...
sudo hypervscrres --help
sudo hypervscrres --get grub
sudo hypervscrres --set grub 1366x768
sudo hypervscrres --set grub 1366x768 update
sudo hypervscrres --set grub 1366x768 update reboot
sudo hypervscrres --set grub 1366x768 update reboot yes
yes | sudo hypervscrres --set grub 1366x768 update reboot
Hello,
Are you sure that potential users of your program will find it easier to
install your program and run it than it is to perform the original task
that your program is meant to replace?
-- Gard
Re: how to add small console application to debian linux distribution?
Hi pe pi and others,
Quoting Alex Mestiashvili (2020-10-13 09:54:15)
> it's nice that you want to make the software available for others, but
> this task is simply way to simple to have a special package for it.
> The whole thing can be done with a few shell commands, so there is no
> need for a tool in my opinion. For example a perl oneliner doing the
> line substitution:
>
> export myopt='bla'; perl -i -pe
> 's/^(GRUB_CMDLINE_LINUX_DEFAULT=)\"(.*)\"/$1\"$2 $ENV{myopt}\"/' /tmp/grub
Beware that export mangles some characters special to POSIX shell.
This is more reliable and shorter (also by using \K and no capture):
myopt='bla' perl -i -pe
's/^GRUB_CMDLINE_LINUX_DEFAULT=\".*\K(?=\")/ $ENV{myopt}/' /tmp/grub
I agree with the general point that this feels too tiny and narrow
purpose for a Debian package.
I do recognize, however, that oneliners like the above are easy to do
wrong, and that's scary when it is the bootloader configuration you are
messing with.
Would it perhaps be interesting for you to generalize your script to a
"grub-set-bootarg" script which adds _any_ option to grub, or replace
its value for an option already declared)?
You could then propose the package maintainers of grub to include that
script with the grub package.
If grub maintainers reject your proposed script, you might consider
generalizing even further to a "configfile-set-arg" script that first
tries to detect syntax, and for a syntax recognized does the surgery.
You could then propose to have that script added to package moreutils.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Re: how to add small console application to debian linux distribution?
Hi,
it doesnt matter if it is written in c language or perl script or in
something else
main goal is to make it that simple, how can it be
and as a part of linux main install, not as an optional package
available in every variants of shell
pe pi
On 13. 10. 2020 9:54, Alex Mestiashvili wrote:
Hi,
it's nice that you want to make the software available for others, but
this task is simply way to simple to have a special package for it.
The whole thing can be done with a few shell commands, so there is no
need for a tool in my opinion.
For example a perl oneliner doing the line substitution:
export myopt='bla'; perl -i -pe
's/^(GRUB_CMDLINE_LINUX_DEFAULT=)\"(.*)\"/$1\"$2 $ENV{myopt}\"/'
/tmp/grub
However nobody prevents you for creating a debian package even for a
small application or a script, a good starting place probably is the
New Maintainer's Guide: https://www.debian.org/doc/manuals/maint-guide/
Best,
Alex
On 10/12/20 2:11 PM, pe pi wrote:
Hello,
im not sure
if you install one linux machine, maybe this tool will be unnecessary.
but if you will install for example 10 linux machines it will be
usefull.
i think better solution will be if tools like this be a part of linux
main install.
pe pi
On 12. 10. 2020 13:41, Gard Spreemann wrote:
pe pi writes:
1) Open Terminal
2) Type: sudo nano /etc/default/grub
3) Find the line starting with GRUB_CMDLINE_LINUX_DEFAULT, and add
video=hyperv_fb:[the resolution you want].
So my line ends up looking like this:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=hyperv_fb:1366x768"
4) Write the changes and quit nano
5) Run: sudo update-grub
6) Reboot the virtual machine run: sudo reboot
... and i have developed console application which do it this way ...
sudo hypervscrres --set grub 1366x768 update reboot yes
... and all application variants of use looks like this ...
sudo hypervscrres --help
sudo hypervscrres --get grub
sudo hypervscrres --set grub 1366x768
sudo hypervscrres --set grub 1366x768 update
sudo hypervscrres --set grub 1366x768 update reboot
sudo hypervscrres --set grub 1366x768 update reboot yes
yes | sudo hypervscrres --set grub 1366x768 update reboot
Hello,
Are you sure that potential users of your program will find it
easier to
install your program and run it than it is to perform the original task
that your program is meant to replace?
-- Gard
Archive rebuilds as a service
Hi, FYI: I'm able to run archive rebuilds on a quite regular basis. I do that to find (and file) FTBFS bugs, but it's also possible to test candidate changes in Debian (for example, new versions of compilers, interpreters, or other packages that are common build-depends). If that's useful for you or your team, please get in touch with me. I'll ask you to provide: 1) a script that customizes a chroot. Examples are available at: https://salsa.debian.org/lucas/collab-qa-tools/-/tree/master/modes 2) a list of source packages to test-build. (if there are many of them and if it's not trivial to determine the exact set of packages to test-build, building all of unstable is of course possible) I usually factor a few of those rebuilds together, so you might have to wait a few weeks. There's some manual process involved, so please also provide a small explanation of why that's useful. Lucas
epoch bump for libtraceevent
Hi All, libtracevent is currently being packaged from the linux kernel source and as such it has the version of '5.8.14-1' same as the kernel. As reported in #971976, the upstream libtraceevent now lives in its own repo and has a version of '1.1.0' So, I will need to add an epoch to the version to package it directly from its upstream repo. Current version: 5.8.14-1 Proposed version: 1:1.1.0-1 If its ok then I will go ahead with it. -- Regards Sudip
Re: Co-maintaining some packages
On Fri, Oct 09, 2020 at 09:00:44PM -0500, Brett Gilio wrote: > I am a long term user of Debian GNU/Linux (and a regular contributor to > GNU Guix). I have been using Debian or some other variant of GNU/Linux > for 10+ years, in both professional and personal capacities. I notice > that some packages that I depend on are not getting much attention, and > I would like to offer help. I currently maintain my own repository using > reprepro, but would like to return the packages I maintain on my own to > the community as a whole. Thank you for your interest and offer of help! Generally speaking, the best way to set up collaborative maintenance for such packages is to put them up on Salsa [0], for that you'll need to convert them to Git packaging [1] if they aren't already on it (e.g. blank VCS field for MLton tells me that it's not). [0] https://wiki.debian.org/Salsa [1] https://wiki.debian.org/PackagingWithGit > For example, MLton [0] could use updating, and working through the > different branches. Likewise for PolyML, and SMLnj. I think helping with > these three collections of packages would be a good first step into > possibly helping Debian in the future. Sounds like your interests are relevant for the Debian Science team [2] (which is marked dead) and Debian Science Maintainers team [3], getting in touch with them would be a good place to start. [2] https://wiki.debian.org/DebianScience -- Dmitry Borodaenko
Re: Co-maintaining some packages
On Tue, Oct 13, 2020 at 09:52:24AM -0700, Dmitry Borodaenko wrote: > Sounds like your interests are relevant for the Debian Science team [2] > (which is marked dead) and Debian Science Maintainers team [3], getting > in touch with them would be a good place to start. Oops, messed up my references, above should read: "Debian Science mailing list (which is marked dead)[2] and Debian Science Maintainers team [3]" [2] https://lists.debian.org/debian-science/ [3] https://wiki.debian.org/DebianScience -- Dmitry Borodaenko
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
* Noah Meyerhans [201013 00:54]: > "open" is a verb commonly used to describe the action of accessing a > file in Linux. You used it yourself above, and it's one of the most > prominent functions in the file API. It seems sensible to provide a > tool that matches the verb most commonly used to describe this action. > > The availability of > /usr/bin/open wouldn't preclude your use of whatever program you want to > use. What it would do is provide a convenient utility to support people > who don't (yet) have a preference for what application they want to use > to open a file. Maybe they have only basic needs, or are unfamiliar > with the file type and its associated commands. There are surely many > other reasons. Earlier in this thread, the program "see", part of mime-support, was mentioned as already providing this functionality. What does the proposed "open" do that "see" doesn't, or what does it do in a significantly different way that having both of them would be a benefit? So far, the only answer I have seen is that MacOS users are familiar with open. To me, this is not significant enough. A symlink or cover script that does simple massaging of the arguments, which invokes an existing utility like run-mailcap, would be better served by a macos-helpers package that can become a collection of utilities that help users coming from MacOS feel more comfortable in Linux. These wouldn't clutter the $PATH space for users who did not want them. The other difference that I remember being mentioned is that the proposed open only handled files, not URLs, but the author was willing to add that functionality to open if it was deemed popular. Describing a clear benefit to having both open and see would help immensely. Alternatively, convincing the mime-support authors that open should replace see would also work. If open does not provide any real benefit over see, I would not want it to be in the transitive Depends or Recommends of a standard Debian desktop installation, which would then obviate its usefulness in the archive (except as a macos-helper as above). ...Marvin
Re: Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
On Tue, Oct 13, 2020 at 1:52 PM Marvin Renich wrote:
>
> * Noah Meyerhans [201013 00:54]:
> > "open" is a verb commonly used to describe the action of accessing a
> > file in Linux. You used it yourself above, and it's one of the most
> > prominent functions in the file API. It seems sensible to provide a
> > tool that matches the verb most commonly used to describe this action.
> >
> > The availability of
> > /usr/bin/open wouldn't preclude your use of whatever program you want to
> > use. What it would do is provide a convenient utility to support people
> > who don't (yet) have a preference for what application they want to use
> > to open a file. Maybe they have only basic needs, or are unfamiliar
> > with the file type and its associated commands. There are surely many
> > other reasons.
>
> Earlier in this thread, the program "see", part of mime-support, was
> mentioned as already providing this functionality. What does the
> proposed "open" do that "see" doesn't, or what does it do in a
> significantly different way that having both of them would be a benefit?
>
> So far, the only answer I have seen is that MacOS users are familiar
> with open. To me, this is not significant enough. A symlink or cover
> script that does simple massaging of the arguments, which invokes an
> existing utility like run-mailcap, would be better served by a
> macos-helpers package that can become a collection of utilities that
> help users coming from MacOS feel more comfortable in Linux. These
> wouldn't clutter the $PATH space for users who did not want them.
>
> The other difference that I remember being mentioned is that the
> proposed open only handled files, not URLs, but the author was willing
> to add that functionality to open if it was deemed popular.
>
> Describing a clear benefit to having both open and see would help
> immensely. Alternatively, convincing the mime-support authors that open
> should replace see would also work.
This thread is full of people who strongly prefer "open" over "see"
("see" is also little known). Add me to that list. In this case, I
don't care whether other operating systems do it or not.
I think "see" was used because "open" was not available. I don't know
why you are so interested in having "see" go away. It could be removed
but it's not clear at all to me that it needs to be removed at the
same time "open" is added. (I don't see anything else that would want
to use "see".)
Thanks,
Jeremy Bicha
> If open does not provide any real benefit over see, I would not want it
> to be in the transitive Depends or Recommends of a standard Debian
> desktop installation, which would then obviate its usefulness in the
> archive (except as a macos-helper as above).
>
> ...Marvin
Help with contacting Ubuntu devs for updating critically broken packages
Hi all (please Cc) is there a way to update hopelessly broken packages in Ubuntu Focal LTS? (packages in question are onedrive and in particular calibre - I refrain from commenting on the reasons behind calibre) Ubuntu seems to pull at arbitrary intervals rather incomplete packages that end up in LTS releases, and upstream gets flooded with bug reports. Thanks for any pointer Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: Help with contacting Ubuntu devs for updating critically broken packages
On Wed, 14 Oct 2020, Norbert Preining wrote: Hi all (please Cc) is there a way to update hopelessly broken packages in Ubuntu Focal LTS? (packages in question are onedrive and in particular calibre - I refrain from commenting on the reasons behind calibre) Ubuntu seems to pull at arbitrary intervals rather incomplete packages that end up in LTS releases, and upstream gets flooded with bug reports. Yes, Ubuntu has a Stable Release Update process[1], but this is probably better discussed on an Ubuntu mailing list, rather than Debian. Scott [1] https://wiki.ubuntu.com/StableReleaseUpdates
Re: Help with contacting Ubuntu devs for updating critically broken packages
On Wed, 14 Oct 2020 07:23:58 +0900, Norbert Preining wrote: >Hi all > >(please Cc) > >is there a way to update hopelessly broken packages in Ubuntu Focal >LTS? > >(packages in question are onedrive and in particular calibre - I >refrain from commenting on the reasons behind calibre) > >Ubuntu seems to pull at arbitrary intervals rather incomplete packages >that end up in LTS releases, and upstream gets flooded with bug >reports. > >Thanks for any pointer > You are probably looking for this: https://wiki.ubuntu.com/StableReleaseUpdates The upload needs to be confirmed that it fixes the problem by someone else than you before it gets into Ubuntu proper. I haven't had any good experience with it. -- Andreas Rönnquist mailingli...@gusnan.se andr...@ronnquist.net
Re: Co-maintaining some packages
Dmitry Borodaenko writes: > > Generally speaking, the best way to set up collaborative maintenance for > such packages is to put them up on Salsa [0], for that you'll need to > convert them to Git packaging [1] if they aren't already on it (e.g. > blank VCS field for MLton tells me that it's not). > Thankfully, MLton is indeed using Git. That field will need to be updated. > > [0] https://wiki.debian.org/Salsa > [1] https://wiki.debian.org/PackagingWithGit > >> For example, MLton [0] could use updating, and working through the >> different branches. Likewise for PolyML, and SMLnj. I think helping with >> these three collections of packages would be a good first step into >> possibly helping Debian in the future. > > Sounds like your interests are relevant for the Debian Science team [2] > (which is marked dead) and Debian Science Maintainers team [3], getting > in touch with them would be a good place to start. > > [2] https://wiki.debian.org/DebianScience > Could you explain what "marked dead" means in this context? Is the Debian Science team different from the Debian Science Maintainers team? Thank you for clarifying the issue. -- Brett M. Gilio https://brettgilio.com
Re: Help with contacting Ubuntu devs for updating critically broken packages
Hi Scott, hi Andreas, thanks for your answers. On Tue, 13 Oct 2020, Scott Talbert wrote: > better discussed on an Ubuntu mailing list, rather than Debian. I have sent an email to ubuntu-devel with detailed explanations. I hoped for some contact here of a Debian *and* Ubuntu developer with experience in these kinds of actions. Best Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: Co-maintaining some packages
Brett Gilio writes: > > Could you explain what "marked dead" means in this context? Is the > Debian Science team different from the Debian Science Maintainers team? > Thank you for clarifying the issue. Update, I see what you mean. The blend mailing list is marked dead. -- Brett M. Gilio https://brettgilio.com
Re: Co-maintaining some packages
Dmitry Borodaenko writes: > > Oops, messed up my references, above should read: "Debian Science > mailing list (which is marked dead)[2] and Debian Science Maintainers > team [3]" > > [2] https://lists.debian.org/debian-science/ > [3] https://wiki.debian.org/DebianScience It sounds like the Debian Science Maintainers team uses https://alioth.debian.org/, but that URL is not resolving. -- Brett M. Gilio https://brettgilio.com
Re: Co-maintaining some packages
Brett Gilio writes: > It sounds like the Debian Science Maintainers team uses > https://alioth.debian.org/, but that URL is not resolving. Update: Ignore this, just a case of an outdated Wiki. :) -- Brett M. Gilio https://brettgilio.com
Re: Help with contacting Ubuntu devs for updating critically broken packages
Thank you, Norbert, for trying to get this fixed. calibre upstream already had 6 bug reports and counting in just the last week, for an issue: - that was fixed in May - only applicable to people field-testing the python3 transition which was marked as beta and is currently superseded by stable releases Obviously, upstream getting bug reports due to distro respins shipping *outdated* and broken beta code is one of those "non-ideal" situations... > The upload needs to be confirmed that it fixes the problem by someone > else than you before it gets into Ubuntu proper. I haven't had any good > experience with it. I guess it would be nice if "I'm the debian maintainer, you accidentally pulled a beta build which is RC-buggy" had some weight to it. We'll see how it goes, I suppose. There will be major problems if Ubuntu keeps this in an LTS release for the next 5 years. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
