[00:01] Oh, ok. [00:22] this is madness, gdebi reports my package as broken, but dpkg installs it without ever complaining [00:23] lintian does not offer any help, everything seems to be fine [00:23] *sigh* [00:24] TomaszD: If dpkg installs it, but gdebi doesn't then I'd call that a bug in gdebi. [00:25] ScottK, I just hacked up the linux-image deb, adding a few drivers, adding md5sums, put it back together, installed it on a test machine using dpkg, works great, gdebi complains [00:26] So complain back. [00:26] ScottK, I'm still not sure if it's my fault [00:26] I didn't update the changelog, for one [00:27] If dpkg understands it, not your fault is a reasonably safe assumption. [00:27] I'll see what lintian says about the original package and then I'll complain [00:28] huh, exactly the same results, it's not my fault then [00:29] Is there anyway to get stats on how many people use a certain package? [00:30] stefanlsd: kinda sorta not really. [00:31] heh. was just wondering how you figure out if a package should be removed [00:31] ok, lol, my fault it is, left a test file that obviously doesn't have an md5 in md5sums :P [00:31] stefanlsd: It's more commonly dead upstream, serious unfixed bugs for a long time, stuff like that, not user base. [00:32] ScottK: mm. ok. Im busy looking at a sync request for diald and there's an upstream version also, but it was last done in 2001 and it hardly compiles without changing stuff [00:33] ScottK: but i see the debian guys for the previous version did change some of the stuff that wasnt changed upstream [00:33] Then you probably want to keep the Debian fixes. [00:47] stefanlsd, debian has opt-in tracking for what's installed, to show how many people use a given package [00:49] directhex: Ubuntu has the same. [00:49] ScottK, so it does. i don't like recommending debianish packages, in case they're not directly applicable [00:50] not searchable though. how annoying === lakin__ is now known as lakin === dmoerner is now known as infinitycircuit [01:25] Would anyone know why this happens in pbuilder when i try build - /usr/bin/install -c -d -m 0755 /etc/pam.d [new line] /usr/bin/install -c -o root -g root -m 0644 config/diald.pam //etc/pam.d/diald [new line] /usr/bin/install: cannot create regular file `//etc/pam.d/diald': Permission denied [01:29] stefanlsd: because your package needs to redirect the upstream build rules to not try to install files in the real root directory [01:30] stefanlsd: it needs to be installing to a subdirectory of your build tree instead, where the installed files can then be gathered back up for packaging [01:32] slangasek: ok. thanks. i see thats happening in the Makefile.in [02:06] hello === zooko is now known as zookofamtime === ember_ is now known as ember [02:37] I want to upload a package to REVU [02:38] I already have my launchpad account and I have setted my pgp key [02:38] this is what is confusing me: dpkg-buildpackage -S -sa -rfakeroot [02:40] What part of that is confusing? [02:41] not sure of what It'll do, I've read the motu wiki, bt still not clear [02:42] the output of that command, is what I have to puload? [02:43] Yes. [02:44] Well, rather, the _source.changes file. [02:44] hello [02:44] i need help on packaging, someone around ? [02:44] gastoni: Specifically, that command will build a source package from the modified local sources. [02:46] my package has this name: conkygui_v12_all.deb [02:46] how do I issue the command, I can't get it to work [02:49] http://pastebin.ubuntu.com/33213/ [02:49] error: [02:49] debian/rules build [02:49] dh_testdir [02:49] # Add here commands to configure the package. [02:49] cp -f /usr/share/misc/config.sub config.sub [02:49] cp -f /usr/share/misc/config.guess config.guess [02:49] ./configure --host=i486-linux-gnu --build=i486-linux-gnu --prefix=/usr --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info CFLAGS="-g -O2" LDFLAGS="-Wl,-z,defs" [02:49] ./configure: 6: Syntax error: "(" unexpected [02:49] make: *** [config.status] Error 2 [02:49] dpkg-buildpackage: failure: debian/rules build gave error exit status 2 [02:49] pbuilder: Failed autobuilding of package [02:50] Can you help me? :-] [02:50] gastoni: How did you create your ,deb file? [02:51] dldc: It looks like you've some syntax error in ./configure. Have you looked there? [02:51] persia: http://pastebin.ubuntu.com/33213/ [02:51] is good [02:52] with the dpkg -b command, http://ubuntuforums.org/showthread.php?t=876537 [02:52] dldc: The problem isn't with debian/rules, it's with ./configure [02:53] gastoni: Ah. I wouldn't start from there :) [02:53] !packaging [02:53] The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports [02:53] gastoni: You might do well to review the packaging guide. That will help you construct a source package (you have a binary package now). REVU only accepts source packages. [02:54] persia http://pastebin.ubuntu.com/33214/ [02:54] awh damn [02:54] persia: so, to build a source package with java, which is the general idea? [02:55] to package the sources with a shell script that will compile them druing installation? [02:55] persia found error? :-[ [02:55] gastoni: Usually one uses ant or something rather than a shell script, and calls it from debian/rules [02:56] wouldn't people need JDK if they want to install my package, then? [02:56] dldc: No, but I suspect it is in the function definition [02:57] gastoni: They would. Your package should Depend on the JDK [02:57] if i put only "./configure" in debian/rules same error :-[ [02:58] dldc: Yes. You need to verify that the function definition works with dash [02:58] but, if i run in my box ./configure work fine [02:58] persia: but a normal user doesn't install JDK, they just use JRE. right? [02:58] persia: wouldn't that be an annoyance for the common user? [02:59] oh no wrong [02:59] same error if i run it in my box [02:59] :-[ [02:59] gastoni: I think http://www.debian.org/doc/manuals/debian-java-faq/ch6.html#s6.5 is roughly what you want (although, yes, there should be a better one) [03:00] gastoni: There are two sorts of packages: source packages and binary packages. [03:00] persia Suggests to solve it ? [03:00] Developers work on source packages, and make the changes there. These source packages are then fed to the buildds, which run sbuild against them to generate binary packages, which are installed on user machines. [03:01] Your source package will need a JDK to build, but your binary package probably only needs a JRE [03:01] damn, packaging is a lot harder than I though [03:02] I'll stick to the binary for while [03:03] gastoni: OK. I'm fairly sure there will be a MOTU School session on Java packaging in the next few months: you may want to watch for that, and try again then. [03:03] AH, perfect [03:03] how can I see/read those sessions? [03:04] anyone here is interested to join me in my project, Conky GUI, as a packager? [03:05] dldc: Looks like dash doesn't support "function". Patching that away might help. === jmarsden_ is now known as jmarsden [03:14] gastoni: See https://wiki.ubuntu.com/MOTU/School for school sessions. Is your package currently build using GNU Autotools? [03:24] GNU autotools?? I just made the control file and dpkg took care of everything else [03:33] gastoni: No, I meant for building the .jar from sources, for example... looks like you just used Ant instead... [03:33] jmarsden: oh, I just clicked "build" in netbeans [03:34] gastoni: OK.... that won't work too well for automated builds in REVU, for example :-) [03:36] Or be in any way acceptable to the archive-admins. [03:36] ah ok, so i have to compile by hand, geez [03:37] If it's not built from source, we don't want it. [03:39] (in universe.) [03:39] it si buitl from source, I wrote the program [03:39] crimsun: We've lived without it for years, so we don't want it in multiverse either. [03:39] which is the difference??? [03:39] gastoni: It needs to be automatically buildable. [03:40] wgrant: oh I agree, I'm just thinking of the many source packages that either retrieve binaries from the 'net or simply bundle a binary. [03:41] e.g., flashplugin-nonfree and eagle, respectively [03:41] Right. [03:41] wgrant: what does "automatically buildable" means? [03:41] gastoni: I should be able to build it by running dpkg-buildpackage. [03:41] s/should/must/ [03:42] it is enough if its build by running dpkg --build ??? [03:44] I don't believe so. [03:44] ok ok, I guess I'll have to read more about all this [03:45] gastoni: See https://wiki.ubuntu.com/PackagingGuide/Complete [03:45] gastoni: Basically, running dpkg-source -x on the source package, editing the source files in the tree it extracts, and then running dpkg-buildpackage should result in your changes propogating to the package that gets built. [03:50] a ok thank you for all your help [04:02] Three cheers for packages using the new Debhelper 7 format so I have to be inside an Intrepid chroot to even build the source package. [04:03] ;-) [04:03] Progress hurts. [04:07] ScottK: You probably wanted to be in a intrepid chroot for building the source package anyway: that way you get any modifications to the tools that run debian/rules clean [04:09] * ScottK starts to wonder about some control file entry for source package versioned build depends. [04:10] Yeah, well, that's been a persistent issue for more years than Ubuntu existed. I suspect that the current requirement that Debian uploads include a sid binary is in part an attempt to work around it. [04:22] I can understand perhaps using the simplified debhelper 7 rules for a new package. I don't get rewriting an exisiting and working rules file ... [04:23] I can perhaps think of a time when I'd do that, but in general, no. What package is that? [04:24] libnet-ssleay-perl. [04:24] It's just a fricking Perl module. [04:24] Refactoring code is usually a good thing, and what you’re talking about is just hiding stuff you don’t need to care about behind an interface that handles the dirty work, so that future maintenance becomes more enjoyable. [04:25] I guess that's one way to look at it. I look at it more like doing work to change something from something that works to something that works. [04:26] But debian/rules isn't terribly complicated to begin with, and unless you're starting out it's a bit impolite to require intrepid to do anything to the package. [04:27] The Debian guy isn't required to worry that he's inconveniencing me, I just think it's an odd way to spend your time. [04:28] RAOF: But it's acceptable to require lenny to do anything with a package targeted at lenny, which we inherit. [04:28] persia: Right. I was thinking this was an Ubuntu change. [04:28] No, I'm updating a merge. [04:28] RAOF: Oh. I can't think of a good excuse for that. [04:29] The new uploader in Debian managed to add a lintian over-ride for a line to long somewhere, but missed our patch that fixed an FTBFS on 64bit. [04:29] Whoops. [04:30] I'm going to see if they have it in their BTS already or not. [04:31] Of course it was uploaded on Lenny freeze day, so it may have been a bit hurried. [04:31] may? [04:31] It could have been planned for then all along. [04:32] Ah, it builds on Debian OK anyway. [04:32] I suppose, although I'd think the one-week warning would have caused most of those to go in a day or two ahead of schedule [04:32] Cheers for Debian/Soyuz sbuild differences. [04:33] I don't mind that so much: it's the Ubuntu/Soyuz sbuild differences that catch me every time. [04:33] It's funny how the freeze stuff goes. [04:34] I maintain 9 packages in Debian. I knew one needed some minor work and uploaded that 2 days before the freeze. [04:34] In the 48 hours before the freeze I uploaded 4 of the other 8. [04:35] All for stuff I didn't know about more than 48 hours before the freeze. [04:35] All the planning in the world wouldn't have helped me. === hemanth__ is now known as hemanth [04:43] RainCT, ping [05:02] * No1Viking is away: BBL [05:10] Is there a procedure or tag or something for requesting a (no source changes) rebuild in universe? [05:23] hello [05:23] Im trying to package FLTK 2 library [05:23] what do you think about following directory layout for it [05:24] prefix="/usr/lib/fltk2/" so /usr/lib/fltk2/lib/*.a /usr/lib/fltk2/include/*.h* and /usr/lib/fltk2/bin/fltk-config [05:24] it would reasemble closelly upstream (and overall development libs practise) [05:24] No, I don't think it would. [05:24] why not? [05:25] Firstly, *.a is probably not very useful. Secondly, headers go in /usr/include, thirdly the libs should go in /usr/lib [05:25] yeah, I ment libfltk2-dev [05:25] not just for users [05:26] Hmm, /usr/lib/fltk2/* seems more organized to me, then having bunch of files in /usr/include/ from various libs. [05:26] So, you want to be reading the library packaging guide. [05:27] LimCore: With the big disadvantage that nothing will link against anything in /usr/lib/fltk2 [05:27] yes Im going to do that, but Im wondering about selecting this pathes [05:27] It's not in LD_LIBRARY_PATH [05:27] LimCore: The path you should use are spelled out in that policy. [05:27] hmm [05:28] well, it's not like Jesus stepped down and give us the policy on 2 stone blocks, never to be upgraded? :) [05:28] Correct. On the other hand, the way to upgrade it is to discuss in on debian-devel. [05:28] not on ubuntu-devel? [05:29] If it doesn't follow the policy (or have good reasons where it doesn't), it's not going in the archive. [05:29] I'd say debian-devel; this is very much a Debian level policy. [05:29] fltk2 can follow it, no problem. I was just thinking thta I would organize it other way, to have each lib more self contained dir [05:29] mhm ok [05:30] Welcome to linux. We do things differently :) [05:31] what do you mean? I liked the defaul FLTK (and wx.. and probably most libs?) behaviour, where all library files go to one dir, and are in {$prefix}lib ${prefix}include etc [05:31] on linux [05:32] Certainly, includes go in $prefix/include, generally as a sub-directory. [05:32] But all the libraries go in /usr/lib, because if they're _not_ there then nothing can link against them. [05:33] uhm wait.. ok.. the /usr/local/LIBNAME was my idea <_< not fltk2 default huh [05:33] stil I think its a good idea =) [05:34] ok anyway, I will make it for prefix=/usr/ [05:35] about the linking problem, are you sure? Isnt extra option for proper LD_ included in the binary when it is build on system where libs are in say /usr/local/libname/ [05:35] Well, yes. You have to use prefix=/usr [05:35] LimCore: Nope. In fact, having such an RPATH is against policy, and you should strip it out. [05:35] mhm [05:35] so, ELF can contain extra path to look for libs, but it should be not used right? [05:35] Correct. [05:36] ok [05:36] Applications should say "I need libfoo.so.6", and it's up to the ld.so to provide that to it. [05:36] on a similar topic [05:37] how about making more packages using ~/etc/ instead brain dead ~/.foo for configs? [05:37] bd_: Not really. They require a new source upload (changelog changes only). [05:37] persia: oh. [05:37] limcore: A freedesktop spec says ~/.config/appname [05:37] * LimCore hates how ~ is littered with 100 config files [05:37] LimCore: /etc/ is used for system-wide config, ~/.foo is used for user-specific configs. [05:37] ~/etc not /etc [05:38] LimCore: XDG basedir spec [05:38] ion_: I know, and I think, with respect to freedesktop etc etc, this is totally stupid idea [05:38] No, ~/etc is just not idea. ~/.config/ is a little better, although it's just hiding stuff that was hidden anyway (that's the leading .) [05:38] s/not idea/not ideal/ [05:38] * persia uses ~/etc for other things [05:38] afair, ~/etc/ is a standard among some developers, but it got adopted only in some places (BSD?) [05:39] persia: Not only hiding stuff, but grouping things with the same function into their own subdirectory. I like that. [05:39] which is sad... consider backing up your configuration files. And consider when in time ~ is filled with like 150 config files making it look chaotic [05:39] more exactly, ~/etc/appname or ~/etc/.appname [05:40] ion_: I guess, although I rarely want to perform an operation on all of them, and tend to treat each application differently. [05:40] I’ve never seen an application using ~/etc (and i’d hate to see one), but i seem to have 36 entries in ~/.config [05:40] LimCore: Why is it important that the subdirectory of the home directory be called "etc"? What is wrong with ".config"? [05:40] .config is also good [05:41] LimCore: Ah, so you don't think ~/.config/ is a totally stupid idea :) [05:41] no, its good [05:42] * persia misinterpreted backscroll then [05:42] Dotti [05:42] Uh. Ditto [05:42] what I do not like, is to have 100 directories directly inside ~ because 1) its littering my home 2) its harder to backup [05:42] 1) is supposed to be covered by the convention that .??* is hidden from view. I don't understand why you claim 2) [05:43] RAOF, you got a minute [05:43] overall I want to see hidden files [05:44] persia: tar ... ~/.config overall, one big directory with all configs (like ~/.config/) is more organized, therefore easier to backup, restore, compare, etc [05:44] LimCore: I guess. I tend to backup /home [05:44] * NCommander just does a recursive backup of /home/mcasadevall [05:45] tar cjmgf [05:45] persia: Splitting e.g. ~/.foorc, ~/.bardatabase and ~/.bazcache (things of all three categories in the same tree level) to ~/.config/foo/rc, ~/.local/share/bar/database and ~/.cache/baz/whatever is really nice. Although .cache could have been .local/cache IMO. [05:45] so, since some apps are already using .config how hard would it be to make most use it? [05:45] Hard. [05:45] ion_: that is a nice idea too [05:46] LimCore: Typically a trivial source change. Mind you, it's probably 10,000 individual changes. [05:46] Also, it's the sort of change that is typically only accepted upstream. [05:46] Death of 1,000 cuts. Hard. [05:46] * LimCore 's program will have a --path-etc [05:46] Not to mention making them migrate from old config to ~/.config [05:47] ion_: I see the point, although I'm skeptical of the value of trying to do it at a distro-level. [05:47] LimCore: How about --user-config to make it clear to more people? === hemanth__ is now known as hemanth [05:47] persia: I’m not advocating doing that, though i’d prefer upstreams to migrate to XDG basedirs. [05:48] ion_: I guess. I'm not happy with XDG basedirs for lots of other reasons: mostly having to do with i10n [05:48] whats the problem, persia [05:49] LimCore: strcmp("Desktop", "デスクトップ"); doesn't return true. [05:49] LimCore: tar zcf /path/to/backup/somefile.tar.gz ~/.[!.]* # should do your config backup for you [05:50] jmarsden: unless I have ~/.myporn [05:50] not all hidden files in ~ are configs [05:50] I have my “Desktop” in ~/.local/share/desktop ;-) [05:50] One thing less polluting my precious ~ [05:51] ion_: It's not that way by default. If that is how XDG basedirs is supposed to be implemented, all the better. [05:51] * LimCore installs VISTA to ion_'s ~ [05:51] LimCore, thats just evil [05:51] Yeah, not by default, but thanks to Gnome’s XDG basedir compliance, i was able to move it there easily. [05:51] * NCommander watches gameplay of Deadly Towers [05:52] ion_: Do you have some fancy run-time overlay that maps localised names in ~ to ./local/share/foo ? [05:52] (if so, I want it) [05:52] persia: I just set XDG_DESKTOP_DIR="$HOME/.local/share/desktop" in ~/.config/user-dirs.dirs and moved the directory. [05:52] ion_: Ah, so it's still a specific localised name :/ [05:53] names like Desktop should not be localized [05:53] thats just idiotic [05:53] * LimCore mv /usr /użytkownika ; mv /lib /biblioteki [05:53] LimCore: Why? Many people don't understand the word "Desktop", and may not be able to read any of those characters. [05:54] I mean the directory names [05:54] GUIs could translate it [05:54] Yes, so do I. [05:54] why? for same reason /home is not /dom [05:54] Erm. It's a lot easier for there to be a filesystem overlay that provides the localised names rather than having *every* GUI change. [05:54] or just ln -s [05:55] LimCore: Well, at a primitive level that works, but tends to get awkward if you switch your locale. [05:55] LimCore: I don't want 15000 symlinks cluttering up my ~ thankyou... how many langauges are there... :-) [05:56] jmarsden: The symlink way is not the perfect solution, but it wouldn’t have to implemented *that* badly. :-) [05:56] ln -s Desktop Desssssssssssktop # python language [05:56] ion_: How woudl you decide which languages to provide symlinks for? [05:56] Hundreds, and there are 7 basedir names [05:56] jmarsden: By looking at the user’s locale settings. [05:57] jmarsden: One way would be to generate symlinks on session start, and clean up on session end (or do cleanup on session start for crash recovery). [05:57] I’m not advocating the proposed symlink way, just speaking hypothetically. [05:58] Then I log in in one language but start thinking in another and ... aargh, my dirs are not there they disappeared... ugh. [05:58] Ah. ISO 639 provides for 17,029 possible languages (not all are currently implemented) [05:59] wtf [05:59] some countires really should stop heaving more then 5 languages heh [05:59] jmarsden: Presumably you tend to log in to a locale in which you think, or are doing specific testing. If you need multiple simultaneous language support, there are greater issues. [05:59] That said, on-the-fly locale switching would be interesting (if tricky to implement) [06:02] Also, if one implements it with something like ~/.local/share/$(XDGNAME) one has a static representation available for scripting, etc. === tritium_ is now known as tritium [06:04] Yes, the current implementation offers to rename them at session startup, which could make locale-independent scripting awkward [06:06] Yes indeed. [06:07] I still think a FUSE layer to generate the apparent directories without bothering with symlinks would be even better, but it's probably more work. [06:08] persia, maybe not, writing FUSE plugins isn't qutie as bad as most other things [06:08] (although file system plugin development is the kings displine) [06:08] persia, mind if I steal you for a moment to get an advocation of a package ;-) [06:08] NCommander: Fell like giving it a shot? A plugin would also work. [06:08] NCommander: Yes, because I just got the phone call saying I'm supposed to head somewhere else. [06:09] persia, d'oh :-P. Bad timimg on my part [06:09] persia, I've only been half paying attention to the conversation [06:09] if I would develop small LGPL user application, and provide correct ubuntu scripts/package, how long can it take to take it to officiall repos? [06:10] LimCore, not long, post it to revu, and then ask some MOTUs to sponsor [06:10] LimCore, once its in the archive, just post an updated .diff.gz/dsc file as a bug, and add universe sponsors to update it [06:10] Anyone feel like reviewing http://revu.tauware.de/details.py?package=compcache-setup? Thanks. [06:17] btw [06:17] how about naming binaries with some extension? [06:17] like foo.elf [06:18] the default of empty extension for binaries is unfortunate for scripting, processing, sorting, etc [06:18] (obviously common utilities like cp mv ls must always remain how they are) [06:21] why? [06:21] file /bin/ls [06:21] good morning [06:24] limcore: The fact that some pieces of software opt to decide the file type based on its extension is very unfortunate. [06:25] The filenames are *only* for humans. If it is deemed beneficial for humans that the name also tells its type, fine, but software should not base its decision of the type only on it. [06:25] ion_: I don't agree, considerf [06:26] * consider, how would you write a script to resize all your jpg images? [06:26] In a perfect world, find foo -mime image/jpeg blahblah [06:27] noone does that [06:27] plus, your solution would try to resize my randomdata.nr04329432 file [06:27] and/or my dump of encrypted partition, etc [06:28] No, it wouldn’t. [06:29] file utility does FULL parsing of a jpeg image, or just looks and part of file that /seems/ to be a header [06:29] but also can be random data [06:30] I think perfect script would find *.jpg[e] , and then file them to confirm [06:30] .jp[e]g [06:31] That would fail with images/Foo, which happens to contain JPEG data. [06:32] so "Foo" is the file name? [06:32] See Windows® for the worst example: deciding that it’s executable because its human identifier happens to end with the string “.exe” [06:33] s/example/case/ [06:33] this is a good example, if you think about it more [06:33] I mean, its the right thing to do [06:33] Ha! :-) [06:33] at first look, it looks noob [06:33] Since when is executing a JPG the right thing to do? [06:33] but then, using some data as JPG just because first N bytes /seem/ to look like jpeg, is as wrong [06:34] jmarsden: executing? we talk about finding jpeg's (to resize them, in script) [06:34] If you have one named foo.exe then by your reasoning the right thing to do with ti ti always to execute it. [06:35] s/ti ti/it is/ [06:35] no [06:35] do action for jpeg, if file is named *.jp[e]g AND if it is the proper file type (header) [06:36] You said that deciding that it’s executable because its human identifier happens to end with the string “.exe” is "the right thing to do" -- I think!? [06:36] yes, but still check the actuall file type (header) [06:38] If you can determine a file's type from the header, then it's type is independent of its name. If you can;t fully do so because of random weird exceptions, then requiring both name.exe *and* a header still doesn't get you 100% (encrypted filesystem saved as junk.exe)... [06:38] overall the point was: file extensions are helpfull for people to sort and oraganize files, obivously. Too bad that executables are human-identified by an EMPTY extension. How about introducing another extension, like .run or .elf That would make it nicer for users. [06:39] LimCore: Only for users who identify files that way.. as in, users trained in the ways of MSDOS. [06:39] why that way is wrong? [06:39] Better to absorb a little of the culture they are migrating into. [06:39] jmarsden: foo.jpg. What is it? (normally) ? [06:39] A typo :-) It’s jpeg. [06:39] foo.html is what? [06:39] and foo is...? [06:40] media/text/todo: UTF-8 Unicode text [06:40] on windows world, "foo.exe" is executable. Nicer to talk about it, search for it, etc. Linux lacks this [06:41] Linux user can say "send me the JPEGs" or "send me the PDF version" but can not say "send me the exe" [06:41] Different OS worlds have different conventions and different expectations. If you prefer those of one world, live and work and play in that one... :-) [06:41] we could fix that by adding say .elf [06:41] or .run (I do not like .bin) [06:42] jmarsden: windows/dos got that one better then linux, so we could incorporate the better idea. Unless "foo" is nicer for humans then "foo.run" for some reason? [06:42] Then you would lose the possibility to replace the file with an alternative implementation in a different format. [06:42] LimCore: It is shorter to type, too. [06:42] I like foo.elf, but since not all is ELF as ion_ noted, foo.run could be generic [06:42] Yeah, much better than Linux. Just look at all the virus attachments called foo.jpeg.exe, with the OS helpfully hiding part of their human name. :-) [06:42] and I used Linux when the standard binary executable format was a.out ... [06:43] ion_: how this argument makes any sense? is it FUD =) ? [06:43] Just pointing out the system’s idiocy. [06:43] which doesnt have nothing to do with good/bad evaluation of foo.run right? [06:44] So what are .BAT files in Windnows... why are they not named .EXE since they are executable? Likewise, if I install a JRE do I need to rename all *.jar files to *.exe or *.run now, since they just became executable? The whole thing breaks down. [06:44] hidding part of file name is stupid. assuming there is just one "." in file is stupid too. I'm not proposing either of that [06:45] Feel free to call it foo.run if you deem it to be helpful for a human, but please don’t kill the functionality which parses the file’s header to decide how to run it. :-) [06:45] File names are only for humans. Computers could live with plain inode numbers. [06:45] jmarsden: lets leave .sh and .jar as they are. But add .elf for elf flies. And .run as general indication that this file is some program [06:45] Btw, calling stuff in $PATH foo.run is not helpful for humans. [06:45] I thought that was .exe [06:45] ion_: yes, this is my idea. renaming to .foo does not brake file, but it helps humans [06:46] ion_: leave standard tools like ls mv dd tar apt-get etc, as they are. Use new for bigger new applications. [06:46] I think some applicaions do that already [06:46] for i in /bin/* /usr/bin/* ; do file $i |grep -sq executable && mv $i $i.run ; done # would be cool on your system, then, right? Go ahead and try it :-) [06:47] yes they do: /usr/lib/openoffice/program/soffice.bin [06:47] Either of the facts that it has the executable bit on *and* it resides in the binary directory is enough for me as a human. :-) [06:47] ion_: www.omg.com/foo what is it? [06:47] ion_: www.omg.com/foo.exe what is it? [06:47] Gah, why does _every_ management program for iriver only support MTP? [06:48] Does nobody use UMS, or what? [06:48] (and don't start FUD with "its a virus" =) [06:48] limcore: http://www.w3.org/Provider/Style/URI “What to leave out” [06:49] ion_: .run will not change [06:49] limcore: I’ve replaced multiple http://something/foos where foo is a JPEG with a HTML page that displays the JPEG without the URLs breaking. [06:49] its for another use case [06:50] "Download https://test.com/foo.exe" - this is obviously an information to get a program [06:50] in linux world this is not as comfortable [06:50] Please don’t abuse the word FUD. The fact that Windows® doesn’t require an executable bit to be set for it to run stuff is just plain wrong. That statement is not spreading FUD. [06:51] LimCore: Now imagine files on a shared filesystem that are executable on PPC machines ... should they be named .run even if they do not run on x86 machines? Or do we have to create special file system overlays so only files that are executable on one particular architecture are seen as being .run files? [06:51] it is indeed worng; I was saying that it would be FUD to say that there shouldnt be any binaries on www anyway [06:51] LimCore: In the Linux world we do not geenrally pass random executable binaries around... [06:51] jmarsden: I would name them foo.i386.run foo.ppc.run etc [06:51] Very short to type... nice... ? [06:52] https://x.com/foo [06:52] https://x.com/foo.i386.run [06:52] Heaven help us no. Please don't try to make the file names mean anything. [06:52] and once it is downloaded, ln -s, desktop & menu shortcut, and bash completion [06:53] LimCore: This adds complexity and mess, and gains us what, exactly? [06:53] It sounds like a lot of work for no gain. [06:53] * LimCore renames all ScottK's .jpeg .png .mp3 .odt .pdf .txt .c .cpp .h and .sh to extention-less format. Cool? [06:54] Well, my photos are already under a photos directory, my music is in a music tree, my text files are in a text directory. Sure, go ahead. [06:54] * NCommander does one better, and attachs resource forks and filetype meta data to LimCore's files [06:54] If those things had ways of knowing otherwise, I'd be in favor. [06:54] jmarsden: way for users to know that file is an probably executable just by knowing file name, same as foo.jpg - you know it (should be) an image. [06:54] ScottK, can I get you to look over a package in REVU when you have a moment? [06:54] NCommander: No. I'm about to fall over. [06:55] ion_: ~/from_alice/my_story/ camp.jpg camp.mp3 camp.pdf would you like to have this extenion-less? [06:55] Man, MOTU's dropping like flies [06:55] I wouldn’t mind all programs showing the file’s type (based on its MIME type) in a column next to the filename. [06:55] NCommander: Also I just finished writing my thoughts on the Launchpad 3.0 specs. [06:55] ScottK, do I need to wear flame-resistant firegear, or will normal sunblock work ;-) [06:55] NCommander: I'm grumpy even for me as a result. You don't want me reviewing your package right now. [06:55] ion_: I wouldnt too. But .run is good for other cases [06:55] eh [06:55] * NCommander gets his bunker gear on, and hugs a charged hose [06:56] NCommander: The top 5 things on my list weren't on theres. [06:56]