Re: Search for porterbox machines on the command line
On Fri, Jun 13, 2014 at 02:48:05PM -0400, Jon Bernard wrote: > Heya, I just created a small utility that dumps the porterbox machine > list to stdout, which makes looking up a test machine for a particular > architecture much quicker (at least for me). I'll add my script[0] to the list as well. It's just a small wrapper around ldapsearch. Paul Wise requested a much more featureful script in #469263. That bug might be a good place to describe the various requirements people want and try to come up with something common. [0]: http://paste.debian.net/104880/ -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: There should not be dependencies on systemd (Was: Cinnamon environment now available in testing)
On Sun, Sep 07, 2014 at 02:20:33AM +0200, Guillem Jover wrote: > On Sun, 2014-09-07 at 00:05:59 +0200, Marco d'Itri wrote: > > On Sep 06, Noel Torres wrote: > > > It is just wrong to have dependencies on the init system. > > > If you need dbus, you should Depend on dbus, and systemd should > > > Provides dbus. > > > This is why most of these dependencies are on libpam-systemd, which does > > not depend on systemd. > > That's incorrect: No, it isn't. It was just poorly worded. > $ apt-cache show libpam-systemd | egrep '^(Version|Depends):' > Version: 214-1 > Depends: libc6 (>= 2.17), libcap2 (>= 2.10), libpam0g (>= 0.99.7.1), > systemd (= 214-1), libpam-runtime (>= 1.0.1-6), dbus, > systemd-sysv | systemd-shim (>= 6-4) While libpam-systemd does Depend on the systemd binary package, that package does not enforce systemd as the init system. The relevant relationship there is the ORed “systemd-sysv | systemd-shim (>= 6-4)”. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy -- 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/20140907011959.gf26...@freya.jamessan.com
Re: Trimming priority:standard
On Sat, Sep 13, 2014 at 12:58:04PM +0200, Didier 'OdyX' Raboud wrote: > Le vendredi, 12 septembre 2014, 13.55:53 Joey Hess a écrit : > > Theodore Ts'o wrote: > > > One thought... there will probably be trademark concerns with > > > "unix".[1] So we might have to choose a name for the tasksel task > > > to be someting like "unix-like". > > > > Or we could just call it "standard system". > > Could we make sure the full "vim" is in that then? I keep contemplating packaging ex-vi and advocating to replace vim-tiny with that. After all, the intent is to have something providing /usr/bin/vi, as one expects to have on a *nix system, so why not have it actually be vi? Then I could drop all the annoying packaging we had to add (and I have to maintain) to the vim packages, although it did help find some corner cases in handling of diversions, and stop getting annoyed at people complaining about vim-tiny. > I miss it on every > new installation and I'm quite sure that's not uncommon. Then install vim (or one of the other more featured binary packages) when you uninstall vim-tiny & nano. Just because the package is included as part of the install doesn't mean you have to use it. I'm sure there are plenty of people that remove vim-tiny and install some other non-vi(m) editor too. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Trimming priority:standard
On Mon, Sep 15, 2014 at 10:56:16AM -0600, Bob Proulx wrote: > James McCoy wrote: > > I keep contemplating packaging ex-vi and advocating to replace vim-tiny > > with that. After all, the intent is to have something providing > > /usr/bin/vi, as one expects to have on a *nix system, so why not have it > > actually be vi? > > The package is already done. > > apt-cache show nvi That's an odd answer to "why not have it actually be vi?". Sure, nvi is a vi-clone, but it's not the actual vi. Whether that really matters much to anyone is a different question. It's worth noting that nvi was the package that previously filled the role for providing /usr/bin/vi, before vim-tiny replaced it. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy -- 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/20140915194645.go26...@freya.jamessan.com
Re: Trimming priority:standard
On Mon, Sep 15, 2014 at 10:07:08PM +0200, Jonas Meurer wrote: > Am 13.09.2014 um 12:58 schrieb Didier 'OdyX' Raboud: > > Le vendredi, 12 septembre 2014, 13.55:53 Joey Hess a écrit : > >> Theodore Ts'o wrote: > >>> One thought... there will probably be trademark concerns with > >>> "unix".[1] So we might have to choose a name for the tasksel task > >>> to be someting like "unix-like". > >> > >> Or we could just call it "standard system". > > > > Could we make sure the full "vim" is in that then? I miss it on every > > new installation and I'm quite sure that's not uncommon. > > At least vim-tiny should provide /usr/bin/vim, so a 'vim' executable is > actually available on the "standard system". I would be fine with the > stripped-down vim from vim-tiny if at least 'vim ' would work. Many people were not fine with that and complained about unexpected behavior (i.e., their normal vim config blowing up in their face) when running "vim" from vim-tiny. That's why I made the choice to have vim-tiny stop providing the /usr/bin/vim alternative. You can see more discussion about my stance in #681012 and related bug reports referenced therein. As I said in my other reply, the intent of vim-tiny is to provide a vi command. The fact that it is using Vim to do so is the means, not the end. > At the moment I pretty often end up either installing full vim or > replacing 'vim' with 'vim.basic' on the commandline. Which is fine, because you actually want something that behaves like most people would expect Vim to, not something that behaves more like vi. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Trimming priority:standard
On Tue, Sep 16, 2014 at 03:54:21AM +0200, Marco d'Itri wrote: > On Sep 16, James McCoy wrote: > > > As I said in my other reply, the intent of vim-tiny is to provide a vi > > command. The fact that it is using Vim to do so is the means, not the > > end. > I think it's more complex than this: I like vim-tiny because I can use > it on small images without wasting space for the dependencies, and after > setting nocompatible it's as much as good as regular vim for system > administration tasks. The very informed/knowledgeable user isn't the one that soured my perception of the choice to have vim-tiny provide /usr/bin/vim. It's rather the people that know enough to get by on Vim and be comfortable installing various plugins, but don't really delve much deeper into Vim. They setup a new computer, deploy their dotfiles somehow, run vim and then see things not working because only vim-tiny is installed, so a bug gets filed. So while I agree that being able to "flip the switch" to have /usr/bin/vi act more like a typical Vim install for that editing session is useful, I don't agree the same to be true about vim-tiny also providing /usr/bin/vim. A standard install provides /usr/bin/vi and if you happen to know it's provided via a stripped down build of Vim, then feel free to take advantage of that. Otherwise, actively install Vim to get what is going to behave as expected. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: r-base-core upload to unstable does not respect freeze policy
On Nov 11, 2014 10:34 AM, "Andreas Tille" wrote: > I was close to trap into the pitfall to uploaded an RC bug fix built in > an unstable chroot which would not be able to migrate to testing since > the R cdbs helper injects a > > Depends: r-base-core (>= ) This looks like more fallout from #704805 not being fixed. A similar discussion happened last freeze in the thread starting at < https://lists.debian.org/20824.26651.775823.264...@max.nulle.part>.
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Tue, Nov 18, 2014 at 04:24:30PM +, Ian Jackson wrote:
> Guido Günther writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
> repositories"):
> > On Fri, Nov 14, 2014 at 03:44:35PM +, Ian Jackson wrote:
> > > Current practice seem so be to replace both : and ~ with _. Unless
> > > we
> >
> > This didn't work well so gbp switched to what Raphael documented years
> > ago (: -> %, ~ -> _).
>
> In fact it appears I noticed this earlier and already fixed dgit to
> work this way (but had forgotten...)
>
> I have updated
>https://wiki.debian.org/Punctuation
>
> Are there other gitish tools which are still using _ for both ?
Hmm, seems debcommit is converting ~ to . and stripping the epoch
entirely. I guess at least the former should probably be changed to
follow the common pattern.
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
signature.asc
Description: Digital signature
Re: debuild/dpkg-buildpackage behaves not as expected
On Wed, May 16, 2012 at 09:05:21AM +0200, Olе Streicher wrote: > What is the rationale behind the automatic reversal of the applied > patches before a cleanup? Quoting from the bug I meant to refer you to (#649531) when closing the debuild bug: On one hand, in dpkg's source format v3, the patched source is considered to be standard "unpacked" form. … On the other hand, some people like to work most of the time with the unpatched source, as in pre-v3 days. … "dpkg-source --after-build" distinguishes between the two cases by checking for the ".pc/.dpkg-source-unapply" file, which is added when "dpkg-source --before-build" notices that patches were not already applied. You can ensure patches remain applied by applying the patches yourself before starting the build. QUILT_PATCHES=debian/patches quilt push -a debuild; # or dpkg-buildpackage, or whatever So, you have a method that you can work with. My main point was that you should be trying to drive change through dpkg, not through devscripts. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: debuild/dpkg-buildpackage behaves not as expected
On Wed, May 16, 2012 at 04:23:05PM +0200, Olе Streicher wrote: > Unpatching the sources *before* the build process was cleaned up makes > no sense to me at all. Could you provide a use case for that? As was described in #649531: vcs clone cd repo ... tweak a little ... dpkg-buildpackage; # applies patches, builds, and unapplies patches vcs diff; # looks good? vcs commit > > dpkg-source leaves the source in the same state it finds it before > > build. I think Goswin meant dpkg-buildpackage here. > because it does *not* leave the sources in the same state. Yes, it does. If you started with patches applied, then they will still be applied after calling "dpkg-buildpackage". If you didn't have patches applied, then "dpkg-buildpackage" will apply the patches, build and unapply the patches. -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: debuild/dpkg-buildpackage behaves not as expected
On Thu, May 17, 2012 at 08:21:23AM +0200, Thibaut Paumard wrote: > Le 17/05/12 00:25, James McCoy a écrit : > > On Wed, May 16, 2012 at 04:23:05PM +0200, Olе Streicher wrote: > >> Unpatching the sources *before* the build process was cleaned up > >> makes no sense to me at all. Could you provide a use case for > >> that? > > > > As was described in #649531: > > > > vcs clone cd repo ... tweak a > > little ... dpkg-buildpackage; # applies patches, builds, and > > unapplies patches > > Precisely, the point is that should be: > applies patches, builds, *cleans* and unapplies patches So, you would want dpkg-buildpackage to be an expensive no-op? Running the clean target means that you no longer have the artifacts produced by the build. -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: gitpkg with a quilt export hook
On Thu, May 24, 2012 at 01:54:23PM +1000, Brian May wrote: > On 23 May 2012 23:31, Bastien ROUCARIES wrote: > > Ok step for imagemagick > > Thanks. > > Just trying this out now. Anyway I can avoid gitpkg asking the > following question? I think No is the only correct answer when using > pristine-tar (it already replaced the file anyway), but I can't see > anyway of making gitpkg assume No without asking. > > $ gitpkg debian/2.4.5a-1 upstream/2.4.5a Drop the upstream branch. $ gitpkg debian/2.4.5a-1 -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: gitpkg with a quilt export hook
On Thu, May 24, 2012 at 06:08:11AM -0400, James McCoy wrote: > On Thu, May 24, 2012 at 01:54:23PM +1000, Brian May wrote: > > On 23 May 2012 23:31, Bastien ROUCARIES wrote: > > > Ok step for imagemagick > > > > Thanks. > > > > Just trying this out now. Anyway I can avoid gitpkg asking the > > following question? I think No is the only correct answer when using > > pristine-tar (it already replaced the file anyway), but I can't see > > anyway of making gitpkg assume No without asking. > > > > $ gitpkg debian/2.4.5a-1 upstream/2.4.5a > > Drop the upstream branch. > > $ gitpkg debian/2.4.5a-1 Also, see gitpkg.force-overwrite-orig in gitpkg(1). -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Search for a file in all Debian source packages
On Mon, Jun 04, 2012 at 06:40:18PM -0400, Yaroslav Halchenko wrote: > > On Mon, 04 Jun 2012, Jakub Wilk wrote: > > >I have just realized that this helpful Contents-sources.gz I had > > >on my drive is more than a year old and is not updated by cron as > > >I thought it was ;-) > > > >Raphael, is there a chance to reincarnate this "service" or was it > > >superseded by a better solution? > > > http://http.debian.net/debian/dists/unstable/main/Contents-source.gz > > awesome -- thanks -- that is what I was looking for -- great to see it > now "officially" available > > FWIW: here is the relevant (still open) wishlist bug for apt-file: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632254 > apt-file: option to search Contents-source.gz files $ apt-file -a source update … $ apt-file -a source os_unix.c chromium-browser: /src/third_party/sqlite/src/src/os_unix.c db: /lang/sql/sqlite/src/os_unix.c db5.3: /lang/sql/sqlite/src/os_unix.c iipimage: /fcgi/libfcgi/os_unix.c inadyn: /src/os_unix.c kompozer: /mozilla/db/sqlite3/src/os_unix.c libfcgi: /libfcgi/os_unix.c lyx: /src/support/os_unix.cpp mame: /src/osd/sdl/sdlos_unix.c mess: /src/osd/sdl/sdlos_unix.c ncbi-blast+: /c++/src/corelib/ncbi_os_unix.cpp olsrd: /lib/tas/src/os_unix.c reaver: /src/utils/os_unix.c refit: /.pc/gptsync_dont_truncate.patch/gptsync/os_unix.c refit: /.pc/gptsync_nom_nom_nom_newline.patch/gptsync/os_unix.c refit: /.pc/gptsync_quiet_mode.patch/gptsync/os_unix.c refit: /gptsync/os_unix.c sqlite3: /.pc/20-hurd-locking-style.patch/src/os_unix.c sqlite3: /src/os_unix.c vim: /src/os_unix.c wpa: /src/utils/os_unix.c wpasupplicant: /src/utils/os_unix.c -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: [RFC] Add upstream VCS info to control file
On Jun 14, 2012 11:51 AM, "Thomas Goirand" @ debian.org > wrote: > > 3/ How to achieve it > |=-=-=-=-=-=-=-=- > |To acheive this, we would need something like this: > > ||Vcs-Git-Debian-Branch-Name: debian/unstable > ||Vcs-Git: > |git://anonscm.debian.org<http://anonscm.debian.org/openstack/nova.git> / <http://anonscm.debian.org/openstack/nova.git>openstack<http://anonscm.debian.org/openstack/nova.git> / <http://anonscm.debian.org/openstack/nova.git>nova.git<http://anonscm.debian.org/openstack/nova.git> Since devscripts 2.11.7, you can do this: Vcs-Git: git://anonscm.debian.org<http://anonscm.debian.org/openstack/nova.git> / <http://anonscm.debian.org/openstack/nova.git>openstack<http://anonscm.debian.org/openstack/nova.git> / <http://anonscm.debian.org/openstack/nova.git>nova.git<http://anonscm.debian.org/openstack/nova.git>-b debian/unstable I thought the patch that added that also updated the documentation, but it looks like documentation still needs to be added. -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy @ debian.org >
Re: Enabling uupdate to simply remove files from upstream source
On Mon, Aug 20, 2012 at 09:39:34AM +0200, Andreas Tille wrote: > On Mon, Aug 20, 2012 at 12:10:19AM +0200, gregor herrmann wrote: > > Next guess: > > > > Dpkg::Control::Hash - parse and manipulate a block of RFC822-like fields > > (libdpkg-perl) > > How would you compare this to Jonas solution using > > use Parse::DebControl; Using Dpkg::Control::Hash would be preferable since we're already using that library in devscripts. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Filtering bugs from apt-listbugs reports (was Re: Bug severity and private data disclosure)
On Jun 10, 2013 1:28 PM, "Andrey Rahmatullin" wrote: > > On Mon, Jun 10, 2013 at 04:15:27PM +0200, Vincent Lefevre wrote: > > > It's amazing how much simpler Debian life becomes if one simply ignores > > > bug severities entirely. Of course harder to do nearer to release, but > > > we live in a time of relative luxury right now… > > > > This is important for apt-listbugs, which takes into account RC bugs by > > default > Which too is not ideal: for example, I don't think users should care about > such RC bugs as FTBFS See /etc/apt/apt.conf.d/10apt-listbugs. Bugs which have FTBFS in the subject are already ignored. Similar filtering should be possible for other categories of bugs as long as there's a standard way to recognize them. James
Re: Custom Reload command/signal in upstart
On Fri, Aug 23, 2013 at 04:42:15PM -0400, John Paul Adrian Glaubitz wrote: > Imagine there is a vulnerability in SSH which has not been fixed > yet for whatever reason. Having SSH run in this situation all the > time would make the machine a target for possible attacks. If all I have to do is make a connection to port 22 to start the service, which would happen as part of an attack anyway, then there's no added security provided by socket activation. -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Less dinstall FTW?
On Aug 29, 2013 10:30 AM, "Ondřej Surý" wrote: > > On Thu, Aug 29, 2013 at 2:39 PM, Ansgar Burchardt wrote: >> >> The open question is if having earlier (easy) access to uploads is >> worthwhile or > > > That would only make sense if buildds would be given access to i.d.o, and I consider this to be very dangerous (so I am not proposing this, juste mentioning it). As Ansgar described in another part of his email, the buildds already have access to incoming.
Re: Proposal: switch default desktop to xfce
On Thu, Oct 24, 2013 at 11:40 AM, Steve McIntyre wrote: > Let's change the default desktop for installation to xfce. > ... > Pros: > > * CD#1 will work again without size worries > > * Smaller, simpler desktop > > * Works well/better on all supported kernels (?) > > * Does not depend on replacing init This falsely implies that sticking with Gnome requires replacing the init system. The only requirement is that systemd is installed, not that it is used as the init system. I'm not objecting to the proposal, but the pros/cons should be accurate. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAFeRdpdk0mzeTNFkzCBMhFJ5qF_RuMeWE-6LS120W5mK=px...@mail.gmail.com
Re: Proposal: switch default desktop to xfce
On Fri, Oct 25, 2013 at 12:57:37AM +0100, Steve McIntyre wrote: > James wrote: > >On Thu, Oct 24, 2013 at 11:40 AM, Steve McIntyre wrote: > >> Let's change the default desktop for installation to xfce. > >> ... > >> Pros: > >> > >> * CD#1 will work again without size worries > >> > >> * Smaller, simpler desktop > >> > >> * Works well/better on all supported kernels (?) > >> > >> * Does not depend on replacing init > > > >This falsely implies that sticking with Gnome requires replacing the > >init system. The only requirement is that systemd is installed, not > >that it is used as the init system. > > That may be the case today, but I personally think it's abundantly > clear from the current path of Gnome development that sooner or later > it's going to have a hard dependency on using systemd. That doesn't contradict what I stated. One can use systemd (the package) without using systemd (the binary) as PID 1. I don't see any reason why Gnome would care what init system is used, while I do see reasons why they want to use the various other tools that come along with systemd (the package). Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Bug#652891: ITP: nerdtree -- Nerdtree is a vim plugin which gives a tree view of all the directories
On Wed, Dec 21, 2011 at 07:24:58PM +0530, medhamsh wrote: > * Package name: nerdtree The binary package should be vim-nerdtree. > Version : 4.1.0 > Upstream Author : Marty Grenfell > * URL : http://www.vim.org/scripts/script.php?script_id=1658 > * License : (Public Domain) It's WTFPL, not Public Domain. > Programming Lang: (Ruby) It's vimscript, not Ruby. > Description : Nerdtree is a vim plugin which gives a tree view of all > the directories The short description should be everything after "Nerdtree is a". See §6.2.2 of the developer's reference. I'd been delaying adding this, or any new script, to vim-scripts (as requested in #624661) since vim-addon-manager needs to be fixed to better handle new/removed/renamed files. Currently, if any of that happens, the user has to notice it and remove/re-add the plugin. Seeing how NERD tree now has plugins, this may be something you run into in later versions. -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Bug#652891: ITP: nerdtree -- Nerdtree is a vim plugin which gives a tree view of all the directories
On Wed, Dec 21, 2011 at 11:42:02PM +0530, Medhamsh wrote: > Should I close this bug and resubmit with > proper information? No, you don't need to. The intent of the bug (declaring your intent to package NERD tree) is still valid. These are just comments to keep in mind as you prepare the packaging. -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: new on list
On Jan 5, 2012 3:02 PM, "Patrick Ouellette" wrote: > > On Thu, Jan 05, 2012 at 08:15:47PM +0200, vangelis wrote: > > Thank you Osamu, i ' ll read all about but please if any group needs > > help i'm offering. > > Check http://www.debian.org/devel/wnpp/ > > find some package(s) that you are interested in and use. Or, slightly easier, install devscripts and run wnpp-alert.
Re: Bug#655232: ITP: pushkey -- ITP: pushkey - Pushes your ssh key to a remote location. It tries to create a .ssh folder remotley then it adds your ssh key to authorized_keys.
On Jan 9, 2012 10:03 AM, "Al Biheiri" wrote: > * Package name: pushkey > Version : 1.0 > Upstream Author : Al Biheiri > * URL : http://dl.dropbox.com/u/77428/website-dev/index.htm > * License : (GPL v3) > Programming Lang: (bash) > Description : Pushes your ssh key to a remote location. It tries to > create a .ssh folder remotely then it adds your ssh key to authorized_keys. Why not use the ssh-copy-id command that comes in the openssh-client package?
Re: test "/etc/init.d/MyPackage start" before shipping, please
On Sat, Mar 24, 2012 at 09:45:03AM +0800, jida...@jidanni.org wrote: > I have an idea, > all /etc/init.d/ script packages should test to see they actually can be > started and stopped before their debs get shipped. As Arno already stated[0], this isn't a problem with Apache. One of the libraries it depends on was incorrectly uploaded with a changed ABI. When Apache then tried to use the library, it obviously failed. No amount of testing Apache would have caught that a library upload 10 days later would be broken. [0]: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;bug=665330 -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: dpkg-buildpackage now sets DEB_BUILD_HOST etc for you?
On Mar 30, 2012 8:40 AM, "Goswin von Brederlow" wrote: > > Hopefully dpkg-buildpackage will stop setting those varibales at some > point so sources that wrongfully depend on the variables being set > actualy break. Already happened in version 1.16.1 (#560070).
Re: thoughts on using multi-arch based cross-building
On Sun, Sep 30, 2012 at 03:34:18PM +0100, peter green wrote: > Build-depends installation: > apt-get build-dep is fine if you are building an unmodified package > from a repo but it's of no use if you have modified the > build-dependencies to make them satisfiable. > > dpkg-checkbuilddeps doesn't tell me what architecture the packages > need to be for and i'm not sure it can (since to do so it would need > to know whether packages that are not installed are multi-arch > foreign or not). > > Does a tool exist that can be told "install the build-depends needed > to build the debianised source tree in directory x for architecture > y"? if not IMO such a tool (or a new option in an existing tool) > needs to be created. See mk-build-deps(1) from devscripts. For example: mk-build-deps -a y -i -s sudo -r x/debian/control Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: multiarch and interpreters/runtimes
On Thu, Apr 18, 2013 at 04:18:20PM +0100, Neil Williams wrote: > On Thu, 18 Apr 2013 16:41:35 +0200 > Matthias Klose wrote: > > > - running a gdb:amd64 on i386 to debug 64bit binaries. This is the > >reason for our current gdb64 package on i386, but it is missing the > >support for the python based pretty printer. > >Installing gdb:amd64 on i386 in wheezy will remove the whole i386 > >python stack and then install the amd64 python stack. For this use > >case the needed amd64 python stuff should just be installed without > >removing the i386 packages. > > > > - install vim for a foreign architecture. Ok, not really a good use case, > >but it comes with an insane amount of embedded interpreters. It > >should be installable without removing the "native" interpreter > >packages, and the embedded interpreters should still be usable. > > Hmm, is this really a strong use case? vim-tiny can be a pain > sometimes, I know, but are those embedded interpreters in vim-full all > that useful? (Or am I missing something?) They're useful if you want to use or develop plugins for Vim that use those language bindings instead of basic vim script. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Dead-lock in replaced package scripts
On Tue, Nov 12, 2013 at 05:32:28PM +0100, Ondřej Surý wrote: > On Tue, Nov 12, 2013, at 14:37, Tollef Fog Heen wrote: > > ]] Ondřej Surý > > > > > Now the "nsd" user has been removed in nsd3.postinst, but it is still > > > needed by nsd (>= 4.0.0) package. Any ideas how to fix that? Or should I > > > just cross the fingers and hope nobody would do such thing? > > > > As others have said: stop removing the user > > I will, but the harm has been already done at the time I become the nsd* > maintainer. > > > but also, rm the old postrm script (with suitable checks). > > I'll use: > > sed -i -e '/deluser --quiet nsd/ d' /var/lib/dpkg/info/nsd3.postrm > > instead, but thanks for the hint. That helped me to break from > '/var/lib/dpkg/info is sacred' mindset. It's the hard-coding of the path that should be avoided. Instead, use “dpkg-query --control-path nsd3 postrm” to get the path. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Subversion 1.8.4
On Fri, Nov 15, 2013 at 01:39:07PM +0400, Виталий Филиппов wrote: > Hello everyone! > > As the latest packaged Subversion in Debian is now 1.8.4 and it seems > that the maintainer doesn't care updating it by now (see > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725787), I've recently > packaged svn 1.8.4 and serf 1.3.2 (which is needed by svn) by myself. As you stated, there's a dependency on a new serf before subversion can be updated. That is the reason subversion has not yet been updated. I hadn't updated the bug until recently because a) it's not an urgent problem that 1.8.x isn't in the archive yet and b) I've been rather busy with non-Debian events lately and have been focusing my time on more important issues. I talked to Peter about an updated serf package and he's looking into it. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Registering a media type for Debian binary packages ?
On Feb 2, 2014 8:23 AM, "Charles Plessy" wrote: > > -Since the Debian packages vehiculate programs to be installed on a computer, > +Since the Debian packages conveys programs to be installed on a computer, Small nit -- s/conveys/convey/. Cheers, James
Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)
Hi all,
In devscripts 2.13.3, uscan gained the ability to verify signature of
the upstream tarball using a file debian/upstream-signing-key.pgp. In
2.14.0, I added the ability to use armored keys and decided to move the
files under debian/upstream/, an idea which had been suggested by a few
people.
This introduced a conflict with DEP-12 (c.f., #736760), which uses
debian/upstream to track metadata about the upstream project. Tools
like umegaya[0] and Debian Med's task list[1] use the information
provided in this file.
[0]: http://upstream-metadata.debian.net/
[1]: http://blends.debian.org/med/tasks/
Part of the reason I chose to use debian/upstream/ is that an extensible
location for upstream related information (similar in spirit to
debian/source/) could be useful. I also was unaware of (or had
forgotten about) DEP-12's existing use of debian/upstream, which was
appropriated around 01/2012 as the new name for
debian/upstream-metadata.yaml.
This leads to the question of how to move forward from here?
Transitioning to debian/upstream/ would require:
- Choosing a new name for DEP-12's file and updating the wording in
DEP-12. My suggestion would be debian/upstream/metadata.
- Updating the data collection code for umegaya and Debian Blends, the
latter of which has an initial patch[2] based on my suggestion in 1).
- Renaming the file in the VCS repositories for all packages providing
this information. This is ~350 packages according to
ullman:/srv/udd.debian.org/mirrors/machine-readable, which doesn't
include packages that still haven't transitioned from
upstream-metadata.yaml. Note, that this only needs to happen in the
VCS and not a source upload.
[2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736760#35
Sticking with the status quo would require:
- Changing uscan to look for debian/upstream-signing-keys.{pgp,asc}
- Updating the ~17 packages that have started using debian/upstream/
While the latter is less work, my preference would be for the former
since it provides a consistent place to look for upstream information
in the context of a Debian source package. It seems unlikely to me both
that uscan/DEP-12 will be the only projects that will want access to
upstream-related information and that any other information would
necessarily fit into one of those two buckets that they understand.
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
signature.asc
Description: Digital signature
Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)
On Fri, Feb 07, 2014 at 01:18:09PM +0800, Paul Wise wrote: > Another project that looks at DEP-12 metadata is DUCK, the Debian URL > checker. I think it looks at DEP-12 stuff as a source of URLs to > check. From a quick glance, doesn't seem so. > In your patch I think you mean [ ! -d $srcfile ] instead of -e? The > latter will match if debian/upstream is a dir or a file but I think > you want it to only match on files and maybe symlinks? The part I think you're referring to is the handling of svn repositories, in which case the existence check is for an exported file named either upstream (for debian/upstream) or metadata (for debian/upstream/metadata). There's a call to "svn ls" a few lines earlier that determines which actually exists. I did notice something else in looking over the patch and will follow up with that to the bug. > There are other issues with uscan/DEP-12; > > debian/watch is duplicated in the Watch field in DEP-12 debian/upstream. Partially. DEP-12 assumes it to be a version=3 format line and only supports a single line. > umegaya doesn't support packages where there is no VCS. Not sure if > the blends site has the same issue? As far as I know, both are specifically intended to collect data only from a VCS, yes. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)
On Fri, Feb 07, 2014 at 10:32:52AM +0100, Daniel Leidert wrote: > James McCoy wrote: > >Part of the reason I chose to use debian/upstream/ is that an extensible > >location for upstream related information (similar in spirit to > >debian/source/) could be useful. > > I've really wondered, why you didn't use debian/source/ for this purpose > and introduced another directory? Why not put the key used to sign the > upstream source right into debian/source/? debian/source/ is for content related to the source package. debian/upstream/ would be for content related to upstream. There's a distinct separation there and as the signing key is, IMO, obviously upstream metadata it's not appropriate for debian/source/. The only relation it has to the source package is that it's used to verify one component of the source package. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Wanted: perl package home for condorcet computation script
On Fri, Feb 07, 2014 at 05:32:29PM +, Ian Jackson wrote:
> Ian Jackson writes ("Re: Wanted: perl package home for condorcet computation
> script"):
> > Paul Wise writes ("Re: Wanted: perl package home for condorcet computation
> > script"):
> > > On Mon, Feb 3, 2014 at 11:46 PM, Ian Jackson wrote:
> > > > It would like to live in some Debian package.
> > >
> > > devscripts seems like the ideal package. I guess some folks would want
> > > to use it for meeting times and team decisions.
> >
> > CCing the devscripts list. Hi, devscripts maintainers. What do you
> > think ?
>
> Hi, James, I was wondering if you had an opinion about this proposal.
> Would my condorcet vote counter fit into devscripts ?
It didn't seem to fit your criterion about dependencies, but if you're
fine with that, then sure.
> The dependencies have grown a bit: now it depends on
> Graph::Writer::GraphViz too, so, indirectly, on graphviz.
Given the more niche role of the script, the dependencies probably won't
be part of the "default install" set anyway, so that shouldn't be a big
deal.
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
signature.asc
Description: Digital signature
Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)
On Mon, Feb 10, 2014 at 09:21:02AM +0100, Andreas Tille wrote: > I wonder whether you have further files in mind which should end up in > debian/upstream/ dir. Could your please give some reasons why you > dropped the previously used location, debian/upstream-signing-key.pgp, Quoting my initial email in this thread: Part of the reason I chose to use debian/upstream/ is that an extensible location for upstream related information (similar in spirit to debian/source/) could be useful. I received the suggestion from multiple people to use this directory, presumably for the same reason, which reinforced my existing inclination to do so. > in favour of introducing a directory which even conflicts with some > other file name which is discussed in a DEP-12 without minding any > discussion. Quoting my initial email in this thread: I also was unaware of (or had forgotten about) DEP-12's existing use of debian/upstream, which was appropriated around 01/2012 as the new name for debian/upstream-metadata.yaml. > IMHO, it is simply not the right way to to a grab into the > name space without dicussion and creating work for your fellow DDs by > doing so. Please do not ascribe malice to something that happened out of ignorance. Simply because I wasn't aware of DEP-12's usage of debian/upstream, nor had encountered its use anywhere in the past two years, does not mean that I intentionally caused this conflict. If I had known of it, I would have started a discussion. > For instance: Do you plan to move the debian/watch file to > debian/upstream/ dir as well (or not and if not why not?) I think it would be appropriate to move it there, yes. I haven't made any changes in that direction yet because I'd like this discussion to finalize first. On Tue, Feb 11, 2014 at 09:15:33AM +0900, Charles Plessy wrote: > Help is welcome but just helping is not enough. Just helping would be for > instance to migrate 50 packages over 300, and tell us to do the rest. This > would be worse than doing nothing. > … > I personally find peoples attitudes quite brutally top-down confrontational. > Just because you maintain devscripts or dpkg does not mean that you decide how > others spend their time. > … > A: Hey, I sent you a trivial patch to > s|debian/upstream|debian/upstream/metadata|. > B: Thanks, but please do the full migration yourself. I'm not trying to be confrontational. I'm trying to do work towards what I thought you had agreed was an amenable solution as long as someone does the work. Having debian/upstream be a directory is something I think is worthwhile to work toward, which is why I said I would do that. However, I'm ignorant of the existing uses of debian/upstream. Andreas mentioned the udd gatherer as something that would need changes if there were to be a transition. I therefore provided a patch spcifically to honor both the existing path and the proposed path so that the transition doesn't have to be immediate. I've stated from the start that I would work on a transition, but without knowledge of what needs to be transitioned (which I'm assuming you and Andreas have) it's not easy to do that. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)
On Tue, Feb 11, 2014 at 11:08:44AM +0900, Charles Plessy wrote: > Le Mon, Feb 10, 2014 at 08:38:51PM -0500, James McCoy a écrit : > > > > I'm not trying to be confrontational. I'm trying to do work towards > > what I thought you had agreed was an amenable solution as long as > > someone does the work. > … > > I've stated from the start that I would work on a transition, but > > without knowledge of what needs to be transitioned (which I'm assuming > > you and Andreas have) it's not easy to do that. > > Hi James, > > I am upset to have to repeat you again and again that what needs to be > transitionned is to move debian/upstream to debian/upstream/metadata in the > VCS > where we store our source packages. No more, no less. That wasn't clear to me in your previous messages, which is why I presumed you were wanting someone to transition the consumers of the file not the files themselves. That also seems like it's unnecessary to do immediately since the consumers should be able to handle both paths so the files can transition over time (as happened when upstream-metadata.yaml was renamed, which still isn't complete). If all you're concerned about is moving the files in the repositories, I'll gladly do that. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)
On Tue, Feb 11, 2014 at 12:04:29PM +0900, Charles Plessy wrote: > Le Mon, Feb 10, 2014 at 09:39:09PM -0500, James McCoy a écrit : > > > > That wasn't clear to me in your previous messages, which is why I > > presumed you were wanting someone to transition the consumers of the > > file not the files themselves. That also seems like it's unnecessary to > > do immediately since the consumers should be able to handle both paths > > so the files can transition over time (as happened when > > upstream-metadata.yaml was renamed, which still isn't complete). > > At least for the work done on my side, what seems suggested above is not true: > there was not double-support for both debian/upstream-metadata.yaml and > debian/upstream-metadata at the same time. That was poor wording on my part. I meant that not all packages have renamed debian/upstream-metadata.yaml to debian/upstream in their repository, so supporting multiple locations in the consumers is useful. That support would also enable this transition to gradually take place as people have need to deal with their packages. > You are making assumptions that 1) are wrong and 2) support your views. > Please > review them more careully, especially when they look convenient for you. Please be less confrontational. I'm not assuming anything. I'm simply attempting to explain why I think that modifying the consumers is a simpler way to handle this than trying to adapt all of the providers immediately. > > If all you're concerned about is moving the files in the repositories, > > I'll gladly do that. > > When will you start and when do you plan to finish ? Just do it please. I've put together a script to do this, using data from Andreas' gatherer and the packages that apt-file reports as having a debian/upstream file. That being said, I don't have access to most of the packages. Even if I did, it feels "dirty" to go and commit to a couple hundred packages I have no involvement with instead of adapting two pieces of software to deal with both path names. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)
On Sat, Feb 22, 2014 at 10:07:42AM +0900, Charles Plessy wrote: > you are very welcome to migrate the ‘debian/upstream’ files of the Debian Med > packaging team. Please do not worry about the ‘debian/upstream-metadata.yaml’ > files. > > Since a large share of the ‘debian/upstream’ files are in Debian Med packages, > this will give the momentum for the whole migration. Ok. I'll update my repository list this weekend and run through the changes then. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Multirelease, something like Multiarch.
On Fri, Feb 21, 2014 at 09:31:56AM -0600, Mike Mestnik wrote: > Now we've a similar situation for releases and even distributions. We can > run multiple releases using a chroot for each, but perhaps this system can > be improved on. This doesn't seem particularly Debian-specific, so I'm not sure this list is the right place to hold such a discussion. You may be interested in Bedrock Linux[0] which seems to be doing pretty much what you describe. 0: http://www.bedrocklinux.org/ Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Backports, Stable releases, Testing, Oh my!
On Feb 26, 2014 10:49 AM, "micah" wrote: > For example, say package X has been backported at version 1.0, version > 2.0 is uploaded to sid, transitions to jessie and then has an RC bug > that threatens removal. If the RC bug is properly versioned, then the 1.0 upload, which isn't affected, shouldn't be removed from testing. Cheers, James
Re: building arch:all packages on the buildd network (was: Re: when will we finally throw away binary uploads)
On Wed, Feb 26, 2014 at 09:51:41PM -0500, Paul Tagliamonte wrote: > So, building off this mail (and ideas I had kicking around): > > > | Build-Depends-Indep field is defined as a list of architectures that the ^-- Build-Architecture-Indep, right? Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#740398: ITP: pangoterm -- GTK/Pango-based terminal emulator
Package: wnpp Severity: wishlist Owner: James McCoy * Package name: pangoterm Version : 0~20140228 Upstream Author : Paul Evans * URL : http://www.leonerd.org.uk/code/pangoterm/ * License : MIT Programming Lang: C Description : GTK/Pango-based terminal emulator A minimal GTK/Pango-based terminal that uses libvterm to provide terminal emulation. -- 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/20140301022311.21426.48429.report...@cerberus.jamessan.com
Bug#740400: ITP: libvterm -- abstract library implementation of a VT220/xterm/ECMA-48 terminal emulator
Package: wnpp Severity: wishlist Owner: James McCoy * Package name: libvterm Version : 0~20140228 Upstream Author : Paul Evans * URL : http://www.leonerd.org.uk/code/libvterm/ * License : MIT Programming Lang: C Description : abstract library implementation of a VT220/xterm/ECMA-48 terminal emulator An abstract C99 library which implements a VT220 or xterm-like terminal emulator. It doesn't use any particular graphics toolkit or output system, instead it invokes callback function pointers that its embedding program should provide it to draw on its behalf. It avoids calling malloc() during normal running state, allowing it to be used in embedded kernel situations. -- 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/20140301022604.1139.73303.report...@cerberus.jamessan.com
Re: Bug#743282: ITP: apt-get-snapshot -- Download a specific package version from snapshot.debian.org
On Apr 1, 2014 6:39 AM, "Mike Gabriel" wrote: > * Package name: apt-get-snapshot > Version : 1.1 > Upstream Author : Leandro Lisboa Penz > * URL : https://github.com/lpenz/apt-get-snapshot > * License : BSD > Programming Lang: Python > Description : Download a specific package version from snapshot.debian.org > > apt-get-snapshot is a command-line tool that downloads a specific version of > a debian package from snapshot.debian.org. This sounds a lot like the debsnap tool in the devscripts package. Cheers, James
Re: Does partial upgrade between stable and testing must be supported ?
On Sat, Apr 05, 2014 at 07:40:49PM +, Sune Vuorela wrote:
> On 2014-04-05, Vincent Danjean wrote:
> > The maintainer think that he does not need to do anything about
> > that. People should just upgrade all their packages from stable to
> > testing when r-base-core is upgraded.
> > Other people (and me) disagree and think that other broken r-related
> > packages must be either removed or upgraded automatically by apt
> > when r-base-core is upgraded (due to additional conflicts/breaks/...
> > declarations)
>
> I agree with you and other people. partial upgrade should work.
> Requiring packages to be uninstalled is a great way of ensuring that
> partial upgrades works.
There was a similar discussion a year ago[0] where it was suggested that
a core r package should provide a virtual package, similar to
perlapi-5.18.1. Then some build helper should ensure that gets added to
the Depends of relevant packages through some substvar (likely
${R:Depends}).
[0]: http://lists.debian.org/87bo9ztrww@deep-thought.43-1.org
Apparently, there hasn't been any action in that direction.
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
--
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/20140405233748.gg2...@jamessan.com
Re: Proposed mass bug filing: /usr/lib/perl5 is changing with Perl 5.20
On Sat, May 31, 2014 at 11:13:43PM +0300, Niko Tyni wrote: > "Normal" build systems based on ExtUtils::MakeMaker or Module::Build do > this automatically, but 62 packages either failed to build or lost their > libperl linkage because of this in my test rebuilds of affected packages > (reverse dependencies of perlapi-5.18.* or libperl5.18, with a total of 540). Do you have these build logs available for people to review? That would help in diagnosing the problems before we're able to easily test build against 5.20. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]
On Mon, Jan 19, 2015 at 11:31:20AM +, Wookey wrote: > Am I right that the > only way to expliticly mail the submitter and the maintainer is to > look the submitter's mail up in the initial bugrep and just CC it, > whilst replying to bugnum@b.d.o, which will automatically include the > maintainer? (which feels like work the BTS could do for me, maybe even > by default). Or should I mail both nnn@b.d.o _and_ nnn-submitter@b.d.o > to get the desired effect? The latter. The forward to debian-bugs-dist is handled by the BTS so it will deduplicate the message. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy -- 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/20150120005418.gi22...@freya.jamessan.com
Bug#776033: ITP: dex -- generate and execute Application type .desktop files
Package: wnpp Severity: wishlist Owner: James McCoy * Package name: dex Version : 0.7 Upstream Author : Jan Christoph Edersbach * URL : http://github.com/jceb/dex * License : GPL 3+ Programming Lang: Python Description : generate and execute Application type .desktop files DesktopEntry eXecution implements the Freedesktop.org autostart specification, independent of any desktop or window manager environment. Applications may be filtered based on the Desktop Environment advertised in the .desktop file. . dex can also create a minimal .desktop file for a specified program. - why is this package useful/relevant? It enables users of tiling/minimal WMs to easily autostart applications and applets in their X session. - is it a dependency for another package? No. - do you use it? Yes. - if there are other packages providing similar functionality, how does it compare? Other than manually editing .xsession, I don't know of any in the archive. - how do you plan to maintain it? In collab-maint. -- 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/20150123033939.29753.54945.report...@freya.jamessan.com
Re: How to type ellipsis on Linux keyboard
On Feb 12, 2015 10:18 AM, "Joachim Breitner" wrote: > > Hi, > > Am Donnerstag, den 12.02.2015, 15:22 +0100 schrieb Jakub Wilk: > > * Jonas Smedegaard , 2015-02-12, 12:54: > > >I have¹ the following in my ~/.profile: > > > > > > setxkbmap dk -option compose:menu > > > > You might want to enable it globally in /etc/default/keyboard instead. > > Documentation: https://pkg-xorg.alioth.debian.org/howto/configure-input.html#_basic_keyboard_configuration > > btw, do you know what’s the modern equivalent to having lines like > keycode 53 = x X leftdoublequotemark leftsinglequotemark leftdoublequotemark leftsinglequotemark > in my ~/.Xmodmap, and loading that using xmodmap? I think you're referring to xkb. madduck thoroughly documented[0] how he converted his xmodmap setup to xkb. [0]: http://madduck.net/docs/extending-xkb/ Cheers, James
Re: mass mailing usertagged bug reports
On Thu, Mar 05, 2015 at 06:52:22PM +0100, Michael Biebl wrote: > I filed a bunch of bug reports using mass-bug, properly usertagging > those bug reports. > > Now I'd like to follow up on those bug reports, and I'd like to do that > in one go instead of mailing each bug report individually. > > Does anyone know a tool, which I can point at a template, user and tag, > which will then pull all (open) bug reports from the bts and send an > email based on the template? Hmm, looks like such a tool was proposed to devscripts some time back[0]. It could use some cleanup, but a mass-reply script could be a good counterpart to mass-bug. [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=205416 Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: GitHub “pull request” is useful and can be easily integrated'’
On Sun, Apr 19, 2015 at 10:27:01AM -0700, Russ Allbery wrote: > The repositories and Git management are the very nice features of GitHub, > and there's nothing there data-wise you can't pretty trivially extract. > It's just a very nice UI. In fact, joeyh wrote a nice tool[0] that will extract all the data that can be extracted and put it into your git repository. [0]: https://joeyh.name/code/github-backup/ Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Bug #778876: linux-kbuild-3.19 missing from experimental
On Tue, Apr 21, 2015 at 12:47:11AM +0200, Adam Borowski wrote: > On Mon, Apr 20, 2015 at 07:15:53PM +0100, Nick Morrott wrote: > > Obviously no DKMS support is available "out of the box as a result of > > this. The linux-image-3.19* and linux-headers-3.19* packages are all > > available. > > If you need a newer kernel, you'd be better off using kernel-package > instead. Or just the deb-pkg target in the upstream Makefile. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#783043: ITP: unibilium -- Simple, self-contained terminfo library
Package: wnpp Severity: wishlist Owner: James McCoy * Package name: unibilium Version : 1.1.2 Upstream Author : Lukas Mai * URL : https://github.com/mauke/unibilium * License : LGPL-3+ Programming Lang: C Description : Simple, self-contained terminfo parsing library Unibilium is a very basic terminfo library. It doesn't depend on curses or any other library. It also doesn't use global variables, so it should be thread-safe. why is this package useful/relevant? is it a dependency for another package? - Dependency of Neovim (#752264) how do you plan to maintain it? - In collab-maint git -- 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/20150421025140.13901.69101.report...@freya.jamessan.com
Bug#783044: ITP: busted -- Lua unit testing framework focused on ease of use
Package: wnpp Severity: wishlist Owner: James McCoy * Package name: busted Version : 2.0.rc8 Upstream Author : Olivine Labs, LLC. * URL : http://olivinelabs.com/busted/ * License : MIT Programming Lang: Lua Description : Lua unit testing framework focused on ease of use busted test specs read naturally without being too verbose. You can even chain asserts and negations, such as assert.not.equals. Nest blocks of tests with contextual descriptions using describe, and add tags to blocks so you can run arbitrary groups of tests. . An extensible assert library allows you to extend and craft your own assert functions specific to your case with method chaining. A modular output library lets you add on your own output format, along with the default pretty and plain terminal output, JSON with and without streaming, and TAP-compatible output that allows you to run busted specs within most CI servers. You can even register phrases for internationaliation with custom or built-in language packs. why is this package useful/relevant? is it a dependency for another package? - Dependency for testing Neovim how do you plan to maintain it? - collab-maint git -- 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/20150421040757.15344.63464.report...@freya.jamessan.com
Linking Python extensions with libpython (was: linking perl statically against libperl)
On Wed, Apr 22, 2015 at 12:58:38AM +0200, Matthias Klose wrote: > - note that in Debian python extensions aren't usually linked with >-lpythonX.Y. This is done to not depend on multiple python versions >when building an extension for multiple python versions in a single >binary package, but also to not load the shared library. I don't see >a memory waste here. Of course, the shared library is loaded when >an application is started using an embedded python interpreter (vim). Note that this decision prevents a single Vim instance from being able to run both Python2 and Python3 code. For that reason alone, I'd rather have extensions linked with -lpythonX.Y. That would be one step toward me being able to enable dynamic loading of language bindings in Vim. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Linking Python extensions with libpython
On Wed, Apr 22, 2015 at 12:58:54PM +0200, Matthias Klose wrote: > On 04/22/2015 02:30 AM, James McCoy wrote: > > On Wed, Apr 22, 2015 at 12:58:38AM +0200, Matthias Klose wrote: > >> - note that in Debian python extensions aren't usually linked with > >>-lpythonX.Y. This is done to not depend on multiple python versions > >>when building an extension for multiple python versions in a single > >>binary package, but also to not load the shared library. I don't see > >>a memory waste here. Of course, the shared library is loaded when > >>an application is started using an embedded python interpreter (vim). > > > > Note that this decision prevents a single Vim instance from being able > > to run both Python2 and Python3 code. For that reason alone, I'd rather > > have extensions linked with -lpythonX.Y. That would be one step toward > > me being able to enable dynamic loading of language bindings in Vim. > > sure, but can't you just have one vim extension linked with the interpreter > which is loaded by default? In general, applications embedding the python > interpreter should just support one language version, and that should be > Python3 > at this time. Not sure I like the gdb way to build two versions of the > debugger > for different python versions. Currently I don't dynamically load any of the language bindings because I don't think we (Debian) have good support for automatically managing application upgrades when a dynamically loaded library has a transition. Since the express purpose of dynamically loading is to avoid a hard dependency, simple binNMUs aren't sufficient. One would have to manually add relevant Breaks to any libraries that are being dynamically loaded so the libraries don't get upgraded without the application. If I'm wrong and someone can educate me otherwise, I'd be happy. However, with the current state of affairs, I've stuck with dynamic linking so binNMUs handle any transitions Vim is apart of instead of risking Vim crashing because it wasn't upgraded along with a supporting, dynamically loaded library. If I were dynamically loading the language bindings then, due to the way Python extensions are built in Debian, Vim will load whichever Python version a script uses first and block the other version from loading in that Vim session. This isn't very friendly to people that shouldn't have to care about what language some plugin author chose to use. Pulling the language binding out into its own module which is linked against libpython isn't currently supported in Vim. Also, due to the functionality exposed to the language bindings, I would have to build multiple versions of this hypothetical module to support both vim and gvim. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#783156: ITP: libtermkey -- library for processing keyboard input from terminal-based programs
Package: wnpp Severity: wishlist Owner: James McCoy * Package name: libtermkey Version : 0.17 Upstream Author : Paul Evans * URL : http://www.leonerd.org.uk/code/libtermkey/ * License : MIT Programming Lang: C Description : library for processing keyboard input from terminal-based programs This library allows easy processing of keyboard entry from terminal-based programs. It handles all the necessary logic to recognise special keys, UTF-8 combining, and so on, with a simple interface. why is this package useful/relevant? is it a dependency for another package? - Dependency for Neovim if there are other packages providing similar functionality, how does it compare? - Quoting from upstream in regard to a comparison with terminfo This library uses the terminfo database for the terminal type given by $TERM as a first attempt to convert raw incoming bytes into symbolic keypress events. If this translation fails, and the terminal type is known to be one that uses xterm's generic CSI scheme for representing modified keypresses (e.g. xterm), then the sequence is interpreted according to xterm's rules. Finally, if all of these fail, the raw bytes will be presented as they are. how do you plan to maintain it? - collab-maint git, co-maintainers welcome -- 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/20150423011910.31604.5639.report...@freya.jamessan.com
Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)
On Sat, May 02, 2015 at 01:46:25PM +0200, David Kalnischkies wrote:
> (aka: I don't see why a debug
> package has to depend on the package it provides symbols for at all. If
> any the relation should be 'Enhances'…).
The intention is to ensure the debug symbols came from the same build as
the binary packages which are being enhanced. Enhances doesn't provide
that guarantee since it's a purely aesthetic relationship. The
alternative is to have all the packages which are enhanced by the debug
symbols declare “Breaks: foo-dbg (<< ${binary:Version}), foo-dbg (>>
${binary:Version})”
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
signature.asc
Description: Digital signature
Re: Modern Debian packaging system for DevOps: does it exist?
On Fri, May 15, 2015 at 10:04:35AM +0200, Vincent Bernat wrote: > A good timesaver is to have libeatmydata or similar. But this is still > slow. For example, the manual page step. Why is man-db even installed in a build chroot? Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: scripts for merging local changes
On Mon, May 25, 2015 at 03:45:38AM +0100, peter green wrote: > I just hacked together some scripts (the code is in two parts, the overall > control code is in bash script while the changelog processing is in python) > to deal with merging local changes (provided in the form of a debdiff) with > a new version from Debian (provided in the form of a dsc) Have you seen dpkg-mergechangelogs(1) in dpkg-dev? Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: ppp plugins and dependencies
On Sun, Jun 07, 2015 at 11:26:12AM +0100, Chris Boot wrote:
> One of the first tasks on my list is to resolve the issue with
> dependencies and ABI compatibility surrounding the building of ppp
> plugins. Several packages in the archive use the ppp-dev package to help
> them build ppp plugins that are loaded into pppd at run-time using
> dlopen(). The plugins are generally installed into a particular
> versioned directory on the filesystem (currently
> /usr/lib/pppd/${abi_version}/) where pppd looks for them by default.
>
> There is currently no mechanism for binary packages to depend on a
> particular ppp plugin ABI version being available, other than manually
> creating (and maintaining) dependencies such as:
>
> Depends: [...] ppp (>= 2.4.6~), ppp (<< 2.4.7~) [...]
This sounds like the same issue I brought up in
<20150422234712.gc19...@freya.jamessan.com>. We, as a distribution,
haven't solved the problem of ensuring
a) Packages which dynamically load a shared library are rebuilt when
appropriate
b) After such a rebuild, the package loading the shared library and the
shared library are upgraded together
while still avoiding the use of hard Depends (since they defeat the
purpose of dynamically loading a library).
This has been solved for programs which just dynamically link libraries
through binNMUs and symbols/shlibs files, but we really need a similar
mechanism for dynamically loaded libraries.
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
signature.asc
Description: Digital signature
Re: Re: GitHub “pull request” is proprietary, incomp atible with Git ‘request-pull ’
On Jul 10, 2015 12:11 PM, "Ian Jackson"
wrote:
>
> Dimitri John Ledkov writes ("Re: GitHub “pull request” is proprietary,
incomp atible with Git ‘request-pull ’"):
> > What you have described here is github pull requests =) they use
> > refs/pull/# namespace though, so one needs to tweak fetch config to
> > get them all.
>
> Except that (a) we don't have an implementation of the server side
> (b) a person who wants to submit a github pull request needs to push
> buttons on the web UI too.
Creating a pull request can be done purely by using their API[0], which is
exactly how the CLI tools git-hub works.
[0]: https://developer.github.com/v3/pulls/#create-a-pull-request
Cheers,
James
Re: salsa.debian.org: merge requests and such
On Sun, Nov 11, 2018 at 01:51:56PM +, Jonathan Dowland wrote: > On Fri, Nov 09, 2018 at 04:57:51PM +, Matthew Vernon wrote: > > That's what Vcs-Git et al are for, isn't it? > > I'm sorry I don't understand what you're saying. That was in response to the visibility aspect of your email. In terms of visibility, it doesn't matter where the repo is hosted or whether it's in Salsa's debian org or one's own namespace -- Vcs-Git clearly tells people where to find it. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: Git Packaging: Native source formats
On Fri, Aug 30, 2019 at 09:05:45AM -0700, Russ Allbery wrote: > Ian Jackson writes: > > This is also not that hard, in simple cases. There is a tool > > git-debcherry which can do it automatically. I haven't used it but AIUI > > if your Debian delta queue has few commits, and doesn't have commits > > which involve merge conflicts with upstream merges (basically, if each > > change is carried Debian only for a short time), it will always produce > > the nice output you would hope for. > > This lets you generate the patches for people on demand, but they aren't > just sitting out there for anyone to look at whenever they want. > > I suppose it could be provided as an automated service that publishes the > results, but that would be a piece of infrastructure someone has to run. Since git-debcherry is used to export the patches when creating the source package, such a service already exists -- https://sources.debian.org/ Now, git-debcherry doesn't always make the most human consumable patch series. For example, the neovim 0.3.4-3[0] upload in which I cherry-picked a large number of patches for a security fix. Rather than having distinct patches for most of those commits, they were mostly munged into a single "debcherry fixup" patch. [0]: https://sources.debian.org/src/neovim/0.3.4-3/debian/patches/ Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1034075: ITP: tree-sitter-lua -- Lua grammar for tree-sitter
Package: wnpp Severity: wishlist Owner: James McCoy X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: tree-sitter-lua Version : 0.0.14 Upstream Contact: Munif Tanjim * URL : https://github.com/MunifTanjim/tree-sitter-lua * License : MIT Programming Lang: JavaScript, C, Rust Description : Lua grammar for tree-sitter This package provides a tree-sitter parser for Lua. This is needed for Neovim's tests and is one of the tree-sitter parsers expected to be available. It will be maintained in the tree-sitter team.
Bug#1052202: ITP: tree-sitter-vimdoc -- Vim help file parser for tree-sitter
Package: wnpp Severity: wishlist Owner: James McCoy X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: tree-sitter-vimdoc Version : 2.0.0 Upstream Contact: Thomas Vigouroux * URL : https://github.com/neovim/tree-sitter-vimdoc/ * License : Apache 2.0 Programming Lang: JavaScript, C, Rust Description : Vim help file parser for tree-sitter This package provides a tree-sitter parser for Vim's help files. This is needed for Neovim's tests and is one of the tree-sitter parsers expected to be available. It will be maintained in the tree-sitter team.
Bug#1052203: ITP: tree-sitter-vim -- Vimscript parser for Tree-sitter
Package: wnpp Severity: wishlist Owner: James McCoy X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: tree-sitter-vim Version : 0.3.0 Upstream Contact: Thomas Vigouroux * URL : https://github.com/neovim/tree-sitter-vim/ * License : MIT Programming Lang: JavaScript, C, Rust Description : Vimscript parser for Tree-sitter This package provides a vimscript parser for tree-sitter. This is needed for Neovim's tests and is one of the tree-sitter parsers expected to be available. It will be maintained in the tree-sitter team.
Bug#1052204: ITP: tree-sitter-query -- Tree-sitter query parser for Tree-sitter
Package: wnpp Severity: wishlist Owner: James McCoy X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: tree-sitter-query Version : 0.1.0 Upstream Contact: Neovim Treesitter Team * URL : https://github.com/nvim-treesitter/tree-sitter-query * License : Apache 2.0 Programming Lang: JavaScript, C, Rust Description : Tree-sitter query parser for Tree-sitter This package provides a tree-sitter queries parser for tree-sitter. This is needed for Neovim's tests and is one of the tree-sitter parsers expected to be available. It will be maintained in the tree-sitter team.
Bug#1054565: RFP: golang-github-zeebo-xxh3 -- XXH3 algorithm in Go
Package: wnpp Severity: wishlist Control: block 1037440 by -1 * Package name: golang-github-zeebo-xxh3 Version : 1.0.2-1 Upstream Author : Jeff Wendling * URL : https://github.com/zeebo/xxh3 * License : BSD-2-clause Programming Lang: Go Description : XXH3 algorithm in Go XXH3 . GoDoc (https://godoc.org/github.com/zeebo/xxh3) Sourcegraph (https://sourcegraph.com/github.com/zeebo/xxh3?badge) Go Report Card (https://goreportcard.com/report/github.com/zeebo/xxh3) . This package is a port of the xxh3 (https://github.com/Cyan4973/xxHash) library to Go. . Upstream has fixed the output as of v0.8.0, and this package matches that. This is needed to package a new upstream version of kitty. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1055347: RFA: kitty -- fast, featureful, GPU based terminal emulator
Package: wnpp Severity: normal X-Debbugs-Cc: ki...@packages.debian.org, debian-devel@lists.debian.org Control: affects -1 + src:kitty I request an adopter for the kitty package. I no longer use the package and don't have time to figure out how to deal with the new golang parts of the package. The package description is: Kitty supports modern terminal features like: graphics, unicode, true-color, OpenType ligatures, mouse protocol, focus tracking, and bracketed paste. . Kitty has a framework for "kittens", small terminal programs that can be used to extend its functionality.
Bug#1059470: ITP: rust-rustix-openpty -- safe rust bindings to "openpty" and related functions
Package: wnpp Severity: wishlist Owner: James McCoy X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rust-rustix-openpty Version : 0.1.1 Upstream Contact: Dan Gohman * URL : https://github.com/sunfishcode/rustix-openpty * License : Apache-2.0 with LLVM exception or Apache-2.0 or MIT Programming Lang: Rust Description : safe rust bindings to "openpty" and related functions This is a new dependency for the next alacritty release.
Bug#1059681: ITP: rust-calloop-wayland-source -- wayland-rs client event source for callloop
Package: wnpp Severity: wishlist Owner: James McCoy X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rust-calloop-wayland-source Version : 0.2.0 Upstream Contact: Kirill Chibisov * URL : https://github.com/smithay/calloop-wayland-source * License : MIT Programming Lang: Rust Description : wayland-rs client event source for callloop This is needed for the new rust-smithay-client-toolkit release and will be maintained in the pkg-rust team.
Bug#1059774: ITP: rust-as-raw-xcb-connection -- rust trait to interop with libxcb C API
Package: wnpp Severity: wishlist Owner: James McCoy X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rust-as-raw-xcb-connection Version : 1.0.1 Upstream Contact: Uli Schlachter * URL : https://github.com/psychon/as-raw-xcb-connection * License : MIT or Apache-2.0 Programming Lang: Rust Description : rust trait to interop with libxcb C API This is needed for the new upstream release of x11rb and will be maintained in the pkg-rust team.
Bug#1059798: ITP: rust-wayland-csd-frame -- rust interface for wayland client side decorations (CSD)
Package: wnpp Severity: wishlist Owner: James McCoy X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rust-wayland-csd-frame Version : 0.3.0 Upstream Contact: Kirill Chibisov * URL : https://github.com/rust-windowing/wayland-csd-frame * License : MIT Programming Lang: Rust Description : rust interface for wayland client side decorations (CSD) This package is a dependency of the new smithay-client-toolkit release and will be maintained in the pkg-rust repo.
Bug#1059800: ITP: rust-wayland-protocols-wlr -- Generated API for the WLR wayland protocol extensions
Package: wnpp Severity: wishlist Owner: James McCoy X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rust-wayland-protocols-wlr Version : 0.2.0 Upstream Contact: Elinor Berger * URL : https://github.com/smithay/wayland-rs * License : MIT Programming Lang: Rust Description : Generated API for the WLR wayland protocol extensions This a new dependency for the next version of smithay-client-toolkit and will be maintained in the pkg-rust repo.
Bug#1059803: ITP: rust-xkeysym -- X11 keyboard symbol utilities for Rust
Package: wnpp Severity: wishlist Owner: James McCoy X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rust-xkeysym Version : 0.2.0 Upstream Contact: John Nunley * URL : https://github.com/notgull/xkeysym * License : MIT or Apache-2.0 or Zlib Programming Lang: Rust Description : X11 keyboard symbol utilities for Rust This package is a dependency of the new smithay-client-toolkit release and will be maintained in the pkg-rust repo.
Bug#1060382: ITP: rust-xkbcommon-dl -- Dynamically loaded xkbcommon and xkbcommon-x11 Rust bindings
Package: wnpp Severity: wishlist Owner: James McCoy X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rust-xkbcommon-dl Version : 0.4.1 Upstream Contact: Kirill Chibisov * URL : https://github.com/rust-windowing/xkbcommon-dl * License : MIT Programming Lang: Rust Description : Dynamically loaded xkbcommon and xkbcommon-x11 Rust bindings This is a dependency for the new version of rust-winit and will be maintained in the pkg-rust repo.
Bug#1060697: ITP: rust-wayland-protocols-plasma -- Generated API for the Plasma wayland protocol extensions
Package: wnpp Severity: wishlist Owner: James McCoy X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rust-wayland-protocols-plasma Version : 0.2.0 Upstream Contact: Elinor Berger * URL : https://github.com/smithay/wayland-rs * License : MIT Programming Lang: Rust Description : Generated API for the Plasma wayland protocol extensions This is a dependency of the new version of winit and will be maintained in the pkg-rust repo.
Re: Limited security support for Go/Rust? Re ssh3
On Tue, Jan 16, 2024 at 04:44:14PM +0100, IOhannes m zmölnig (Debian GNU|Linux) wrote: > On 1/16/24 13:56, Jérémy Lal wrote: > > > > > > As Built-Using is for license compliance only, no? > > > > > > See > > > > > > https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using > > > > Indeed, thanks for the link. > > > > it seems that many people think that "Built-Using" can be used to express > static linking (including yours truly, even though i *know* that it is meant > for license compliance only). > > which makes me wonder: probably we should have an additional field that > expresses such static linking (and therefore would trigger a rebuild when > the dependency changes). There's been some effort to move to a Static-Built-Using field to express that semantic, and leave Built-Using as its intended purpose related to licensing. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: How to ask efficiently for removal of 32 bit architectures of about 40 packages (Was: reverse dependenc)
On Mon, Mar 11, 2024 at 09:12:30PM +0100, Andreas Tille wrote: > Hi, > > Am Mon, Mar 04, 2024 at 06:25:50PM + schrieb Thorsten Alteholz: > > Control: tags -1 + moreinfo > > > > please file one RM bug for each package that needs to be partially removed. > > This needs to be done even for dependencies of dependencies. > > Please remove the moreinfo tag once that is done. > > As Thorsten wrote above[1] every single package needs its own bug to > enable ftpmaster removing the binary packages of 32bit architectures for > about 40 packages (currently affected by testing removals). > > I hope there is some better solution than sending single bug reports > for those packages. Sounds like a use case for devscript's mass-bug(1). Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: New supply-chain security tool: backseat-signed
On Fri, Apr 05, 2024 at 01:31:25AM +0300, Adrian Bunk wrote: > On Thu, Apr 04, 2024 at 09:39:51PM +0200, kpcyrd wrote: > >... > > I've checked both, upstreams github release page and their website[1], but > > couldn't find any mention of .tar.xz, so I think my claim of Debian doing > > the compression is fair. > > > > [1]: https://www.vim.org/download.php > >... > > Perhaps that's a maintainer running "git archive" manually? Yes, in whichever way git-deborig(1) is driving git archive. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: Silent hijacking and stripping records from changelog
On Sun, Apr 07, 2024 at 09:58:10PM +0200, Jonas Smedegaard wrote: > And when you do hijack packages²³, then please be respectful and give > credit, by preserving/reviving past contributions in the changelog file. As the person who uploaded rust-lazy-regex-proc-macros, I wasn't aware the crate already existed in Debian and wasn't intending to upload a hijack of your package. The Rust team _does_ have a lot of automated tooling and when I prepared the upload to NEW, it agreed the package was new. Now, that happens because our tooling is based around a 1:1 relationship of crate to source package where as you've been packaging an entire workspace as a source package. We need to adapt our tooling to better detect this so we get accurate information presented to us and avoid stepping on your work. I'd still prefer if we could consolidate our efforts into the rust team (and re-integrate your forks of our package helpers), rather than have two divergent sources of rust packaging. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: Silent hijacking and stripping records from changelog
On Mon, Apr 08, 2024 at 10:21:49PM +0200, Jonas Smedegaard wrote: > ...and about moving on: Can you please also clarify if you understand > "moving on" as reverting to me maintaining the package that you > accidentally hijacked, or if you instead understand it as you (on bhalf > of the Rust team) now having taken over maintainership of that package? I've already filed an RM request for src:rust-lazy-regex-proc-macros, so your package will prevail. > > Den mån 8 apr. 2024 kl 12:41 skrev James McCoy : > > > Now, that happens because our tooling is based around a 1:1 > > > relationship of crate to source package where as you've been > > > packaging an entire workspace as a source package. We need to adapt > > > our tooling to better detect this so we get accurate information > > > presented to us and avoid stepping on your work. > > Yes, please improve your tooling to better align with Debian packaging > rules, not assume your team rules apply also outside of your team. Having policy for a language ecosystem is pretty common, since that makes it easier to interoperate. > > > I'd still prefer if we could consolidate our efforts into the rust > > > team (and re-integrate your forks of our package helpers), rather > > > than have two divergent sources of rust packaging. > > I would also prefer if we could consolidate our efforts, and am open to > joining the Rust team and collaborate there, as also stated previously. > > What I am not open to is abandon the one-git-repo-per-source-package > packaging style that is commonly practiced in Debian. As I understand > it, only Haskell and Rust teams use giant-git-for-all-team-packages > style, and only the Rust team strictly enforce that style (Perl team > uses myrepos to work across many packages which I recommend you to > consider). When I first started looking into Rust packaging it was initially going to be for a workspace of crates. I didn't receive any pushback when I asked about taking over the one crate that had already been packaged and handling it from a single source package for that workspace. In the end I changed my mind and continued using the monorepo for the rest of the crates. It makes certain things easier, while using a repo based on upstream git makes other things easier. Which method is used is up to the maintainer. Not using the monorepo just requires better coordination. > More important, however, and despite what I can or cannot agree with: > For as long as the Rust team chooses to deviate from general Debian > practices, it *must* constrain those deviated rules to team work, and > *not* make the flawed assumption that all Rust crates in Debian are > aligned with Rust team packaging rules. At any time any Debian developer > may upload a rust-* package - that namespace does not belong to the Rust > team, regardless if/when I join the team. As far as I know, no one has claimed that we have sole ownership of the rust-* namespace. However, we do expect anything using that namespace is uploading a package which agrees with upstream's use of that namespace. If src:rust-foo or bin:lib-foo-dev is not the same project as foo on crates.io, then *that* is a problem. The only confusing example I'm aware of is the opposite issue -- no use of the rust-* namespace when I was expecting it to be (src:btm rather than src:rust-bottom). > I am happy that you bring up my forks of cargo-related package helpers. > I'd be delighted if they were to be adopted in dh-cargo, as that would > simplify my packaging. Only reason I haven't filed bugreports was that > my past interaction with Wimin and Josh regarding the core packaging > choices of those helper script of yours left me with a very clear > understanding that the Rust team had made those choices deliberately and > was not about to negotiate changes to them. I'm not sure how broad the sentiment is, but I would certainly like to see the workspace handling reintegrated. I've considered that for some packages I work on, and I believe others have been interested in it as well. I'm not familiar with what other changes have been made, so thank you for the pointer to the fork repo. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1072001: ITP: tree-sitter-python -- Python parser for Tree-sitter
Package: wnpp Severity: wishlist Owner: James McCoy X-Debbugs-Cc: debian-devel@lists.debian.org Control: block 1071572 by -1 * Package name: tree-sitter-python Version : 0.21.0 Upstream Contact: Max Brunsfeld * URL : https://github.com/tree-sitter/tree-sitter-python/ * License : MIT Programming Lang: JavaScript, C, Rust Description : Python parser for Tree-sitter This package provides a Python 2/3 parser for tree-sitter. It's required for the new upstream release of neovim and will be maintained in the tree-sitter team.
Bug#1072002: ITP: tree-sitter-bash -- Bash parser for Tree-sitter
Package: wnpp Severity: wishlist Owner: James McCoy X-Debbugs-Cc: debian-devel@lists.debian.org Control: block 1071572 by -1 * Package name: tree-sitter-bash Version : 0.21.0 Upstream Contact: Max Brunsfeld * URL : https://github.com/tree-sitter/tree-sitter-bash/ * License : MIT Programming Lang: JavaScript, C, Rust Description : Bash parser for Tree-sitter This package provides a bash parser for tree-sitter. It's required for the new upstream release of neovim and will be maintained in the tree-sitter team.
Bug#1072003: ITP: tree-sitter-markdown -- Markdown parser for tree-sitter
Package: wnpp Severity: wishlist Owner: James McCoy X-Debbugs-Cc: debian-devel@lists.debian.org Control: block 1071572 by -1 * Package name: tree-sitter-markdown Version : 0.2.3 Upstream Contact: Matthias Deiml * URL : https://github.com/MDeiml/tree-sitter-markdown/ * License : MIT Programming Lang: JavaScript, C, Rust Description : Markdown parser for tree-sitter This package provides a markdown parser for tree-sitter. It's required for the new upstream release of neovim and will be maintained in the tree-sitter team.
Bug#1029745: ITP: rust-tree-sitter-cli -- command-line for Tree-sitter parsers
Package: wnpp Severity: wishlist Owner: James McCoy X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rust-tree-sitter-cli Version : 0.20.7 Upstream Contact: Max Brunsfeld * URL : https://github.com/tree-sitter/tree-sitter * License : MIT Programming Lang: Rust, Javascript Description : command-line for Tree-sitter parsers tree-sitter-cli is the tool used to create, test, and use tree-sitter parsers. * why is this package useful/relevant? Neovim 0.8+ include support for using Tree-sitter parsers. This is needed to build the packages to provide the parsers. * how do you plan to maintain it? I'll be maintaining it within the Debian Rust team.
Bug#1030088: ITP: tree-sitter-c -- C grammar for tree-sitter
Package: wnpp Severity: wishlist Owner: James McCoy X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: tree-sitter-c Version : 0.20.2 Upstream Contact: Max Brunsfeld * URL : https://github.com/tree-sitter/tree-sitter-c * License : MIT Programming Lang: Javascript, C, Rust Description : C grammar for tree-sitter This package provides a tree-sitter parser for C99. This is needed for Neovim's tests and is one of the tree-sitter parsers expected to be available.
Re: RFC: Replacing vim-tiny with nano in essential packages
On Mon, Mar 16, 2020 at 11:06:11AM +0100, John Paul Adrian Glaubitz wrote: > The rationale behind that suggestion is that the vim package is becoming more > and more complex and hence more prone to build failures as can be seen from > the current build logs [1] I'd love any help fixing the test failures. As far as priorities, whatever the project/ftp-masters decide is fine with me. I've wanted to drop vim-tiny altogther, but that's been met with resistance. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: A little "research" on nvi given the vim-tiny issue
On Wed, Mar 18, 2020, 17:29 Tom H wrote: > PPS: Gentoo's vim[minimal] is vim configured using > "--with-features=tiny" like Debian's vim-tiny. > Debian's vim-tiny actual uses "--with-features=small". We used to, back in 2007, build a hybrid between small and tiny, by configuring the tiny feature set and then enabling extra features. However, that became too brittle to maintain and now most, if not all, of the features we were enabling are enabled by default upstream. >
Re: Upcoming change to perl: current directory in @INC
On Thu, Sep 08, 2016 at 02:04:21PM +0300, Lars Wirzenius wrote: > On Thu, Sep 08, 2016 at 11:55:26AM +0100, Dimitri John Ledkov wrote: > > On 29 August 2016 at 14:39, Dominic Hargreaves wrote: > > > tl;dr: '.' is being removed from perl's @INC by default; some breakage > > > in apps expected. > > > > > > For some years[1], it's been known that perl's habit of including '.' > > > in its module load path, (@INC) is potentially dangerous, since it > > > can allow untrusted code to be run under certain circumstances. However, > > > for most of that time it wasn't taken that seriously, particularly as the > > > fix is quite disruptive. > > > > Other languages do that too. E.g. python, Doesn't python have the same > > concerns then too? > > Python doesn't put . in sys.path (the search path for imported > modules). It puts the absolute path where the script was found as the > first element. Although, there were similar problem when embedding Python in other programs. See CVE-2008-5983[0] for the Python side of the issue. There were also various CVE's at the time for the programs that were doing the embedding (like Vim[1], X-Chat[2], etc.). [0]: https://security-tracker.debian.org/CVE-2008-5983 [1]: https://security-tracker.debian.org/CVE-2009-3916 [2]: https://security-tracker.debian.org/CVE-2009-3915 Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: [pkg-gnupg-maint] Bug#840669: Beware of leftover gpg-agent processes (was: Re: Changes for GnuPG in debian)
On Fri, Oct 14, 2016 at 03:21:43PM -0400, Daniel Kahn Gillmor wrote: > On Fri 2016-10-14 13:17:06 -0400, Ian Jackson wrote: > > This (and the change to gnupg2) has now broken dgit's DEP-8 test > > suite, when run under schroot. I'm discussing this in #840669 (CC'd). > > in particular, the lack of a cleanup process breaks the test suite. If > the test suite had a cleanup process, we know exactly how to "un-break" > things. > > > I am trying to persaude Daniel that we should provide (at least > > optionally) a mode where an autostarted agent (and the corresponding > > authorisations, if the user types in a passphrase) have a lifetime > > limited by that of the gpg process which started the agent. > > fwiw, i'm not the person who needs persuading. Ian's proposal is rather > complex, seems likely to introduce new problems, and it isn't a change > i'm up for either writing myself or supporting as a divergence from > GnuPG upstream. > > The simple fix (cleaning up the test suite by eithe deleting the > temporary GNUPGHOME directory or by invoking "gpgconf --kill gpg-agent") > is a lot more straightforward. I had to make a similar change[0] for devscripts' test suite, and it was indeed pretty straightforward. The biggest hurdle was my fingers making typos. Granted, the code to create the temporary GNUPGHOME for the test was already there, so it was just a matter of killing the agent. Supporting setup and teardown around a test suite/case seems pretty typical. Heck, even sh supports performing an action on exit (via trap). [0]: https://anonscm.debian.org/cgit/collab-maint/devscripts.git/commit/?id=4038fbd93536c17ec2ad9cdb1b68acaae5782184&context=3&ignorews=1&dt=0 Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: More 5 november in the release schedule
On Thu, Nov 10, 2016 at 12:24:20AM +0100, Wouter Verhelst wrote: > On Tue, Nov 08, 2016 at 11:05:59AM +0100, Christian Seiler wrote: > > 30 days within the deep freeze should be plenty enough - and as I > > said: if the problem is more complicated, just talk to the release > > team _while the package is still in testing_. > > Let's say I'm on holiday (or I get hit by a bus and end up in hospital, > or I get a major project at work which eats up all my time, or whatnot) > and I don't notice for a while that a package that I maintain gets an RC > bug. The automated machinery throws the package out before I have time > to work on the package again. Now what? If I understand correctly, activity on the bug resets the counter, so you could ping it to say that you're busy right now but will look at it in a few days or some such. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: depending on libssl1.0-dev, buildd fails to find it
On Sun, Dec 18, 2016 at 01:55:16AM +, Sean Whitton wrote: > Hello Christian, > > On Sat, Dec 17, 2016 at 05:40:49PM +0100, Christian Seiler wrote: > > On 12/17/2016 04:49 PM, Daniel Pocock wrote: > > > In my reSIProcate control[1] file, I included the following: > > > > > > Build-Depends: ... , libssl-dev (<< 1.1) | libssl1.0-dev (>= 1.0.0), ... > > > > > > pdebuild correctly builds it for sid with libssl1.0-dev from openssl1.0[2] > > > > > > In the buildd[3] report, it says that libssl-dev is uninstallable on > > > every platform, it doesn't appear to try libssl1.0-dev > > > > > > Is buildd sensitive to the order of the dependencies when multiple > > > options are given? Or is there some other glitch here? > > > > sbuild will always use the first alternative of build > > dependencies. If you're doing this to make backporting easier, > > then I'm afraid that won't work - you'll have to manually > > change the B-D for backports. > > Do you know why sbuild is ignoring alternative build-deps? As Arno hinted at, it's to have reliable builds. A transient inability to install the first arm of an alternation should caused a dep-wait state, not building with the alternate Build-Depends. Now, backports are a different story because they use a different resolver which will pull in alternates. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: depending on libssl1.0-dev, buildd fails to find it
On Dec 18, 2016 05:38, "Mattia Rizzolo" wrote: On Sat, Dec 17, 2016 at 09:27:12PM -0500, James McCoy wrote: > Now, backports are a different story because they use a different > resolver which will pull in alternates. afaik sbuild strips the alternatives while parsing the .dsc (or d/control or whatever), before passing the information to the resolvers, so even if you use another resolver for -bpo you still get the same behaviour. Well, sbuild's man page documents that the aptitude resolver will check alternatives. If it doesn't in practice, that sounds like a bug. Cheers, James
Re: depending on libssl1.0-dev, buildd fails to find it
On Sun, Dec 18, 2016 at 02:26:09PM +0100, Ondrej Novy wrote: > Hi, > > 2016-12-18 14:14 GMT+01:00 James McCoy : > > Well, sbuild's man page documents that the aptitude resolver will check > alternatives. If it doesn't in practice, that sounds like a bug. > > > you need to run sbuild with "--resolve-alternatives" or add same option in > sbuildrc. Imho bug in manpage. Quoth the man page: --build-dep-resolver=resolver … The aptitude resolver is very similar, but smarter and slower, and it will consider all alternatives by default; it is suited to more complex situations, such as building packages for the experimental distribution, where packages need installing from multiple suites (unstable and experimental). … --resolve-alternatives Allow the use of alternatives in Build-Depends, Build-Depends-Arch and Build-Depends-Indep. This is the default for the aptitude dependency resolver. so there shouldn't be a need to use --resolve-alternatives with --build-dep-resolver=aptitude. The python-tornado backport didn't even make it to the buildd, so the issue you're seeing is probably related to wanna-build. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#848591: wanna-build: Only enable --deb-emulate-sbuild for non-backports builds
Package: buildd.debian.org
Tags: patch
On Sun, Dec 18, 2016 at 12:15:24PM +0100, Ondrej Novy wrote:
> 2016-12-18 11:38 GMT+01:00 Mattia Rizzolo :
> > afaik sbuild strips the alternatives while parsing the .dsc (or
> > d/control or whatever), before passing the information to the resolvers,
> > so even if you use another resolver for -bpo you still get the same
> > behaviour.
>
> right:
>
> https://buildd.debian.org/status/package.php?p=python-tornado&suite=jessie-backports
> https://anonscm.debian.org/cgit/python-modules/packages/python-tornado.git/tree/debian/control#n24
>
> python-tornado build-depends on missing:
> - python3:arm64 (>= 3.5)
>
> So jessie-backports buildd have this "bug" too.
On Sun, Dec 18, 2016 at 10:04:46AM -0500, James McCoy wrote:
> On Sun, Dec 18, 2016 at 02:26:09PM +0100, Ondrej Novy wrote:
> > Hi,
> >
> > 2016-12-18 14:14 GMT+01:00 James McCoy :
> >
> > Well, sbuild's man page documents that the aptitude resolver will check
> > alternatives. If it doesn't in practice, that sounds like a bug.
> >
> >
> > you need to run sbuild with "--resolve-alternatives" or add same option in
> > sbuildrc. Imho bug in manpage.
> […]
> The python-tornado backport didn't even make it to the buildd, so the
> issue you're seeing is probably related to wanna-build.
I think the attached patch will help, but I wasn't sure how to actually
test it.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
>From 56e9530528835a0ee8eecd1a0093da2a60166b06 Mon Sep 17 00:00:00 2001
From: James McCoy
Date: Sun, 18 Dec 2016 10:50:33 -0500
Subject: [PATCH] Only enable --deb-emulate-sbuild for non-backports builds
fbf59be7c5efcfbb6b991b06c9a4db148e331a4a unconditionally added
--deb-emulate-sbuild to @doseoptions, but this breaks detection of
available dependencies for backports builds.
Signed-off-by: James McCoy
---
bin/wanna-build | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/bin/wanna-build b/bin/wanna-build
index a9e9b27..dcd7903 100755
--- a/bin/wanna-build
+++ b/bin/wanna-build
@@ -1756,7 +1756,8 @@ sub wb_dose_builddebcheck {
my $args = shift;
my $architecture=$args->{arch};
-my @doseoptions = qw(--failures --explain --quiet --deb-emulate-sbuild);
+my @doseoptions = qw(--failures --explain --quiet);
+push @doseoptions, '--deb-emulate-sbuild' if $distribution !~ /backports/;
my $packagefiles = $args->{pkgs};
my $sourcesfile = $args->{src};
--
2.11.0
Re: Help with watch file
On Thu, Dec 22, 2016 at 05:42:43PM -0500, Bill Blough wrote:
> On Thu, Dec 22, 2016 at 12:40:26PM +, Ian Jackson wrote:
> > suffers rather from leaning toothpick syndrome. Does the
> > `downloadurlmangle' support Perl's ability to handle nonstandard
> > delimiters ? Using something other than / means that / does not need
> > to be \-escaped. { } are often a good choice.
>
> A quick look through the uscan source suggests that it does not.
> However, Paul's solution is way cleaner than mine, so it's probably
> moot, at least in this case.
It should be supported. The safe_replace[0] function makes no
assumptions about what the separator is.
[0]:
https://anonscm.debian.org/cgit/collab-maint/devscripts.git/tree/scripts/uscan.pl?id=bce34b8d7fa410e64c411bd780f8e21603167ae7#n4441
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
