Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
On Mon, Sep 24, 2012 at 11:08:31AM +1200, Chris Bannister wrote:
> If it pulls in half of GNOME when you install it, its nice to have the
> name "gnome" in there somewhere.
Well I disagree, but either way, it doesn't¹:
> Depends: ${misc:Depends},
> ${python:Depends},
> gir1.2-champlain-0.12,
> gir1.2-gtkchamplain-0.12,
> gir1.2-gtk-3.0,
> gir1.2-glib-2.0,
> gir1.2-clutter-1.0,
> gir1.2-gdkpixbuf-2.0,
> python-lxml,
> gir1.2-gtkclutter-1.0
I don't see 'libgnome' anywhere.
¹ http://bazaar.launchpad.net/~sigurdga/maps/master/view/head:/debian/control
--
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/20120924093233.GA4417@debian
Bug#688627: ITP: genivi-audio-manager -- The GENIVI AudioManager is a software framework for low-level management of audio in the context of a car.
Package: wnpp Severity: wishlist Owner: "Jeremiah C. Foster" * Package name: genivi-audio-manager Version : 2.1 Upstream Author : Christian Linke * URL : http://www.genivi.org/projects * License : Mozilla Public License v2.0 Programming Lang: C++ Description : The GENIVI AudioManager is a software framework for low-level management of audio in the context of a car. The AudioManager is meant to abstract audio in an IVI setting in a way that creates a common API allowing an independence from routing mechanisms. Designed to handle both dynamic and static sources and sinks it provides an API upwards to other applications, like HMI. The AudioManager is not another routing mechanism however. -- 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/20120924100047.30949.69986.reportbug@debian
Bug#688629: ITP: genivi-layer-management -- Applications in an automobile are often stand-alone implementations, not integrated into a coherent whole. The Layer Management software is designed to prov
Package: wnpp Severity: wishlist Owner: "Jeremiah C. Foster" * Package name: genivi-layer-management Version : 0.9.7 Upstream Author : Michael Schuldt * URL : http://www.genivi.org/projects * License : Apache 2.0 Programming Lang: C Description : Applications in an automobile are often stand-alone implementations, not integrated into a coherent whole. The Layer Management software is designed to provide a vendor-specific layer management implementation that unifies look and feel. In the automotive domain, most HMI systems use their own window manager implementation. Many applications (e.g. navigation, reverse camera) are implemented standalone and therefore one service is used to composite all applications to final image on the screen Layer Manager. The goal of this work package is to define a common API and provide a proof-of-concept implementation for the IVI Layer Management Service. The GENIVI IVI Layer Management provides; - A well-defined interface - Standardized compositing - Convenient and consistent access to hardware accelerated modules - Separation of HMI and Layer Management - Dynamic extensions during runtime - Low integration complexity - Limited dependency on hardware -- 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/20120924100745.31007.56027.reportbug@debian
Re: assumptions about the build environment.
On Sat, Sep 22, 2012 at 07:06:57PM +0200, Adam Borowski wrote: > On Sat, Sep 22, 2012 at 04:28:32PM +0200, Wouter Verhelst wrote: > > On Sat, Sep 22, 2012 at 12:23:36AM +0200, Kurt Roeckx wrote: > > > They probably should try to use the output of dpkg-architecture to > > > select the arch. Then should never check that output of uname -m. > > > > That's living on the assumption that there's never any upstream build > > system which is both complex (thus difficult to patch correctly) and > > relying on uname -m in one or more places. I'm not saying we should > > necessarily support such systems, but if running inside something akin > > to linux32 is not causing too many problems, it would make that easier. > > What's the harm? > > That it breaks multiarch builds. Multiarch builds are not done on our buildd machines. > You'd need a separate chroot for every arch you want to be able to compile > for. Buildd machines typically have only one chroot for each distribution they build, as they don't build for multiple architectures. [...] > As for complex "hard to patch" build systems, could you give me an example? > I can't quite think of a case where patching references to uname could be > tricky. I can't give you an example of *this* particular issue; but given the amount of complex build systems I've seen, I don't think it's too unreasonable to assume they exist. I'm not saying we should change policy to mandate that i386 builds in i386 chroots should be done with linux32 running or something similar. But I also do happen to think that tuning buildd machines to do a bit more than what policy requires them to do is usually a good thing. For I used to keep debhelper installed in my buildd chroots, even though it's not part of build-essential; but since almost all packages use it in some form or another, it was being installed and deinstalled enough that I could gain some time by having it installed by default. The result was of course that packages who mistakenly failed to add debhelper to their build-depends would successfully build on my buildd hosts, but I didn't think that was much of a problem. Similarly, if adding linux32 to the environment on amd64 hosts building inside a chroot means the success rate for packages built will go up, I don't think we should refrain from doing so -- unless, of course, doing so would cause more problems than it would solve, which was the point of my question. After all, the autobuilder network is not meant to do QA; we have resources for doing full-archive rebuilds for that purpose. Instead, the autobuilder network is meant to make sure we build as many packages as possible. If we can avoid some issues in building packages that isn't really worth spelling out in policy by just doing some minor configuration tweak on a buildd host, I think we should do so -- and this certainly qualifies, IMO. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20120924111419.gq17...@grep.be
Re: Changes to Debian Maintainer upload permissions
On Sun, Sep 23, 2012 at 07:13:08PM +0200, Joachim Breitner wrote: > (BTW, source only uploads anyone? Then I can easily do the uploads on my > own and need neither the DDs nor the DMs in my team to do what computers > can do better.) If it's happening often enough, you may want to think about creating your own autobuilding environment to which you can then do source-only uploads. Signing those builds (using gpg-agent or similar) should then be fairly easy, no? -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20120924111745.gr17...@grep.be
Re: assumptions about the build environment.
Wouter Verhelst (24/09/2012): > On Sat, Sep 22, 2012 at 07:06:57PM +0200, Adam Borowski wrote: > > You'd need a separate chroot for every arch you want to be able to > > compile for. > > Buildd machines typically have only one chroot for each distribution > they build, as they don't build for multiple architectures. I guess “typically” was indeed warranted, s390/s390x come to mind (ditto on the porterbox side). Mraw, KiBi. signature.asc Description: Digital signature
Bug#679853: marked as done (general: Too much downtime during a big dist-upgrade - avoidable with snapshots)
Your message dated Mon, 24 Sep 2012 16:25:41 +0200 with message-id <201209241625.42568.hol...@layer-acht.org> and subject line too broad idea / complain has caused the Debian Bug report #679853, regarding general: Too much downtime during a big dist-upgrade - avoidable with snapshots to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 679853: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679853 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general, apt Severity: normal Today I ran "aptitude update ; aptitude dist-upgrade" on my virtual machine that provides some web applications to the clients. There were 126 updated packages (accumulated since 2012-06-18). The upgrade and the following kexec-based reboot went well, except for one thing: it took too long between stopping and starting again apache and mysql. A technology exists that can keep downtime to a minimum. It is called "btrfs snapshots", see below for the details. After Wheezy, Debian should support it natively in installer, dpkg and apt/aptitude. 1) The installer should be able to install the system to a btrfs subvolume (except /home and /var, which should be on separate subvolumes). 2) On such system, dpkg and apt/aptitude, if requested by the user and/or by default, should make a writeable snapshot of the root subvolume, mount it to some temporary location, chroot into it and perform the upgrade there. During this process, the main system will, of course, continue to work. 3) Then a kexec-based reboot should happen, using the new subvolume as the root filesystem. A kexec-based reboot is currently faster than a two-week dist-upgrade of the testing distribution, and thus it should be good for minimizing the downtime. Besides, the kernel is upgraded often in the testing distribution, thus a reboot is needed anyway. Maybe this procedure is also doable with LVM snapshots. Also note that this is different from the "offline updates" proposal from Lennart Poettering (that essentially involves running the current dist-upgrade between two reboots) and has different goals. His goal is to ensure consistency during and after the upgrade, my goal is to minimize downtime. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/1 CPU core) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- Alexander E. Patrakov --- End Message --- --- Begin Message --- Hi, closing this bug report as the idea is too broad to be usefully tracked here... please file bugs about the individual components, if at all. cheers, Holger--- End Message ---
Re: Changes to Debian Maintainer upload permissions
[Joachim Breitner] > Would it be possible to extend the syntax to specify lists of > packages not by name, but by Maintainer, > e.g. pkg-haskell-maintainers@l.a.d.o? Bonus points if such an > assigment is expanded at dinstall time, so that the statement “DM > 1234 may upload all packages owned by this group” stays up-to-date > even if after new packages of this team have been added? So ... you want to give a DM the ability to NMU any package in the archive, just by changing the Maintainer field? While I'm sure such shenanigans would be caught quickly enough and the DM LARTed, it still doesn't seem like a good idea to me. Peter -- 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/20120924165905.ga4...@p12n.org
Re: Changes to Debian Maintainer upload permissions
Hi, Am Montag, den 24.09.2012, 11:59 -0500 schrieb Peter Samuelson: > [Joachim Breitner] > > Would it be possible to extend the syntax to specify lists of > > packages not by name, but by Maintainer, > > e.g. pkg-haskell-maintainers@l.a.d.o? Bonus points if such an > > assigment is expanded at dinstall time, so that the statement “DM > > 1234 may upload all packages owned by this group” stays up-to-date > > even if after new packages of this team have been added? > > So ... you want to give a DM the ability to NMU any package in the > archive, just by changing the Maintainer field? Obviously the question whether a DM, who is allowed to upload packages on behalf of pkg-haskell-maintainers@l.a.d.o, is allowed to upload package X would depend on the maintainer field of the packages already in Debian, not the one in the package he uploads. Just the way it is at the moment with DMUA: A DM cannot just NMU an arbitrary package just by setting the flag in the new package. But thanks for asking, just in case this was not clear to others. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Changes to Debian Maintainer upload permissions
On Mon, Sep 24, 2012 at 07:33:03PM +0200, Joachim Breitner wrote: > Hi, > > Am Montag, den 24.09.2012, 11:59 -0500 schrieb Peter Samuelson: > > [Joachim Breitner] > > > Would it be possible to extend the syntax to specify lists of > > > packages not by name, but by Maintainer, > > > e.g. pkg-haskell-maintainers@l.a.d.o? Bonus points if such an > > > assigment is expanded at dinstall time, so that the statement "DM > > > 1234 may upload all packages owned by this group" stays up-to-date > > > even if after new packages of this team have been added? > > > > So ... you want to give a DM the ability to NMU any package in the > > archive, just by changing the Maintainer field? > > Obviously the question whether a DM, who is allowed to upload packages > on behalf of pkg-haskell-maintainers@l.a.d.o, is allowed to upload > package X would depend on the maintainer field of the packages already > in Debian, not the one in the package he uploads. Just the way it is at > the moment with DMUA: A DM cannot just NMU an arbitrary package just by > setting the flag in the new package. One way to read your "bonus points" would allow the DM to upload a new package with the maintainer set to pkg-haskell-maintainers. That can also be interpreted as allowing the DM to upload/NMU any package as long as he sets the maintainer field to pkg-haskell-maintainers. But I can also read it as a DD first needs to upload the package with the maintainer field set to pkg-haskell-maintainers, and from then on any DM in that group can upload that package. Kurt -- 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/20120924215301.ga1...@roeckx.be
Bug#389591: RFP: freeswitch -- Modular Media Switching Software Library and Soft-Switch Application.
Package: wnpp Followup-For: Bug #389591 Owner: William King Submitting Intent To Package freeswitch. -- 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/20120924230541.29408.86257.report...@quentusrex-thinkpad.home.quentustech.com
Bug#688723: ITP: erlang-cowboy -- small, fast and modular HTTP server written in Erlang
Package: wnpp Severity: wishlist Owner: Nobuhiro Iwamatsu * Package name: erlang-cowboy Version : 0.6.1 Upstream Author : Loïc Hoguin * URL : https://github.com/extend/cowboy.git * License : ISC license Programming Lang: erlang Description : small, fast and modular HTTP server written in Erlang Cowboy is also a socket acceptor pool, able to accept connections for any kind of TCP protocol. . Cowboy aims to provide the following advantages: . * 'Small' code base. * Damn 'fast'. * 'Modular': transport and protocol handlers are replaceable. * 'Binary HTTP' for greater speed and lower memory usage. * Easy to 'embed' inside another application. * Selectively 'dispatch' requests to handlers, allowing you to send some requests to your embedded code and others to a FastCGI application in PHP or Ruby. * No parameterized module. No process dictionary. 'Clean' Erlang code. -- 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/20120925041028.18831.62288.reportbug@chimagu
