Re: autopkgtest results influencing migration from unstable to testing
Hi all, On 06-06-18 08:52, Simon McVittie wrote: > On Wed, 06 Jun 2018 at 10:28:53 +0530, Pirate Praveen wrote: >> ruby-state-machines and ruby-state-machines-activemodel should go >> together and even when autopkgtest for the version is unstable passed, >> instead of reducing the age, it is considered a regression because >> autopkgtest for the version in testing failed and age is increased. > > Isn't this a sign that ruby-state-machines has broken API, and should gain > "Breaks: ruby-state-machines-activemodel (<< 0.5)" or similar before it > migrates to testing? If so, then the autopkgtest is doing its job: it > has found a bug. I fully agree. In the past this hasn't been such an issue because typically timing would be all right, but... > If packages in unstable "should go together" then you need to tell > apt that, otherwise it will assume that arbitrary partial upgrades are > a valid solution. Testing migration uses the same metadata. it is fragile to not document it. Autopkgtest will do the right thing if you tell apt how to handle the dependencies. Indeed, the last couple of months multiple packages needed a "Breaks" statement and everything was all right afterwards. Paul signature.asc Description: OpenPGP digital signature
Re: autopkgtest results influencing migration from unstable to testing
On 6 June 2018 at 06:58, Pirate Praveen wrote: > I think we need to handle cases like this, > > https://tracker.debian.org/pkg/ruby-state-machines > > ruby-state-machines and ruby-state-machines-activemodel should go > together and even when autopkgtest for the version is unstable passed, > instead of reducing the age, it is considered a regression because > autopkgtest for the version in testing failed and age is increased. > > I think in cases where version differs in testing and unstable, > regression in testing should not delay migration. Won't adding appropriate Breaks handle this already?
Re: autopkgtest results influencing migration from unstable to testing
On Wednesday 06 June 2018 12:22 PM, Simon McVittie wrote: > On Wed, 06 Jun 2018 at 10:28:53 +0530, Pirate Praveen wrote: >> ruby-state-machines and ruby-state-machines-activemodel should go >> together and even when autopkgtest for the version is unstable passed, >> instead of reducing the age, it is considered a regression because >> autopkgtest for the version in testing failed and age is increased. > > Isn't this a sign that ruby-state-machines has broken API, and should gain > "Breaks: ruby-state-machines-activemodel (<< 0.5)" or similar before it > migrates to testing? If so, then the autopkgtest is doing its job: it > has found a bug. > > If packages in unstable "should go together" then you need to tell > apt that, otherwise it will assume that arbitrary partial upgrades are > a valid solution. Testing migration uses the same metadata. Thanks everyone, I have added breaks now. signature.asc Description: OpenPGP digital signature
Bug#900874: O: schroot -- Execute commands in a chroot environment
Package: wnpp Severity: normal I just orphaned the schroot package. I never really want to assume its maintainance but it just happened that at some point I was unhappy with unresolved bugs with pending patches and someone had to step in and I did. Now this package is still an important building block of our build infrastructure and it deserves a better maintainer than me (my last upload dates back to one year ago). The upstream maintainer (Roger Leigh) is still around and reachable although he's not doing much work on schroot AFAIK. The package is in Salsa in the debian group so all DD can easily contribute to its maintainance: https://salsa.debian.org/debian/schroot The package description is: schroot allows users to execute commands or interactive shells in different chroots. Any number of named chroots may be created, and access permissions given to each, including root access for normal users, on a per-user or per-group basis. Additionally, schroot can switch to a different user in the chroot, using PAM for authentication and authorisation. All operations are logged for security. . Several different types of chroot are supported, including normal directories in the filesystem, and also block devices. Sessions, persistent chroots created on the fly from files (tar with optional compression) and Btrfs and LVM snapshots are also supported. . schroot supports kernel personalities, allowing the programs run inside the chroot to have a different personality. For example, running 32-bit chroots on 64-bit systems, or even running binaries from alternative operating systems such as SVR4 or Xenix. . schroot also integrates with sbuild, to allow building packages with all supported chroot types, including session-managed chroot types such as Btrfs and LVM snapshots. . schroot shares most of its options with dchroot, but offers vastly more functionality.
Bug#900881: ITP: gokey -- simple vaultless password manager in Go
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: gokey Version : 0.0~git20170602.05f83bb Upstream Author : Ignat Korchagin * URL : https://github.com/cloudflare/gokey * License : BSD-3-clause Programming Lang: Go Description : simple vaultless password manager in Go gokey is a password manager, which does not require a password vault. Instead of storing your passwords in a vault it derives your password on the fly from your master password and supplied realm string (for example, resource URL). This way you do not have to manage, backup or sync your password vault (or trust its management to a third party) as your passwords are available immediately anywhere. I want to maintain this package in the Debian Go Packaging Team. -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: https://www.profitbricks.de Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens
Bug#900900: ITP: oci-image-tools -- OCI image tooling
Package: wnpp Severity: wishlist Owner: Dmitry Smirnov X-Debbugs-CC: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package name: oci-image-tools Version: 1.0.0~rc1 Upstream Author: The Linux Foundation License: Apache-2.0 URL: https://github.com/opencontainers/image-tools Vcs-Browser: https://salsa.debian.org/go-team/packages/oci-image-tools Description: OCI image tooling oci-image-tool is a collection of tools for working with the OCI image format specification (https://github.com/opencontainers/image-spec). --- "oci-image-tool" binary package was formerly provided by "image-spec" but now it has its own repository. signature.asc Description: This is a digitally signed message part.
Renew SSO Cert (was: its dead jim - alioth is gone)
Hi, First, thanks Alexander and everyone involved in alioth/salsa migration! Le 05/06/2018 à 21:49, Alexander Wirt a écrit : > […] > Whats left? > > […] > - deploy the new sso.debian.org backend What are the plans regarding the new sso.debian.org backend? In particular for non-DD or DM profiles that need to renew their cert? Cheers k
Re: Renew SSO Cert (was: its dead jim - alioth is gone)
On Wed, 06 Jun 2018, kaliko wrote: > Hi, > > First, thanks Alexander and everyone involved in alioth/salsa migration! > > Le 05/06/2018 à 21:49, Alexander Wirt a écrit : > > […] > > Whats left? > > > > […] > > - deploy the new sso.debian.org backend > > What are the plans regarding the new sso.debian.org backend? > In particular for non-DD or DM profiles that need to renew their cert? You can still login to sso. During gsoc we are currently developing a new frontend/backend. Alex
Re: autopkgtest results influencing migration from unstable to testing
On 05.06.2018 22:54, Paul Gevers wrote: Hi all, On 06-06-18 08:52, Simon McVittie wrote: On Wed, 06 Jun 2018 at 10:28:53 +0530, Pirate Praveen wrote: ruby-state-machines and ruby-state-machines-activemodel should go together and even when autopkgtest for the version is unstable passed, instead of reducing the age, it is considered a regression because autopkgtest for the version in testing failed and age is increased. Isn't this a sign that ruby-state-machines has broken API, and should gain "Breaks: ruby-state-machines-activemodel (<< 0.5)" or similar before it migrates to testing? If so, then the autopkgtest is doing its job: it has found a bug. I fully agree. In the past this hasn't been such an issue because typically timing would be all right, but... If packages in unstable "should go together" then you need to tell apt that, otherwise it will assume that arbitrary partial upgrades are a valid solution. Testing migration uses the same metadata. it is fragile to not document it. Autopkgtest will do the right thing if you tell apt how to handle the dependencies. Indeed, the last couple of months multiple packages needed a "Breaks" statement and everything was all right afterwards. agreed in principle, however it this really feasible? Usually this will result in re-uploads until you catch all these breaks.
Re: Renew SSO Cert (was: its dead jim - alioth is gone)
On Wed, 06 Jun 2018, Alexander Wirt wrote: > > What are the plans regarding the new sso.debian.org backend? > > In particular for non-DD or DM profiles that need to renew their cert? > You can still login to sso. During gsoc we are currently developing a > new frontend/backend. That's assuming your alioth account was part of some group and didn't have a trivially guassable password. If it wasn't part of a group, please contact us directly and we can manually set you up with an account that gets access to sso until the new system is in place. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Bug#900438: general: fails to hibernate correctly
Package: general Followup-For: Bug #900438 Dear Maintainer, Problems began when I upgraded from Debian 8.x to Debian 9.4. When restarting my computer after doing a hibernate most of the running processed fail to be restored. In the case of Firefox, sometimes Firefox will allows me to do a restore to recover website links and sometimes all the website links are lost. -- System Information: Debian Release: 9.4 Architecture: i386 (i686) Kernel: Linux 4.9.0-6-686 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) /proc/cpuinfo contains the following information: processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 6 model name : AMD Athlon(tm) II X2 245 Processor stepping: 2 microcode : 0x198 cpu MHz : 2915.780 cache size : 1024 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug: no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid eagerfpu pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall npt lbrv svm_lock nrip_save bugs: tlb_mmatch fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2 bogomips: 5831.56 clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor : 1 vendor_id : AuthenticAMD cpu family : 16 model : 6 model name : AMD Athlon(tm) II X2 245 Processor stepping: 2 microcode : 0x198 cpu MHz : 2915.780 cache size : 1024 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fdiv_bug: no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid eagerfpu pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall npt lbrv svm_lock nrip_save bugs: tlb_mmatch fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2 bogomips: 5831.56 clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate /proc/meminfo contains the following info: MemTotal:2067584 kB MemFree: 135528 kB MemAvailable: 648052 kB Buffers: 52664 kB Cached: 808196 kB SwapCached: 20 kB Active: 947632 kB Inactive: 895208 kB Active(anon): 597596 kB Inactive(anon): 539184 kB Active(file): 350036 kB Inactive(file): 356024 kB Unevictable: 32 kB Mlocked: 32 kB HighTotal: 1187400 kB HighFree: 15228 kB LowTotal: 880184 kB LowFree: 120300 kB SwapTotal: 4190204 kB SwapFree:4186140 kB Dirty: 5784 kB Writeback: 0 kB AnonPages:982008 kB Mapped: 339676 kB Shmem:154800 kB Slab: 49632 kB SReclaimable: 29140 kB SUnreclaim:20492 kB KernelStack:3392 kB PageTables: 6380 kB NFS_Unstable: 0 kB Bounce:0 kB WritebackTmp: 0 kB CommitLimit: 5223996 kB Committed_AS:4098212 kB VmallocTotal: 122880 kB VmallocUsed: 0 kB VmallocChunk: 0 kB HardwareCorrupted: 0 kB AnonHugePages: 0 kB ShmemHugePages:0 kB ShmemPmdMapped:0 kB HugePages_Total: 0 HugePages_Free:0 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 4096 kB DirectMap4k: 12280 kB DirectMap4M: 897024 kB /proc/interrups contains the following info: CPU0 CPU1 0: 45 0 IO-APIC 2-edge timer 1: 0 2789 IO-APIC 1-edge i8042 7: 1 0 IO-APIC 7-edge parport0 8: 0 1 IO-APIC 8-edge rtc0 9: 0 0 IO-APIC 9-fasteoi acpi 14: 0 0 IO-A
Bug#900939: ITP: yubikey-manager -- Python library and command line tool for configuring a YubiKey
Package: wnpp Severity: wishlist Owner: Nicolas Braud-Santoni * Package name: yubikey-manager Version : 0.7.0 Upstream Author : Yubico A.G. * URL : https://developers.yubico.com/yubikey-manager/ * License : BSD-2 Programming Lang: Python Description : Python library and command line tool for configuring a YubiKey YubiKey Manager (ykman) is a command line tool for configuring a YubiKey over all transports. It is capable of reading out device information as well as configuring several aspects of a YubiKey, including enabling or disabling connection transports an programming various types of credentials. It is built around a Python library for configuring YubiKey over all transport modes, for Python 2 and Python 3.
Bug#900940: ITP: python-fido2 -- Python library for implementing FIDO 2.0
Package: wnpp Severity: wishlist Owner: Nicolas Braud-Santoni * Package name: python-fido2 Version : 0.3.0 Upstream Author : Yubico A.G. * URL : https://www.github.com/Yubico/python-fido2/ * License : BSD-2 and Apache-2.0 Programming Lang: Python Description : Python library for implementing FIDO 2.0 A Python library for communicating with a FIDO device over USB HID as well as verifying attestation and assertion signatures. Supports FIDO U2F and FIDO 2.0.
