Re: Bits from the Security Team (for those that care about bits)
On 24/01/11 02:52, Paul Wise wrote: * README.test An alternative is to just provide *-test Debian packages. If the package exists then building it is the same as running a test of the packages it requires to be installed - maybe just the "*" package, but it could also be an integration test. I've got some packages in SourceForge that allow you to - build from GIT version control - install to a sandbox - do a "make distcheck" and build the Debian package from the tar ball. - check a particular branch with "make git branch=X check" The build goodies are in the v3c project http://www.sourceforge.net/projects/v3c All the other projects inherit these features from v3c. I hope this gives you some food for thought. Philip
Where does the update-initramfs hook get the kernel name from?
Hi there. I've got a multi-boot system for which I maintain my own (Grub2) grub.cfg. I've got Debian Lenny, Debian Squeeze and Ubuntu partitions inside an encrypted LVM2 logical volume, a booting nicely. I just have to watch out if one of them tries to "update" grub.cfg, completely trashing it. Anyway, this puts me under the radar regarding submitting a bug report, so here I am, writing this. I just did an apt-get upgrade in Squeeze and one of the deferred hooks failed: Processing triggers for initramfs-tools ... /boot/initrd.img-26.32.5-amd64.squeeze does not exist. Cannot update. The initrd image I have for Squeeze is "2.6.32-5-amd64.squeeze" and the only way I can update it is to use update-initramfs -t -u -v -k 2.6.32-5-amd64 and then rename it. The grub.cfg entry for Squeeze is linux /vmlinuz-2.6.32-5-amd64 root=/dev/mapper/VgCompaq-squeeze resume=/dev/mapper/VgCompaq-swap ro quiet vga=0x317 cryptopts=target=sda4_crypt,source=UUID=41d45178-c0d4-4d8f-a190-1c56b6328318,key=none,rootdev,lvm=VgCompaq-squeeze initrd /initrd.img-2.6.32-5-amd64.squeeze Where does the update-initramfs hook get the kernel name from? Philip
Re: Where does the update-initramfs hook get the kernel name from?
On 27/01/11 01:09, Ben Hutchings wrote: On Wed, 2011-01-26 at 19:50 +, Philip Ashmore wrote: [...] I just did an apt-get upgrade in Squeeze and one of the deferred hooks failed: Processing triggers for initramfs-tools ... /boot/initrd.img-26.32.5-amd64.squeeze does not exist. Cannot update. Where does the update-initramfs hook get the kernel name from? See<http://kernel-handbook.alioth.debian.org/ch-update-hooks.html>. Ben. According to the docs you mentioned, the script gets supplied the kernel version from "uname -r". The output I get is "2.6.32-5-amd64", not "26.32.5-amd64.squeeze" as you see above, so the documentation must be wrong. Philip -- 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/4d417c1e.4090...@philipashmore.com
Re: Ideas for object-based git-like storage on Linux
On 06/02/11 23:40, Roger Leigh wrote: Hi folks, There are lots of Debian people out there using git, and some of them have expressed interest over the years in having the ability to use git as a filesystem in its own right (#477942 is an example of one in a package I maintain). I've finally got down to it and written all my thoughts on the topic down in a mostly-organised form, which you can find at http://www.codelibre.net/~rleigh/hashlink.pdf This paper looks at the concept of object-based storage, and the creation of "hashlinks", essentially symlinks which use hashes rather than pathnames to refer to a file. Currently a complete draft, which could probably use a little more editing. Any thoughts or comments welcome; I'm just putting it out there because I have no time to actually implement this at the moment, but it's an interesting topic, and one which could potentially revolutionise the way we use filesystems if done properly. I started writing to organise my thinking on the matter, and I think that through that I've actually got a basically implementable robust design that would actually work very efficiently. [For the curious, I thought I'd forego XeLaTeX and inkscape, and write this in troff (-ms) and xfig/PIC. It's not too shabby for a nearly 40 year old system, though I am not half as proficient in it as I am with LaTeX.] Regards, Roger You could take a look athttp://sourceforge.net/projects/treedb/ which implements an object data store right now. It doesn't have transactions or a security model yet but it does support 64 bit memory maps. It's stable but not mature yet, and has plenty of tests/demos to get you started, in C and C++. I'm working on v3c-schema now which will allow you to specify the object schema directly instead of through C structure definitions + code. This will for example allow you to do speed versus resource usage analysis more easily. Comments + suggestions welcome. Philip
Debian documentation permalinks
Hi there. First, here's what I'm talking about - http://en.wikipedia.org/wiki/Permalink Unfortunately Wikipedia doesn't offer permalinks itself, so hopefully the above link won't "rot". This was initially in reference to the recent spat of comments/opinions to "Re: Moving /tmp to tmpfs makes it useful". It's sometimes amusing to watch as helpful enthusiasts try to unravel a problem. I nearly deleted the entire thread without giving it a moments thought - I get a lot of message list email. What I noticed by its absence was that no-one linked to official Debian policy detailing the choices made and their justification. Then it struck me that if such a document existed, it would be subject to change as Debian policy itself evolved, making any old links nonsensical or misleading. So what I'm requesting is that Debian documentation be "permalink friendly" i.e. that Debian documentation pages provide permalinks. It would be even better if they also mentioned the version(s) of Debian they apply to. This could be done using the "wayback machine" - here's an interesting example. http://wayback.archive.org/web/*/http://en.wikipedia.org/wiki/Wikipedia:Using_the_Wayback_Machine From this it's possible to specify a permalink URL even to sites without permalinks, but note that a version being referenced might be missed or duplicated, so this isn't an ideal solution. Regards, Philip Ashmore -- 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/4fc039da.5090...@philipashmore.com
Exported (ba)sh functions in the environment
Hi there. I recently had cause to search for an environment variable to see if it was being set. As a result I noticed that the environment has become a bit of a dumping ground for installed programs where configuration files would have been a cleaner option. Looking for an override in the environment is of course a good idea, but setting default values in the environment that could be 1. hard coded in the programs as defaults 2. stored in a configuration file 3. sourced from a configuration script is a bit sloppy. On my machine running "set > set.txt && ls -lsa set.txt" reveals that my environment contains 225517 of "stuff" - some of it is even being taken up by exported function definitions! That's 225517 bytes that needs to be copied every time a script runs. Regards, Philip Ashmore -- 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/4fc044da.90...@philipashmore.com
Re: Exported (ba)sh functions in the environment
On 26/05/12 03:50, Philip Ashmore wrote: That's 225517 bytes that needs to be copied every time a script runs. Yeah that should read "every time a script or program runs." Philip -- 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/4fc0472e.70...@philipashmore.com
Re: Exported (ba)sh functions in the environment
On 26/05/12 03:59, Philip Ashmore wrote:
> On 26/05/12 03:50, Philip Ashmore wrote:
>>
>> That's 225517 bytes that needs to be copied every time a script runs.
>
> Yeah that should read "every time a script or program runs."
>
> Philip
>
Sorry Ben, our emails collided.
According to "man sh" (which links to the dash man page)
set [{ -options | +options | -- }] arg ...
The set command performs three different functions.
With no arguments, it lists the values of all shell variables.
So are these copied every time a script runs?
Philip
--
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/4fc0495d.6070...@philipashmore.com
Re: Exported (ba)sh functions in the environment
On 26/05/12 04:14, Russ Allbery wrote:
> I'm curious why even your set of shell variables is so large, though. My
> environment is only 1699 bytes on a system I logged onto via ssh, and
1998
> on my desktop (running Xfce). One of the biggest chunks of that is
> LS_COLORS.
>
Here's where I wish I was a shell script guru:
for var in `cat set.txt`; do
{ if in env discard }
done
{ sort offenders by decending size }
Here's a summary of the ones that caught my eye. Sorry if I missed
anyone out!
_xspecs
__expand_tilde_by_ref()
__gdbus()
__get_cword_at_cursor_by_ref()
__git_complete_remote_or_refspec()
( lots more git functions )
__grub_dir()
_a2dismod()
_apt_file()
_debconf_show()
_dkms()
_hg()
_inkscape()
_insserv()
_module_assistant()
_openvpn()
_pbuilder()
_stg()
_svn()
_update_initramfs()
_valgrind()
_xinetd_services()
Regards,
Philip
--
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/4fc04e32.3010...@philipashmore.com
Re: Exported (ba)sh functions in the environment
On 26/05/12 04:34, Russ Allbery wrote:
> Philip Ashmore writes:
>
>> Here's where I wish I was a shell script guru:
>>for var in `cat set.txt`; do
>> { if in env discard }
>>done
>>{ sort offenders by decending size }
>> Here's a summary of the ones that caught my eye. Sorry if I missed
>> anyone out!
> Oh. This is smelling like artifacts of bash-completion; perhaps set is
> dumping your completion settings. I'm pretty sure those are not copied
> into subshells and are only loaded in interactive shells.
>
In my original email I ran "set > set.txt && ls -lsa set.txt".
Putting the same into a script:
#!/bin/sh
set > set.txt && ls -lsa set.txt
...got me 2353 bytes - I'll be a donkeys ass!
It looks like the fact that I typed it made it interactive, even though it
didn't require/allow any interaction.
Thanks,
Philip
--
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/4fc051da.6060...@philipashmore.com
Re: Debian documentation permalinks
On 05/26/2012 06:53 AM, Jonathan Callen wrote: > On 05/25/2012 10:03 PM, Philip Ashmore wrote: >> Hi there. >> >> First, here's what I'm talking about - >> http://en.wikipedia.org/wiki/Permalink >> Unfortunately Wikipedia doesn't offer permalinks itself, so >> hopefully the above link won't "rot". > > And here's the permalink to the above article, as it was when the > preceding post was made: > http://en.wikipedia.org/w/index.php?title=Permalink&oldid=483438630 > Or, if you prefer links that don't indicate where they're really going: > http://en.wikipedia.org/w/index.php?oldid=483438630 I'm happy and sad with this. Happy that Wikipedia provides permalink support. Sad that it didn't document it in its article about permalinks. Is there documentation on this feature somewhere? Permalinks, along with the fact that MediaWiki is free GPLv2, makes a compelling argument for moving Debian documentation to MediaWiki. Regards, Philip Ashmore -- 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/4fc12a6c.1010...@philipashmore.com
Re: Exported (ba)sh functions in the environment
On 28/05/12 19:17, Peter Samuelson wrote: [Philip Ashmore] On my machine running "set> set.txt&& ls -lsa set.txt" reveals that my environment contains 225517 of "stuff" - some of it is even being taken up by exported function definitions! As mentioned earlier, 'set' is not reporting much more than the environment exported to external processes and scripts. Observe: $ set | wc -c 189097 That's my interactive bash session, including a huge chunk from bash-completion. But... $ env | wc -c 792 That's all that actually gets exported to external processes, including shell scripts. $ sh -c set | wc -c 908 $ sh -i -c set | wc -c 908 That's dash, including the 792 bytes of exported environment noted earlier. Interactive mode (-i) seems to make no difference. $ bash -c set | wc -c 1371 $ bash -i -c set | wc -c 189101 ...and that's bash, which does a bit more at startup than dash. Interactive mode (-i) enables bash-completion and other stuff. Big difference! But probably no shell scripts ever run in interactive mode. Plus "set" is built-in and so doesn't run in a sub-shell, while "env" is a program so it is run in a sub-shell, so non-exported variables aren't available. I guess I'm confused as to why bash completion needs these. Philip -- 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/4fc3c66e.1040...@philipashmore.com
Re: Debian documentation permalinks
On 30/05/12 12:29, Bernd Zeimetz wrote: On 05/26/2012 09:09 PM, Philip Ashmore wrote: On 05/26/2012 06:53 AM, Jonathan Callen wrote: On 05/25/2012 10:03 PM, Philip Ashmore wrote: Hi there. First, here's what I'm talking about - http://en.wikipedia.org/wiki/Permalink Unfortunately Wikipedia doesn't offer permalinks itself, so hopefully the above link won't "rot". And here's the permalink to the above article, as it was when the preceding post was made: http://en.wikipedia.org/w/index.php?title=Permalink&oldid=483438630 Or, if you prefer links that don't indicate where they're really going: http://en.wikipedia.org/w/index.php?oldid=483438630 I'm happy and sad with this. Happy that Wikipedia provides permalink support. Sad that it didn't document it in its article about permalinks. Is there documentation on this feature somewhere? Permalinks, along with the fact that MediaWiki is free GPLv2, makes a compelling argument for moving Debian documentation to MediaWiki. Which documentation are you talking about? Most official documentation should have a fixed URL. If you are talking about the wiki: retrieving a fixed version from moinmoin is the same as in mediawiki. So I can't see a useful argument here, only FUD trying to talk people into using Mediawiki. Hi there and thanks for your feedback. I'm talking about the fact that Debian has mail archives that may include links to documentation that has changed since the mail was written, possibly rendering the mail thread misleading or nonsensical. Any documentation system that can provide a means to refer to a specific version (permalinks) would be better than what's there now. This would 1. prevent link rot (moved documentation) 2. allow someone who finds an archived email that refers to Debian documentation to see the version being referred to, not the current version In summary would be useful if Debian documentation included the names of the versions it referred to, a permalink to the version you're reading, and some way of indicating if an updated version is available. I merely suggested MediaWiki as Wikipedia uses it. From past experience I know that if you're documenting say a class library then it helps if you use the same documentation style as the toolkit it's based on, so you (and your readers) can focus on the contents and not the documentation style itself. By the way, this extends to man/info pages too, but as they're versioned, you can refer to a specific version through the package version. I still haven't figured out how to downgrade my installed packages to a particular update date, i.e. "revert the upgrades I just ran, I had Sid enabled by mistake". This all goes to providing something that can be referred to after the fact. Regards, Philip Ashmore -- 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/4fc61088.3000...@philipashmore.com
Re: Debian documentation permalinks
On 30/05/12 22:42, Karl Goetz wrote: On Wed, 30 May 2012 13:20:24 +0100 Philip Ashmore wrote: On 30/05/12 12:29, Bernd Zeimetz wrote: On 05/26/2012 09:09 PM, Philip Ashmore wrote: On 05/26/2012 06:53 AM, Jonathan Callen wrote: On 05/25/2012 10:03 PM, Philip Ashmore wrote: Hi there. First, here's what I'm talking about - http://en.wikipedia.org/wiki/Permalink Unfortunately Wikipedia doesn't offer permalinks itself, so hopefully the above link won't "rot". And here's the permalink to the above article, as it was when the preceding post was made: http://en.wikipedia.org/w/index.php?title=Permalink&oldid=483438630 Or, if you prefer links that don't indicate where they're really going: http://en.wikipedia.org/w/index.php?oldid=483438630 I'm happy and sad with this. Happy that Wikipedia provides permalink support. Sad that it didn't document it in its article about permalinks. Is there documentation on this feature somewhere? Permalinks, along with the fact that MediaWiki is free GPLv2, makes a compelling argument for moving Debian documentation to MediaWiki. Which documentation are you talking about? Most official documentation should have a fixed URL. If you are talking about the wiki: retrieving a fixed version from moinmoin is the same as in mediawiki. So I can't see a useful argument here, only FUD trying to talk people into using Mediawiki. Hi there and thanks for your feedback. I'm talking about the fact that Debian has mail archives that may include links to documentation that has changed since the mail was written, possibly rendering the mail thread misleading or nonsensical. Any documentation system that can provide a means to refer to a specific version (permalinks) would be better than what's there now. Could you give examples of things lacking permalinks? thanks, kk http://www.debian.org/ Philip -- 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/4fc6a645.7010...@philipashmore.com
Re: Debian documentation permalinks
On 30/05/12 22:42, Karl Goetz wrote: > On Wed, 30 May 2012 13:20:24 +0100 > Philip Ashmore wrote: > >> On 30/05/12 12:29, Bernd Zeimetz wrote: >>> On 05/26/2012 09:09 PM, Philip Ashmore wrote: >>>> On 05/26/2012 06:53 AM, Jonathan Callen wrote: >>>>> On 05/25/2012 10:03 PM, Philip Ashmore wrote: >>>>>> Hi there. >>>>>> >>>>>> First, here's what I'm talking about - >>>>>> http://en.wikipedia.org/wiki/Permalink >>>>>> Unfortunately Wikipedia doesn't offer permalinks itself, so >>>>>> hopefully the above link won't "rot". >>>>> >>>>> And here's the permalink to the above article, as it was when the >>>>> preceding post was made: >>>>> http://en.wikipedia.org/w/index.php?title=Permalink&oldid=483438630 >>>>> Or, if you prefer links that don't indicate where they're really >>>>> going: http://en.wikipedia.org/w/index.php?oldid=483438630 >>>> >>>> I'm happy and sad with this. >>>> Happy that Wikipedia provides permalink support. >>>> Sad that it didn't document it in its article about permalinks. >>>> >>>> Is there documentation on this feature somewhere? >>>> >>>> Permalinks, along with the fact that MediaWiki is free GPLv2, >>>> makes a compelling argument for moving Debian documentation to >>>> MediaWiki. >>> >>> Which documentation are you talking about? Most official >>> documentation should have a fixed URL. >>> >>> If you are talking about the wiki: retrieving a fixed version from >>> moinmoin is the same as in mediawiki. >>> >>> So I can't see a useful argument here, only FUD trying to talk >>> people into using Mediawiki. >>> >> Hi there and thanks for your feedback. >> >> I'm talking about the fact that Debian has mail archives that may >> include links to documentation that has changed since the mail was >> written, possibly rendering the mail thread misleading or nonsensical. >> >> Any documentation system that can provide a means to refer to a >> specific version (permalinks) would be better than what's there now. > > Could you give examples of things lacking permalinks? > thanks, > kk > http://wiki.debian.org/BridgeNetworkConnections It doesn't mention which version(s) of Debian it applys to. It doesn't provide links to versions that apply to previous or testing versions of Debian. I also couldn't find a permalink on the page. Oh and I couldn't get it to bridge from my wifi to the ethernet port. Does anyone else out there wish there was an app that (graphically) simulated packet flow/filtering based on test configurations? This page is definitely not noob-friendly, or is that a feature? Philip -- 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/4fc8bf4e.4070...@philipashmore.com
Re: Debian documentation permalinks
On 01/06/12 14:53, Ben Hutchings wrote: On Fri, 2012-06-01 at 14:10 +0100, Philip Ashmore wrote: On 30/05/12 22:42, Karl Goetz wrote: > On Wed, 30 May 2012 13:20:24 +0100 > Philip Ashmore wrote: > Could you give examples of things lacking permalinks? > thanks, > kk > http://wiki.debian.org/BridgeNetworkConnections It doesn't mention which version(s) of Debian it applys to. It doesn't provide links to versions that apply to previous or testing versions of Debian. It's a wiki, so how would we ensure that? By mentioning which version(s) of Debian it applies to. I also couldn't find a permalink on the page. Oh and I couldn't get it to bridge from my wifi to the ethernet port. Not particularly surprising; that recipe is a nasty hack. Routing makes more sense. Does anyone else out there wish there was an app that (graphically) simulated packet flow/filtering based on test configurations? This page is definitely not noob-friendly, or is that a feature? It's a wiki, so how would we ensure that? Ok, I guess I'm being off topic here - I'm talking about a Debian package that can 1. Accept the same configuration files/syntax as the "real" services do. 2. Allows the user to describe some hypothetical networking set-up, possibly involving multiple networking interfaces on multiple machines. Also, network manager interactions should be visible too. 3. Can identify the kinds of packets that each machine would be expected to send / accept based on role options (DHCP, wifi, Gateway, non-configurable) configurable with dialogs. 4. Can display a simulation of the packets being routed/forwarded/rejected based on the configuration 5. Can generate scripts to be run on one or more of the target machines (that run Debian?) to verify a particular configuration deployment among the target machines. Ben. Philip -- 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/4fc8cfed.4090...@philipashmore.com
Re: Debian documentation permalinks
On 04/06/12 09:53, Bernd Zeimetz wrote: On 06/01/2012 03:53 PM, Ben Hutchings wrote: [...] It's a wiki, so how would we ensure that? I also couldn't find a permalink on the page. Read the moinmoin documentation? http://wiki.debian.org/BridgeNetworkConnections?action=recall&rev=19 I see two options. Either or both are better than it is now. 1. change "immutable page" to "permalink" which is a link to this version. 2. Add a hyperlinks to each section allowing the viewer to grab a link to the current version or the version they're reading. Option 2 has the advantage that you only see the links if you hover the mouse over the heading. If these were standardised then I wouldn't have to read the documentation for the web software used - I could focus on the content. Philip Oh and I couldn't get it to bridge from my wifi to the ethernet port. [...] -- 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/4fcc9df8.8050...@philipashmore.com
Re: Report from the Bug Squashing Party in Salzburg
On 19/06/12 23:26, Bernd Zeimetz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 For those who do not read Planet Debian, here is the report from the Debian BSP in Salzburg (markdown/ikiwiki source, sorry for not re-formatting it :)) Participation and Results - --- - From June 15-17th we held a Debian BugSquashingParty in Salzburg, hosted and sponsored by [conova communications GmbH](http://www.conova.com/). It was a fun and busy weekend, with 15-17 people from 5 coutries being around, mainly working on RC bugs in Testing/Unstable. Gerfried Fuchs (rhonda) also worked on triaging the impact of RC bugs on the version in Squeeze, while Peter Palfrader (weasel) took care of Tor related things and Debian sysadmin work, including starting on the new bugs and udd hosts. Phillip Hug (hug) worked on the debian.ch infrastructure. Together with Miroslav Suchý from Red Hat Bernd Zeimetz (bzed) worked on the packaging of the necessary libraries and daemons to add (basic) Spacewalk client support to Debian. As soon as the packages passed NEW and [#677871](http://bugs.debian.org/677871) was applied (thanks to the APT guys for working on that already), managing Debian clients with Spacewalk should work out of the box. Of course we also had a little keysigning party :) Statistics - --- - - about 68 bugs in unstable/testing were triaged/patched/fixed or at least pinged - - 54 bugs were tagged to show if they affect Squeeze, several other bugs were pinged to retrieve necessary information or to trigger an update in the next stable pointrelease. - - 5 packages were introduced into Debian (still in NEW, though) - the Spacewalk client related packages and libapache2-mod-auth-memcookie. Accomodation - - Thanks to Debian funds we were able to provide accomodation for four participants in the JUFA youth hostel in Salzburg. We had paid in advance for eight, but changing to rooms with a higher category for only 4 people would have been equally or more expensive. Press/Media coverage - ---_- Additionally to being mentioned in the calendars on ProLinux and similar pages, we had some press coverage by the local newspaper and online magazines: - - [Scan of Salzburger Woche / Stadt Nachrichten](http://www.conova.com/fileadmin/user_upload/dl.php?file=files/Presse_Debian_Bug_Squashing_Party_Stadt_Nachrichten.pdf) - - [article on the Salzburger Nachrichten website](http://search.salzburg.com/news/artikel.html?uri=http%3A%2F%2Fsearch.salzburg.com%2Fnews%2Fresource%2Fsn%2Fnews%2Fst152700_15.06.2012_41-40204916) - - [meinbezirk.at](http://regionaut.meinbezirk.at/salzburg-stadt/leute/debian-bug-squashing-party-erstmals-in-salzburg-d194324.html/action/lesen/1/recommend/1/) - - [Salzburg Cityguide - Photogallery](http://www.salzburg-cityguide.at/de/partyzone/detail/debian-bug-squashing-party---conova_102492) Fun facts - - We consumed 2kg of Leberkas, a big plate of "Buchteln mit Vanillesosse", about 16000cm^2 of Pizza, about 80 litres of coke, juice, beer and whine and I guess we drank at least the same amount of water. We had coffee made of 1.5kg coffee beans and managed to empty the (formerly well filled) icemaker in the fridge. Also we had successful training sessions of a standard Debconf game (rules won't be explained here obviously). Maybe we even successfully spread the game to the employees of a commercial linux distribution ;) - -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIbBAEBCAAGBQJP4PysAAoJEOs2Fxpv+UNfedIP+LpbOOiIgbSOR95L+78kxzM1 AXr/eDEVv3uGpIslaQ2PIUaDGFiB0ecBxnloajrXBKoY46X/rLORQMBb6yyN/jHD L3HzZWU8tZyyvObFiedMsi/OwW/qALT/BXi3MAIIR8+Y8pMKUWCt0jWjCKr13QOC F/0ZFA47R7uFO2iQOgw6bkQp2NIBeh7PUX3TV/sK0AUwWt3e7LeVF4rU5nzDyzCu gACn4+jG7XwdTERT/3YMmMwhKOl7HLUBGMWNX6/JfFhj0xDxc9SXckpiZg+bk+xi Vp0yjwEkNd63GPk5032hqBa60yYlqJaJot1DVKKHbQSm1xPyXTn7NaLWvSxJCb5y 7NwyCGkQGnWGjQvxvy+22OsuYgWAc6GknQuMOCwX6l6bDIfbM013uXPmELi3m6Bj 5Y231jxa4HbZYuk5ZKSx1H7ktNE49dxyTHxa0T0pK97PDb0EpM4Uwp9iPkc1r5Bg feOee7QBotQEg/DFuRGNqylVsnWwxqtL+mmRIGPrfhvI3/41gt/Tm+yvm6bpPUGq DW68QTqhQBwLzcdMO4vYpAlFsR9Ggk1GQxF3hv7EyEPVeg3yHrpKVNocJbti0EIg wl6uSxlnVOIW2M1U5Ezo45yqy8tjx4FDp0QMgUpt0OwKxWH3Cwh86udQUOTRYPbf yHMWXVt2ordA5q7jCbc= =SpWN -END PGP SIGNATURE- Sounds like it was a lot of fun! Has anyone thought about starting a hangout at Google+? It would be a lot more convenient (especially for newbies) than Internet Relay Chat (IRC), something I never took to. Regards, Philip Ashmore -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive
Re: Report from the Bug Squashing Party in Salzburg
On 20/06/12 15:48, The Fungi wrote: On 2012-06-20 13:34:22 +0100 (+0100), Philip Ashmore wrote: [...] Has anyone thought about starting a hangout at Google+? [...] Sounds intruiging. Is there a Debian package in main so I can run a Google+ server easily? Setting up my own IRC servers is already pretty trivial, but if all the cool kids are installing Google+ servers these days... No, I meant using Googles Google+ as an alternative to setting a location, arranging accommodation, setting aside X number of days for the trip, getting to and from there... Some bugs triaging may require participants to reboot their PC (not everyone has laptops) so a bug squashing hangout would allow members to come and go. The thought of setting up personal (or even Debian-wide) Google+ servers never occurred to me. Regards, Philip Ashmore -- 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/4fe253b5.5010...@philipashmore.com
Re: Report from the Bug Squashing Party in Salzburg
On 21/06/12 13:10, Bernd Zeimetz wrote: On 06/21/2012 04:53 AM, Paul Wise wrote: On Thu, Jun 21, 2012 at 6:50 AM, Philip Ashmore wrote: The thought of setting up personal (or even Debian-wide) Google+ servers never occurred to me. I think you might have missed the point. Google+ is a proprietary SaaS used for selling your eyeballs to advertisers. It is unlikely that Google will ever let it be installed on other servers, let alone release the source code under a free license. Debian should avoid using such SaaS offerings and promote the free alternatives that exist and the movements that support them, some links: http://autonomo.us/ http://wiki.debian.org/FreedomBox http://mako.cc/writing/hill-free_tools.html Seriously, thats all fine stuff, but if having a hangout with 10+ people on google+ helps Debian to get the bugs squashed, I can't see a reason why we should not use it. It is much more pain free to use than any other solution we have in Debian. Two points, two cents each: 1. I see plenty of @gmail.com email addresses belonging to people in Debian mailing lists. I guess they have that ad problem. 2. The "perfect storm" of people at such geographically distant locations that a meetup anywhere isn't an option. Some will spend a lot more on travel than others. Philip -- 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/4fe31a33.1000...@philipashmore.com
Re: Report from the Bug Squashing Party in Salzburg
On 22/06/12 07:12, Thomas Goirand wrote: On 06/21/2012 10:39 PM, Jon Dowland wrote: Fair enough - but let's not lob hand grenades at people who might find it useful. Let them get on with it if they want to. Sorry, but it's fair enough to "lob hand grenades" at people suggesting non open source solutions, useful or not. Feel free to get on them if you wish, but please do not suggest it inside Debian. Thomas Huh. So physically travelling to a potentially distant location for a bug squash is the Debian way? Anyway, I'd like to see something like http://www.bigbluebutton.org/ but with multiple participants, be it Google+ or something else that can do that. I know that one useful aspect of IRC is the ability to archive and review the session, so it should have that feature too. I must admit I have something in mind for the future that will fit this requirement, so anything out there that comes close is of interest to me. Regards, Philip Ashmore -- 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/4fe4a49d.5040...@philipashmore.com
Re: Report from the Bug Squashing Party in Salzburg
On 22/06/12 23:04, Holger Levsen wrote: Hi, On Freitag, 22. Juni 2012, Neil Williams wrote: Bug squashing parties are *social* events where bugs happen to get fixed. soon there will be a 14 day BSP, in Central America, in Managua :-D You'll be able to participate remotly, mostly via IRC ;) cheers, Holger I never said I didn't enjoy a social event - don't get me wrong. But for those who can't make it, what about http://www.bigbluebutton.org/ or http://plus.google.com/ too? It could even hook up several such events around the globe! Philip -- 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/4fe4f6ec.4000...@philipashmore.com
Re: Report from the Bug Squashing Party in Salzburg
On 23/06/12 23:59, Wookey wrote: +++ Philip Ashmore [2012-06-23 05:45 +0100]: On 23/06/12 00:53, Wookey wrote: I'm too busy developing the-next-big-thing(TM), but wanted to encourage some sort of global social bug-squashing event(s) - it might even encourage non-debianites to participate, or take more interest in Debian. This is a worthy goal. But nothing about that ideal _requires_ using google+ rather than any other chat service. I think you'd get a lot more traction if you separated those two ideas. Nearly everyone would agree that a global bug-squashing party is a good thing (although time-zones do impose limits on how well that works). Fewer would favour using google+ to synchronise it, as you have discovered. And again, I'm more in favour of Google+ as they provide the hardware+bandwidth now - I can't really see how an open source alternative could compete. It doesn't have to 'compete', it just has to be available, and there are plenty of open source chat services that would work for co-ordinating a bug-squashing party. And I don't really buy the "use open source at all costs" argument either That is obvious :-) - I don't know what software the network hubs use between me and the WWW, even the router I use pays half-assed lip-service by providing a download for some libraries it might have used - not enough to pimp it. My router runs openWRT (which makes it a lot more useful than the software that came with it). The packets out on the net may travel through some proprietary software but that's not something under my control. Yes it's almost impossible not to use _some_ proprietary software (PC bioses are hard to get away from for example, as is google's search engine), but there is value in only using the stuff you need to because there is no other sensible way (and people on what constitutes 'sensible'. Bug-squashing party co-ordination software does not come into that category IMHO, which is why you are finding your google+ suggestion less than enthusiasticaly received. I say, gauge the demand first, write an open source alternative if you can do it as well or better later. As I say - try to separate the ideas of global bug-squashing, from the service used to co-ordinate it, when gauging enthusiasm. It'll certainly help with an audience of Debian users and developers. It may make less difference to 'new people'. Wookey Somehow we went off-list - I know I do that sometimes accidentally. Anyway, I guess what I would look for, to share the bug squashing atmosphere with others, is a YouTube video summarising the event, maybe magazine style - it doesn't have to show someone actually squashing a bug, but it might help highlight the community spirit, and a video would be something I would click on to take a break from reading text. Philip -- 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/4fe73f3c.5030...@philipashmore.com
Re: Bug#678815: ITP: wmfs -- Window Manager From Scratch
On 24/06/12 18:15, Neil Williams wrote: On Sun, 24 Jun 2012 18:02:56 +0200 Mickaël Raybaud-Roig wrote: Thomas Koch wrote: Hi, I shortened the list to only include one line for each window manager already in Debian: axi-cache --all search x11::window-manager 100% 9wm - emulation of the Plan 9 window manager 8-1/2 100% aewm - minimalist window manager for X11 100% aewm++ - minimal window manager written in C++ 100% afterstep - window manager with the NEXTSTEP look and feel 100% blackbox - Window manager for X 100% bluetile - full-featured tiling for the GNOME desktop environment 100% dwm - dynamic window manager 100% evilwm - a minimalist window manager for X11 100% fluxbox - Highly configurable and low resource X11 Window manager 100% flwm - Fast Light Window Manager 100% fvwm - F(?) Virtual Window Manager 100% i3-wm - improved dynamic tiling window manager 100% icewm - wonderful Win95-OS/2-Motif-like window manager 100% jwm - very small lightweight pure X11 window manager with tray and menus 100% kde-window-manager - K window manager (KWin) 100% larswm - Lars Window Manager with tiled windows 100% lwm - lightweight window manager 100% matchbox-window-manager - window manager for resource-limited systems 100% metacity - lightweight GTK+ window manager 100% miwm - minimalist window manager with virtual workspaces 100% mutter - lightweight GTK+ window manager 100% openbox - standards compliant, fast, light-weight, extensible window manager 100% oroborus - A lightweight themeable windowmanager for X 100% pekwm - very light window manager 100% ratpoison - keyboard-only window manager 100% sapphire - A minimal but configurable X11R6 window manager 100% stumpwm - tiling, keyboard driven Common Lisp window manager 100% tinywm - tiny window manager 100% twm - Tab window manager 100% vtwm - Virtual Tab Window Manager 100% w9wm - enhanced window manager based on 9wm 100% windowlab - small and simple Amiga-like window manager 100% wm2 - small, unconfigurable window manager 100% wmaker - NeXTSTEP-like window manager for X 100% wmii - lightweight tabbed and tiled X11 window manager, version 3 100% xfwm4 - window manager of the Xfce project 100% xmonad - Lightweight X11 window manager written in Haskell 100% e17 - Enlightenment DR17 Window Manager 100% olvwm - OpenLook virtual window manager 100% olwm - Open Look Window Manager 100% herbstluftwm - manual tiling window manager for X11 You're right, there are already a lot of X11 window managers in Debian ... But WMFS is not already in the list and it works fine, that's why I want to package it :-) That is no reason for it to be in Debian. Debian is not a dumping ground for every piece of free software just because it "works fine". Do the hard work of objectively identifying *all* of the pros and cons of *all* the existing equivalents inside Debian already, compare those with the pros and cons of yours and if there's any time left before the heat death of the universe, maybe it can be considered. PS: i've uploaded a package here: http://mentors.debian.net/package/wmfs That is no reason for it to be uploaded either. There is no good reason for any new window managers in Debian. There are good reasons to look at removing at least 10% of the ones which are in Debian. Doing that comparative analysis would be a good start for identifying which can be removed - now *that* would be doing something useful for Debian. This bug is *not* useful to anyone. Please close it and find an RC bug to close instead. I didn't know you could do that with axi-cache - thanks. I'm always on the lookout for a better window manager - it's a matter of taste. Bug#678854: Acknowledgement (icewm won't start) Philip -- 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/4fe75da9.9030...@philipashmore.com
Re: Report from the Bug Squashing Party in Salzburg
On 24/06/12 17:54, Lars Wirzenius wrote: On Sun, Jun 24, 2012 at 05:24:28PM +0100, Philip Ashmore wrote: Anyway, I guess what I would look for, to share the bug squashing atmosphere with others, is a YouTube video summarising the event, maybe magazine style - it doesn't have to show someone actually squashing a bug, but it might help highlight the community spirit, and a video would be something I would click on to take a break from reading text. That's not a bad idea, but... Video production takes quite a lot of effort, both human and CPU. If you would like to participate in a bug squashing party and do that, please do. On the whole, however, Debian already has its full share of people with ideas. What we chronically have a shortage of is people who do things. Suggesting new things for others to do is orders of magnitude less useful than fixing or attempting to reproduce any of the reported bugs, writing even a barebones tutorial on the wiki, or helping someone with whatever problem they may have when using Debian. Could we perhaps entice you, Philip, to make a change to Debian instead of suggesting things for us to do? Bug#678854: Acknowledgement (icewm won't start) I've also got several projects in SourceForge and in Debian Mentors - it would be great if someone could be a point of contact for me in Debian - the projects are all related. Regards, Philip Ashmore -- 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/4fe75e5e.1080...@philipashmore.com
Re: Report from the Bug Squashing Party in Salzburg
On 24/06/12 17:35, Jonas Smedegaard wrote: On 12-06-24 at 05:24pm, Philip Ashmore wrote: Anyway, I guess what I would look for, to share the bug squashing atmosphere with others, is a YouTube video summarising the event, maybe magazine style - it doesn't have to show someone actually squashing a bug, but it might help highlight the community spirit, and a video would be something I would click on to take a break from reading text. Sounds like a great idea. Please consider contacting the Debian video team to instead/also distribute video content via http://vide.debian.net/ - and coordinate with them which formats to use (to avoid loosing quality from too many lossy conversions if initially published files are in formats inappropriate for Debian redistribution). - Jonas That should be http://video.debian.net/ I see an ogv file in http://meetings-archive.debian.net/pub/debian-meetings/2012/bucharest-talk/debian_ceata.ogv : 370MB - not the friendliest way for people to browse files - some snippets on YouTube would help with publicity here. Since I'm not in the position to decide how to trim this down (or even if it needs trimming) I'm sorry to say that I can't do this myself. Something like this should be on Debians main web page. Philip -- 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/4fe75ff5.7050...@philipashmore.com
Dublin, Ireland bug squashing party
Hi there. It's come to my attention that bug squashing parties are _the_ way to fix bugs. Not to be seen as uncool, I'm proposing a bug squashing party somewhere in Dublin, Ireland at a mutually agreed date and time. I'm just canvassing for support right now, as I don't know the Debian procedure for doing this - or even if there is one. One of the topics/issues/bugs I hope to address is getting my open source projects in SourceForge knocked into shape for acceptance into Debian. I don't know if that meets the criteria for "party" - maybe a shindig or a hootenanny. Regards, Philip Ashmore -- 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/4fe7fe98.1030...@philipashmore.com
Debian BSP, Dublin, Ireland
Hi there. I would like to invite you to the Doodle poll "Debian BSP, Dublin, Ireland". I've pencilled the weekends in July initially, unless there are compelling reasons for a different month. I haven't decided on a location yet as it is subject to sponsorship and/or space donation. Please follow the link in order to participate in the poll: http://www.doodle.com/qmiu7fp73g2i3xet Regards, Philip Ashmore -- 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/4fe8e021.1020...@philipashmore.com
Re: Dublin, Ireland bug squashing party
On 25/06/12 16:03, Martín Ferrari wrote: Hi Phillip, On Mon, Jun 25, 2012 at 7:00 AM, Philip Ashmore wrote: It's come to my attention that bug squashing parties are _the_ way to fix bugs. Not to be seen as uncool, I'm proposing a bug squashing party somewhere in Dublin, Ireland at a mutually agreed date and time. That is a great idea! There does not seem to be much local Debian activity, despite the number of DDs living here, and this is a good way to help revert that, and help the release! Have you thought of a place, or talked with anybody about that? I'm thinking the TOG might be a good place. How many people can it accommodate? Are there fees? Network/WiFi? Food/drink? I'm just canvassing for support right now, as I don't know the Debian procedure for doing this - or even if there is one. I'd participate and/or help organise. Yes to both - it's my first BSP. One of the topics/issues/bugs I hope to address is getting my open source projects in SourceForge knocked into shape for acceptance into Debian. I don't know if that meets the criteria for "party" - maybe a shindig or a hootenanny. I think BSPs usually focus on fixing problems for packages already in Debian, specially RC bugs. But nobody would discourage you from working on your packages and getting help from other people doing so! Tincho. Philip -- 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/4fe8e190.3060...@philipashmore.com
Re: Debian BSP, Dublin, Ireland
On 25/06/12 23:07, Mika Pflüger wrote: Hi, Am Mon, 25 Jun 2012 23:03:13 +0100 schrieb Philip Ashmore: Hi there. I would like to invite you to the Doodle poll "Debian BSP, Dublin, Ireland". I've pencilled the weekends in July initially, unless there are compelling reasons for a different month. I haven't decided on a location yet as it is subject to sponsorship and/or space donation. Please follow the link in order to participate in the poll: http://www.doodle.com/qmiu7fp73g2i3xet you might want to send that email also (or exclusively) to debian-events...@lists.debian.org ; There might be people interested that are not subscribed to debian-devel and as debian-events-eu is the "right" list, you might have more luck over there. Cheers, Mika Hi there. I wasn't subscribed to that list, so I wouldn't have known about the event if someone else had posted it. I don't remember reading about where to post a BSP - where does one look this stuff up? Sounds like someone needs to write an "interfacing with Debian" app. The first thing I'd like the app to be able to do is to list what li...@debian.org I'm subscribed to. Thanks for the heads up! Regards, Philip Ashmore -- 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/4fe8eb35.4010...@philipashmore.com
Debian BSP, Dublin, Ireland, Cork alternative
Hi there. I got into a delete-those-emails frenzy earlier and assumed I could read them on Debians mailing list. This is true only if someone doesn't mail me personally, which I now realise happened wrt. an email suggesting it be hosted in Cork. Please send the email to me or the list again - there's no need to pick between Dublin and Cork - why not have both? If they're at different times then more can go to both. If they're on at the same time then we can try some video-conferencing software as long as it doesn't cost anything to use and is easy to set up - open source if possible. Regards, Philip Ashmore -- 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/4fe939c2.1060...@philipashmore.com
Re: Debian BSP, Dublin, Ireland
Hi there. I've got a Samsung NP-RF711-S07UK laptop - it's so new that Samsungs own website doesn't list it. Here's a link with product specs: http://www.elaraonline.co.uk/productdetail.aspx?productcode=ECE2391461 Anyway, it's got back-light+hot-keys+fan control issues. It turns out that even the latest kernel linux-3.5-rc4 doesn't have a DMI table entry for it in drivers/platform/x86/samsung-laptop.c. # dmidecode -s system-product-name RF511/RF411/RF711 It would be great if any kernel developers could be present at the BSP - it's a great laptop and sorting out support for it would be a sweet bug to fix. Regards, Philip Ashmore -- 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/4fe94615.6040...@philipashmore.com
apt-get source gets a more recent version of linux than I can install
Hi there. I noticed a few hours ago that apt-get source linux gets me 3.2.21-1, but the I have the "latest" kernel installed which is 3.2.20-1. What gives? Philip -- 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/4fea072d.8040...@philipashmore.com
Bug#681058: ITP: v3c-storyboard -- Tell a story
Package: wnpp Severity: wishlist Owner: Philip Ashmore * Package name: v3c-storyboard Version : 0.2.0-04 Upstream Author : Philip Ashmore * URL : http://sourceforge.net/projects/v3c-storyboard/ * License : LGPLv3 Programming Lang: C, C++ Description : Tell a story Bootstraps software development from fundamental principals. It uses the "story" narritive to explain these principals as well as showing the user how to do the same with their ideas. -- 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/20120710103311.6383.57346.reportbug@buckyball.local
Debian stickers
Hi there. Has anyone thought of making Debian stickers for 1. products that work with Debian 2. products that can have Debian installed on them This would need some kind of database detailing products and any issues associated with them. These could be grouped by company, country of origin, application etc. Maybe there could also be an offenders top ten list for companies that aren't bothered 1. providing the software they developed using Debian or GPL code without build instructions 2. closed source firmware I know I would have liked to see a page on the installation process that told me how well the PC I was installing Debian on was supported in terms of drivers and features. For unidentified or new hardware it could offer to add the PC to a database where users of the same make/model could go to track updates in driver selection etc, or even do it for them. Thoughts? Philip Ashmore -- 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/500ac127.9010...@philipashmore.com
Re: Debian stickers
On 21/07/12 18:17, Neil Williams wrote: On Sat, 21 Jul 2012 15:48:07 +0100 Philip Ashmore wrote: I know I would have liked to see a page on the installation process that told me how well the PC I was installing Debian on was supported in terms of drivers and features. For unidentified or new hardware it could offer to add the PC to a database where users of the same make/model could go to track updates in driver selection etc, or even do it for them. Thoughts? Many similar ideas have been and gone over the years, nobody has managed to collate the data and make it work. Are you volunteering? The Linux Hardware Database is long gone. http://linuxhardware.net/ has a noticeable lack of data, just a set of links to various wikis. Then you'd have to deal with the whole range of Debian installations, from servers to laptops to embedded. The biggest problem is that none of the arbitrary strings which get printed on the packaging, product specs or even on the hardware itself have any direct link to the actual chipsets used and it is the chipsets which determine support. Most manufacturers have no interest in providing this information as Debian compatibility is not seen as interesting. What version of Debian is this meant to be the basis of the data? Don't assume stable because it's unstable where new support arrives but it is testing which gets updated d-i builds. Who updates the data? It's not really about the distro anyway, it's about the kernel in most cases. If you fancy working with the kernel and d-i teams to implement this support, send patches to the relevant lists. The point is not the stickers, the point is the reliable identification of hardware despite manufacturers deliberately hiding the actual details of which chips are actually used. This kind of stuff has to be done by the manufacturer - that's how it works for Windows compatibility. Doing this after manufacture is impractical because manufacturers will always have to change chipsets without changing the "branding" of the "product". That may mean providing an "updated" driver for Windows, it does not always mean providing Linux kernel support, let alone GNU/Linux distribution support. This is an old problem. Big organisations are already involved in lobbying for improved support - in the end, there shouldn't need to be a database, the problem needs to be fixed at manufacture such that Linux kernel support "just happens". Check out the Linux Foundation. Yes it is a can of worms that created itself through vendors playing games with the specifications (like ACPI), and Microsoft letting them to do so. It raises some interesting questions: 1. If Microsoft are going to sign a Debian EFI key, what version of Debian does it apply to? 2. If Microsoft are inclined to sign such a key, to they also commit to providing things like chipset identification data, allowing Debian to uniquely identify a PC and/or all its features? 3. Could Debian seriously claim to support a particular PC without the means to identify it and/or its features? 4. Could this be a "certified for Debian" requirement? 5. Could Microsoft require Debian certification before signing Debians key for a PC? Regards, Philip -- 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/500b1c15.8020...@philipashmore.com
Re: Debian stickers
On 22/07/12 10:57, Mike Dupont wrote: That would be great! It would help when shopping! On Sat, Jul 21, 2012 at 2:48 PM, Philip Ashmore mailto:cont...@philipashmore.com>> wrote: Has anyone thought of making Debian stickers for 1. products that work with Debian -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org Saving wikipedia(tm) articles from deletion http://SpeedyDeletion.wikia.com Contributor FOSM, the CC-BY-SA map of the world http://fosm.org Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3 I hadn't thought of the vendor sticking the badge on their product - nice idea. I guess if Microsoft is willing to sign Debians EFI key, then they must at least in theory concede that some vendors might sell PCs without Windows installed - bizarre. No, I was (initially) thinking of regular users buying badges, like you could for the Raspberry Pi - I hope the shop opens again soon! http://www.raspberrypi.org/archives/320 Philip -- 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/500c737a.4050...@philipashmore.com
Re: Preventing government subversion in Debian, verification of binary package uploads
On 24/08/13 22:58, Russ Allbery wrote: > Thomas Hood writes: > >> If a Debian contributor were faced with a demand to do something that >> undermines the privacy or other interests of Debian users then I would >> hope and expect that the contributor would choose instead to cease being >> a contributor. Were he not to do so then he would have to be regarded as >> an infiltrator. > >> Here I assume that U.S. law is not so draconian that it can require >> someone who has contributed to Debian (and who is therefore trusted) to >> continue doing so. > > I believe that assumption is not correct based on previous things that > have happened with National Security Letters from the small amount of > public information that people have been able to gather. > The defining attribute of open source is that the source is available for anyone to inspect, change and compile themselves. That of course breaks down when we have to install binary blobs for some devices to function, or to make enhanced functionality available. It's still better than closed source operating systems you pay money for and in return promise to be the best they can, given the constraint that they're in it for the money, and that they're the ones to trust with your data, unless the people after it are very very good/bad. Don't even get me started about the hardware our OSes run on. Regards, Philip Ashmore -- 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/52193057.4040...@philipashmore.com
Re: Bug#646069: Debian and AutoMake
Hi there. This email isn't a criticism of rxtx - thanks Scott for accepting my patch. It's more of a starting point for issues with development on Debian and other distributions - see the last comment. On 23/10/11 15:08, Scott Howard wrote: clone 646069 -1 retitle -1 rxtx: make -dbg package for rxtx retitle 646069 rxtx: fails when "java.ext.dirs" system property contains more than one directory rxtx doesn't fail, it just fails to read any gnu.io.rxtx.properties file that may exist in one of these directories because the filename is constructed from the directory names joined with ":". I created a gnu.io.rxtx.properties file in one of the directories but I don't know what would happen (Java-wise) if there were more than one of these files - I haven't tested it. It will work without finding any gnu.io.rxtx.properties file. severity -1 wishlist thanks Thanks for the patch, great work. Separated this into two bugs 1) I'll apply the patch and forward it upstream. RXTX really isn't maintained much anymore upstream, but I'll at least share it on the mailing list. 2) We'll build with make -DDEBUG_VERBOSE and make a -dbg package for gdb. A "foo-dbg" package is one with debugging symbols for package "foo". Maybe "rxtx-verbose" would be a better name, with rxtx <- conflicts -> rxtx-verbose as an install option. As for the make uninstall, autotools does a poor job with uninstall targets [1] and upstream has a custom install target that just puts the RXTXcomm.jar into the same directory as the jvm and libtool install the native libraries. The Debian source package really isn't intended to be used to install outside of the debian packaging system. That's a shame if it's the case in general. I certainly wouldn't have considered using dpkg-buildpackage given the turnaround I wanted with the source code changes. fakeroot debian/rules binary didn't work either. I've got some packages in SourceForge. You can get them via http://sourceforge.net/users/philipashmore You can build Debian/Ubuntu packages with make debian You can install/uninstall them with make install make uninstall using the makefile in the package root that wraps automake. You will need to use "sudo" if you want to install them in a system directory, like /usr or /usr/local. If you've git-cloned a package repository you can also do things like make git branch=a.b.c distcheck make git tag=a.b.c release debian The "tag" variant is for branches you tag locally. If you want to build a package in a sandbox along with all its dependent v3c packages, you git clone the v3c packages into some directory writeable by you, then you can use v3c's "v3c-tryout" script v3c-tryout , as in ./v3c-tryout v3c-dcom-0.3.2-01 tryout-v3c-dcom and it will 1. git checkout the respective versions of the dependent packages as required by the version of the package you specified, into the sandbox dir. 2. build and install them to the sandbox dir in order. 3. create shell scripts to set up a (b/d)ash session inside the sandbox, to test the packages or run "make check", mess with the sources, uninstall... to uninstall, just delete the .jar and glibtool --mode=uninstall $(RM) list_of_targetlib Cheers, Scott [1] http://sourceware.org/autobook/autobook/autobook_109.html I'd really like to see something like this adapted by Debian and other distributions to save developers from reinventing the wheel or discovering that the package doesn't adhere to published documentation. What do you think? Philip -- 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/4ea43e15.6050...@philipashmore.com
Re: Using Qt debug libraries without configure and qmake
On 17/11/11 12:19, Simon McVittie wrote: On Thu, 17 Nov 2011 at 13:00:40 +0100, Malte Forkel wrote: - What do you mean by Don't strip in the upstream build. Just don't. Ever. Is it that any stripping should be initiated from debian/rules, but should never be performed by the upstream Makefiles? Always build with -g, and never discard the debug symbols entirely. The Debian way to strip debug symbols out of the "normal" library is usually done with dh_strip, part of debhelper: * first, objcopy(1) the debug symbols into files that will end up installed to /usr/lib/debug by the -dbg binary package - gdb knows how to find them there automatically * then and only then, use strip(1) to remove the debug symbols from the "main" version of the library The files in /usr/lib/debug are not complete libraries: they contain the debug symbols which were previously in the corresponding library in /usr/bin, but they do not contain any executable code. This means the main library package is small (because it only contains the executable code), but can still be debugged by installing the corresponding -dbg package (which contains the corresponding debug symbols). While debugging your program or library, gdb reads both the main library and its debug symbols, and behaves as if the debug symbols had been in the main library all along. I've been saying "library", but some packages do the same for binaries (e.g. dbus-dbg contains /usr/lib/debug/usr/bin/dbus-daemon, which contains the debug symbols for /usr/bin/dbus-daemon, without duplicating the executable code). The dh_strip source code is very readable; have a look at it if you want more detail. S While useful, debug symbolsonlyhelp so much. On some other distributions the debugging symbols package includes the source code and kdbg integration so that kdbg can prompt you to download the dbg package while you're debugging an app. Even with this, optimization can make the instruction pointer appear to dart all over the place when single stepping, and also optimizes out variables that you would sometimes really like to know the value of. Maybe a "noopt" package variant would help here, but that would nearly double the number of package builds. Wasn't there a gcc objective to tame this with release builds? Looking at "Re: Could the multiarch wiki page be explicit about pkgconfig files?" I've seen debugging symbols point to source files all over the place, depending on who or how the package in question was built, none of which pointed to /usr/lib/debug or similar. Developers new to Debian can't fail to be surprised by this. Regards, Philip Ashmore -- 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/4ec507ec.3000...@philipashmore.com
Re: Using Qt debug libraries without configure and qmake
On 17/11/11 14:56, Neil Williams wrote:
On Thu, 17 Nov 2011 13:11:08 +
Philip Ashmore wrote:
While useful, debug symbolsonlyhelp so much.
On some other distributions the debugging symbols package includes the source
code
and kdbg integration so that kdbg can prompt you to download the dbg package
while
you're debugging an app.
Even with this, optimization can make the instruction pointer appear to dart all
over the place when single stepping, and also optimizes out variables that you
would sometimes really like to know the value of.
Maybe a "noopt" package variant would help here, but that would nearly double
the
number of package builds.
Wasn't there a gcc objective to tame this with release builds?
Looking at "Re: Could the multiarch wiki page be explicit about pkgconfig
files?"
I've seen debugging symbols point to source files all over the place, depending
on who or how the package in question was built, none of which pointed to
/usr/lib/debug or similar.
Developers new to Debian can't fail to be surprised by this.
The path doesn't matter that much, as long as the debugger can find a
filename which at least matches the end of the path. i.e. work
backwards and use the best match. This isn't down to Debian, it is down
to how gcc and gdb work together and how developers need to use gdb or
other tools frontending gdb to set the path to the unpacked sources.
Some tools do it better than others, especially when considering how to
follow a call down through a couple of different libraries.
You mean as long as the user knows where the sources are supposed to be
installed, such as
/usr/src/foo-1.2/src/foo-widget.cpp
, presuming they are even installed or the user downloaded (the matching
version of) them.
The debugger will only find the file itself if the debugging information
contains an absolute path.
The choice of root folder, for example /usr/src/foo-1.2 or
/usr/src/{build-id}/foo-1.2
is Debian specific.
The tools which Debian supplies should also use it so that the sources
get installed there.
Hopefully one day, the Debian build tools will alter the debugging
information to point to this
location regardless of where the sources really were when the package
was built.
Could this be a build option?
Also, if source packages from deb-src could be "installed", populating
/usr/src then that would
avoid having to package "source" binary packages, and be version-safe.
Philip
--
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/4ec56826.1070...@philipashmore.com
Re: Using Qt debug libraries without configure and qmake
On 18/11/11 00:07, Neil Williams wrote:
On Thu, 17 Nov 2011 20:01:42 +
Philip Ashmore wrote:
On 17/11/11 14:56, Neil Williams wrote:
The path doesn't matter that much, as long as the debugger can find a
filename which at least matches the end of the path. i.e. work
backwards and use the best match. This isn't down to Debian, it is down
to how gcc and gdb work together and how developers need to use gdb or
other tools frontending gdb to set the path to the unpacked sources.
Some tools do it better than others, especially when considering how to
follow a call down through a couple of different libraries.
You mean as long as the user knows where the sources are supposed to be
installed, such as
/usr/src/foo-1.2/src/foo-widget.cpp
$ apt-get source
That puts the unpacked source exactly where the user expects - in the
current directory.
You'd need to be root to put the unpacked source into /usr/src using
apt-get source and that is NOT good advice.
There are binary packages which *install* the source into /usr/src but
that isn't the default. This is about getting the source of typical,
routine Qt applications and libraries. *That* is what you get from
deb-src URL's. Packages which unpack to /usr/src will come from deb
repositories NOT deb-src.
, presuming they are even installed or the user downloaded (the matching
version of) them.
apt-get source - it always gives you the matching version, that's the
point.
presuming you've done apt-get upgrade, which requires elevated(root)
privileges.
The debugger will only find the file itself if the debugging information
contains an absolute path.
Not true. The debugger will look for the path you provide and try to
match the files according to the reverse lookup - much the same way as
patch.
so it won't find it itself based on the path provided in the debugging
information.
Sometimes it's far from obvious which package a source file belongs to.
It would be great if the debugger could tell you.
The choice of root folder, for example /usr/src/foo-1.2 or
/usr/src/{build-id}/foo-1.2
is Debian specific.
More commonly, /home/$USER/code/src/$PACKAGE etc.
The tools which Debian supplies should also use it so that the sources
get installed there.
Hopefully one day, the Debian build tools will alter the debugging
information to point to this
location regardless of where the sources really were when the package
was built.
Could this be a build option?
No, because the actual location varies according to user preference.
but unless you've built the package from source yourself, the debugging
information points to just one place - usually the location on the
machine that
built it, not very useful.
I use /home/neil/code/debian/src or /home/neil/code/debian/qa/
or /home/neil/code/debian/rc, depending on why I'm debugging a
particular package. ./src/ for routine devleopment, ./qa/ for orphaned
packages and ./rc/ for release goals. Depending on exactly what is
going on, I could quite easily be debugging three different versions of
the same package in those directories and if I need to debug a fourth,
well it's trivial.
Also, if source packages from deb-src could be "installed", populating
/usr/src then that would
avoid having to package "source" binary packages, and be version-safe.
Forget about /usr/src, it isn't useful for the majority of packages.
Arbitrary directories specified by the user are the only way to allow
developers to debug against a variety of dependencies and in a variety
of situations. /usr/src is a privileged path, source does not need a
privileged path and is usually far better in a user path.
Qt applications or libraries do NOT use /usr/src.
I'm not a Fedora fan, but that's exactly what they do.
It's a de-facto Debian decision not to standardize on any install path,
which is
bizarre.
Don't forget, some people have accounts on multi-user systems, and filling
their home directory with package sources is something they simply cannot do
for space reasons, and even if they could, it duplicates downloads and
storage.
Yes, I realise this isn't Qt specific.
With respect, have you had a look at
http://lists.debian.org/debian-devel/2011/09/msg00517.html
?
Philip
--
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/4ec64bb1.7000...@philipashmore.com
GNU/Linux COM development and Wine/Samba
Hi there. I've got several projects in SourceForge, one of which is v3c-dcom http://sourceforge.net/projects/v3c-dcom/ I'm quickly coming to the realisation that I would need several headers/tools from Wine http://www.winehq.org/ , the idea being to be able to develop COM components natively. I'd rather not simply pick them out of Wine, and was hoping to start off something more productive. I guess the topics for discussion are 1. What's the "Debian" way of doing this? Wine development packages would be split into a shared, Wine, Samba and GNU/Linux-specific binary/dev packages. 2. Does Debian officially approve of the idea of a native COM/DCOM implementation? Wine already does this, but the premise is that it's for Windows programs, which is a bit vague. As this seems to be approved by Microsoft by default, could this situation change with a native port? Would this be rocking the apple cart? 3. These native components could eventually talk to Wine/Samba components. Does anybody care about this? 4. Samba/Wine integration Shared components mean less code to debug. Samba and Wine seem to be stuck here. Maybe having a native implementation that they could both use would be the answer, since Wine and Samba are native implementations already. Comments please. Regards, Philip Ashmore -- 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/4ee17e08.40...@philipashmore.com
Re: GNU/Linux COM development and Wine/Samba
On 09/12/11 19:57, Stephen Kitt wrote: Hi Philip, On Fri, 09 Dec 2011 03:18:32 +, Philip Ashmore wrote: I've got several projects in SourceForge, one of which is v3c-dcom http://sourceforge.net/projects/v3c-dcom/ I'm quickly coming to the realisation that I would need several headers/tools from Wine http://www.winehq.org/ , the idea being to be able to develop COM components natively. I'd rather not simply pick them out of Wine, and was hoping to start off something more productive. Do you have a list of the headers involved? The MinGW-w64 project regularly syncs some of its headers from Wine, it may already have what you're looking for (albeit in an awkward location if you're developing for Linux rather than for Windows). It's available in Debian as mingw-w64; the headers are in mingw-w64-dev. Regards, Stephen To avoid duplication please see my reply to Jelmer Vernooij's email. Philip -- 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/4ee29497.5010...@philipashmore.com
Re: GNU/Linux COM development and Wine/Samba
On 09/12/11 17:43, Jelmer Vernooij wrote: Am 09/12/11 04:18, schrieb Philip Ashmore: I've got several projects in SourceForge, one of which is v3c-dcom http://sourceforge.net/projects/v3c-dcom/ I'm quickly coming to the realisation that I would need several headers/tools from Wine http://www.winehq.org/ , the idea being to be able to develop COM components natively. I'd rather not simply pick them out of Wine, and was hoping to start off something more productive. debian-devel is probably not the best place for this discussion - you might want to talk to the relevant upstream project (Wine) instead. I'm thinking of this as a packaging issue. There may be patches to fill in some gaps. I guess the topics for discussion are 1. What's the "Debian" way of doing this? Wine development packages would be split into a shared, Wine, Samba and GNU/Linux-specific binary/dev packages. There isn't anything Samba-related or GNU/Linux-specific in the Wine headers as far as I know. What would you like to split out? The initial list: widl - to generate header files and type libraries. oaidl.idl objidl.idl unknwn.idl wtypes.idl basetsd.h guiddef.h Then there's the code to parse type libraries and use them to implement IDispatch::Invoke. v3c-dcom's implementation is really small - too small even for multi-threading or Apartments, but once the kernel is there, others are free to build on it. 2. Does Debian officially approve of the idea of a native COM/DCOM implementation? Wine already does this, but the premise is that it's for Windows programs, which is a bit vague. As this seems to be approved by Microsoft by default, could this situation change with a native port? Would this be rocking the apple cart? I can see the use of wanting to support DCOM/COM for interoperability reasons, but is anybody actually interested in developing new applications using these technologies? Even Microsoft has been slowly phasing them out. Having worked on a DCOM implementation (in Samba 4) myself in the past, it would be the last RPC mechanism I would choose to use if I was starting a new project... I'll admit that DCOM isn't at the top of my list. v3c-dcom's initial goal is a layer of components you can use for something as small as a boot loader. At the moment it's a really general purpose plug-in system. Once it can do COM threading and marshalling, you could choose which ever RPC mechanism was convenient/available - more plug-ins. Just out of interest, which RPC mechanism would you choose? 4. Samba/Wine integration Shared components mean less code to debug. Samba and Wine seem to be stuck here. Maybe having a native implementation that they could both use would be the answer, since Wine and Samba are native implementations already. Samba is wire-level compatible with Windows, but apart from that it has a completely different architecture. Wine is API-level compatible, which seems more appropriate for implementing an interface technology like COM. DCOM is a part of COM that allows using it over the network, on top of DCE/RPC. Before DCOM even comes into the picture though, you would have to implement COM in Wine, which is a *huge* undertaking all by itself. When you get to implementing DCOM, you could probably use some of the Samba libraries (in particular, our DCE/RPC client/server libraries). Those libraries are already there though, and usable. I don't see why it is necessary to add new components that have to be shared between Wine and Samba. If I understand correctly, Wine already implements DirectX, which requires a COM implementation. If all of them (Wine, Samba, + others), could reuse a common set of libraries to talk to each other over named pipes, fifos, tcp/ip or what ever OS mechanism was at hand then porting them to new platforms or architectures would be that much easier. Cheers, Jelmer Regards, Philip -- 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/4ee294bd.2030...@philipashmore.com
Re: GNU/Linux COM development and Wine/Samba
On 10/12/11 02:46, Jelmer Vernooij wrote: Am 10/12/11 00:07, schrieb Philip Ashmore: On 09/12/11 17:43, Jelmer Vernooij wrote: Am 09/12/11 04:18, schrieb Philip Ashmore: I've got several projects in SourceForge, one of which is v3c-dcom http://sourceforge.net/projects/v3c-dcom/ I'm quickly coming to the realisation that I would need several headers/tools from Wine http://www.winehq.org/ , the idea being to be able to develop COM components natively. I'd rather not simply pick them out of Wine, and was hoping to start off something more productive. debian-devel is probably not the best place for this discussion - you might want to talk to the relevant upstream project (Wine) instead. I'm thinking of this as a packaging issue. There may be patches to fill in some gaps. It seems to me that it just requires a lot of upstream work in Wine, possibly utilizing already existing other libraries - that don't require any significant changes. The only packaging changes required (other than updating to a new upstream with the COM support) would be limited to (at most) adding extra dependencies. I think we should probably take this discussion off-list, or to the wine list, until there is something concrete related to Debian to talk about. I'm literally talking about Debian creating a "wine-vine"package that contains 1. widl 2. some pared down idl's, leaving out anything to do with window handles/GUIs 3. adding some stuff from v3c-dcom to create sandboxes and instances, like it's mini-ATL (c++). Then there's a "wine-script" package that would use vine-vine but provide, in addition 3. type library bits and bobs It would be for developers who wanted a plug-in system with scripting capability, say to write their own scripting language. I guess the topics for discussion are 1. What's the "Debian" way of doing this? Wine development packages would be split into a shared, Wine, Samba and GNU/Linux-specific binary/dev packages. There isn't anything Samba-related or GNU/Linux-specific in the Wine headers as far as I know. What would you like to split out? The initial list: widl - to generate header files and type libraries. oaidl.idl objidl.idl unknwn.idl wtypes.idl basetsd.h guiddef.h Then there's the code to parse type libraries and use them to implement IDispatch::Invoke. v3c-dcom's implementation is really small - too small even for multi-threading or Apartments, but once the kernel is there, others are free to build on it. Those are all unrelated to Samba nor are they specific to GNU/Linux. They're just a part of COM and could happily live in Wine. But I'm talking about Debian packages, wine-vine with vastly pared down bits Wine, and wine-talk for a layer above that. These allow for COM development in GNU/Linux forGNU/Linux, but in code reuse terms Wine and Samba plus others would benefit from additional transport mechanisms as well as what a common code base gets you - additional testing - extra capabilities - simplifying porting 2. Does Debian officially approve of the idea of a native COM/DCOM implementation? Wine already does this, but the premise is that it's for Windows programs, which is a bit vague. As this seems to be approved by Microsoft by default, could this situation change with a native port? Would this be rocking the apple cart? I can see the use of wanting to support DCOM/COM for interoperability reasons, but is anybody actually interested in developing new applications using these technologies? Even Microsoft has been slowly phasing them out. Having worked on a DCOM implementation (in Samba 4) myself in the past, it would be the last RPC mechanism I would choose to use if I was starting a new project... I'll admit that DCOM isn't at the top of my list. v3c-dcom's initial goal is a layer of components you can use for something as small as a boot loader. At the moment it's a really general purpose plug-in system. Once it can do COM threading and marshalling, you could choose which ever RPC mechanism was convenient/available - more plug-ins. COM wouldn't be my first choice for a component interface either, unless I was trying to get existing COM-based code to work... :-) So what would be your first choice, then? Just out of interest, which RPC mechanism would you choose? It depends on the circumstances, but even plain DCE/RPC is a lot more sensible than DCOM if you need a generic RPC mechanism. The DCOM protocol is complex, proprietary, badly documented, inefficient, and hard to implement. 4. Samba/Wine integration Shared components mean less code to debug. Samba and Wine seem to be stuck here. Maybe having a native implementation that they could both use would be the answer, since Wine and Samba are native implementations already. Samba is wire-level co
Bug#652423: ITP: v3c -- C/C++/sh/make/automake/Debian utility toolkit
Package: wnpp Severity: wishlist Owner: Philip Ashmore * Package name: v3c Version : 2.5.0-01 Upstream Author : Name * URL : http://sourceforge.net/projects/v3c/ * License : (LGPL) Programming Lang: C, C++, make, m4 Description : C/C++/sh/make/automake/Debian utility 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/20111217050655.12016.99679.reportbug@potemkin.local
Bug#652425: ITP: treedb -- on-disk memory library
Package: wnpp Severity: wishlist Owner: Philip Ashmore * Package name: treedb Version : 1.3.0-01 Upstream Author : Philip Ashmore * URL : http://sourceforge.net/projects/treedb/ * License : LGPL Programming Lang: C, C++,m4 Description : on-disk memory library -- 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/20111217052352.29427.26191.reportbug@potemkin.local
Bug#652429: ITP: meta-treedb -- on-disk memory library using meta-data
Package: wnpp Severity: wishlist Owner: Philip Ashmore * Package name: meta-treedb Version : 1.4.0-01 Upstream Author : Philip Ashmore * URL : http://sourceforge.net/projects/meta-treedb/ * License : LGPL Programming Lang: C, C++, m4 Description : on-disk memory library using meta-data -- 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/20111217053122.8044.95065.reportbug@potemkin.local
Bug#652432: ITP: v3c-dcom -- Baby steps to DCOM
Package: wnpp Severity: wishlist Owner: Philip Ashmore * Package name: v3c-dcom Version : 0.5.0-01 Upstream Author : Philip Ashmore * URL : http://sourceforge.net/projects/v3c-dcom/ * License : LGPL Programming Lang: C, C++, m4 Description : Baby steps to DCOM -- 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/20111217055011.28240.18694.reportbug@potemkin.local
Bug#652433: ITP: v3c-qt -- v3c/automake wrapper for QT
Package: wnpp Severity: wishlist Owner: Philip Ashmore * Package name: v3c-qt Version : 0.7.0-01 Upstream Author : Philip Ashmore * URL : http://sourceforge.net/projects/v3c-qt/ * License : LGPL Programming Lang: m4 Description : v3c/automake wrapper for QT -- 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/20111217061006.20682.98725.reportbug@potemkin.local
Bug#652435: ITP: v3c-qt-examples -- v3c/automake wrapper for Qt4 - examples
Package: wnpp Severity: wishlist Owner: Philip Ashmore * Package name: v3c-qt-examples Version : 0.7.0-01 Upstream Author : Philip Ashmore * URL : http://sourceforge.net/projects/v3c-qt/ * License : LGPL Programming Lang: C++ Description : v3c/automake wrapper for Qt4 - examples -- 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/20111217064549.7799.98567.reportbug@potemkin.local
Re: Bug#652423: Acknowledgement (ITP: v3c -- C/C++/sh/make/automake/Debian utility toolkit)
Long description: utility C/C++ include files libv3c - a C/C++ library v3c - a utility program meant to be used in scripts or from the command line makefile includes - see v3c's client projects "makefile" for examples automake/aclocal m4 macros - see v3c's client projects for examples -- 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/4eec7e73.7010...@philipashmore.com
Re: Bug#652425: Acknowledgement (ITP: treedb -- on-disk memory library)
Long description: treedb can implement malloc functionality, and much more! Need a heap that allocates of a fixed size chunk of memory? No problem. But where treedb comes into its own is when it comes to allocating from a mmap()ed disk file - the memory becomes persistent. . If you follow the tests/examples, you too can store dictionaries, trees, lists or whatever you can think of in disk-based memory, just an open() and mmap() away. . Treedb comes with an AVL tree, doubly-linked-list and variable-entry-sized-array implementations for you to use in your data structures. -- 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/4eec7f06.8060...@philipashmore.com
Re: Bug#652429: Acknowledgement (ITP: meta-treedb -- on-disk memory library using meta-data)
Long description: meta-treedb can implement malloc functionality, and much more! Need a heap that allocates of a fixed size chunk of memory? No problem. But where treedb comes into its own is when it comes to allocating from a mmap()ed disk file - the memory becomes persistent. . If you follow the tests/examples, you too can store dictionaries, trees, lists or whatever you can think of in disk-based memory, just an open() and mmap() away. . Meta-treedb comes with an AVL tree, doubly-linked-list and variable-entry-sized-array implementations for you to use in your data structures. . So, what distinguishes meta-treedb from treedb? * "class" interfaces for treedb collections . These are vtables (virtual function tables) that implement the interface. * faster compiles - only the "class" interfaces are visible to client code . This is at the expense of a small performance hit. * the ability to use implementations that were developed after client code was . compiled. . This feature hasn't been fully fleshed out yet, as it would require a . plug-in system such as that provided by v3c-dcom, but it's coming soon. -- 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/4eec7f91.4040...@philipashmore.com
Re: Bug#652432: Acknowledgement (ITP: v3c-dcom -- Baby steps to DCOM)
Long description: v3c-dcom provides a plug-in system as an alternative COM implementation. Unlike COM, v3c-dcom encourages the use of "sandboxes" of registered plug-ins, so allowing per site, per-group, per-user, per-program and per-job sandboxes, allowing virtually unlimited configuration and customization. Users and client programs can even create sandboxes on the fly. . Using COM's naming scheme aims at reducing the learning curve for those familiar with COM, as does the tiny ATL implementation for C++ developers. -- 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/4eec8020.5060...@philipashmore.com
Re: Bug#652433: Acknowledgement (ITP: v3c-qt -- v3c/automake wrapper for QT)
Long description: The v3c-qt package ties QT doxygen-generated documentation into the v3c documentation chain, so that client packages can "inherit" this in their own doxygen-generated documentation. . It also provides automake rules for MOC, UIC and RCC, to ease their usage in client packages automake Makefile.am files. -- 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/4eec8188.5000...@philipashmore.com
Re: Bug#652435: Acknowledgement (ITP: v3c-qt-examples -- v3c/automake wrapper for Qt4 - examples)
Long description: The v3c-qt package ties QT doxygen-generated documentation into the v3c documentation chain, so that client packages can "inherit" this in their own doxygen-generated documentation. . It also provides automake rules for MOC, UIC and RCC, to ease their usage in client packages automake Makefile.am files. . This is the examples package. -- 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/4eec81fe.1020...@philipashmore.com
Re: Bug#652433: ITP: v3c-qt -- v3c/automake wrapper for QT
On 17/12/11 16:25, Mario Fux wrote: Am Samstag 17 Dezember 2011, 07.10:06 schrieb Philip Ashmore: Package: wnpp Severity: wishlist Owner: Philip Ashmore * Package name: v3c-qt Version : 0.7.0-01 Upstream Author : Philip Ashmore * URL : http://sourceforge.net/projects/v3c-qt/ * License : LGPL Programming Lang: m4 Description : v3c/automake wrapper for QT I think this should be "Qt" (for the Qt Framework from Nokia) and not "QT" for Quicktime? And yes I saw that's wrong upstream (see URL above) as well. thx Mario Fixed upstream - thanks. Should I file another ITP to change the spelling? Regards, Philip Ashmore -- 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/4eed382b.50...@philipashmore.com
Re: Bug#652423: Acknowledgement (ITP: v3c -- C/C++/sh/make/automake/Debian utility toolkit)
On 17/12/11 15:29, David Prévot wrote: Le 17/12/2011 08:59, Reinhard Tartler a écrit : On Sa, Dez 17, 2011 at 12:35:15 (CET), Philip Ashmore wrote: Long description: utility C/C++ include files libv3c - a C/C++ library v3c - a utility program meant to be used in scripts or from the command line makefile includes - see v3c's client projects "makefile" for examples automake/aclocal m4 macros - see v3c's client projects for examples This description fails to explain what this package is intended for and how it relates and is better to alternatives in Debian. After reading the package description, the reader should be able to decide if the package satisfies the user's requirements. cf. http://mdcc.cx/debian/descriptions.html and many other guidelines on the internet. Please prefer the up to date developers' reference: http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices#bpp-desc-basics www.debian.org/doc/manuals/developers-reference/best-pkging-practices#bpp-pkg-synopsis www.debian.org/doc/manuals/developers-reference/best-pkging-practices#bpp-pkg-desc Regards David package_description: automake wrapper + utility toolkit package_long_description: Highlights: = "make" wrapper = make - configures + builds the package (debug mode by default - see below) make dist - builds a distribution tar ball make check - runs the packages automake checks make distcheck - builds a distribution tar ball, installs and "make check"s it make install - installs the package - may require elevated (root) privileges . = GIT version control = make git branch=master - build the "master" branch make git tag=test1.2.3 - build the branch locally tagged as "test1.2.3" . = Debian/Ubuntu packages = make debian - runs "make distcheck", then builds Debian/Ubuntu packages . = build modes = You can choose several configurations using "build modes" - "debug" and "release" are available by default, and "debug" is the default build mode. make debian (optimizations off unless "release" was the last build mode used) make release debian (optimizations on) make git tag=new2 debug distcheck The build system remembers your last build mode, so make release ...tests+edits make (uses the last build mode - release in this case) ...tests+edits make debug ...tests+edits make install ...tests+edits make uninstall This gives you a relatively quick turnaround for testing/debugging. . = libv3c = - a C/C++ utility library . = doxygen documentation integration = make doxygen-doc - generates html documentation from the packages source files make install-doxygen-doc - installs it . = v3c = - a utility program for use in scripts or the command line The "v3c" build system uses this extensively. . = lots of examples/tests = Run "make check" to see more. Please let me know what you think. Regards, Philip Ashmore -- 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/4eed38bd.9070...@philipashmore.com
Re: Bug#652423: Acknowledgement (ITP: v3c -- C/C++/sh/make/automake/Debian utility toolkit)
On 18/12/11 01:30, David Prévot wrote: Le 17/12/2011 20:50, Philip Ashmore a écrit : On 17/12/11 15:29, David Prévot wrote: Please prefer the up to date developers' reference: http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices#bpp-desc-basics […] Please let me know what you think. Quote from the previous URL: “If you are having problems writing your description, you may wish to send it along to and request feedback.” Regards David Hmm. I'm a native English speaker although being from Ireland the odd twang may creep in. I read the "best packaging practices link" above but I couldn't figure out how to add formatting to the long description. Is that where you think I need help? Otherwise, if your issue is with me asking for a review of the packages long description, martin f krafft complained about the lack of long descriptions for my ITPs, which I duly addressed. Then Reinhard Tartler had legitimate issues that I addressed with the updated long description. If no one has any more issues with the new long description then I'll assume all is well. Regards, Philip Ashmore -- 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/4eed9796.7030...@philipashmore.com
Re: Bug#652423: Acknowledgement (ITP: v3c -- C/C++/sh/make/automake/Debian utility toolkit)
On 18/12/11 08:35, martin f krafft wrote: also sprach Philip Ashmore [2011.12.18.0834 +0100]: If no one has any more issues with the new long description then I'll assume all is well. Hello Philip, a long description is neither a text of marketing, nor should it be a complete list of features. The former can go on a website, the latter should be found in a README file. The long description should preemptively provide a user with enough information so that s/he can make a choice. It should be written with complete sentences in free text, with an informative, objective style. A rough guidelines of questions to be answered across three paragraphs could be: 1. What is the general purpose of the software in this package, or the collection of software that this package belongs to? 2. What distinguishes this software from other software? For what use cases was the software designed? 3. How does this package fit in into a collection (unless it's a single package)? Are there any other noteworthy things that the user might need to know to decide for or against a piece of software? Being too familiar with a package sometimes has it's drawbacks. Here's my revised long description, based on your feedback - thanks! v3c is a wrapper package that provides a standard means of interacting with packages by providing "boilerplate" code, programs and scripts, and allowing you to manipulate a package through "make" targets, such as . make check make dist make distcheck make git branch=1.3.5 release debian make install make distclean . Among its capabilities are doxygen documentation integration, Git version control integration, configurable build modes (for debug and release builds, for example), and the ability to specify most configurable options in the top-level makefile. It also provides a C++ class library for use in client projects. Run "make check" to see test/example C++ programs that use it. . See treedb, meta-treedb, v3c-dcom and v3c-qt as examples of projects that use the v3c build framework. Regards, Philip Ashmore -- 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/4eedb545.7010...@philipashmore.com
Re: ITP: v3c-qt -- v3c/automake wrapper for Qt4 (was ITP: v3c-qt -- v3c/automake wrapper for QT)
retitle 652433 ITP: v3c-qt -- v3c/automake wrapper for Qt4 thanks Done! Regards, Philip Ashmore -- 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/4eedbc1c.90...@philipashmore.com
Re: Bug#652423: Acknowledgement (ITP: v3c -- C/C++/sh/make/automake/Debian utility toolkit)
On 18/12/11 10:34, martin f krafft wrote: also sprach Philip Ashmore [2011.12.18.1041 +0100]: Being too familiar with a package sometimes has it's drawbacks. Absolutely. Thank you for your patience! v3c is a wrapper package that provides a standard means of interacting with packages by providing "boilerplate" code, programs and scripts, and allowing you to manipulate a package through "make" targets, such as . make check make dist make distcheck make git branch=1.3.5 release debian make install make distclean How about: v3c is a build framework that ties in with GNU make, providing "boilerplate" code for the most common use cases of building software. I'd say that's enough, no need to enumerate example targets. Among its capabilities are doxygen documentation integration, Git version control integration, configurable build modes (for debug and release builds, for example), and the ability to specify most configurable options in the top-level makefile. Good! It also provides a C++ class library for use in client projects. Run "make check" to see test/example C++ programs that use it. Why would I want to use build framework from within C++? Maybe you can try to answer this question. The C/C++ library is just another goodie in the goodie-bag. It would help provide C/C++ developers with most everything they would need to start out with packages, using the v3c tests/examples as starting points. I'm not a huge automake fan, but until something much better comes along, it's widely used, so here we are. The note about "make check" should go into the README file, IMHO. See treedb, meta-treedb, v3c-dcom and v3c-qt as examples of projects that use the v3c build framework. Ok. I am still somewhat confused why the project v3c-dcom and v3c-qt carry the name of the build framework in the package names, but I suppose I would look at those packages' descriptions to find out more. It was either that or name them "dcom", "qt" etc. I've seen a few others like them. Treedb and meta-treedb escaped this because they're unique already. Also, v3c is an easy-to-type, easy-to-read C++ name space. I'm not on a branding exercise, it just seemed like the thing to do. Cheers, So how's this? v3c is a build framework that ties in with GNU make, providing "boilerplate" code for the most common use cases of building software. . Among its capabilities are doxygen documentation integration, Git version control integration, configurable build modes (for debug and release builds, for example), and the ability to specify most configurable options in the top-level makefile. It also provides a general purpose C++ class library for use in client projects. . See treedb, meta-treedb, v3c-dcom and v3c-qt as examples of projects that use the v3c build framework. Regards, Philip Ashmore -- 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/4eedf20b.4020...@philipashmore.com
Re: Bug#652432: Acknowledgement (ITP: v3c-dcom -- Baby steps to DCOM)
On 18/12/11 20:50, John D. Hendrickson and Sara Darnell wrote: DCOM's package description. DCOM's danger. I studied Microsoft's DCOM. It's a lesser hack of Sun Java technology (which Microsoft patently attempted to steal, hide, and destroy). Object interfacing. (ie, apple's corba) It came out predictably much later than Java. You forgot to mention DCE. While I think it's great to provide support or alternates for PATENDED material like DCOM. Surely it was allot of work I appreciate that. It's being used in Samba on Linux now. Not forgetting Wine. I think it's misleading to sweepingly say "virtually unlimited configuration and customization. What isn't? "Users and client programs can even create sandboxes on the fly" "for use with linux Makefiles." (how is dcom related to unix Makefiles again ??) The package provides a plug-in system. Each plug-in file contains two dictionaries, one mapping ProdIDs to GUIDS and another mapping GUIDS to plug-in filenames. I don't recall saying "for use with linux Makefiles.", please include the relevant text. Who knows a DCOM copy cat would probably bring yet another Microsoft lawsuit toward linux. Microsoft has often stole the X of Xerox Windows (ie, X-box which did not use any X technology, while sony ps3 does or did). That DOESN'T mean microsoft won't try to sue if it's the other way around. Doesn't anyone remember "lindows"? Wishing to make computing ubiquitous? That linux team got sued and LOST in court. Remember anyone? Qt provides a plug-in system but it's system-wide and shared between programs and users. v3c-dcom provides the same system but inside a file, and programs and users can choose to share them by specifying their path in an environment variable. There's not much to v3c-dcom, and it really could become part of a boot loader. What I mean is: "Baby steps toward DCOM?" Yea. But is this baby a 500lb Gorilla baby? It's SURELY against Debian Rules to write incorrect package descriptions. DCOM doesn't provide sandboxes. v3c-dcom provides a library to allow anyone to create a sandbox - it's a file. Description: see Microsoft for copyright material on DCOM's purpose, function, form, and compatibility. repeating it out of band could be infringement. Again, Samba, Wine. I'm sorry. Microsoft "paid to make it" (or said they did) and they don't wish to share it, am I not completely correct? Then there's ATL - the C++ wrapper. I deliberately limited myself to the contents of "Inside ATL" Copyright© 1999 by George Shepherd, Brad King, ISBN 1-57231-858-9. Yes, it states that "No part of the contents of this book may be reproduced or transmitted in any form or by any means without the written permission of the publisher." and that's Microsoft Press. If you think about it, I broke copyright right there, by telling you how I broke copyright! There is an aspect of copyright law that allows people to discuss and communicate their opinions on published works, by making reference to them, and their contents. Oh and, by the way, you can't reference anything you read in this email. Hell, you can't even read it. We're all free to voice legal-sounding mumbo-jumbo that will never see a court room. Here in Ireland there's a company called UPC and they state in some legaleze document I read somewhere, something along the lines of "non-UPC equipment cannot be connected to the UPC TV outlet". How about a TV then? Believe it or not there are libraries for sale that you have to sign a non-disclosure agreement for before you can even read the documentation. And they don't have snippet galleries, discussion forums, help groups learning centres that are two clicks away from a web search. I think that's called due diligence, but I'm not at liberty to discuss it. There comes a point when discussions reference other discussions and the subject matter becomes so widely discussed on the web that it enters the public domain, and someone who hasn't bought or read about the subject from a privileged source can become quite knowledgeable about it. And so to the crux of the matter, I wrote v3c-dcom firstly because I think it's a really neat plug-in system. I used Microsoft's naming scheme as it may be familiar with some software developers. I could change all the names by adding an "idily" at the end - CoCreateInstanceExIdily() - would that be OK? Then someone would publish a header file to #define them back so they could compile their code on Windows and Linux. If you like, I can change the projects name to "v3c-dcomidily". I hope you're getting the point by now. That's life I'm not saying I like it
history transparency
Hi there. Looking at advances in storage that are on the horizon coupled with advances with processing power, it would appear that "something wonderful" is on the horizon. It will be possible to build an entire Debian distribution in a matter of minutes. This capability requires no changes to the way Debian "does things" right now. But when it comes to old bug reports involving source packages in GIT or other version control systems, it's already the case that older C/C++ code won't compile due to advances and increasing strictness in compilers. Right now it's difficult/impossible to recreate a snapshot of Debian as it was (updates included) when the bug was reported. I think Debian needs a way to be able to pick a point in history and obtain at least the versions + patches of all the source packages that would have been installed / available to reproduce the Debian system running on the users machine at the time they reported the bug. With more and more source packages becoming available under publicly accessible version control, what needs to change in Debian to make this possible? Regards, Philip Ashmore -- 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/4f3387b6.10...@philipashmore.com
Re: history transparency
On 09/02/12 09:00, Adam D. Barratt wrote: On 09.02.2012 08:45, Philip Ashmore wrote: Right now it's difficult/impossible to recreate a snapshot of Debian as it was (updates included) when the bug was reported. I think Debian needs a way to be able to pick a point in history and obtain at least the versions + patches of all the source packages that would have been installed / available to reproduce the Debian system running on the users machine at the time they reported the bug. Like http://snapshot.debian.org/ , for instance? Regards, Adam Never heard of it, or if I did, I didn't understand its significance - thanks! I guess the next thing to roll out in the future will be virtual machines representing Debians target architectures running acceptance tests on the snapshots before publication. Regards, Philip Ashmore -- 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/4f339079.3060...@philipashmore.com
Re: On init in Debian
On 16/03/12 21:44, Philip Hands wrote:
On Fri, 16 Mar 2012 20:05:25 +0100, Andreas
Metzler wrote:
Philip Hands wrote:
On Fri, 16 Mar 2012 14:37:39 +0100, Vincent Danjean wrote:
[...]
* We could try to define a file format that allow a conversion (by a
separate specific tool or at runtime) to various init systems.
This would avoid to be blocked by the syntax/features of one "source"
init system.
This was mentioned in the thread (I forget by whom) and strikes me as
the only viable strategy, in that this is the only way that the various
factions can all collaborate on making a workable solution, rather than
fighting for theirs to be The One True Init.
[...]
I am not sure this actually is a big improvement, we might end up with
* either being limited to the common featureset
* or doing something like
#ifdef systemd
elseif upstart
...
which is almost as bad as having to ship both init-scripts and systemd
configuration file.
If we were going to end up with anything like that, then it would be no
improvement at all, and would not be worth wasting any effort on.
I was presuming (perhaps wrongly) that it would be possible to come up
with a high level specification of what a daemon provides, what it needs
to happen in order to run, what needs to be done to provoke it to reread
its settings, how one runs it in the foreground, and in the background
(either of which might be missing) etc. etc. etc
And then, given that lot, write a generic init.d script that can take
that as input and do something useful with it, but likewise, process it
into appropriate configs for both systemd and upstart.
Of course, I don't know enough about either systemd or upstart to know
how feasible such an approach might be, but if it is feasible it would
almost certainly eliminate some of the repeated bugs in sysinit at least,
and perhaps be helpful in the same way for the other two.
On the other hand, the xkcd cartoon is depressingly true, so perhaps we
should forget that idea -- I was rather hoping that it doesn't quite
apply here though, since we'd not be trying to write yet another init,
but just describe the configuration data needed by all init type things.
Cheers, Phil.
I'm writing a system that can accept the following:
program
( name("hello-world")
, contents
( sys-include("stdio.h")
, function
( name("main")
, returns("int")
, parameters
( parameter(name("argc"), type("int"))
, parameter(name("argv"), type(array(pointer("char"
)
, body
( call("printf", "Hello, world!\n")
, return(0)
)
)
)
)
and parse it into a binary form.
With this I can use a c/c++ generator program to produce
#include
int main(int argc, char *argv[])
{
printf("Hello, world!\n");
return 0;
}
Would something like this help here?
Regards,
Philip Ashmore
--
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/4f63d2a1.1040...@philipashmore.com
Re: Mandatory -dbg packages
On 27/10/12 19:30, Michael Biebl wrote: On 27.10.2012 12:25, Vincent Bernat wrote: Hi! Libraries with `-dbg` package are a pain to deal with when debugging some problem. The solution to ask each user to rebuild the library without stripping debug symbols[1] seem suboptimal. Asking each maintainer to ship a `-dbg` package may be a solution[2] but couldn't we generate those packages automatically by the builders, like this is done with Ubuntu[3]? I remember we had a discussion about this a few years ago. An automatic service has been setup for this[4] by myon but it does not seem to be updated anymore. Why does this experiment have been stopped? Could we mainstream it? Afaik the work was started by pochu as port of GSoC [1][2]. According to [3], Marc was his mentor. I've CCed both, maybe they can comment on what's still missing. I'd love to see that happen. Yeah, in (cough)Fedora, kdbg even offers to download and install debug packages for you. Debug packages also make back-traces more than useless, and (cough)Ubuntu offers to download debug packages which it installs and re-examines the back-trace to see if more are needed. Having the sources installed in /usr/src and referenced there rather than /buildd would be an improvement too. If there's a way to re-path debug information from /home/user/x or /buildd to /usr/src then that would be great. One less reason for Debians build process to need a fake root. Michael [1] http://wiki.debian.org/EmilioPozueloMonfort/GSoC2009Ddebs [2] http://wiki.debian.org/AutomaticDebugPackages [3] http://wiki.debian.org/SummerOfCode2009#Automatic_Debug_Packages_Creation_and_Handling Philip -- 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/508ce6cd.4000...@philipashmore.com
Re: Mandatory -dbg packages
On 28/10/12 16:09, Wouter Verhelst wrote: On Sun, Oct 28, 2012 at 08:03:25AM +, Philip Ashmore wrote: Having the sources installed in /usr/src and referenced there rather than /buildd would be an improvement too. That's why there is the 'substitute-path' feature in gdb to fix that. Also see http://grep.be/blog/en/computer/code/gdb_substitute_path While this feature allows gdb to know the correct source locations, using it implies that packages requiring the feature contain incorrect source paths - wouldn't it be better for these packages to contain correct source paths in the first place? Regards, Philip -- 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/508dd2c3.9090...@philipashmore.com
Re: Mandatory -dbg packages
On 29/10/12 07:25, Neil Williams wrote: On Mon, 29 Oct 2012 08:53:05 +0800 Paul Wise wrote: On Mon, Oct 29, 2012 at 8:50 AM, Philip Ashmore wrote: While this feature allows gdb to know the correct source locations, using it implies that packages requiring the feature contain incorrect source paths - wouldn't it be better for these packages to contain correct source paths in the first place? There is no such thing as a "correct source path", I unpack source tarballs to ~/tmp/ when debugging, you seem to use /usr/src/ and John Doe uses ~/src/debian/pool/f/foo/foo-0.1/. The "correct source path" for gdb is whatever the user has put into ~/.gdbinit - the paths inside the package don't matter. dir /path/one/ dir /path/another/ In Fedora, the dbg package includes the source code for the package, and the debug information points to it. In Fedora, by convention, such source code goes under /usr/src. If you prefer your users mess with .gdbinit so they can create a useful stack trace then that's up to you. Philip -- 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/508e5ef8.6010...@philipashmore.com
Re: Where could I upload x32 port bootstrap?
On 10/11/12 16:10, Peter Samuelson wrote: On Sat, Nov 10, 2012 at 10:47:43AM +0100, Adam Borowski wrote: On the other hand, widespread dumb-ass assumptions about i386/amd64 may cause quite a bit of issues: basically any Makefile that talks about "x86" is somewhat suspicious. This is the main reason one may want to oppose the inclusion of x32 in Debian, IMHO. [Andrey Rahmatullin] Can you elaborate? [Henrique de Moraes Holschuh] This is no worse than any other new arch. The new wrinkle is that, because x32 uses the x86-64 instruction set, it defines preprocessor symbols associated with x86-64, and which a lot of source code uses to differentiate between i386 and amd64. Thus, code which cares about long and pointer size may well misdetect them on x32. From the revised AMD64 ABI Draft, chapter 7, page 105 (linked from https://sites.google.com/site/x32abi/documents): Table 7.1: Predefined Pre-Processor Symbols __amd64 Defined for both LP64 and ILP32 programming models. __amd64__ Defined for both LP64 and ILP32 programming models. __x86_64 Defined for both LP64 and ILP32 programming models. __x86_64__Defined for both LP64 and ILP32 programming models. _LP64 Defined for LP64 programming model. __LP64__ Defined for LP64 programming model. _ILP32Defined for ILP32 programming model. __ILP32__ Defined for ILP32 programming model. Note that "LP64" means "longs and pointers are 64-bit", our existing amd64 port. "ILP32" means "int, long, pointer all 32-bit", or x32. Peter Apologies in advance that this is off-topic or just a silly question. If I want my C source code to build correctly on x32, how do I choose the correct printf format strings for int32_t, int64_t etc? Regards, Philip Ashmore -- 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/509e7f4a.1020...@philipashmore.com
A common configuration format, anyone?
Hi there.
As someone who develops software for Debian I encounter situations where
I have to specify the same information multiple times, and when that
information changes I have to remember to update it in each of these places.
Just now I had to add a debian/*doc.postrm.in to one of my projects.
Makefile.am - save the *in file in EXTRA_DIST
configure.ac - convert the *.in to a *.
Git - add to version control.
makefile - new version
NEWS - what's changed
ChangeLog - what's changed
Git - store the changes
As a C++ developer it can get much worse and the opportunity for
mistakes to happen increase proportionately.
This is from someone who uses the compiler to check my syntax.
Each of these processes provides a way to verify your input but it's not
the right place to properly address the issue.
I'm proposing a means to capture these work-flows by storing the
information in one place and providing mechanisms for doing
project-level semantic validation and change management.
I've already got a format - a text file that has a binary representation.
You can take a look at the sb/tests directory to see "Hello world!"
printed out using several different approaches to inspect the same data.
program
( attributes
( id([bd64d1f6-a1f8-45bf-9f65-ce0842eda6d7])
)
, name("hello-world")
, contents
( puts
( type(function-prototype)
, returns(int)
, parameters
( str(type(pointer(const(char
)
)
, main
( type(function)
, returns(int)
, parameters
( argc(type(int))
, argv(type(array(pointer(char
)
, body
( puts("Hello, world!")
, return(0)
)
)
)
)
I realise that asking all developers to change their configuration
format is ridiculous, but I ask it anyway.
Specifying content in a way that's easy to inspect transform and verify
should be a corner-stone of software development but it seems to be one
of those things that "was like that when I got here".
Anyway, I'm going to keep with it and see how deep this rabbit-hole goes.
Regards,
Philip Ashmore
--
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/50a32f87.2040...@philipashmore.com
Re: A common configuration format, anyone?
That "sb/tests" directory is in my v3c-storyboard project http://sourceforge.net/projects/v3c-storyboard/ Philip -- 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/50a33065.8060...@philipashmore.com
Re: A common configuration format, anyone?
On 14/11/12 06:48, Chow Loong Jin wrote: On 14/11/2012 13:43, Philip Ashmore wrote: Hi there. As someone who develops software for Debian I encounter situations where I have to specify the same information multiple times, and when that information changes I have to remember to update it in each of these places. Just now I had to add a debian/*doc.postrm.in to one of my projects. Makefile.am - save the *in file in EXTRA_DIST configure.ac - convert the *.in to a *. Why are you generating debian/* files from within the upstream build system? That's just wrong. Packaging is packaging. Upstream matter is upstream matter. Also, you don't need to add the file into EXTRA_DIST if you've already added it using AC_CONFIG_FILES -- autotools does that automatically. Now that's the kind of thing that semantic validation/constraints that I'm talking about. If Debian had a wizard where you could go to "add pre-processing file" it would eliminate such typos. Git - add to version control. Ack. makefile - new version If you generate your upstream tarball with autogen/make dist, you should never have this issue. The build system I've developed has a top-level "makefile" that stores the version, short and long descriptions. It's easy to communicate using terms one is familiar with and forget about transposition and assumed knowledge. NEWS - what's changed ChangeLog - what's changed Autogenerate this from git log. Some upstreams don't bother with this, even. I must look into this sometime. Glad to know. Git - store the changes Ack. As you can see, you're uselessly repeating steps that can already be automatically done today, in addition to doing it just plain wrong (re: Makefile.am/configure.ac) [...] That aside, I have nfc how to interpret your proposed text file thing, but GNOME has something similar, called DOAP files[1], which albeit in XML format, are more readable than yours. It's a simple format which, like xml, is human-readable but that's just a plus - us humans prefer to interact with the content efficiently rather than be bogged down in the representation. I plan to use the format to allow more expressive graphical representations to be developed. Plus, the binary form can be transformed using the "sbd" tool/example packaged with v3c-storyboard, but these are all baby steps to being able to develop interfaces with it that can interact with the "real world" and transform content - including (different versions of) themselves. This format can be interpreted using libffi to define closures - interpreted functions, as the sb/tests/hello-world4-test program shows. Then those functions can be transformed into executable code using LLVM as the hello-world3-test program shows, so I hope it will be easier to do rapid prototyping with than html5/JavaScript, because you use one visual representation to modify something elses visual representation, which could be anything. (And finally, like Ben said, please don't ask anyone to package anything in this format.) [1] https://live.gnome.org/MaintainersCorner#maintainers I wasn't thinking of asking anyone to package software in this format - sorry if I gave that impression. The packaging tools used by Debian and others have a steep learning curve because their representation isn't human-friendly - it's all for the convenience of a build system dating back to UNIX. I'm talking about a graphical interface that generates these files so that developers never have to look at them. In my opinion anything written in (ba)sh or m4 is just asking for a typo to do the unexpected, which is a fundamental flaw of textual representation. My goal is to narrow the grand canyon of a gap between how graphical interfaces do such a great job of hiding the details, to the way we develop them, which is all about the details. Whether I achieve anything like that is another matter, but I don't see any huge obstacles in my way. The idea is to have a Debian/Fedora/AnOther "portal" where you're basically hand-held at every step in the process if doing whatever you want to, from system configuration to developing packages. The other approach, the one that was there since before GUIs, is the mailing list. Regards, Philip Ashmore -- 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/50a38000.5010...@philipashmore.com
Re: A common configuration format, anyone?
On 14/11/12 16:52, Dominique Dumont wrote: On Wednesday 14 November 2012 12:26:56 Philip Ashmore wrote: The packaging tools used by Debian and others have a steep learning curve because their representation isn't human-friendly - it's all for the convenience of a build system dating back to UNIX. I'm talking about a graphical interface that generates these files so that developers never have to look at them. Hmm, that sounds like 'cme edit dpkg' (provided by libconfig-model-dpkg-perl). For more details, see [1]. HTH [1] https://github.com/dod38fr/config-model/wiki/Using-config-model#wiki-Debian_packaging Except that the system I'm working on could also implement the GIT api, the APT package database, and be controlled by a text user interface (TUI) as well as the command line or a GUI. Come to think of it, Debian does have a portal to all things Debian - the world wide web. Regards, Philip -- 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/50a40d7c.5040...@philipashmore.com
Re: A common configuration format, anyone?
On 15/11/12 00:15, Dmitrijs Ledkovs wrote: On 14 November 2012 15:31, Benjamin Drung wrote: Am Mittwoch, den 14.11.2012, 15:32 +0400 schrieb Игорь Пашев: 2012/11/14 Philip Ashmore simple format which, like xml, is human-readable XML is not human-readable :-) XML is human-readable, but in most cases ugly to write. IMO XML is not human-writable. Also XML is not "diff-able" easily, which is usual for tree-like structures. In XML defence, at least it's not "write once" / "write only" format the way perl is ;-) Regards, Dmitrijs. It's possible to paint a picture a pixel at a time too ;) Philip -- 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/50a44341.3030...@philipashmore.com
Re: A common configuration format, anyone?
On 15/11/12 10:18, Dmitrijs Ledkovs wrote: On 15 November 2012 08:38, Vincent Lefevre wrote: On 2012-11-15 00:15:06 +, Dmitrijs Ledkovs wrote: Also XML is not "diff-able" easily, which is usual for tree-like structures. If you mean diff-able for the human, then it depends on the complexity of the data. I have no problems with mine. wdiff can help. But what I really like with XML is the validation (in some standard way) via schemas (for config files, where an error can be critical, this is quite important), and the fact that there's no ambiguity on the charset. How about YAML?! Yeah, I took a look at that and it's got some neat ideas, but it targets modelling, where mine targets content. The v3c-storyboard test/examples show how you can overlay semantic validation - test2 even allows you to specify a bison grammar for this. Where sbd wins over YAML in terms of format is that it's a binary representation that can be walked any way you like and is in-place-editable. You can generate sbd (the binary format) from sbt files (the text format), and sometimes I still find a text editor handier for some things, then drag-drop the result into sb-designer to insert it into an sbd. Regards, Dmitrijs. Philip -- 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/50a56f83.5080...@philipashmore.com
Re: release goal for jessie! (Source-only uploads
On 25/11/12 00:00, Thorsten Glaser wrote: Thomas Goirand debian.org> writes: Though I'm in the favor of dropping binaries rather than source-only, This could even help the cases of packages that need itself to be built. When a packager does a source+binary upload of foo (= 1.2-1), it would be built in a clean, minimal chroot (yes, I’m adding the minimal here, with several side-stabs…) whose sources.list would contain unstable, and experimental for packages targetting that, as right now, plus ANOTHER, NEW repository, which is created by buildd “on the fly”, which contains the binaries that the packager uploaded, but is marked to never be used automatically just like experimental, so the binaries by the packager *CAN* be used to build the binaries that will make it into the archive, but *only* if the packager explicitly states it, here by doing a B-D on foo (>= 1.2-1), or even foo (>= 1.2) would work in this case. That one-package APT repo and its content would then be dropped afterwards, never to be seen again, no matter whether the build succeeded or not. bye, //mirabilos If you need binaries from a package in its build process then you use the ones in the build tree in preference to any that might be installed. It's just a shame that automake can't use LD_LIBRARY_PATH to prefer shared libraries from the build tree in the same way. Regards, Philip -- 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/50b1bb8c.30...@philipashmore.com
Re: history transparency
On 09/02/12 08:58, Paul Wise wrote: On Thu, Feb 9, 2012 at 4:45 PM, Philip Ashmore wrote: I think Debian needs a way to be able to pick a point in history and obtain at least the versions + patches of all the source packages that would have been installed / available to reproduce the Debian system running on the users machine at the time they reported the bug. With more and more source packages becoming available under publicly accessible version control, what needs to change in Debian to make this possible? Nothing, it already exists: http://snapshot.debian.org/archive/debian/20091229T215155Z/ How do I work out which snapshot I have installed now? I download from Sid. Is there a micro-version file that stores this information or is it a time stamp on some file? Regards, Philip -- 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/514271a5.7010...@philipashmore.com
Re: history transparency
On 15/03/13 02:19, Dmitrijs Ledkovs wrote: On 15 March 2013 00:56, Philip Ashmore wrote: On 09/02/12 08:58, Paul Wise wrote: On Thu, Feb 9, 2012 at 4:45 PM, Philip Ashmore wrote: I think Debian needs a way to be able to pick a point in history and obtain at least the versions + patches of all the source packages that would have been installed / available to reproduce the Debian system running on the users machine at the time they reported the bug. With more and more source packages becoming available under publicly accessible version control, what needs to change in Debian to make this possible? Nothing, it already exists: http://snapshot.debian.org/archive/debian/20091229T215155Z/ How do I work out which snapshot I have installed now? I download from Sid. Take the checksum of Packages from /var/lib/apt/lists and find a matching one on snapshots. Is there a web interface for that, or a script that can do this? It will be close, but not everything. A better way is to use apt-clone which will generate a more comprehensive state tarball. Is there a micro-version file that stores this information or is it a time stamp on some file? How would that help at all? Given that it will never know the set of packages you have installed, or obsolete packages not-removed, modified conffiles etc. I get you, but I'm talking from a pbuilder or similar perspective. If I run into a problem and a week later it's gone it would be nice to be able to tell what packages changed. Backing up /var/lib/apt/lists would do it but then you would start backing it up all over the place, that's why a micro-version number would be better, just increment it every time new packages appear in snapshots. It it were in its own file or available from lsb_release or similar then even better. Regards, Dmitrijs. Cheers. -- 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/5142a111.4020...@philipashmore.com
Fwd: Re: Where does the update-initramfs hook get the kernel name from?
Better late than never ;) Original Message Subject: Re: Where does the update-initramfs hook get the kernel name from? Date: Wed, 01 Jun 2011 03:13:03 +0100 From: Philip Ashmore To: Philip Ashmore According to the docs you mentioned, the script gets supplied the kernel version from "uname -r". The output I get is "2.6.32-5-amd64", not "26.32.5-amd64.squeeze" as you see above, so the documentation must be wrong. Philip I finally went ahead and did an "apt-get source initramfs-tools" to check this out after upgrading to Wheezy. The postinstall hook was calling "update-initramfs -u" This script looks in $STATEDIR which is /var/lib/initramfs-tools by default, for versions to sort so it can get the latest one. The problem was that if you create a few flavours yourself, delete them in /boot and don't know about $STATEDIR then "update-initramfs -u" will forever more tell you about non-existent versions. The solution in this case is to delete the checksum files in $STATEDIR that match the ones you already deleted in /boot. The correct procedure is to "update-initramfs -k some-version -d". There should probably be a Debian web page to store solutions to problems like this. Regards, Philip -- 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/51475bcf.4020...@philipashmore.com
Fair comment
Hi there. Last year some time I contacted Microsoft Press about their book, Inside ATL MSPRESS Inside ATL ISBN 1-57231-858-9. It was one of their web-form thingies and I wasn't sent an email copy of the message. Basically I stated that my SourceForge package, http://sourceforge.net/projects/v3c-dcom/ used parts of the book to implement just enough of dcom to allow developers to write any kind of plugin-system, through which the in-process servers can be queried for the interfaces they implement with QueryInterface. It's been quite a while without feedback, but that leaves me in Limbo. I'm sure this situation isn't unique to me, so here are the questions 1. Is there anyone at Microsoft who reads this mailing list who can comment on my particular situation. 2. The Oracle vs Google Android court case basically said that "you can't own an interface". If that's true, then does it mean I'm not in Limbo after all? 3. Given that (d)com has its roots in DCE, which has its roots in RPC, should I be worried? Or, putting it another way, should those wishing to develop software based on v3c-dcom be worried? I know this only has a glancing relevance to the development of Debian, but if the coast is clear I plan to make it a lot easier to develop packages for Debian that will use my SourceForge projects, and these may well provide superior alternatives to those already in Debian. For example, if you wanted to to configure a router, wouldn't it be better if you could see how it configuration reacts to the standard DDOS attack vectors via visual simulation instead of needing to be a networking expert (which is actually not a guarantee of a DDOS-resilient networking setup)? Regards, Philip Ashmore -- 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/5156b03d.1010...@philipashmore.com
Re: Bug#750576: ITP: debdry -- Semi-assisted automatic Debian packaging
Hi there. On 04/06/14 18:33, Enrico Zini wrote: > On Wed, Jun 04, 2014 at 06:18:01PM +0100, Enrico Zini wrote: > >> In the meantime I'd like to use it for my packages, because frankly, >> I'm bored of writing everything twice. > > Also, debdry is the first package that I have written that takes care of > its own packaging :) > > > Ciao, > > Enrico > I've been doing this for a while now with my v3c package: http://sourceforge.net/projects/v3c/ I haven't (recently) tried to have it accepted into Debian as it uses automake, which I want to move away from, although it's getting better. It uses a top level make file to build various targets, including targets for other versions stored in the projects git repository. You can build for Debian or Ubuntu, but the thing I like most is the ability to do quick installs/uninstalls before taking the scenic route of building a package first, and with "make -j9" it's fast! Do please take a look, there may be some ideas you can use. Regards, Philip Ashmore -- 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/538ff3fa.1050...@philipashmore.com
Re: Static libraries in development packages
Hi there. Nobody thought to mention that static linking can dramatically increase performance, or to put it the other way around, dynamic linking can incur serious runtime penalties. I don't want to encourage everyone to start static linking everywhere just to get a few percentage points in efficiency, obviously your mileage may vary, but basically my treedb project got 100 times faster and meta-treedb got at least 20 times faster, through static linking on x86_64. You can get these from SourceForge. These do little more than function calls and memory access through memory maps, so maybe they're unusual in this respect. I've yet to upload the versions (including v3c) that build static libraries and the static tests, but I thought it was worth mentioning. Philip -- 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/4daa0912.6070...@philipashmore.com
Re: Conditional Recommends
On 21/05/11 12:24, Josselin Mouette wrote: Therefore, I’m wondering whether it would be possible to extend the syntax of Recommends to allow for conditional dependencies. For example, IANADD, however... In database terms you're talking about a separate table that stores N:N relationships, so why store the information in either package? It would be better from a data-processing perspective to store this information in another package, as this would allow for arbitrary constraints and brings in the whole concept of actions (such as package installs) once prerequisite-triggers fire. This "package" wouldn't even need to be the "a.plugin-b" package, if there are many such packages. Philip -- 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/4dd99865.9070...@philipashmore.com
openvg.h not found
Hi there. While trying to build QT 4.8.0 technology preview I had occasion to search for openvg.h. According to http://packages.debian.org/search?suite=wheezy§ion=all&arch=amd64&searchon=contents&keywords=openvg.h it's not in Wheezy/amd64, and yet there it is in libopenvg1-mesa-dev. Is there some button that someone needs to press to update the Debian package search web site? Philip -- 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/4ded4cf7.5010...@philipashmore.com
Recent upgrade problems
Hi there. I ran synaptic and it did the following (from /var/log/apt/history.log) Start-Date: 2011-08-15 03:06:42 Commandline: synaptic Install: xulrunner-5.0:amd64 (5.0-6, automatic), libmozjs5d:amd64 (5.0-6, automatic) Upgrade: python-coherence:amd64 (0.6.6.2-5, 0.6.6.2-6), openprinting-ppds:amd64 (20110617-1, 20110803-1), python-debian:amd64 (0.1.20, 0.1.21), uuid-runtime:amd64 (2.19.1-4, 2.19.1-5), libmount1:amd64 (2.19.1-4, 2.19.1-5), libblkid1:amd64 (2.19.1-4, 2.19.1-5), foomatic-db-engine:amd64 (4.0.7-2, 4.0.8-1), libmozjs-dev:amd64 (1.9.1.19-3, 5.0-6), util-linux:amd64 (2.19.1-4, 2.19.1-5), foomatic-filters:amd64 (4.0.7-1, 4.0.9-1), libcpufreq0:amd64 (007-1, 007-2), libfreetype6:amd64 (2.4.4-2, 2.4.6-1), libxfont1:amd64 (1.4.3-2, 1.4.4-1), iceweasel:amd64 (3.5.19-3, 5.0-6), cpufrequtils:amd64 (007-1, 007-2), bsdutils:amd64 (2.19.1-4, 2.19.1-5), libfreetype6-dev:amd64 (2.4.4-2, 2.4.6-1), libmx-1.0-2:amd64 (1.2.0-1, 1.3.0-1), uuid-dev:amd64 (2.19.1-4, 2.19.1-5), libuuid1:amd64 (2.19.1-4, 2.19.1-5), xpdf:amd64 (3.02-19, 3.02-21), foomatic-db:amd64 (20110617-1, 20110803-1), mount:amd64 (2.19.1-4, 2.19.1-5), xulrunner-dev:amd64 (1.9.1.19-3, 5.0-6), freetype2-demos:amd64 (2.4.4-2, 2.4.6-1) End-Date: 2011-08-15 03:09:25 Then I rebooted. I'm using KDE 3.5.12 (trinity). I tried the amarok play global shortcut, but it has stopped working (it worked before the reboot). I wanted to report a bug in iceweasel 5, to see if it could handle my html5 test page http://www.philipashmore.com/timeline/ It fails to comply with the mdc spec regarding adding options to a select group in JavaScript. https://developer.mozilla.org/en/DOM/HTMLSelectElement#add%28%29 I first tried reportbug but that crashed with a memory corruption issue. Also, while I'm at it, I can't open html links in iceweasel, but that's been true for a while. Sorry for dumping this mess in your laps. Regards, Philip -- 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/4e489ca3.8050...@philipashmore.com
Bug#642703: general: Scan lines appear in drop-down menus. LibreOffice also shows artifacts when starting. Might be something to do with the version of fglrx.
Hi there. Do you have swap space enabled? How much memory do you have? I get this problem, including font corruption (one or two characters per font), whenever I run something that causes the system to start using swap space. For me, it seems to happen most to Gnome apps, including Google Chrome. Did you notice excessive hard disk activity when you started the program, I mean, apart from the activity involved in loading the program. Check: try closing other programs first, starting LibreOffice, and see if there's any difference. Regards, Philip -- 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/4e7e6933.3070...@philipashmore.com
100% hardware coverage - is it a realistic goal?
Hi there. Apologies in advance if this issue is already addressed somewhere in the Debian universe. Last night it occurred to me that my specific model of laptop, the Samsung RF711-so7uk, has some hardware features that could use some close attention. Rather than plead to users, developers, Debian etc. to "do the job 100%" I thought a more modest enquiry would be appropriate. How much of the hardware in your machine is directly supported by Debian? As a percentage like "supported/present" I don't know. If there was a package that displayed it then I could try connecting devices to see how that changed and pick the best one. A crude metric for sure, but better than a compass. What then about the "21st century" features: OpenGL, WebGL 1.0/2.0, Wayland...? The Debian version of google-chrome (Chromium) from Jessie supports WebGL 1.0 whereas the direct-from-google version (google-chrome Version 56.0.2924.87 (64-bit)) doesn't support the installed hardware. The installed hardware being (from lspci) - VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) - 3D controller: NVIDIA Corporation GF108M [GeForce GT 540M] (rev ff) - Network controller: Broadcom Corporation BCM4313 802.11bgn Wireless Network Adapter (rev 01) (from lsusb) 148f:7601 Ralink Technology, Corp. I started using the Ralink/Mediatek usb wifi adapter after the Broadcom one had problems. And it took a download from Fedora for the firmware to work: https://bugzilla.redhat.com/show_bug.cgi?id=1264631 I realise that as a community-driven project, gauging how much of your users hardware is supported is a niche topic. Could Debian have an install option to be allowed to query the installed hardware so it can build a database of hardware configurations Debian is installed on, like popcon? Then you would have metrics: how many machines, how many types of each machine, how many instances of each device type, ... You could then tag a bug report with your configuration hash(es) and have a better chance that someone else using the same hardware would be able to help. Possibilities abound! Regards, Philip Ashmore
