Bug#900958: ITP: barebox-host-tools -- useful development tools from the barebox source tree
Package: wnpp Severity: wishlist Owner: Roland Hieber * Package name: barebox-host-tools Version : 2018.05.0 Upstream Author : Sascha Hauer and others * URL : https://barebox.org * License : GPL, LGPL Programming Lang: C Description : useful development tools from the barebox source tree Barebox is a bootloader for booting Linux on embedded devices. Its source tree contains some useful tools which can also be used stand-alone: - bareboxenv: generate or read a barebox environment archive - bareboximd: Extract metadata from a barebox image - imx-usb-loader: USB image loader for i.MX series processors - omap3-usb-loader, omap4_usbboot: USB image loaders for OMAP processors I plan to package the last two tools into separate binary packages. With certain effort, barebox itself could also be packaged as a bootloader, but the host tools should suffice for now. I'm not a Debian maintainer mysqlf, but Uwe (Cc'd) has already offered to sponsor this package.
Bug#900969: ITP: node-merge-source-map -- Merge javascript source map
Package: wnpp Severity: wishlist Owner: ro...@debian.org X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-merge-source-map Version : 1.1.0 Upstream Author :kato kei * URL : https://github.com/keik/merge-source-map#readme * License : Expat Programming Lang: JavaScript Description : Merge javascript source map This package merge two source map in order to create an unique source map. . Source maps allow tools to display unminified code from minified code with an optimized mapping between them, thus allowing easy debugging a minified javascript. . This package is a dependency of browserify, a JavaScript tool that allows developers to write Node.js-style modules that compile for use in the browser . Node.js is an event-based server-side JavaScript engine.
Re: autopkgtest results influencing migration from unstable to testing
On June 6, 2018 12:45:55 PM GMT+05:30, Pirate Praveen wrote: >Thanks everyone, I have added breaks now. But even now it added 10 days delay. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: autopkgtest results influencing migration from unstable to testing
On Thu, Jun 07, 2018 at 07:03:38PM +0530, Pirate Praveen wrote: > On June 6, 2018 12:45:55 PM GMT+05:30, Pirate Praveen > wrote: > >Thanks everyone, I have added breaks now. > > But even now it added 10 days delay. Please give it some time. The last test run was done only half an hour ago, and it correctly passed now. Also, Brtiney already noticed it, and if you look at https://release.debian.org/britney/update_excuses.html#ruby-state-machines you'll read "Required age reduced by 3 days because of autopkgtest", so everything is great. Tracker has a 4 hours delay on updating info whereas Britney now updates hourly. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: autopkgtest results influencing migration from unstable to testing
On 07/06/2018 15:33, Pirate Praveen wrote: On June 6, 2018 12:45:55 PM GMT+05:30, Pirate Praveen wrote: Thanks everyone, I have added breaks now. But even now it added 10 days delay. It looks like the test on 2018-06-07 12:22:45 UTC was successful [1]. Maybe give the tracker page a little while to refresh? [1] https://ci.debian.net/packages/r/ruby-state-machines-activemodel/testing/amd64/
Re: autopkgtest results influencing migration from unstable to testing
Hi On 07-06-18 15:52, Mattia Rizzolo wrote: > Tracker has a 4 hours delay on updating info whereas Britney now updates > hourly. Tracker only syncs 4 times a day (code needs to be reorganized to fix this properly, patches welcome I guess), so the delay can be 6.5 hours from the moment britney figures out what should happen (the excuses.yaml is synced at *:30 while britney runs at *:00, qa.debian.org/excuses.php is getting it's data at *:45, so I use that personally most of the time. I don't know the timings of packages.qa.debian.org, they are NOT the same as qa.debian.org/excuses.php). Paul signature.asc Description: OpenPGP digital signature
Re: autopkgtest results influencing migration from unstable to testing
On Thu, Jun 07, 2018 at 05:50:03PM +0200, Paul Gevers wrote: > Hi > > On 07-06-18 15:52, Mattia Rizzolo wrote: > > Tracker has a 4 hours delay on updating info whereas Britney now updates > > hourly. > > Tracker only syncs 4 times a day sorry, I confused every 4 hours with 4 times a day... :\ Thanks for correcting me! -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: concerns about Salsa
]] Russell Stuart > On Tue, 2018-06-05 at 15:44 +0100, Ian Jackson wrote: > > Packages are great for software which you can just install and use > > without much fuss. That is often true for mature software. But for > > services which are less mature, and more complex, and which have more > > tentacles, the admin is likely to need to change things. This makes > > using packages awkward. > > I think it's better to express the trade off in terms of consequences. > > - Using software packaged by a distro requires very little effort, > which makes packaged software the ultimate sysadmin force > multiplier. I know sysadmin's who exploit it to the extent they > maintain literally 1000's of working boxes. > > - Taking a package straight from the developer gives you flexibility > using software packaged simply can't provide or worse you can't use > it at all because it's not packaged. The downside is you become a > nurse maid for the box it's installed on. Nurse maid's are literally > orders of magnitude less productive than one sysadmin maintaining an > automated assembly line, so the end product had better be orders of > magnitude more useful than the packaged version. Packages does not imply automation (lots of people maintain machines by logging into each one and running apt by hand and $EDITOR on their configuration files; I suspect this applies to the majority of desktops and laptops by people on this list), and git repositories do not imply not-automation. Those are simply transport mechanisms for bits and the level of automation you use is not decided by git-vs-packages. For debian.org hosts, the choice is primarily a matter of privilege separation: Service owners generally don't have root on the hosts, and so if they are to be able to update the service configuration, the service must run as a user they have access to or we need to build control planes with access controls which allow service owners to control their service. DSA has root on the hosts and maintain those, but we don't run all our services, so we'd rather not be on the critical path for updating various services (which we'd need to be if those came from packages). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: autopkgtest results influencing migration from unstable to testing
Mattia Rizzolo writes ("Re: autopkgtest results influencing migration from
unstable to testing"):
> On Thu, Jun 07, 2018 at 05:50:03PM +0200, Paul Gevers wrote:
> > On 07-06-18 15:52, Mattia Rizzolo wrote:
> > > Tracker has a 4 hours delay on updating info whereas Britney now updates
> > > hourly.
> >
> > Tracker only syncs 4 times a day
>
> sorry, I confused every 4 hours with 4 times a day... :\
In general it is nice if systems that periodically produce data give
an indication of when they were most recently updated; and even better
if they also report the dates reported by all of their inputs; and say
when they will next poll for updates. That would probably save a lot
of human effort.
Do we have a standardised format for any of our services to report
this origin timing information ? (I run only one service in Debian
and it is supposed to always produce up-to-date data...)
Ian.
Re: concerns about Salsa
]] Russ Allbery I agree with the points in your mail, but I wanted to expand slightly on where I think Debian stands in the scale you described. > I think people's varying reactions on this thread may have a lot to do > with where they are in this hierarchy of scale, and what problems they > therefore anticipate. But the Debian Project infrastructure itself seems > to me to be firmly in that middle tier where it makes sense to run the > core thing out of Git and the supporting scaffolding from packages. We > have a lot of things that we're working on directly and intensely as the > core mission of that part of the project, but generally they're deployed > on one or two machines and don't need management at scale, canarying, and > rollback properties. As DSA, I'd love to have Kubernetes or similar in stable so we could have deployment using containers and just rebuild those and then service owners could have a good way to do both development, testing and deployment of their services. It would also offer a much better way for people to help out with services: If you want to help with, say, packages.d.o, you can download the git repo and some sample data (or database schema + importer), build a container with your changes and then test them. This is significantly easier than the current way, which is something like: install a set of packages (defined in the debian metapackages repo), then maybe set up some scaffolding (defined in dsa-puppet), then deploy the service (with scripts that make assumptions about the environment, host names, etc; if you're unlucky that «script» is only in the service owner's .$SHELL_history file), then test that and finally provide a patch with just the relevant changes for the feature or bug you're trying to implement or fix. So while we're not likely to have many deployments of each service, lowering the bar for setting up services, defining a very clear boundary between the service and its surroundings and making service development much easier would be worth it for us. > More broadly, one useful way to think about the mission of a Linux > distribution is to make all the things our users *don't* care about > effortless and simple, so that they can invest all of their energy and > attention into the one or two things they *do* care about. Trying to get > them to package those few things that they care about deeply is more > dubious and often doesn't add much value for them. This is a good point. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: concerns about Salsa
On 2018-06-07 18:48:58 +0200 (+0200), Tollef Fog Heen wrote: [...] > So while we're not likely to have many deployments of each > service, lowering the bar for setting up services, defining a very > clear boundary between the service and its surroundings and making > service development much easier would be worth it for us. [...] While we don't operate under the same set of constraints and assumptions, on the OpenStack Infrastructure team (basically the OpenStack community's analogue of Debian's DSA) we found that having a consistent and standardized framework for deploying the services we operate on behalf of our community significantly increased the ability of interested contributors to participate in the process of designing and maintaining those services. Granted, we don't give out SSH access to the servers and we drive these sorts of tasks through code-reviewed changes to automation and configuration management; but the idea that you as a random individual with no root access to the production servers can with just a few minutes locally deploy a dev version of one of our services, modify it and then propose a patch (which subsequently gets regression tested, reviewed by the root sysadmin team, and then automatically deployed to production) is very empowering for our community at large. -- Jeremy Stanley signature.asc Description: PGP signature
Standards-Version and compat level
Hi Which Standards-Version and compat level should I use in the Debian packages I publish? - Tommi Höynälänmaa
Re: Standards-Version and compat level
On Thu, Jun 07, 2018 at 06:26:56PM +0300, Tommi Höynälänmaa wrote: > Which Standards-Version and compat level should I use in the Debian packages > I publish? try running lintian from sid on your .changes file :) spoiler: 4.1.4 and 11. -- cheers, Holger signature.asc Description: PGP signature
Re: Standards-Version and compat level
Hello, On Thu, Jun 07 2018, Tommi Höynälänmaa wrote: > Hi > > Which Standards-Version and compat level should I use in the Debian > packages I publish? Do you mean publish outside of Debian? Or in Debian? For the standards version, you should use whatever version of Debian Policy the package is compliant with. Please be sure you understand the purpose of the standards version field before using it! https://www.debian.org/doc/debian-policy/#s-f-standards-version -- Sean Whitton signature.asc Description: PGP signature
Bug#901001: python3-minimal should Pre-Depend on python3.N-minimal
Package: python3-default Severity: serious When python3 default version changes, and a new python3-minimal is unpacked before its python3.N-minimal, we end up with a system without a working python3 symlink. This breaks upgrades because prerm scripts of python3 packages use: if which py3clean >/dev/null 2>&1; then py3clean -p PKGNAME the which succeeds, as py3clean exists, but since the python3 symlink will be broken, py3clean will be run and fail with Not Found. (originally reported at https://bugs.launchpad.net/bugs/1768379) (CCing debian-devel) -- System Information: Debian Release: buster/sid APT prefers cosmic APT policy: (500, 'cosmic'), (100, 'cosmic-proposed') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-20-generic (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Re: concerns about Salsa
On Thu, 2018-06-07 at 18:14 +0200, Tollef Fog Heen wrote: > Packages does not imply automation (lots of people maintain machines > by logging into each one and running apt by hand and $EDITOR on their > configuration files; I suspect this applies to the majority of > desktops and laptops by people on this list), and git repositories do > not imply not-automation. Those are simply transport mechanisms for > bits and the level of automation you use is not decided by git-vs- > packages. No, distros are not "just transport mechanisms". In particular they allow security patch upgrades to be automated by doing several things. On is automatically scanning for them and installing them which some rare packages do provide (eg, browsers) and the second is supplying back ported security patches which gives a good enough guarantee it will be backward compatible that I let them through without testing. I'll drive the point home with yesterdays (literally yesterdays) headline: "Three months later, a mass exploit of powerful Web servers continues". The headline is referring to the 1000's of unpatched Drupal servers out there, unpatched because patching required upgrading to the latest version which is too hard. Wordpress sites using the Debian package with unattended upgrades installed would likely have been patched before news of the exploit made the headlines. In a nod to Salsa's team, they have taken the road you suggest and automated everything they can with Ansible. And yes, it's true the burden of supplying these security back patches may fall on them, so packaging it would not save them time. But that's how it works for DD's - we don't do this for our benefit, it's the rest of the world that benefits. > For debian.org hosts, the choice is primarily a matter of privilege > separation: Service owners generally don't have root on the hosts, > and so if they are to be able to update the service configuration, > the service must run as a user they have access to or we need to > build control planes with access controls which allow service owners > to control their service. DSA has root on the hosts and maintain > those but we don't run all our services, so we'd rather not be on > the critical path for updating various services (which we'd need to > be if those came from packages). I accept that's doesn't leave the Salsa team with much choice, but it still leaves me scratching my head. Containers / VPS's / VM have been a thing for years now. They solve this separation problem in a way that reduces the workload for everyone. signature.asc Description: This is a digitally signed message part
Bug#901003: There is no standard way of removing transitional / dummy packages
Package: general There is no standard way of removing transitional / dummy packages. One has to grep for the words transitional / dummy in their descriptions to find them. They should all have a standard Tag:. And the Debian documentation should mention what apt command will remove them.
Re: Hi, I am blind
I think accessibility for the blind will help us all. For example, there are times when a sighted person might be better served with an audio interface, or an alternate visual interface. I hope to explore some of the options myself. Thanks for the pointers, Mengual. On Sun, Apr 15, 2018 at 3:21 PM MENGUAL Jean-Philippe wrote: > > Hi, > > Le 15/04/2018 à 15:49, Steffen Möller a écrit : > > Hi, > > > > > > The problem with Debian for supporting blind users is that most of its > > developers are not (yet) visually impaired beyond wearing glasses. They > > don't have the devices which are costly and even if they had then they > > likely have nobody to test it. I have no immediate idea how to help that > > situation. > > It is quite important that accessibility work not to be done only by > disabled persons. First because in free software, disable persons are > few. Next because to make an inaccessible program accessible, difficult > without any idea about what it looks. Major developers of accessibility > in free software have no visual problems: Orca is developped by > Joanmarie, GNOME accessibility by Alejandro Pinero, Debian installer by > Samuel, etc > > To help, you can take as basis what Samuel Thibault explained at Debconf > 2015 (Heidelberg). His talk explained many things. Other useful > resources are on Development page of the Hypra website. > > To sum up, exploring a program via accerciser shows what it sends to > accessibility stack and how it is accessible. Running orca with -e > braille-monitor option shows what a user will read on a braille display. > brltty provides similar features for people without braille display > (Samuel does not have one). Finally, if devs could label correctly their > widgets and create correct relationship between them, it would help. > > In Debian, the fact the installer is accessible is quite excellent. The > fact the accessibility is enabled by defautl in GUI is good. I think the > most effort needs to be done upstream now. Of course, see > https://wiki.debian.iorg/accessibility-devel for todo specific to > Debian. For example, adding a tag to mention if some package is or not > accessible would be a good idea. > > Regards > > > > > Cheers, > > > > Steffen > > > > > -- -- Best Regards. This is unedited. This message came out of me via a suboptimal keyboard.
Work-needing packages report for Jun 8, 2018
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1301 (new: 4) Total number of packages offered up for adoption: 159 (new: 2) Total number of packages requested help for: 53 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: cpqarrayd (#900559), orphaned 6 days ago Description: monitoring tool for HP (Compaq) SmartArray controllers Installations reported by Popcon: 174 Bug Report URL: http://bugs.debian.org/900559 logfs-tools (#900755), orphaned 3 days ago Description: Tools to manage logfs filesystems Reverse Depends: logfs-tools-dbg Installations reported by Popcon: 127 Bug Report URL: http://bugs.debian.org/900755 python2-pythondialog (#900614), orphaned 5 days ago Description: Python 2 module for making simple terminal-based user interfaces Installations reported by Popcon: 1067 Bug Report URL: http://bugs.debian.org/900614 schroot (#900874), orphaned yesterday Description: Execute commands in a chroot environment Reverse Depends: buildd debci-worker debomatic mini-buildd python-schroot python3-schroot sbuild-debian-developer-setup schroot Installations reported by Popcon: 2178 Bug Report URL: http://bugs.debian.org/900874 1297 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: note (#900663), offered 4 days ago Description: small program managing notes from commandline Installations reported by Popcon: 67 Bug Report URL: http://bugs.debian.org/900663 opendkim (#900774), offered 3 days ago Description: Milter implementation of DomainKeys Identified Mail Reverse Depends: libopendkim-dev librbl-dev libvbr-dev milter-greylist opendkim opendkim-tools Installations reported by Popcon: 1637 Bug Report URL: http://bugs.debian.org/900774 157 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: autopkgtest (#846328), requested 554 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker openstack-pkg-tools Installations reported by Popcon: 1088 Bug Report URL: http://bugs.debian.org/846328 balsa (#642906), requested 2447 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 643 Bug Report URL: http://bugs.debian.org/642906 broadcom-sta (#886599), requested 150 days ago (non-free) Description: Broadcom STA Wireless driver (non-free) Installations reported by Popcon: 1906 Bug Report URL: http://bugs.debian.org/886599 cargo (#860116), requested 422 days ago Description: Rust package manager Reverse Depends: dh-cargo Installations reported by Popcon: 615 Bug Report URL: http://bugs.debian.org/860116 cups (#532097), requested 3288 days ago Description: Common UNIX Printing System Reverse Depends: ayatana-indicator-printers bluez-cups boomaga chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd (67 more omitted) Installations reported by Popcon: 171290 Bug Report URL: http://bugs.debian.org/532097 cyrus-sasl2 (#799864), requested 988 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli autofs-ldap cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier claws-mail-address-keeper claws-mail-archiver-plugin (120 more omitted) Installations reported by Popcon: 194242 Bug Report URL: http://bugs.debian.org/799864 dee (#831388), requested 692 days ago Description: model to synchronize mutiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-1.0-4-dbg libdee-dev zeitgeist-core Installations reported by Popcon: 60373 Bug Report URL: http://bugs.debian.org/831388 developers-reference (#759995), requested 1377 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 12871 Bug Report URL: http://bugs.debian.org/759995 devscripts (#800413), requested 982 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero autodeb-worker brz-debian b
Bug#901009: ITP: kubectx -- Fast way to switch between clusters and namespaces in kubectl
Package: wnpp
Severity: wishlist
Owner: ChangZhuo Chen (陳昌倬)
* Package name: kubectx
Version : 0.5.0
Upstream Author : Name
* URL : https://github.com/ahmetb/kubectx
* License : Apache-2
Programming Lang: bash
Description : Fast way to switch between clusters and namespaces in
kubectl
This package provides kubectx and kubens tools. kubectx is an utility
to manage and switch between kubectl contexts. kubens is an utility to
switch between Kubernetes namespaces.
--
ChangZhuo Chen (陳昌倬) czchen@{czchen,debconf,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B
signature.asc
Description: PGP signature
Bug#901003: There is no standard way of removing transitional / dummy packages
Control: reassign -1 debian-handbook On Fri, 2018-06-08 at 07:08 +0800, 積丹尼 Dan Jacobson wrote: > Package: general > > There is no standard way of removing transitional / dummy packages. > > One has to grep for the words transitional / dummy in their > descriptions to find them. > > They should all have a standard Tag:. Developers' Reference says to put them in the oldlibs section: https://www.debian.org/doc/manuals/developers-reference/ch06.en.html#bpp-transition > And the Debian documentation should mention what apt command will > remove them. I don't think you can do it with apt, but deborphan can identify various kinds of unneeded packages and aptitude should be able to select and remove packages in the oldlibs section. Reassigning this to debian-handbook, which doesn't seem to say anything about this currently. Ben. -- Ben Hutchings When in doubt, use brute force. - Ken Thompson signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#901003: There is no standard way of removing transitional / dummy packages
Processing control commands: > reassign -1 debian-handbook Bug #901003 [general] There is no standard way of removing transitional / dummy packages Bug reassigned from package 'general' to 'debian-handbook'. Ignoring request to alter found versions of bug #901003 to the same values previously set Ignoring request to alter fixed versions of bug #901003 to the same values previously set -- 901003: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901003 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: concerns about Salsa
On Fri, Jun 8, 2018 at 6:46 AM, Russell Stuart wrote: > I'll drive the point home with yesterdays (literally yesterdays) > headline: "Three months later, a mass exploit of powerful Web servers > continues". The headline is referring to the 1000's of unpatched > Drupal servers out there, unpatched because patching required upgrading > to the latest version which is too hard. Wordpress sites using the > Debian package with unattended upgrades installed would likely have > been patched before news of the exploit made the headlines. In my experience the Wordpress upstream auto-upgrade system is typically faster than the Debian's handling of Wordpress. I also get the impression that the number of CVEs (let alone all security issues) is scaling faster than the amount of folks in Debian who are handling them. -- bye, pabs https://wiki.debian.org/PaulWise
Hibernate not working !
I am currently running Debian Stretch and MATE desktop. I have noticed a while back the hibernate option disappearing from desktop options and have found this does not work. Is there any reason for this not working on Debian Stretch or Debian Jessie or even other Linii I have tried ? Regards, Aaron -- Aaron Gray Independent Open Source Software Engineer, Computer Language Researcher, Information Theorist, and amateur computer scientist.
