[01:03] \o/ we can now schedule rebuilds for Universe packages! [01:04] we can? that's rather useful [01:05] e.g. https://edge.launchpad.net/ubuntu/+source/anjuta/2:2.4.1-1/+build/602185 [01:05] when modifying a patch, should it be kept under the same name, or should it's number be increased (ex: 12_foo_bar.diff 13_foo_bar.diff) [01:05] ajmitch: currently in edge, but should be in production with 1.2.5 [01:05] ryanakca: don't change the name [01:09] pochu: thanks [01:10] ryanakca: the number is to indicate/define the order in which they are applied, rather than the revision or anything. [01:13] james_w: aha :) [02:17] ScottK: can we backport Wordpress 2.5.1-2ubuntu1 (intrepid) in hardy and gutsy? [02:18] there are more security fixes and features, if not i will work to fix this security bugs in hardy/gutsy. [02:18] what do you think about it ? [02:19] argh big idle [02:28] Heya gang [04:24] could someone review this merge please? https://bugs.edge.launchpad.net/ubuntu/+source/bygfoot/+bug/226988 [04:24] Launchpad bug 226988 in bygfoot "Please merge bygfoot 2.0.1-1 (universe) from debian unstable (main) " [Undecided,Confirmed] === boomer` is now known as boomer [05:28] http://jdong.mit.edu/~jdong/Screenshot-Terminal-1.png [05:28] whoo! [05:28] go Apple! [05:43] hi y'all [06:46] <\sh> moins [06:49] heya \sh :) [06:50] <\sh> hey emgent...how is the day starting? :) [06:51] waiting MC response :P [06:51] for now all good [06:51] hehehe [06:52] * \sh looks into NEW queue and sees etpan still being in [06:53] hi all [06:53] Guten Morgen \sh [06:55] <\sh> geser: Guten Morgen :) [06:55] <\sh> 7topic German Lessons now for free :) [07:00] is there an easy merge waiting for a MOTU hopeful? [07:01] <\sh> mruiz, you are free to take any merge with my direct name tag on MoM :) just give me a short message via jabber on which package you work [07:02] <\sh> mruiz, jid: sh@linux-server.org [07:03] thanks \sh ... I'll work on some packages ;-) [07:03] <\sh> mruiz, ruby1.9 is on my radar..so leave that out :) [07:03] \sh, sure === asac_ is now known as asac [07:14] \sh, ttyl ;-) [07:14] <\sh> ttyl? [07:15] <\sh> no package I know of ;) [07:16] hahaha [07:16] \sh, talk to you later ... ;-) [07:16] lol [07:17] <\sh> oh I'm old...I really thought ttyl is some package which does some tty line streaming or what [07:18] heh [07:18] it was wierd the first time my dad IM'd me that [07:18] i had to ask him what it meant =( === thekorn_ is now known as thekorn [07:54] http://xkcd.com/424/ :) [07:59] <\sh> rotfl [08:00] <\sh> good one === tb1 is now known as tbf [08:43] right then. is \sh about? [08:43] * \sh is online, responding and ready to serve [08:44] jms@osc-bigmac:~/Projects/packaging$ wc -l mono_1.9.1+dfsg-1ubuntu1.debdiff [08:44] 425 mono_1.9.1+dfsg-1ubuntu1.debdiff [08:44] * \sh @ remote:~ (enter your command) > [08:45] <\sh> directhex, push it to a merge bug report, subscribe ubuntu-main-sponsors and ping someone with core upload rights ;) [08:45] \sh, someone already filed a wishlist on a merge. is a new bug neccessary? [08:45] <\sh> nope. [08:46] <\sh> just attach the debdiff and subscribe the main sponsors team [08:46] <\sh> oh and add (LP: #) to the changelog before you generate the debdiff pls [08:47] gah, damn [08:57] there we go. and i think the status/assignment are right now too [10:17] \sh: around? I again need to know why you introduced " * Patched Makefile to link against zlib (added -lz) [10:17] " and if it's still necessary ^^ [10:17] <\sh> sebner, which package? [10:18] \sh: ah sry, athcool [10:18] <\sh> sebner, I#ll have a look...I#m a bit busy right now...give me some mins [10:19] \sh: no problem. thanks [10:43] huhu sistpoty|work [10:43] hi sebner [10:50] Hello from Fosscamp. [10:51] TheMuso: are you here? [10:51] nxvl: yes I am. [10:51] awesome [10:51] we will meet in some minutes i think [10:51] :D [10:51] <\sh> sebner, because of a missing build-dep during these days...now it's ok...sync [10:51] nxvl: Lets hope so. You would likely see me before I saw you. [10:52] \sh: ha, I knew it. I'll log what you've said for norsetto. he doesn't trust me :P [10:52] heh [10:52] <\sh> where is he? [10:52] :D [10:52] nxvl: I am actually serious, since I have a vision impairement. [10:53] \sh: norsetto? [10:53] <\sh> yes [10:53] TheMuso: yes, i know [10:53] nxvl: Ok. [10:53] nxvl: You staying for UDS? [10:53] c [10:53] \sh: not online ^^, yesterday I filed the sync request and I reviewed it and insisted on it to have a log or something of what you say about athcool. As I said, he doesn't trust me =) [10:53] yup [10:54] TheMuso: i will be here the whooooole week [10:54] :D [10:54] \sh: argh. *he* reviewed it [10:54] nxvl: thats awesome! [10:55] <\sh> sebner, I'll changed the bug now to approved, confirmed/wishlist and subscribed archive-admins [10:55] <\sh> s/ll/ve/ [10:55] \sh: hmm no stress. I can tell him when he is online again [10:55] <\sh> sebner, already done :) [10:56] \sh: ok then ^^, thanks :) [10:56] <\sh> and changed assignee...he'll kill me ;) [10:56] \sh: I tried to stop you, I have irc logs as evidence ^^ [11:18] * Hobbsee waves [11:22] what's a typical turnaround time from subscribing ubuntu-main-sponsors to a merge request, and a response of some kind? [11:23] depends. [11:23] few days to a copule of weeks [11:24] a lot doing the allocation are at UDS atm. [11:24] which one? [11:31] Hobbsee, mono. bug number, um... [11:31] ew [11:31] a while, then. [11:31] 225426 [11:32] * directhex pokes the bot [11:32] i said "LP 225426" [11:32] Launchpad bug 225426 in mono "[wishlist]please update mono to 1.9.1" [Undecided,Confirmed] https://launchpad.net/bugs/225426 [11:50] <\sh> ruby1.9 new version is coming along === AstralJa1a is now known as AstralJava === torkel_ is now known as torkel [12:18] <\sh> damn...I wonder why my builds are going through and on our official buildds the very same package is failing [12:22] \sh: I know that. the magic of opensource ..x xD [12:23] <\sh> nope...I expect, that when my mirrors are up2date and my chroots too...that it gives the same results...anyways..it's depwait now [12:36] sistpoty|work: I also dist-upgraded now to intrepid. you may know how to fix pidgin? because of this perl 5.8 - perl 5.10 thing ^^ [12:36] sebner: no idea... (not even what pidgin is *g*) [12:36] sistpoty|work: damn this kde users [12:36] :P [12:36] hrhr [12:39] sebner: use kopete. problem solved. [12:39] Hobbsee: I'll try some gtk stuff :P [12:40] sebner it just needs a rebuild, but before that some deps need a rebuild to [12:41] ember: yep, hmm you are the pidgin guy. go go go :D and then xchat ^^ [12:47] Hmm. I've a package which installs its .desktop file into /usr/share/applications as it should, but the icon doesn't appear in the menu even after running update-desktop-database manually. Am I missing something? === Czessi_ is now known as Czessi [12:53] <\sh> Laney, what does desktop-file-validate say to your .desktop file? [12:57] Hey [12:58] \sh: http://pastebin.ubuntu.com/12444/ [12:58] (The file is distributed in the upstream tarball) [13:22] <\sh> Laney, get rid of the encoding line and remove .png from the icon= line [13:23] <\sh> Laney, desktop-file-validate again...be happy...dance [13:23] can i be happy and dance? [13:23] \sh: Actually, I just tried it in a fresh VM and it works properly... Guess I messed up my system somehow [13:24] * \sh isn't happy...and could bang his head against the wall.... [13:24] <\sh> crappy winxp [13:25] could be worse [13:25] winxp causes me less pain than SLES [13:26] <\sh> oh sles... [13:26] <\sh> sles9 was my favorite [13:28] maybe one day i'll be able to run a 'dist-upgrade' equivalent on suse without spending hours fighting broken update mechanisms [13:28] <\sh> directhex, I used yum on sles9 and a selfmade package repository for it...that worked [13:29] i think self-made package repos count as high maintenance [13:31] <\sh> directhex, na...I wrote a perl script which grabbed all updates from the novell website for sles9 automatically...and pushed them into the archives...quite easy...I'm sad that I was not allowed to take this source with me, when we had to leave the last company [13:32] Oh ha ha, I just had to remove btnx-config.desktop from ~/.local/share/applications/ === _neversfelde is now known as neversfelde [13:50] <\sh> oh no...another gnome vs kde war ... hopefully it lasts long on the u-d-d ml [13:51] <\sh> add a "not " [13:51] heya [13:52] \sh, both suck. real men use ctwm [13:52] <\sh> na dwm [13:53] evilwm! [13:55] Hi RainCT [13:58] I've been using xmonad on my eee, it's pretty nice [14:03] morning === fta_ is now known as fta === Zenton is now known as Zenton_ [14:29] Hmm, the REVU comment design has changed [14:57] Heya folks [14:58] hi bddebian [15:00] Heya sistpoty|work [15:00] Hi bddebian [15:00] Hi geser [15:05] what are the policies regarding putting something from main in hardy-backports? [15:08] directhex: the same for universe packages AFAIK [15:11] directhex: Backports makes no distinction between release pockets. [15:11] pockets/components [15:13] I'm looking for avahi-sharp in the archive but I cannot find it, although I see it here https://edge.launchpad.net/ubuntu/+source/avahi-sharp [15:13] Also I can see it with the apt-cache showsrc cmd. [15:14] Am I missing something? [15:14] Iulian: try a apt-get update and try again [15:14] sebner: I already did that. [15:14] Iulian: What binary package are you trying to install? [15:15] Iulian, libavahi1.0-cil is the binary package made by the avahi-sharp source package [15:15] avahi-sharp is the source package name. [15:15] Iulian: it's i386 only [15:16] ScottK: I need it as a b-d to build a package. [15:16] I will use what directhex said. [15:16] Iulian: You still need the binary for that. [15:16] sebner, erm... is it? libavahi1.0-cil_0.6.19-1_all.deb [15:16] ScottK: Yes, indeed. [15:16] directhex: only looked at avahi-sharp [15:17] sebner, that IS avahi-sharp [15:17] directhex: https://edge.launchpad.net/ubuntu/+source/avahi-sharp/0.6.19-2 Builds: intrepid i386 Successfully built (DONE) [15:17] http://packages.ubuntu.com/source/intrepid/avahi-sharp -> libavahi-ui0.0-cil and libavahi1.0-cil and monodoc-avahi-manual [15:17] sebner, Arch: all packages are only built once [15:18] directhex: but the others should be listed also there === whs is now known as lliwlliw [15:20] Guys, do you have an idea when notify-sharp will be synced with debian? [15:20] It's bug #139356 [15:20] Launchpad bug 139356 in debian "Please sync notify-sharp (0.4.0~r2998-1) from Debian unstable (main)" [Unknown,Fix released] https://launchpad.net/bugs/139356 [15:20] Iulian: subscribe u-u-s [15:21] Iulian: ah no sry [15:21] sebner: It will be synced automatically. [15:21] Iulian: autosync. well there is a lot to do so it will take some time [15:23] In the mean time, can I submit a package to REVU with a B-D on that package? [15:30] ScottK: Could we talk about the issue with Windows-illegal characters? [15:30] Sure. [15:30] Have you read the bug report? [15:30] I'd been talking on there rather than the ML. [15:31] https://bugs.launchpad.net/ubuntu/+bug/230906 [15:31] Launchpad bug 230906 in ubuntu "Using special characters in filenames prevents Windows from opening" [Undecided,Incomplete] [15:31] No. I've been away from my computer and doing mail via my phone until recently. [15:31] * ScottK looks [15:31] I've now moved a little bit beyond what I suggested there. [15:32] OK. I read the bug. [15:32] How would you feel about a uni_xlate option that did something more like :a...:z for various characters likely to cause problems for this or that implementation? [15:33] Fundamentally I don't think Ubuntu should be coded to limit itself based on Window's limitation. [15:33] I think automatically renaming user's files is an unfriendly act. [15:33] There's also the issue of devices using FAT that assume Windows' limitations. [15:33] How so? [15:34] The big problem isn't manually names files, but ones that are automatically generated. [15:34] Note that there are existing bugs about issues with moving files in the other direction causing name changes, and efforts to fix them. This has all the earmarks of a bugwar issue. [15:34] persia: Could you give me an example? [15:35] * persia digs out launchpad [15:36] As an example, I use Kmail as my MUA with maildir storage. The filenames it generates for the mails (maildir is one file per mail) are often not legal windows filenames. Kmail also keeps an index per directory. If I backup and restore to/from my 20GB USB microdrive (I have one and it's FAT32), under your plan you just renamed files out from under the index. What's the impact of that? [15:36] My big concern about renaming files is that sometimes it's not going to be possible (e.g. a 255 byte-long filename with a * in it), and that sometimes you'd get collisions (e.g. what if I happen to have named a file this:that). [15:37] Achh, I always forget: which is the current address of FSF, Franklin St. or Temple Place? [15:37] ScottK: My suggestion is that it would be transparent above the FS layer. [15:37] mok0: The one that lintian doesn't complain about. [15:37] ;-) [15:37] So it's translated one way going in, then the other way coming back. [15:38] ScottK: heh ok I'll check lintian source code [15:38] It's probably easier to look on the FSF web site. [15:39] I can see benifit in some kind of utility that one could use to verify if a folder contained legal Windows filenames. I see tons of risk for very little benifit in modifying things at such a fundamental level. [15:39] andrew_sayers: Bug #49217 is one example [15:39] Launchpad bug 49217 in dosfstools "Problem in FSCK checking Chinese filename (Big5)" [Medium,Confirmed] https://launchpad.net/bugs/49217 [15:40] mok0: the 51 one (you could always look at /usr/share/common-licenses though) [15:40] andrew_sayers: I guarantee you'll have a hard time writing such a translation layer that would take the ~50,000 maildir files on my desktop can convert them both ways with no collisions an no errors. [15:40] mok0: Just look in /usr/share/lintian: the text of the correct address is there [15:40] heya persia := [15:40] Note that such a translation filter is especially hard when confronted with the variety of different accepted encodings for "FAT32". [15:42] 51 Franklin St. is the current === _stink__ is now known as _stink_ [15:42] * mok0 transfers to memory [15:43] mok0: just remember temple == money != FSF [15:43] Erm. Except that Franklin street is usually higher rent than Temple street... [15:43] norsetto: Ha! That's really a good one! [15:44] Franklin = Benjamin Franklin = electricity = computers = FSF [15:45] norsetto: now we just need a mnemonic to un-remember the really old address at Mass Ave [15:45] moko: which one !? [15:45] mok0: which one !? [15:45] persia: Thanks, I'll mention that as a related issue. [15:45] andrew_sayers: I appreciate what you are trying to do and understand the reasons for it. I think it's appropriate to provide some tool, but not something that fundamentally affects the way the system works. [15:45] Free Software Foundation, Inc., 675 Mass Ave, Cambridge, [15:46] ScottK: Actually, let's just get a related issue out of the way first - whatever the mechanism, on by default or off by default? [15:46] andrew_sayers: Off. [15:46] andrew_sayers: Thanks. If you do find a solution, it would be great, but it's really not hard, in large part because of missing portions of the FAT specs, and differing implementations by different formatting tools (even when ostensibly the same, e.g. MS Windows 2000 with MUA vs. without MUA). [15:47] mok0: That's really old. Those were the offices right after moving out of MIT. [15:47] persia: You mean really not easy? [15:47] Err... Or really hard, depending :) [15:47] ScottK: Surely the people that want it off are more likely to know how to turn it off? [15:48] andrew_sayers: I'm going to agree with ScottK here: the potential for data corruption (especially in double-byte locales) is so high as to make on by default very dangerous, unless it is known to be perfect. [15:48] Start with off by default. After lots and lots of testing, on by default could be a separate discussion. [15:48] persia: ye, that address is on my very first emacs manual [15:49] andrew_sayers: At the very least, whether on by default is the ultimate goal or not, initially it absolutely has to be off by default (as persia says). [15:50] What about, at least to start with, warning by default? [15:50] andrew_sayers: I really think that it would be very odd for a person coming from Windows to manually invent a file name that's illegal in Windows. They are the ones most likely to know the Windows rules. [15:51] andrew_sayers: I don't like that. It's useless information thrown at me from my perspective. [15:51] andrew_sayers: Noisy. Copying files to/from FAT is known broken now: warning changes behaviour without improvement. [15:51] As in, saves a file unmodified, but pops up a thing saying "such-and-such a drive has files with names that mightn't be supported by Windows". [15:51] andrew_sayers: Except there's no good filter. The FAT filesystem cannot know what encoding is used for files thereon, so you will have a difficult time knowing what bytes to allow. [15:51] Personally I find such pop-ups really annoying. [15:52] huhu norsetti [15:52] andrew_sayers: Think about the case where 0x3A is a valid byte. [15:52] no0tic: athcool sync ;) [15:52] ScottK: It seems to me that until we have a good solution, the only real alternative is user awareness. What if you could turn the warnings off? [15:53] norsetto: : athcool sync ;) [15:53] no0tic: sry [15:53] I don't see what we are discussing, if an user uses a filename that cannot be read by windows, thats a windows problem ... [15:53] norsetto: +1 [15:53] andrew_sayers: I really think this is very much a corner case and will cause lots of pain to little benifit. [15:53] andrew_sayers: How can you know when to warn? 0x5C is sometimes valid in FAT, and sometimes a directory indicator [15:53] persia: I have - I agree that's a knotty problem. But uni_xlate already uses : as an escape character, so I'm assuming it's been looked at before. [15:53] sebner: good, next time try to be more verbose in your requests (archive admins will plainly reject them) [15:54] andrew_sayers: uni_xlate is known broken for double-byte locales [15:54] persia: How so? [15:54] norsetto: well I was 99% sure ;) and if a MOTU does it without checking no ones complains ..... :) [15:55] andrew_sayers: OK. I'm just going to explain from the point of view of Windows, and let's assume there is sufficient variation in all other FAT implementations that other cases are also covered. [15:55] Microsoft distributes several different versions of the filesystem drivers, depending on the locale in which the kernel is expected to be installed. In some cases, there is an aftermarket add-on that allows one to alter the drivers. [15:56] For warnings, false positives aren't a huge problem. "Such-and-such might cause problems" doesn't really break anything. === lliwlliw is now known as willwill [15:56] Each driver has a different set of assumptions about the native encoding for the filesystem tables in the FAT. As this information is tracked by the host operating system, rather than recorded within the filesystem metadata, FAT partitions moved between different drivers will generate corrupt filenames. [15:57] Microsoft works around this by the introduction of a codepage parameter that can be set on the command line, which changes the display characters used by the cmd process. [15:57] sebner: I hope you were sure, if you weren't I would be worried, the issue is that you have to be document what you are doing, not take things for granted [15:58] Unfortunately, this doesn't actually change the meaning of the characters as read by the standard file access libraries, so files must first be recopied with cmd prior to being read by other programs when there are issues. [15:58] norsetto: well, at least I testbuilded and it was fine, I run it and it doesn't segfault and I had in mind that we can sync it ;) [15:59] In the case of uni_xlate, it assumes that the FAT filesystem is configured to match the user locale, and there are a heap of special cases for different locales listed in the dosfstools source. [15:59] This breaks when one uses a FAT filesystem with a codepage that doesn't match one's locale. [15:59] norsetto: and yes, I know everything should be documented, except when I'm motu ... ;) [16:00] *ouch* [16:00] andrew_sayers: On the other hand, if you could build some tool that could accurately detect the encoding of a FAT filesystem, it might make sense to use that as a basis of a warning, assuming a sufficiently small processing delay. [16:01] persia: where do I find this uqm-music maintainer that I should annoy? [16:01] That would only fail in the cases such as someone using a USB stick in several different computers, where the files may have several different encodings. [16:01] If there's no metadata about which encoding is being used, guessing is a very hard problem. [16:02] The only way I know would be to scan the whole filesystem and look at character frequencies. [16:02] sebner: You don't want to annoy anyone, and the uqm-music maintainer isn't likely to want to migrate especially. The person who hosts the repository wouldn't mind migrating, but no longer has a direct interest (and didn't migrate when they did). I'd recommend just filing a sync request based on the information in /usr/share/doc/uqm/ [16:02] Which would be slow, require lots of files, and be prone to error. [16:02] andrew_sayers: Precisely :) This might take a while for a terabyte-sized filesystem [16:03] persia: /usr/share/doc/uqm/ is the thing I wanted to hear ;) [16:03] persia: For a terrabyte-sized FS, you could just stop when you've got enough data. I'm more worried about floppy disks. [16:04] persia: Tollef Fog Heen right? [16:05] Hang on, we're wandering a bit here - you're saying that it's very hard to accurately *import files from* Windows. I'm looking for a way to accurately *export files to* Windows. [16:05] andrew_sayers: Floppies / USB sticks are a common case, but also various other USB storage devices (e.g. portable media players, backup solutions, some cameras, etc.). Also consider that it may be that you might have a large number of files before reaching enough. Just about everything in a default codepage 932 install of Windows is codepage 437 compatible. [16:05] persia: Are you in Prague yet? :-) [16:06] StevenK: Nope. I start my journey in about 5 hours. [16:06] persia: Ahh [16:07] andrew_sayers: It's the same thing. While I'm more familiar with the problems of extracting data from FAT you'll have the same issues putting it there. How should you encode your data for storage? When is 0x5C a valid byte to store, and when will it break a filename? [16:08] This is particularly problematic for the USB drive case since you have no access to information about the target system. === thekorn_ is now known as thekorn [16:08] ScottK: Or more accurately, any given target system cannot be passed metadata explaining the choices made during the data write operation. [16:09] Yes. [16:09] Hang on - another newbie moment I'm afraid - when you say "break", what breaks? e.g. reading open(2), I wasn't sure whether bad filenames cause EFAULT. [16:09] persia: btw, don't forget about my merge ^^. quick upload before you're away ;) [16:09] sebner: Unlikely. I'm just finishing a meal, and still have to sort my electronics. I've a couple uploads of my own that I don't anticipate pushing. [16:10] persia: for sure, no problem =) [16:11] andrew_sayers: When I say "break" I mean that the filename is considered corrupt. The File Allocation Table is usually safe enough that minor editing makes the filename safe, but it looks ugly, and may require technical expertise beyond that of the average user. [16:11] This is, again, compounded for double-byte locales as there is typically insufficient documentation on the workarounds available in the local language. [16:12] persia: should I subscribe directly the archive admins? [16:12] sebner: Probably not. I suspect they'll reject it without a sponsor. [16:12] Ah okay, so you would say that creating a file "a & b.txt" breaks the filename, because it causes headaches in some OSs? [16:12] andrew_sayers: Just as an aside, this is currently broken for copies between Windows systems: and the same issues affect every FAT implementation. [16:12] persia: do want to "ACK" or should I ask somebody else? [16:13] sebner: I'll look for it when I next open launchpad, but if someone else ACKs first, I won't complain. [16:13] persia!!!!!!!!!!!!!!!!!!!!!!!! [16:13] bddebian!!!!!!!!!!!!!!!! [16:13] Yeah, this does sound like one of those terrible pre-Unicode black holes. [16:14] My day job involves handling that and worse sometimes. [16:14] persia: Heh. Don't worry, I don't need anything, you just never say Hi anymore.. :'-( [16:14] * andrew_sayers rocks back and forth [16:14] persia: so I'll just subscribe you. No rush [16:14] andrew_sayers: Essentially, yes. Again, if you can find the solution, every single maker of systems that are FAT compatible would likely rejoice. [16:14] Plus, every non-English web user, everyone that wrote documents before 1995... [16:15] Um, well, it's not that bad. Most things (notably including HTML) support some means of passing encoding metadata. [16:16] Whether users take advantage of it is an entirely different issue. [16:16] andrew_sayers: hmmmm, I met an Andy Sayers a couple of years ago [16:16] norsetto: I've only gone by Andy at university, so unlikely to be me. [16:16] Re: the hfsprogs request in u-m, has anyone done anything about it? [16:16] norsetto: And then not entirely by choice :) [16:17] andrew_sayers: oh well, was worth a try ... :-) [16:17] I have actually looked into detection in a different context. I can't promise it's impossible, but I've come to accept that I'm not the man for the job. [16:17] mok0: Not that I know of. Someone should explain (at the very least) that since we only do source uploads, his package will have to build in sbuild on amd64. [16:18] norsetto: ironically, I met another Andrew Sayers at university. Kept getting his post :s [16:19] ScottK: He should patch it [16:19] andrew_sayers: I see, so its quite a common name (good when you have to pay taxes I would say ;-)) [16:19] ScottK: I'll write a reply [16:19] mok0: I agree. I'm getting ready to travel today, so I'm not the one to tell him. [16:19] Great. [16:19] ScottK: ah, you're going to uds too? [16:19] Yes [16:20] persia: To look at this from the other direction, which characters are known to be unambiguous? ASCII between 0x2b..0x7f? [16:20] ScottK: Is it open to anyone, or do you need an invitation? [16:20] It's open to anyone. [16:20] mok0: why don't you come? It will be fun! [16:20] They even feed breakfast and lunch to anyone that shows up. [16:20] ScottK: Ah, shame I didn't know that; I would have liked to go [16:20] Perhaps next year [16:20] andrew_sayers: Unambiguous how? [16:21] If you show up with a sleeping bag, I guarantee we can find you a place to crash. [16:21] mok0: ^^^ [16:21] persia: In that I can reasonable assume that it will be interpreted identically by all implementations. [16:22] ScottK: Heh! Unfortunately I am too busy to leave at the moment... but sounds like it could be fun! [16:22] mok0: just because of the beer :P [16:22] Is it OK for two packages to depend on each other? [16:22] sebner: you're just saying that to make me feel bad [16:23] mok0: I took off for a few days and just showed up at the last one in Boston. I'm glad I did. [16:23] andrew_sayers: There exists no such range. The second byte in double-byte locales is handled differently, depending on the double-byte locale. Your best source of reference about how double-byte encoding works on FAT is Microsoft's programming documentation. [16:23] ScottK: When does the meeting start? [16:23] Laney: it's not the best thing to do [16:23] Laney: If, and only if, they are not both versioned depends, and one of them is essential. [16:23] Actually, I'm assuming that it's not possible even to rename files with an '&' in them. [16:23] mok0: no no. don't worry. I neither will be there nor I drink beer :) [16:23] (etc.) [16:24] mok0: This weekend is fosscamp which is pretty freeform. The actual UDS starts on Monday and runs through Friday. [16:24] andrew_sayers: It's possible to do that, it's just hard. emacs in dired mode will do it in nearly any OS for nearly any FS. [16:24] persia: What does "essential" mean here? [16:24] For context, here's the upstream: http://www.ollisalonen.com/btnx/ - two parts of the same application distributed separately but are both required for it to function. [16:24] persia: it's possible to rename them, you mean? [16:24] Laney: Priority: essential (and no, you can't set that just to make a circular dependency permitted) [16:24] ScottK: will you be there for the whole thing? [16:25] mok0: Yes. Arriving Sunday PM and leaving Saturday very early. [16:25] andrew_sayers: Yes. The names are just bitstrings in the FAT. I think even 0x00 ought be able to be in a filename, with the right arrangement, although that would break most normal file readers (notably the standard C library, unless accessing without the use of the filename). [16:26] I was fortunate enough to fool <<<< convince Canonical that it was worth it to them to pay my travel expenses. [16:26] ScottK: Should be fun [16:26] Yes. I was only there two days last time. [16:26] Laney: do both really mutually require it? or would e.g. btnx-config just recommend btnx? === tb1 is now known as tbf [16:27] sistpoty|work: Well, btnx-config doesn't run without some files created by btnx. I guess btnx would technically install without -config, but you wouldn't be able to do anything with it. [16:27] persia, ScottK: okay, so how about this: provide a little Windows tool on the Ubuntu CD that searches for characters that tend to cause problems, and renames them to something more sensible? [16:27] Laney: then how about introducing a 3rd package (-common) from btnx, which btnx-config could then depend on it? [16:28] andrew_sayers: Something like that sounce reasonable as long as it's up to the user to ask it done. [16:28] sounce/sounds [16:28] Laney: or s.th. like that [16:28] andrew_sayers: That sounds more sensible. Look at the dosfstools source for the list of known hints for locale to charset mapping, and use that as a guide for when to determine which characters might cause issues. Be sure that you know the locale for which the install will be done at the time of the test. [16:30] persia: Just to be clear, when you say "double-byte encodings", are these ASCII-compatible type things like UTF-8, or incompatible (like UTF-16)? === santiago-php is now known as santiago-ve [16:31] andrew_sayers: Depends on the encoding. Shift-JIS is mostly ASCII compatible, but Big5 isn't. Microsoft has fairly good docs about FAT and double-byte encodings, which are worth a read. [16:32] Also, they don't tend to be like UTF8, in that all characters are typically double-byte, although some characters may have a null second byte. [16:32] I'm just thinking that the tool is a lot easier to write if you can assume that any files with no characters above 0x7F are ASCII-compatible. [16:32] Ah. You can't. [16:32] Fair enough. I'll write this all up in an ML post and misrepresent all your positions to my advantage ;) [16:32] sistpoty|work: So you mean -common would depend on then both, or..? [16:33] andrew_sayers: Sounds good :) [16:33] Laney: actually the other way round... btnx would depend on -common, and btnx-config would depend on common (and btnx would also depend on btnx-config) [16:34] sistpoty|work: Why -common? Shouldn't it just be btnx-config depending on btnx and btnx recommending btnx-config (to allow space for e.g. a CLI configurator, or btnk-kconfig)? [16:35] persia: if it works, yes... however I understood, that btnx would also require stuff from btnx-config.. did I misread that? [16:35] Laney: You might also be interested in gizmod, which is a python-scriptable framework for input multiplexing, already in the archive. [16:36] sistpoty|work: I can't tell. From what I see, btnx ought work as long as it is configured, even if btnx-config isn't available, but you can't set up btnx without btnx-config. [16:36] persia: Thanks. btnx seems extremely popular (104 page forum thread), which is why I took this up. [16:36] persia: That's how I see it too. [16:37] Laney: then persia's suggestion should be optimal ;) [16:37] sistpoty|work, persia: Thanks to you both! I expect to be REVUing it soon :) [16:38] Laney: Understood. The big issue with gizmod is that it's a framework, and doesn't have a bunch of GUIs. On the other hand, I'm seeing a proliferation of uinput-based single-device userspace drivers, and would think consolidation on a single framework would improve the situation for all, and provide better support. [16:38] (gizmod does come with a base python script to handle USB remote controls interfacing with lirc, and powermates, but that's not useful for most people) [16:39] So, I'm now answering the hfsprogs guy. Is there a way to have a different set of patches on different platforms? I think he is saying that he can patch the program to run on amd64 [16:40] persia: And all of the same issues apply to FAT16, FAT32, NTFS etc.? For example, NTFS doesn't mandate Unicode? [16:40] mok0: There are several ways to do that. All of them are discouraged. The closest to being acceptable is passing different arguments to ./configure. [16:40] persia, thanks. I can use that ad verbatim :-) [16:41] andrew_sayers: I don't know that much about NTFS. The reason I know about this is for linux <-> linux transfers having issues with files in codepage 932 for non-Japanese locales. [16:41] (on FAT USB sticks) [16:42] Okay, I'll prefix this with "true for FAT, unknown for NTFS". === StevenK_ is now known as StevenK [16:52] I see envyng-core is on it's 3rd -proposed upload in 10 days. [16:52] * ScottK wonders if it was really ready for the archives. [16:54] ScottK: Did any of them make -updates? If not, that's an excellent example of the SRU process working. [16:54] No. Not yet. [16:55] persia: Take a look at the debian/changelog entries. I think it's an example of the complete failure of our package review process. [16:55] persia: One of the latest entries is something like remove the lintian over-rides and fix the problems lintian was complaining about. [16:55] ScottK: what's the problem? [16:56] With envyng-core? It looks to me like it should never have been accepted. [16:56] ScottK: thanks [16:56] I'm pretty stunned to have an SRU about not taking the packages from the PPA. [16:56] ScottK: That might be a good thing, depending on the lintian issues. I'm not excited about the changelog, but that's a different issue. [16:57] ScottK: downloading is different from installing [16:57] persia: Well I think it was shoved in a the last minute due to pressure from people who didn't really look at the package. [16:57] Umm. Yeah. The lintian one might just be a poor changelog, but missing a file or pulling from the PPA seems like a review miss :( We need to get motu-sru back up to fully staffed. [16:57] tseliot: It depends on what the meaning of the word 'is' is. I think that's parsing it very finely. [16:58] * StevenK tries to figure out how to use shar [16:58] persia: We it was initially uploaded to Hardy with the PPA install thing enabled over my (and others) objections. [16:58] (It is one of the shell commands I've never actually had to use.) [16:58] ScottK: are we going to talk about this again? [16:58] persia: After kees jumped in and kvetch we got a last minute upload in that was said to remove that, but now it seems that's not accurate. [16:59] tseliot: If it'd been fixed the first time properly, we wouldn't be. [16:59] Scottk: EnvyNG installs the drivers from Ubuntu's repositories [16:59] StevenK: `shar -S files* > myfiles.shar`, `sh ./myfiles.shar` [16:59] So what's the PPA related change in the latest upload to hardy-proposed? [17:00] ScottK: Ah. That's an issue with motu-release as well then. [17:00] Scottk: the problem is that there is another function which lets users download the packages to a directory [17:00] persia: Yes. I was not one of the ones that advocated it. [17:01] Scottk: and that function still pointed to the PPA. [17:01] Right. And that's my point about it not being fixed correctly before release. [17:01] Scottk: those packages were not installed [17:01] Umm. It's fixed now, so it's not worth rehashing it specifically. [17:01] That makes it less severe, but not correct. [17:01] There are two more general issues of interest [17:02] ScottK: and yes, I noticed the problem and I fixed it [17:02] I appreciate that. [17:02]