Re: uscan, watch files, and gihub tags
On 12/19/2011 03:15 PM, Thomas Goirand wrote: > I tried to poke with opts="uversionmangle=s/^master\///" to remove "master/" > from the version of upstream git repo, but no luck... > Seems this works for me now: version=3 https://github.com/jonludlam/xen-api/tags /jonludlam/xen-api/tarball/master/(.+) Cheers, Thomas -- 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/4eef27f1.7080...@debian.org
Bug#652658: ITP: clinica -- Simple medical records manager
Package: wnpp Severity: wishlist Owner: Leonardo Robol * Package name: clinica Version : 0.2.1 Upstream Author : Leonardo Robol , Gianmarco Brocchi * URL : http://launchpad.net/clinica-project/ * License : GPLv3 Programming Lang: Vala, Python, C Description : Simple medical records manager Simple tool for the desktop to mantain medical records. It is thought to be easy to use and it's mainly addressed to a single doctor. It features: * Patient management * Doctor management (with associated patients) * Visit creation/editing * Medicine search online (via plugins) * Calendar for events and visits -- 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/20111219165244.29005.3094.reportbug@aranovich
Re: Bug#652432: Acknowledgement (ITP: v3c-dcom -- Baby steps to DCOM)
Maybe put it in "non-free" is a good idea. That's all I really meant... reply to comments... Philip Ashmore wrote: You forgot to mention DCE. Absolutely not, RPC is from unix, and I didn't mean to be all inclusive. But thank you for caring. And I don't believe Microsoft's code for DCE matches their advertisements. DCE is what kills unix and leaves Microsoft stocks rich. That's all you need to know. It's always been that way. one mapping ProdIDs to GUIDS and another mapping GUIDS to plug-in filenames. Product IDs is a new Microsoft monopoly feature right? It's in many past non-ms products. But them centrally controlling who gets PIDs (and to pay for ms), that is "all new". Seems abusable does it not? It will be. > Qt provides a plug-in system but it's system-wide and shared between > programs and users. Am I halucinating? Qt is apple, not microsoft, and Qt was given not taken (see below). ATL? The U.S. government end up paying to fix DCOM and ATL because Microsoft's was bereft of real code? Yes they did. Read up. You admit taking material that brandishes warnings you should not? Maybe put it in "non-free" is a good idea. That's all I really meant. > I could change all the names by adding an "idily" at the end - > CoCreateInstanceExIdily() - > "v3c-dcom provides the same system but inside a file" > "could become part of a boot loader" Wine? Used to require you pay for MS libs. You weren't supposed to steal the libs. And Win3.1 it's no longer a competitive venue. Samba? Different days, when ftp was cool. Those "protocols" were not solely designed or owned by Microsoft. Were they not Intel? Anyhow. Anyhow, no one complained back then. A microsft patented bootloader for linux? I'd say the nvidia blobs are too much. "tainted" If Debian showed concern about use of Java don't you think they'd take DOUBLE the precaution with DCOM ? Sun was friendly, MS is not. "Distributed Component Object Model (DCOM) is a proprietary Microsoft technology for communication among software components distributed across networked computers." (not really true anyhow) Ah! But Microsoft stole the C/C++ compiler (as well as apple's X and many other softwares) to make this "proprietary thing" didn't they? Yes they did. Sites that don't want "tainted kernel blobs" or "tainted submissions" may be concerned with having "baby DCOM" on their company drive. If your a kid you don't care. Of course ! :) It matters not how often Microsoft has been proven to steal. (though I love reminding people). What matters is a 500lb gorilla has in the past been shown harass and to sue and win against linux groups, which debian is. If Debian could only boot with nVidia blob supported in the kernel how long do you think it would be until Microsoft shut it off?" If you think they wouldn't you are reading false history. They would and are trying. -- 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/4eef7ab6.3040...@cox.net
Re: Bug#652432: Acknowledgement (ITP: v3c-dcom -- Baby steps to DCOM)
Take your arguments about Microsoft vs Linux to comp.os.linux.advocacy, please. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20111219180452.ga20...@decadent.org.uk
Bug#652670: RFA: time -- The GNU time program for measuring cpu resource usage
Package: wnpp Severity: normal Description: The GNU time program for measuring cpu resource usage The `time' command runs another program, then displays information about the resources used by that program, collected by the system while the program was running. You can select which information is reported and the format in which it is shown, or have `time' save the information in a file instead of display it on the screen. . The resources that `time' can report on fall into the general categories of time, memory, I/O, and IPC calls. . The GNU version can format the output in arbitrary ways by using a printf-style format string to include various resource measurements. I don't really use it any longer since shells tend to have this built-in. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/874nwwmmkn@qurzaw.varnish-software.com
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Sun, Dec 18, 2011 at 03:37:43AM +0100, Marco d'Itri wrote: > On Dec 17, Roger Leigh wrote: > > > So WRT mounting /usr (and potentially /etc and other filesystems), > > I've pushed patches upstream for util-linux (initramfs mount option) > > and initramfs-tools (generate /etc/fstab from host and mount after > > rootfs). (Merging this and the reply to #652459) I'd just like to clear up a few points about the desired behaviour and requirements for the initramfs. I have some ideas about other ways to achieve this goal. > > 1) Generation of /etc/fstab in the initramfs, including the rootfs > >and all the filesystems desired to be mounted > This is highly suboptimal, because it suddenly makes the initramfs not > generic anymore. > The initramfs should: > - mount / as usual > - look at the rootfs fstab > - mount /usr using the information from the rootfs fstab Regarding keeping the initramfs generic, we already permit hardcoding of the rootfs into the image. This is overridden by root=xxx, but still permitted. I'm not sure I see the difference between hardcoding the root device rather than an fstab entry. There is of course the addition of the mount options, which might be incompatible if the fstype of the rootfs changes. > > 2) In local mountroot(), rather than just mounting the rootfs, loop > >over all mountpoints in /etc/fstab and mount them. > If there is no need to mount file systems other than /usr, why do it? It would permit additional flexibility for initramfs extensions by users. I'm not sure if this is necessarily a good or bad thing. If it's desirable not to permit this, I'm sure we can find a better way. Mounting /usr is obviously the main goal here. Whether or not we migrate stuff to or from /usr, we would still need to have the ability to mount /usr in the initramfs for compatibility with systems with a separately-mounted /usr, in order to privide the guarantee that /usr is available in early boot. Mounting /etc separately is not essential, but this would be a nice-to- have feature for those who wish to encrypt it. > > and other files to the root filesystem. It additionally permits > > mounting of /etc separately, thereby permitting it to be > > encrypted and/or writable while the root filesystem is > > unencrypted and/or read-only. > I do not believe that this is desireable, it is complex and would come > for free anyway by a / -> /usr move. Why would it come for free? You would still have files in places other than /etc on the rootfs. And if we are deprecating a separate /usr, it doesn't solve the problem at all, since everything would be on the rootfs, and then everything would be encrypted. As mentioned earlier in the thread, encrypting /etc is an entirely different problem than mounting /usr separately--a separate mount would IMO be the best solution to this problem, and mounting it in the initramfs is certainly technically possible. Regarding the objections above, which are primarily concerned with the creation of a non-generic initramfs, how does this alternative suggestion sound: - The addition of usr= options analogous to the root= options which permit the bootloader to specify the /usr filesystem to mount. By default would do nothing, but grub could be updated to generate such options on systems with a separate /usr. - We could also add an additional etc= option with the same semantics. I'll be happy to implement this if this sounds more acceptable than the existing approach. It does, I think, address your primary criticisms. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- 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/20111219201051.gb5...@codelibre.net
Bug#652680: ITP: gmtk -- a set of gtk widgets to use with gnome-mplayer, and gecko-mediaplayer
Package: wnpp Severity: wishlist Owner: Brandon Snider * Package name: gmtk Version : 1.0.5b2 Upstream Author : Kevin DeKorte * URL : http://code.google.com/p/gmtk/ * License : (GPL v2) Programming Lang: (C++) Description : a set of gtk widgets to use with gnome-mplayer, and gecko- mediaplayer -- 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/20111219211338.11161.19371.reportbug@localhost6.localdomain6
Re: uscan, watch files, and gihub tags
Am Mon, 19 Dec 2011 20:02:57 +0800 schrieb Thomas Goirand : > On 12/19/2011 03:15 PM, Thomas Goirand wrote: > > I tried to poke with opts="uversionmangle=s/^master\///" to remove > > "master/" from the version of upstream git repo, but no luck... > > > Seems this works for me now: > > version=3 > https://github.com/jonludlam/xen-api/tags > /jonludlam/xen-api/tarball/master/(.+) I assume the "tags as .tar.gz" feature is something special from github. Or could I use also tags from e.g. git.debian.de in a watchfile? Kind Regards, Andreas -- Andreas Rütten andreasruet...@gmx.de 4096R: 0x6C9DFFB2 / 8394 99DA 59BD BCE2 3FC8 3A9E 6633 0089 6C9D FFB2 signature.asc Description: PGP signature
Re: Heads-up: Boost defaults changing from 1.46 to 1.48
On Sat, Dec 10, 2011 at 21:23:49 -0600, Steve M. Robbins wrote: > Hi, > > Boost 1.48 was uploaded to sid about 9 days ago so it should > transition to "testing" in the next day or so. > > My plan is to update the default boost version to 1.48 immediately > following this transition. > > I'd appreciate feedback on any build failures with 1.48 for > boost-using packages. > I heard of at least two failures in the last couple of hours: libreoffice (#652681), and wesnoth (#652677). As such, I'd appreciate if you could: - revert boost-defaults to 1.46 for the time being - test-build at least the most prominent reverse deps against 1.48 before bumping it again - contact debian-release before that bump, so we can coordinate a timing that doesn't suck with regards to other ongoing transitions. Thanks in advance, Julien signature.asc Description: Digital signature
Bug#652685: ITP: libgmtk0 -- a set of gtk widgets to use with gnome-mplayer.
Package: wnpp Severity: wishlist Owner: Brandon Snider * Package name: libgmtk0 Version : 1.0.5b2 Upstream Author : Kevin DeKorte * URL : http://code.google.com/p/gmtk/ * License : (GPL v2) Programming Lang: (C++) Description : a set of gtk widgets to use with gnome-mplayer. -- 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/20111219222041.12104.35830.reportbug@localhost6.localdomain6
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Mon, 19 Dec 2011, Roger Leigh wrote: [..] Regarding the objections above, which are primarily concerned with the creation of a non-generic initramfs, how does this alternative suggestion sound: - The addition of usr= options analogous to the root= options which permit the bootloader to specify the /usr filesystem to mount. By default would do nothing, but grub could be updated to generate such options on systems with a separate /usr. Nonsense, should come from /etc/fstab. - We could also add an additional etc= option with the same semantics. Something like this would be necessary to support separately mounted /etc, but I see that as a completely separate discussion. Also note that you would need to patch _all_ existing bootloaders for _all_ arches to automatically include that option in any generated config file (namely by parsing the one&only main config location which is /etc/fstab or possibly /etc/fstab.d). Related issue: how to specify desired fsck options (such as FSCKFIX) for / and /etc, while /etc is not yet mounted. Next, you'll be arguing that /etc/fstab should be moved to /. And /etc/default/rcS too. Oh, and now that I'm at it, do we also have initramfs support for bootlogd? and keyboard-setup? and hwclockfirst? (Last two could be required for proper fsck on various arches.) Plus their config files. Best regards, Anne Bezemer -- 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/pine.lnx.4.64.1112192352230.14...@wormhole.robuust.nl
Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Tue, Dec 20, 2011 at 12:11:39AM +0100, J.A. Bezemer wrote: > > On Mon, 19 Dec 2011, Roger Leigh wrote: > > [..] > > > >Regarding the objections above, which are primarily concerned with the > >creation of a non-generic initramfs, how does this alternative suggestion > >sound: > > > >- The addition of usr= options analogous to the root= options which > > permit the bootloader to specify the /usr filesystem to mount. By > > default would do nothing, but grub could be updated to generate > > such options on systems with a separate /usr. > > Nonsense, should come from /etc/fstab. Of course. In case it wasn't implicit from the above, this information would necessarily need to be taken from /etc/fstab by update-grub or its equivalent for other bootloaders when generating grub.cfg (or its equivalent). They presumably already do the same for / (or look at the current rootfs), so it's simply copying existing practice for the rootfs. > >- We could also add an additional etc= option with the same semantics. > > Something like this would be necessary to support separately mounted > /etc, but I see that as a completely separate discussion. Also note > that you would need to patch _all_ existing bootloaders for _all_ > arches to automatically include that option in any generated config > file (namely by parsing the one&only main config location which is > /etc/fstab or possibly /etc/fstab.d). Agreed. In order to guarantee that /usr is always available, we will need to support this for all bootloaders. As an aside, this support would only be required for situations where a separate /usr is used /and/ stuff on /usr is required for early boot. Support for minor tools/platforms might not be required since the other solution is simple: keep /usr on the rootfs if you need those guarantees. Either way, having support in the initramfs is a prerequisite for updating the bootloaders. > Related issue: how to specify desired fsck options (such as FSCKFIX) > for / and /etc, while /etc is not yet mounted. I would presume that this would be unchanged. By the time fsck is run, you'll have / and additionally /etc and/or /usr mounted, so keeping it on /etc will be just fine. > Next, you'll be arguing that /etc/fstab should be moved to /. And > /etc/default/rcS too. No. I'm simply proposing a way to make additional guarantees about the availability of /usr in early boot. Nothing else is changed except for when /usr is mounted. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- 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/20111220001514.gd5...@codelibre.net
Re: uscan, watch files, and gihub tags
On Tue, Dec 20, 2011 at 5:24 AM, Andreas Rütten wrote: > I assume the "tags as .tar.gz" feature is something special from > github. Or could I use also tags from e.g. git.debian.de in a watchfile? git.debian.de doesn't exist so that would not work. As for non-github sites, gitweb doesn't appear to support this, but cgit does: http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/refs/tags -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6gp-ehpz7mwqbwwlvxtjnpaunc06jah0ojattp7bzx...@mail.gmail.com
Bug#652694: ITP: libgmtk0-dbg -- Debugging symbols for libgmtk0
Package: wnpp Severity: wishlist Owner: Brandon Snider * Package name: libgmtk0-dbg Version : 1.0.5b2 Upstream Author : Kevin DeKorte * URL : http://code.google.com/p/gmtk/ * License : (GPL v2) Programming Lang: (C++) Description : Debugging symbols for libgmtk0 -- 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/20111220011906.13101.92814.reportbug@localhost6.localdomain6
Bug#652695: ITP: libgmlib0 -- libgmlib0 - gnome-mplayer toolkit
Package: wnpp Severity: wishlist Owner: Brandon Snider * Package name: libgmlib0 Version : 1.0.5b2 Upstream Author : Kevin DeKorte * URL : http://code.google.com/p/gmtk/ * License : (GPL v2) Programming Lang: (C++) Description : libgmlib0 - gnome-mplayer toolkit. -- 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/20111220012159.13186.71848.reportbug@localhost6.localdomain6
Bug#652696: ITP: libgmlib0-dbg -- Debugging symbols for libgmlib0
Package: wnpp Severity: wishlist Owner: Brandon Snider * Package name: libgmlib0-dbg Version : 1.0.5b2 Upstream Author : Kevin DeKorte * URL : http://code.google.com/p/gmtk/ * License : (GPL v2) Programming Lang: (C++) Description : Debugging symbols for libgmlib0 -- 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/20111220012434.13232.92093.reportbug@localhost6.localdomain6
Bug#652697: ITP: libgmtk-dev -- libgmtk0 development headers
Package: wnpp Severity: wishlist Owner: Brandon Snider * Package name: libgmtk-dev Version : 1.0.5b2 Upstream Author : Kevin DeKorte * URL : http://code.google.com/p/gmtk/ * License : (GPL v2) Programming Lang: (C++) Description : libgmtk0 development headers -- 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/20111220012809.13268.23803.reportbug@localhost6.localdomain6
Bug#652698: ITP: libgmlib-dev -- libgmlib development headers
Package: wnpp Severity: wishlist Owner: Brandon Snider * Package name: libgmlib-dev Version : 1.0.5b2 Upstream Author : Kevin DeKorte * URL : http://code.google.com/p/gmtk/ * License : (GPL v2) Programming Lang: (C++) Description : libgmlib development headers -- 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/20111220013037.13309.11787.reportbug@localhost6.localdomain6
Re: Bug#652698: ITP: libgmlib-dev -- libgmlib development headers
On 20.12.2011 02:30, Brandon Snider wrote: > Package: wnpp > Severity: wishlist > Owner: Brandon Snider > > > * Package name: libgmlib-dev > Version : 1.0.5b2 > Upstream Author : Kevin DeKorte > * URL : http://code.google.com/p/gmtk/ > * License : (GPL v2) > Programming Lang: (C++) > Description : libgmlib development headers Please file a single bug for the source package, not each binary package. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
